我说子 Agent 挂了会重试，面试官追问了一句，整个房间安静了

面试官：你在简历里写了做过 Multi-Agent，讲讲具体怎么做。

我：Supervisor 把任务拆成几个子任务，分给不同的 Agent 各自去跑。

面试官：那子 Agent 挂了怎么办？

我：……会重试。

面试官：重试几次？等多久？重试还失败，整个任务就失败了吗？

我：…………

（此处房间安静了大概五秒）

面试官又问了一个：

你的 ResearchAgent 说这家公司营收在增长，AnalysisAgent 说营收在下滑。WriterAgent 怎么合并？

我没接上来。

他最后说了一句：

你说的 Multi-Agent，只是把几个 LLM 调用摆在一起，不是真正的 Multi-Agent 系统。

我在那之后认真想了很久。

因为我意识到，那三个追问其实是在问同一件事：这个系统有没有「结构」，还是只有「分工」。

分工是把活切开，结构是切完之后还知道谁说了算、失败了怎么办、结果怎么被验证。

只有分工没有结构的系统，本质上是一个跑得很快、但没人知道它什么时候在胡说的流水线。

同一个项目，我们自己测过

那次面试之后我认真想了两天。

因为我在自己项目里，确实把同一套东西在银行项目上跑过。

「拓业智询」——50 家企业做 A/B 测试，5 名客户经理盲评打分。

维度

单 Agent

Multi-Agent

耗时

45 秒

18 秒

上下文

超过 32000 token

各子 Agent 独立，最长不超 8000 token

报告得分（盲评）

72 分

89 分（+23.6%）

Multi-Agent 是赢的，赢得很明确。

但我看完自己的配置文档，第一反应不是开心，是后怕。

因为我们踩过的坑，和面试官问的，是同一批。

我们怎么处理「两个 Agent 说法相反」

真实场景里最容易出事的一种情况：

ResearchAgent 走新闻检索，判断某企业营收向好；AnalysisAgent 读财务报表，发现应收账款周转率下降、实际现金流紧张。

两个结论方向完全相反。

我们最后是这么裁定的，写死在 Prompt 里：

财务数据 > 新闻检索。

就这一条，不让 LLM 自己决定。

因为让模型自己权衡，它会根据上下文的长短、哪个证据写得更好看，来选一个立场——这不是推理，这是挑一个听着顺耳的说法。

所以我特别理解那个面试官为什么追问：能答出「会重试」的人很多，能答出「谁说了算」的人很少。

顺便说一句，那次测试里最好看的其实是上下文那一栏。

单 Agent 要扛 32000 token 以上，Multi-Agent 每个子 Agent 独立，上下文最长不超过 8000 token。

这一点比「快了 2.5 倍」重要得多。因为上下文越短，模型在这个环节出错的概率越低，报告质量才涨得起来。

多 Agent 的第一个真实收益不是快，是让每个环节都只看见自己该看见的东西。

重试、降级、以及那句「数据缺失，仅供参考」

我们给的错误处理参数是：

• 重试上限 2 次，间隔 1 秒
• 全部失败 → 降级为
• status="degraded"
• WriterAgent 强制标注「数据缺失，仅供参考」

注意最后一条。

失败不是最可怕的，失败之后假装没失败才可怕。

一个「降级」标记的显式声明，好过一份看起来完整、但里面有两个事实是编的报告。

这里还有一个反直觉的点值得说。

很多系统不是靠「不失败」活下来的，是靠「失败得足够明显」活下来的。

我们把降级状态一路透传到最终报告里，用户看到的是「本次数据不完整」，而不是一份看起来煞有介事的结论。

并行也不是越多越好

顺手把并行度也测了。

方案

耗时

顺序执行

24 秒

3 个并行

9 秒

提速 2.7 倍，不是 3 倍。

再往上加就不行了：2-3 个是最优区间，4-5 个开始 API 限速，6 个的总耗时反而比 3 个更长。

