\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{ReAct（Reasoning + 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{HITL（Human-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理解
    ↓
阶段2：AI生成
  AI → 生成多个候选方案 → 呈现给设计师
    ↓
阶段3：设计师审核
  设计师 → 评估方案 → 提出修改意见
    ↓
阶段4：AI调整
  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}
}
