多智能体AI系统为什么总是"团队翻车"？加州大学伯克利分校揭秘AI团队合作的14种失败模式

这项由加州大学伯克利分校的Mert Cemri、Melissa Z. Pan等研究团队完成的突破性研究，于2025年1月发表在arXiv预印本平台上。论文全称为《Why Do Multi-Agent LLM Systems Fail?》，感兴趣的读者可以通过arXiv:2503.13657v2访问完整论文。这是首个系统性分析多智能体AI系统失败原因的大规模研究。

多智能体AI系统就像是让多个AI"员工"组成一个团队来完成复杂任务，比如让一个AI负责写代码，另一个AI负责检查错误，还有一个AI负责测试功能。这种"团队作战"的方式听起来很美好，理论上应该比单个AI更强大，但现实却让人大跌眼镜。研究团队发现，即使是最先进的多智能体系统，失败率也高得惊人——有些系统的成功率只有30%左右，这意味着十次任务中有七次都会搞砸。

就像人类团队一样，AI团队也会出现各种"团队翻车"的情况：有时是因为任务分配不清楚，AI们不知道自己该干什么；有时是因为沟通不畅，一个AI说的话另一个AI理解错了；还有时是因为质量把关不严，明明做错了却没人发现。但与人类团队不同的是，AI团队的失败模式更加复杂和难以预测。

研究团队花费了大量时间，像侦探一样仔细分析了200多个AI团队的"工作录像"——这些录像记录了AI们是如何一步步完成任务，又是如何一步步搞砸的。每个录像平均包含超过1万5千行对话内容，相当于一本中等厚度的书。通过这种"解剖"式的分析，他们发现了14种不同的失败模式，就像医生发现了14种不同的"团队合作综合症"。

这项研究的创新之处在于，它不仅仅是简单地统计"成功了多少次，失败了多少次"，而是深入挖掘每一次失败背后的具体原因。研究团队还开发了一套自动化的"AI团队诊断工具"，就像给AI团队配了一个专业的"团队心理医生"，能够快速识别出团队哪里出了问题。

更重要的是，这项研究揭示了一个令人深思的现象：仅仅提升单个AI的能力并不能解决团队合作的问题。就像一支篮球队，即使每个球员都是顶级选手，如果缺乏有效的战术配合和沟通机制，整个团队的表现反而可能不如配合默契的普通球队。这意味着，要让AI团队真正发挥作用，我们需要重新思考如何设计AI之间的协作机制。

一、AI团队失败的三大"病症"

研究团队通过对200多个AI团队案例的深入分析，发现了AI团队失败的三大根本性问题，就像三种不同类型的"团队病症"。

第一种病症叫做"规格说明书问题"，占所有失败案例的41.77%。这就像给装修工人一份不清楚的装修图纸，结果工人们各自按照自己的理解开始干活，最后装出来的房子完全不是业主想要的样子。在AI团队中，这种情况表现为AI们不遵守任务要求、角色定位混乱、重复做同样的工作，或者完全忘记了之前的对话内容。

研究团队发现了一个有趣的现象：AI不遵守规定并不仅仅是因为它们"理解能力差"。以ChatDev这个AI软件开发团队为例，当用户要求它开发一个"标准的五字母单词游戏，每天提供不同单词"时，AI团队生成的程序却使用了固定的单词库，完全忽略了"每天不同"这个关键要求。更奇怪的是，当研究人员提供更明确的说明——"不要使用固定单词库，每天随机选择新的五字母单词"——AI团队不但没有改进，反而引入了新的错误，比如接受不正确的输入。

这种现象说明了一个重要问题：AI团队的失败往往不是因为用户的要求不够清晰，而是因为整个团队系统的设计存在缺陷。就像一个管理混乱的公司，即使老板的指示再清楚，员工们也可能因为各种制度问题而无法正确执行。

第二种病症叫做"智能体协调失调"，占失败案例的36.94%。这就像一个乐队，每个乐手都是高手，但他们没有统一的指挥，结果演奏出来的音乐乱七八糟。在AI团队中，这种情况包括突然重启对话、不寻求澄清就按错误假设行动、偏离原始任务、隐瞒重要信息、忽视其他AI的输入，以及想法和行动不一致。

研究团队记录了一个典型案例：在一个音乐应用任务中，负责Spotify服务的AI知道用户名应该是电话号码格式，但它没有将这个关键信息告诉监督AI。结果监督AI一直用错误的用户名格式尝试登录，反复失败，最终导致整个任务无法完成。这就像一个团队成员知道门锁密码，但不告诉其他成员，导致大家一直在门外干等。

