ReAct Agent 与 Agent 编排：从单 Agent 闭环到多 Agent 协作
本篇文章，大概会花费你10分钟时间，带你对Agent进行更加深入的了解。
目录：
-
- [ReAct Agent 与 Agent 编排：从单 Agent 闭环到多 Agent 协作](#ReAct Agent 与 Agent 编排：从单 Agent 闭环到多 Agent 协作)
- [一、这 10 分钟到底会讲什么](#一、这 10 分钟到底会讲什么)
- 二、我将会分8节来讲
-
- [第 1 节：为什么要讲 ReAct 和 Agent 编排](#第 1 节：为什么要讲 ReAct 和 Agent 编排)
-
- [时间：1 分钟](#时间：1 分钟)
- [第 2 节：先讲清 Agent 的最小运行时骨架](#第 2 节：先讲清 Agent 的最小运行时骨架)
-
- [时间：1 分钟](#时间：1 分钟)
- [第 3 节：ReAct 到底是什么](#第 3 节：ReAct 到底是什么)
-
- [时间：1.5 分钟](#时间：1.5 分钟)
- [第 4 节：Eino 里 ReAct 是怎么落地的](#第 4 节：Eino 里 ReAct 是怎么落地的)
-
- [时间：1.5 分钟](#时间：1.5 分钟)
- [第 5 节：Agent 编排到底在编排什么](#第 5 节：Agent 编排到底在编排什么)
-
- [时间：1 分钟](#时间：1 分钟)
- [第 6 节：三种典型编排模式，一次讲清](#第 6 节：三种典型编排模式，一次讲清)
-
- [时间：2 分钟](#时间：2 分钟)
- [第一种：Workflow Agents](#第一种：Workflow Agents)
- 第二种：Supervisor
- 第三种：Plan-Execute
- [第 7 节：几个最容易讲混的边界](#第 7 节：几个最容易讲混的边界)
-
- [时间：2.5 分钟](#时间：2.5 分钟)
- [边界 1：Transfer vs AgentAsTool](#边界 1：Transfer vs AgentAsTool)
- [边界 2：BreakLoop vs Exit](#边界 2：BreakLoop vs Exit)
- [边界 3：ADK Workflow Agents ≠ compose.Workflow](#边界 3：ADK Workflow Agents ≠ compose.Workflow)
- [第 8 节：收尾](#第 8 节：收尾)
-
- [时间：0.5 分钟](#时间：0.5 分钟)
- 三、总结
一、这 10 分钟到底会讲什么
开场：
今天我只讲一条主线：
单个 Agent 怎么跑起来，多 Agent 又是怎么被编排起来的。前者的核心是 ReAct 闭环 ，后者的核心是 Agent orchestration (编排)。
而 CloudWeGo Eino ADK，给这两件事提供了工程化落地方式。
什么是编排？
从广义上来讲：只要你在组织多个执行单元的顺序、依赖、分工、路由，这都叫编排。
- 单个 Agent 内部的多节点流程编排，算编排
- 多个 Agent 之间的协作编排，也算编排
而今天编排的主角是，多Agent之间的协作。
二、我将会分8节来讲
第 1 节：为什么要讲 ReAct 和 Agent 编排
时间：1 分钟
这一页我只说一个问题：
"能对话"为什么不等于"能上线"？
原因：
很多人第一次接触 Agent，会觉得它无非就是
Prompt + Model + Tool。但真到生产环境中，这些是远远不够的。
因为一个能上线的 Agent，不只是要会回答，还要会：
- 调工具
- 传状态
- 控制流程
- 中断恢复
- 输出可观测的执行过程
所以今天这场分享，其实不是在讲"一个聪明的模型"，
而是在讲"一个可治理的 Agent 系统"。
第 2 节：先讲清 Agent 的最小运行时骨架
时间：1 分钟
这一页讲三个词：
AgentRunnerAgentEvent
可以这样说：
在 Eino ADK 里，我觉得最重要的不是某个具体 Agent，而是它背后的运行时骨架。
Agent解决的是：谁来执行任务 。
Runner解决的是：这个任务怎么被统一托管起来 。
AgentEvent解决的是：执行过程中发生了什么。这意味着，Agent 不再只是一次性返回一个字符串，
而是持续地产出事件流：
可能是模型输出、可能是 tool call、可能是 transfer，也可能是 interrupt。
所以 Eino 的切入点很精准：
把 Agent 运行过程也当成一等公民。
这里有一点可以确定：
后面我们讲 ReAct 和编排，其实都建立在这套运行时骨架上。
第 3 节：ReAct 到底是什么
时间：1.5 分钟
本页是核心页，
所以需要大家着重注意：
ReAct 的核心不是"某种 prompt 技巧"，
而是一种闭环范式：
Reason → Act → Observe也就是：
- 模型先思考下一步怎么做
- 然后调用工具去拿外部信息
- 再把工具结果喂回模型继续推理
这个闭环会不断重复，直到模型不再产生 tool call，才结束。
所以这就是ReAct最关键的价值：
它为什么重要？
因为它把模型的推理，锚定在了外部事实之上。
以前模型是"自己想"；
现在模型是"边查边想"。
所以它的可解释性更强，幻觉风险也更低。
这里抛一个面试点：
面试里经常会问两个控制点：
终止条件是什么？答：模型不再产生 tool call。
为什么要有 MaxIterations/MaxStep？答：防止无限循环，控制成本和可用性。
若这一页理解透了，则后面所有内容都顺了。
切记，所谓的范式，不过是一套方法模板罢了，没有大家想象的高大上。
第 4 节：Eino 里 ReAct 是怎么落地的
时间：1.5 分钟
这页我不会讲太细的源码，而是重点讲工程表达。
可以这样说：
在 Eino 里，ReAct 不是停留在概念层，而是被明确表达成了一个执行闭环。
最直观的理解就是：
ChatModel 和 ToolsNode 之间形成了一个环。模型先输出 tool call，工具执行后把 observation 写回状态，再回到模型继续推理。
这个过程一直循环，直到没有 tool call，或者命中直接结束条件。
在 ADK 里，这个闭环最典型的封装就是
ChatModelAgent。它本质上就是一个工程化的 ReAct Agent。
它帮你处理了很多工程问题，比如：
- 工具调用循环
- 最大迭代次数
- 某些工具执行后直接返回
- 显式退出协议
记住这句很关键的话：
因此，我更愿意把
ChatModelAgent理解成：
不是"一个聊天模型"，而是"一个带 ReAct 运行时的 Agent 封装"。
这一点，真的很加分。
第 5 节：Agent 编排到底在编排什么
时间：1 分钟
本页承上启下，非常重要。
可以这样说：
如果 ReAct 解决的是"一个 Agent 内部怎么闭环"，
那 Agent 编排解决的就是：
多个 Agent 之间怎么协作。所以这两件事不是同一个层面的问题。
- ReAct 关注的是单 Agent 内部：推理、行动、观察
- Orchestration 关注的是多 Agent 外部：分工、路由、状态共享、控制权转移
也就是说：
ReAct 是单体闭环，编排是群体协作。
然后直接引到后面三种模式：
在 Eino ADK 里，最值得讲的三种编排模式分别是：
- Workflow Agents
- Supervisor
- Plan-Execute
第 6 节：三种典型编排模式，一次讲清
时间：2 分钟
这一页很朴素，你可以直接把这三种编排当成 "三兄弟"
第一种：Workflow Agents
可以这样说：
Workflow Agents 是确定性编排。
路怎么走，是代码提前写死的。
比如顺序执行、循环执行、并行执行。
它的优点是：可预测、易审计、易测试。
它的缺点是：灵活性不如模型自主决策。
第二种：Supervisor
Supervisor 是中心化调度。
也就是有一个总控 Agent，负责把任务分配给不同子 Agent。
子 Agent 负责干活，总控负责继续判断下一步。
它更像一个项目经理模式。
第三种：Plan-Execute
Plan-Execute 是"先规划，再执行，再重规划"。
它适合长任务、复杂任务。
因为它不是边走边猜，而是先把任务拆成步骤，再一步一步做。
所以它比纯 ReAct 更适合长链路研究型任务。
然后你做个总收束：
这三种模式，本质上对应三种不同的控制哲学：
- Workflow：代码决定流程
- Supervisor：中心调度决定流程
- Plan-Execute：规划结果决定流程
第 7 节：几个最容易讲混的边界
时间：2.5 分钟
这一页不贪多，只讲3个最有价值的。
边界 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 这种方式去做。
第 8 节：收尾
时间：0.5 分钟
这 10 分钟，如果只记住一句话，我希望是这句：
ReAct 解决的是单 Agent 如何形成"推理---行动---观察"的闭环；
Agent 编排解决的是多个 Agent 如何分工、协作和治理。
Eino ADK 的价值，就在于把这两件事都做成了可工程化落地的运行时。所以从面试视角看，真正重要的不是你会不会调一个模型，
而是你能不能讲清：
- 一个 Agent 为什么能跑起来
- 多个 Agent 为什么能协作起来
- 它们为什么能被治理、被中断、被恢复、被追踪
三、总结
本篇文章，以下几点最为重要。
- ReAct 是单 Agent 闭环
- 本篇说的编排是多 Agent 协作
- Workflow / Supervisor / Plan-Execute 是三种不同控制哲学
- ADK Workflow Agents 和 compose.Workflow 不是一回事
所以从工程视角看，Agent 不只是"模型会说话"，
而是"模型、工具、状态和控制流"被组织成了一个可治理系统。
ReAct 是这个系统里单 Agent 的闭环，编排是多个 Agent 的协作方式。