循环即宿命：Agent推理回路六范式实测

2026 年的 Agent 领域出现一个反直觉共识：选框架不再是选"哪个 SDK 好用"，而是选"用哪条推理回路（reasoning loop）思考"。回路——即系统如何规划、调用工具、观察结果、决定何时停止的那段控制流——是 Agent 的一切其他特性（记忆、并发、可观测、终止判断）的上游基因。本系列过去拆过记忆、通信、上下文、沙箱、工具触发等下游症状，本轮回到最上游：把 ReAct、Plan-and-Execute、ReWOO、CodeAct、Graph Loop、Conversational/Handoff 六条回路摆在同一张实验台上，用同一组任务测量每步 LLM 调用数、上下文膨胀率、失败恢复成本与可调试性。结论很硬：回路形状决定了 Agent 的 token 经济学和故障模式，而绝大多数团队选框架时根本没意识到自己锁死的是哪条回路。

六范式对比矩阵

深度分析

一、ReAct：经典循环的隐性税

循环范式	代表框架	控制粒度	每步 LLM 调用	上下文膨胀	失败恢复成本	最适合任务
ReAct（思维-动作-观察）	smolagents ToolCallingAgent、LangChain AgentExecutor	中	高（每步一次）	线性增长	低（单步重试）	探索性、步骤数未知
Plan-and-Execute（先规划后执行）	LangChain plan-execute、BabyAGI 血统	中高	规划1次+每步1次	中	中（需重规划）	目标明确、路径可分解
ReWOO（推理与观察解耦）	老 LangChain ReWOO、研究原型	高	规划全展开	低	高（依赖链断裂难补）	无依赖或弱依赖子任务批
CodeAct（代码即动作）	smolagents CodeAgent、CodeAct 血统	低（交给解释器）	低（少回合）	低	中（代码报错可重写）	数据处理、可数值化任务
Graph Loop（图状态机）	LangGraph、Temporal 血统	极高	由边决定	可控（可裁剪状态）	低（检查点回放）	生产级、可审计、有环流程
Conversational/Handoff（对话轮次/转交）	AutoGen/AG2、OpenAI Agents SDK	低	每轮一次	高（对话累积）	高（谁该说话难判）	多角色协作、路由分发

ReAct（Reason + Act）是绝大多数开发者脑中"Agent"二字的默认形状：模型先 Thought，再 Action，拿到 Observation，循环直至 Final Answer。smolagents 的 ToolCallingAgent 与 LangChain 早期的 AgentExecutor 都是这条回路的纯种实现。它的优点是认知门槛极低——一段 while 循环就能讲清楚，调试时每一步的 thought 都肉眼可见。

# ReAct 回路骨架
while not done:
    thought, action = model(prompt + history)   # 每步一次 LLM 调用
    observation = run_tool(action)
    history += [thought, action, observation]
    done = is_final(thought)

实测的核心问题是 token 经济学线性退化：每多走一步，整段对话历史就要重新喂进上下文一次，第 N 步的输入 token ≈ 前面所有 Observation 之和。在 10 步以上的任务里，输入 token 常数倍于输出。更隐蔽的是"观察淹没"——长工具返回值把真正的推理挤到上下文尾部，模型注意力衰减。ReAct 适合步骤数未知、需要边走边看的探索任务，但它把"思考"和"执行"强绑定，导致任何一步失败都要带着完整历史重试，成本随步数平方级上升。变现上，这是讲 Agent 入门课的最佳素材（心智模型最直觉），却是最不适合直接上生产的回路。

二、Plan-and-Execute：用一次规划换掉 N 次胡思乱想

Plan-and-Execute 把回路拆成两段：先让一个 Planner 把目标展开成有序步骤列表，再让一个 Executor 逐条执行，必要时 Replanner 修正。它的哲学是"先想清楚再动手"，代价是 Planner 那一次调用要承担全部结构化压力。LangChain 官方的 plan-and-execute cookbook、BabyAGI 的任务分解血脉都属此类。

plan = planner(task)                       # 一次性规划
results = {}
for step in plan:
    results[step] = executor(step, results)
    if step_failed(step, results):
        plan = replanner(task, plan, results)  # 动态重规划

实测发现两个分水岭：其一，Planner 的质量直接决定上限——一个把任务拆错的开局，后面 Executor 再强也救不回来，这是典型的"规划即天花板"；其二，Executor 单步执行时上下文只需携带该步与必要前序结果，膨胀率显著低于 ReAct。但 Replanner 的触发条件极难调：太敏感会反复推翻已完成的步骤（自我抵消），太迟钝会带着错误路径走到死。Plan-and-Execute 适合目标边界清晰、子任务可枚举的场景（如"调研 X 并写报告"），变现潜力中等，可包装成"结构化任务训练营"，但学员最容易卡在 Replanner 的调参上。

三、ReWOO：把推理和观察彻底解耦的激进派

