feat(latex): 新增 LaTeX 排版系统，从 Markdown 生成 ctexbook
- 新增 officefile/latex/ 目录，包含 main.tex、preamble.tex 及 14 个章节 + 10 个附录 tex 文件 - md→tex 转换流程：pandoc 转换 + _postprocess.py 后处理（去编号、修破折号、清标签） - 修复 5 个 md 源文件的标题层级（H1→H2 降级，统一层级结构） - 配置 VS Code LaTeX Workshop（xelatex + ctexbook 编译链） - 新增 VS Code workspace 和 .gitignore（排除 LaTeX 编译产物） Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,674 @@
|
||||
\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}
|
||||
}
|
||||
Reference in New Issue
Block a user