Anthropic 自己的应用 AI 团队表示，太多企业智能体的设计只是照搬组织架构图。他们的解决办法是先做评估，再逐个引入子智能体。是什么让你保留了自己的设计？

Anthropic 的应用 AI 团队于 10 月 22 日发布了一份指南，读起来像是对许多多智能体项目的复盘。他们观察到，人们常常为每个团队或每类问题单独设置一个子智能体，结果智能体架构变成了组织架构图的翻版（他们引用了康威定律）。他们列出的失效模式，任何在大型组织工作过的人都会觉得熟悉。上下文在交接中丢失。数百个职能重叠的子智能体不断堆积，却无人负责。每个团队都往系统提示词里加一句话，直到规则彼此矛盾，他们将其称为“弗兰肯提示词”。每个团队都编写针对自身子任务优化的评估，结果没人对整个系统的质量负责。而额外的层级也带来了延迟：一位客户测得，改用单一循环后，运行速度大约提升到了原来的两倍，不过 Anthropic 没有透露这位客户的名字。他们建议的原则是按上下文拆分，而不是按问题类型拆分。子智能体应当接手一项几乎不依赖系统其余部分的工作，并返回简洁的结果。如果按问题类型拆分，每次交接都会使信息失真，他们将其形容为传话游戏。最值得我借鉴的是他们的迁移方法。先建立一套小规模的端到端评估（他们说，起步时哪怕只有 10 个黄金样例也足够），再逐个整合子智能体：将其提示词转化为技能，将其 API 调用转化为工具，只有当整合后的版本得分更低时，才保留该子智能体。他们还建议每项任务都运行不止一次，因为在他们自己的客服智能体测试中，一次性能退化只在两次运行中的一次出现。这些对比来自 Anthropic 自己的企业部署，底层数据并未公开。他们仍然建议在需要并行工作、上下文出现可测量的膨胀，或工具选择遇到困难时使用子智能体。如果你正在运行一套多智能体系统，在尝试整合子智能体时，是什么让你决定保留它，或者整合后出了什么问题？你们的评估是由一个团队统一负责，还是各个团队各写各的？