从 ReAct 到 Supervisor-Worker：AI Agent 核心概念与架构选择

前几天和一个做业务的朋友聊天，他很认真地问我：“现在到处都在说Agent，到底和ChatGPT有什么区别？是不是把提示词写长一点，再给它接几个工具，就算Agent了？” 这个问题很有代表性。 2024到2025年，大家还在兴奋地讨论“大模型能不能用工具”。到了2026年，讨论已经变成了“你的Agent是单循环还是多Agent？Supervisor怎么设计？上下文怎么压缩才不会爆炸？” 概念普及的速度，远远落后于技术演进的速度。 很多团队今天上线的所谓“Agent”，本质上还是一个加了工具调用的对话机器人。它能完成简单任务，但一旦步骤变多、环境开始变化、需要专业分工，系统就会迅速变得不可控——成本飙升、循环无法终止、出错后根本不知道问题出在哪一层。 这篇文章不讲空泛的趋势，也不堆砌论文名。我会用尽可能直白的方式，把Agent最核心的概念、主流架构模式、以及生产环境里真正会踩的坑，一次讲清楚。 读完之后，你至少能回答这几个问题： Agent和普通大模型调用的本质区别是什么？ ReAct、Plan-and-Execute、Reflexion到底解决什么问题，分别适合什么场景？ 什么时候该上多Agent，什么时候上了反而更糟？ Supervisor和普通Agent、Orchestrator之间到底有什么差别？ 真正要落地时，最该优先解决的工程问题是哪些？

准备好，我们从头说起。 一、Agent的本质：它不是“会说话的模型”，而是“会行动的闭环”

先把最容易混淆的点说清楚。 大模型（LLM）本身是一个输入→输出的函数。你给它一段文本，它返回一段文本。它没有“目标”，也没有“持续行动”的能力。 Agent则不同。 一个Agent至少具备四个基本能力： 目标：它知道自己要完成什么事。 感知：它能接收环境反馈（工具返回结果、用户新输入、系统状态变化）。 决策：它能根据当前观察，决定下一步做什么。 行动：它能真正调用工具、修改状态、或者委托其他Agent。

这四个能力构成一个闭环。只要任务没完成，它就继续“感知→决策→行动→再感知”。 这就是为什么我们说“Agent是行动的闭环”，而不是“会聊天的模型”。 用一个最简单的例子说明。 用户说：“帮我查一下明天上海到北京的高铁，选一趟合适的，并告诉我是否需要提前订票。” 普通大模型可能会直接编造一趟车次，或者告诉你“建议去12306查询”。 一个具备工具调用能力的Agent会这样做： 思考：我需要先获取实时车次信息。 行动：调用高铁查询工具。 观察：拿到返回的车次列表。 再思考：根据用户偏好（假设之前提过喜欢下午出发）筛选。 再行动：可能再查一次余票情况。 最终给出有依据的建议。

关键差别在于：它把“思考”和“行动”交错进行，并且每一步都依赖真实的环境反馈，而不是一次性生成全部答案。 这个“交错进行”的思想，直接引出了今天最基础、也是使用最广泛的Agent模式——ReAct。 二、单Agent的三大基础模式：ReAct、Plan-and-Execute与Reflexion

单Agent系统是所有复杂架构的基础。搞不清楚单Agent怎么转，多Agent基本会变成灾难。 目前生产环境里，最常被讨论的三种模式是ReAct、Plan-and-Execute和Reflexion。它们解决的问题层级不同，经常被组合使用。 1. ReAct：走一步看一步的适应性循环

ReAct（Reason + Act）的核心思想非常直接：让模型在每一步都先产生思考（Thought），再决定行动（Action），然后观察结果（Observation），如此循环，直到任务结束。 它的执行流程可以用下面这张图表示：

ReAct的优势非常明显： 适应性强。中间任何一步的结果都可以改变后续路径。 对未知路径友好。当任务步骤无法提前完全枚举时，它依然能工作。 调试相对直观。整条轨迹是线性的，出了问题可以顺着看。

但它的代价同样真实： 上下文会随着步数快速膨胀。每一步都要把历史Thought、Action、Observation全部带上，token消耗呈近似二次方增长。 容易陷入局部最优或无限循环。模型可能反复尝试同一个失败的工具调用。 调用次数多，延迟和成本都偏高。

因此，生产中使用ReAct时，几乎必须加上硬约束：最大步数、重复动作检测、token预算熔断。 适合ReAct的场景：路径不可完全预知、需要根据实时观察改道、步骤数相对较少（通常控制在8步以内）、交互性强的任务。例如开放式信息搜集、根据报错动态调试代码、用户随时可能插话的客服对话。 2. Plan-and-Execute：先定全局，再按图执行

