智能体开发范式总结

这一篇脱离平台，讲通用的编排范式。这些范式最初由 Anthropic 在《Building Effective Agents》中系统整理，LangGraph 的文档又给出了对应的实现骨架，本文的分类和命名沿用这一脉络。

需要说明的是，这些范式不是框架，也不是必须遵守的规范，它们是被反复验证过的结构模板。认识它们的价值在于：拿到一个需求时，你不必从零开始想该怎么搭，而是能很快判断”这个像是路由 + 并行”，然后直接从模板出发。

1 范式总览#

所有范式都可以按自主性排成一条谱系，从完全不需要范式的单次调用开始，越往下模型接管的决策越多：

• 单次调用 —— 一进一出，没有控制流可言
• 工作流类（控制流在设计时确定，模型只负责每个步骤内部的具体工作）
  1. Prompt Chaining 提示链
  2. Parallelization 并行化
  3. Routing 路由
  4. Orchestrator-Worker 编排者-执行者
  5. Evaluator-Optimizer 评估者-优化者
• 智能体类（控制流在运行时生成，模型接管”下一步做什么”） 6. ReAct 及其各种改进版 7. Multi-Agent 多智能体

从上往下，能处理的任务越开放，可控性、可预测性、成本可估算性依次下降。

有一点容易被误解：Orchestrator-Worker 虽然归在工作流类，却已经带有相当程度的动态性——子任务是运行时决定的，只是编排结构本身固定。范式的边界本就是渐变的，不必纠结某一种归哪边，重要的是看清它把哪一部分的决策权交了出去。

2 先问一句：这个需求真的需要智能体吗#

在展开范式之前，先讲一个反向的判断顺序，因为过度设计是这个领域最常见的浪费。

正确的顺序是从简单往复杂走：能用单次调用解决的，就别引入检索；单次调用答不准，加上检索（RAG）看看能不能解决；检索还不够，说明任务需要多步，这时上固定工作流；工作流画不出来，才考虑智能体。

每往前一步，你付出的是延迟、成本和可控性，换回的是处理更开放任务的能力。这笔交易只在必要时才划算。

那么什么时候是”必要”？有三个比较可靠的信号。步骤无法穷举——你试着画流程图，发现分支多到画不完，或者根本不知道下一步该干什么，取决于上一步的结果。工具组合是开放的——不是”先查 A 再查 B”，而是”可能查 A，可能查 B 再查 A，也可能都不用查”。需要根据中间结果改变策略——比如查到的资料不足时要换个角度再查一轮。

反过来，如果你能在白板上把流程图完整画出来，那就照着画的搭，别用智能体。能画出来的流程，交给模型去”想”，只是花更多的钱买更不稳定的结果。

3 工作流类范式#

以下五种范式的顺序沿用 LangGraph 文档的排列。

3.1 Prompt Chaining｜提示链#

提示链的定义，按 Anthropic 的原话是：把一个任务分解成一串步骤，其中每一次 LLM 调用处理上一次调用的输出。

这句话里”步骤”和”LLM 调用”是分开说的，值得照着读一遍（也就是 0.3 节钉过的那组术语）。**步骤是任务侧的分解结果，LLM 调用是实现它的手段。**一个步骤未必只对应一次调用，链条上也未必每个环节都要调模型——下面这张图里的门禁就是个例子。

flowchart LR
    IN([输入]) --> S1["LLM 调用 1<br/>步骤：提炼要点"]
    S1 --> G{"门禁校验<br/>程序判断，不调模型"}
    G -- 通过 --> S2["LLM 调用 2<br/>步骤：写成初稿"]
    G -- 不通过 --> FB([兜底 / 终止])
    S2 --> S3["LLM 调用 3<br/>步骤：润色成稿"]
    S3 --> OUT([输出])

这张图上有 3 个步骤、3 次 LLM 调用、4 个节点——门禁是第四个节点，但它不产生任何 LLM 调用。三个数字不相等，这正是要把三个词分开用的原因。

提示链的价值在于降低每个步骤的难度。让模型一次性完成”读懂这份需求文档、提炼出功能点、写成用户故事、再评估每个故事的工作量”，它多半会顾此失彼；分解成四个步骤，每个步骤都简单到不容易出错，整体质量反而更高。