诊断这类失败特别复杂，因为相似的表面现象可能有完全不同的根本原因。比如，当AI团队缺少某个重要信息时，可能是因为有AI故意隐瞒信息，也可能是因为AI忽视了其他成员的输入，还可能是因为对话内容太长导致遗忘，或者是因为上下文管理出现问题。要准确找出真正的原因，需要仔细分析整个对话过程。

第三种病症叫做"任务验证问题"，占失败案例的21.30%。这就像一个制造工厂没有质检部门，产品做完就直接出厂，结果次品率居高不下。在AI团队中，这包括过早结束任务、没有进行验证或验证不完整，以及验证方法错误。

研究团队发现了一个令人困惑的现象：即使是配备了专门验证AI的团队，仍然会出现大量验证失败。以ChatDev为例，它生成的国际象棋程序通过了所有轮次的验证，但实际运行时却存在严重漏洞，比如接受无效移动。问题在于，验证AI只进行了浅层检查，如代码编译和注释检查，而没有验证程序是否符合实际的游戏规则或利用在线知识进行深度检查。这就像汽车工厂的质检员只检查外观是否美观，却不测试发动机是否能正常启动。

二、AI团队的14种具体"翻车"方式

在三大类问题下，研究团队识别出了14种具体的失败模式，每一种都有其独特的表现形式和潜在原因。

在规格说明书问题类别中，最常见的是"不遵守任务规格"，占所有失败的10.98%。这就像餐厅服务员明明听到了顾客点菜，却端上了完全不同的菜品。研究团队发现，这种问题并不仅仅是AI理解能力的问题，更多时候是系统设计的缺陷。当AI团队需要完成一个看似简单的任务时，它们可能会因为内部协调机制的不完善而产生偏差。

"角色规格不遵守"虽然只占0.5%，但却反映了一个根本性问题：AI不知道自己在团队中的确切定位。这就像一个足球队里，守门员跑去当前锋，前锋却回来守门，整个战术体系彻底崩塌。

"步骤重复"占17.14%，是一个相当严重的问题。这种情况就像一个人陷入了"鬼打墙"，不断重复同样的动作却意识不到问题所在。在AI团队中，这通常是因为轮换配置过于僵化，AI们被困在某个循环中无法跳出。

"对话历史丢失"占3.33%，但其影响往往是灾难性的。这就像一群人在开会时突然失忆，忘记了前面讨论的所有内容，只能从头开始。研究团队记录了一个案例：AI团队原本决定用scikit-learn替代lightgbm来解决兼容性问题，但随后又回到了lightgbm，完全忘记了之前的讨论。

"不知道终止条件"占9.82%，这就像一个人不知道什么时候该停止工作回家。在一个数学问题解决案例中，AI已经正确判断出问题因信息不足而无解，但另一个AI却坚持要求继续求解，导致无意义的重复对话。

在智能体协调失调类别中，"对话重置"占2.33%，就像团队成员突然失忆，忘记了所有之前的交流内容。"未能寻求澄清"占11.65%，这就像员工对老板的指示有疑问，但不敢询问，结果按照错误理解去执行。

"任务偏轨"占7.15%，是一个特别有趣的现象。AI团队会像被什么东西带偏了一样，逐渐偏离原始目标。研究团队发现了一个案例：AI被要求解决一个特定的数学问题，但却开始解决一个完全不同的问题，而且解决得还挺认真。

"信息隐瞒"占1.66%，"忽视其他智能体输入"占0.17%，这两种情况就像团队成员之间缺乏信任或存在沟通障碍。

"推理-行动不匹配"占13.98%，是一个相当普遍的问题。这就像一个人说要往东走，却迈步向西。AI可能正确分析了问题，但采取的行动却与分析结果不符。

在任务验证类别中，"过早终止"占7.82%，就像厨师菜还没做熟就端上桌。"无验证或验证不完整"占6.82%，"验证错误"占6.66%，这些都反映了AI团队在质量控制方面的严重不足。

三、验证机制：并非万能的"质检员"

研究团队特别关注了验证机制在AI团队中的作用，因为许多人认为只要给AI团队配一个"质检员"就能解决大部分问题。然而，现实情况却让人大跌眼镜。