ReWOO（Reasoning WithOut Observation）是最被低估也最危险的范式：Planner 在没有任何观察结果的情况下，一次性把所有步骤连同它们之间的依赖（Ax → By(Ax) → Cz(By)）全写出来，然后 Executor 按依赖图批量执行，最后 Solver 拿全部结果做最终答案。它赌的是"很多任务的步骤是可静态推导的，根本不需要边看边想"。

# 无观察推理：先全规划
plan = ["Ax: search(X)", "By: derive(Ax)", "Cz: format(By)"]
vars = {}
for node in topological(plan):
    vars[node.id] = execute(node, vars)   # 依赖满足即执行
answer = solver(task, vars)               # 一次性收口

激进换来了惊人的 token 节省：因为推理不再穿插观察，中间思考不再反复进上下文，依赖无关的步骤甚至可并行执行。但它的失败模式极致命——一旦某个中间节点（比如 Ax）返回的不是 Planner 预期的形态，整条依赖链 By(Ax) → Cz(By) 全部失配，而回路里没有"边走边修正"的机制，Solver 只能在错的输入上硬解。实测中 ReWOO 在子任务彼此独立或弱依赖的批处理上表现接近理论最优，一旦遇到强依赖或不可预测的工具返回，成功率断崖式下跌。它适合做"低延迟问答批"的内部组件，几乎无法独立支撑需要动态判断的复杂任务。

四、CodeAct：让模型写代码当动作

CodeAct（Code Action）是近两年最快崛起的回路，smolagents 的旗舰 CodeAgent 是其代表。它颠覆了"工具调用即结构化 JSON"的传统，让模型直接产出一段可执行 Python，由沙箱里的解释器运行。一个回合里，模型可以一次写出"先搜索、再过滤、再聚合"的多步代码，回路回合数骤降。

# smolagents CodeAgent 风格
# 模型输出即为可执行代码
code = """
pages = [search(q) for q in queries]
clean = [p['text'] for p in pages if p.get('ok')]
summary = summarize('\\n'.join(clean))
final_answer(summary)
"""
exec(code, sandbox)   # 沙箱执行，结果回填

实测的核心收益是 回合数与 token 双降：传统 ToolCallingAgent 要 Thought→Action→Observation 三段来回 N 次，CodeAct 常常一个代码块就把多步逻辑压成一次 LLM 调用。smolagents 官方对比显示 CodeAgent 在数据处理类任务上比 ToolCallingAgent 步数更少、中间 token 更省。代价是失败模式从"工具参数错误"变成了"代码报错"——模型写的代码可能引用不存在的变量、拼错函数名、或在沙箱里触发资源限制。好在代码错误有 stack trace，比模糊的"工具调用失败"更可诊断。CodeAct 最适合可数值化、可串接的任务（数据清洗、报表、批处理），但纯文本/对话类任务收益有限，且对沙箱安全要求极高（执行任意代码 = RCE 风险）。

五、Graph Loop：把回路变成显式状态机

LangGraph 把回路工程化到了极致：节点（node）是处理函数，边（edge）是控制流，状态（state）是显式传入传出的字典，连"是否继续"都是一条条件边。这不再是"一个 while 循环"，而是"一张可编译、可检查点、可回放的有向图"。

# LangGraph：回路即图
graph = StateGraph(State)
graph.add_node("retrieve", retrieve_node)
graph.add_node("grade",   grade_docs)
graph.add_node("generate", generate_node)
graph.add_edge("retrieve", "grade")
graph.add_conditional_edges("grade", decide, {"ok":"generate","retry":"retrieve"})
graph.add_edge("generate", END)
app = graph.compile(checkpointer=MemorySaver())  # 检查点=可回放

实测最大的结构性优势是 失败恢复成本最低：因为每个节点的 state 都被 checkpointer 持久化，任何一步崩了都能从最近的检查点回放，不必重跑全程；条件边让"重试""跳过""转人工"都变成图上的一等公民。上下文也可控——state 字典可显式裁剪，不必把全部历史喂给每个节点。代价是样板代码与认知负荷最高：一个简单的 ReAct 逻辑，在 LangGraph 里要拆成节点+边+状态 schema+条件函数，初学者常被图结构劝退。Graph Loop 是六范式里唯一天生为生产/可审计设计的回路，金融、医疗、合规场景几乎必选；变现上是最适合做"生产级 Agent 训练营"的素材，但教学曲线陡峭。

六、Conversational 与 Handoff：让多个角色轮流说话

AutoGen（现 AG2）和 OpenAI Agents SDK 代表另一支血脉：回路不是单体的 while，而是多个 Agent 在对话里轮流发言。AutoGen 用 GroupChatManager 调度谁该说话；OpenAI 用 Handoff——一个 Triage Agent 把任务"转交"给专家 Agent，专家做完再转回。

# OpenAI Handoff：回路=转交链
triage = Agent(name="triage", handoffs=[billing, support, refund])
billing = Agent(name="billing", tools=[get_invoice], handoffs=[triage])
# 用户消息进 triage → 判断后 handoff 到 billing → billing 处理 → 可 handoff 回