第二个价值是步骤之间可以插入程序化的门禁。Anthropic 的示意图里专门画了这个 Gate，LangGraph 的文档也提到链条上可以加条件判断：检查上一次调用的输出是否合格，不合格就走兜底或直接终止，不必让错误一路传下去。这类判断是程序逻辑，不消耗 LLM 调用，却是纯提示词做不到的。

适用信号很明确：任务能被清晰地分解成有先后顺序的几个步骤，且每个步骤的产出都能被检验。文档翻译（先直译、再润色、再校对术语）、内容审核（先分类、再按类型详查）、报告生成（先列大纲、再逐节写）都是典型。

代价也很直接：串行意味着延迟叠加，四个步骤如果各对应一次调用，端到端就是四次 LLM 调用的时间；而且错误会沿着链条放大——第一个步骤提炼错了功能点，后面三个做得再好也没用。所以门禁的位置要设在关键处，尤其是第一次调用之后。

3.2 Parallelization｜并行化#

并行化是让多个模型调用同时进行，而不是排队等待。它有两个形态，解决的问题完全不同。

分片（Sectioning）把任务切成互不依赖的块，同时处理，最后聚合。比如要审阅一份五十页的合同，把它按章节切成十份，十个模型调用同时跑，各自返回本章的风险点，最后合并成一份清单。这里的核心收益是速度——十份并行的耗时约等于一份的耗时。前提是这些块之间真的没有依赖关系；如果第七章的理解依赖第三章的定义，切开就会出错。

投票（Voting）则是让同一个任务跑多次，然后聚合多次结果。比如判断一段代码有没有安全漏洞，跑五次，五次里有三次说有就判定为有。这里的收益是准确率——用冗余换可靠性。它适合那些单次判断不够稳、但错判代价高的场景。聚合方式可以是多数表决，也可以是”任一命中即告警”这样的保守策略，取决于你更怕漏报还是误报。

flowchart TD
    IN[输入] --> A[子任务 A]
    IN --> B[子任务 B]
    IN --> C[子任务 C]
    A --> AGG[聚合节点]
    B --> AGG
    C --> AGG
    AGG --> OUT[输出]

在低代码平台上，分片通常用迭代节点实现，投票则需要复制几路相同的分支再汇聚。要注意的是，并行省的是时间，不是钱——十路并行的 token 消耗和十路串行是一样的。

3.3 Routing｜路由#

路由的做法是先对输入做一次分类，再根据分类结果分流到不同的处理支路，每条支路用各自最合适的提示词、知识库甚至模型。

flowchart TD
    IN[用户输入] --> R{分类器}
    R -- 价格咨询 --> P1[报价支路]
    R -- 退款申请 --> P2[退款支路]
    R -- 技术故障 --> P3[技术支持支路]
    R -- 其他 --> P4[兜底支路]

它解决的是一个很实际的矛盾：当输入类型差异很大时，试图用一套提示词覆盖所有情况，会让每一种情况都做不好。你为了照顾退款场景加的那句约束，可能正好干扰了技术咨询的回答。分开之后，每条支路都可以针对性地优化，互不干扰。

路由还有一个常被忽略的好处是成本控制：简单类型分流到便宜的小模型，复杂类型才走贵模型。在调用量大的场景里，这一项省下的钱相当可观。

设计路由时有三个要点。分类要用结构化输出，让模型返回一个枚举值而不是一段自然语言，否则解析会不稳定；低代码平台上的”问题分类”节点就是干这个的。必须有兜底支路，因为总会有输入不属于任何已定义的类别，没有兜底就会走到空分支。类别数量要克制，超过七八个之后分类准确率会明显下降，这时候应该考虑做两级路由。

3.4 Orchestrator-Worker｜编排者-执行者#

编排者-执行者常被误认为是并行化的变体，但两者有一条本质区别，值得单独强调：并行化的子任务是你事先切好的，编排者-执行者的子任务是运行时才决定的。

