给每个部门配一个 agent 之后，他们更不说话了

企业花了很多年拆筒仓，请咨询、搞敏捷、上 OKR。AI 来了之后，筒仓数量按部门翻了一倍。

工程一个 agent，产品一个，市场一个，销售一个，QA 一个，财务那边有人在用一台风扇声像商用吹叶机的机器跑本地模型。大家各自 prompt，各自积累上下文，各自拿到不一样的结果。人类之间的跨部门沟通没解决，先教会了各自的 agent 互不搭理。

OpenClaw 在 GitHub Universe 展台的演示很简单。两台笔记本连同一个 agent，旁边一块大屏，实时 3D 渲染着他们所在的 Fort Mason。观众从旧金山以外挑一个地标，多数人挑自由女神像。

第一台输入 Add the Statue of Liberty。还没按回车，第二台上已经逐字出现这句话。按下去，一座低多边形、边缘有点塌的自由女神像落在 Fort Mason 旁边。

换第二台，输入 Make that three times bigger。第一台同步看到。提交，雕像大三倍。

全程没人解释 that 指什么，没人复制上一轮对话，没人让 agent 重建同事的思路。

博客里写，现场数到 11 次自发的 oh my god。他们自己数的。

机制不复杂：共享 workspace、共享 agent、共享上下文，请求走同一个队列，所以看得到 agent 正忙，不至于闭眼往里塞互相冲突的指令。基金会内部已有 50 多人在同一环境协作。MIT 协议，模型无关，可自托管，带自己的模型，OpenAI、Qwen、Claude、本地都行。83000 个 fork。免费。

官方博客里有一段产品与工程的日常：PM 描述需求，工程实现，PM 说不是这个意思，工程解释为什么这么实现，PM 补充，工程指出新要求和上周二定的东西冲突。有了各自的 agent 之后，这段对话还要在两边各跑一遍，中间靠人肉摘要传递。传着传着，重要信息就没了。

演示顺，评论区的问题更接近日常。

有网友说，自己一个任务开一个 agent，一半时间花在把答案从一个窗口复制到另一个窗口。

有人担心两个人同时改同一个计划，还是想先有个沙箱，再碰生产环境。

有人问冲突编辑怎么处理。他维护的项目里，两个贡献者并行修同一个规则 bug，本地状态各不相同，合并才是真正的工作量。

还有人对共享上下文本身不放心：一个 agent 的记忆漏进另一个团队的规则怎么办，市场部的 prompt 把工程部的 agent 弄坏怎么办。也有人直说，共享上下文在多数场景是好事，但对自己不合适。

这些担心指向同一个缺口：共享队列管的是并发，权限边界管的是该不该。

能看到对方在打字、能排队提交，不等于能决定谁有权改哪一段。市场部的 prompt 会不会污染工程部的上下文，取决于 workspace 能不能切成可授权的规则集，而不只是一个谁都能进的房间。博客没讲这个。

还有一个前提被跳过：共享上下文要求大家信任同一个 agent 的输出。信任不成立时，共享上下文会让错误传播得更快。以前的筒仓至少能让错误停在部门内部。

行业花了很多篇幅算一个人用 agent 能干多少活：代码产量、需求草稿速度、省下多少小时。这些账都好看。一群人各自高效、再花半天同步上下文，这笔账很少人算。

OpenClaw 把这个问题摆上桌了。筒仓能不能真拆掉，要看冲突和权限怎么落地。演示里的自由女神像可以大三倍，生产环境里的规则不行。

原文：Shattering Silos with OpenClaw Multiplayer

Multiplayer 文档：docs.openclaw.ai/start/multiplayer

原推：OpenClaw on X