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。它帮你处理了很多工程问题,比如:工具调用循环最大迭代次数、某些工具执行后直接返回、显式退出协议等。