flowchart TD
    IN[输入] --> O[编排者<br/>动态拆解任务]
    O --> W1[执行者 1]
    O --> W2[执行者 2]
    O --> Wn[执行者 n]
    W1 --> S[汇总者<br/>合成最终结果]
    W2 --> S
    Wn --> S
    S --> OUT[输出]

编排者读完输入之后，自己判断这个任务该拆成几个子任务、每个子任务是什么，然后把它们分发给执行者；执行者各自完成后，再由汇总环节合成最终结果。子任务的数量和内容都是动态的——同样的编排结构，处理 A 需求时拆成三个子任务，处理 B 需求时可能拆成七个。

这就是为什么 LangGraph 文档说它适合”子任务无法预先定义”的场景。写代码是最典型的例子：改一个功能要动哪几个文件，事先没法知道，得先看过代码才能决定。做研究报告也是：要查哪几个方向，取决于题目。

它的代价在于：编排者的拆解质量决定了整体上限，拆错了后面全白做；而且子任务数量不受控，成本难以预估——所以实践中一定要给拆解数量设上限。

在低代码平台上，这个范式的实现通常是”一个 LLM 节点输出结构化的任务数组 → 迭代节点逐项处理 → 聚合节点汇总”。

3.5 Evaluator-Optimizer｜评估者-优化者#

评估者-优化者引入了一个循环：生成者产出结果，评估者按标准打分并给出修改意见，如果不合格就带着意见回到生成者重写，直到通过或达到次数上限。

flowchart LR
    IN[输入] --> G[生成者]
    G --> E{评估者}
    E -- 不通过 · 附修改意见 --> G
    E -- 通过 --> OUT[输出]
    E -- 达到次数上限 --> OUT

这个范式模拟的是人类”写完再改”的过程，在需要打磨质量的任务上效果明显——文案创作、翻译润色、代码优化都属于此类。

它能起作用有一个前提，这个前提很关键：评价标准必须能被明确表达出来。“这段文案要有感染力”是没法评估的，模型只会给出空泛的赞美；“这段文案必须在 80 字以内、包含产品名、包含一个具体数字、不使用感叹号”才是可评估的。标准写不清楚，这个循环就退化成了自我陶醉。

另外两个工程要点：必须设停止条件，通常是最大轮次（经验值 2 到 3 轮，再多收益急剧递减）；评估者最好换一个视角，比如用不同的提示词甚至不同的模型，让它扮演一个挑剔的审稿人，而不是复述生成者的思路。

3.6 五种范式对比#

真实项目里，这些范式几乎从不单独出现。一个成熟的客服流程往往是”路由分流 → 某条支路里用提示链先检索再作答 → 关键回复过一遍评估者”的组合。把范式当积木，而不是当选择题。

4 智能体类范式#

从这一节开始，控制权交给模型。LangGraph 文档对智能体的描述是”在持续的反馈循环中使用工具执行动作”，适合”不可预测的、需要自主决策该用什么工具的问题”。下面六种范式，本质上都是在回答同一个问题：这个循环该怎么组织，才能既灵活又不失控。

4.1 ReAct#

ReAct 是绝大多数智能体的默认底座，名字来自 Reasoning + Acting。它的循环结构非常简单：模型先输出一段思考（Thought），说明当前情况和下一步打算；然后输出一个行动（Action），也就是调用某个工具；工具返回结果作为观察（Observation）回到上下文；模型基于新的观察再思考，如此往复，直到它认为可以作答。

flowchart LR
    Q[用户问题] --> T[Thought 思考]
    T --> A[Action 调用工具]
    A --> O[Observation 观察结果]
    O --> T
    T -- 已足够 --> ANS[生成回答]

它为什么有效？因为它把”想”和”做”显式地交替开来，让模型每做一件事之前先说明理由。这种结构一方面提升了决策质量，另一方面让整个过程变得可读——出问题时你能看到它是在哪一轮想歪的。

ReAct 的两个通病也很明显。轨迹冗长：每一轮都要输出思考，token 消耗随轮次线性增长，一个复杂任务跑下来上下文可能膨胀好几倍。错误累积：一旦某一轮的观察被误读，后面的思考都建立在错误前提上，而模型很少会主动推翻自己之前的判断。这两个问题正是后面几种范式想要改进的地方。