这个数据我第一次看到的时候笑了一下——因为它太像现实了。

人手加到某个点以后，不是产出变多，是所有人都在等。

等限速恢复，等接口响应，等上游那个最慢的先跑完。

并行的收益永远有一个上限，而那个上限不由你决定。

这也是我经常劝人的一句：先问「我这个任务里哪几步真的互相独立」，再问「我能开几个并行」。顺序反了，就会得到一个更慢、还更难调试的系统。

学术界的数据，比这个反常识得多

后来我去查了几篇论文，结果比上面这些还扎人。

Meta-Team（arXiv 2605.29790）：三层协作演化带来的提升，平均比「不进化的多 Agent 系统」高 6.6%。

但同一个实验里还有另一行结果：

初始手工设计的多 Agent 系统，在 9 个测试中有 6 个，不如单个 Agent。

**EvoChamber（arXiv 2605.11136）**更直接：

去掉协作进化机制后，20 个 Agent 的团队和 1 个 Agent 表现完全没差别。

这两篇拼起来是同一句话：

没有协作机制，多 Agent 不是加法而是减法。多 Agent 的价值 100% 来自协作机制本身，堆 Agent 数量本身不产生任何价值。

加人不等于加价值。

那「协作机制」到底指什么

拿一个更成熟的领域打个比方。

ReAct 论文在 ALFWorld 环境里的消融结果：有了动作空间（可以调用的具体动作、可观测的环境反馈）之后，成功率比纯推理高 34 个百分点。

同样是「让模型多想」vs「给模型手」。

差别不在想得多深，在于有没有一个真实的、能被验证、能被纠偏的接口。

多 Agent 里的协作机制，就是这个接口：

• 谁给谁派活（不是平铺并发）
• 谁对冲突做裁定（不是模型投票）
• 失败怎么被标记和降级（不是悄悄吞掉）
• 上一个环节的结果，怎么变成下一个环节能真正读懂的输入

这四条，一条都没有的话，那就是面试官说的「把几个 LLM 调用摆在一起」。

我想再补一个更简单的自检方法。

把 Supervisor 的那段派活逻辑写成流程图，如果你画出来发现所有箭头都是平行的、没有任何一个节点在做判断——那大概率不需要多 Agent，你需要的只是一个更长的 Prompt。

真正的协作机制里，一定存在一个「不生产、只负责裁决或校验」的角色。

我们的项目里，财务优先于新闻这条规则，就是这样一个角色的全部内容。

它一行代码都不写，没有产出任何新信息，但整个系统的可信度都挂在它身上。

结尾：我给自己留了三个判断题

不是问「该不该上多 Agent」，而是三个更具体的问题。你现在就可以对着自己的项目问一遍：

**第一问：我的子任务之间，有没有一条写死的裁定规则？**如果没有，冲突裁决就是模型在猜。

**第二问：某个 Agent 全部失败之后，谁负责在最终产物里把这件事说出来？**如果没有，你已经造了一个会编的流水线。

第三问：我上一次加 Agent，是因为活变多了，还是因为我觉得「多 Agent 听起来更高级」？

第三条最难答，也最值。

然后是我自己要答的那个：

我上一次给 Agent 数量做加法，是因为它真的变强了，还是因为我低估了验证的成本。

顺便说一句，我写这篇的时候顺手去搜培训机构的广告，看到一句很实在的话：

把一个项目部的能力列成一个人的课程大纲，再把它卖给零基础学员，这才是我真正反对的东西。

多 Agent 这个词现在也差不多。

它该被当成一道工程难题来解，不该被当成一个简历上的名词来背。

这是「数字生命岐伯」第 9 问。我，野慢，广东，25岁。白天在大厂做AI产品，晚上被AI教做人。今天这题我替你们问过了，坑也替你们踩了。想让我测哪个AI，评论区点单。我们，下篇见