验证失败确实是一个突出问题，不正确或不完整的验证加起来占所有失败的13.48%。这个比例相当可观，说明质量控制确实是AI团队的一个重要薄弱环节。研究结果部分支持了最近一些强调验证智能体重要性的研究观点。

配备专门验证机制的系统，如MetaGPT和ChatDev，在总体失败次数上确实比没有专门验证机制的系统表现更好。这似乎证实了"质检员很重要"的直觉。然而，这种改善却远远没有达到人们的期望。

最令人困惑的是，即使有了验证机制，AI团队的整体成功率仍然低得令人震惊。ChatDev在ProgramDev数据集上的正确率只有33.33%，这意味着三次任务中有两次会失败，而且这还是在处理一些相对简单的编程任务时，比如实现井字游戏、国际象棋和数独游戏——这些都是网上有大量参考资料的经典程序。

更让人意外的是验证失败的具体表现。研究团队发现，AI团队生成的井字游戏程序会宣布错误的获胜者，国际象棋程序会接受格式不正确的移动。通过详细的端到端人工检查，研究人员发现当前的验证AI往往只进行表面检查，比如检查代码是否缺少注释或能否编译通过，却无法确保更深层次的正确性。

这就像汽车工厂的质检员只检查车漆是否光亮，却不测试刹车系统是否正常工作。表面上看起来一切正常，但关键功能却存在严重缺陷。

为了探索改进验证机制的可能性，研究团队进行了一个有趣的实验。他们为ChatDev增加了一个额外的验证步骤，专门关注高层次的任务目标，补充现有的代码级检查。这个相对简单的架构改变带来了显著的改善，在ProgramDev数据集上实现了15.6%的绝对改进。

这个结果表明，多层次验证确实是有效的。就像制造业中的多道质检程序一样，仅仅依靠最终阶段的低层次检查是不够的。强大的AI团队需要模块化的单元测试机制，就像复杂软件系统一样。

然而，研究团队也发现了一个重要问题：如果AI团队在有验证机制的情况下仍然失败，责任全在验证机制吗？答案是否定的。验证应该作为最后一道防线，如果问题在早期阶段就出现了，而验证机制未能发现，那么问题的根源可能在前面的环节。

研究团队提出了一个重要观点：仅仅关注验证机制会忽略AI团队早期阶段的关键问题和潜在的连锁反应。这就像一家医院把所有注意力都放在急救室，却忽视了预防保健和早期诊断的重要性。

四、干预实验：简单修补难以根治"团队病"

为了验证他们的发现，研究团队进行了两个大规模的干预实验，就像给AI团队开不同的"药方"来看看哪种治疗方案更有效。

第一个实验以AG2系统为对象，这是一个数学问题解决团队。研究团队设计了两种干预方案：改进提示词和重新设计团队架构。

在改进提示词方案中，他们为AI团队提供了更清晰的结构化指导，就像给员工提供了更详细的工作手册。新的提示词包括了专门的验证部分，要求AI在给出最终答案前进行自我检查。这种改进在GPT-4上带来了显著提升，成功率从84.75%提高到89.75%。然而，当他们尝试重新设计团队架构时，效果却不够理想。

重新设计的架构将原来的两人团队（学生和助手）扩展为三人专业团队：问题解决者负责用推理方法解决问题，编程者负责编写和执行Python代码，验证者负责审查讨论并评估解决方案。这种设计看起来更加专业化，但实际效果却没有达到预期。统计检验显示，这种改进在GPT-4上并不显著，只有在GPT-4o上才显示出统计意义上的改善。

第二个实验以ChatDev为对象，这是一个模拟软件公司的AI团队。研究团队实施了两种干预：优化角色特定提示词以加强层级关系和角色遵守，以及从有向无环图改为循环图的基础架构变更。

在角色优化方案中，研究人员发现CPO（首席产品官）经常在没有充分解决CEO约束条件的情况下过早结束与CEO的讨论。为了防止这种情况，他们确保只有上级智能体才能结束对话。同时，他们还增强了验证者角色规格，使其更关注任务特定的边缘情况。

架构变更更加根本性。原来的系统采用有向无环图结构，任务完成后就结束了。新系统改为循环图，只有当CTO智能体确认所有审查都得到妥善满足时，流程才会终止，并设置最大迭代次数防止无限循环。这种方法支持迭代改进和更全面的质量保证。

