多 Agent 一定比单 Agent 好吗？什么时候反而是灾难？
谁在问：二三面反直觉题；被多 Agent 坑过的技术负责人最爱问，用来筛掉跟风架构师
口语化问法
- 都说多智能体是趋势，你觉得它一定比单 Agent 强吗？
- 你见过多 Agent 做砸的例子吗？砸在哪儿？
- 什么样的任务你打死也不会拆成多个 Agent？
考察意图
这题几乎不考知识，只考判断力和经历。面试官在验四层：
- 敢不敢给反向结论。 顺着"多 Agent 是趋势"说下去的人，直接出局——他问这题就是想听反面。
- 说不说得出失败的机理。 "多 Agent 更贵更复杂"是常识；能讲清交接损失是乘法的、假设冲突无法在合成阶段调和才是做过。
- 知不知道很多拆分其实是组织原因。 按团队边界拆 Agent 而不是按任务边界拆，是 2026 很常见的架构病。
- 会不会用数据把架构争论收敛。 这题的终点是"怎么证明该不该拆"，不是"我觉得不该拆"。
参考答案
60 分答案（及格线）
不一定，而且默认应该是单 Agent——多 Agent 需要理由，单 Agent 不需要。
多 Agent 真正成立的场景只有几种：子任务互相独立且并行有价值、各自上下文会互相污染、输入类型差异大到需要不同工具集、或者需要一个有客观信号的评审角色。除此之外，拆分带来的是净损失。
灾难场景主要是：
- 任务需要全局一致的判断（写一份连贯的方案、做一个整体架构决策）——拆了必然割裂；
- 子任务强耦合，需要频繁交换中间结果；
- 有写副作用且需要事务性，多个 Agent 并发改同一份状态；
- 任务本身很短，协调开销大于收益；
- 团队还没有 trace 和评测能力——多 Agent 会让可观测债务直接翻倍。
90 分答案（有生产经验的回答）
补三层机理，这是本题真正的分水岭。
1. 交接损失是乘法的，而且静默。 Agent 之间用自然语言交接，本质是一次有损转述。一条信息经过三次转述，细节、限定条件、不确定性会层层丢失——关键是它不报错。微服务之间的 API 有 schema、字段少了会失败；Agent 之间少传了一句"用户预算只有五万"，下游会自信地继续往下做。链路越长，损失按乘法累积。
2. 假设冲突在合成阶段是无解的。 各个 worker 在信息不完整时会各自做出看起来都合理但互相矛盾的假设——一个按"面向国内用户"设计，另一个按"要支持多语言"设计，两份产出都自洽，合成时却无法调和。合成器要么强行圆场（产出一份自相矛盾的东西），要么丢掉一边。这类问题不是提示词能修的，根因是拆分时没有把共享前提广播下去。
3. 责任分散让排障变成扯皮。 单 Agent 出错，你知道该改哪段提示词、哪个工具。多 Agent 出错，每个 Agent 单看都"没做错"，问题出在缝隙里。加上轨迹空间爆炸，回归测试基本失效——这才是多 Agent 最贵的隐性成本，比 token 贵得多。
4. 很多拆分的真实原因是组织，不是任务。 三个团队各做一个 Agent，接口就按团队边界切——这是康威定律的 AI 版。任务边界和团队边界不重合时，拆出来的系统必然在缝隙处漏水。面试里能主动点出这条的人很少，但它在真实公司里的解释力极强。
5. 2026 的形势判断（截至 2026-08）：模型上下文更长、指令遵循更稳、工具调用更准，单 Agent 的天花板一直在抬高。早期靠多 Agent 绕开的问题（窗口不够、角色混乱、一个提示词塞不下太多职责）现在多数能用单 Agent 加好工具集解决。所以我看到"多 Agent 架构"时的第一反应是问它是哪一年设计的——很多是 2024–2025 的遗留结构，现在重估会发现拆分理由已经不成立了。
6. 怎么把争论收敛成实验：拿单 Agent 做 baseline，比三条线（成功率、P95 时延、单位成本）；再把多 Agent 的失败案例做归因分类，看有多少属于"交接损失"和"假设冲突"这类拆分本身引入的错误。如果这类占比高，说明拆分是净负——这个数据比任何架构辩论都有说服力。
追问链
自然语言交接有损，那微服务之间传数据有什么不同？
期望三点：① 契约 —— 微服务有schema，字段缺失显式失败；自然语言少传一句下游照跑，静默失真；② 语义精度，结构化字段含义唯一，转述引入歧义；③ 可验证性，「约束传全了没」没法断言。缓解是结构化交接，但要坦白悖论：越结构化越像 workflow，自治价值越小信号点出「静默失真」和那个结构化悖论 → 真思考过；答「都是传数据，差不多」→ 没意识到接口精度的量级差异怎么向团队证明「这个任务不该拆」？
期望靠两组数据：①baseline对照 —— 单 Agent 配同样好的工具集（不许拿稻草人）比多 Agent，看成功率、P95、单位成本；② badcase 打标签：交接丢信息／假设冲突／合成抹平属拆分引入的错误，占比高即净伤害。同模型同工具、只换控制结构、重复多次看分布信号强调「别拿没优化的单 Agent 当稻草人」并做失败归因分类 → 做过公正对照；只答「跑一下看哪个效果好」→ 实验设计不严谨组织或合规原因非拆不可，怎么把伤害降到最低？
期望五条：① 广播共享前提 —— 原始需求、硬约束、已确认决定原样发给每个 worker，不转述（假设冲突的根因）；② 结构化交接契约：固定字段 + 置信度 + 未完成项 + 证据句柄，禁纯自由文本；③ 结构扁平，减少交接跳数；④ 单点写，其余只读；⑤ 统一 trace 与关联 id信号把「广播共享前提」排在第一位 → 抓到了假设冲突的根因；只答「加强各 Agent 之间的沟通」→ 方向反了，沟通越多越糟多 Agent 的评测和单 Agent 有什么不同？
期望三点：① 必须分环节评 —— 分解质量、单个 worker 质量、合成保真度各自可测，只看端到端会混成一团，改都不知道改哪；② 轨迹空间爆炸，固定用例覆盖不了，只能抽样 + 重复跑取分布；③ 要有拆分专属指标：交接保真度、假设冲突率、合成前后信息损失率。成本看分布不看均值信号提出「交接保真度／假设冲突率」这类拆分专属指标 → 评测过多 Agent；只答「跟单 Agent 一样看成功率」→ 端到端指标掩盖了环节问题CTO 看了竞品的「多智能体平台」宣传，要三个月内把单 Agent 改造成多 Agent，你怎么答？
期望两天尽调（文档、API、招聘 JD）：对外叫多智能体的，内部常是 router 分诊或 workflow → 对外叙事与内部架构解耦 → 一期 router 分诊，二期挑能并行的场景做 orchestrator-workers 试点带 baseline，三期看数据定 → 风险清单让 CTO 签字：真瓶颈是评测跟不上，附成本倍数与回滚，留单 Agent 兜底信号先尽调、把叙事与架构解耦、把评测列为首要瓶颈 → 能向上管理；硬顶「多 Agent 没用」或全盘接受却说不出风险 → 都让人担心组织生存能力
评分要点
- 明确给出反向结论：默认单 Agent，多 Agent 需要理由
- 说得出交接损失是乘法且静默的，并能对比 API 契约
- 说得出假设冲突在合成阶段无解，根因是共享前提没广播
- 提到责任分散与轨迹空间爆炸导致排障和回归失效
- 列得出灾难场景（全局一致判断、强耦合、事务性写、短任务、缺可观测能力）
- 加分：识别"按团队边界拆 Agent"这一组织性根因
- 加分：知道 2026 模型能力提升在抬高单 Agent 天花板，旧拆分理由需重估
- 加分：用 baseline + 失败归因分类把架构争论收敛成数据