Files
2026_DesignAI/chapters/ch07-agent.tex
T
pengxiao c9d2ce8a69 fix(latex): 修复中文引号渲染,''...'' → "..."(139处)
pandoc 转换将中文双引号变为两个ASCII单引号,导致LaTeX中
左右引号均渲染为右引号。替换为Unicode中文引号以正确显示。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-29 14:05:08 +08:00

675 lines
25 KiB
TeX
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
\chapter{AI Agent——从执行到自主}
\section{篇章导读}
AI Agent(智能体)代表了人工智能的下一个前沿:从“被动响应”到“主动行动”,从“单一能力”到“系统协同”。如果说前几章介绍的AI模型是“工具”,那么AI Agent就是能\textbf{自主使用工具的助手}
想象这样一幅场景:你告诉AI“帮我分析这块场地的开发潜力”,它不再只是被动地等待你一步步指令,而是主动调用地图工具获取地块信息、查询规划数据库核对用地性质、分析日照和交通数据、最终生成一份完整的场地分析报告。这就是AI Agent——一个能感知环境、制定计划、调用工具并持续改进的智能系统。
本章将从规则系统出发,系统介绍LLM-based Agent的架构、推理模式、多Agent协作机制,以及在设计领域的应用前景。
\section{从规则到智能}
\subsection{规则系统时代}
最早的“智能系统”基于\textbf{规则(Rules},即“如果满足条件A,则执行动作B”。
\textbf{典型结构:}
\begin{lstlisting}
if 场地坡度 > 25%:
标记为"不适宜建设"
elif 场地坡度 > 15%:
标记为"限制建设区"
else:
标记为"适宜建设"
\end{lstlisting}
\textbf{专家系统(Expert System} 是这一范式的代表:将领域专家的知识编码为大量if-then规则,构建知识库,通过推理引擎进行逻辑推断。
\textbf{局限性:}
\begin{itemize}
\tightlist
\item
规则难以穷举——现实世界的问题远比预想的复杂
\item
无法泛化——遇到规则未覆盖的新情况便束手无策
\item
维护困难——规则数量膨胀后,系统变得难以理解和更新
\item
缺乏理解——系统并不“理解”规则背后的含义,只是机械执行
\end{itemize}
\subsection{传统规划方法}
在规则系统之外,符号AI(Symbolic AI)还发展出了\textbf{规划(Planning} 方法:
\begin{lstlisting}
定义初始状态 → 定义目标状态 → 定义操作算子 → 搜索路径 → 执行计划
\end{lstlisting}
这类方法在限定领域内效果良好(如国际象棋、路径规划),但面对开放、模糊的现实设计任务时,往往难以定义完整的状态空间和操作算子。
\subsection{LLM带来的范式转变}
大语言模型(LLM, Large Language Model)的出现,为Agent的发展带来了根本性的转变:
{\def\LTcaptype{none} % do not increment counter
\begin{longtable}[]{@{}lll@{}}
\toprule\noalign{}
特性 & 规则系统 & LLM-based Agent \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
知识表示 & 人工编写规则 & 从海量数据中学习 \\
理解能力 & 无真正理解 & 深度语义理解 \\
泛化能力 & 仅限规则覆盖范围 & 可处理未见过的任务 \\
交互方式 & 结构化输入 & 自然语言对话 \\
推理能力 & 逻辑推理 & 逻辑+常识+类比推理 \\
\end{longtable}
}
LLM之所以能成为Agent的“大脑”,关键在于它具备了:
\begin{itemize}
\tightlist
\item
\textbf{语义理解}:理解用户的真实意图,而非仅仅匹配关键词
\item
\textbf{常识推理}:运用大量世界知识进行合理推断
\item
\textbf{指令遵循}:按照复杂的指令序列执行任务
\item
\textbf{工具学习}:通过描述快速学会使用新工具
\end{itemize}
\section{LLM-based Agent}\label{llm-based-agent}
\subsection{核心组件}
一个完整的LLM-based Agent由以下核心模块构成:
\begin{lstlisting}
┌─────────────────────────────────────────────────┐
│ LLM Core │
│ (大语言模型:推理、决策中枢) │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 感知 │ │ 记忆 │ │ 工具 │ │
│ │Perception│ │ Memory │ │ Tool Use │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 规划 │ │ 反思 │ │
│ │ Planning │ │Reflection│ │
│ └──────────┘ └──────────┘ │
│ │
└─────────────────────────────────────────────────┘
\end{lstlisting}
\subsection{感知(Perception}
感知模块负责\textbf{接收和理解外部信息}
\begin{lstlisting}
输入信息 → 解析与理解
- 用户指令:"帮我设计一个小型社区公园"
- 环境状态:场地数据、周边条件、限制因素
- 工具反馈:查询结果、执行状态、错误信息
\end{lstlisting}
感知的关键在于\textbf{理解意图}——用户说“设计一个公园”,Agent需要理解这涉及场地分析、功能分区、路径规划、植物配置等多个子任务。
\subsection{规划(Planning}
规划模块负责\textbf{将复杂目标分解为可执行的步骤}
\begin{lstlisting}
目标:"设计一个社区公园"
↓ 分解
子任务1:分析场地条件(地形、面积、周边环境)
子任务2:确定功能分区(儿童游乐、健身、休憩、绿化)
子任务3:布局路径系统(主入口、环线、无障碍通道)
子任务4:选择植物配置(适地适树、四季景观)
子任务5:评估与优化(成本、可达性、景观效果)
确定执行顺序和依赖关系
\end{lstlisting}
\subsection{记忆(Memory}
记忆模块为Agent提供\textbf{信息存储和检索}能力:
\begin{lstlisting}
┌─────────────────────────────────────────┐
│ 短期记忆 (Short-term Memory) │
│ 对话上下文、当前任务状态、临时变量 │
│ 特点:容量有限,任务结束后清除 │
├─────────────────────────────────────────┤
│ 长期记忆 (Long-term Memory) │
│ 知识库、经验积累、历史案例 │
│ 特点:持久存储,可跨任务复用 │
└─────────────────────────────────────────┘
\end{lstlisting}
\textbf{记忆的常见实现方式:}
{\def\LTcaptype{none} % do not increment counter
\begin{longtable}[]{@{}lll@{}}
\toprule\noalign{}
类型 & 实现方式 & 说明 \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
短期记忆 & 上下文窗口(Context Window & 当前对话的历史记录 \\
工作记忆 & 划痕板(Scratchpad & 中间计算结果和推理过程 \\
长期记忆 & 向量数据库(Vector Database & 嵌入式检索相关知识 \\
程序性记忆 & 工具库(Tool Library & 已学会的工具使用方法 \\
\end{longtable}
}
\subsection{工具调用(Tool Use}
工具调用是Agent与外部世界交互的关键能力:
\begin{lstlisting}
可用工具集:
- 数据库查询:查询规划规范、用地数据
- GIS工具:获取地形、高程、坡度信息
- API调用:获取天气数据、交通数据
- 代码执行:运行计算脚本、数据处理
- 图像生成:调用Stable Diffusion等生成模型
- 文件操作:读取CAD图纸、导出PDF报告
\end{lstlisting}
Agent的核心能力在于根据任务需要\textbf{自主选择和组合工具},而非按预设流程机械调用。
\section{推理模式}
\subsection{思维链(Chain of Thought, CoT}
CoT是最基础的推理增强技术,核心思想是\textbf{将推理过程显式化}
\textbf{基本模式:}
\begin{lstlisting}
问题 → 推理链(一步步思考) → 答案
\end{lstlisting}
\textbf{设计示例——``设计一个公园''}
\begin{lstlisting}
问题:"在3000㎡的社区用地上设计一个公园"
推理链:
Step 1:分析场地条件
→ 场地面积3000㎡,属于中小型社区公园
→ 需要满足不同年龄段的休闲需求
Step 2:确定功能分区
→ 儿童活动区(约600㎡):滑梯、沙坑、秋千
→ 健身运动区(约500㎡):器材、慢跑道
→ 休闲游憩区(约800㎡):座椅、凉亭、景观小品
→ 绿化种植区(约1100㎡):草坪、花境、乔木
Step 3:布局路径系统
→ 主入口连接城市道路
→ 环形主路串联各功能区
→ 次级步道提供更丰富的游线体验
Step 4:选择植物配置
→ 选用本地适生树种
→ 考虑四季景观变化
→ 兼顾遮阴和观赏需求
答案:完整的公园设计方案
\end{lstlisting}
CoT的价值在于\textbf{让思考过程可见},这不仅提升了推理的准确性,也使结果更具可解释性。
\subsection{ReActReasoning + Acting}\label{reactreasoning-acting}
ReAct模式将\textbf{推理与行动交替进行},形成“思考-行动-观察”的循环。
\textbf{基本循环:}
\begin{lstlisting}
Think(思考):分析当前状态,决定下一步行动
Act(行动):调用工具或执行操作
Observe(观察):获取行动结果和反馈
Think(思考):基于观察结果,决定下一步行动
...(循环直到任务完成)
\end{lstlisting}
\textbf{设计示例——场地分析任务:}
\begin{lstlisting}
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:任务完成,向用户展示报告。
\end{lstlisting}
ReAct模式的优势在于\textbf{可以根据中间结果动态调整策略},而非严格按照预设流程执行。
\subsection{反思(Reflection}
反思机制使Agent能够\textbf{自我评估和改进}
\begin{lstlisting}
执行任务 → 评估结果 → 发现不足 → 调整策略 → 重新执行
\end{lstlisting}
\textbf{示例:}
\begin{lstlisting}
第1轮:Agent生成设计方案A
反思:方案A的路径系统不够流畅,存在多个死角
调整:优化路径拓扑结构,增加环路设计
第2轮:Agent生成改进方案B
反思:方案B的绿化率偏低,不满足规范要求
调整:增加绿化面积,调整硬质铺装比例
第3轮:Agent生成最终方案C
评估:满足所有约束条件,方案质量达标
输出:最终方案
\end{lstlisting}
\section{多Agent协作}
\subsection{单Agent架构}
单Agent适合\textbf{相对简单的任务}
\begin{lstlisting}
用户请求 → 单一Agent(LLM + 工具) → 执行结果
\end{lstlisting}
当任务复杂度增加时,单个Agent面临挑战:
\begin{itemize}
\tightlist
\item
上下文窗口有限,难以处理大量信息
\item
同时扮演多个角色,专业性不足
\item
错误容易累积,缺乏交叉验证
\end{itemize}
\subsection{多Agent协作}
多Agent系统通过\textbf{分工协作}解决复杂任务:
\begin{lstlisting}
┌───────────┐ ┌───────────┐ ┌───────────┐
│ 规划Agent │ → │ 分析Agent │ → │ 设计Agent │
│ Planner │ │ Analyst │ │ Designer │
└───────────┘ └───────────┘ └───────────┘
↓ ↓ ↓
任务分解 数据分析 方案生成
\end{lstlisting}
\textbf{各Agent的职责分工:}
{\def\LTcaptype{none} % do not increment counter
\begin{longtable}[]{@{}
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3333}}
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3333}}
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3333}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
Agent角色
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
职责
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
使用工具
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
规划Agent (Planner) & 理解需求、分解任务、协调进度 & 任务管理、调度工具 \\
分析Agent (Analyst) & 场地分析、数据收集、条件评估 & GIS工具、数据库查询、统计分析 \\
设计Agent (Designer) & 方案生成、空间布局、效果渲染 & CAD工具、生成模型、设计规范库 \\
审查Agent (Reviewer) & 合规检查、质量评估、问题标记 & 规范数据库、检查规则 \\
\end{longtable}
}
\subsection{Agent通信模式}
多Agent之间的通信是协作的关键:
\begin{lstlisting}
模式1:顺序传递(Pipeline
Agent_A → Agent_B → Agent_C → 最终结果
模式2:讨论协商(Debate
Agent_A ← 讨论 → Agent_B
↓ 达成共识
最终方案
模式3:层级管理(Hierarchical
管理Agent → 分配任务给多个子Agent → 汇总结果
模式4:群体协作(Group Chat
多个Agent在同一"讨论组"中协作
各自贡献专业能力,共同解决问题
\end{lstlisting}
\subsection{新兴Agent社会}
随着Agent技术的发展,正在出现更复杂的协作形态:
\begin{itemize}
\tightlist
\item
\textbf{Agent团队}:多个Agent组成固定团队,各有专长
\item
\textbf{Agent市场}:Agent可以“雇佣”其他Agent完成特定子任务
\item
\textbf{Agent社会}:大量Agent在开放环境中自主交互和协作
\end{itemize}
\begin{quote}
\textbf{设计思考}:多Agent协作模式与设计团队的工作方式高度相似——项目总负责人协调各专业(规划、建筑、结构、景观),各专业设计师各司其职又相互配合。AI Agent系统的设计可以从现实设计团队的协作经验中汲取灵感。
\end{quote}
\section{协作与协议}
\subsection{MCP协议(Model Context Protocol}
\textbf{MCP(模型上下文协议)} 是连接AI模型与外部工具和数据的开放标准。
\textbf{核心问题:数据孤岛}
\begin{lstlisting}
传统方式:
AI模型A → 只能访问数据源X
AI模型B → 只能访问数据源Y
AI模型C → 只能访问数据源Z
→ 数据孤岛,工具碎片化
MCP方式:
AI模型 ← MCP统一接口 → 所有工具和数据源
→ 标准化连接,即插即用
\end{lstlisting}
\textbf{MCP架构:}
\begin{lstlisting}
┌────────────────────────────────────────────┐
│ AI Application │
Claude、ChatGPT、自定义应用等) │
└──────────────────┬─────────────────────────┘
│ MCP协议
┌──────────────────┴─────────────────────────┐
│ MCP Client(客户端) │
├────────────────────────────────────────────┤
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 文件系统 │ │ 数据库 │ │ API服务 │ │
│ │ Server │ │ Server │ │ Server │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ │
│ │ GIS工具 │ │ 设计软件 │ ...更多工具 │
│ │ Server │ │ Server │ │
│ └──────────┘ └──────────┘ │
└────────────────────────────────────────────┘
\end{lstlisting}
\textbf{MCP的核心价值:}
\begin{itemize}
\tightlist
\item
\textbf{标准化}:统一接口协议,不同工具无需逐一适配
\item
\textbf{即插即用}:新增工具只需实现MCP接口即可接入
\item
\textbf{安全可控}:权限管理、审计日志、访问控制
\item
\textbf{生态开放}:社区可贡献各类MCP Server
\end{itemize}
\subsection{HITL:人在回路(Human-in-the-Loop}
\textbf{HITLHuman-in-the-Loop} 是在AI决策的关键环节引入人类干预的协作模式。
\textbf{HITL的层次:}
{\def\LTcaptype{none} % do not increment counter
\begin{longtable}[]{@{}llll@{}}
\toprule\noalign{}
层次 & 人类角色 & 自动化程度 & 适用场景 \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
完全自动 & 无干预 & 100\% & 低风险、标准化任务 \\
人工审核 & 监督者 & 80-90\% & 常规任务,抽查关键节点 \\
交互决策 & 合作伙伴 & 50-70\% & 复杂设计,人机共创 \\
人工主导 & 操作者 & \textless50\% & 高风险、创新性任务 \\
\end{longtable}
}
\textbf{设计中的HITL工作流:}
\begin{lstlisting}
阶段1:需求输入
设计师 → 描述设计需求 → AI理解
阶段2AI生成
AI → 生成多个候选方案 → 呈现给设计师
阶段3:设计师审核
设计师 → 评估方案 → 提出修改意见
阶段4AI调整
AI → 基于反馈迭代优化 → 再次呈现
阶段5:最终确认
设计师 → 确认最终方案 → AI输出成果
\end{lstlisting}
\begin{quote}
\textbf{设计实践原则}:AI负责快速的方案生成和数据分析,设计师负责审美判断、人文考量和最终决策。HITL不是在降低效率,而是在确保质量——让机器做机器擅长的事,让设计师专注于真正需要人类智慧的部分。
\end{quote}
\section{设计应用与展望}
\subsection{场景分析Agent}
\textbf{输入:} 场地基础数据(位置、面积、周边环境)
\textbf{分析流程:}
\begin{lstlisting}
Step 1:地形分析 → 调用GIS工具 → 获取坡度、高程、排水方向
Step 2:气候分析 → 调用气象数据API → 获取日照、风向、降雨
Step 3:交通分析 → 调用地图API → 获取可达性、公共交通覆盖
Step 4:视觉分析 → 调用视域分析工具 → 获取景观视野、视廊
Step 5:法规分析 → 查询规划数据库 → 获取用地限制、退让要求
输出:场地综合分析报告(数据、图表、建议)
\end{lstlisting}
\subsection{设计生成Agent}
\textbf{输入:} 设计需求 + 场地分析报告
\textbf{生成流程:}
\begin{lstlisting}
Step 1:理解需求(CoT推理)
→ 解析功能要求、风格偏好、预算约束
Step 2:功能布局(调用空间规划工具)
→ 基于场地条件和需求,生成功能分区方案
Step 3:路径连接(调用图算法)
→ 设计交通流线,连接各功能区域
Step 4:效果渲染(调用生成模型)
→ 将布局方案转化为可视化效果图
输出:初步设计方案(图纸、效果图、说明)
\end{lstlisting}
\subsection{合规审查Agent}
\textbf{输入:} 设计方案
\textbf{审查流程:}
\begin{lstlisting}
Step 1:调用规范库 → 获取适用的规划条文和建筑规范
Step 2:逐条核对 → 对比设计方案与规范要求
Step 3:标记问题 → 高亮不符合项,标注具体条款
Step 4:生成报告 → 输出合规审查意见,含修改建议
输出:合规审查报告
\end{lstlisting}
\subsection{多Agent协同设计流程}
三个Agent协同工作的完整流程:
\begin{lstlisting}
场景分析Agent 设计生成Agent
↓ ↓
场地综合分析报告 ────────→ 需求+分析→设计方案
合规审查Agent
审查报告+修改建议
设计生成Agent(迭代优化)
最终设计方案(设计师确认)
\end{lstlisting}
\subsection{未来展望}
AI在设计领域的角色将经历三个阶段的演进:
\textbf{短期(1-2年):AI作为工具}
\begin{lstlisting}
AI辅助能力:
- 数据分析与可视化
- 快速方案生成(基于模板和规则)
- 合规自动化检查
- 文档自动生成
设计师角色:主导者,AI是高效的辅助工具
\end{lstlisting}
\textbf{中期(3-5年):AI作为助手}
\begin{lstlisting}
AI增强能力:
- 创意发散与灵感推荐
- 多方案自动优化与比选
- 设计文档智能撰写
- 实时协作与迭代反馈
设计师角色:导演者,AI是得力的智能助手
\end{lstlisting}
\textbf{长期(5-10年):AI作为合作伙伴}
\begin{lstlisting}
AI协作能力:
- 与设计师共同创造
- 自主处理复杂设计任务
- 专业评审与质量把控
- 跨领域知识融合与创新
设计师角色:战略决策者,AI是平等的创造伙伴
\end{lstlisting}
\begin{quote}
\textbf{核心观点}:无论技术如何演进,设计的核心——对人需求的理解、对美的追求、对社会和环境的责任——始终需要人类设计师的参与。AI Agent的发展方向不是取代设计师,而是让设计师从重复性劳动中解放出来,专注于更有创造性和价值的工作。
\end{quote}
\section{思考与练习}
\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
\textbf{架构理解}LLM-based Agent与传统规则系统相比,有哪些本质性的优势?又可能引入哪些新的风险?
\item
\textbf{推理模式}:CoT和ReAct各适用于什么场景?请分别举一个设计领域的应用案例。
\item
\textbf{多Agent设计}:如果要设计一个“城市规划审批Agent系统”,你会设计哪些Agent角色?它们之间如何协作?
\item
\textbf{HITL实践}:在设计流程中,哪些环节应该由AI自动完成,哪些环节必须保留人工审核?请给出你的判断依据。
\item
\textbf{MCP理解}:MCP协议如何解决设计领域AI应用的“数据孤岛”问题?以一个具体的建筑设计场景为例进行说明。
\item
\textbf{未来展望}:你认为AI Agent在未来10年会如何改变设计行业的就业结构?设计师应该如何准备?
\end{enumerate}
\section{关键术语}
{\def\LTcaptype{none} % do not increment counter
\begin{longtable}[]{@{}
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3333}}
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3333}}
>{\raggedright\arraybackslash}p{(\linewidth - 4\tabcolsep) * \real{0.3333}}@{}}
\toprule\noalign{}
\begin{minipage}[b]{\linewidth}\raggedright
中文
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
英文
\end{minipage} & \begin{minipage}[b]{\linewidth}\raggedright
说明
\end{minipage} \\
\midrule\noalign{}
\endhead
\bottomrule\noalign{}
\endlastfoot
智能体 & 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一次能处理的最大文本长度 \\
\end{longtable}
}