康威定律

Conway 在 1968 年的原文 指出，设计系统的组织，会产生复制组织沟通结构的设计。这里关心的是实际沟通路径，而不只是组织架构图上的职位名称。

在软件团队里，谁和谁沟通、哪些信息需要交接、谁负责协调和集成，会影响系统的模块边界与接口。放到 Agent 系统中，沟通结构则由上下文范围、消息路由、角色间接口，以及最终决策和集成责任共同构成。

从 Agent Worker 到 Agent Group

这些形态不一定会彼此替代，它们代表不同的任务拆分和协作方式。

Agent Worker：单个 Agent 完成明确任务

Agent Worker 是最直接的协作形式。人先分析需求，再把边界明确的任务交给一个 Agent，比如实现一个登录拦截器并对接 Google OAuth。

任务上下文集中在人与单个 Agent 之间，不需要跨角色交接。任务变复杂后，人仍然可以持续补充上下文和验收结果，但执行过程主要由同一个 Agent 完成。

Agent Worker 协作示意图

Agent Workflow：把协作路径固定在流程中

Agent Workflow 用预先定义的流程连接触发、分析、执行和修复。比如 Issue 自动触发需求分析和 PR 提交，CI/CD 出现异常后，工作流继续调用 Agent 分析并修复。

Workflow 的通信路径由流程编排决定。它不依赖多个长期存在的职位角色，而是让 Agent 在明确的流程节点上完成任务。

Agent Workflow 流程示意图

Agent Tag：把 Agent 变成聊天中的同事

Agent Tag 将 Agent 接入 IM，让它以某个职位或同事的身份参与沟通。比如在飞书群里接入研发 Agent，业务同学通过 @Agent 提交和讨论需求，群里其他人也能看到讨论过程和结论。

这种形态改变了人与 Agent 的交互入口。Agent 不再只接收一条独立指令，而是进入已有的团队沟通环境。

Agent Tag 群聊协作示意图

Agent Team：两种角色协调形态

Agent Team 将 PM、UI、RD、QA、SRE 等角色放进同一个协作系统。每个角色负责一类工作，并可以保留自己的上下文。角色增加以后，跨角色的上下文一致性、冲突决策和最终集成成为新的协作工作。按照谁来承担这些工作，可以分成两种形态。

形态一：人直接协调，人分别与各个角色对齐需求，任务通常按 PM、UI、RD、QA、SRE 串行推进。人能够掌握讨论和执行细节，但也需要保证跨角色的上下文一致，负责冲突决策、异常跟进和最终验收。

形态二：Agent Manager 统一协调，人主要与 Manager 对齐。Manager 拉起各个角色、传递信息并组织角色间讨论，最后由 Manager 汇总结果并统一对外沟通。人不再逐项协调角色，但上下文一致性、冲突决策和集成责任仍需在 Team 内部得到处理。

Agent Team 两种协调形态示意图

Agent Group AB 测试：比较不同的组织方式

Agent Group AB 测试把实验对象从单个 Agent 扩展到整个团队。对照组可以采用不同的角色数量、通信拓扑或协调方式，再比较它们的交付结果。

这里测试的不只是哪个 Agent 的回答更好，而是哪种组织范式更适合当前任务。找到表现更好的结构后，再继续复制和迭代。

Agent Group AB 测试示意图

Agent 范式实验

实验设置

实验中尝试了两种团队结构，并做了一组 Agent Group AB 测试。第一种团队由我直接协调 PM、UI、RD、QA、SRE，串行推进需求。每个角色都能完成自己的工作并保留上下文，但角色联动时需要保证上下文一致性，出现问题后也需要我决策和跟进。

第二种团队由 Agent Manager 统一拉起和协调其他角色，我主要与 Manager 对齐。Manager 代替我处理角色间的沟通，不同角色也可以相互讨论，最后由 Manager 汇总结果。

这两种团队结构想验证同一个问题：把人类软件团队的组织结构复制给 Agent，能否获得类似专业团队的分工收益？

实验现象

尝试下来，问题主要集中在团队整体的交付过程：

  • 运行时间更长，资源消耗更大。
  • 执行结果会偏离预期，后续调整周期较长。
  • 为了达到预期，需要反复修改和验收。
  • 完全交给 Team 执行后，早期 Agent 上出现过的问题仍然存在。

单个角色能够完成自己的工作，不代表角色组合以后就能得到符合预期的产品。至少在当前实验配置中，增加 PM、UI、RD、QA、SRE，并没有自动带来人类专业团队的分工效果。

退化发生的位置

这里所说的退化，不是模型本身变弱，而是整个执行系统需要更多时间、消耗和人工验收，才能达到预期。

在这组实验中，一个通用 Agent 已经能够完整处理任务时，继续按照人类职位拆分角色，没有带来预期的专业化收益，反而增加了上下文边界、通信成本和验收成本。复用人类组织结构没有让 Agent Team 变得更强，反而让它表现出早期 Agent 的一些问题。

判断一次拆分是否有效，不能只看角色是否齐全，还要看它带来的收益能否覆盖新增的协作成本。

退化机制

上下文碎化。完整任务被分到多个角色，每个角色只保留局部上下文。原本由通用 Agent 一次性掌握的信息，变成了需要跨角色维护的共享状态。

传递损耗。角色之间通过消息交接，需求、约束和决策不一定能完整进入下一步。传递环节越多，确认一致性的工作也越多。

局部目标替代整体目标。每个角色都可以完成自己的职责，但局部完成不等于整体符合预期。最终仍需要一个角色对集成结果负责。

验收责任重新集中。Team 内部无法解决分歧或偏差时，决策和异常会回到我这里。Manager 改变了协调路径，却没有让信息传递和合作问题自动消失。

Agent Team 实验中的退化机制示意图

实验的边界

当前实验更直接支持的是协作成本上升和执行结果偏移。App 的模块、接口或测试边界是否也复制了团队边界，还需要结合产出代码与执行记录继续检查。因此，康威定律在这里是一种解释框架，不是已经被实验完整证明的结论。

这些结果也不能直接推广为所有 Agent Team 都会退化。herdr 和 orca 的编排开销、角色 Prompt、模型和工具差异、验收标准，都可能影响实验结果。当前结论应限定在本次实验所用的平台与配置中。

新方向

人类组织的职位分工，建立在人的时间、经验和认知限制上。Agent 的能力结构不同，直接复用这些职位，不一定能得到同样的收益。

这次实验让我把目光从复用人类组织结构，转向让 Agent 形成适合自己的新范式。Agent 可以根据任务决定是否需要拆分、按什么边界拆分，以及何时重新合并。拆分依据可以是独立工具、权限、可并行工作或独立验证，而不是 PM、RD、QA 这些既有名称。角色可以是完成任务所需的临时能力单元，不必组成一套固定的人类公司。

AB 实验也不应只比较两套人类组织图，还应将单个通用 Agent 作为基线。在相同任务、模型、工具和验收标准下，对比运行时间、资源消耗、执行偏移、修改轮次和人工介入，才能判断一种新的组织方式是否真的优于直接执行。

如果通用 Agent 已经能够独立完成任务，增加角色也需要有实验收益作为依据。否则，拆分只是在制造更多协调工作。Agent 更可能需要的，是从自身能力和任务结构出发形成的新范式，而不是对人类组织结构的另一份复制。