实验结果显示，这些干预确实带来了改善。在ProgramDev-v0数据集上，基线成功率为25.0%，改进提示词后提升到34.4%，新架构设计达到了40.6%。在HumanEval数据集上，改善幅度较小但仍然存在：从89.6%提升到90.3%（改进提示词）和91.5%（新架构）。

然而，这些结果也揭示了一个重要问题：即使是成功的干预，改善幅度也相对有限。特别是在原本成功率就很低的任务上，即使有了15.6%的绝对改进，ChatDev的成功率仍然只有40.6%，这意味着十次任务中仍有六次会失败。

更重要的是，研究团队使用他们开发的MAST工具对干预前后的失败模式进行了详细分析。结果显示，虽然大多数失败模式都有所减少，但并没有被完全消除。这就像给病人用了药，症状有所缓解，但疾病的根源仍然存在。

这些发现表明，简单的修补措施虽然有用，但不足以解决AI团队协作的根本问题。就像一栋房子地基有问题，仅仅刷新油漆或更换家具是无法解决结构性问题的。要实现真正可靠的AI团队性能，可能需要对系统设计进行更根本性的重新思考。

五、深层问题：不只是AI能力的问题

研究团队在分析过程中发现了一个非常重要的洞察：AI团队的失败并不能简单归咎于单个AI的能力不足。这个发现颠覆了许多人的直觉认知。

许多人可能会认为，AI团队出现问题是因为组成团队的AI还不够聪明，只要等技术发展，AI变得更强大，这些问题自然就会解决。然而，研究团队的干预实验提供了相反的证据。

在所有的干预实验中，研究团队都确保使用相同的基础AI模型和相同的用户输入，唯一的变化是系统设计。结果显示，仅仅通过改进系统设计，就能带来显著的性能提升。这强烈暗示，观察到的失败并不仅仅是因为模型能力限制，而是因为系统设计本身的缺陷。

这就像一支篮球队，即使每个球员都是顶级选手，如果缺乏有效的战术体系和沟通机制，整个团队的表现可能还不如配合默契的普通球队。问题不在于个体能力，而在于组织协调。

研究团队引用了组织理论中的一个重要概念：即使是由高素质个体组成的组织，如果组织结构存在缺陷，也可能发生灾难性失败。高可靠性组织的研究表明，良好定义的设计原则可以预防这种失败。

然而，干预实验也揭示了一个更深层的挑战。虽然这些干预带来了统计上显著的改进，但并没有消除所有失败模式，而且任务完成率要么略有改善（对于本来就表现较好的任务），要么仍然保持在较低水平。这表明，要实现高可靠性，可能需要对智能体组织、沟通协议、上下文管理和验证集成进行更根本性的改变。

研究团队通过MAST框架的分析发现，理解这些根本原因对于设计有效的干预措施至关重要。仅仅治标不治本的方法无法解决核心设计缺陷。这就像医生需要诊断疾病的根本原因，而不是仅仅治疗症状。

这个发现对AI研究和应用具有重要意义。它表明，推进AI团队技术不仅需要提升单个AI的能力，更需要深入研究如何设计有效的多智能体协作机制。这包括建立标准化的沟通协议、设计强大的验证系统、实现不确定性量化，以及改善记忆和状态管理。

六、解决方案的两个层次：治标与治本

基于研究发现，研究团队提出了两个层次的解决方案：战术性方法和结构性策略。

战术性方法就像给病人开止痛药，能够快速缓解症状，但不能根治疾病。这类方法包括改进提示词和优化智能体组织交互。

在提示词改进方面，研究团队发现AI团队的提示词应该提供清晰的指令描述，每个智能体的角色应该被明确规定。提示词还可以澄清角色和任务，同时鼓励主动对话。当出现不一致时，智能体可以重新参与或重试。

完成复杂多步骤任务后，可以在提示词中添加自我验证步骤，通过重新陈述解决方案、检查条件和测试错误来回溯推理。然而，这种方法可能会遗漏缺陷，依赖模糊条件，或者不切实际。

清晰的角色规格可以通过定义对话模式和设置终止条件来加强。采用简单、定义明确的智能体的模块化方法，而不是复杂的多任务智能体，可以提高性能并简化调试。

团队动态还支持多智能体系统其他有趣的可能性：不同智能体可以提出各种解决方案，讨论他们的假设和发现（交叉验证）。多智能体策略可以模拟学术同行评议过程来发现更深层的不一致。

然而，这些看似直接的解决方案往往被证明是不一致的，这与研究团队的案例研究发现相呼应。这突出了对更强大、结构性策略的需求。

