把公司搭成一个阿米巴联邦

上篇立了两条公理：AI 无状态（statelessness），且上下文有限（context window）。它像一个每天失忆的天才，你必须把所有事实、规则、默契写下来喂给它，而且每一次都要重来。

从这两条一路推下来：经典的「沟通漏斗」在人机协作里失去了兜底机制，每个人的工作从执行者变成了沟通者；组织的最小原子单位从「个人」变成「一个人＋一组 agent」，大公司的组织病提前到 5 人小团队就发作。解法也在上篇给了：从细节倒推回使命、愿景、价值观，立一部宪法，落到一个单一事实来源（SSOT）上，再用一套 a2a 的自动化基础设施，让对齐每天低成本地自动发生。

这一篇把镜头继续拉远：当尺度从一个小团队放大到部门、公司、成百上千人，这套逻辑会把组织形态本身改写成什么样。

规模的物理：熵、水位线，与评审带宽

任何一个持续迭代的组织，信息量都只增不减：人越多、团队存在越久、迭代越频繁，产生的文档、决策、邮件、聊天记录就越多。这种只增不减的杂乱信息，软件工程里借热力学的说法，把它叫作熵（entropy）。

我在《宣言》第 12 章「Token 作为项目规模的量化指标」里写过，一个项目的复杂度，可以用它包含的 token 总量来衡量。这个衡量放到组织上，就成了一条硬约束——因为 AI 的上下文窗口是有限的，而一个中等规模业务经年累月沉淀下来的信息，动辄几百万、上千万 token。没有任何一个 AI 能装下一整家公司。

于是有了一条很物理的水位线：一个项目的 token 总量在 1M（一百万）以内，一个人带着他的那队 AI，还能把全貌完整地装进头脑和上下文窗口里——作为参照，1M token 大约是一个超小型 AI 原生团队 15 到 30 天产出的全部内容；到 10M 就到了临界点，混乱和对不齐开始超出控制；超过 10M，必须拆分成多个 1M–10M 的子项目。

这直接决定了组织形态的走向：单元必须分裂，部门必须变小，组织必须变扁。过去，部门按职能划分（市场部、销售部、技术部），或按业务划分（游戏一部、电商二部），那条边界是组织架构图上的一根线，本质是权力、资源与汇报关系的表达。而在 AI 原生的世界里，划分部门只剩一条逻辑：切分上下文。因为没有任何一个 AI 吃得下一整家公司的上下文，你只能把它切开，让每一块都塞得进一个有限的上下文窗口，并让每个部门都拥有一个相对完整的信息世界。

一个部门，本质就是一块「上下文有界的 token 分区」。

你把它叫「市场部」，只因为这块分区里装的是市场、用户、渠道的上下文。这条边界的意义，从「管人」转向了「管信息」——让信息能被有效地喂进去、处理掉。

那么一个单元应该多小？5 人上下。这不是管理学的魔法数字，而是沟通与产出的均衡点：人数再多，花在内部对齐上的时间，就开始超过花在实际工作上的时间。

什么时候该给团队加人？不是招聘指标下达的时候，也不是有人抱怨忙不过来的时候。

团队必须扩张的临界点，是「评审带宽」饱和。AI 能极大地增加执行带宽，却增加不了评审带宽。

评审带宽，指一个人一天能认真看完并给出有效判断的材料量——一份方案、一份合同、一版设计，这个上限受限于他的能力、经验，以及团队对齐基础设施的扎实程度。AI 让执行的产量翻了十倍，可这些产出最后都要经过人的这一关。当组织里每个人的评审带宽都已用满、工作仍在溢出，整体吞吐才算真正到达瓶颈。这时候才该加人，把一块大的 token 分区，再拆成两块更小的。

反方：为什么我不看好 agent 群聊

谈到这里，一个很自然的疑问是：如果 agent 之间能自己沟通、自己协作、自己解决冲突，是不是就不必这么费力地切分组织了？市面上已经有不少「agent swarm」「多 agent 协作」方向的产品，期望一群 agent 在群聊里自主完成全部工作。

我不看好这条路，至少在可见的未来。理由有四条。

一，上下文管理不一致。每个 agent 携带的上下文、对同一个词的理解、信息更新的频率都不一样，放进一个群聊里，这种不一致会被迅速放大成误解。