4.2 Plan-and-Execute#

Plan-and-Execute 把规划和执行分成两个阶段：先由一个规划器一次性产出完整的步骤列表，再由执行器逐条执行，执行完再看要不要重新规划。

flowchart TD
    Q[任务] --> P[规划器<br/>产出完整步骤列表]
    P --> E[执行器<br/>逐条执行]
    E --> C{全部完成?}
    C -- 否，且计划仍适用 --> E
    C -- 否，但情况有变 --> RP[重规划器] --> E
    C -- 是 --> ANS[汇总输出]

它相对 ReAct 的改进有两点。全局视野：ReAct 是走一轮看一轮，容易在局部打转；Plan-and-Execute 一开始就通盘考虑，步骤之间的衔接更连贯。成本优化：规划需要强推理能力，执行往往只是照做，所以可以让贵模型规划、便宜模型执行，这在长任务上省下的成本很可观。

它的软肋是计划赶不上变化。第三步执行时发现前提不成立，后面的计划就全部作废。所以完整的 Plan-and-Execute 必须带**重规划（Replan）机制——执行过程中定期检查计划是否仍然有效，失效就重新规划。没有重规划的 Plan-and-Execute 在真实环境里很脆弱。

4.3 Reflexion#

Reflexion 在执行循环之外加了一层自我反思：一次尝试失败或结果不理想之后，让模型分析”这次为什么没做好”，把反思的结论写进记忆，下一次尝试时带着这份记忆重来。

这里需要厘清三个容易混淆的概念。Reflection（反思）是最宽泛的说法，泛指让模型审视自己输出的做法。Self-Refine（自我精炼）是在同一次任务内生成、自评、重写的循环——它其实就是 3.5 的 Evaluator-Optimizer，只不过评估者也是模型自己。Reflexion 的独特之处在于两点：它依赖外部反馈（测试是否通过、工具是否报错、任务是否达成这类客观信号，而不只是模型的自我评价），并且它把反思结论跨轮次积累在记忆里，让智能体在多次尝试之间真正”学到东西”。

所以判断一个设计是不是 Reflexion，就看两条：有没有外部的成败信号，反思结论有没有跨次留存。只有模型自己夸自己、且下一次尝试时上一次的教训已经丢了的，那是 Self-Refine，不是 Reflexion。

它适合有明确成败判据、且允许多次尝试的场景，代码生成配合单元测试是最经典的例子。代价是尝试次数成倍增加，延迟和成本都不低。

4.4 ReWOO 与 LLMCompiler：为省钱和降延迟而生#

这两种范式都在改进 ReAct 的开销问题，思路相邻，放在一起看更清楚。

ReWOO（Reasoning WithOut Observation）针对的是 token 消耗。ReAct 每调一次工具，结果都会拼进上下文再发给模型，调五次工具就是五次 LLM 调用，且输入越来越长。ReWOO 则让规划器一次性写出带占位符的完整工具调用计划，交给一个不含模型的执行器批量跑完，最后模型再汇总一次。全程只有两次 LLM 调用——核心收益是省 token。代价是计划在看到任何结果之前就定死了，无法根据中间结果调整策略。

LLMCompiler 可以理解为 ReWOO 加上并行调度：同样先规划，但把任务组织成依赖关系图（DAG），让无依赖的任务并行跑。要查三个互不相关的数据源，ReWOO 依次查，LLMCompiler 三个一起发——核心收益是降延迟。代价是复杂度最高，需要规范的依赖描述和真正的调度器，在低代码平台上基本搭不出来，只能用”一次规划 + 并行分支”近似。

顺带一提几个不常单独使用、但概念上值得知道的：Tree of Thoughts 每轮产生多个候选方向并像搜索一样剪枝，适合需要试错的解题类问题，代价极高；Self-Ask 让模型回答前先自问自答子问题，算提示链的轻量变体；Chain of Thought 严格说是提示技巧而非智能体范式，但它是上述所有范式的认知基础。

4.5 横向对比#

这张表最实用的读法是按约束反查：预算紧就往 ReWOO 看，要求响应快就往 LLMCompiler 看，任务不可预测就回到 ReAct，有明确成败判据且允许重试就上 Reflexion。

