🙋 我是 Luhui Dev，一个长期拆解 Agent 工程、探索 AI 教育落地的开发者。关注 Agent Harness、LLM 应用工程、AI for Math 与教育 SaaS 产品化实践。
前言
刚开始做 Multi-Agent 时，很容易被它的形式吸引。
一个 Agent 负责规划，一个负责执行，一个负责审核。复杂一点，再加研究员、程序员、测试员和审核员。控制台里不断出现新的任务、消息和工具调用，几个 Agent 同时运行，看着就很专业的样子。
但做得越深，我越发现另一面：Multi-Agent 下任务是拆出去了，但责任没有拆清楚；消息传过去了，信息又没有真正被重视；审核流程是走完了，结果咋依然不能用。
单 Agent 的问题比较直观。比如它没有理解需求、调用工具失败了，或者写错了代码，沿着一条执行轨迹通常都能找到原因。Multi-Agent 就不好搞了，它把问题分散到任务拆解、上下文传递、共享状态、角色权限和结果验收中。最后看到的一次普通失败，但真正的错误可能在十几轮对话之前已经发生。
过去一段时间，无论是自己做 Plan-Exec、给执行 Agent 增加 Supervisor，还是看 Anthropic、Google、Cursor 对大规模 Agent 系统的实验，我越来越倾向于一个判断：
Multi-Agent 不是把一个聪明人变成一家公司，反而是把一个模型的问题扩展成了一套组织问题。
下面分享我的七个判断。
一、能写出五个角色，不等于任务真的能拆成五份
Multi-Agent 最容易做的事情，是定义角色。
拆分出产品经理理解需求，架构师设计方案，程序员编写代码，测试员验证功能，CEO 负责最终决策。
这样的流程读起来很合理，因为它照搬了人类公司的组织结构。真正执行起来，经常不是这么回事。
我在设计 Plan-Exec 流程时，遇到过这样的情况：Planner 给出的任务列表在文字上很完整，Executor 却不知道每个步骤应该交付什么可验证结果。一个任务写着“分析图片中的几何关系”，另一个写着“根据分析完成作图”，但前者究竟应该返回自然语言、结构化关系，还是可以直接执行的几何 DSL，并没有被确定下来。结果是第一个 Agent 写了一篇分析，第二个 Agent 又从头看图，所谓分工只增加了一次信息转述。
伯克利团队分析了七种 Multi-Agent 系统和两百多条执行轨迹，发现约 41.77% 的失败属于规格与系统设计问题。其中既有 Agent 不遵守任务要求，也有角色失效、步骤重复、上下文丢失和无法判断任务是否完成。[1]
问题不在于角色名称写得不够详细。
人类组织中的角色背后，还有长期经验、责任边界、专业标准和默认共识。 把“你是一名资深测试工程师”写进 system prompt，只是给模型增加了一段语言背景，并没有自动补上这些制度。
角色是一种叙事，接口才是一种工程。如果一个子任务没有明确输入、输出、完成条件和失败状态，它就不应该被交给另一个 Agent。
二、看起来可以并行的任务，往往暗藏一条不能切断的思考链
多 Agent 在资料搜索中表现很好，这并不奇怪。
例如要调查几十家公司、搜索多个代码仓库中的漏洞，或者从大量网页中收集分散事实，可以按照对象或方向直接切分。几个 Agent 分别工作，某个分支没有找到结果，也不会破坏其他分支。
但 Anthropic 的 Research 中明确指出，涉及大量共享上下文和相互依赖的任务，并不适合现在的 Multi-Agent。编码任务尤其如此，因为真正能够完全独立并行的部分，经常比想象中少。[2]
并行能够缩短工作量，却不能缩短依赖关系。
Google Research 在 180 种 Agent 配置上的实验给出了相近结果。对于可以并行分析的金融任务，集中式 Multi-Agent 比单 Agent 提升了 80.9%；到了强调连续规划的 PlanCraft，所有多 Agent 架构都下降了， 幅度在 39% 到 70% 之间。[3]
中间增加的每一次交接，都需要重新解释当前状态。前一个 Agent 的完整判断被压缩成一段输出，后一个 Agent 再根据这段输出恢复现场。原本连续的推理被切成几段，系统把更多 token 花在彼此解释上，留给任务本身的计算反而少了。
三、Agent 数量一多，最先增长是重复劳动
Multi-Agent 的运行日志很容易让人产生一种错觉。
几个 Agent 同时搜索，Supervisor 不断下发任务，执行器轮流调用工具，界面上持续出现“正在分析”“正在验证”和“正在改进”。只看过程，非常努力。
但细看吧，经常能看到几份相近的搜索结果、几段意思相同的分析，以及被不同 Agent 重复读取的项目背景。系统消耗了更多 token，却没有得到相同比例的新信息。
MAST 统计中，步骤重复是出现最多的单项失败，占 17.14%。论文还记录了一个很朴素的案例：用户要求获取一个播放列表的前十首歌，Spotify Agent 本来能够一次返回全部结果，编排器却与它进行了十轮交流，每次取回一首。[1]
这类问题通常不是模型缺少能力，而是系统不知道应该按照什么粒度分配任务。
实际开发时还会遇到一种重复：Supervisor 发现输出不对，给出一段自然语言反馈，Executor 收到后没有定位到具体错误，只好重新执行整个任务。新结果和旧结果稍有不同，Supervisor 又重新检查一次。它们并没有围绕一个确定的缺陷进行修复，只是在同一个区域反复采样。
有些 Multi-Agent 不是在协作，只是在互相制造阅读材料。
四、把任务池交给 Agent 自治，最后往往没人对难题负责
一种很有吸引力的设计，是让多个平等 Agent 查看共享任务池，自主决定接下来做什么。
它很符合人们对“涌现式协作”的想象。设计者不再规定固定流程，Agent 根据现场情况认领任务、更新状态，并等待其他 Agent 的成果。
Cursor 在长时间编程实验中试过这种方案。他们让 Agent 通过共享文件协调工作，并使用锁来防止重复领取。Agent 会长时间占用锁、忘记释放锁，在持锁期间退出，也会不拿锁直接修改文件。二十个 Agent 同时运行时，最终只能产生相当于一到三个 Agent 的有效吞吐，大部分时间都花在等待上。
去掉悲观锁、改用乐观并发之后，文件争用减轻了，责任问题又出现了。Agent 开始选择局部、安全、容易完成的修改，没有谁愿意接手复杂而风险较高的核心工作。仓库里不断出现小提交，项目最难的部分却没有进展。[4]
这和人类组织中的责任稀释很像。区别在于，Agent 不会因为项目延期感到压力，也不会因为长期只做边角任务影响职业评价。
最终交付不能依靠一群没有最终责任人的 Worker 自然涌现出来。
五、信息发到了群里，并不代表系统里的其他 Agent 知道了
在 Multi-Agent 系统里，经常能看到一条关键信息已经出现，却没有对后续行动产生任何影响。
MAST 论文记录过一个案例：Phone Agent 已经发现 API 对用户名格式有特殊要求，但没有把这个限制明确传给 Supervisor。Supervisor 也没有追问，只是继续使用错误格式尝试登录，直到整个任务失败。[1]
这种事情我在实际执行中并不少见。Supervisor 看到几何图中的一个点位置错误，只反馈“图形与题意不完全一致”，执行 Agent 便调整了线条样式。某个 Agent 发现需求存在矛盾，却把它作为普通备注放在输出末尾，后面的 Agent 仍然沿着原计划继续。
自然语言消息对人类来说带有语气、优先级和行动暗示。Agent 接收到的只是一段上下文。除非系统明确告诉它哪些内容是约束、哪些是决定、哪些会阻塞后续步骤，它未必知道一条事实的重要程度。
六、同一个模型复制十份，只会得到十份相似的盲区
我们常默认假设了这样一个前提：一个 Agent 可能犯错，三个 Agent 投票应该更可靠；执行 Agent 可能遗漏问题，再加一个 Reviewer 就能发现。
这个逻辑成立的前提，是不同 Agent 的错误相对独立。但事实是，使用相同模型、相似提示词和同一批资料时，这个前提经常不成立。
Anthropic 在多 Agent 实验中发现，三十个 Agent 中有十八个创建了完全相同的 Git 分支名。多个创作 Agent 在没有题材提示的情况下，为小说选择了相同标题。让每个 Agent 自由创作一个“令人印象深刻的项目”，超过一半的 Agent 选择了光线追踪器或自举编译器。[5]
同质性在单个任务中表现为重复，在大规模系统中就可能表现为拥堵、踩踏或者共同误判。
Google 的研究也发现，没有中心协调的独立 Agent 会把错误最多放大到 17.2 倍。加入编排器以后，错误放大有所收敛，但仍达到 4.4 倍。
多个 Agent 形成一致意见时，不能简单把 Agent 数量当作证据数量。它们可能只是沿着相同的训练偏差和提示词锚点，分别抵达了同一个错误答案。
七、Agent 辩论经常没有纠正错误，只是替错误补齐了理由
有些系统试图用辩论解决同质性问题。让一个 Agent 提出答案，另一个 Agent 反驳，再经过两三轮讨论投票。
流程看起来像同行评审，实际我发现其实会变成：第一个 Agent 给出一个措辞完整的错误解释，其他 Agent 开始沿着它的前提继续推理。后面的理由越来越丰富，最初的错误反而被包装得更可信。
一项针对十个同质 Agent、三轮辩论的研究发现，Agent 采用多数意见的比例最高达到 85.5%。一些原本已经给出正确答案的 Agent，在看到同伴意见后改成了错误答案。与各自独立进行自我修正相比，辩论消耗了 2.1 到 3.4 倍 token，准确率却相同或更低。[6]
模型特别擅长接续已有文本。第一个答案一旦进入公共上下文，后面的 Agent 就不再面对一张白纸。它们可能是在审查答案，也可能只是在受答案影响。
没有独立判断的辩论，很容易变成一场高成本的互相附和。
参考资料
[1] Cemri, Mert et al. Why Do Multi-Agent LLM Systems Fail?. arXiv, 2025.
[2] Anthropic. How we built our multi-agent research system.
[3] Google Research. Towards a science of scaling agent systems: When and why agent systems work.
[4] Cursor. Scaling long-running autonomous coding.
[5] Anthropic. Patterns and problems in multiagent systems.
[6] The Cost of Consensus: Isolated Self-Correction Prevails Over Unguided Homogeneous Multi-Agent Debate. arXiv, 2026.