二，复杂度超出多数人的驾驭能力。不必说 10 个 agent，多数人连两三个都难以管好：每个 agent 有自己的输入、自己的偏移方向，要把它们协调成一支队伍，对人的要求极高。

三，对齐成本高。上篇讲的沟通漏斗，在群聊里会变成一张网：你跟 A 对齐，A 跟 B 对齐，B 再跟 C 对齐，每一段都在损耗，每天都在消耗你。

四，失控之后极难收敛。每个 agent 都在自己那个小方向上越走越深，到验收时你拿到的是一大批看似完整、却在 10 个不同方向上各有小缺陷的产出，而且每个缺陷都不显眼。要把它们收束回来，你必须在 10 个方向上同时纠 10 个不同的错，比从头重做还难。

归根结底，每个 agent 都在占用你的「邓巴预算」——人类学家邓巴发现，一个人能维持稳定关系的人数上限大约是 150 人，即邓巴数。带 agent 比带人占用得更多：不是因为它智力不足，是因为你的上下文宽度有限。一个人能有效带的 agent 数量，是上下文窗口的函数，不是一个可以无限叠加的数字。

大组织的形态：一个阿米巴的联邦

一个超级大脑装不下全部上下文，装得下的独立单元又只有 5 人上下——那么当组织成长到足够大，它唯一的出路，就是变成一个由「上下文有界单元」组成的联邦。这种小单元，最现成的名字叫阿米巴（Amoeba）：每个阿米巴专职一个板块，带着自己那几队 agent，在自己那块有界的上下文里独立完成交付。

这不是 AI 时代的新发明，而是同一条物理定律在组织形态上的又一次投射。而且我们不必从头摸索，几十年前那些最早实践扁平化、自治小单元的公司，已经交出过答卷。稻盛和夫的京瓷，靠「单位时间附加值」这份人人读法一致的经营数字，加一本共享的「京瓷哲学」，让上千个阿米巴在没有复杂层级的情况下朝同一个方向盈利。海尔的人单合一，靠内部市场化和一个共享平台，让每个小微都成为直面用户的创业单元。晨星（Morning Star），靠同事之间点对点的书面承诺（CLOU），撑起一套没有老板、却责权分明的协作网。还可以再算上 Gore 的格子架构（以 150 人的邓巴数封顶）和荷兰的 Buurtzorg（小队＋共享 IT 平台）。

把这些实践抽象出来，它们解决「没有厚层级，信息怎么上下通、左右齐」这个难题，靠的是同一套三件套。

一份共享的、人人可读的信息底座；一部共享的、人人信奉的使命价值观；一套单元之间责权清晰的市场式或明文契约接口。

AI 原生组织，只是把这三样各换了一个引擎：共享底座，换成机器可读的 a2a 上下文池；共享哲学，换成 agent 也在读、并据此行事的那部宪法；明文契约，换成 agent 之间互相调用的 a2a 协议。连单元的大小，都从心理学上的邓巴数，变成了被 token、熵和上下文窗口限定的物理结果。

这里必须补一条康威定律（Conway's Law）的警告。这条软件工程定律说的是：你们造出来的系统，结构上必然像你们组织内部的沟通结构。AI 是放大器，只放大你既有的结构，不凭空创造新的。多数公司会走那条看起来最省事的被动路：把 AI 当效率工具，直接塞进现有的职能筒仓，市场部的 AI 做市场，销售部的 AI 做销售。结果不是更少的墙，而是更多的墙、筑得更快更结实——每个 AI 带着本部门的上下文、目标和偏见，用远超人的速度，产出更多只顾本位的「优化」。你买不到一个会翻墙的 AI，想让 AI 打通壁垒，只能先靠人把那堵墙拆掉：先改变人的结构，把组织从按职能切分的竖井，重建成一个个跨职能、面向目标的阿米巴，再把 AI 交到这些阿米巴手上。

规律不新，软件行业已代你交过学费

下面这些规律，你可能第一次听说它们的名字，但每一条所对应的现象，想必你已经在自己的公司里见过。软件行业只是第一个被迫把它们总结成铁律的行业，因为它是第一个不得不大规模管理「工人」的行业，而这种工人恰好无状态、只认字面、上下文有限、但执行得无限快。

