Agent 架构
本章学习目标：理解 AI Agent 的标准架构、各组件的作用以及完整的工作流程
预计阅读时间：40 分钟
一、Agent 架构概述
1.1 什么是 Agent 架构？
Agent 架构是指构成 AI Agent 的核心组件及其组织方式。它定义了 Agent 如何：
- 📥 接收输入（用户任务、环境信息）
- 🧠 处理信息（理解、规划、推理）
- 🔧 使用工具（调用外部服务）
- 📤 输出结果（返回答案、执行操作）
- 🔄 循环迭代（直到任务完成）
1.2 为什么需要理解架构？
理解架构就像了解汽车的引擎构造：
不懂架构：
❌ Agent 是个黑盒
❌ 遇到问题不知道如何调试
❌ 无法优化性能
理解架构：
✅ 知道每个组件的作用
✅ 能定位问题和瓶颈
✅ 可以针对性优化
✅ 能够设计自己的 Agent二、标准 Agent 架构
2.1 核心组件图
一个典型的 AI Agent 包含以下核心组件：
┌──────────────────────────────────────────────────────────┐
│ 用户输入目标 │
│ "帮我研究最新的 AI 趋势" │
└────────────────────┬─────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 1. 感知模块 (Perception) │
│ ───────────────────────────────────────────────────── │
│ 功能：理解用户意图和任务背景 │
│ 技术：LLM 理解、意图识别、上下文分析 │
│ 输出：结构化的目标表示 │
└────────────────────┬─────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 2. 记忆模块 (Memory) │
│ ───────────────────────────────────────────────────── │
│ 功能：存储和检索相关信息 │
│ 组成： │
│ • 短期记忆：当前对话上下文 │
│ • 长期记忆：历史经验、知识库 │
│ • 工作记忆：执行过程中的临时信息 │
└────────────────────┬─────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 3. 规划模块 (Planner) │
│ ───────────────────────────────────────────────────── │
│ 功能：拆解任务、制定执行计划 │
│ 技术：任务分解、思维链、规划算法 │
│ 输出：有序的任务列表 │
│ │
│ 示例： │
│ 目标：研究 AI 趋势 │
│ 计划： │
│ 1. 搜索最新 AI 新闻 │
│ 2. 查找最新论文 │
│ 3. 分析产品发布 │
│ 4. 总结趋势 │
└────────────────────┬─────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 4. 推理模块 (Reasoning) │
│ ───────────────────────────────────────────────────── │
│ 功能：基于当前状态决定下一步行动 │
│ 技术：思维链、ReAct、自我反思 │
│ 考虑因素： │
│ • 当前任务是什么？ │
│ • 已完成什么？ │
│ • 需要什么信息？ │
│ • 哪个工具最合适？ │
│ • 是否需要调整计划？ │
└────────────────────┬─────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 5. 工具模块 (Tools) │
│ ───────────────────────────────────────────────────── │
│ 功能：提供外部能力 │
│ 常用工具： │
│ • 搜索引擎（获取实时信息） │
│ • API 调用（访问服务） │
│ • 代码执行（运行代码） │
│ • 文件操作（读写文件） │
│ • 数据库（存储和查询） │
└────────────────────┬─────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 6. 行动模块 (Action) │
│ ───────────────────────────────────────────────────── │
│ 功能：执行具体操作，获取结果 │
│ 流程： │
│ 1. 调用选定的工具 │
│ 2. 传递必要的参数 │
│ 3. 获取执行结果 │
│ 4. 处理可能的错误 │
└────────────────────┬─────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────────┐
│ 7. 反思模块 (Reflection) │
│ ───────────────────────────────────────────────────── │
│ 功能：评估结果，决定下一步 │
│ 问题： │
│ • 任务完成了吗？ │
│ • 结果是否符合预期？ │
│ • 需要继续、调整还是结束？ │
│ • 从中学到了什么？ │
└────────────────────┬─────────────────────────────────────┘
↓
┌──────────────┐
│ 循环判断 │
└──────┬───────┘
↓
任务完成? ───否──→ 返回推理模块
│ 是
↓
返回最终结果给用户2.2 组件间的协作关系
感知 ←─────→ 记忆
↓ ↑
└────→ 规划 ←┘
↓
推理 ←──────→ 记忆
↓ ↑
工具 ─────→ 行动
↓ ↑
反思 ←────────┘
↓
[判断是否继续]协作流程说明：
- 感知从输入和记忆中获取信息
- 规划基于感知信息制定计划
- 推理结合计划、记忆和工具选择决定行动
- 行动执行具体操作
- 反思评估结果并更新记忆
- 循环直到任务完成
三、完整工作流程示例
3.1 实例：旅行规划 Agent
让我们通过一个具体案例看各组件如何协作。
用户输入：
"帮我规划下周去日本的旅行，预算 2 万，想去东京和京都"步骤 1：感知模块
输入分析：
• 目标：规划旅行
• 时间：下周
• 目的地：日本（东京、京都）
• 预算：2 万
• 隐含需求：需要交通、住宿、景点、餐饮建议
结构化表示：
{
"task_type": "travel_planning",
"destination": ["Tokyo", "Kyoto"],
"duration": "1 week",
"budget": 20000,
"currency": "CNY",
"preferences": []
}步骤 2：记忆模块
检索相关信息：
• 长期记忆：日本旅行的一般信息、最佳实践
• 用户记忆：历史偏好（如果有的话）
• 当前上下文：这次对话的所有信息
从记忆中提取：
✓ 日本首都为东京，古都为京都
✓ 两城市间有新干线连接
✓ 需要提前预订的热门景点步骤 3：规划模块
任务分解：
1. 确定具体行程天数和城市分配
2. 搜索和推荐机票
3. 规划城市间交通
4. 推荐住宿
5. 推荐景点和活动
6. 估算费用
7. 生成完整行程单
优先级排序：
高优先级：机票、住宿（必须提前预订）
中优先级：景点、交通
低优先级：餐饮、购物步骤 4：推理模块
当前状态：
• 已完成：任务分解
• 下一步：确定行程天数
推理：
用户说"下周"，需要：
1. 确认具体日期
2. 假设 7 天行程
3. 城市分配：东京 4 天 + 京都 3 天
决策：
→ 使用搜索工具查询当前日期
→ 使用天气工具查询下周天气
→ 根据天气调整行程安排步骤 5：工具模块 + 行动模块
工具调用序列：
【操作 1】搜索工具
search("东京京都 7天行程 最佳路线")
目的：获取常见的行程安排参考
【操作 2】天气工具
weather_forecast("Tokyo", "Kyoto", dates)
目的：了解下周天气情况
【操作 3】航班搜索工具
flight_search(
origin: "用户城市",
destination: "Tokyo",
date: "出发日期"
)
目的：查找合适航班
【操作 4】住宿工具
hotel_search(
city: "Tokyo",
check_in: "日期",
check_out: "日期",
budget: "预算分配"
)
目的：推荐住宿
【操作 5】景点数据库
attraction_search(
city: ["Tokyo", "Kyoto"],
type: ["文化", "历史", "现代"]
)
目的：获取景点信息
【操作 6】计算工具
calculate_total_cost(
flight: xxx,
hotel: xxx,
transport: xxx,
food: xxx
)
目的：验证是否在预算内步骤 6：反思模块
评估：
✓ 机票和住宿已预订（或提供预订链接）
✓ 行程安排合理
✓ 总费用 18,500 元，在预算内
✓ 包含主要景点
✗ 没有考虑用户的具体兴趣点
决策：
→ 生成初步行程
→ 询问用户是否有特殊兴趣
→ 根据反馈调整
→ 提供可调整的建议3.2 最终输出
markdown
# 日本 7 日行程规划
## 行程概览
- 日期：2025 年 x 月 x 日 - x 月 x 日
- 城市：东京（4 天）+ 京都（3 天）
- 预算：18,500 元（在 20,000 预算内）
## 详细行程
### 东京（Day 1-4）
...
### 京都（Day 5-7）
...
## 费用明细
- 机票：8,000 元
- 住宿：6,000 元
- 交通：2,500 元
- 餐饮：1,500 元
- 门票：500 元
- **总计：18,500 元**
## 建议
1. 提前预订新干线票
2. 购买 JR Pass 如果有更多移动需求
3. 京都有些寺庙需要提前预约
请问您对以下哪些方面特别感兴趣？
- [ ] 历史文化（寺庙、古迹）
- [ ] 现代都市（购物、夜景）
- [ ] 美食（特色料理）
- [ ] 动漫（秋叶原、吉卜力）
- [ ] 自然（公园、富士山）四、架构变体
4.1 简化架构（简单任务）
用户输入 → LLM → 工具调用 → 返回结果适用场景：
- 单步任务（如搜索、计算）
- 不需要复杂规划
- 工具调用次数少
例子：
用户："现在几点了？"
Agent：调用时间工具 → 返回时间4.2 标准架构（一般任务）
就是我们前面介绍的标准架构，适用于大多数场景。
4.3 复杂架构（复杂任务）
┌──────────────────────────────────────────┐
│ 用户目标 │
└────────────┬─────────────────────────────┘
↓
┌────────────────┐
│ 主 Agent │
│ (Orchestrator)│
└────┬───────┬───┘
│ │
┌────┘ └────┐
↓ ↓
┌────────┐ ┌────────┐
│子Agent 1│ │子Agent 2│
│(搜索) │ │(分析) │
└────────┘ └────────┘适用场景：
- 需要多领域专业知识
- 任务可以并行处理
- 需要多个"专家"协作
例子：
- 研究型 Agent：搜索 Agent + 分析 Agent + 写作 Agent
- 开发型 Agent：架构 Agent + 编码 Agent + 测试 Agent
五、关键技术选择
5.1 LLM 选择
| LLM | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| GPT-4 | 推理能力强，工具调用好 | 成本高 | 复杂任务、需要深度推理 |
| Claude | 上下文长，安全性好 | 工具生态较小 | 长文档处理、代码相关 |
| 开源模型 | 成本低，可私有部署 | 能力相对较弱 | 简单任务、数据敏感场景 |
5.2 记忆实现
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 对话上下文 | 简单，内置 | 容量有限 | 短对话 |
| 向量数据库 | 语义搜索，可扩展 | 需要额外服务 | 长期记忆，知识库 |
| 键值存储 | 快速，精确匹配 | 无语义理解 | 结构化数据 |
| 混合方案 | 灵活，全面 | 复杂度高 | 生产环境 |
5.3 工具调用方式
| 方式 | 描述 | 优点 | 缺点 |
|---|---|---|---|
| Function Calling | LLM 原生支持 | 精确，可靠 | 仅部分模型支持 |
| 文本解析 | 从输出解析工具调用 | 兼容性好 | 不稳定，易出错 |
| 路由器 | 预定义规则控制 | 可控性强 | 灵活性差 |
六、架构设计原则
6.1 模块化
✓ 好的设计：
每个组件职责清晰
可以独立测试和优化
容易替换和升级
✗ 不好的设计：
所有逻辑混在一起
难以维护和调试
修改一处影响全局6.2 可观测性
需要能够追踪：
• Agent 做了哪些决策？
• 调用了哪些工具？
• 每步的结果是什么？
• 在哪里出了问题？
实现方式：
- 详细的日志
- 执行轨迹可视化
- 中间结果展示6.3 可控性
用户应该能够：
• 设置限制（预算、时间、资源）
• 中止执行
• 查看和调整计划
• 审批关键操作
实现方式：
- 执行前的计划展示
- 关键操作的确认机制
- 人工接管接口6.4 鲁棒性
Agent 应该能够：
• 处理工具调用失败
• 从错误中恢复
• 降级到备用方案
• 不传播错误
实现方式：
- 错误处理和重试机制
- 多个备选工具
- 异常情况的预案本章小结
核心要点
标准架构包含 7 个核心组件：
- 感知（理解输入）
- 记忆（存储信息）
- 规划（制定计划）
- 推理（决策行动）
- 工具（外部能力）
- 行动（执行操作）
- 反思（评估迭代）
工作流程：
- 不是线性的，而是循环的
- 各组件紧密协作
- 持续迭代直到完成
架构变体：
- 简单任务用简化架构
- 复杂任务用多 Agent 架构
设计原则：
- 模块化、可观测、可控、鲁棒
架构对比记忆口诀
感知理解问什么，
记忆保存学什么，
规划决定做什么，
推理思考怎么做，
工具提供能力库，
行动执行具体活，
反思判断是否完。思考题
基础题：请画出 Agent 的标准架构图，并解释每个组件的作用。
进阶题：如果要构建一个"程序员 Agent"（能写代码、调试、运行测试），它需要哪些工具？为什么？
挑战题：在某些场景下，Agent 可能陷入死循环（反复做同样的事情）。如何从架构层面避免这个问题？
实践探索
观察活动： 访问 Coze 或 Dify，创建一个 Agent 并观察其执行日志。你能识别出架构中的哪些组件？
设计练习： 选择以下一个场景，设计 Agent 架构：
- 客服 Agent
- 数据分析 Agent
- 内容创作 Agent
画出架构图，说明：
- 需要哪些工具？
- 记忆如何存储？
- 如何规划任务？
扩展阅读
推荐文章：
- LangChain: Agents - 实用的 Agent 架构文档
- Building AI Agents - Anthropic 的 Agent 构建指南
架构模式：
- ReAct: Synergizing Reasoning and Acting - 推理与行动结合
- Reflexion: Language Agents with Verbal Reinforcement Learning - 自我反思机制
实践框架：
下一章：我们将学习不同类型的 Agent 及其适用场景。