一、为什么要学 Agent 设计范式？

很多人一讲 Agent，就只会说“LLM 自己思考、自己调用工具”。这句话没错，但太粗。真正落到工程里，问题会立刻变成：任务流程要不要固定？下一步由代码决定，还是由模型决定？失败后要不要反思？复杂任务要不要先规划？线上成本和延迟怎么控制？

Agent 设计范式解决的不是“概念好不好听”，而是“一个智能系统应该怎么组织执行过程”。同一个业务需求，用不同范式实现，系统的稳定性、成本、可解释性完全不同。

二、Workflow 和 Agent 的核心区别

先把底层问题说清楚：Workflow 和 Agent 最大的区别，不在于有没有调用大模型，也不在于有没有工具，而在于“下一步由谁决定”。

Workflow 是开发者提前把流程写好。比如：先检索，再重排，再生成，再质检。每一步如何走、失败后去哪条分支，都是代码里定死的。LLM 只是流程中的一个能力节点。

Agent 则把下一步决策权交给 LLM。你给它目标、工具和边界，它自己判断该调哪个工具、传什么参数、是否继续、什么时候给最终答案。

编辑

搜图

代码结构上也能一眼看出来。Workflow 的控制流写在代码里；Agent 的控制流出现在模型每一轮的决策里。

所以工程选型的第一原则是：能固定的流程，就不要让模型自由发挥；只有当某个节点真的需要灵活判断，才把它升级成 Agent。

三、ReAct：最经典的 Agent 小循环

ReAct 是 Reasoning + Acting 的缩写。它的核心不是“让模型想很多”，而是把每一轮执行拆成三个清晰阶段：Thought、Action、Observation。

Thought：模型先分析当前状态，判断下一步该做什么。

Action：模型选择一个工具，并生成结构化参数。

Observation：工具返回结果，模型读取反馈，再进入下一轮。

编辑

搜图

ReAct 适合工具调用链路不长、每一步相对独立的任务。比如查资料、查订单、调计算器、调用一个业务 API。它的好处是执行轨迹非常清楚：模型为什么调这个工具、调完看到了什么、为什么继续或停止，都能记录下来。

1

# ReAct 的典型轨迹，不是普通聊天，而是可观察的执行过程。

2

Thought: 用户想比较两个产品，我需要先查询产品 A 的价格。

3

Action: web_search({"query": "产品A 最新价格"})

4

Observation: 搜索结果显示产品 A 当前价格为 299 元。

5

Thought: 还缺产品 B 的价格，继续查询。

6

Action: web_search({"query": "产品B 最新价格"})

7

Observation: 搜索结果显示产品 B 当前价格为 259 元。

8

Thought: 信息已经足够，可以给出对比结论。

9

Final Answer: 产品 B 更便宜，但还需要结合功能和售后判断。

ReAct 的短板也很明显：它是“走一步看一步”。如果任务需要全局规划，比如写一份完整行业研究报告、迁移一个大型项目、做多轮数据分析，单纯 ReAct 容易在中途偏离目标，或者反复调用工具。

四、Plan-and-Execute：复杂任务先规划再执行

Plan-and-Execute 解决的是 ReAct 的全局视野问题。它会先让 Planner 生成一个完整计划，再让 Executor 按步骤执行。成熟的实现不是死板照计划跑，而是每一步执行完都把结果反馈给 Planner，必要时动态重规划。

这个范式适合步骤多、依赖强、需要全局目标约束的任务。比如“调研某个行业趋势并输出报告”，一上来就让模型自由搜索，很容易乱；先生成计划，再按计划执行，会稳定很多。

Plan-and-Execute 的代价是多了一层规划器。每次规划、重规划都要调用 LLM，延迟和费用都会上升。所以它不适合特别简单的任务，简单问题用它反而是过度设计。

五、Reflection / Reflexion：让 Agent 自己检查自己

Reflection 是在执行流程中加入“自我评估”环节。模型生成结果后，不是立刻返回给用户，而是再经过一次评估：是否满足要求？有没有事实错误？代码能不能通过测试？格式是否正确？如果不合格，就带着反馈再生成一次。

Reflexion 是 Reflection 的增强版。它不是简单重试，而是把失败原因写成一段“反思总结”，作为下一次尝试的上下文。你可以把它理解为模型给自己写“错题本”。

编辑

搜图

Reflection 很适合质量要求高、允许多花一点时间的场景，比如代码生成、方案评审、长文生成、SQL 生成。它的代价也很直接：多一次评估、多一次反思、多一次重试，token、延迟和费用都会增加。

六、三种经典范式怎么选？

ReAct、Plan-and-Execute、Reflection 不是互斥关系。真正的项目里，经常是组合使用：外层用 Plan-and-Execute 控住全局计划，单个步骤内部用 ReAct 调工具，关键输出再用 Reflection 做质量检查。

可以用一个非常简单的判断：如果任务只有一两步，ReAct 足够；如果任务有很多步骤且前后依赖强，用 Plan-and-Execute；如果结果质量要求高，在前面任何范式上叠加 Reflection。

七、生产环境更常见的是 Agentic Workflow

纯 Agent 很酷，但在生产里不一定好用。它的问题是路径不稳定、难复现、成本难预估。实际业务系统更常见的是 Agentic Workflow：主流程依然是 Workflow，关键节点才嵌入 Agent。

比如客服系统的主链路是固定的：意图识别 -> 知识检索 -> 回答生成 -> 质检输出。但在“知识检索”这个节点里，可以让 Agent 动态决定要不要多轮检索、要不要查订单系统、要不要调用工单工具。

这也是比较成熟的工程答案：不要一上来就做纯 Agent。先用 Workflow 保证大方向稳定，再把不确定性高的局部节点交给 Agent。

八、上线前必须考虑的工程护栏

Agent 的风险不是“不够聪明”，而是“太自由”。它可能重复调用工具，可能误调敏感接口，可能为了完成目标绕过业务规则。所以每一个 Agent 都要加边界。

至少要有 6 类控制：最大步数、工具白名单、参数校验、预算控制、人工兜底、全链路追踪。没有这些控制，Agent 更像一个 demo，而不是一个能上线的系统。

九、总结

Agent 和 Workflow 的区别，是“下一步由谁决定”。Workflow 的下一步由代码决定，稳定、可控、好测试；Agent 的下一步由 LLM 决定，灵活但不稳定。

常见 Agent 设计范式包括 ReAct、Plan-and-Execute、Reflection / Reflexion。ReAct 适合短链路工具调用；Plan-and-Execute 适合复杂任务的全局规划；Reflection 适合对质量要求高、允许多轮评估和重试的场景。

工程实践里，纯 Agent 不一定是首选。更稳的做法是 Agentic Workflow：整体用 Workflow 控主流程，在需要灵活判断的节点嵌入 Agent。这样既保住了系统可控性，又能获得局部智能。