AI系统像人类团队一样失败，并非因人为因素。核心问题在于“批量”过大导致复杂性与协调困难。通过自动化和减小批次，持续交付是解决之道。
译自：Why AI systems are failing in familiar ways
作者：Steve Fenton
随着人工智能辅助编程工具和智能体的引入，许多人曾希望我们能解决人类团队面临的所有问题。 没有了人、政治和个性，软件交付应该会变得轻松。 这种愿景很有吸引力，因为我们长期以来都将系统故障归咎于人。但多智能体AI的证据却揭示了一个令人尴尬的事实：相同类型的故障仍在相同的地方发生，且原因与人类无关。 那么，即使你消除了懒惰和愚蠢，为什么大量的任务仍然会失败呢？
项目村庄
关于软件项目的传统思维就像一个奇怪的村庄。它与世隔绝了数千年，并对自然法则形成了一些有趣的信念。他们用地毯铺墙，导致吸尘困难。他们用玻璃做屋顶，饱受室内温度之苦。他们用头发做衣服，因为没有人会对自己的头发过敏。 或许这个村庄最奇怪的一点是，他们相信重力是人类意志力的体现。 山谷里所有的动物都是鸟，它们似乎紧 clinging 在灌木枝上，否则就会滑向天空。他们也没有果树，这意味着他们从未有过牛顿式的顿悟。在没有相反证据的情况下，他们的集体错觉已经持续了许多代。 如果你拜访这个村庄，你会听到诸如“大地承载自强不息者”和“我愿意，故我立足”之类的哲学思考。每周三，他们都会聚集在市政厅互相提醒：“若心志坚定，地面自会升起与你相接。” 为了解决地毯清洁问题，村庄发明了一个铸铁人形机器人，用于吸尘清洁墙壁。为了防止机器人飘走，他们在其脚跟处内置了吸盘装置。有一天，一个机器人在两栋房屋之间移动时断电了。 令他们惊讶的是，机器人并没有飘走。村庄的哲学家们聚集起来讨论这一奇怪事件。他们唯一能得出的逻辑结论是，机器人已经发展出了人类的意志力，使其能够留在地面上。否则它怎么能留在地上呢？
这不是意志力，这是重力
在村庄之外，我们都知道重力对机器人有效，就像它对人、鸟和石头有效一样。但这并不能阻止我们在构建软件时犯类似的错误。 大型软件项目经常失败，负责人将原因归咎于人为因素。将这些失败归咎于人们的缓慢、懒惰、迟钝和需要休息，就像村庄相信重力是意志力的体现一样。 现实是，软件交付存在一种重力，它随着批量大小的增加而增强。这就是为什么当你给人工智能智能体群体分配大型复杂任务时，它们会以与人类团队完全相同的方式失败。 在多智能体人工智能的组织物理学一书中，Jeremy McEntire描述了一项实验，其中使用不同排列的AI智能体创建了相同的多服务后端系统。有一种观点认为，协调AI智能体团队将使AI能够处理更复杂的任务，但实验表明，协调的复杂性超过了在多个智能体之间分配工作的好处。 多智能体工作的失败看起来很熟悉。它们与大型项目的失败相同，只不过没有人类可以指责。这证明了挑战是复杂工作固有的，不能归因于人为因素。 我忽然意识到，我们责怪人为因素导致糟糕的系统已经太久了，我们需要承认它们不是过去IT系统失败的原因。
喃喃自语的平衡
“当我使用一个词时，”Humpty Dumpty以一种颇为轻蔑的语气说，“它的意思就是我选择的那个意思——不多也不少。”——路易斯·卡罗, 《爱丽丝梦游仙境》 当我说“rock”时，有些人会想到地质学（rocca源自拉丁语），而另一些人会想到音乐（roccian源自古英语）。少数人可能会想到一种海边的硬糖或一种用于固定未纺纤维的工具。 对于像一个词语这样简单的事物，我可以通过将其放入句子中来减少您的解释偏好。当沟通变得更加复杂时，我们很少能对想要传达的含义达成完全一致。沟通的精确性会从完美对齐下降，并可能退化到一种喃喃自语的平衡状态，即消息中没有传达任何信息。 这种不一致可以通过DevOps之前的问题来理解：开发团队以吞吐量衡量，而运维团队以可靠性衡量。当你向这两个独立的“筒仓”传达相同的信息时，解释会有很大的不同。 当人类指示AI智能体执行工作时，这种信息传递的挑战依然存在。因此，会出现“你提示错了”的反驳。更令人惊讶的是，当AI智能体向其他AI智能体发送消息时，这种挑战依然存在。这就是为什么多智能体配置的表现不如单智能体设置。 当你理解为什么智能体群体会加剧问题而不是解决问题时，答案就开始变得熟悉了。这些都不是新问题。早在AI智能体出现之前，人类开发团队就因为完全相同的结构性原因而失败。那些得以恢复的团队是通过解决结构问题，而不是人来解决的。
修复工作系统
在我过去的职位中，我经常被邀请加入公司“修复开发团队”。他们已经到了这样一个阶段：每一次部署都演变成高严重性事件，每一次变更都导致高度可见的错误，业务部门对团队交付可用软件的能力失去了信心。 这些团队通常已经有了基本的工具，比如版本控制和自动化构建。但缺失的是部署管道的其余部分，而这正是所有问题的根本原因。以下是我如何修复它的方法。 部署自动化使生产发布可重复且可靠，消除了这些团队最痛苦和影响最广泛的失败。这导致了更频繁的部署，进而减少了工作批次的大小。将工作分解成更小的步骤是提高沟通成功率的好方法。 测试自动化增加了我们对软件可部署的信心。发现没有自动化测试的团队并不少见，因此为最重要的功能添加特征测试减少了团队产生的令人尴尬的软件版本数量，例如那些甚至无法登录的版本。 监控和告警帮助团队了解系统在生产环境中的运行情况。随着我们对工具进行微调，团队成为第一个发现问题或问题早期迹象的人。通过优先处理保持软件健康的工作，我们改善了与业务部门的关系，包括处理投诉升级的高管，并使客户对软件更加满意。 这三项改变的结果不仅是部署、软件质量和可观测性的改进。拥有一个完整的管道会降低你的批次大小。这使得复杂性保持在较低水平，并解决了在大量工作中变得难以克服的沟通和协调问题。那些让AI智能体无法交付可用软件的问题，正是曾经阻止人类团队实现这一目标的问题。
批次有重力
软件交付存在一些基本法则，这意味着批次具有一种引力，这种引力会让人类团队或AI智能体难以管理。批次越大，一切就变得越重，移动它们所需的能量也越多。 拥有现代软件工程实践的组织，不是寻找更大的拖拉机来移动巨型物体，而是将一切都放入一个轻便的背包中。小批量是持续交付背后的秘诀，而DORA 研究增强了我们对这种方法的信心。 正如Fred Brooks在*《人月神话》*中所观察到的，给一个延期的软件项目增加人手只会使其更晚完成。McEntire的研究表明，这同样适用于你仅仅增加处理工作的AI智能体数量的情况。 无论代码是由谁或什么编写的，持续交付仍然是交付软件的最佳方式。
