Agent 设计模式
不同的 Agent 工作流适用于不同场景。了解主流的 Agent 设计模式，才能为你的任务选择最合适的架构。
演进视角：从 ReAct 出发的两条线
ReAct Agent 是 Agent Loop 的起点——思考-行动-观察的循环定义了"什么算 Agent"。但 ReAct 太原始，直接用在生产中会面临两个核心痛点：
- 没有规划 — 面对复杂任务，模型会陷入"走一步看一步"的混乱
- 没有反思 — 模型做错了不知道，做得不够好也不知道
从 ReAct 出发，工程界自然演化出了两条主线：
ReAct（起点）
/ \
/ \
规划线（Plan） 反思线（Reflect）
拆解任务、 自我评估、
提前规划路径 迭代改进
↓ ↓
Plan-and-Execute Reflexion / Self-Critique
PlanReAct Encoder-Critic
LLM Compiler ...
侧重规划的 Agent"和"侧重反思的 Agent"两条线，正对应本章后续要讲的两类核心模式——规划线对应"模式 2：规划执行"，反思线对应"模式 3：反思循环"和"模式 6：编码者-评审者"。理解这条演进路径，才能知道每个模式在解决什么具体问题。
两条线不是互斥的——实际生产中最强的方案往往是"规划 + 反思"的组合（如先 Plan-and-Execute 出 v1，再用 Self-Critique 迭代到 v2/v3），后续的"模式 4：树状搜索"和"模式 5：专家路由"则是在这两条线之上做的更复杂编排。
模式 1：顺序执行（Sequential）
适用场景
简单、确定性的任务，步骤可以预先确定。
工作流程
步骤 1 → 步骤 2 → 步骤 3 → 完成
特点
✅ 简单可靠，容易调试 ✅ 可预测的执行路径 ❌ 灵活性差，遇到意外难以调整
典型示例：代码评审流程
1. 读取变更文件列表
2. 逐个分析每个文件
3. 收集所有问题
4. 生成评审报告
模式 2：规划执行（Plan-and-Execute）
适用场景
复杂但可以拆解的任务，需要先做规划再执行。
工作流程
理解目标
↓
制定详细计划
↓
按计划逐步执行
↓
检查进度
↓ 必要时调整计划
完成
特点
✅ 适合复杂任务 ✅ 执行有章法，不容易跑偏 ✅ 人可以审查和干预计划
典型示例：写一篇技术文章
【规划阶段】
1. 确定文章大纲和结构
2. 列出需要的参 考资料
3. 规划每个部分的写作顺序
【执行阶段】
1. 收集和整理参考资料
2. 按大纲逐节写作
3. 整合和润色全文
实现要点
def plan_and_execute(goal):
# 1. 规划
plan = create_plan(goal)
# 2. 执行
for step in plan.steps:
result = execute_step(step)
# 3. 检查是否需要调整计划
if need_replan(result):
plan = update_plan(plan, result)
return final_result
模式 3：反思循环（Reflexion）
适用场景
需要高质量输出的场景，对结果要求高，愿意花更多时间换质量。
工作流程
第一次尝试 → 生成结果
↓
自我批判：这个结果有什么问题？
↓
根据批判改进 → 生成 v2
↓
再次批判...
↓ （多轮迭代）
最终满意的结果
特点
✅ 输出质量显著提升 ✅ 自我修正能力强 ❌ 耗时更长，token 消耗更大
典型示例：生成代码
第一轮：写一个 Python 函数实现快速排序
→ 生成 v1 代码
反思：
- 边界条件处理了吗？
- 有没有性能问题？
- 代码可读性怎么样？
- 有 bug 吗？
根据反思修正 → v2 代码
再次反思...
直到满意为止。
模式 4：树状搜索（Tree of Thoughts）
适用场景
探索性强、有多种可能路径的问题，需要尝试不同方向。
工作流程
问题
/ | \
方案A 方案B 方案C
/ \
路径A1 路径A2
↓
继续探索
特点
✅ 可以探索多种可能性 ✅ 不容易错过最优解 ❌ 计算成本非常高 ❌ 实现复杂度高
典型示例：解数学题 / 编程竞赛
问题：有多少种方法可以用 1、5、10 凑出 27 元？
分支 1：先拿 10 元的
→ 剩下 17 元，继续递归
分支 2：先拿 5 元的
→ 剩下 22 元，继续递归
分支 3：先拿 1 元的
→ 剩下 26 元，继续递归
... 评估各分支，剪枝无望的路径 ...
模式 5：专家路由（Expert Routing）
适用场景
领域很广，没有单一专家能处理所有情况，需要多个专业 Agent 协作。
工作流程
用户问题
↓
路由 Agent：这是什么类型的问题？
├─ 代码问题 → 交给代码专家 Agent
├─ 数据分析 → 交给数据专家 Agent
├─ 写作任务 → 交给写作专家 Agent
└─ 复杂问题 → 交给协调 Agent 拆分
特点
✅ 每个专家在自己领域更专业 ✅ 可以独立优化每个专家的 prompt 和工具 ✅ 易于扩展新的领域
典型实现：多角色客服系统
路由 Agent：
- 技术问题 → 技术支持
- 账单问题 → 财务客服
- 投诉建议 → 客户成功
- 不知道 → 人工转接
模式 6：编码者-评审者（Encoder-Critic）
适用场景
需要严格质量控制的场景，有明确的验收标准。
工作流程
编码者（Encoder） → 生成解决方案
↓
评审者（Critic） → 审查方案，指出问题
↓
编码者根据意见修改
↓ （多轮迭代）
评审者验收通过
特点
✅ 双重检查，质量更高 ✅ 评审者可以有更严格的标准 ✅ 两个角色可以用不同的模型配置
典型示例：生产环境代码编写
编码者：
- 实现功能代码
- 编写单元测试
评审者：
- 检查代码规范
- 检查安全问题
- 检查性能问题
- 检查测试覆盖率
如何选择合适的模式？
决策矩阵
| 场景复杂度 | 质量要求 | 推荐模式 | 典型步数 |
|---|---|---|---|
| 简单 | 一般 | 顺序执行 | 1-3 步 |
| 中等 | 一般 | 规划执行 | 3-10 步 |
| 中等 | 高 | 反思循环 | 3-5 轮 |
| 复杂 | 一般 | 规划执行 + 专家路由 | 10-30 步 |
| 复杂 | 高 | 编码者-评审者 + 反思 | 10-50 步 |
| 探索性 | 高 | 树状搜索 | 50-200+ 步 |
成本 vs 质量权衡
质量
↑
│ 树状搜索
│ 反思循环
│ 编码者-评审者
│ 规划执行
│ 顺序执行
└──────────────────→ 成本
最佳实践建议
- 从简开始：先用简单模式，不够再加复杂
- 渐进升级：顺序不够用规划，规划不够加反思
- 监控成本：注意 token 消耗和时间成本
- 可观测性：记录每个步骤的决策，方便调试优化
没有最好的模式，只有最适合场景的模式。模式是前人踩坑总结的经验，不是教条。