AI Agent

多 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	交接处校验格式与新鲜度；步骤回退要显式建模
编排者	知道需要哪类帮助，细节随请求变	主导者的计划 + 每个帮手的任务边界	计划先经人批准；帮手之间禁止直连；总预算单点记账
黑板	没人能事先知道步骤	板上的事实与假设分开存	跳数上限 + 到点停机问人；同一事实不得重复写入