Agent 编程 5 种模式与各自的失败模式

过去 4 个真实项目，每个用了不同的 agent 模式。这篇把它们的适用场景、典型失败模式、 token 成本、调试体验拆开比较——不是教程，是选型指南。

TL;DR

• 不知道选什么：默认 ReAct。能跑通 80% 简单任务。
• 多步骤强依赖前序结果：Plan-Execute。可解释性最好。
• 对正确率要求高：Reflexion。但慢 + 贵。
• 主要工具是写代码：Code-as-Action（smolagents）。调试舒适。
• 能不上 Multi-Agent 就别上。2026 年还没看到划得来的真实生产案例。

1. ReAct — 默认起点

Thought → Action → Observation 循环。最古老最稳的范式。langchain、llamaindex 默认都是它。

适合

• 简单工具调用（搜索、查 DB、调 API）
• 步骤数 ≤ 5
• 对延迟敏感（一次完成 vs Plan-Execute 两阶段）

失败模式

• 循环陷阱——Action 失败后，模型继续重试同样的 Action（提高 temperature 也救不了）
• 过早终止——觉得「我有答案了」其实信息不够
• 工具调用不一致——同样问题第二次跑用了不同的工具组合

缓解

# 加 max_iterations + 失败计数器
agent = ReActAgent(
    tools=tools,
    llm=claude,
    max_iterations=8,
    early_stop_on_repeated_action=True,  # 关键
)

2. Plan-Execute — 多步骤主流

先 plan 出步骤列表，再逐步执行，每步可以回看 plan 调整。 2025 后大部分严肃 agent 系统的默认。

适合

• 步骤之间有依赖（步骤 3 用步骤 2 的输出）
• 需要 human-in-the-loop（用户在 plan 阶段可以改）
• Claude Code 的 Plan mode 就是这个范式

失败模式

• plan 过早细化——一开始就列 12 步，遇到第 3 步报错全乱了。
  缓解：plan 只列 high-level，每步再展开
• 不更新 plan——执行中发现新信息，但 agent 还按老 plan 跑
• plan / execute 模型不一致——plan 用 Sonnet，execute 用 Haiku，理解偏差

3. Reflexion — 高准确度

Action 之后多一步「自我评判」，错了就改。在数学、代码、严谨问答上能涨 10-25%。

适合

• 有客观对错的任务（代码能否跑、数字对不对）
• 对单次正确率要求 > 95%
• 用户能接受 2-3× 延迟

失败模式

• self-critique 是 yes-man——模型批评自己时还是说「我做得对」
• 反复横跳——A 改成 B 又改回 A

4. Code-as-Action — 工程师友好

Agent 不输出 JSON 工具调用，而是写 Python / TypeScript 代码，运行后看结果。 HuggingFace smolagents 主推这个。

适合

• 主要任务就是数据处理 / 文件操作 / API 调用
• 工程师能读懂中间过程（这是最大优势——可调试）
• 不需要严格 sandbox 的环境（或你接受 docker）

典型代码

from smolagents import CodeAgent, HfApiModel

agent = CodeAgent(
    tools=[search_tool, web_fetch_tool],
    model=HfApiModel("Qwen/Qwen2.5-Coder-32B-Instruct"),
)
agent.run("找出 2026 年 AI 工具领域 GitHub star 增量 top 5 的仓库")
# 它会输出可读的 Python 代码而不是工具调用序列

失败模式

• 沙箱逃逸——必须用 docker 或 nsjail，不要相信 exec() 黑名单
• 包依赖混乱——agent 装包时和宿主环境打架

5. Multi-Agent — 谨慎使用

AutoGen、CrewAI 这类把任务拆给多个「专业 agent」（Planner、Coder、Tester...）。 理论很美，工程现实很惨。

例外

• 真有强角色隔离——比如 producer / reviewer 必须独立判断
• 研究而非生产——探索 emergent behavior
• 团队人手 ≥ 3——有人专门维护 agent 编排

6. 选型决策树

你的任务步骤数 ≤ 3？
├─ 是 → ReAct（够用）
└─ 否 ↓

需要 ≥ 95% 单次正确率？
├─ 是 → Reflexion（接受 2× 慢、2× 贵）
└─ 否 ↓

主要操作是写代码 / 数据处理？
├─ 是 → Code-as-Action（smolagents）
└─ 否 ↓

步骤间有强依赖、需要可解释？
├─ 是 → Plan-Execute
└─ 否 → ReAct（默认）

任何时候都问：能不能去掉 agent 直接 prompt？
80% 时候答案是「能」。

7. 真实成本对比

同一任务（"找出 GitHub trending 中 5 个 RAG 工具，写一段 200 字对比"）4 个范式跑各 50 次：

看到 Multi-Agent 的数字了吗？4× token、3× 延迟，准确率反而比 Plan-Execute 还低。 这就是为什么我说「不要在没有强证据时上多 agent」。