ReAct、Plan-and-Execute与工作流Agent怎么选？三种架构的成本、稳定性和适用场景

文章摘要

ReAct、Plan-and-Execute和工作流Agent经常被混为一谈，但三者在决策方式、模型调用次数、可预测性、恢复能力和开发成本上差异很大。本文以企业报表、客服查询和高风险审批为例，比较三种架构，并给出从任务类型、流程稳定度、工具风险和预算约束出发的选型方法。

一、三种架构解决的是不同问题

ReAct

每一步都由模型根据当前状态决定下一步动作：

思考
→ 行动
→ 观察
→ 再思考

Plan-and-Execute

先生成完整或阶段性计划，再由执行器逐步完成：

生成计划
→ 执行步骤
→ 检查结果
→ 必要时重规划

工作流Agent

开发者预先定义节点、分支和状态转移，模型只在局部节点中决策：

固定流程骨架
＋局部模型能力

三者不存在绝对优劣，核心区别是：

把多少决策权交给模型，把多少控制权留给确定性程序。

二、ReAct：灵活，但容易产生长链路

典型循环：

while not finished:
    action = model.decide(state)

    if action.type == "tool":
        observation = execute(action)
        state.add(observation)
    else:
        return action.answer

优点

• 不需要提前知道完整任务结构；
• 能根据工具结果动态调整；
• 适合探索、搜索和开放式问题；
• 实现简单，原型速度快。

缺点

• 每一步都可能调用模型；
• 容易重复工具调用；
• 路径不可预测；
• 难以估算总成本；
• 长任务容易上下文膨胀；
• 出错后恢复位置不清晰。

适合场景

• 多源搜索；
• 开放式研究；
• 工具数量少；
• 风险较低；
• 任务步骤无法预先确定。

三、Plan-and-Execute：先规划，再执行

结构通常包括：

Planner
Executor
Reviewer
Replanner

Planner输出：

{
  "objective": "生成本月渠道经营分析报告",
  "steps": [
    {
      "id": "S1",
      "task": "查询销售数据"
    },
    {
      "id": "S2",
      "task": "查询库存与退货数据",
      "dependsOn": ["S1"]
    },
    {
      "id": "S3",
      "task": "计算异常指标",
      "dependsOn": ["S1", "S2"]
    },
    {
      "id": "S4",
      "task": "生成报告",
      "dependsOn": ["S3"]
    }
  ]
}

优点

• 用户和系统可以提前看到计划；
• 更容易估算工具数和成本；
• 可以并行执行无依赖步骤；
• 失败后可以从具体步骤恢复；
• 适合加入人工审批；
• 轨迹更容易审计。

缺点

• 初始计划可能基于错误假设；
• 环境变化后需要重规划；
• 计划过细会增加模型开销；
• 计划过粗又失去控制价值；
• Planner输出需要严格校验。

适合场景

• 多步骤业务任务；
• 报告生成；
• 跨系统数据汇总；
• 可以定义完成标准；
• 需要中断恢复和执行审计。

四、工作流Agent：最稳定，但灵活度最低

工作流把主流程写成图或状态机：

接收申请
→ 校验身份
→ 查询额度
→ 风险评估
→ 人工审批
→ 执行业务
→ 发送通知

模型可以用于：

• 提取表单字段；
• 分类风险；
• 生成审批摘要；
• 判断需要补充哪些材料；
• 生成最终说明。

但模型不能随意跳过关键节点。

优点

• 路径可预测；
• 容易测试；
• 权限边界清晰；
• 成本易估算；
• 适合事务和审批；
• 方便合规审计。

缺点

• 新场景需要修改流程；
• 开放式任务适应性弱；
• 分支过多时维护复杂；
• 需要开发者提前理解业务。

适合场景

• 付款；
• 删除数据；
• 审批；
• 工单流转；
• 订单处理；
• 有明确SOP的企业流程。

五、核心维度对比

六、不要按“哪个更高级”来选

场景一：查询订单状态

步骤很稳定：

识别订单号
→ 查询订单
→ 返回状态

最佳选择通常是确定性工作流，没有必要让ReAct自由探索。

场景二：调查某个技术趋势

需要搜索、比较、追问和调整方向，ReAct更合适。

场景三：生成企业经营分析报告

任务包含多个数据源和明确交付物：

Plan-and-Execute
＋局部工作流

更合适。

场景四：付款审批

必须经过身份、额度、风险和人工确认：

工作流Agent

不能交给自由Agent决定流程。

七、企业项目常用的是混合架构

生产系统往往不是三选一，而是组合：

外层确定性工作流
→ 中间Plan-and-Execute
→ 某个研究节点使用ReAct

例如售前方案生成：

1. 固定流程：读取客户资料
2. Planner：拆解行业、需求、方案、报价章节
3. ReAct：在知识库和外部资料中研究
4. Reviewer：检查事实和结构
5. 固定流程：人工确认后导出

这种方式把模型灵活性限制在安全边界内。

八、选型决策树

第一步：任务是否有固定SOP

有：

优先工作流Agent

没有则进入第二步。

第二步：任务是否需要多个可描述步骤

需要：

优先Plan-and-Execute

不需要或难以提前规划：

优先ReAct

第三步：工具是否有高风险副作用

有：

必须增加确定性审批工作流

第四步：是否需要断点恢复

需要：

Plan-and-Execute或工作流

九、成本如何估算

ReAct

总成本 ≈ 步数 × 单步输入输出Token

上下文通常随步骤增加，后期调用更贵。

Plan-and-Execute

规划成本
＋执行步骤成本
＋审核或重规划成本

虽然组件更多，但可以使用小模型执行简单步骤。

工作流Agent

模型只出现在局部节点，总成本最容易预算。

企业可以采用模型分级：

规划 → 强模型
简单执行 → 低成本模型
审核 → 强模型或规则

十、稳定性设计建议

无论选择哪种架构，都应具备：

• 最大执行步数；
• 工具调用预算；
• Token预算；
• 超时；
• 幂等键；
• 重试策略；
• 人工审批；
• 状态持久化；
• Trace；
• 最终完成条件。

架构选型不能替代基础工程治理。

十一、我的建议

小型低风险工具助手

ReAct

复杂多步骤业务任务

Plan-and-Execute

高风险、强合规流程

工作流Agent

大型企业Agent平台

工作流骨架
＋计划执行
＋局部ReAct

真正成熟的Agent架构，不是最大限度增加模型自主性，而是：

在任务需要的地方开放决策，在风险需要的地方收回控制权。