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 负责干活，总控负责继续判断下一步。它更像一个项目经理模式。
