pengxiao
cee196b09f
原：RL(Ch06) → 生成式AI(Ch07) → Agent(Ch08) 新：生成式AI(Ch06) → Agent(Ch07) → RL(Ch08) 感知→创造→行动 的叙事线更贴合设计专业学生。 更新了目录、CLAUDE.md 和所有章节内编号。 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
22 KiB
第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的发展方向不是取代设计师，而是让设计师从重复性劳动中解放出来，专注于更有创造性和价值的工作。
思考与练习
-
架构理解：LLM-based Agent与传统规则系统相比，有哪些本质性的优势？又可能引入哪些新的风险？
-
推理模式：CoT和ReAct各适用于什么场景？请分别举一个设计领域的应用案例。
-
多Agent设计：如果要设计一个"城市规划审批Agent系统"，你会设计哪些Agent角色？它们之间如何协作？
-
HITL实践：在设计流程中，哪些环节应该由AI自动完成，哪些环节必须保留人工审核？请给出你的判断依据。
-
MCP理解：MCP协议如何解决设计领域AI应用的"数据孤岛"问题？以一个具体的建筑设计场景为例进行说明。
-
未来展望：你认为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一次能处理的最大文本长度 |