refactor(ch06-08): 调整第三篇章节顺序

原：RL(Ch06) → 生成式AI(Ch07) → Agent(Ch08) 新：生成式AI(Ch06) → Agent(Ch07) → RL(Ch08) 感知→创造→行动的叙事线更贴合设计专业学生。更新了目录、CLAUDE.md 和所有章节内编号。 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-25 18:57:59 +08:00
parent 49ceadeb0d
commit cee196b09f
6 changed files with 94 additions and 93 deletions
@@ -0,0 +1,581 @@
+# 第7章：AI Agent——从执行到自主
+
+## 篇章导读
+
+AI Agent（智能体）代表了人工智能的下一个前沿：从"被动响应"到"主动行动"，从"单一能力"到"系统协同"。如果说前几章介绍的AI模型是"工具"，那么AI Agent就是能**自主使用工具的助手**。
+
+想象这样一幅场景：你告诉AI"帮我分析这块场地的开发潜力"，它不再只是被动地等待你一步步指令，而是主动调用地图工具获取地块信息、查询规划数据库核对用地性质、分析日照和交通数据、最终生成一份完整的场地分析报告。这就是AI Agent——一个能感知环境、制定计划、调用工具并持续改进的智能系统。
+
+本章将从规则系统出发，系统介绍LLM-based Agent的架构、推理模式、多Agent协作机制，以及在设计领域的应用前景。
+
+---
+
+## 7.1 从规则到智能
+
+### 7.1.1 规则系统时代
+
+最早的"智能系统"基于**规则（Rules）**，即"如果满足条件A，则执行动作B"。
+
+**典型结构：**
+
+```
+if 场地坡度 > 25%:
+    标记为"不适宜建设"
+elif 场地坡度 > 15%:
+    标记为"限制建设区"
+else:
+    标记为"适宜建设"
+```
+
+**专家系统（Expert System）** 是这一范式的代表：将领域专家的知识编码为大量if-then规则，构建知识库，通过推理引擎进行逻辑推断。
+
+**局限性：**
+
+- 规则难以穷举——现实世界的问题远比预想的复杂
+- 无法泛化——遇到规则未覆盖的新情况便束手无策
+- 维护困难——规则数量膨胀后，系统变得难以理解和更新
+- 缺乏理解——系统并不"理解"规则背后的含义，只是机械执行
+
+### 7.1.2 传统规划方法
+
+在规则系统之外，符号AI（Symbolic AI）还发展出了**规划（Planning）** 方法：
+
+```
+定义初始状态 → 定义目标状态 → 定义操作算子 → 搜索路径 → 执行计划
+```
+
+这类方法在限定领域内效果良好（如国际象棋、路径规划），但面对开放、模糊的现实设计任务时，往往难以定义完整的状态空间和操作算子。
+
+### 7.1.3 LLM带来的范式转变
+
+大语言模型（LLM, Large Language Model）的出现，为Agent的发展带来了根本性的转变：
+
+| 特性 | 规则系统 | LLM-based Agent |
+| --- | --- | --- |
+| 知识表示 | 人工编写规则 | 从海量数据中学习 |
+| 理解能力 | 无真正理解 | 深度语义理解 |
+| 泛化能力 | 仅限规则覆盖范围 | 可处理未见过的任务 |
+| 交互方式 | 结构化输入 | 自然语言对话 |
+| 推理能力 | 逻辑推理 | 逻辑+常识+类比推理 |
+
+LLM之所以能成为Agent的"大脑"，关键在于它具备了：
+
+- **语义理解**：理解用户的真实意图，而非仅仅匹配关键词
+- **常识推理**：运用大量世界知识进行合理推断
+- **指令遵循**：按照复杂的指令序列执行任务
+- **工具学习**：通过描述快速学会使用新工具
+
+---
+
+## 7.2 LLM-based Agent
+
+### 7.2.1 核心组件
+
+一个完整的LLM-based Agent由以下核心模块构成：
+
+```
+┌─────────────────────────────────────────────────┐
+│                  LLM Core                       │
+│           （大语言模型：推理、决策中枢）            │
+├─────────────────────────────────────────────────┤
+│                                                 │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐     │
+│  │  感知     │  │  记忆     │  │  工具     │     │
+│  │Perception│  │ Memory   │  │ Tool Use │     │
+│  └──────────┘  └──────────┘  └──────────┘     │
+│                                                 │
+│  ┌──────────┐  ┌──────────┐                    │
+│  │  规划     │  │  反思     │                    │
+│  │ Planning │  │Reflection│                    │
+│  └──────────┘  └──────────┘                    │
+│                                                 │
+└─────────────────────────────────────────────────┘
+```
+
+### 7.2.2 感知（Perception）
+
+感知模块负责**接收和理解外部信息**：
+
+```
+输入信息 → 解析与理解
+    - 用户指令："帮我设计一个小型社区公园"
+    - 环境状态：场地数据、周边条件、限制因素
+    - 工具反馈：查询结果、执行状态、错误信息
+```
+
+感知的关键在于**理解意图**——用户说"设计一个公园"，Agent需要理解这涉及场地分析、功能分区、路径规划、植物配置等多个子任务。
+
+### 7.2.3 规划（Planning）
+
+规划模块负责**将复杂目标分解为可执行的步骤**：
+
+```
+目标："设计一个社区公园"
+    ↓ 分解
+子任务1：分析场地条件（地形、面积、周边环境）
+子任务2：确定功能分区（儿童游乐、健身、休憩、绿化）
+子任务3：布局路径系统（主入口、环线、无障碍通道）
+子任务4：选择植物配置（适地适树、四季景观）
+子任务5：评估与优化（成本、可达性、景观效果）
+    ↓
+确定执行顺序和依赖关系
+```
+
+### 7.2.4 记忆（Memory）
+
+记忆模块为Agent提供**信息存储和检索**能力：
+
+```
+┌─────────────────────────────────────────┐
+│          短期记忆 (Short-term Memory)     │
+│   对话上下文、当前任务状态、临时变量        │
+│   特点：容量有限，任务结束后清除            │
+├─────────────────────────────────────────┤
+│          长期记忆 (Long-term Memory)      │
+│   知识库、经验积累、历史案例               │
+│   特点：持久存储，可跨任务复用              │
+└─────────────────────────────────────────┘
+```
+
+**记忆的常见实现方式：**
+
+| 类型 | 实现方式 | 说明 |
+| --- | --- | --- |
+| 短期记忆 | 上下文窗口（Context Window） | 当前对话的历史记录 |
+| 工作记忆 | 划痕板（Scratchpad） | 中间计算结果和推理过程 |
+| 长期记忆 | 向量数据库（Vector Database） | 嵌入式检索相关知识 |
+| 程序性记忆 | 工具库（Tool Library） | 已学会的工具使用方法 |
+
+### 7.2.5 工具调用（Tool Use）
+
+工具调用是Agent与外部世界交互的关键能力：
+
+```
+可用工具集：
+    - 数据库查询：查询规划规范、用地数据
+    - GIS工具：获取地形、高程、坡度信息
+    - API调用：获取天气数据、交通数据
+    - 代码执行：运行计算脚本、数据处理
+    - 图像生成：调用Stable Diffusion等生成模型
+    - 文件操作：读取CAD图纸、导出PDF报告
+```
+
+Agent的核心能力在于根据任务需要**自主选择和组合工具**，而非按预设流程机械调用。
+
+---
+
+## 7.3 推理模式
+
+### 7.3.1 思维链（Chain of Thought, CoT）
+
+CoT是最基础的推理增强技术，核心思想是**将推理过程显式化**。
+
+**基本模式：**
+
+```
+问题 → 推理链（一步步思考） → 答案
+```
+
+**设计示例——"设计一个公园"：**
+
+```
+问题："在3000㎡的社区用地上设计一个公园"
+
+推理链：
+Step 1：分析场地条件
+  → 场地面积3000㎡，属于中小型社区公园
+  → 需要满足不同年龄段的休闲需求
+
+Step 2：确定功能分区
+  → 儿童活动区（约600㎡）：滑梯、沙坑、秋千
+  → 健身运动区（约500㎡）：器材、慢跑道
+  → 休闲游憩区（约800㎡）：座椅、凉亭、景观小品
+  → 绿化种植区（约1100㎡）：草坪、花境、乔木
+
+Step 3：布局路径系统
+  → 主入口连接城市道路
+  → 环形主路串联各功能区
+  → 次级步道提供更丰富的游线体验
+
+Step 4：选择植物配置
+  → 选用本地适生树种
+  → 考虑四季景观变化
+  → 兼顾遮阴和观赏需求
+
+答案：完整的公园设计方案
+```
+
+CoT的价值在于**让思考过程可见**，这不仅提升了推理的准确性，也使结果更具可解释性。
+
+### 7.3.2 ReAct（Reasoning + Acting）
+
+ReAct模式将**推理与行动交替进行**，形成"思考-行动-观察"的循环。
+
+**基本循环：**
+
+```
+Think（思考）：分析当前状态，决定下一步行动
+    ↓
+Act（行动）：调用工具或执行操作
+    ↓
+Observe（观察）：获取行动结果和反馈
+    ↓
+Think（思考）：基于观察结果，决定下一步行动
+    ↓
+...（循环直到任务完成）
+```
+
+**设计示例——场地分析任务：**
+
+```
+Think：用户要求分析这块场地的开发潜力，我需要先获取基本信息。
+Act：调用GIS工具，获取场地位置和高程数据。
+Observe：场地位于北纬31.2°，东经121.5°，平均高程12m，最大高差3m。
+
+Think：地形比较平坦，适合建设。接下来需要查询规划限制。
+Act：调用规划数据库，查询该地块的用地性质和容积率限制。
+Observe：用地性质为R2（二类居住用地），容积率≤2.5，建筑限高60m。
+
+Think：用地性质和开发强度明确。现在分析日照和交通条件。
+Act：调用日照分析工具和交通数据API。
+Observe：南侧无遮挡，日照充足。距地铁站800m，公交站200m。
+
+Think：所有关键数据已获取，可以生成分析报告了。
+Act：整合信息，生成场地开发潜力评估报告。
+Observe：报告已生成，包含地形、规划、日照、交通四维分析。
+
+Think：任务完成，向用户展示报告。
+```
+
+ReAct模式的优势在于**可以根据中间结果动态调整策略**，而非严格按照预设流程执行。
+
+### 7.3.3 反思（Reflection）
+
+反思机制使Agent能够**自我评估和改进**：
+
+```
+执行任务 → 评估结果 → 发现不足 → 调整策略 → 重新执行
+```
+
+**示例：**
+
+```
+第1轮：Agent生成设计方案A
+反思：方案A的路径系统不够流畅，存在多个死角
+调整：优化路径拓扑结构，增加环路设计
+
+第2轮：Agent生成改进方案B
+反思：方案B的绿化率偏低，不满足规范要求
+调整：增加绿化面积，调整硬质铺装比例
+
+第3轮：Agent生成最终方案C
+评估：满足所有约束条件，方案质量达标
+输出：最终方案
+```
+
+---
+
+## 7.4 多Agent协作
+
+### 7.4.1 单Agent架构
+
+单Agent适合**相对简单的任务**：
+
+```
+用户请求 → 单一Agent（LLM + 工具） → 执行结果
+```
+
+当任务复杂度增加时，单个Agent面临挑战：
+
+- 上下文窗口有限，难以处理大量信息
+- 同时扮演多个角色，专业性不足
+- 错误容易累积，缺乏交叉验证
+
+### 7.4.2 多Agent协作
+
+多Agent系统通过**分工协作**解决复杂任务：
+
+```
+┌───────────┐    ┌───────────┐    ┌───────────┐
+│ 规划Agent │ →  │ 分析Agent │ →  │ 设计Agent │
+│ Planner   │    │ Analyst   │    │ Designer  │
+└───────────┘    └───────────┘    └───────────┘
+     ↓                ↓                ↓
+  任务分解         数据分析         方案生成
+```
+
+**各Agent的职责分工：**
+
+| Agent角色 | 职责 | 使用工具 |
+| --- | --- | --- |
+| 规划Agent (Planner) | 理解需求、分解任务、协调进度 | 任务管理、调度工具 |
+| 分析Agent (Analyst) | 场地分析、数据收集、条件评估 | GIS工具、数据库查询、统计分析 |
+| 设计Agent (Designer) | 方案生成、空间布局、效果渲染 | CAD工具、生成模型、设计规范库 |
+| 审查Agent (Reviewer) | 合规检查、质量评估、问题标记 | 规范数据库、检查规则 |
+
+### 7.4.3 Agent通信模式
+
+多Agent之间的通信是协作的关键：
+
+```
+模式1：顺序传递（Pipeline）
+  Agent_A → Agent_B → Agent_C → 最终结果
+
+模式2：讨论协商（Debate）
+  Agent_A ← 讨论 → Agent_B
+      ↓ 达成共识
+  最终方案
+
+模式3：层级管理（Hierarchical）
+  管理Agent → 分配任务给多个子Agent → 汇总结果
+
+模式4：群体协作（Group Chat）
+  多个Agent在同一"讨论组"中协作
+  各自贡献专业能力，共同解决问题
+```
+
+### 7.4.4 新兴Agent社会
+
+随着Agent技术的发展，正在出现更复杂的协作形态：
+
+- **Agent团队**：多个Agent组成固定团队，各有专长
+- **Agent市场**：Agent可以"雇佣"其他Agent完成特定子任务
+- **Agent社会**：大量Agent在开放环境中自主交互和协作
+
+> **设计思考**：多Agent协作模式与设计团队的工作方式高度相似——项目总负责人协调各专业（规划、建筑、结构、景观），各专业设计师各司其职又相互配合。AI Agent系统的设计可以从现实设计团队的协作经验中汲取灵感。
+
+---
+
+## 7.5 协作与协议
+
+### 7.5.1 MCP协议（Model Context Protocol）
+
+**MCP（模型上下文协议）** 是连接AI模型与外部工具和数据的开放标准。
+
+**核心问题：数据孤岛**
+
+```
+传统方式：
+  AI模型A → 只能访问数据源X
+  AI模型B → 只能访问数据源Y
+  AI模型C → 只能访问数据源Z
+  → 数据孤岛，工具碎片化
+
+MCP方式：
+  AI模型 ← MCP统一接口 → 所有工具和数据源
+  → 标准化连接，即插即用
+```
+
+**MCP架构：**
+
+```
+┌────────────────────────────────────────────┐
+│            AI Application                  │
+│      （Claude、ChatGPT、自定义应用等）        │
+└──────────────────┬─────────────────────────┘
+                   │ MCP协议
+┌──────────────────┴─────────────────────────┐
+│            MCP Client（客户端）              │
+├────────────────────────────────────────────┤
+│  ┌──────────┐ ┌──────────┐ ┌──────────┐   │
+│  │ 文件系统  │ │ 数据库   │ │ API服务  │   │
+│  │ Server   │ │ Server   │ │ Server   │   │
+│  └──────────┘ └──────────┘ └──────────┘   │
+│  ┌──────────┐ ┌──────────┐                │
+│  │ GIS工具  │ │ 设计软件  │  ...更多工具    │
+│  │ Server   │ │ Server   │                │
+│  └──────────┘ └──────────┘                │
+└────────────────────────────────────────────┘
+```
+
+**MCP的核心价值：**
+
+- **标准化**：统一接口协议，不同工具无需逐一适配
+- **即插即用**：新增工具只需实现MCP接口即可接入
+- **安全可控**：权限管理、审计日志、访问控制
+- **生态开放**：社区可贡献各类MCP Server
+
+### 7.5.2 HITL：人在回路（Human-in-the-Loop）
+
+**HITL（Human-in-the-Loop）** 是在AI决策的关键环节引入人类干预的协作模式。
+
+**HITL的层次：**
+
+| 层次 | 人类角色 | 自动化程度 | 适用场景 |
+| --- | --- | --- | --- |
+| 完全自动 | 无干预 | 100% | 低风险、标准化任务 |
+| 人工审核 | 监督者 | 80-90% | 常规任务，抽查关键节点 |
+| 交互决策 | 合作伙伴 | 50-70% | 复杂设计，人机共创 |
+| 人工主导 | 操作者 | <50% | 高风险、创新性任务 |
+
+**设计中的HITL工作流：**
+
+```
+阶段1：需求输入
+  设计师 → 描述设计需求 → AI理解
+    ↓
+阶段2：AI生成
+  AI → 生成多个候选方案 → 呈现给设计师
+    ↓
+阶段3：设计师审核
+  设计师 → 评估方案 → 提出修改意见
+    ↓
+阶段4：AI调整
+  AI → 基于反馈迭代优化 → 再次呈现
+    ↓
+阶段5：最终确认
+  设计师 → 确认最终方案 → AI输出成果
+```
+
+> **设计实践原则**：AI负责快速的方案生成和数据分析，设计师负责审美判断、人文考量和最终决策。HITL不是在降低效率，而是在确保质量——让机器做机器擅长的事，让设计师专注于真正需要人类智慧的部分。
+
+---
+
+## 7.6 设计应用与展望
+
+### 7.6.1 场景分析Agent
+
+**输入：** 场地基础数据（位置、面积、周边环境）
+
+**分析流程：**
+
+```
+Step 1：地形分析 → 调用GIS工具 → 获取坡度、高程、排水方向
+Step 2：气候分析 → 调用气象数据API → 获取日照、风向、降雨
+Step 3：交通分析 → 调用地图API → 获取可达性、公共交通覆盖
+Step 4：视觉分析 → 调用视域分析工具 → 获取景观视野、视廊
+Step 5：法规分析 → 查询规划数据库 → 获取用地限制、退让要求
+    ↓
+输出：场地综合分析报告（数据、图表、建议）
+```
+
+### 7.6.2 设计生成Agent
+
+**输入：** 设计需求 + 场地分析报告
+
+**生成流程：**
+
+```
+Step 1：理解需求（CoT推理）
+  → 解析功能要求、风格偏好、预算约束
+Step 2：功能布局（调用空间规划工具）
+  → 基于场地条件和需求，生成功能分区方案
+Step 3：路径连接（调用图算法）
+  → 设计交通流线，连接各功能区域
+Step 4：效果渲染（调用生成模型）
+  → 将布局方案转化为可视化效果图
+    ↓
+输出：初步设计方案（图纸、效果图、说明）
+```
+
+### 7.6.3 合规审查Agent
+
+**输入：** 设计方案
+
+**审查流程：**
+
+```
+Step 1：调用规范库 → 获取适用的规划条文和建筑规范
+Step 2：逐条核对 → 对比设计方案与规范要求
+Step 3：标记问题 → 高亮不符合项，标注具体条款
+Step 4：生成报告 → 输出合规审查意见，含修改建议
+    ↓
+输出：合规审查报告
+```
+
+### 7.6.4 多Agent协同设计流程
+
+三个Agent协同工作的完整流程：
+
+```
+场景分析Agent                    设计生成Agent
+    ↓                               ↓
+场地综合分析报告 ────────→  需求+分析→设计方案
+                                  ↓
+                            合规审查Agent
+                                  ↓
+                          审查报告+修改建议
+                                  ↓
+                          设计生成Agent（迭代优化）
+                                  ↓
+                          最终设计方案（设计师确认）
+```
+
+### 7.6.5 未来展望
+
+AI在设计领域的角色将经历三个阶段的演进：
+
+**短期（1-2年）：AI作为工具**
+
+```
+AI辅助能力：
+    - 数据分析与可视化
+    - 快速方案生成（基于模板和规则）
+    - 合规自动化检查
+    - 文档自动生成
+
+设计师角色：主导者，AI是高效的辅助工具
+```
+
+**中期（3-5年）：AI作为助手**
+
+```
+AI增强能力：
+    - 创意发散与灵感推荐
+    - 多方案自动优化与比选
+    - 设计文档智能撰写
+    - 实时协作与迭代反馈
+
+设计师角色：导演者，AI是得力的智能助手
+```
+
+**长期（5-10年）：AI作为合作伙伴**
+
+```
+AI协作能力：
+    - 与设计师共同创造
+    - 自主处理复杂设计任务
+    - 专业评审与质量把控
+    - 跨领域知识融合与创新
+
+设计师角色：战略决策者，AI是平等的创造伙伴
+```
+
+> **核心观点**：无论技术如何演进，设计的核心——对人需求的理解、对美的追求、对社会和环境的责任——始终需要人类设计师的参与。AI Agent的发展方向不是取代设计师，而是让设计师从重复性劳动中解放出来，专注于更有创造性和价值的工作。
+
+---
+
+## 思考与练习
+
+1. **架构理解**：LLM-based Agent与传统规则系统相比，有哪些本质性的优势？又可能引入哪些新的风险？
+
+2. **推理模式**：CoT和ReAct各适用于什么场景？请分别举一个设计领域的应用案例。
+
+3. **多Agent设计**：如果要设计一个"城市规划审批Agent系统"，你会设计哪些Agent角色？它们之间如何协作？
+
+4. **HITL实践**：在设计流程中，哪些环节应该由AI自动完成，哪些环节必须保留人工审核？请给出你的判断依据。
+
+5. **MCP理解**：MCP协议如何解决设计领域AI应用的"数据孤岛"问题？以一个具体的建筑设计场景为例进行说明。
+
+6. **未来展望**：你认为AI Agent在未来10年会如何改变设计行业的就业结构？设计师应该如何准备？
+
+---
+
+## 关键术语
+
+| 中文 | 英文 | 说明 |
+| --- | --- | --- |
+| 智能体 | Agent | 能感知环境并自主行动的AI系统 |
+| 感知 | Perception | 接收和理解外部信息的能力 |
+| 规划 | Planning | 将目标分解为可执行步骤的能力 |
+| 记忆 | Memory | 存储和检索信息的能力（短期+长期） |
+| 工具调用 | Tool Use | 调用外部工具和API的能力 |
+| 思维链 | Chain of Thought (CoT) | 将推理过程显式化的技术 |
+| 推理与行动 | ReAct | 交替进行思考和行动的推理模式 |
+| 反思 | Reflection | 自我评估与改进的机制 |
+| 多Agent协作 | Multi-Agent Collaboration | 多个Agent分工协作解决复杂任务 |
+| 模型上下文协议 | MCP (Model Context Protocol) | 连接AI与外部工具/数据的开放标准 |
+| 人在回路 | HITL (Human-in-the-Loop) | 在AI关键决策环节引入人类干预 |
+| 数据孤岛 | Data Silo | 各系统独立存储数据、互不连通的问题 |
+| 专家系统 | Expert System | 基于规则的早期AI系统 |
+| 上下文窗口 | Context Window | LLM一次能处理的最大文本长度 |