🙋
我是 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.