文章摘要：架构选型不是追逐新名词，而是判断任务中有多少不确定性、状态和风险必须交给模型。本文用最小代码、决策树、调用量级和真实演进路径，选择 ReAct、Workflow、Graph 或 Multi-Agent。

所属系列：ReAct 与 Agent Loop 工程（6/6）

很多 Agent 项目一上来就画出五六个角色：规划 Agent、搜索 Agent、分析 Agent、写作 Agent、审查 Agent。图很好看，系统却更慢、更贵，也更难调试。

选型的第一原则不是哪个词更新，而是：任务里到底有多少不确定性必须交给模型。

三种最小代码形态

先看代码结构，差异会比名词更直观。下面都省略业务实现，只对比控制权放在哪里。

固定 Workflow：步骤和顺序由代码决定。

async def workflow(order_id: str) -> dict:
    order = await read_order(order_id)
    eligibility = check_refund_rules(order)
    if not eligibility["allowed"]:
        return eligibility
    return await create_refund(order_id, order["amount"])

ReAct：模型根据每轮工具反馈决定下一步，一次应用调用内部可能包含多次模型调用。

import os
from langchain.agents import create_agent

MODEL = os.getenv("AGENT_MODEL")
if not MODEL:
    raise RuntimeError("请设置 AGENT_MODEL")
agent = create_agent(model=MODEL, tools=[read_order, search_policy])

async def run_react(request: str) -> dict:
    return await agent.ainvoke(
        {"messages": [{"role": "user", "content": request}]}
    )

Graph：节点、条件边、恢复点和人工中断由显式状态机决定；节点本身可以是普通函数，也可以是 Agent。

from langgraph.graph import END, START, StateGraph

builder = StateGraph(OrderState)
builder.add_node("read", read_node)
builder.add_node("judge", rule_node)
builder.add_node("review", human_review_node)
builder.add_edge(START, "read")
builder.add_edge("read", "judge")
builder.add_conditional_edges("judge", route_risk, {"review": "review", "end": END})
graph = builder.compile(checkpointer=checkpointer)

第三篇的 StateGraph 就是典型案例：Plan-and-Execute 负责生成和补齐计划，Graph 负责保存状态、执行节点和控制路由。

四种模式分别适合什么

• 模式：Workflow；控制权：代码；适合场景：路径固定、规则明确、稳定执行；主要代价：灵活性低，新增分支要改代码
• 模式：ReAct；控制权：模型局部决策；适合场景：少量动态步骤，下一步依赖即时反馈；主要代价：调用次数和延迟有波动
• 模式：Plan/Graph；控制权：显式状态与路由；适合场景：多分支、全局覆盖、恢复、人审；主要代价：状态设计和测试成本更高
• 模式：Multi-Agent；控制权：多个隔离执行体；适合场景：上下文、工具、权限确有隔离收益；主要代价：调用、协调和错误传播最多

Plan-and-Execute 不是第五种底层运行时。它通常落在 Workflow 或 Graph 之上：先得到结构化计划，再由执行图管理依赖、worker 和审查。

一个可执行的决策树

能否用普通函数完成？
  能 -> 普通代码
  不能 -> 执行路径是否固定？
           是 -> Workflow
           否 -> 是否只有少量动态步骤？
                  是 -> ReAct
                  否 -> 是否需要全局覆盖、恢复或人工审批？
                         是 -> Plan-and-Execute / Graph
                         否 -> 先把任务缩成可验收 PoC

只有当拆分能带来上下文、工具或权限隔离时，才继续考虑 Multi-Agent。

“先缩小问题范围”具体做什么

这不是让读者回去把需求想清楚，而是做五个可执行动作：

1. 先定义 verifier： 写出什么结果算通过，最好能自动检查。
2. 拆可独立验收的子任务： 例如先完成“收集 3 家竞品定价”，不要一口气做完整战略报告。
3. 砍非核心交付物： PoC 先不要自动发邮件、做幻灯片和写数据库。
4. 固定输入源与工具： 先限定一个知识库、两个只读工具，减少搜索空间。
5. 只跑一条主路径： 先证明最常见路径可靠，再增加异常分支、恢复和审批。

如果缩小后变成固定步骤，就用 Workflow；如果只剩两三个动态判断，就用 ReAct。不要因为原始需求很大，就默认需要多 Agent。

成本和延迟怎样估

不要引用没有测试环境的“平均 3.2 秒”之类数字。更可靠的是先数模型调用，再乘以你自己环境的单次延迟和 token 分布。