5 Multi-Agent｜多智能体#

5.1 为什么要多智能体#

多智能体是当下最热闹也最容易被滥用的方向，所以先说清楚它到底解决什么问题。

上下文隔离是最实在的动因。单个智能体挂上二十个工具、一份三千字的提示词之后，表现往往不升反降——它开始挑错工具，开始忽略提示词中段的约束。拆成多个各管一摊的智能体，每个只看见自己需要的那部分，判断质量立刻回升。

角色与工具集的专业化是第二个动因。写代码的智能体和查资料的智能体需要的提示词风格、工具集、甚至模型都不同，硬塞在一起是互相拖累。

并行加速是第三个。多个子任务确实可以同时推进，尤其是研究、检索这类天然可拆的工作。

还有一个伪动因值得警惕：单纯因为”像一个团队”而设计多智能体。给每个 Agent 起个”产品经理""架构师”的名字，看起来很像回事，但如果这些角色之间的信息传递并没有减少上下文负担、也没有提升专业度，那它带来的只有成本和不确定性。多智能体是用来解决上下文和专业化问题的，不是用来模拟组织架构的。

5.2 六种拓扑：总览#

多智能体系统之间的差异，几乎全部体现在拓扑上——谁能把控制权交给谁。这一个问题决定了系统的可预测性、调试难度、token 开销和失控方式。

下面六种拓扑按控制权集中度从高到低排列，和 1 节那条自主性谱系是同一个思路：越往后走，系统能应对的任务越开放，你对它的掌控越少。

flowchart LR
    A[流水线] --> B[子智能体作为工具] --> C[主管式] --> D[分层] --> E[网状] --> F[辩论式]
    A -.- L1[控制集中<br/>路径可预测<br/>调试容易]
    F -.- L2[控制分散<br/>路径不可预测<br/>调试困难]

读这六张图时，建议盯住三件事：实线箭头是控制权的流向（谁激活了谁），虚线箭头是控制权的交回，以及子智能体之间有没有横向连线——最后这一条往往就是两种拓扑的本质区别所在。

拓扑一：流水线（Sequential / Pipeline）#

flowchart LR
    IN([任务输入]) --> A[检索智能体]
    A -->|资料| B[撰写智能体]
    B -->|初稿| C[校对智能体]
    C --> OUT([交付])

控制流：固定顺序，一条直线走到底。前一个智能体的输出就是后一个的输入，没有任何分支和回头路。谁在什么时候工作，在设计阶段就定死了。

流水线严格说已经踩在多智能体的门槛上——它和 3.1 的提示链没有结构上的区别，唯一的不同是每一环有自己的角色、提示词和工具集。检索环节挂着知识库和搜索工具，撰写环节挂着模板和写作提示词，校对环节挂着术语表，各司其职。

什么时候用：业务流程本身就是线性的，而且每一环需要的能力差异明显。内容生产（检索 → 撰写 → 校对）、数据处理（提取 → 清洗 → 汇总）、代码流程（生成 → 测试 → 修复）都是典型。

代价与失败方式：灵活性最差——中间某一环发现前一环做错了，没有机制退回去重做。而且错误会沿着链条单向放大，这就是 5.5 节那个乘法：三个 90% 串起来只剩 73%。缓解办法是在环与环之间插入程序化的门禁，不合格就中止或走兜底，而不是硬着头皮往下传。

拓扑二：子智能体作为工具（Agent-as-Tools）#

flowchart TD
    IN([任务输入]) --> M[主智能体<br/>ReAct 循环]
    M -->|工具调用| T1[普通工具<br/>查询数据库]
    M -->|工具调用| T2[子智能体<br/>数据分析]
    M -->|工具调用| T3[子智能体<br/>报告撰写]
    T1 -->|返回值| M
    T2 -->|返回值| M
    T3 -->|返回值| M
    M --> OUT([输出])

控制流：只有一个真正的决策者。主智能体跑自己的 ReAct 循环，把每个子智能体封装成一个普通工具来调用；子智能体做完自己那一小段，把结果作为工具返回值交回来，控制权从未真正离开过主智能体。

