# 第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一次能处理的最大文本长度 |