Plan-and-Execute把“策略”和“战术”分开。 它先让一个较强的模型（Planner）生成完整的任务分解计划，通常是一个有序步骤列表，或者带依赖关系的DAG。然后再由执行器（可以是同一个模型，也可以是更弱的模型）按计划逐步执行。 流程如下：

这种模式的核心收益： 计划本身是可审计的产物。你可以在执行前先看计划是否合理，甚至让人审批。 成本更可控。强模型只用于规划，执行阶段可以用更便宜、更快的模型。 支持一定程度的并行（当计划里步骤没有依赖时）。

主要风险： 计划错了会被“忠实执行”。如果Planner一开始就理解偏差，后面所有步骤都会建立在错误基础上。 中途环境变化时适应性较差，除非显式设计了replan触发机制。

适合Plan-and-Execute的场景：步骤可以相对清晰地枚举、需要可审批的中间产物、成本敏感、全局一致性比中途微调更重要的任务。例如报告生成（先列大纲）、已知业务流程的自动化、多源数据汇总分析流水线。 3. Reflexion：让Agent具备“事后批评”的能力

Reflexion（以及更广义的Reflection）不是一个独立的完整架构，而是一个质量闭环层。 它的做法是：在执行过程中或执行结束后，让模型对刚才的轨迹或最终产出进行口头反思，生成“哪里做错了、下次应该怎么改”的信号，然后再带着这个信号重试或修正。 它可以叠加在ReAct之上，也可以叠加在Plan-and-Execute之上。 它解决的核心问题是：模型经常会重复犯同样的错误。通过显式的自我批评，可以把“这次失败的经验”快速注入到下一次尝试中，形成一种短期的、针对当前任务的学习。 代价也很直接：额外的LLM调用会增加延迟和成本。如果反思本身产生幻觉，反而会引入噪声。 因此在生产中，Reflexion通常被限制使用——只在最终输出、或关键失败节点触发，而不是每一步都反思。 三种模式如何组合

现实中几乎没有人只使用某一种纯净模式。更常见的是分层混合： 外层用Plan-and-Execute（或Supervisor）产出高层计划。 对简单确定的步骤直接执行。 对复杂或不确定的步骤，降级为有界的ReAct子循环。 在关键产出或失败点叠加Reflexion/Verifier。

这种混合既能保留计划的可审计性，又给局部不确定性留了适应性空间。 三、为什么需要多Agent？单Agent的边界在哪里

当任务变得足够复杂，单Agent会遇到三个结构性瓶颈： 上下文窗口与注意力衰减。历史越长，模型对早期约束的遵循能力越弱。 能力稀释。一个通用Agent同时处理检索、分析、写作、验证，每一项都做不到专精。 并行度受限。单线程的思考-行动循环无法有效利用可并行的子任务。

多Agent的核心价值，就是通过专业化分工和受控协作，突破这三个瓶颈。 但必须先说清楚一个反直觉的事实：多Agent不是免费的午餐。 每增加一个Agent，潜在的交互路径就在增加。协调本身会消耗token、增加延迟、放大失败传播的风险。很多团队在单Agent还没跑稳的时候就上多Agent，结果只是把“模型错误”变成了更难调试的“协调错误”。 所以判断标准很简单： 单Agent的上下文或能力已经明显成为瓶颈 → 考虑拆分。 任务天然可以按职责或阶段清晰切开 → 拆分收益更大。 团队还没有跨Agent的tracing和状态持久化能力 → 先别拆。 四、多Agent协作的主流形态：Supervisor-Worker

在2026年的生产实践中，真正跑得比较稳的多Agent模式高度收敛到层次化的Supervisor-Worker（也常被称为Orchestrator-Workers）。 基本结构

一个（或少量）Supervisor负责全局：理解目标、分解任务、路由给合适的Worker、收集压缩后的结果、决定是否继续或重新规划。 多个Worker各自持有窄职责、窄上下文和专项工具，只返回结构化的结果摘要，而不是完整轨迹。 控制流大致如下： 分工的关键原则

分工的本质是缩小每个Agent的决策空间。 常见有效的划分维度包括： 角色职责：检索、分析、写作、批评、报告。 模型能力：强模型做Supervisor和最终综合，弱模型做执行型Worker。 工具权限：每个Worker只暴露自己需要的工具子集，降低权限爆炸风险。 上下文范围：Worker只看到完成当前子任务所需的最小信息。

信息传递必须结构化。下行是清晰的任务包（目标、约束、输入、成功标准、步数上限），上行是结构化的结果包（状态、摘要、关键证据、错误信息）。禁止用自由文本“手递手”，否则信息丢失几乎不可避免。 Supervisor到底是什么

这里必须澄清一个常见混淆。 Supervisor是一种特殊角色的Agent，而不是与Agent对立的另一类东西。 Agent是通称：任何能感知、决策、行动的LLM驱动实体。 Supervisor是被赋予了全局控制权的Agent：它负责分解、路由、状态维护和最终决策。