请注意图中子智能体之间没有任何横向连线——这正是它和下一种拓扑的分界线。子智能体是被”调用”的，不是被”移交”的；它没有资格说”这事该找 B 来办”，只能把结果还给主智能体，由主智能体再决定。

什么时候用：**这是大多数业务场景应该优先尝试的结构。**它复用了成熟的函数调用机制，不需要额外设计移交协议；子智能体的上下文天然隔离（它只看到主智能体传给它的参数）；调试时轨迹清晰，因为所有决策都在一个地方发生。

代价与失败方式：主智能体的上下文会被子智能体的返回值不断填充，任务一长仍然会膨胀，所以子智能体应该返回结论而不是过程。另一个限制是子智能体之间无法直接协作，如果你的场景里 A 做完必须由 B 接着做同一份工作，用这个结构会绕得很别扭——那就该升级到主管式了。

拓扑三：主管式（Supervisor）#

flowchart TD
    IN([任务输入]) --> S{{主管智能体}}
    S -->|派发任务| A[数据智能体]
    S -->|派发任务| B[分析智能体]
    S -->|派发任务| C[写作智能体]
    A -.->|交回控制权| S
    B -.->|交回控制权| S
    C -.->|交回控制权| S
    S -->|判定完成| OUT([输出])

控制流：一个中心节点决定当前该由谁来做。子智能体拿到控制权后可以自主工作若干轮，完成后把控制权交回主管，主管看过结果再决定下一步派给谁——也可能派回给同一个，也可能判定任务结束。

它和”子智能体作为工具”的区别，图上就是那组虚线的交回箭头：那里是”返回一个值”，这里是”交还控制权”。差别体现在两点：子智能体在这里是有状态的参与者，可以持有自己的对话历史；而且它可以在自己的回合里主动说”我做不了，请交给 B”，由主管去执行这次转交。

什么时候用：任务需要在几个智能体之间来回多轮，且顺序不能事先确定。研究类任务是典型——查完资料发现缺口，要回去再查，查完再分析，分析完发现还缺一块。

代价与失败方式：主管是瓶颈也是单点。每一次交接都要经过主管的一次完整模型调用，token 开销显著高于工具式；主管的判断一旦跑偏，整个系统跟着偏。另一个常见故障是主管来回派发同一个任务却始终判定不了完成，所以总轮次上限在这里是必需的，不是可选项。

拓扑四：分层（Hierarchical）#

flowchart TD
    IN([任务输入]) --> T{{总主管}}
    T -->|分派| M1{{研究组主管}}
    T -->|分派| M2{{交付组主管}}
    M1 --> A1[检索智能体]
    M1 --> A2[核实智能体]
    M2 --> B1[撰写智能体]
    M2 --> B2[排版智能体]
    A1 -.-> M1
    A2 -.-> M1
    B1 -.-> M2
    B2 -.-> M2
    M1 -.->|阶段成果| T
    M2 -.->|阶段成果| T
    T --> OUT([输出])

控制流：主管之上再加主管，用分治应对规模。总主管只跟中层主管打交道，中层主管管好自己组内的几个执行者。每一层都只需要在有限的几个选项之间做选择。

什么时候用：当子智能体数量超过七八个、主管开始分不清该派给谁的时候。这个信号很明确——你会看到主管频繁派错人，或者提示词里罗列的智能体说明长得像一本目录。这时候按领域分组，每组一个中层主管，每一层的决策空间就重新回到了可控范围。

代价与失败方式：层级是有成本的，每加一层就多一轮转述，信息在向上汇报和向下分派的过程中会失真。经验上三层以上收益极低而成本极高，绝大多数场景两层足够。另一个陷阱是过早分层——子智能体只有四五个就搞两层，纯属自找麻烦。

拓扑五：网状（Network / Swarm）#

flowchart LR
    IN([任务输入]) --> A
    A[研究智能体] <-->|移交| B[编码智能体]
    B <-->|移交| C[测试智能体]
    A <-->|移交| C
    C --> OUT([输出])

控制流：没有中心。任意智能体都可以把控制权直接移交给任意其他智能体，谁接手由当前持有控制权的那个自己决定。

