康威定律正在影响你的智能体集群

打开你多智能体系统的架构图。然后再打开你的组织架构图。如果你眯起眼睛看，它们其实是同一张图。“研究智能体”对应着负责搜索的团队。“账单智能体”的硬边界恰恰就在财务部门停止与产品部门沟通的地方。那个将工作分发给五位专家的编排器，看起来极其像是一个带着五名直属下属的工程经理。你并非有意如此设计。是康威定律（Conway's Law）为你做了决定。

Melvin Conway 在 1967 年的观察是：任何系统设计都会反映出设计该系统的组织的沟通结构。六十年来，这始终是一个关于微服务和单体架构的故事。但智能体集群是我见过的对该定律最字面意义上的展示：智能体本身 就是 沟通结构。智能体边界是一个进程将消息传递给另一个进程并等待的地方。当你为了匹配团队而不是为了解决问题而划定这些边界时，你不仅继承了组织架构的形态，还继承了它的功能障碍，并以机器速度运行它。

数据表明这种情况已经在造成负面影响。Gartner 记录了在 2024 年第一季度到 2025 年第二季度之间，多智能体系统咨询量激增了 1,445%，组织平均运行着 12 个智能体——而大约 40% 的多智能体试点在进入生产环境后的六个月内以失败告终。失败的原因很少归咎于拓扑结构。它们通常归咎于模型、提示词或框架。但其中有惊人的一部分是因为康威定律正在收取它的“过路费”：一个复制了组织架构的智能体图谱，其中充斥着信息孤岛、有损交接，以及那些从未出现在设计文档中的地盘之争。

智能体图谱就是你伪装后的组织架构图

观察一下多智能体系统在公司内部是如何实际构建的。拥有客户数据库的团队会构建一个封装该数据库的智能体。负责支付的团队会构建一个支付智能体。每个智能体都获得了该团队已有的工具、上下文和权限——仅此而已，因为另一个团队的数据被隔离在早于项目存在的访问边界之后。其结果是，同一个团队拥有的智能体之间可以自由共享数据和工具，而不同团队拥有的智能体则通过狭窄、正式的接口进行沟通，这些接口看起来和那些团队之间的 Slack 频道或工单队列一模一样。

这感觉很自然，因为它 确实 很自然——这是阻力最小的路径。但它在你的架构中植入了一个特定的假设：分解 问题 的正确方法与你恰好分解 团队 的方法是一致的。这两者几乎从未是同一种分解方式。你的组织架构是针对人员编制、汇报关系和季度所有权而优化的。而你的问题本身不针对任何东西进行优化——它只是具有某种自然结构，而这种结构很少会考虑谁向谁汇报。

那种谁也解释不清的交接就是迹象。当一个任务为了完成用户眼中的单一操作（例如“更新我的地址”）而不断在三个智能体之间跳转——依次触达个人资料智能体、账单智能体和合规智能体——你所面对的并不是一个本质上分为三部分的问题。你面对的是三个分别拥有一小块业务的团队，以及一个忠实地复制了它们之间接缝的智能体集群。用户想要的是一件事。你的组织架构却给了他们三次往返。

当耦合变成 Bug 时

镜像组织结构的拓扑并不一定是错误的。只有当组织的沟通结构带来了对人类来说可以忍受、但对智能体来说却是灾难性的成本时，它才会变成一个 Bug。

人类可以吸收歧义。当账单团队向合规团队提交一个定义模糊的请求时，人员会读懂言外之意，在走廊里询问一个澄清问题，并用判断力填补空白。智能体不会这样做。它们会从字面上理解定义不足的交接，导致错误不断蔓延。流传已久的 2026 年级联研究（cascade research）给出了确凿的数据：在基于图的框架中，在 中心（hub） 节点注入故障会导致接近 100% 的系统级故障率，而叶子节点的相同故障率则低于 10%。你放置在拓扑中心的智能体——通常是镜像你最核心团队的那些智能体——恰恰是那些一旦失败就会拖垮下游所有环节的智能体。

接下来是 Token 账单。每一次智能体间的交接都是一个序列化边界：上下文被打包成消息、发送、解包并在另一端重新锚定。从业者报告称，在优化之前，预算大约是单智能体基线的 15 倍 Token 开销，其中 Token 量解释了性能波动的大部分原因。一个存在无谓交接的拓扑结构——那些仅仅因为两个团队不共享数据存储而存在的交接——会在每一次请求中永远支付这笔税。康威定律将你组织的协作成本转化为了每一笔查询的行项目费用。

最昂贵的版本是无声的。对等协作拓扑（像跨职能团队那样在共享的“群聊”中聊天的智能体）是 2026 年生产部署中明显 未能 幸存的模式之一。它的失败方式与委员会的失败方式如出一辙：责任分散，最终答案没有明确的所有者，以及来自一个智能体的一个自信的谎言演变成全系统的错误共识，因为没有智能体被赋予推翻它的权力。这不是模型问题。这是你编码到软件中的组织设计问题。

加载中…