这篇读的是 OpenClaw 基金会 11 月 5 日发的一篇博客，《Shattering Silos with OpenClaw Multiplayer》，作者 Joe Pishgar。OpenClaw 是一个开源的 agent 项目，由非营利基金会维护；Multiplayer 是它新推出的功能，让好几个人同时对同一个 agent 说话。
先说清楚材料性质：这是官方发布文，不是评测。语气很像发布会，开头就喊“我们带来了一颗拆楼用的破碎球”。文中的证据有三类：一场官方现场演示、基金会自己的内部使用情况，以及项目开源免费这类基本信息。没有第三方数据，也没有对照实验。
原文想解决什么
作者的出发点是“筒仓”，也就是部门墙。他的说法是，企业花了几十年想让各部门互相通气，结果 AI 来了，每个人又有了自己的 agent：工程、产品、市场、销售、QA、DevOps 各用各的，模型也不一样，有人用 GPT，有人用 Claude，财务还有人在一台“吵得像吹叶机”的机器上跑本地模型。
各自 prompt，各自攒上下文，结果当然各不相同。问题出在需要协作的时候：一个人得向同事解释自己做了什么、跟 agent 说了什么、它产出了什么；同事再把一个“大致的版本”喂给自己的 agent，指望关键信息别丢。作者的判断是：经常会丢。他用三句话概括后果，翻过来大概是：“上下文丢了，指令走样了，改动撞车了。”
基金会自己就被这事折腾过。按原文，他们有十几位全职维护者，还有一大批贡献者，其中不少人用 AI 大量提交代码，让所有人保持同步很痛苦。Multiplayer 就是为此做的。
全文顺序是：讲问题，讲一场现场演示，讲产品和研发之间的日常摩擦，讲内部使用情况，最后讲开源和免费。下面细读其中两段：演示，以及产品和研发那段。标题里“官司”这个说法就出自后者。
那场演示到底演了什么
演示是在旧金山的 GitHub Universe 大会上做的。设置很简单：两台笔记本连着同一个 OpenClaw agent，旁边一块大屏显示他们所在的 Fort Mason 的实时 3D 画面。工作人员请观众挑一个旧金山以外的地标，常见的选择是自由女神像。
过程分两步。
第一步，观众在第一台电脑上输入 “Add the Statue of Liberty”（加一座自由女神像）。还没按回车，工作人员就指给观众看：第二台电脑上，这句话正一个字一个字地同步出现。回车之后，Fort Mason 前面冒出一个低多边形的自由女神像，原文说它“疙疙瘩瘩，但认得出来”。
第二步，换到第二台电脑，输入 “Make that three times bigger”（把那个放大三倍）。雕像变成了三倍大。
原文真正想让人注意的，是第二步里的 “that”。第二个人没有说明“那个”指的是哪个东西，没有复制第一个人的 prompt，没有总结前面的对话，也没有让 agent 去重建别人做过的事。因为两个人本来就在同一个会话里，agent 手里是同一份上下文。
还有一个细节：多人的请求通过同一个队列协调，大家能看到 agent 什么时候在忙，不至于因为看不见状态，在同一时间盲目塞进相互冲突的指令。至于两条指令意思上打架怎么办，原文没讲。
作者说现场他们数过，有 11 次观众脱口而出“Oh my god”。他的解读是，观众兴奋的不是那座巨型雕像，而是开始联想到自己的工作。这个数字是官方自己数的，当现场气氛看就好。
我的批注：把演示拆开，被省掉的就是“交接”那一步。平时两个人协作，中间隔着一次转述：A 把自己的上下文压缩成几句话讲给 B，B 再讲给自己的 agent。Multiplayer 的做法不是把转述做得更好，而是让这一步不存在。
“官司”是怎么打起来的
接下来这段，原文写的是产品经理和工程师。我把它的过程照译出来：
PM 描述想要什么。工程师理解。活干完了。PM 看了说，这不太是我的意思。工程师解释为什么这么做。PM 澄清。工程师指出，新需求跟上周二定好的东西冲突。
作者的形容是，协作最后变成了一场庭审，产品是原告，研发是被告。再给双方各配一个 agent，各自带着各自的理解，摩擦只会更多。他给的方案是：产品、研发、QA、DevOps，甚至不懂技术的同事，在同一个环境里对同一个 agent 说话，看着彼此的指令写出来，一起调整，不用再在 agent 之间玩“传话游戏”。
回到标题的问题：能少打几场？我把这段里的回合分成两类看。
一类是上下文没传到位引起的。“这不太是我的意思”往往属于这类：PM 脑子里有的前提，没写进需求，也没到工程师的 agent 那里。“跟上周二定的冲突”也有一部分属于这类：上周二的约定只在某个人的记忆或某个 agent 的对话里。如果大家对着同一个 agent、同一段历史，只要前提被写进共享会话，它就留在大家都看得到的地方；PM 看到工程师下指令时，也能当场补一句。
另一类跟上下文没关系：需求本身没想清楚，两边优先级不一样，或者上周二的约定本来就该推翻。这些争执换了工具还会在，只是吵的地方从会议室换到了共享会话里。
所以我的回答是：能少的是第一类。至于第一类在你们团队占多少，原文给不了答案，得看自己的返工记录。作者自己也留了余地，他说 Multiplayer“治不了糟糕的管理，也治不了那个总在约会议讨论要不要多约会议的人”，只是在处理“一大块组织摩擦”。
证据到哪一步为止
除了现场演示，原文给的持续使用证据只有一条：基金会内部有 50 多人在同一个共享环境里协作，并且通过 Focus Week（维护者和贡献者围绕某几个项目优先级集中协作的活动）继续改进体验。
项目本身的信息：MIT 开源许可，不绑定模型，自己带模型（OpenAI、Qwen、Claude、本地模型都可以），可以跑在自己电脑、VPS 或别的地方。原文说已有 83,000 个 fork，Multiplayer 同样免费。
原文没讲、但团队试用前绕不开的几件事：
- 谁能往共享 agent 里下指令，能不能有人只看不改；
- 队列解决了“同时说话”，两个人方向相反的指令最后听谁的；
- 几十个人往同一份上下文里说话，agent 还分不分得清；
- 一个结果是谁的哪条指令造成的，事后能不能查。
演示是两个人改一个 3D 场景，和一个产品团队几十人共用 agent 做真实需求，中间还差这些问题的答案。
读完的判断
原文最后提的问题我觉得是对的：行业花了大量时间讨论一个人加一个 agent 能干多少活，却很少讨论这些各自高效的人怎么一起干活。
对 PM 来说，共享 agent 上下文值得试的场景，是那些返工主要来自“信息没传到”的协作，比如需求细节多、来回补充多的功能。如果你们团队的争执主要在优先级和取舍上，这个功能帮不上大忙。
软件本身免费开源，但模型要自己带，模型费用和部署、试用的时间需要自己算。
参考：Joe Pishgar，Shattering Silos with OpenClaw Multiplayer，OpenClaw Blog，2026-11-05，https://openclaw.ai/blog/shattering-silos-with-openclaw-multiplayer