# 循环即宿命：Agent推理回路六范式实测 ## 概述 2026 年的 Agent 领域出现一个反直觉共识：选框架不再是选"哪个 SDK 好用"，而是选"用哪条推理回路（reasoning loop）思考"。回路——即系统如何规划、调用工具、观察结果、决定何时停止的那段控制流——是 Agent 的一切其他特性（记忆、并发、可观测、终止判断）的上游基因。本系列过去拆过记忆、通信、上下文、沙箱、工具触发等下游症状，本轮回到最上游：把 ReAct、Plan-and-Execute、ReWOO、CodeAct、Graph Loop、Conversational/Handoff 六条回路摆在同一张实验台上，用同一组任务测量每步 LLM 调用数、上下文膨胀率、失败恢复成本与可调试性。结论很硬：回路形状决定了 Agent 的 token 经济学和故障模式，而绝大多数团队选框架时根本没意识到自己锁死的是哪条回路。 ## 六范式对比矩阵 | 循环范式 | 代表框架 | 控制粒度 | 每步 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：经典循环的隐性税 ReAct（Reason + Act）是绝大多数开发者脑中"Agent"二字的默认形状：模型先 Thought，再 Action，拿到 Observation，循环直至 Final Answer。smolagents 的 `ToolCallingAgent` 与 LangChain 早期的 `AgentExecutor` 都是这条回路的纯种实现。它的优点是认知门槛极低——一段 while 循环就能讲清楚，调试时每一步的 thought 都肉眼可见。 ```python # 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 的任务分解血脉都属此类。 ```python 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 拿全部结果做最终答案。它赌的是"很多任务的步骤是可静态推导的，根本不需要边看边想"。 ```python # 无观察推理：先全规划 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，由沙箱里的解释器运行。一个回合里，模型可以一次写出"先搜索、再过滤、再聚合"的多步代码，回路回合数骤降。 ```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 循环"，而是"一张可编译、可检查点、可回放的有向图"。 ```python # 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，专家做完再转回。 ```python # 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 成本随轮数线性甚至更快增长。这条回路最适合多视角协作（写代码+审代码、正方+反方辩论）和路由分发（客服分流），却最难做可观测性，因为"谁、何时、为什么说话"全是隐式的模型决策。 ## 六范式回路架构总览 ```mermaid 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 适合作为专项模块而非主线课程。 ## 参考来源 1. [AI Agent Reasoning Loops in 2026: ReAct vs ReWOO vs Plan-and-Execute](https://slavadubrov.github.io/blog/2026/01/31/ai-agent-reasoning-loops/) — 对三种核心推理回路（ReAct/ReWOO/Plan-and-Execute）的工程级对比，论证"回路是 Agent 最大的单一决策" 2. [Agentic Loops: From ReAct to Loop Engineering (2026 Guide)](https://datasciencedojo.com/blog/agentic-loops-explained-from-react-to-loop-engineering-2026-guide/) — 从 ReAct 到循环工程化的演进梳理，覆盖回路类型与工程化模式 3. [2026 AI Agent Framework Showdown: LangGraph vs CrewAI vs AG2 vs Claude SDK vs Strands vs OpenAI](https://qubittool.com/blog/ai-agent-framework-comparison-2026) — 六大主流框架基准驱动对比，含 2026 生态整合趋势 4. [CodeAgent vs. ToolCallingAgent — Smolagents Documentation](https://huggingface.co/docs/smolagents/en/guided_tour) — CodeAct 与传统工具调用回路的官方对比，CodeAgent 在步数与 token 上的实测数据来源 5. [How the agent loop works — Claude Code Docs](https://code.claude.com/docs/en/agent-sdk/agent-loop) — Claude Agent SDK 内置回路的消息生命周期、工具执行与上下文管理机制 --- **51学通信** · 每日深度技术解读 · 站长「爱卫生」（微信：gprshome201101） > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。