这是六种拓扑里最灵活也最难预测的一种。它的吸引力在于省掉了主管这个中转环节——测试智能体发现 bug，可以直接交给编码智能体，不必回到主管那里绕一圈，交接成本更低、链路更短。

什么时候用：智能体数量不多（三到五个）、彼此的职责边界清晰、且协作顺序高度依赖运行时情况。编码类的场景比较适合，因为”写—测—改”的循环本身就是不定次数的横向往返。

代价与失败方式：踢皮球死循环是它的标志性故障——A 觉得该 B 管，B 觉得该 A 管，两个智能体可以这样来回交接到你的预算耗尽。总移交次数上限在这里是保命的。此外它的轨迹最难读，出了问题要在好几份日志里对照着还原控制权的流转路径。在生产环境上网状结构之前，先确认你有能力观测它。

拓扑六：辩论式（Group Chat / Debate）#

flowchart TD
    IN([议题]) --> R[(共享对话空间)]
    P1[提案方] <--> R
    P2[质疑方] <--> R
    P3[领域专家] <--> R
    R --> J{{主持人<br/>判定是否收敛}}
    J -->|未收敛，继续| R
    J -->|已收敛| OUT([结论])

控制流：所有智能体共享同一个对话空间，都能看到彼此说过的话，通过多轮讨论逐步收敛。通常需要一个主持人角色来决定谁下一个发言、以及讨论什么时候可以结束。

它和前五种有一个根本区别：前五种是在分配工作，它是在碰撞观点。提案方给方案，质疑方挑毛病，专家补充事实，几轮下来得到的结论往往比任何单个智能体一次性给出的更周全。

什么时候用：需要多视角碰撞的判断类任务——方案评审、风险识别、复杂决策的利弊权衡。注意它的产出是一个结论，而不是一批完成的工作。

代价与失败方式：收敛性差是它最大的问题。没有主持人和轮次上限，几个智能体可以礼貌地互相赞同十几轮而毫无进展；角色设定不够对立，则会迅速退化成一片和谐的附和，失去辩论的意义。成本也是六种里最高的——每一轮每个角色都要看完整的共享历史。生产环境中要慎用，它更适合作为离线的方案打磨工具。

5.3 六种拓扑横向对比与选择路径#

选择时不必在六种之间横向比较，按下面这条递进路径走就行，每一步都只在遇到明确瓶颈时才往前迈：

先看流程是不是线性的，是就用流水线，别想复杂了。不是线性的，默认从”子智能体作为工具”起步——它覆盖了绝大多数业务场景，且工程上最省心。当你发现子智能体之间需要有状态地来回协作、一次调用返回一个值不够用时，升级到主管式。当子智能体多到主管派错人时，再分一层。只有在交接次数极多、主管中转的开销确实成了瓶颈时，才考虑网状，并且必须先备好移交次数上限和轨迹观测。辩论式则单独放在一边，它解决的是另一类问题，需要多视角碰撞时才用。

最后提醒一句：**拓扑越往后，收益是线性增长的，成本和失控风险却是指数增长的。**多数团队最终会退回到”子智能体作为工具”或”主管式”，这不是保守，而是这两种确实覆盖了绝大部分真实需求。

5.4 协作机制#

拓扑之外，还有三件事决定了多智能体系统好不好用。

移交（Handoff）怎么表达。移交本质上是一次特殊的工具调用：智能体输出”我要把任务转给 X，附带这些信息”。设计时的关键是移交时要带什么——只带一句任务描述，接收方可能缺少必要背景；把全部历史都带上，上下文又会爆炸。

通信模型选哪种。一种是共享状态，所有智能体读写同一份状态对象，好处是信息不丢失，坏处是每个智能体都要面对与自己无关的信息，且并发写入容易冲突。另一种是消息传递，智能体之间只传递明确的消息，好处是隔离干净，坏处是信息可能在传递中丢失。实践中常用的折中是”共享一份精简状态 + 定向传递详细内容”。

上下文工程是多智能体成败的关键，也是最容易被做砸的一环。一个常见的错误是把主对话的全部历史原封不动地塞给每个子智能体——这样一来上下文隔离的好处荡然无存，成本却翻了好几倍。正确的做法是为每个子智能体裁剪出它真正需要的那部分上下文，通常是一段任务描述加上几个关键变量，而不是一整部聊天记录。

