第一章：Agent 基础概念与架构
1.1 什么是 AI Agent：从概念定义到本质特征
AI Agent 是当前大模型应用领域最受关注的技术范式。要准确理解它，需要回到这个概念的本质。
斯坦福大学教授 Yoav Shoham 在 1993 年的经典论文中给出了一个被广泛引用的定义：Agent 是能够感知环境、自主行动并对其行为负责的计算实体。这个定义虽然朴素，但奠定了后续几十年 Agent 研究的基本框架。
进入大模型时代后，Lilian Weng 在 "LLM Powered Autonomous Agents" 中给出了更贴合当前技术栈的定义：以 LLM 为核心控制器，通过规划、记忆和工具使用完成复杂任务的智能体。关键在于把 LLM 定位为 Agent 的"大脑"，而非全部。
从工程视角看，一个真正的 AI Agent 需要具备四个本质特征。
自主性（Autonomy）：Agent 应当能在没有人类持续干预的情况下独立完成任务分解、决策和执行。这与传统聊天机器人有本质区别------聊天机器人对单条输入产生单条输出，Agent 能自主决定下一步做什么。
目标导向性（Goal-oriented）：Agent 的行为不是为了生成一条"看起来正确"的回复，而是为了达成具体目标。比如"分析这份财报并给出投资建议"是一个目标，Agent 需要拆解为读取文件、提取数据、计算指标、对比历史、生成报告等多个步骤。
环境交互性（Environment Interaction）：Agent 必须能感知外部环境状态，并通过行动改变环境。"环境"可以是文件系统、数据库、API、浏览器，甚至物理世界（机器人场景）。
持续运行性（Persistence）：Agent 通常不是一次性问答，而是一个持续运行的循环------在多个时间步中不断感知、决策、行动，直到任务完成或被终止。
下面用一个简化的 Python 伪代码来展示 Agent 的核心结构：
python
class Agent:
def __init__(self, llm, tools, memory):
self.llm = llm # 大模型作为大脑
self.tools = tools # 可调用的工具集
self.memory = memory # 记忆系统
def run(self, task):
while not self.is_done(task):
# 感知当前状态
observation = self.observe()
# 规划下一步行动
action = self.llm.plan(task, observation, self.memory)
# 执行行动
result = self.execute(action)
# 更新记忆
self.memory.update(action, result)
return self.get_result()这段伪代码揭示了 Agent 的核心运行逻辑：感知、规划、执行、更新的循环。不同类型的 Agent 在这个框架上会有不同实现，但底层结构高度一致。
业界对 Agent 的定义存在分歧。一派认为只有具备完全自主决策能力的系统才算 Agent，另一派认为只要 LLM 能调用工具就算 Agent。这种分歧在实际工程中不影响架构选型，理解这个光谱而非执着于某个定义更有助于实际工作。
1.2 Agent 系统核心架构：感知、记忆、规划、执行、反思
一个完整的 Agent 系统由五个核心模块构成，它们协同工作构成 Agent 的认知架构。
感知模块（Perception） 是 Agent 与外部世界的接口，负责将环境中的原始信息转化为 Agent 可理解的格式。文本场景中可能就是简单的输入解析器；多模态场景中则需要处理图像、音频、视频等非结构化数据。感知模块的设计直接影响 Agent 对环境的理解精度。
记忆模块（Memory） 是 Agent 的信息存储中心，通常分为短期记忆和长期记忆。短期记忆保存当前任务的上下文信息，类似人类的工作记忆；长期记忆存储历史经验、用户偏好等持久化信息。工程实现中，短期记忆通常用对话历史列表或滑动窗口管理，长期记忆依赖向量数据库或知识图谱。
bash
┌──────────────────────────────────────────────┐
│ Agent 系统架构 │
├──────────┬──────────┬──────────┬──────────────┤
│ 感知模块 │ 记忆模块 │ 规划模块 │ 执行模块 │
│ Perception│ Memory │ Planning │ Execution │
├──────────┴──────────┴──────────┴──────────────┤
│ 反思模块 │
│ Reflection │
├──────────────────────────────────────────────┤
│ LLM (大语言模型) 核心 │
└──────────────────────────────────────────────┘规划模块（Planning） 是 Agent 的决策中心，接收感知模块传来的环境信息和记忆模块中的历史数据，决定 Agent 接下来做什么。规划可以是即时的一步决策，也可以是多步骤长程规划。复杂的规划模块还会使用思维链（CoT）、思维树（ToT）等推理技术提升决策质量。
执行模块（Execution） 负责将规划模块的决策转化为具体行动，通常意味着调用外部工具或 API。执行模块需要处理参数构造、错误处理、结果解析等工程细节，应当具备重试机制、超时控制和并发执行能力。
反思模块（Reflection） 是区分初级 Agent 和高级 Agent 的关键，允许 Agent 从执行结果中学习，评估决策是否正确，并在必要时调整策略。AutoGPT 和 Reflexion 等框架都把反思作为核心机制。
五个模块之间的协作流程可以概括为以下循环：
| 步骤 | 模块 | 输入 | 输出 |
|---|---|---|---|
| 1 | 感知 | 环境状态 | 结构化观察数据 |
| 2 | 记忆 | 观察数据 + 历史记忆 | 检索到的相关上下文 |
| 3 | 规划 | 任务目标 + 观察 + 上下文 | 行动计划 |
| 4 | 执行 | 行动计划 | 执行结果 |
| 5 | 反思 | 执行结果 + 预期目标 | 评估和调整策略 |
五个模块并非总是全部存在。轻量级 Agent 可能只有感知、规划和执行，没有显式的记忆和反思。但随着任务复杂度提升，缺少记忆和反思的 Agent 往往在长程任务中表现不佳。
实际工程中，模块之间的边界并不总是清晰的。规划模块可能内嵌记忆检索逻辑，执行模块可能包含简单的反思能力。重要的不是模块的物理划分，而是这些功能是否被完整覆盖。
1.3 Agent 核心范式：从 PRA 循环到 ReAct 模式
Agent 的运行模式经历了从简单到复杂的演进。理解这些范式的演进，有助于在不同场景下选择合适的架构。
最基础的范式是 PRA 循环（Perception-Reasoning-Action），即"感知-推理-行动"循环。这是 Agent 的最简形式：感知环境状态，进行推理决策，执行行动，然后进入下一轮循环。PRA 循环的概念来源于经典的感知-行动循环（Sense-Act Cycle），在机器人控制领域有悠久历史。
PRA 循环的问题在于它过于简化了推理过程。实际任务中，Agent 往往需要在推理和行动之间交替进行：先思考一下，执行一个动作，根据结果再思考下一步。这就是 ReAct（Reasoning and Acting）模式的由来。
ReAct 模式由 Yao 等人在 2022 年提出，核心思想是让 LLM 在推理（Reasoning）和行动（Acting）之间交替进行。在每一步中，模型先生成一个推理过程（Thought），然后决定一个行动（Action），执行行动后获得观察结果（Observation），再进入下一轮推理。
一个典型的 ReAct 流程如下：
bash
Thought 1: 我需要查找北京今天的天气
Action 1: search_weather("北京")
Observation 1: 北京今天晴，最高温度35度
Thought 2: 用户可能需要防暑建议，我应该给出高温提醒
Action 2: generate_response("北京今天晴，最高35度，注意防暑")
Observation 2: 回复已发送
Thought 3: 任务已完成ReAct 模式的优势在于将推理过程显式化，使 Agent 的决策过程可追溯、可调试。相比纯推理模式（如 CoT），ReAct 能通过行动获取外部信息，克服 LLM 知识截止日期的限制。相比纯行动模式，ReAct 的推理步骤能提升决策质量。
以下是 ReAct 模式的简化实现：
python
def react_loop(llm, tools, task, max_steps=10):
messages = [{"role": "user", "content": task}]
for step in range(max_steps):
# LLM 生成 Thought + Action
response = llm.chat(messages, tools=tools)
if response.is_final:
return response.content
# 执行工具调用
tool_result = execute_tool(response.tool_call, tools)
# 将观察结果加入上下文
messages.append({"role": "assistant", "content": response.thought})
messages.append({"role": "tool", "content": tool_result})
return "达到最大步数限制"除 ReAct 外，还有几种值得关注的 Agent 范式。
Plan-and-Execute 模式将任务分为两个阶段：先一次性生成完整的执行计划，再逐步执行。适合步骤明确、不易变化的任务，但在动态环境中可能不够灵活。
Reflexion 模式在 ReAct 基础上增加了自我反思机制。当 Agent 执行完一个行动后，它会评估结果是否符合预期，如果不符合则生成反思并调整后续策略。这种范式在代码生成、数学推理等需要迭代改进的场景中表现优异。
LATS（Language Agent Tree Search）模式更进一步，使用树搜索策略探索多条可能的行动路径，并通过自我评估选择最优路径。计算成本较高，但在复杂决策任务中效果更好。
| 范式 | 核心思想 | 优势 | 适用场景 |
|---|---|---|---|
| PRA 循环 | 感知-推理-行动 | 结构简单 | 基础任务 |
| ReAct | 推理与行动交替 | 可追溯、可调试 | 通用任务 |
| Plan-and-Execute | 先规划后执行 | 步骤明确 | 流程固定任务 |
| Reflexion | 带自我反思 | 迭代改进 | 代码生成、推理 |
| LATS | 树搜索策略 | 全局最优 | 复杂决策任务 |
在实际项目中选择 Agent 范式时，应当在任务复杂度和计算成本之间取得平衡。ReAct 是目前最常用的通用范式，多数 Agent 框架（如 LangChain、LlamaIndex）都将其作为默认模式。
1.4 Agent 与 Workflow 的边界：自主性与确定性之争
在 Agent 技术落地过程中，一个反复出现的争论是：Agent 和 Workflow（工作流）的边界在哪里？这个问题不仅关乎概念辨析，更直接影响架构选型。
Workflow 是一种预定义流程的执行框架。在 Workflow 中，每一步做什么、下一步走哪个分支，都是在运行前就确定好的。LLM 在 Workflow 中通常被用作某个节点的处理工具，比如文本摘要、情感分析、数据提取等。流程的控制权在编排系统手中。
Agent 则不同。Agent 拥有对流程的控制权，它可以根据当前状态自主决定下一步做什么、是否需要调用工具、是否已经完成任务。LLM 在 Agent 中不仅是处理工具，更是决策中心。
Anthropic 在其技术文章中给出了一个清晰的对比例子。假设要实现一个"客户需求处理"系统：
Workflow 方式：先将需求分类（LLM 节点），然后根据分类结果路由到不同处理流程（固定分支），每个流程中有预定义的步骤序列。整个流程的可视化图在运行前就完全确定。
Agent 方式：把需求交给 Agent，Agent 自主判断需要哪些信息，决定是否查询数据库、是否需要调用分类模型、是否需要人工介入。运行路径在运行时才确定。
两者各有优劣。Workflow 的优势在于确定性和可预测性------每次执行的路径可控，便于调试和审计。Agent 的优势在于灵活性和适应性------面对意料之外的情况，Agent 可以自主调整策略。
实际工程中，纯 Agent 和纯 Workflow 都不多见。大多数生产系统采用混合架构：在关键路径上使用 Workflow 保证确定性，在需要灵活决策的环节引入 Agent 的自主能力。
bash
确定性 ──────────────────────────── 自主性
│ │
Workflow Hybrid Agent
(全预定义) (部分自主)
│
Pure Agent
(全自主)判断一个系统应该用 Workflow 还是 Agent，可以参考以下决策矩阵：
| 维度 | 偏向 Workflow | 偏向 Agent |
|---|---|---|
| 任务路径 | 步骤固定且已知 | 路径不确定，需动态探索 |
| 错误代价 | 错误成本高，需严格管控 | 错误可容忍，允许试错 |
| 环境变化 | 环境稳定，规则明确 | 环境多变，需要适应 |
| 调试需求 | 需要完整审计追踪 | 结果正确即可，过程不关键 |
| 延迟要求 | 严格延迟限制 | 可接受较长执行时间 |
一个常见的误区是把 Agent 视为 Workflow 的"升级版"。实际上，它们是互补关系而非替代关系。在许多企业场景中，Workflow 仍然是更可靠的选择，尤其是涉及资金交易、合规审批等高风险流程。Agent 的价值在于处理那些无法预先穷举所有分支的复杂场景。
一些现代 Agent 框架已经支持在 Agent 内部嵌入 Workflow。比如 Agent 可以在规划阶段生成一个类似 Workflow 的执行计划，然后在执行阶段按照计划逐步执行。这种"Agent 规划 + Workflow 执行"的混合模式，兼顾了灵活性和确定性。
1.5 Agentic AI 的自主性等级与认知架构
Agentic AI 是近年来从学术研究走向工程实践的重要概念。不同 Agent 系统的自主性程度差异巨大，有必要建立一个等级框架来进行区分。
参照自动驾驶的 SAE（Society of Automotive Engineers，国际汽车工程师学会）等级体系，可以为 AI Agent 定义类似的自主性等级。
Level 0：无自主性。系统完全由人类控制，LLM 仅作为响应工具。典型代表是传统聊天机器人，每次交互都是独立的请求-响应对。
Level 1：辅助型自主。系统能在人类指导下完成单一任务步骤。比如 LLM 调用一个工具（如搜索）后返回结果，由人类决定下一步。工具调用是自动的，但流程控制权在人类。
Level 2：有限自主。系统能在特定任务范围内自主完成多步骤操作，但需要人类在关键节点进行确认。比如一个数据分析 Agent 可以自主读取数据、清洗、分析，但在生成最终报告前需要人类审核中间结果。
Level 3：条件自主。系统在大多数情况下能自主完成任务，仅在遇到边界情况时请求人类介入。这类 Agent 具备基本的自我评估能力，能识别自己何时需要帮助。
Level 4：高度自主。系统能在广泛任务范围内自主完成全流程，包括错误恢复和策略调整。人类主要提供任务描述和最终验收，中间过程无需干预。
Level 5：完全自主。系统能自主理解任务目标、规划执行策略、处理异常情况，并在任务完成后自我评估和学习改进。这是目前的技术天花板，尚无系统能稳定达到。
| 等级 | 名称 | 人类参与度 | 典型特征 |
|---|---|---|---|
| L0 | 无自主性 | 全程参与 | 单轮问答 |
| L1 | 辅助型 | 高 | 单工具调用 |
| L2 | 有限自主 | 中 | 多步骤，关键节点确认 |
| L3 | 条件自主 | 低 | 自主完成，遇阻求助 |
| L4 | 高度自主 | 极低 | 自主全流程，自纠错 |
| L5 | 完全自主 | 无 | 自主学习与进化 |
认知架构是支撑自主性的底层结构。一个 Agent 的认知架构决定了它如何处理信息、做出决策和积累经验。
当前主流的 Agent 认知架构主要有三种类型。
反应式架构（Reactive Architecture）不维护内部状态，直接根据当前感知做出反应。响应速度快，但缺乏规划能力，适合简单、确定的环境。
deliberative 架构（Deliberative Architecture）维护完整的内部世界模型，通过符号推理做出决策。规划能力强，但计算开销大，适合复杂但变化缓慢的环境。
混合架构（Hybrid Architecture）结合两者优点，在需要快速反应时使用反应式策略，在需要深度思考时切换到 deliberative 模式。多数现代 Agent 系统采用混合架构。
理解自主性等级的实际意义在于工程选型。并非所有场景都需要 L4 或 L5 的自主性。在许多企业应用中，L2 到 L3 的自主性已经足够，而且更容易落地、更易于审计。盲目追求高自主性反而会增加系统复杂度和不可控风险。
1.6 LLM 作为 Agent 大脑：角色定位与能力边界
在 Agent 系统中，LLM 扮演着"大脑"的角色。它负责理解任务目标、分析环境信息、制定执行计划、生成工具调用指令。但 LLM 的能力边界在哪里？它能做什么、不能做什么？这是设计 Agent 系统时必须厘清的问题。
LLM 在 Agent 中的核心职责可以归纳为四个方面。
任务理解：LLM 需要准确理解用户给出的任务描述，包括显式要求和隐含期望。这要求 LLM 具备较强的自然语言理解能力和常识推理能力。对于领域特定任务，LLM 还需要理解领域术语和专业概念。
策略规划：LLM 需要根据任务目标和当前环境状态制定执行策略。这包括决定需要哪些信息、调用哪些工具、以什么顺序执行。规划质量直接决定 Agent 的整体表现。
工具选择与调用：LLM 需要从可用工具集中选择合适的工具，并生成正确的调用参数。这要求 LLM 理解每个工具的功能、输入输出格式和使用约束。当前主流 LLM 通过 function calling（函数调用）接口来实现这一能力。
结果解读：工具执行后返回的结果需要 LLM 进行解读，判断是否满足任务需求。如果结果不符合预期，LLM 还需要分析原因并调整策略。
以下是一个 LLM 作为 Agent 大脑的提示词框架示例：
python
SYSTEM_PROMPT = """你是一个任务执行 Agent。
当前任务：{task}
可用工具：{tools_description}
当前状态：{current_state}
历史记录：{history}
请按以下格式输出：
Thought: 推理过程
Action: 工具调用（JSON格式）
或
Thought: 任务已完成
Final Answer: 最终回复
"""然而，LLM 作为 Agent 大脑也存在明确的能力边界。
上下文窗口限制：LLM 的上下文长度是有限的，当对话历史和工具输出累积到一定量时，早期信息会被截断或压缩。这导致 Agent 在长程任务中可能遗忘关键信息。虽然上下文窗口在不断扩大（从 4K 到 128K 甚至更长），但信息利用效率并不随窗口大小线性增长。
幻觉问题：LLM 可能生成不存在的工具名称、错误的参数格式或虚构的事实。在 Agent 场景中，幻觉比纯文本对话更危险，因为 Agent 可能基于幻觉信息执行实际操作。工具调用的结构化输出能在一定程度上缓解这个问题，但不能完全消除。
推理深度不足：面对需要多步逻辑推理的复杂问题，LLM 的推理链条可能在中途断裂或偏离正确方向。思维链技术能改善这个问题，但无法根本解决。
实时信息缺失：LLM 的知识有截止日期，对于训练后发生的事件一无所知。Agent 需要通过工具调用来获取实时信息，但这增加了执行复杂度和延迟。
针对这些局限，工程上通常采用以下补偿策略：
| 局限性 | 补偿策略 | 实现方式 |
|---|---|---|
| 上下文限制 | 记忆管理 | 摘要压缩、向量检索 |
| 幻觉问题 | 输出约束 | 结构化输出、校验层 |
| 推理深度 | 推理增强 | CoT、ToT、多轮反思 |
| 实时信息 | 工具集成 | 搜索API、数据库查询 |
需要强调的是，LLM 在 Agent 架构中虽然重要，但不是全部。一个成熟的 Agent 系统还需要大量的"非 LLM"工程：确定性逻辑处理、错误恢复机制、并发控制、状态管理等。把 LLM 视为万能解决方案是 Agent 工程中最常见的陷阱之一。
1.7 Observation 机制：闭环反馈的关键环节
Observation（观察）是 Agent 闭环架构中最容易被忽视、但对系统可靠性影响最大的环节。它指的是 Agent 在执行行动后获取环境反馈信息的机制。
在 ReAct 模式中，Observation 是 Thought-Action-Observation 三元组的第三元素。Action 改变环境，Observation 感知这种改变，下一个 Thought 基于 Observation 做出新的推理。如果 Observation 机制设计不当，整个闭环就会断裂。
Observation 机制的实现看似简单------不就是获取工具的返回值吗？但在实际工程中，它面临多个挑战。
信息过载：工具返回的信息量可能远超 LLM 能有效处理的范围。一个数据库查询可能返回上千行数据，一个网页抓取可能产生数万字内容。如果直接把原始结果塞进 LLM 的上下文，不仅浪费 token，还会干扰决策。
信息缺失：有些工具的返回值并不能完整反映环境的真实状态。比如调用一个发送邮件的 API，返回值可能只是一个"成功"标志，但邮件是否真的到达了收件箱、是否被标记为垃圾邮件，这些信息是缺失的。
信息噪声：工具返回的数据可能包含大量无关信息。比如搜索 API 返回的页面中可能有广告、导航栏、页脚等与任务无关的内容。Agent 需要从中提取有价值的部分。
针对这些挑战，一个设计良好的 Observation 机制应当包含以下处理层：
python
def process_observation(raw_result, task_context):
# 1. 格式标准化：统一不同工具的输出格式
normalized = normalize_output(raw_result)
# 2. 信息过滤：去除噪声，保留与任务相关的内容
filtered = filter_relevant(normalized, task_context)
# 3. 摘要压缩：对过长内容进行摘要
if len(filtered) > MAX_LENGTH:
filtered = summarize(filtered, task_context)
# 4. 结构化：转化为 LLM 易于理解的格式
structured = structure_output(filtered)
return structuredObservation 的质量直接影响 Agent 的决策质量。一个好的 Observation 应当具备以下特征：准确性（忠实反映环境状态）、相关性（与当前任务相关）、简洁性（不含冗余信息）、及时性（反映最新状态）。
不同类型的工具需要不同的 Observation 处理策略：
| 工具类型 | 原始输出特征 | Observation 处理策略 |
|---|---|---|
| 搜索引擎 | 大量网页摘要 | 提取Top3结果的关键信息 |
| 数据库查询 | 结构化数据行 | 转为自然语言描述或表格 |
| 代码执行 | 控制台输出+错误信息 | 截取关键输出，突出错误 |
| 文件读取 | 长文本内容 | 摘要或分段返回 |
| API调用 | JSON响应 | 提取关键字段，去除元数据 |
Observation 机制的另一个重要方面是错误观察。当工具执行失败时，Agent 需要获得足够的信息来诊断问题并调整策略。一个常见的错误是只返回"执行失败"而不提供任何细节。好的做法是返回错误类型、错误消息以及可能的修复建议。
设计 Observation 机制时还需要考虑多模态信息。如果 Agent 调用了图像分析工具，返回的可能不是文本而是图像描述。如何将多模态的观察结果统一融入 Agent 的推理链，是一个活跃的研究方向。
Observation 机制虽然在概念上不起眼，但它是 Agent 与环境之间的桥梁。在 Agent 系统的调试和优化过程中，改善 Observation 质量往往能带来最显著的性能提升。许多看起来是 LLM 推理能力不足的问题，实际上根源在于 Observation 机制没有给 LLM 提供足够好的信息。
1.8 Agent 架构的演进趋势：从单体到分布式
Agent 架构正在经历从单体到分布式的演进。这一趋势与软件工程领域从单体应用到微服务架构的演进路径高度相似，但增加了智能体协作这一独特维度。
第一代：单体 Agent。一个 LLM 实例承担所有职责：理解任务、规划策略、选择工具、解读结果。AutoGPT 是单体架构的典型代表------一个循环中 LLM 反复生成 Thought 和 Action，直到任务完成。
单体架构的优势在于实现简单、上下文完整。所有信息都在一个 LLM 实例的上下文中，不存在信息传递损耗。但劣势也很明显：单一 LLM 的能力上限决定了整个系统的天花板，而且随着任务复杂度增加，上下文会迅速膨胀。
第二代：角色分工。不同 LLM 实例扮演不同角色------一个负责任务分解，一个负责执行，一个负责审核。这种分工可以通过 prompt 设计来实现（在同一个 LLM 中切换角色），也可以通过多个 LLM 实例来实现。ChatDev 和 MetaGPT 是这种思路的代表，它们模拟了软件开发团队中的不同角色协作。
第三代：多 Agent 系统。多个 Agent 各自拥有独立的记忆、工具集和目标，通过通信协议进行协作。每个 Agent 可以是不同模型驱动的，拥有不同的专业能力。这种架构的灵活性最高，但也面临协调难度大、通信开销高等挑战。
bash
第一代：单体 Agent 第二代：角色分工 第三代：多 Agent 系统
┌─────────┐ ┌───────────┐ ┌───┐ ┌───┐ ┌───┐
│ LLM │ │ Planner │ │ A1│←→│ A2│←→│ A3│
│ Agent │ │ Executor │ └───┘ └───┘ └───┘
└─────────┘ │ Reviewer │ ↕ ↕
└───────────┘ 协作通信层Multi-Agent 系统的核心挑战是协作机制设计。当前主要的协作模式有以下几种。
中心化协作模式中，有一个"管理者" Agent 负责任务分配和结果汇总，其他 Agent 作为执行者。这种模式结构清晰，但管理者可能成为瓶颈。
去中心化协作模式中，Agent 之间直接通信，通过共识机制或市场机制来协调行动。这种模式扩展性好，但协调成本高。
层级化协作模式结合了两者的特点：在同一层级内采用去中心化协作，在层级之间采用中心化管理。这种模式在大型组织中很常见，也被证明适用于 Agent 系统。
以下是一个简单的 Multi-Agent 协作示例：
python
class MultiAgentSystem:
def __init__(self):
self.coordinator = Agent(role="coordinator", llm=gpt4)
self.researcher = Agent(role="researcher", llm=gpt4, tools=[search])
self.writer = Agent(role="writer", llm=claude, tools=[write_file])
def run(self, task):
# 协调者分解任务
subtasks = self.coordinator.plan(task)
results = {}
for subtask in subtasks:
# 根据子任务类型分派给对应 Agent
if subtask.type == "research":
results[subtask.id] = self.researcher.execute(subtask)
elif subtask.type == "writing":
results[subtask.id] = self.writer.execute(subtask)
# 协调者汇总结果
return self.coordinator.synthesize(results)除了协作模式，Agent 架构的演进还体现在以下几个趋势上。
记忆系统外置化。越来越多的 Agent 框架将记忆系统从 LLM 上下文中剥离出来，使用独立的外部存储（向量数据库、知识图谱）。这使得记忆可以跨会话、跨 Agent 共享，也解决了上下文窗口限制的问题。
工具系统动态化。传统 Agent 的工具集是预定义的，而新一代框架支持 Agent 动态发现和加载工具。Agent 可以根据任务需要从工具库中搜索合适的工具，甚至自己编写并执行代码来创建新工具。
执行环境沙箱化。为了安全地执行代码和操作，越来越多的 Agent 系统使用沙箱环境（如 Docker 容器、WebAssembly 运行时）来隔离执行过程。这在保证安全性的同时，允许 Agent 更大胆地尝试和探索。
模型组合多样化。不同任务阶段可以使用不同的 LLM------规划阶段用推理能力强的大模型，执行阶段用速度快的小模型，审核阶段用另一个模型提供独立视角。这种"模型路由"策略在性能和成本之间取得了更好的平衡。
Agent 架构仍在快速演进中。从单体到分布式、从单一模型到多模型协作、从静态工具到动态工具，这些趋势指向一个方向：未来的 Agent 系统将更像一个组织而非单个智能体。理解这些演进趋势，有助于在当前的技术选型中做出更有前瞻性的决策。
本章知识点总结
| 知识点 | 核心内容 | 关键概念 |
|---|---|---|
| AI Agent 定义 | 以 LLM 为核心的自主智能体 | 自主性、目标导向、环境交互、持续运行 |
| 五大核心模块 | 感知、记忆、规划、执行、反思 | Perception、Memory、Planning、Execution、Reflection |
| PRA 循环 | 感知-推理-行动基础范式 | 最简 Agent 闭环 |
| ReAct 模式 | 推理与行动交替进行 | Thought-Action-Observation 三元组 |
| Agent 范式演进 | 从 PRA 到 LATS 的复杂度递增 | Plan-and-Execute、Reflexion、LATS |
| Agent vs Workflow | 自主性与确定性的权衡 | 混合架构为实际主流 |
| 自主性等级 | L0-L5 六级分类体系 | 多数生产系统处于 L2-L3 |
| 认知架构类型 | 反应式、Deliberative、混合 | 混合架构为主流选择 |
| LLM 角色 | 任务理解、规划、工具调用、结果解读 | 能力边界：上下文、幻觉、推理、实时性 |
| Observation 机制 | 闭环反馈的信息处理 | 过滤、压缩、结构化、错误观察 |
| 架构演进趋势 | 单体到分布式 | Multi-Agent、记忆外置、工具动态化、沙箱化 |
| Multi-Agent 协作 | 中心化、去中心化、层级化 | 模型路由与角色分工 |