「从今往后，所有团队都要通过服务接口，对外提供自己的数据和功能。」
史蒂夫·耶格记得，杰夫·贝索斯在亚马逊发过一道命令，开头就是这一句，时间「大概是 2002 年，前后差一年」。耶格在亚马逊干了大约六年半。2011 年，他在一篇本来只写给谷歌同事的长帖里讲了这个故事，结果手一滑，帖子公开了。
按他的转述，后面几条都很严。团队的软件之间只能通过这些接口通信。不许直接读别的团队的数据，不许共享内存，「任何后门都不行」。用什么技术无所谓：「贝索斯不在乎。」每个接口从一开始就要设计成有朝一日能开放给外部开发者用。
然后是第六条：「不照办的人，一律开除。」
还有第七条：「谢谢，祝你今天愉快！」耶格承认，这条是他自己开的玩笑。第六条「可是千真万确，于是大家都开始干活了」。
贝索斯的规定划定了服务之间的边界：谁的代码能碰谁的数据，走哪条路。亚马逊的首席技术官沃纳·沃格斯，讲的是组织怎样跟着调整。1998 年，亚马逊所有开发团队都在改同一个应用，每次发布都得在所有团队之间协调。亚马逊想要的，是一个由各自独立的服务组成的系统。他在 2019 年写道：「为了支撑这种新架构，我们拆掉了按职能划分的层级，把组织改成了一个个小而自主的团队。」其余经过，包括后来的结果，见案例。
把定律倒过来用
1968 年，梅尔文·康威观察到：设计系统的组织，做出来的设计会照搬自己的沟通结构。这就是后来的康威定律。马丁·福勒讲过一位技术负责人，刚接手一个横跨不同城市六个团队的新项目。他做的第一个架构决定是：「会有六个主要子系统。我还不知道它们是什么，但一定是六个。」
如果这条定律成立，它就能倒过来用：先想好系统要长成什么样，再按这个样子安排人。咨询公司 Thoughtworks 在 2014 年把这个思路放进了它的技术雷达，名字叫「逆康威策略」，建议「调整团队和组织结构，去促成你想要的架构」。
这个名字出自乔尼·勒罗伊和马特·西蒙斯 2010 年的一篇文章，讲的是怎么替换老旧难改的软件。他们的说法很克制：动手重写一个应用之前，也许值得先打破那些妨碍团队协作的壁垒，免得新系统把老系统的毛病原样继承下来。他们还提醒，康威定律说的是「沟通结构」，不是汇报关系，所以往往有一些轻巧的办法，不用大动组织架构，也能改变谁跟谁说话。
代价
把线挪了，代价也跟着挪。耶格写道，在亚马逊，一张告警工单可能要「在 20 次服务调用之间转来转去，才找到真正的负责人」。每个兄弟团队都成了「潜在的拒绝服务攻击者」，随时能用请求把别人的服务冲垮，于是每个服务都得设配额、做限流。团队之间学会了互不信任，「方式和不该信任外部开发者的方式差不多」。
福勒也指出了它的局限。一个现成的系统要是结构已经僵硬，光重组人手，并不能马上把它改好，反而更可能让开发者和代码对不上号，平添阻力。他的建议是，组织和代码一起改，一小步一小步来。
四份通讯
设想一家小出版社，办着四份通讯：美食、旅行、理财、园艺。四份稿子都过同一个编辑部。一年下来，它们越写越像：一样的笑话，一样的版式，一样的篇幅。出版社想要四种不同的腔调。它没去写一本风格手册，而是给每份通讯配了自己的编辑，每周跟这份通讯的作者碰头，跟其他编辑一个月才见一次。四种腔调也许会慢慢分开，四份通讯之间想共用点什么，成本也可能跟着变高。
怎么给智能体分工
用 AI 智能体搭系统的人，现在也在有意做同样的选择。Anthropic 的「研究」功能，用一个主智能体来规划，再派出几个子智能体并行搜索，每个子智能体都有自己的上下文窗口。Anthropic 发现，这种结构特别擅长「需要同时追几个独立方向的广度优先问题」。
它也发现了拆分不再划算的地方：「有些领域需要所有智能体共享同一份上下文，或者智能体之间依赖很多，目前并不适合多智能体系统。」它写道，大多数编程任务里真正能并行的部分，比调研少。拆分也有价钱：按 Anthropic 的数据，多智能体系统用掉的词元，大约是普通聊天的 15 倍。
所以对智能体来说，这一招两头都能用。活能干净地拆开，就给每块配一个智能体，再跟主智能体约好清楚的交接方式。各块之间步步相互依赖，硬拆给几个智能体，等于亲手造出了你本想避开的那些交接。
贝索斯那六条，一款产品都没点名。它们画好了各团队服务之间的线，亚马逊随后把团队改成了与之相配的样子。