软件工程，是人类第一个不得不大规模管理一种「无状态、字面理解、上下文有限、但执行无限快」的工人的行业。这种工人，叫「程序」。今天每个行业都领到了同款工人，它的名字叫 agent。于是所有行业，都开始继承同一套硬规律。

AI 的行为，就是程序的行为。这套被继承的硬规律，至少有九条：

1. 项目已经延期，再往里加人，非但不能救火，反而更慢——新人需要老人带，沟通的线路不止翻倍，而是以平方级增加。软件行业把这条写进了《人月神话》，称之为布鲁克斯定律。
2. 想让一个岗位上的员工可以随时被替换、顶上，他手头工作的全部情况就不能只存在于他一个人的脑子里，必须全部记录在案，放在一个共享、随取随用的地方。软件行业管这叫无状态服务。
3. 同一份数据，在三张报表里对不上，几乎总是因为它有三个出处。想让事实不打架，每个重要事实就必须有且只有一个权威出处，其他地方都只能引用它。软件行业管这叫单一事实来源（SSOT, Single Source of Truth）。
4. 管理复杂业务，唯一有效的办法，是把它切成一块块既有意义、又能独立运转的单元。这些单元内部联系紧密，但对外只留最简单、最稳定的接口。软件行业管这叫高内聚、低耦合。
5. 单元与单元之间的协作，不靠开会、交情或默契，而要靠一份份白纸黑字、提前写明的约定。就像晨星公司要求同事之间互相签署的书面承诺（CLOU）那样。软件行业管这叫接口与契约。
6. 每天下班前，把所有人的工作自动汇总到一起，做一次全面的「对账」，让所有潜在的冲突在发生当天就被暴露和解决，而不是藏到项目后期变成灾难。软件行业管这叫持续集成（Continuous Integration, CI）。
7. 一个负责人一天能认真审完的材料就那么多，这个上限决定了整个公司的瓶颈。AI 可以十倍、百倍地提高产出，但最终需要人来拍板，而人的判断力带宽是有限的。软件行业的对应物叫代码审查（Code Review）。
8. 那些当初为了图快、图省事而做出的模糊决定、没有写下来的口头约定，日后都要连本带利地偿还——以误解、返工、内耗和无休止的扯皮为代价。软件行业为它起了一个专门的名字：技术债（Technical Debt）。在组织里，它叫「对齐债」。
9. 定期主动地停下来，重新梳理汇报关系、划分部门、归档或删除过期的资料，是把混乱重新压回可控范围的必要动作。软件行业管这叫重构（Refactoring）。

康威定律是第十条，上一节已经用过了。

决策者的新工作，与被调教的你

当你的团队不再由一个个「人」组成，而是一个个「人＋AI」的阿米巴，你作为决策者的工作也彻底变了。你不再靠督促进度、管理人事来推动组织。新的工作只有三件：维护宪法，守住最顶层的使命、愿景、价值观，让它在组织每个角落都还是最终、唯一的仲裁；设计切分，你最重要的决策，变成了在哪里下刀，把复杂的业务切成一块块边界清晰、上下文自洽的 token 分区，交给一个个阿米巴去深耕；守住对齐，盯住最宏观那一层，让所有阿米巴的合力，仍指向宪法写定的方向。

增长的杠杆也换了。过去增长靠招人，现在无节制地招人，只会带来熵增、沟通成本飙升，迅速撑爆整个组织的评审带宽和上下文窗口。

AI 原生组织的增长杠杆，从「招人」变成了「加清晰度」：把宪法写得更清晰，把切分做得更合理，再去复制那些共享同一部宪法、已经运转顺畅的阿米巴。

我们正处在一个别扭的过渡期。等模型的上下文窗口从今天的百万级涨到五百万、一千万——我估计还要 1 到 3 年——每个人能有效带的 agent 数、每个阿米巴能承载的业务复杂度，都会整体抬升一级。在那之前，这种一人带队、全员别扭的混乱，还会再持续一段时间。

但地基已经很清楚了。AI 只有无状态和上下文有限这两条特性，它像一面镜子，逼着你把自己的组织想清楚、写下来、对齐。被调教的从来不是 AI，而是你。既然你还没招一个人就已经在管一家公司，那就认真把它当作一家公司来搭建——从一部机器也能读的宪法开始。