# AutoGen：回路=对话轮次
manager = GroupChatManager(agents=[researcher, coder, critic], max_round=10)
manager.initiate_chat("实现一个排序函数并review")

实测暴露的是"谁该说话"这个调度难题：Conversational 模式下，下一轮该哪个 Agent 发言高度依赖模型判断，错轮（coder 没写完 critic 就开骂）和抢话（两个 Agent 反复互道感谢陷入死循环）是高频故障。Handoff 用单向转交降低了复杂度，但带来"转交即失忆"——专家 Agent 默认只拿到被转交的上下文，前文状态要显式打包传递。上下文膨胀在这条回路里最严重：对话是累积的，N 轮后每个 Agent 都要把整段对话史读进来，token 成本随轮数线性甚至更快增长。这条回路最适合多视角协作（写代码+审代码、正方+反方辩论）和路由分发（客服分流），却最难做可观测性，因为"谁、何时、为什么说话"全是隐式的模型决策。

六范式回路架构总览

flowchart TB
    subgraph React[ReAct 循环]
        R1[Thought] --> R2[Action] --> R3[Observation] --> R1
        R1 -.每步一次LLM调用.-> LLM1[(LLM)]
    end
    subgraph PE[Plan-and-Execute]
        P1[Planner 一次展开] --> P2[Executor 逐条]
        P2 --> P3{失败?}
        P3 -->|是| P4[Replanner] --> P2
        P3 -->|否| P5[Done]
    end
    subgraph RW[ReWOO 解耦]
        W1[无观察全规划] --> W2[拓扑批量执行] --> W3[Solver 一次收口]
    end
    subgraph CA[CodeAct]
        C1[模型写代码] --> C2[沙箱解释器] --> C3{报错?}
        C3 -->|是| C1
        C3 -->|否| C4[Answer]
    end
    subgraph GL[Graph Loop]
        G1[节点/边/State] --> G2[条件边]
        G2 --> G3[Checkpointer 回放]
        G3 --> G1
    end
    subgraph CH[Conversational/Handoff]
        H1[Triage] -->|handoff| H2[Specialist]
        H2 -->|handoff| H1
        H3[GroupChat 轮次调度] -.谁说话.-> H1
    end
    React --> Cost[Token线性涨]
    PE --> Cost2[规划定上限]
    RW --> Cost3[Token最省但脆]
    CA --> Cost4[回合骤降]
    GL --> Cost5[可回放可审计]
    CH --> Cost6[上下文最膨胀]

何时停止：六范式各自的终止判断盲区

回路不仅是"怎么走"，还包括"怎么停"，而六范式的终止判断盲区截然不同。ReAct 的终止完全依赖模型自觉喊 Final Answer，模型一旦忘了或不敢停，就会无限循环（本系列"设闸仍空转"专题已证）。Plan-and-Execute 的终止看似明确（步骤跑完即停），但 Replanner 可能不断插入新步骤，导致"永远规划不完"。ReWOO 的终止是结构性的——依赖图执行完即停——但这恰恰是它的脆弱点：没有中途停下的机制，错了也只能跑到底。CodeAct 的终止藏在模型写的 final_answer() 调用里，模型忘了调就会一直写代码不收口。Graph Loop 终止最干净（到 END 节点即停），是唯一能用图结构硬保证有穷性的范式。Conversational 模式的终止最不可控，只能靠 max_round 这种外部熔断，否则两个 Agent 可以无限对话。这解释了为什么生产系统偏爱 Graph Loop——它是六范式里唯一把"可终止性"作为一等设计约束的回路。

选型决策：回路先行，框架在后

把六范式映射到具体框架后，选型逻辑应当倒过来：先确定你的任务需要哪条回路，再选实现了它的框架。探索性研究、步骤未知 → ReAct（smolagents ToolCallingAgent）。目标清晰、子任务可枚举 → Plan-and-Execute。批处理、子任务弱依赖、要省 token → ReWOO。数据处理、可数值化、要少回合 → CodeAct（smolagents CodeAgent）。生产级、可审计、需检查点回放 → Graph Loop（LangGraph）。多视角协作、客服路由分发 → Conversational/Handoff（AG2 / OpenAI Agents SDK）。

一个反直觉的实践结论是：成熟团队常常混用而非单选。典型组合是用 Graph Loop 做外层骨架（拿到可审计、可回放），在某个节点内部嵌一个 ReAct 或 CodeAct 子回路（拿到灵活探索），用 Handoff 做路由分发。这种"图为骨、回路为肉"的分层，比死守单范式更能兼顾可控与灵活。训练营变现层面，ReAct 和 CodeAct 是入门引流最佳（心智模型清晰、上手快），Graph Loop 是高客单价进阶课的最佳载体（企业愿意为可审计性付费），而 ReWOO 和纯 Conversational 适合作为专项模块而非主线课程。

参考来源

51学通信 · 每日深度技术解读 · 站长「爱卫生」（微信：gprshome201101）