团队共用一个 Agent，终于不用转发聊天记录了

一个团队让 Agent 干活，最容易断掉的往往不是模型的上下文窗口，而是人之间的交接。

产品同学在群里补了一句需求，工程同学在另一台电脑上翻上一轮对话，负责人再把「它刚才已经试过什么」复制进新的会话。三个人都在推进同一个任务，Agent 却被迫从头认识一次现场。聊天记录越长，谁改过目标、谁已经批准、哪条约束不能碰，越像散在桌上的便签。

OpenClaw 的 Multiplayer 想处理的，就是这个交接问题。按官方 Multiplayer 文档，一个团队可以共用同一个 Gateway：同一批会话能被成员打开、补充上下文和引导；系统还会保留创建者、当前负责人，以及实际发出提示的人。控制台会显示谁正在看、谁正在输入。

这不是「多人一起围观一个聊天框」那么简单。一个可持续跑任务的 Agent，往往连着仓库、浏览器、命令、工单或某些内部服务。交接如果只靠转发聊天记录，人的记忆会丢，Agent 的任务状态也会丢；但把它们放进同一个共享会话，又会把权限问题一起带进来。

本文没有部署或实测 OpenClaw。下面只根据官方公开文档，拆一张适用于团队 Agent 的上线路径卡。

先把人从「上下文搬运」里拿出来

多人协作时，真正稀缺的不是再开一个模型窗口，而是每个人都能看到同一份任务现场。

OpenClaw 的设计里，一段共享会话有三层信息：谁创建了它、现在由谁负责、哪些人真的给过 Agent 指令。这个区分看起来很细，却比「所有人都能说两句」实用得多。创建者负责交代问题从哪来；负责人接住结果；参与者留下具体补充和判断。后来的人不需要猜上一轮对话是谁拍板的。

它在代码任务上的用法也很直白：团队成员能在同一个会话里查看 Agent 做过什么、补充限制、继续引导下一步；如果启用了 Git 共同作者标记，提交可以保留共同参与者，拉取请求还能回到这段会话。对需要交接的修复、排查或小型功能，这比在聊天工具里发一串截图要可靠得多。

图：共享会话的工作方式示意，不是 OpenClaw 官方界面。本文没有进行独立部署实测。

不过，别把「共享上下文」理解成「大家都可以随手改」。一段任务能接力，前提是每个人加入时都知道自己补的是事实、判断还是最终决定。没有这个分工，共享会话只会把原本散落的混乱搬进同一块屏幕。

我会在每个共享任务开头留一张很短的卡。它不需要写成流程文件，关键是让下一位人和 Agent 都读得懂。

任务：修复支付页的订单状态不同步
当前负责人：后端值班同学
可补充：复现步骤、日志位置、验收条件
允许动作：查看指定仓库与测试环境、运行既有测试、提交修复建议
必须人工确认：改生产配置、访问真实订单、合并代码、对外发送消息
完成标准：给出原因、改动、测试结果和回滚方式

这六行没有让 Agent 变聪明，却能少掉很多「我以为你已经说过了」。它也把任务状态从某个人的私聊记忆，变成团队可以复核的交付物。

共享任务，不等于共享所有权限

OpenClaw 官方在文档里写得很明确：一个 Gateway 是一个信任域。 能给带工具 Agent 发消息的人，实际共享的是这名 Agent 被委托的工具权限；有操作员权限的人，也共享同一个控制平面。

这句话比功能介绍重要得多。

假如一个 Agent 可以读仓库、跑命令、访问某个测试服务，那么「让实习生、外包同学或合作伙伴也来看看同一会话」并不只是多开一个观看席。只要他能发出会改变任务走向的指令，就要先问：这条指令会碰到什么工具？谁能批准？日志能不能追？会话是不是必须在沙箱里运行？

官方给的方向是角色约束。团队可以按角色限制成员能触及的会话、可使用的 Agent、允许的操作 scope，以及新会话是否必须进入 sandbox。它解决的不是「所有人都不能动」，而是把不同人的动作范围说清楚：有人可以看，有人可以补充上下文，有人可以接手，有人才能批准外部动作。

图：本文根据官方“一个 Gateway 是一个信任域”的说明绘制。它不是官方控制台截图。

这里有一个特别实用的分界：

• 同一支彼此信任的产品、工程和运营小组，可以先共享一个低风险任务的会话；把谁能查看、谁能推动、谁能批准写进任务卡。
• 需要接触真实客户数据、生产密钥或外部执行渠道的任务，先缩小 Agent 的工具范围，再决定是否让多人接手。
• 互不信任的人、不同客户或不同组织，不要硬塞进同一个 Gateway。官方建议为他们拆成独立 Gateway，最好进一步拆到独立 OS 用户或主机。

最后这一条并不保守。共享会话解决的是协作摩擦，独立 Gateway 解决的是隔离。把两件事混在一起，通常会在任务越跑越顺之后才出问题。

先用一个真实任务试跑

如果团队已经有一个常驻 Agent，不必为了 Multiplayer 重做所有工作流。挑一个已经频繁交接、但外部影响很小的真实任务就够了：整理一次故障复盘、补完测试失败日志、给内部工具开一个可审查的修复建议。

开始前只做四个决定：会话由谁创建；当前 owner 是谁；每个参与者能否执行工具；哪些动作必须等人工确认。任务结束时，再确认一件事：下一位接手的人，能不能只看这段会话就复述目标、约束、已验证的事实和剩余风险？

能，说明共享的不是一串聊天记录，而是可继续推进的工作。

不能，也别急着往系统里加更多 Agent。先把任务卡写短一点，把权限缩窄一点，把负责人写得更清楚一点。多数团队还没缺到第二个 Agent，先缺的是一条谁都看得懂、也没人能悄悄越过的交接线。

你们团队里，哪一种 Agent 任务最常因为「上下文接不上」而反复重来？

—— 小岛 AI