fix(latex): 修复中文引号渲染,''...'' → "..."(139处)
pandoc 转换将中文双引号变为两个ASCII单引号,导致LaTeX中 左右引号均渲染为右引号。替换为Unicode中文引号以正确显示。 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
@@ -2,9 +2,9 @@
|
||||
|
||||
\section{篇章导读}
|
||||
|
||||
AI Agent(智能体)代表了人工智能的下一个前沿:从''被动响应''到''主动行动'',从''单一能力''到''系统协同''。如果说前几章介绍的AI模型是''工具'',那么AI Agent就是能\textbf{自主使用工具的助手}。
|
||||
AI Agent(智能体)代表了人工智能的下一个前沿:从“被动响应”到“主动行动”,从“单一能力”到“系统协同”。如果说前几章介绍的AI模型是“工具”,那么AI Agent就是能\textbf{自主使用工具的助手}。
|
||||
|
||||
想象这样一幅场景:你告诉AI''帮我分析这块场地的开发潜力'',它不再只是被动地等待你一步步指令,而是主动调用地图工具获取地块信息、查询规划数据库核对用地性质、分析日照和交通数据、最终生成一份完整的场地分析报告。这就是AI Agent——一个能感知环境、制定计划、调用工具并持续改进的智能系统。
|
||||
想象这样一幅场景:你告诉AI“帮我分析这块场地的开发潜力”,它不再只是被动地等待你一步步指令,而是主动调用地图工具获取地块信息、查询规划数据库核对用地性质、分析日照和交通数据、最终生成一份完整的场地分析报告。这就是AI Agent——一个能感知环境、制定计划、调用工具并持续改进的智能系统。
|
||||
|
||||
本章将从规则系统出发,系统介绍LLM-based Agent的架构、推理模式、多Agent协作机制,以及在设计领域的应用前景。
|
||||
|
||||
@@ -13,7 +13,7 @@ AI Agent(智能体)代表了人工智能的下一个前沿:从''被动响
|
||||
|
||||
\subsection{规则系统时代}
|
||||
|
||||
最早的''智能系统''基于\textbf{规则(Rules)},即''如果满足条件A,则执行动作B''。
|
||||
最早的“智能系统”基于\textbf{规则(Rules)},即“如果满足条件A,则执行动作B”。
|
||||
|
||||
\textbf{典型结构:}
|
||||
|
||||
@@ -39,7 +39,7 @@ else:
|
||||
\item
|
||||
维护困难——规则数量膨胀后,系统变得难以理解和更新
|
||||
\item
|
||||
缺乏理解——系统并不''理解''规则背后的含义,只是机械执行
|
||||
缺乏理解——系统并不“理解”规则背后的含义,只是机械执行
|
||||
\end{itemize}
|
||||
|
||||
\subsection{传统规划方法}
|
||||
@@ -72,7 +72,7 @@ else:
|
||||
\end{longtable}
|
||||
}
|
||||
|
||||
LLM之所以能成为Agent的''大脑'',关键在于它具备了:
|
||||
LLM之所以能成为Agent的“大脑”,关键在于它具备了:
|
||||
|
||||
\begin{itemize}
|
||||
\tightlist
|
||||
@@ -123,7 +123,7 @@ LLM之所以能成为Agent的''大脑'',关键在于它具备了:
|
||||
- 工具反馈:查询结果、执行状态、错误信息
|
||||
\end{lstlisting}
|
||||
|
||||
感知的关键在于\textbf{理解意图}——用户说''设计一个公园'',Agent需要理解这涉及场地分析、功能分区、路径规划、植物配置等多个子任务。
|
||||
感知的关键在于\textbf{理解意图}——用户说“设计一个公园”,Agent需要理解这涉及场地分析、功能分区、路径规划、植物配置等多个子任务。
|
||||
|
||||
\subsection{规划(Planning)}
|
||||
|
||||
@@ -236,7 +236,7 @@ CoT的价值在于\textbf{让思考过程可见},这不仅提升了推理的
|
||||
|
||||
\subsection{ReAct(Reasoning + Acting)}\label{reactreasoning-acting}
|
||||
|
||||
ReAct模式将\textbf{推理与行动交替进行},形成''思考-行动-观察''的循环。
|
||||
ReAct模式将\textbf{推理与行动交替进行},形成“思考-行动-观察”的循环。
|
||||
|
||||
\textbf{基本循环:}
|
||||
|
||||
@@ -392,7 +392,7 @@ Agent角色
|
||||
\item
|
||||
\textbf{Agent团队}:多个Agent组成固定团队,各有专长
|
||||
\item
|
||||
\textbf{Agent市场}:Agent可以''雇佣''其他Agent完成特定子任务
|
||||
\textbf{Agent市场}:Agent可以“雇佣”其他Agent完成特定子任务
|
||||
\item
|
||||
\textbf{Agent社会}:大量Agent在开放环境中自主交互和协作
|
||||
\end{itemize}
|
||||
@@ -627,11 +627,11 @@ AI协作能力:
|
||||
\item
|
||||
\textbf{推理模式}:CoT和ReAct各适用于什么场景?请分别举一个设计领域的应用案例。
|
||||
\item
|
||||
\textbf{多Agent设计}:如果要设计一个''城市规划审批Agent系统'',你会设计哪些Agent角色?它们之间如何协作?
|
||||
\textbf{多Agent设计}:如果要设计一个“城市规划审批Agent系统”,你会设计哪些Agent角色?它们之间如何协作?
|
||||
\item
|
||||
\textbf{HITL实践}:在设计流程中,哪些环节应该由AI自动完成,哪些环节必须保留人工审核?请给出你的判断依据。
|
||||
\item
|
||||
\textbf{MCP理解}:MCP协议如何解决设计领域AI应用的''数据孤岛''问题?以一个具体的建筑设计场景为例进行说明。
|
||||
\textbf{MCP理解}:MCP协议如何解决设计领域AI应用的“数据孤岛”问题?以一个具体的建筑设计场景为例进行说明。
|
||||
\item
|
||||
\textbf{未来展望}:你认为AI Agent在未来10年会如何改变设计行业的就业结构?设计师应该如何准备?
|
||||
\end{enumerate}
|
||||
|
||||
Reference in New Issue
Block a user