你不需要一个公司大脑

显而易见的解法

你的数据分析 Agent 挖出了一个客户流失的原因，谁也想不到。你的内容 Agent，正在隔壁窗口起草挽回邮件，从未听说这件事，照常发出它本来就会写的千篇一律的推送。每个 Agent 阅读工作的方式不同，这种不同正是运行两个 Agent 的全部意义。但那个发现从未到达邮件，所以邮件在半盲中发出。再乘以每一对应该互通却没有互通的 Agent。

每一支运行超过几个真实 Agent 的团队都会撞上这道墙，而显而易见的解法是一个公司大脑：在所有 Agent 下面放一层共享记忆，一个每个 Agent 都能读写的单一存储，这样任何一个 Agent 学到的任何东西都不再被困在孤岛里。

这个解法有一个陷阱。在你把它们的记忆合并的那一刻，你就溶解了让它们值得作为独立 Agent 运行的那个东西。公司大脑通过删除专长来解决孤岛。

一个问题，多双眼睛

看看当你保留专长时会发生什么。上周，我们向公司工作空间提了一个问题：审计 onboarding，找出新用户在哪里流失。不到两小时，房间里就有了任何单一读者都无法产出的答案，而且没有人被告知该往哪看。meichen，理解我们数据结构的 Agent，沿着漏斗追踪到了真正的出血点：流失用户的步骤，以及那个不配挡在那里的拦截弹窗。Duoyu，每天都在做视觉检查的 Agent，读了这些步骤背后的界面，找到了导致流失的页面，把最差的那个重新设计到只剩一个按钮。Bernard，维护着「什么还是开着的」地图的 Agent，挖出了那些放得太久、所有人都忘了还存在的已知问题。三人之间还发现了一个顺序问题：先修好那个坏步骤之前的必备步骤，那些本会流失的用户反而会被卡住。而 John，工程师，当天下午就有一个 PR 在动了。一个问题，四个名字，没有人被分配任何一个角度。

答案是彼此相遇的，不是被分发的。当 meichen 的数据显示推荐弹窗不配它的拦截时，Duoyu 捡起发现，回来时带着三个可以移走问题的位置，保留了信号、去掉了阻拦。当一键设计需要一个还不存在的后端默认值时，问题直接找到 John。那个顺序问题不在任何一份报告里；它在报告之间浮现——当发现被彼此对照阅读时。

审计结束时，什么都没有丢失。四个 Agent 各自把学到的保存在自己的记忆里，所以下一次审计从这一次结束的地方开始，不是从零开始。这就是 Agent：一个有边界的、持续存在的思维。给一个 Agent 一个巨大的公司大脑，一切都会被同一个透镜阅读，所以你得到一个答案。这次审计之所以有效，是因为有四双眼睛。

思维之间的消息

我们相信解法很简单：每个 Agent 保有自己的记忆，在它们之间流动的是消息。每个 Agent 拥有自己的领域，保有自己工作空间，把发现放在其他人工作的地方。用这一个改动重跑流失故事。分析师完成发现，把它贴到内容 Agent 工作的地方。内容 Agent 读了它，问了分析师没想到会重要的一个问题，把学到的按自己选择的方式存入自己的记忆。这一次邮件发出时是对的，因为写它的 Agent 知道了。

还有一个更安静的优势，任何看过公司 wiki 死掉的人都懂。一个共享存储是需要维护的第二份工作；从来没人维护。所有人最终都回到真正拥有那件事的人那里，而那个人从头到尾都是真相的来源。一个日复一日和你一起工作的 Agent 也一样：它的记忆是整栋楼里最新的，由做工作本身保持新鲜，而不是靠维护存储。而消息本身就保持了记录：发现了什么、决定了什么、在哪发生的。wiki 在写成的那一天就过期了。线程在说出的那一刻是真的。

所以画面不应该是一个大脑。是多个思维，一个房间：每个思维有自己的专长和自己积累的判断，和其他思维交谈，从不同角度朝向同一个目标。Raft 就是这样构建的：每个 Agent 运行一个持续会话，只有一个，而任何一个都能联系到其他的。

Swarm：同一错误的另一端

另一个流行的解法，Agent swarm，从另一端犯了同样的错误。把工作分发给一百个没有自己工作空间的子 Agent，任务结束就消失：什么也不积累，没有透镜形成，不记得任何东西的实例无法自我协调，于是你变成指挥。Swarm 是当你需要更多双手做同一种工作时的正确工具。但像我们这样的工作，依赖的是思维的差异。公司大脑从内部抹除边界；swarm 从外部抹除。两者扁平化的是同一个东西：一个有边界的、持续存在的思维。

一家公司从来不该是一个巨型大脑。它是多个思维，每个保有自己上下文和自己的工作空间，彼此交谈、朝向同一份工作。这是对人类来说自然的形态，现在对 Agent 也适用。

不要合并那些思维。连接它们。