• 模式：Workflow；典型模型调用量级：0，或固定的少量调用；延迟方差：低；调试难度：低
• 模式：ReAct；典型模型调用量级：初始调用 + 每轮工具反馈后的继续调用；延迟方差：中到高；调试难度：中
• 模式：Plan-and-Execute / Graph；典型模型调用量级：planner + 各 worker 循环 + reviewer + 可选 replan；延迟方差：高；调试难度：中到高
• 模式：Multi-Agent；典型模型调用量级：各 Agent 调用之和 + handoff + 汇总；延迟方差：最高；调试难度：高

可以用下面的近似式做容量规划：

ReAct 调用数 ≈ 1 + 工具反馈轮数
Plan-and-Execute ≈ planner + Σ(worker 各自调用) + reviewer + replan
Multi-Agent ≈ Σ(各 Agent 调用) + 交接/汇总调用
总延迟 ≈ 关键路径上的串行调用延迟 + 工具延迟 + 排队/重试

并行只能缩短关键路径，不能自动降低 token 或费用。五个 worker 同时运行，墙钟时间可能下降，总调用成本仍然存在。

架构通常是演进出来的

真实项目很少一次选对，更常见的路径是：

固定 Workflow
  -> 少量步骤需要动态判断，引入 ReAct
  -> 经常漏项，引入 Plan-and-Execute
  -> 需要恢复、审批和复杂分支，落到 Graph
  -> 上下文、工具或权限互相污染，再拆 Multi-Agent

这不是要求每个项目依次升级。只在当前形态暴露了可测量问题时演进：漏项率、失败恢复时间、上下文污染、权限冲突或关键路径延迟。没有问题就不升级。

反向迁移也合理。一个探索期 ReAct 流程稳定以后，可以把高频路径固化成 Workflow，减少成本和不确定性。

为什么 Multi-Agent 不应成为默认答案

每增加一个 Agent，系统都会增加一份上下文、一组模型调用、一条错误传播路径和一套工具权限。如果所谓“研究 Agent”和“写作 Agent”读取同一批资料、使用相同工具、拥有相同权限，只是角色提示词不同，拆分收益通常很小。

真正合理的拆分需要至少一种真实边界：

• 法务资料不能进入营销上下文；
• 研究 Agent 只有读权限，发布 Agent 才有写权限；
• 节点需要不同模型、评测集或验收标准；
• 独立子任务能并行，且结果可以结构化聚合。

Graph 也不等于多个 Agent 连起来。稳定的生产图往往混合普通函数、规则引擎、Agent、人工中断和幂等工具。

用风险决定是否人工介入

不要只写：

if confidence < 0.7:
    ask_human()

模型自报置信度未必经过校准。更可靠的触发条件是金额阈值、敏感数据、生产环境、不可逆操作、证据冲突、业务拒绝和预算即将耗尽。

人工介入是风险控制点，不是模型犹豫时的万能兜底。

什么时候什么都不该用

• 一步查天气、做算术、查单个订单：普通函数或一次 tool calling 足够；
• 流程完全确定：Workflow 比 ReAct 更稳定；
• 没有客观验收条件的开放问题：先定义交付标准，不要先堆循环；
• 团队没有 trace、评测、权限和故障处理能力：先补运行基础，再扩大 Agent 自主性。

最小架构不是保守，而是给未来演进留下可诊断的基线。

六篇文章解决了什么

1. 第 1 篇：ReAct 的核心是根据观察继续行动，不是 Thought: 文本模板。
2. 第 2 篇：Harness 给单次 Agent 运行增加预算、审批、幂等和恢复。
3. 第 3 篇：Plan-and-Execute 用结构化计划、worker 和 reviewer 管长任务。
4. 第 4 篇：Ralph Loop 用外部验证器驱动 Coding Agent 提交小增量。
5. 第 5 篇：MCP 统一外部能力接入，但不替代 Runtime 和业务安全。
6. 第 6 篇：用最少的不确定性选择并演进架构。

小结

确定的事情用代码。
固定路径用 Workflow。
少量动态步骤用 ReAct。
长任务、恢复和复杂状态用 Plan-and-Execute / Graph。
只有存在真实隔离收益时才用 Multi-Agent。

Agent 架构的目标不是让图更壮观，而是用最少的不确定性完成任务，并且能解释失败、恢复执行和验证结果。

参考资料

1. Anthropic, Building effective agents
2. Lilian Weng, LLM Powered Autonomous Agents
3. LangGraph, Workflows and agents
4. LangGraph, Overview
5. LangChain, Multi-agent
6. OpenAI Agents SDK, Agent orchestration