5.5 代价与反模式#

多智能体的成本常被严重低估。Token 是量级式放大的——每个子智能体都有自己的系统提示词、工具定义和上下文，跨三个子智能体的一次任务可能是单智能体的五到十倍；延迟叠加，每次交接都是一次完整的 LLM 调用；状态漂移，信息在多次转述中失真；调试困难，出了问题要在多份轨迹里对照着找。其中最该记住的是错误的乘法：单个智能体 90% 的准确率，三个串起来只剩 73%，设计时经常被忽视。

对应的反模式有四个：为了拆而拆、层级过深（三层以上收益极低）、没有总移交次数上限、共享全部上下文（等于放弃了多智能体最主要的收益）。

5.6 什么时候不该用多智能体#

给一组可操作的反向判据。单智能体的工具数量在十个以内且都属于同一领域——不用拆。任务是线性的——用提示链，不用多智能体。对延迟敏感——多智能体的交接开销通常无法接受。预算敏感——先把单智能体的提示词和工具描述优化到位，收益往往比拆分更大。没有可靠的评测手段——多智能体的问题很难靠人眼发现，没有评测就没有优化的抓手，上了也是失控。

一个务实的路径是：先把单智能体做到极限，遇到明确的上下文瓶颈或专业化瓶颈时再拆，并且一次只拆一刀。

6 横切能力#

以下五件事和具体范式无关，但每个范式都躲不掉，而且往往才是决定一个应用能不能上生产的因素。

记忆分短期和长期。短期就是当前会话的对话历史，靠记忆窗口或会话变量承载；长期是跨会话留存的偏好、结论与经验，需要写进知识库或数据库、用时再检索回来。难点在上下文压缩——滚动摘要、结构化提取（只留结论丢掉过程）、外置存储（上下文里只留引用），三者可以叠加。

工具设计的质量往往比模型选择更能决定成败，这一点被严重低估。描述要说清楚什么情况用、什么情况不用，含糊的描述是”调错工具”的头号原因；参数要少而明确，能给默认值就给、能用枚举就别用自由文本；返回值要结构化，失败时要说清发生了什么、建议怎么做，只回一句 error 模型无法判断该重试还是放弃；写操作类工具还要考虑幂等，因为智能体可能重复调用。

人在环：涉及资金、对外沟通、数据删除这类不可逆动作，应该设人工确认。低代码平台上要么把流程拆成两段、确认后再触发第二段，要么用平台的审批节点挂起等待，注意处理挂起状态的持久化和超时。

可观测性与评测——没有评测就没有优化，智能体的失败常常是”看起来还行但其实不对”，抽查发现不了。至少要能看到完整轨迹（每一轮调了什么、传了什么、返回了什么），分环节的指标比端到端指标更有诊断价值。最朴素也最有效的做法是攒一个回归用例集，每次改提示词或流程之后跑一遍——它是唯一能让你安心修改的东西。

成本与延迟靠三招：模型分层（强模型做规划决策、弱模型做执行格式化）、缓存、并行化。另有一条铁律是给所有循环设上限——ReAct 的最大轮次、Evaluator-Optimizer 的最大重写次数、多智能体的最大移交次数。没有上限的循环迟早会给你一张意外的账单。

7 范式到平台的落地映射#

最后把范式落回平台。下表给出每种范式在两个平台上的搭法。

这张表里最值得注意的是最后几行。越靠近谱系右端的范式，低代码平台越难完整实现——因为它们需要的是动态图调度、异步任务管理这类底层能力，而低代码平台的画布本质上是静态图。

这就引出一条选型建议：如果你的需求必须用 LLMCompiler 这类范式才能满足，那说明它已经超出了低代码平台的舒适区，该考虑用 LangGraph 这样的代码框架来写了。 低代码平台的价值区间是从单次调用到 ReAct 加简单多智能体这一段，这一段覆盖了绝大多数业务需求；越过这条线之后，硬用低代码搭出来的东西会既难维护又不稳定。

认清工具的边界，本身也是选型能力的一部分。