5 个 Agent 设计模式：又稳又省钱

TL;DR — 撑起大部分生产级 Agent 的就五个模式：ReAct（边想边做循环）、Plan-and-Execute（先规划，再用便宜模型执行）、Reflection（提交前自查）、Router（便宜模型分流，贵模型收尾）、Tool-First（把活儿推出模型）。没有万能的一个。按你的延迟预算、容错能力、token 账单来挑。

为什么是模式，不是框架

大多数”怎么搭 Agent”的教程一上来就讲框架。这是本末倒置。框架只是管道。真正决定你的 Agent 能不能上线的是控制流：它怎么决定下一步做什么、什么时候停、为此花多少钱。

Agent 设计模式就是这套控制流的可复用形状。这五个我在 LangGraph、CrewAI 和手写循环里反复重建了太多遍，现在我是先想模式，再碰库。它们是刻意做到框架无关的。模式选对，实现就是个周末的活儿；选错，什么框架都救不了你。

下面是这五个，各自的代价，以及各自在哪儿崩。

1. ReAct：想、做、再想

ReAct 是默认循环。模型先想，挑一个工具，读结果，再想。大部分聊天 Agent 背后是它，也是所有人最先学的那个，最早由 ReAct 论文正式提出。

# ReAct 循环，只留核心
def react_loop(query, tools, max_steps=8):
    history = [{"role": "user", "content": query}]
    for step in range(max_steps):
        response = call_model(history, tools=tools)
        if response.tool_calls:
            for call in response.tool_calls:
                result = tools[call.name](**call.args)
                history.append({"role": "tool", "content": result})
        else:
            return response.content  # 模型判断做完了
    return "到步数上限还没给出最终答案。"

强在哪： 步骤无法预测的开放任务。调研、调试、“帮我找到 X 再总结一下”。模型边学边调整。

崩在哪： 成本和死循环。每一步都是一次完整模型调用，还要带上越滚越大的历史。长上下文跑 8 步 ReAct，成本可能是单次调用的 5 到 10 倍。更糟的是 Agent 会卡在重复同一个失败动作上。永远要给 max_steps 封顶，并且记录步数——一个 ReAct Agent 悄悄从 3 步变成 15 步，是那种你看不见、直到账单来了才发现的预算泄漏。

2. Plan-and-Execute：想一次，跑得便宜

不在每一步都推理，而是先规划好整个流程，再用更便宜的模型（甚至不用模型）执行各步。

[Planner：贵模型] → 产出有序步骤清单
        ↓
[Executor：便宜模型 / 纯代码] → 逐步执行
        ↓
[只在某步失败时才重新规划]

吸引力在经济性。一次贵的规划调用，然后一串便宜的执行。如果你的任务能干净拆解（ETL 任务、多步表单填写、脚本化调研），这相比 ReAct 能砍 60% 到 80% 成本，因为你不用每个动作都让前沿模型重读一遍整段历史。

崩在哪： 计划太脆。Planner 在见到现实之前就把方案定死了。要是第 3 步返回了意料之外的东西，死板的 executor 还是会硬着头皮往下走。解法是加一个重新规划的触发：失败或输出反常时，踢回给 planner。这种混合（规划、执行、偏离时重新规划）才是大多数成熟系统实际跑的东西。Hermes 这类 Agent 的自我改进循环本质上就是带了个会学习的重规划器的 Plan-and-Execute。

3. Reflection：检查自己的活儿

模型先生成答案，再让第二遍对照目标做批判，确认无误才提交。这是性价比最高的可靠性收益。

def reflect(query, draft):
    critique = call_model([
        {"role": "system", "content": "你是严格的审稿人。只列出具体错误。没有就回 'PASS'。"},
        {"role": "user", "content": f"任务：{query}\n\n草稿：\n{draft}"}
    ])
    if "PASS" in critique.content:
        return draft
    return call_model([
        {"role": "user", "content": f"修复这些问题：\n{critique.content}\n\n草稿：\n{draft}"}
    ]).content

强在哪： 代码生成、结构化输出，以及任何有可验证规格的东西。一遍反思能抓出相当比例”看着对、其实错”的输出（Reflexion 论文量化了收益）。想要能把学到的东西跨会话留存的进阶版，看用记忆和反思搭建自我纠错 Agent。