结构性策略就像给病人做手术，需要更深入的干预，但能够从根本上解决问题。这类策略需要更深入的研究和细致的实施，是未来研究的开放性课题。

首先是验证过程和验证智能体在多智能体系统中的关键作用。研究团队的分析显示，弱或不充分的验证机制是系统失败的重要因素。虽然单元测试生成有助于软件工程中的验证，但创建通用验证机制仍然具有挑战性。即使在编程中，涵盖所有边缘情况也很复杂，即使对专家也是如此。

验证因领域而异：编程需要全面的测试覆盖，质量保证需要认证的数据检查，推理受益于符号验证。跨领域适应验证仍然是一个持续的研究挑战。

建立标准化沟通协议是另一个重要策略。基于LLM的智能体主要通过非结构化文本进行沟通，这会导致歧义。清楚地定义意图和参数可以增强对齐，并支持在交互期间和之后进行正式的一致性检查。

一些研究已经在这个方向上进行了探索。多智能体图注意力利用图注意力机制来建模智能体交互并增强协调。注意力沟通使智能体能够选择性地关注相关信息。学习选择性沟通协议提高了合作效率。

强化学习微调MAS智能体是另一个重要研究方向。智能体可以通过角色特定算法进行训练，奖励与任务对齐的行动并惩罚低效率。一些算法优化智能体对定义角色的遵守，使用潜在网络在应用异构决策层之前学习策略，或者通过迭代强化学习进一步增强沟通效率和任务有效性。

将概率性置信度量纳入智能体交互可以显著增强决策制定和沟通可靠性。智能体可以被设计为只有在置信度超过预定义阈值时才采取行动。相反，当置信度较低时，智能体可以暂停收集额外信息。系统还可以受益于自适应阈值调整，其中置信度阈值被动态调整。

虽然通常被视为单智能体属性，但记忆和状态管理对多智能体交互至关重要，可以增强上下文理解并减少沟通中的歧义。一些研究引入了操作系统启发的上下文管理以扩展上下文窗口，或者使用结构化、可重放的日志来迭代记录和完善智能体行动，促进动态任务分解和持续改进。

七、MAST：首个AI团队"体检工具"

研究团队开发的MAST（多智能体系统失败分类法）不仅仅是一个学术概念，更是一个实用的诊断工具，就像给AI团队配备了一个专业的"团队心理医生"。

MAST的开发过程本身就是一个严谨的科学研究。研究团队采用了"扎根理论"这种质性研究方法，就像考古学家一样，一层层地挖掘和分析AI团队失败的深层原因。他们分析了7个流行的多智能体系统框架，涉及200多个任务，每个任务的对话记录平均超过1万5千行文本。

为了确保分类法的可靠性，研究团队进行了严格的标注者间一致性研究。三名标注者独立分析了15个案例，最终达到了0.88的Cohen's Kappa分数，这在学术界被认为是"几乎完美的一致性"。这就像三个医生对同一批病例进行诊断，诊断结果高度一致，说明诊断标准是可靠的。

更重要的是，MAST具有良好的泛化能力。当研究团队将其应用到开发过程中未使用的新系统（Magentic-One和OpenManus）和新基准测试（GAIA和MMLU）时，仍然实现了0.79的Cohen's Kappa分数，证明MAST能够适用于不同类型的AI团队和任务。

为了使MAST能够大规模应用，研究团队还开发了一个自动化的LLM评判管道。这个工具使用OpenAI的o1模型作为"智能诊断师"，能够自动识别AI团队执行过程中的各种失败模式。经过验证，这个自动诊断工具达到了94%的准确率和0.77的Cohen's Kappa分数，这意味着它基本上可以替代人工专家进行失败模式识别。

MAST的实用价值在研究团队的案例研究中得到了充分体现。在对ChatDev和AG2系统进行干预实验时，MAST不仅能够识别干预前的问题所在，还能够准确评估干预后的效果。

通过MAST分析，研究团队发现拓扑结构改变比提示词改进更有效。这种发现对于AI团队的开发者来说具有重要的指导意义：与其花大量时间优化提示词，不如重新思考团队的组织架构。

MAST还揭示了一个有趣的现象：不同的AI团队系统有着截然不同的"失败画像"。AppWorld系统主要受过早终止问题困扰，而OpenManus系统则主要面临步骤重复问题。这种个性化的失败模式分析，为针对性的系统优化提供了精确的指导。