普通Worker Agent的决策范围是局部的（“怎么完成我被分配的这个子任务”），Supervisor的决策范围是全局的（“下一步该谁做、做什么、什么时候算结束”）。 同一个底层模型，既可以当Supervisor，也可以当Worker，区别只在于给它的提示词、工具集、可见上下文，以及它是否拥有决定“下一步谁执行”的权限。 Supervisor与Orchestrator的细微差别

这两个词在文献和框架中经常混用，但侧重点不同： Supervisor更强调“谁说了算”——管理、决策、层级控制。 Orchestrator更强调“事情按什么顺序被推进”——流程编排、依赖管理、状态流转。

在实际系统里，你真正需要的往往是两者的结合体：一个既有智能决策能力，又能可靠地编排执行流程的中心控制组件。叫什么名字是次要的，职责定义清楚才是主要的。 五、工程落地时真正会痛的地方

概念再清晰，一到生产环境，问题就会集中爆发在这几个点上。 1. 状态与持久化

长任务几乎必然会遇到崩溃、限流、人工审批中断。没有checkpoint能力的系统，在生产中基本不可用。状态必须显式设计，并且支持从任意中断点恢复。 2. 终止与熔断

多Agent比单Agent更容易陷入互相等待或循环委托。必须有全局的步数预算、token预算、时间预算，以及重复handoff检测。没有熔断的Agent系统，最后都会变成成本黑洞。 3. 上下文工程

这是当前最被低估的能力。每个Agent只应该拿到完成自己职责所需的最小上下文。Worker返回的结果必须强制压缩。全量历史传递是成本与注意力的双重杀手。 4. 可观测性与归因

单Agent出问题，看线性轨迹通常能定位。多Agent出问题，经常是“协调失败”而不是“某个模型回答错了”。你需要记录：Supervisor的计划版本、每次路由决策、下发的完整任务包、Worker返回的完整结果包。没有这些，系统就是黑盒。 5. 工具与权限边界

工具调用必须schema化，并且在执行前经过策略检查。宽权限 + 模型幻觉 = 生产事故。高风险动作（写库、发消息、涉及资金）应该默认加human-in-the-loop或规则引擎拦截。 6. 评估方式的错位

技术benchmark上的高成功率，经常无法对应真实业务效用。你需要同时看任务成功率、成本、延迟、以及失败后的可恢复性。只优化“能不能做完”，不优化“做完要花多少钱、出了问题能不能修”，系统最终会不可持续。 六、如何选择适合自己的架构：一个可执行的决策框架

面对一个具体任务，可以按下面的顺序判断： 第一步：先问单Agent够不够。 如果步骤少、路径相对确定、上下文窗口足以覆盖，优先用有界的ReAct或Plan-and-Execute。简单系统永远更可控。 第二步：如果需要拆，优先选Supervisor-Worker。 它在可预测性、可调试性、专业化收益之间取得了目前最好的平衡。纯peer-to-peer或Swarm除非有特殊理由，否则不建议作为默认选择。 第三步：明确控制权归属。 谁有权决定下一步？谁有权终止？谁有权触发replan？这些必须在设计阶段就写清楚，而不是运行时靠模型“自己协商”。 第四步：把工程约束当作一等公民。 状态持久化、熔断、结构化接口、tracing，这些不是“上线后再补”的优化项，而是架构的一部分。缺了它们，模式选得再正确也跑不起来。 第五步：用真实任务做小规模验证。 先用3–5个典型任务跑通，同时记录token消耗、延迟、失败模式。很多看起来优雅的设计，一碰到真实数据分布就会暴露问题。 七、写在最后：概念清晰，是工程可控的前提

Agent不是魔法，它是把“目标、感知、决策、行动”显式闭环的工程系统。 ReAct解决的是局部适应性问题。 Plan-and-Execute解决的是全局结构与可审计问题。 Reflexion解决的是质量闭环问题。 Supervisor-Worker解决的是专业化分工与受控协作问题。 它们不是互相取代的关系，而是可以按需组合的控制手段。 真正决定一个Agent系统能否在生产中存活的，往往不是模式选得有多前沿，而是： 上下文有没有被有效管理 失败有没有被清晰隔离 成本与延迟有没有被纳入设计约束 出了问题能不能快速定位到是哪一层、哪一次决策出了偏差

概念普及的意义，正在于此。只有先把这些基础问题想清楚，后面的框架选择、模型选择、提示词优化，才有坚实的地基。 如果你正在从0到1搭建自己的Agent系统，建议从最小的有界ReAct开始，把熔断、日志、评估先做扎实，再根据真实瓶颈决定是否引入Plan-and-Execute或Supervisor-Worker。 复杂是代价，不是目标。