ReAct Agent 与 Agent 编排：从单 Agent 闭环到多 Agent 协作
为什么能对话不等于能上线
很多人第一次接触 Agent，会觉得它无非就是 Prompt + Model + Tool。但真到生产环境中，这些是远远不够的。因为一个能上线的 Agent，不只是要会回答，还要会调工具、传状态、控制流程中断恢复、输出可观测的执行过程。
所以这场分享的核心，不是在讲'一个聪明的模型'，而是在讲'一个可治理的 Agent 系统'。
今天我只讲一条主线：单个 Agent 怎么跑起来，多 Agent 又是怎么被编排起来的。 前者的核心是 ReAct 闭环，后者的核心是 Agent orchestration（编排）。而 CloudWeGo Eino ADK，给这两件事提供了工程化落地方式。
什么是编排？从广义上讲，只要你在组织多个执行单元的顺序、依赖、分工、路由，这都叫编排。单个 Agent 内部的多节点流程编排算编排，多个 Agent 之间的协作编排也算编排。而今天的主角是多 Agent 之间的协作。
Agent 的最小运行时骨架
在深入 ReAct 和编排之前，得先理清三个词：Agent、Runner、AgentEvent。
在 Eino ADK 里，我觉得最重要的不是某个具体 Agent，而是它背后的运行时骨架：
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。它帮你处理了很多工程问题，比如：工具调用循环最大迭代次数、某些工具执行后直接返回、显式退出协议等。
