AI 系统的康威定律：你的组织架构图就是你的 Agent 架构

每家在构建多 Agent 系统的公司最终都会发现同一个令人不安的事实：他们的 Agent 并没有反映技术架构图，而是反映了组织架构图。

处理客户入职的 Agent 与管理计费的 Agent 协调不好——不是因为技术限制，而是因为构建它们的团队之间本来就不怎么沟通。

康威定律——系统设计会映射构建它的组织的沟通结构——已经有五十年历史了，但从未像现在这样切中要害。在 AI Agent 时代，这条定律不仅适用，而且被放大了。当你的"系统"是一个由自主 Agent 组成的网络在做决策时，每一个组织接缝都会成为潜在的故障点：上下文丢失、交接中断、Agent 各自为局部指标优化而相互冲突。

这条定律对 Agent 的冲击更为剧烈

在传统软件中，康威定律产生的是尴尬的 API 边界和重复的数据存储。烦人，但可以应对。你可以用集成层、共享数据库和 API 网关来掩盖组织功能障碍。

对于 Agent，你做不到这一点。一个 Agent 如果缺少另一个 Agent 三步之前做出的决策上下文，它不只是产生次优结果——而是产生一个充满自信的错误结果。不同于返回错误码的微服务，一个做了错误决策的 Agent 会继续执行下去，在后续步骤中不断叠加错误。

以下是几乎每个构建多 Agent 系统的组织都会上演的模式：

• 市场团队构建内容 Agent，针对互动指标优化
• 销售团队构建线索筛选 Agent，针对转化率优化
• 客服团队构建问题解决 Agent，针对工单关闭时间优化
• 这些 Agent 没有一个共享统一的"客户"理解

市场 Agent 生成的内容吸引来的线索，销售 Agent 无法筛选。销售 Agent 做出的承诺，客服 Agent 无法兑现。每个 Agent 在隔离状态下都运行得很好。但放在一起，它们复制了公司已有的每一个跨职能障碍——只不过现在这些障碍以机器速度执行，没有人类在环路中捕捉矛盾。

Prompt 所有权问题

康威定律在 AI 系统中最突出的表现，是我所说的 Prompt 所有权空白：编写 Prompt 的团队几乎从不拥有评估权。

产品经理定义 Agent 应该做什么。工程师编写系统 Prompt。另一个数据或 ML 团队运行评估。当 Agent 在生产环境中出错时，每个团队都指向其他人。产品说 Prompt 实现错了。工程说需求模糊。评估团队说没人告诉他们预期行为变了。

这不是人的问题，而是结构性问题。这三个职能之间的沟通开销产生了不断叠加的延迟：

1. 产品编写描述期望 Agent 行为的规格说明
2. 工程将规格说明翻译为 Prompt 指令（信息丢失 #1）
3. 评估团队根据他们对规格说明的理解构建测试用例（信息丢失 #2）
4. Prompt 和评估在多次迭代中逐渐偏离（信息丢失 #3）

五次迭代之后，Prompt 已经被优化为通过那些不再代表产品真正需求的评估。而且没人注意到，直到客户投诉，因为组织结构创造了三个独立的反馈回路，而实际上只需要一个整合的回路。

Agent 边界就是团队边界

当团队设计多 Agent 架构时，他们几乎总是按照团队边界来划分 Agent 边界。这感觉很自然——每个团队都有领域专长，所以每个团队都应该拥有其领域的 Agent。但由此产生的架构继承了组织架构图已有的每一个沟通瓶颈。

考虑一个典型的电商公司，搜索、推荐、结账和履约分别由不同团队负责。每个团队为自己的领域构建一个 Agent。多 Agent 系统现在有四个 Agent，其交接点恰好映射了跨团队的沟通模式：

• 搜索 → 推荐：搜索 Agent 将结果传递给推荐 Agent，但它们之间的接口是两个团队协商出来的——通常是最小可行的数据契约。用户搜索某样东西的原因在交接中丢失了。
• 推荐 → 结账：推荐 Agent 推荐产品但对结账限制（库存、物流限制、支付限制）一无所知。结账团队没有暴露这些约束，因为历史上他们不需要这样做。
• 结账 → 履约：结账 Agent 确认订单时不与履约产能协调，因为它们是独立的团队，有独立的规划周期。

结果是一个技术上能运行的 Agent 流水线，但在每个边界处都丢失了关键上下文——这恰好就是人类组织的做法，只是更快了。

替代方案是围绕用户旅程或业务成果来设计 Agent 边界，而不是围绕团队领地。但这要求团队放弃"他们的"Agent 的所有权，这是一个组织变革，而非技术变革。

治理映射权力结构

Agent 获得多大的自主权，从来不是一个纯技术决策。它映射的是部署它的组织的信任关系和审批层级。

