Skip to main content

3.2 Agent 设计模式

不同的 Agent 工作流适用于不同场景。了解主流的 Agent 设计模式，才能为你的任务选择最合适的架构。

模式 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 质量权衡​

质量
  ↑
  │     树状搜索
  │       反思循环
  │     编码者-评审者
  │   规划执行
  │ 顺序执行
  └──────────────────→ 成本

最佳实践建议​

  1. 从简开始：先用简单模式，不够再加复杂
  2. 渐进升级：顺序不够用规划，规划不够加反思
  3. 监控成本：注意 token 消耗和时间成本
  4. 可观测性：记录每个步骤的决策，方便调试优化

没有最好的模式，只有最适合场景的模式。模式是前人踩坑总结的经验，不是教条。

Last updated on by Kimi Gao