ReAct Agent 与 Agent 编排：从单 Agent 闭环到多 Agent 协作

一、核心内容概览

本文主要讲解两条主线：单个 Agent 如何运行，以及多 Agent 如何被编排。前者的核心是 ReAct 闭环，后者的核心是 Agent orchestration（编排）。CloudWeGo Eino ADK 为这两件事提供了工程化落地方式。

什么是编排？广义上讲，只要组织多个执行单元的顺序、依赖、分工、路由，都叫编排。单个 Agent 内部的多节点流程编排算编排，多个 Agent 之间的协作编排也算编排。本文重点在于多 Agent 之间的协作。

二、技术详解

1. 为什么要讲 ReAct 和 Agent 编排

'能对话'为什么不等于'能上线'？很多人第一次接触 Agent，觉得它无非就是 Prompt + Model + Tool。但真到生产环境中，这些远远不够。一个能上线的 Agent，不仅要会回答，还要会调工具、传状态、控制流程中断恢复、输出可观测的执行过程。

所以这场分享是在讲'一个可治理的 Agent 系统'。

2. Agent 的最小运行时骨架

在 Eino ADK 里，最重要的不是某个具体 Agent，而是它背后的运行时骨架。包含三个词：Agent、Runner、AgentEvent。

Agent 解决的是：谁来执行任务。
Runner 解决的是：这个任务怎么被统一托管起来。
AgentEvent 解决的是：执行过程中发生了什么。

这意味着，Agent 不再只是一次性返回一个字符串，而是持续地产出事件流：可能是模型输出、可能是 tool call、可能是 transfer，也可能是 interrupt。Eino 的切入点很精准：把 Agent 运行过程也当成一等公民。

3. ReAct 到底是什么

ReAct 的核心不是某种 prompt 技巧，而是一种闭环范式：Reason → Act → Observe。也就是模型先思考下一步怎么做，然后调用工具去拿外部信息，再把工具结果喂回模型继续推理。这个闭环会不断重复，直到模型不再产生 tool call，才结束。

ReAct 最关键的价值在于它把模型的推理锚定在了外部事实之上。以前模型是'自己想'，现在模型是'边查边想'。所以它的可解释性更强，幻觉风险也更低。

关键控制点：

终止条件是什么？答：模型不再产生 tool call。
为什么要有 MaxIterations/MaxStep？答：防止无限循环，控制成本和可用性。

4. Eino 里 ReAct 是怎么落地的

在 Eino 里，ReAct 不是停留在概念层，而是被明确表达成了一个执行闭环。最直观的理解就是 ChatModel 和 ToolsNode 之间形成了一个环。模型先输出 tool call，工具执行后把 observation 写回状态，再回到模型继续推理。这个过程一直循环，直到没有 tool call，或者命中直接结束条件。

在 ADK 里，这个闭环最典型的封装就是 ChatModelAgent。它本质上就是一个工程化的 ReAct Agent。它帮你处理了很多工程问题，比如：工具调用循环最大迭代次数、某些工具执行后直接返回、显式退出协议等。

因此，更愿意把 ChatModelAgent 理解成：不是'一个聊天模型'，而是'一个带 ReAct 运行时的 Agent 封装'。

5. Agent 编排到底在编排什么

如果 ReAct 解决的是'一个 Agent 内部怎么闭环'，那 Agent 编排解决的就是：多个 Agent 之间怎么协作。这两件事不是同一个层面的问题。ReAct 关注的是单 Agent 内部：推理、行动、观察；Orchestration 关注的是多 Agent 外部：分工、路由、状态共享、控制权转移。也就是说：ReAct 是单体闭环，编排是群体协作。

在 Eino ADK 里，最值得讲的三种编排模式分别是：Workflow Agents、Supervisor、Plan-Execute。

6. 三种典型编排模式

第一种：Workflow Agents

Workflow Agents 是确定性编排。路怎么走，是代码提前写死的。比如顺序执行、循环执行、并行执行。它的优点是：可预测、易审计、易测试。它的缺点是：灵活性不如模型自主决策。

第二种：Supervisor

Supervisor 是中心化调度。也就是有一个总控 Agent，负责把任务分配给不同子 Agent。子 Agent 负责干活，总控负责继续判断下一步。它更像一个项目经理模式。

第三种：Plan-Execute

Plan-Execute 是'先规划，再执行，再重规划'。它适合长任务、复杂任务。因为它不是边走边猜，而是先把任务拆成步骤，再一步一步做。所以它比纯 ReAct 更适合长链路研究型任务。

这三种模式，本质上对应三种不同的控制哲学：

Workflow：代码决定流程
Supervisor：中心调度决定流程
Plan-Execute：规划结果决定流程

7. 容易混淆的边界

边界 1：Transfer vs AgentAsTool

Transfer 是控制权交接。我把任务交给你，你接着往下做。AgentAsTool 是工具式调用。我调用你，等你返回结果，然后我继续处理。所以一个是'交棒'，一个是'外包'。

边界 2：BreakLoop vs Exit

BreakLoop 是局部退出。只跳出当前 Loop。Exit 是全局终止。后面的 Agent 都不再执行。

边界 3：ADK Workflow Agents ≠ compose.Workflow

若这个搞混了，将会非常致命。ADK 里的 Workflow Agents，是多 Agent 的编排模式。compose.Workflow 是底层 DAG 编排框架。后者强调的是数据流映射，而且它不支持环。所以 ReAct 这种闭环，不能拿 compose.Workflow 去表达，得用 Graph 或 ChatModelAgent 这种方式去做。

三、总结

ReAct 是单 Agent 闭环。
本篇说的编排是多 Agent 协作。
Workflow / Supervisor / Plan-Execute 是三种不同控制哲学。
ADK Workflow Agents 和 compose.Workflow 不是一回事。

从工程视角看，Agent 不只是'模型会说话'，而是'模型、工具、状态和控制流'被组织成了一个可治理系统。ReAct 是这个系统里单 Agent 的闭环，编排是多个 Agent 的协作方式。