ReAct Agent 与 Agent 编排：从单 Agent 闭环到多 Agent 协作
核心主线
今天只讲一条主线：单个 Agent 怎么跑起来，多 Agent 又是怎么被编排起来的。前者的核心是 ReAct 闭环，后者的核心是 Agent Orchestration（编排）。而 CloudWeGo Eino ADK 给这两件事提供了工程化落地方式。
什么是编排？从广义上讲：只要你在组织多个执行单元的顺序、依赖、分工、路由，这都叫编排。单个 Agent 内部的多节点流程编排算编排，多个 Agent 之间的协作编排也算编排。而今天编排的主角是多 Agent 之间的协作。
为什么需要 ReAct 和 Agent 编排
能对话为什么不等于能上线？很多人第一次接触 Agent，会觉得它无非就是 Prompt + Model + Tool。但真到生产环境中，这些是远远不够的。因为一个能上线的 Agent，不只是要会回答，还要会调工具、传状态、控制流程中断恢复、输出可观测的执行过程。所以这场分享是在讲一个可治理的 Agent 系统。
Agent 最小运行时骨架
在 Eino ADK 里，最重要的不是某个具体 Agent，而是它背后的运行时骨架。包含三个词：Agent、Runner、AgentEvent。
- Agent 解决的是：谁来执行任务。
- Runner 解决的是：这个任务怎么被统一托管起来。
- AgentEvent 解决的是：执行过程中发生了什么。
这意味着，Agent 不再只是一次性返回一个字符串，而是持续地产出事件流：可能是模型输出、可能是 tool call、可能是 transfer，也可能是 interrupt。Eino 的切入点很精准：把 Agent 运行过程也当成一等公民。后面我们讲 ReAct 和编排，其实都建立在这套运行时骨架上。
ReAct 范式详解
ReAct 的核心不是某种 prompt 技巧，而是一种闭环范式：Reason → Act → Observe。也就是：模型先思考下一步怎么做，然后调用工具去拿外部信息，再把工具结果喂回模型继续推理。这个闭环会不断重复，直到模型不再产生 tool call，才结束。
ReAct 最关键的价值在于它把模型的推理锚定在了外部事实之上。以前模型是'自己想'，现在模型是'边查边想'。所以它的可解释性更强，幻觉风险也更低。
面试中常问的两个控制点：
- 终止条件是什么？答：模型不再产生 tool call。
- 为什么要有 MaxIterations/MaxStep？答：防止无限循环，控制成本和可用性。
Eino 中的 ReAct 落地
在 Eino 里，ReAct 不是停留在概念层，而是被明确表达成了一个执行闭环。最直观的理解就是 ChatModel 和 ToolsNode 之间形成了一个环。模型先输出 tool call，工具执行后把 observation 写回状态，再回到模型继续推理。这个过程一直循环，直到没有 tool call，或者命中直接结束条件。
在 ADK 里，这个闭环最典型的封装就是 ChatModelAgent。它本质上就是一个工程化的 ReAct Agent。它帮你处理了很多工程问题，比如：工具调用循环最大迭代次数、某些工具执行后直接返回、显式退出协议等。
因此，更愿意把 ChatModelAgent 理解成：不是'一个聊天模型'，而是'一个带 ReAct 运行时的 Agent 封装'。
Agent 编排的核心逻辑
如果 ReAct 解决的是'一个 Agent 内部怎么闭环'，那 Agent 编排解决的就是：多个 Agent 之间怎么协作。这两件事不是同一个层面的问题。ReAct 关注的是单 Agent 内部：推理、行动、观察；Orchestration 关注的是多 Agent 外部：分工、路由、状态共享、控制权转移。也就是说：ReAct 是单体闭环，编排是群体协作。
在 Eino ADK 里，最值得讲的三种编排模式分别是：Workflow Agents、Supervisor、Plan-Execute。
三种典型编排模式
Workflow Agents
Workflow Agents 是确定性编排。路怎么走，是代码提前写死的。比如顺序执行、循环执行、并行执行。它的优点是：可预测、易审计、易测试。它的缺点是：灵活性不如模型自主决策。
