面试官：你在简历里写了做过 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，评论区点单。我们，下篇见
热门跟贴