崩在哪： 边际递减和自我认同。两遍反思有用；五遍就是烧 token。而且模型审自己的活儿，会和它共享盲区。真要紧的时候，用另一个模型来反思，或者对着真实校验器（编译器、测试套件、JSON schema 校验）来反思，而不是再叠一层 LLM 的主观意见。

4. Router：让对的模型干对的活

不是每个请求都需要前沿模型。Router 把进来的任务分类，分给能搞定它的最便宜的模型。简单 FAQ → 小而快的模型。硬推理 → 贵的那个。

档位	模型级别	成本（相对）	处理
分流	小/快	1x	分类、简单问答、格式化
标准	中端	5-10x	大部分任务、工具调用、摘要
重型	前沿	20-40x	多步推理、硬代码、规划

Router 自己要便宜。用小模型甚至一个分类器来做决定，别用前沿模型。真正的省钱大头就在这个模式里：如果你 70% 的流量是简单的，你把它路由到便宜 10 倍的模型，账单能掉一半以上，用户还察觉不到。哪些模型该进哪个档，本身是个决策，Claude Sonnet 4 vs GPT-4o 里讲了。

崩在哪： 路由错了。把难题丢给便宜档，你会得到一个自信的错误答案。留个逃生口：便宜模型一旦表示低置信，或输出过不了校验，就升级到下一档，认了这笔成本。

5. Tool-First：把活儿推出模型

最被低估的模式。模型不擅长算术、精确查找和确定性转换，而且用它干这些还贵。Tool-First 的意思是：凡是函数能可靠完成的，就交给函数。模型负责编排，不负责计算。

别让模型给列表排序、给某列求和、解析日期。给它一个工具。每把一个确定性操作挪出模型，就少一次幻觉机会，也省掉一大把 token。这同时是通往可测试性最干净的路，因为工具就是普通代码，你可以写单测。工具接口本身该长什么样，见 MCP vs 函数调用。

崩在哪： 工具泛滥。五十个带冗长 schema 的工具，能在任务还没开始前就撑爆你的上下文预算。把工具集控紧，描述写精炼，把相关动作收在一个带 mode 参数的工具后面，而不是摆十个长得几乎一样的工具。

把模式组合起来

真实系统是分层叠的。一个生产级 Agent 常常长这样：前面一个 Router，中间 ReAct 或 Plan-and-Execute，提交前 Reflection，全程 Tool-First。

flowchart LR
    A[请求] --> R[Router]
    R -->|简单| S[小模型 + 工具]
    R -->|复杂| P[Plan-and-Execute]
    P --> RF[Reflection 检查]
    S --> RF
    RF -->|通过| O[响应]
    RF -->|失败| P

常见错误是第一天就把五个全用上。先从能跑的最简单方案起步（通常是 ReAct 加 Tool-First），量一量哪儿疼，再加模式去治具体的疼。质量出问题就加 Reflection。成本出问题就加 Router。串行模型调用太多导致延迟出问题，就加 Plan-and-Execute。

一张速查表

你的问题	用
不可预测的探索型任务	ReAct
可重复的多步流程	Plan-and-Execute
”看着对、其实错”的输出	Reflection（对着真实校验器）
账单太高、流量大多简单	Router
幻觉的算术 / 查找	Tool-First

FAQ

我该先上哪个模式？ ReAct 加 Tool-First。ReAct 给你一个能跑的循环，Tool-First 让它又准又便宜。其余的等你量出了它们能解决的具体问题再加。

Agent 框架会帮我实现这些吗？ 一部分。LangGraph 给你图，让你把任何一个接起来；CrewAI 偏向基于角色的 Plan-and-Execute。但这些模式是你要做的决策，不是开关一拨就有的功能。各框架开箱给你什么，看最佳开源 Agent 框架。

Reflection 到底多贵？ 大概每审一项多一次模型调用，失败的话再加一次重写。对代码 Agent 通常值；对高并发聊天机器人，选择性反思（只对低置信或高风险输出反思）。

Router 不就是平添复杂度吗？ 只有当你的流量很均匀时才是。如果大多数请求简单、少数难，路由就是你 token 账单上最大的那根杠杆。要是什么都难，跳过它。

怎么不让 ReAct Agent 永远循环？ 封顶步数，检测重复的相同动作，看到重复时在 prompt 里加一句”你试过这个了，换个法子或者停下”。永远记录步数，这样失控的循环会在账单之前先冒出来。