研究团队将MAST工具完全开源，包括200多个对话轨迹、LLM评估管道和详细的专家标注。这种开放共享的做法将有助于整个AI研究社区共同推进多智能体系统的发展。

八、未来展望：从"效率"到"正确性"的转变

在开发MAST的过程中，研究团队发现了一个值得深思的现象：当前的AI团队虽然经常完成不了任务，但即使完成了任务，过程也往往极其低效。

研究团队观察到，AI智能体经常进行不必要的长时间对话，或者采取迂回的路线来实现目标。在一个AppWorld案例中，任务是从播放列表中检索前10首歌曲，监督者和Spotify智能体进行了10轮对话，每次检索一首歌，尽管Spotify智能体的能力允许在单个有效操作中检索所有10首歌曲。这种低效可能导致成本（令牌使用）和延迟（运行时间）显著增加，有时甚至增加10倍或更多。

这种现象揭示了当前AI团队研究的一个重要局限：过度关注任务完成的正确性，而忽视了执行效率。在实际应用中，效率问题可能比正确性问题更加致命，因为它直接影响成本和用户体验。

研究团队在MAST的迭代完善过程中有意识地排除了非正确性指标如效率，以保持焦点。然而，他们也认识到，效率以及其他重要维度如成本、鲁棒性、可扩展性和安全性，对于现实世界的MAS部署至关重要。

这个观察为未来研究指明了方向：下一代AI团队不仅要能正确完成任务，还要能高效完成任务。这需要开发新的评估框架和优化目标，不仅要最大化成功率，还要最小化资源消耗和执行时间。

另一个重要的未来方向是跨领域的泛化能力。虽然MAST在多个系统和任务上显示了良好的泛化性，但所分析的任务主要集中在软件开发、数学问题解决等技术领域。未来的研究需要探索MAST是否适用于更广泛的应用领域，如医疗诊断、法律咨询、创意写作等。

系统设计理论的引入也是一个有前景的方向。研究团队已经开始从组织理论和高可靠性组织研究中汲取灵感，未来可以进一步借鉴工程学、管理学、心理学等领域的成熟理论，为AI团队设计提供更坚实的理论基础。

最后，随着AI技术的快速发展，特别是更强大的基础模型的出现，MAST分类法也需要不断更新和完善。新的AI能力可能会带来新的失败模式，也可能会使某些现有的失败模式变得不那么重要。保持MAST的时效性和相关性将是一个持续的挑战。

说到底，这项研究为我们展示了AI团队合作的复杂性和挑战性。虽然让多个AI协同工作的想法很诱人，但实现这个目标比我们想象的要困难得多。简单地把几个强大的AI放在一起，并不能自动产生更强大的团队能力。

归根结底，要让AI团队真正发挥作用，我们需要从根本上重新思考AI系统的设计哲学。这不仅仅是技术问题，更是组织设计和管理的问题。就像人类社会需要法律、制度和文化来维持秩序一样，AI团队也需要精心设计的协作机制和质量保证体系。

这项研究提醒我们，在追求AI能力的道路上，我们不能只关注单个AI的智能水平，更要关注AI之间的协作智慧。毕竟，在现实世界中，最复杂的问题往往需要团队合作来解决，而AI团队合作的成功，将直接决定AI技术能否真正造福人类社会。对于任何对AI技术发展感兴趣的读者，这篇论文都值得深入研读，完整的研究内容可以通过arXiv:2503.13657v2获得。

Q&A

Q1：什么是多智能体AI系统？它和单个AI有什么区别？ A：多智能体AI系统就像让多个AI"员工"组成团队来完成复杂任务，比如一个AI写代码，另一个AI检查错误，还有一个AI测试功能。与单个AI相比，理论上应该更强大，但研究发现实际失败率高达70%，远不如预期。

Q2：MAST分类法会不会过时？随着AI技术发展还有用吗？ A：MAST确实需要随AI技术发展而更新，但其核心价值在于揭示了AI团队失败的根本原因——组织设计问题，而不仅仅是技术能力问题。即使AI个体能力提升，团队协作的挑战仍然存在，所以MAST的框架思路会持续有价值。

Q3：普通开发者如何使用MAST来改进自己的AI系统？ A：研究团队已将MAST工具完全开源，开发者可以通过GitHub访问完整的诊断工具。使用时只需输入AI团队的对话记录，工具会自动识别14种失败模式，并提供具体的改进建议，就像给AI团队做"体检"一样简单。