> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 多智能体编程为什么会失败 - URL: https://www.hubwiz.com/blog/why-multi-agent-coding-fails/ - Published: 2026-08-12T05:39:32.000Z - Updated: 2026-10-13T15:49:47.000Z - Description: 工程问题不是我们能把多少智能体塞进一个软件交付工作流。而是：每增加一个智能体，是否贡献了足够的独立价值，来证明它创造的新的故障面是值得的。 - Author: admin - Tags: AGENT, #Import 2026-10-14 14:41 我最近围绕一个虚拟工程团队构建了一套软件交付系统。不同的智能体可以分别负责架构、实现、功能测试、非功能测试、审查和交付协调。这种分工是有用的，因为它防止了一个智能体对自己工作的每一项重要工程判断都一手包办。 但随着系统不断演化，另一个问题变得越来越明显。每增加一个角色，也就引入了另一次交接、对当前状态的另一种解读、另一个需要维护的上下文，以及另一次两个智能体意见相左、重复劳动或基于不同版本现实行事的机会。 增加智能体并不只是增加了能力。它增加了**协调边界**。 这很重要，因为多智能体系统常常被讨论成能力出众的编程智能体之后的自然下一阶段：一个智能体变成一支团队，专门角色涌现，更多工作在并行中完成。近期研究揭示了一幅更复杂的图景。当工作真正可分解、且智能体贡献独立能力时，多智能体系统可以胜过更简单的方法。当协调本身成为问题的一部分时，它们也可能变得更慢、更贵、更不可靠。 因此，工程问题不是我们能把多少智能体塞进一个软件交付工作流。而是：每增加一个智能体，是否贡献了足够的独立价值，来证明它创造的新的故障面是值得的。 ## 1、许多多智能体失败都是协调失败 这个领域最有用的实证研究之一是 NeurIPS 2025 论文 [多智能体 LLM 系统为什么会失败？](https://proceedings.neurips.cc/paper%5Ffiles/paper/2025/hash/b1041e52d3be19f0a9bc491657488e4a-Abstract-Datasets%5Fand%5FBenchmarks%5FTrack.html?ref=hubwiz.com)。研究人员研究了流行多智能体系统超过 1,600 条轨迹，开发了一个包含 14 种失败模式的分类法。他们把失败归为三大类：规范与系统设计问题、智能体间错位，以及验证或终止问题。 这个分类很重要，因为许多失败最好不被理解为某个个体模型给出了糟糕答案。它们源于原本有能力的智能体之间的交互。 考虑一个相对简单的软件故事，它有一条含糊的验收标准。实现智能体可能以一种方式消解含糊之处，而 QA 智能体假设了另一种方式。审查者随后可能基于又一种解读来评估实现。三个智能体可能推理得都很称职，但系统仍然失败，因为没有哪个组件对未解决的需求拥有权威所有权。 同样的模式也出现在角色边界上。两个具备实现能力的智能体被授予重叠范围时，可能都认为某个共享模块需要修改。一个被允许修复代码的审查者可能逐渐变成另一个开发者。一个也被允许重新设计解决方案的协调者可能重复架构师的工作。问题不在于缺乏智能。而是权威定义得不够充分。 完成（completion）是另一个边界。实现智能体可能因为代码能编译就报告任务已完成。QA 智能体可能认为在行为场景通过之前任务都不算完成。交付控制器可能要求 CI、审查和回滚证据。如果没有共享的就绪定义，"完成"就成了另一个概率性判断。 正是在这里，熟悉的软件工程思想变得惊人地相关。成熟系统已经区分了规范与实现、作者与审查者、当前状态与过期状态、本地完成与发布就绪。多智能体系统对这些区分的需求至少与人类团队一样大。 ## 2、更多智能体可能让系统更糟 反对无差别智能体扩张的最有力论据来自 Google Research 2026 年的研究 [迈向智能体系统扩展的科学](https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/?ref=hubwiz.com)。研究人员评估了跨多种架构和任务类型的 180 种智能体配置。在一个高度可并行的任务上，集中式多智能体协调比单智能体基线提升了 80.9% 的性能。然而在一个顺序规划任务上，他们测试的每一种多智能体架构表现都更差——差了 39% 到 70%。独立式多智能体系统对错误的放大也明显大于集中式架构。 对软件工程来说，这里有一个有用的启示：**多智能体架构是一个工作负载设计决策，而不是一个成熟度等级。** 有些软件工作天然可分解。几个独立的测试失败可以同时调查。一旦存在稳定的实现，文档、性能分析、安全审查和行为验证就可以独立进行。大型研究或迁移任务可能包含多个可分离的工作流。 另一些任务则高度顺序化。一个 schema 决策约束了 API，API 约束了实现，实现又改变了测试。在这些依赖关系尘埃落定之前就启动多个智能体，并不会创造有用的并行。它创造的是日后必须协调的投机性工作。 Anthropic 在一个特别具体的实验中遇到了这种区分。2026 年，一支由 16 个 Claude 智能体组成的团队被用来构建一个约 10 万行的 C 编译器，能够为多种架构编译 Linux。当智能体可以认领不同的失败测试或独立的兼容性目标时，并行运转良好。但当他们遇到一个紧密耦合的 Linux 内核问题时，许多智能体汇聚到同一个障碍上，开始互相覆盖对方的修改。直到问题本身被分解、让智能体再次能够独立工作，进展才恢复。 即使并行有效，它也有经济成本。Anthropic 报告称，其多智能体研究系统消耗的 token 大约是普通聊天交互的十五倍，并特别指出许多编程任务包含的真正可并行分支比研究任务少。 因此复杂性需要一个基线。 2024 年的 [Agentless](https://arxiv.org/abs/2407.01489?ref=hubwiz.com) 论文是一个更早但仍然有用的反例。研究人员没有构建高度自治的软件工程智能体，而是使用了一个相对简单的三阶段流水线：定位、修复和补丁验证。在当时使用的基准上，这个刻意受限的系统胜过了与之对比的开源自治智能体，同时保持了低成本。绝对的基准结果如今已经过时；工程教训则没有。一个更复杂的智能体架构应该证明它额外的自治确实换来了什么。 一个智能体应当赢得它的协调成本。 ## 3、用工程控制取代协调提示词 当我最初开始思考多智能体协调时，很容易想通过指令来解决许多问题：告诉智能体尊重角色边界，要求审查者保持独立，告诉并发工作者不要触碰相同的文件，并提醒每个人检查最新状态。 指令是有用的，但对于决定正确性的属性来说，它们是薄弱的强制执行机制。 ![None](https://www.hubwiz.com/blog/content/images/2026/08/1-dIHRpTKJZ0OiKavytDB8_Q.png) 近期的软件工程研究指向一种更强的方法。2026 年论文 [异步软件工程智能体的有效策略](https://arxiv.org/abs/2603.21489?ref=hubwiz.com) 引入了集中式异步隔离委派（Centralized Asynchronous Isolated Delegation，简称 CAID）。该系统不主要依赖对话式协调，而是使用软件团队已经理解的机制：集中式任务委派、显式依赖规划、隔离的 Git 工作区、分支、提交、合并和可执行测试。在报告的实验中，CAID 在论文复现和 Python 库开发两类任务上都大幅优于等效的单智能体基线。作者指出分支-合并隔离是一个重要的协调机制。 这也是我越来越多地在自己的系统中采取的方向。 如果一个智能体拥有实现的所有权，就把这种所有权显式化，而不是允许两个开发者投机性地修改同一状态。如果并行实现有用，首先要确认依赖关系已经完备、且各智能体的可写范围没有实质重叠。给他们隔离的分支或工作树，而不是一个共享的可变工作区。 独立审查也需要类似的边界。要求实现智能体重新考虑自己的工作是有用的自我批评，但它不是独立审查。最终审查者应该从全新的上下文出发，检查一个可识别的软件状态。 证据也需要身份。 假设审查者接受了提交 `def456`，但开发者随后推送了 `abc123`。一个对话式工作流中可能仍然包含一份完全有效的"已接受"审查。然而在操作上，那份审查已经过期了。 一个简化的就绪记录可能长这样： ``` candifate_head: abc123 required: ci: true functional_qa: true independent_review: true evidence: ci_head: abc123 qa_head: abc123 review_head: def456 ready: false reason: stale_independent_review ``` 没有任何智能体需要辩论这个变更是否就绪。证据没有指向当前状态，所以就绪为假。 这一区分得到了 [SyncMind](https://proceedings.mlr.press/v267/guo25l.html?ref=hubwiz.com) 的支持，这是一项 ICML 2025 关于智能体在协作软件工程中从失同步状态恢复的研究。它的基准包含超过 24,000 个源自真实仓库的场景。即使评估中最强的智能体也只从少数场景中恢复，而且当智能体的理解与环境发生分歧时，它们寻求协作的意愿非常低。 因此，状态新鲜度应该是证据系统的属性，而不是我们期望智能体记得去询问的事情。 ## 4、独立性需要的不仅仅是又一次模型调用 多智能体工作流常常把冗余当作保证机制：让一个智能体实现，另一个审查，也许再有一个投票或批评。这种模式有价值，但前提是第二个智能体提供真正独立的证据。 几个运行相似模型、接收几乎相同上下文、遵循相似推理指令的智能体可能犯同样的错误。它们也可能在讨论中趋向一致，而不是互相纠正。一项 NeurIPS 2025 的研究将多智能体辩论与更简单的多数投票进行比较，发现仅投票一项就解释了通常归功于辩论的大部分表面增益；额外的讨论并不会自动提高期望正确性。 对于软件交付，有意义的独立性可以来自多个来源。审查者可以收到不同的角色和全新的上下文。QA 可以执行行为，而不是仅仅检查开发者的推理。安全验证可以考察不同的失败维度。CI 可以提供确定性的执行证据。当问题值得这个开销时，两种实现偶尔可以相互比较。 重要的区分在于**另一个观点**和**另一个证据来源**。 这也是确定性控制在概率性系统内部仍然有价值的原因。测试、schema、类型检查、分支保护、依赖图、权限边界、不可变标识符、幂等键和状态机验证，并不会因为智能体变得更强大而过时。它们成为自治推理可以围绕其运行的稳定表面。 ## 5、保证应与风险成比例 多智能体系统还有另一种失败方式：技术上安全，但操作上荒谬。 我的第一个交付工作流把大多数变更路由经过一个相当完整的虚拟工程组织。这提供了强职责分离，但也意味着一个小而清晰的变更可能触发多个智能体读取大致相同的仓库上下文并进行重叠推理。 答案不是简单地删除角色。有些变更确实需要更强的审视。 我现在发现，用风险自适应保证（risk-adaptive assurance）来思考更有用。一个小的内部或文档变更可能只需要一个开发者、有针对性的验证和轻量级独立审查。一个普通的行为变更，只有在其特征需要时才加入功能 QA 或专家。而影响支付、权限、认证、生产控制、敏感数据或不可逆状态的变更，则值得一条强得多的路径，并且可能保留显式的人工批准。 角色是作为一种**能力**存在的，而不是每次变更的强制出席者。 同样的原则适用于并发。顺序启动。识别看起来可分解的工作。检查依赖和所有权边界。在隔离或影子模式下运行并行执行。衡量它是否真的减少了耗时而没有增加集成失败。只有在证据支持时才提高自治程度。 这是相当普通软件工程意义上的渐进式自治。我们很少仅仅因为某个生产部署流程的设计看起来令人信服，就一夜之间用全新的流程替换它。智能体工作流值得同样的纪律：影子执行、可观测性、有界发布、回滚，以及围绕高后果路径的更强控制。 自治不一定是二元的。 ## 6、每个智能体都应赢得它的边界 多智能体软件工程仍然前景广阔。有些任务确实受益于并行搜索、专长、独立验证或更大的聚合推理能力。近期研究为这些增益提供了可信的例子。 但每增加一个智能体，也引入了另一个必须让意图、状态、证据和权威穿过的边界。 这改变了我引入新角色之前提出的设计问题。 **这个智能体会增加什么独立能力？因为它的存在，什么协调失败成为可能？一个更简单的确定性机制能否提供同样的保证？** 有时候答案是另一个智能体。 有时候答案是测试、策略规则、分支、锁、schema、证据检查，或者仅仅是一个明确指定的作者。 因此，可靠的多智能体软件工程，可能既取决于知道哪里*不该*用另一个智能体，也取决于学会如何编排许多智能体。目标不是用 AI 复刻一个尽可能大的软件组织。 而是构建最小的智能体与工程控制系统组合，能够交付所需软件，并附上足以让人相信结果的可信证据。 --- 原文链接：[Why Multi-Agent Coding Fails](https://pub.towardsai.net/why-multi-agent-coding-fails-6b3a45746477?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处 > **这是「Agent / MCP」专题的一部分。**完整地图见：[Agent / MCP / 自动化完全指南](https://www.hubwiz.com/blog/agent-stack/)