> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 多 Agent 值不值得拆：三种模式，和一次真实的翻车 - URL: https://www.hubwiz.com/blog/when-to-split-multi-agent-three-patterns/ - Published: 2026-11-07T09:08:32.000Z - Updated: 2026-11-07T09:08:31.000Z - Description: 先把一个 agent 做对。只有当某一段确实需要自己的指令、工具或速度时才拆；拆完以后，把力气花在交接检查、跳数上限和真样本评测上——我自己的系统就栽在这三处。 - Author: admin - Tags: AI Agent, 多 Agent, 架构模式, 评测 **我做过的大多数 AI agent，都只是一个 agent。** 今年早些时候我做了个晚餐推荐器。你告诉它你在哪儿，它查天气，然后推荐适合的食物。在雨季的钦奈，这意味着热茶配 vada 或 bajji；在炎热的下午，则是酪乳或嫩椰子水。它的内部就是一个模型加三个工具（定位、天气、餐厅搜索），再对步数设个上限。它工作得挺好。把它拆成几个 agent 只会更慢、更贵，而且毫无收益。 所以这不是一篇"你需要多 agent"的文章。它讲的是：什么时候把一件工作拆给多个 agent 真的有帮助、人们通常的三种拆法，以及哪里会出问题。我会一直用同一个晚餐问题讲到底，因为它足够小、能跟得上。 ## 什么是多 agent 系统 一个 agent 是能使用工具、并自己决定下一步的 AI 模型。多 agent 系统就是若干个这样的东西，各自负责更窄的工作，在彼此之间传递工作。 想想厨房。一个厨师能做完一顿饭。忙的餐厅会拆开：有人在烤炉，有人在酱汁，一个主厨在喊单。周五晚上五十桌的时候，这很好；在家做一顿晚饭，这就是过度设计。 **什么时候拆有帮助：** - 工作的不同部分需要完全不同的指令或工具。 - 各部分可以同时跑，比如一次查五个主题。 - 你想单独测每一部分。 **什么时候保持一个 agent：** - 一个带好工具的 agent 已经能完成这件事。 - 速度和成本比结构更重要。 - 你还说不清每个 agent 该拥有什么。 ## 模式一：流水线 一条装配线。每个 agent 做一步，把结果交给下一个，顺序永远不变。 当你**在开始之前就能把步骤写成清单**时，用它。这是最容易测的模式，因为每一步都有明确的输入和输出。 注意：它很僵硬。如果第三步有时候需要退回第一步，你就会开始打补丁加特例，直到它悄悄变成下一种模式。 ## 模式二：编排者 主厨。一个主导 agent 读请求、决定需要什么帮助、把工作发出去、再把答案拼起来。帮手只跟主导者说话，彼此之间从不交流。 Claude 和 ChatGPT 这类工具里的"深度研究"功能用的就是这个模式：主导 agent 做计划，几个帮手同时从不同角度检索，主导者写报告。 当你**知道一个请求需要哪几类帮助，但细节取决于请求本身**时，用它。 注意：一切都流过主导者。它计划得不好，每个帮手都会继承这个错误。 ## 模式三：黑板 一块共享白板。没有老板。agent 读板上的内容，加上自己知道的，在有有用信息时介入。 当**没人能事先知道步骤**时，用它。调试是经典场景：一个 agent 提出一个原因，另一个去找证据，第三个挑毛病，下一步做什么取决于他们找到了什么。 注意：没有人拥有计划。这使它成为最难测、也最容易卡在循环里的模式。 ## 试一试：用三种方式跑同一个晚餐请求 原文这里有一个可交互的演示：选一个模式、逐步走完，然后故意弄坏它——给天气 agent 一个过期的读数，或者让 agent 之间互相把活推回去。先看没有护栏时会怎样，再打开护栏。 它标着"这是脚本化的演示，不是真 AI；这些步骤只是在复现真实系统里这些模式的行为"。 ## 真正会坏的地方：Stormwise 的教训 我的另一个项目 Stormwise 是一个基于 Claude 的极端天气助手。它的核心是一条流水线：先拿到官方警报，然后让模型带着这些警报回答你的问题。我用 117 个来自真实美国国家气象局警报的案例做了评测（完整报告在 arXiv 上）。**只有两个阶段，它还是教给了我关于这类系统如何失败的大部分知识。** **1\. 坏数据会旅行，而且到达时看起来像事实。** 气象部门会发布测试警报。我的流水线把其中一些当成了真实警告收进来，模型——很合理地——相信了它们。错误不是模型犯的，是它前面那一步犯的。有多个 agent 时这就是默认状态：agent B 分不清 agent A 的猜测和事实。**在每一次交接处用纯代码检查数据。** **2\. 正确的数据胜过聪明的提示词。** 在拿不到警报的情况下，助手在 69 个案例里有 26 个（38%）告诉用户"天气平静"——而那正是有生效警告的时候。加一句"如果看不到官方警报就承认"反而更糟：31/69（45%）。**把真实警报给进去、提示词写得很朴素：零。** 把正确的信息送到正确的步骤解决了问题，提示词没有。 **3\. 预算在最难的案例上崩掉。** 一个对日常问题足够的 token 预算，在复杂案例上不够用——而在风暴里，复杂的恰恰是最要紧的。你需要预算，但要提前决定预算用完时怎么办：**给一个简短、安全的答案，而不是一个做到一半的答案。** **4\. 你的自动检查器也可能错。** 我一开始用一个简单的模式匹配脚本测量"错误的安抚"，它漏掉了 57 个真实案例里的 53 个，还指向了相反的结论，最后我手工读并标注了全部 342 个回答。**如果一个 agent 检查另一个 agent，那就去检查那个检查器。** 还有两个问题，在任何"agent 之间能把活推回去"的系统里都会遇到：循环和成本。循环就是你在演示里看到的那种——每个 agent 的行为都很合理，系统却在原地打转。成本更安静：我的晚餐 agent 从第一天就有步数上限、从没失控过，但我还是把它下线了，因为 API 账单超过了一个副业能承受的范围。**多一个 agent，就多一次调用，每一次都是。** ## 我第一天就会加的护栏 这些都不聪明。它们是放在 agent 外面的纯代码。 - **检查每一次交接。** 校验一个 agent 交给下一个的东西：格式、新鲜度，以及它是否讲得通。 - **限制跳数。** 如果一个任务在 agent 之间来回弹了几次，停下来，去问人。 - **每个请求一个预算。** 在一个地方记账，而不是每个 agent 各自记，并提前决定降级答案。 - **记录 agent 之间的每条消息。** 一次运行出问题时，你会想一步一步重放它。 - **用真实案例测试。** 建一批真实样本，并手工抽查你的自动评分。 ## 一个快速选择法 - 一个带工具的 agent 能做完吗？→ 用一个 agent，到此为止。 - 你能把步骤写成清单吗？→ 流水线。 - 你知道需要哪几类帮助，但不知道细节？→ 编排者。 - 下一步取决于你发现了什么？→ 黑板，但要加严格限制。 ## 常见问题 **什么是多 agent 系统？** 多 agent 系统是若干个 AI agent，各自负责更窄的工作，在彼此之间传递工作。agent 是一个能使用工具、并自己决定下一步的模型。不是一个 agent 干所有事，而是可能有一个收集信息、一个核对信息、一个写最终答案。 **什么时候该用多个 agent 而不是一个？** 从一个 agent 开始。只有当工作的某些部分需要明显不同的指令或工具、某些部分可以同时跑、或者你需要分开测各块时，才拆。每多一个 agent，就多出模型调用、成本和新的失败方式。 **主要的多 agent 模式有哪些？** 流水线（按固定顺序执行，像装配线）、编排者-工作者（主导 agent 派发任务并汇总结果）、黑板（agent 读写同一份共享工作区，直到答案就绪）。流水线最容易测；黑板最灵活，也最难控制。 **多 agent 系统通常会在哪里出问题？** 一个 agent 的坏数据被下一个当成事实、agent 之间来回推活形成循环、每多一次调用成本就涨、预算或自动检查在最难的案例上失效。这些都要靠 agent 外面的纯代码来修：每次交接都检查、限制跳数、每个请求一个预算、用真实样本评测。 ## 短版本 从一个 agent 开始。只有当某一部分确实需要自己的指令、工具或速度时才拆。然后把你大部分的精力放在那些无聊的部分上：交接检查、限制、真实评测。我的系统就是在这里失败的，你的也会。 如果你接下来要把 agent 接进真实产品，可以看看 MCP 怎么把 AI agent 接进你的产品，以及怎么把 AI 功能发布到生产环境。 ## 我们的整理：三种模式的"最小可测产物" 原文把三种模式讲清楚了，但没说清"拆之前先准备什么"。补一张对照表： | 模式 | 何时成立 | 最小可测产物 | 一上手就该写的护栏 | | --- | --------------- | ------------------ | ------------------------ | | 流水线 | 步骤能提前写成清单 | 每一步的输入/输出 schema | 交接处校验格式与新鲜度；步骤回退要显式建模 | | 编排者 | 知道需要哪类帮助，细节随请求变 | 主导者的计划 + 每个帮手的任务边界 | 计划先经人批准；帮手之间禁止直连；总预算单点记账 | | 黑板 | 没人能事先知道步骤 | 板上的事实与假设分开存 | 跳数上限 + 到点停机问人；同一事实不得重复写入 | 再补两条原文只在例子里提过、但最值钱的经验： **一、交接处是唯一必须写代码的地方。** Stormwise 那条 38% → 0 的对比（有无真实警报）说明：模型"知道"自己有盲区并不会让它变准（加了提示词反而升到 45%），把数据送对才会。所以别在提示词里叮嘱"注意数据质量"，在交接处写校验。 **二、自动评分先被你手测一遍。** 那个漏掉 57 个案例里 53 个的模式匹配脚本，如果没被人工复核抓出来，整个评测结论是反的。花几个小时手标一批样本，比换更贵的模型有用。 原文：[Building a Multi-Agent System: 3 Patterns, Explained Simply](https://kadhar.dev/blog/multi-agent-systems-from-scratch?ref=hubwiz.com)（Kadhar，2026-06-08，10 分钟阅读） 本文由汇智网 · Software 2.0 完整编译，转载请注明出处。 > **这是「Agent / MCP / 自动化」专题的一部分。** 完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/) **相关阅读**：[多 Agent 团队到底划算吗：50 个应用的实测](https://www.hubwiz.com/blog/do-agent-teams-pay-off/) · [Triglav 多 Agent 编排：41 个任务、96 轮评审的复盘](https://www.hubwiz.com/blog/triglav-multi-agent-orchestration/)