拥有集中式风险管理的组织会产生具有集中式审批门的 Agent。每个重要操作都路由到一个审查瓶颈，这会产生延迟，但与组织实际的决策方式相匹配。拥有分布式权力的组织会产生能够更独立行动的 Agent——但它们也会产生偶尔相互矛盾的 Agent，因为没有关于什么是被允许的单一事实来源。

两种模式本质上都没有错。问题在于团队以为自己在做技术设计选择（"Agent 是否应该有人在环审批？"），但实际上他们在编码一个组织决策。如果你的 Agent 在发送客户邮件之前需要三级审批，那不是安全特性——那是你的通信副总裁的审批链，被重新实现为 Agent 基础设施。

这很重要，因为它意味着你不能脱离运营组织来孤立地评估 Agent 架构。一个在高组织信任度和分布式决策环境中运行良好的 Agent 设计，在集中控制的公司会失败——不是因为架构错了，而是因为运营模式不匹配。

AI 的逆康威策略

最初的"逆康威策略"说：如果你想要特定的系统架构，首先重组你的团队以匹配该架构。对于 AI 系统，这转化为三个具体的组织模式。

在产品小组中嵌入 AI 工程师

不要搞一个集中的 AI 团队来服务产品团队的请求，而是直接将 AI 工程师嵌入跨职能小组。每个小组端到端地拥有其 Agent：Prompt、工具、评估和生产监控。

这通过让一个团队负责完整周期来消除 Prompt 所有权空白。代价是重复——多个小组会独立解决类似问题。但对于 Agent 系统来说，重复的成本低于所有权错位的成本。

共享评估基础设施

虽然 Agent 所有权应该是分布式的，但评估基础设施应该是集中的。共享评估平台提供：

• 一致的评估方法论，使团队可以跨领域比较 Agent 质量
• 共享的测试数据集，代表真实的生产流量模式
• 自动化回归检测，捕捉一个团队的变更破坏另一个团队 Agent 的情况
• 跨 Agent 评估，测试交接质量，而不仅仅是单个 Agent 的表现

评估平台团队不拥有任何产品 Agent。他们拥有的是产品团队用来评估自己 Agent 的工具和标准。这创造了组织对齐而不产生组织瓶颈。

Prompt 审查作为共享实践

我见过的最有效的模式是将 Prompt 变更视为代码变更：它们需要经过审查、进行版本控制，并且有关于什么是"好的"的共同理解。

这不意味着一个正式的"Prompt 审查委员会"（那只是另一个委员会）。它意味着建立规范：

• Prompt 变更由理解下游依赖 Agent 的人审查
• 系统 Prompt 的差异在与代码变更相同的 PR 工作流中可见
• 有一个共享的评估标准来判断 Prompt 变更是否保持了与现有 Agent 接口的向后兼容性

目标不是减慢 Prompt 迭代速度。而是让跨 Agent 依赖关系可见，因为当它们不可见时，康威定律保证它们会在最糟糕的时候崩溃。

协调税是真实的

每个 Agent 边界都是一个协调成本。在单 Agent 系统中，上下文在 Prompt 内自由流动。在多 Agent 系统中，上下文必须在每个交接点显式地序列化、传输和反序列化——而信息在翻译中总会丢失。

这种协调税是叠加的：

• 两个 Agent：一个交接，上下文丢失可控
• 五个 Agent：十个潜在的交接对，显著的协议开销
• 十个 Agent：四十五个潜在的交接对，你已经重建了企业中间件

这个数学与布鲁克斯定律对团队的影响相同：增加更多 Agent 会使沟通开销呈二次方增长。解决方案不是避免多 Agent 架构——有时问题确实需要它们。解决方案是诚实面对为什么你在某处划分 Agent 边界。

如果答案是"因为我们的团队就是这样组织的"，你就不是在做架构决策。你是在让康威定律替你做决策。而由此产生的系统将恰好具有你的组织已有的协调问题，编码在 Agent 协议中，以 API 速度运行。

逆势而为的设计

成功交付多 Agent 系统的团队往往做了一件不同的事：他们先设计想要的 Agent 架构，然后问他们的组织是否能支撑它。如果答案是否定的，他们改变组织——或者简化 Agent 架构，直到它与组织实际能协调的程度相匹配。

最糟糕的结果是一个比组织所能管理的更复杂的多 Agent 系统。你最终会得到没人完全理解的 Agent、没人拥有的交接、以及没人能诊断的故障——因为系统的复杂性超过了组织的沟通带宽。

康威定律不是一个需要绕过的 bug。它是一个诊断工具。如果你的 Agent 协调不好，先看组织架构图再看代码。修复方法几乎从来不是更好的交接协议。几乎总是两个本该早就在交流的团队之间的一次对话。