OpenClaw 多人共享 Agent：两台设备，一个上下文

两台设备可以安全地共享同一个 OpenClaw Agent，但前提是你要把“队列”和“持久化”当成两件事来处理。共享会话负责保存上下文，active-tasks.md 这类文件则负责记录真正的任务承诺。

这就是整个机制的关键。OpenClaw 2.0（版本 v2026.8.1，于 2026 年 8 月 30 日公布）在 Gateway 仍然属于同一个共享信任域的基础上，加入了多人共享会话功能。因此，两部手机、两台笔记本，或者两个人，都可以协同操控同一次运行，而不是各自得到一个私有分支（docs.openclaw.ai）。官方文档也明确说明，所有权、在线状态和角色只是协作辅助机制，并不能把互不信任的用户隔离开来（docs.openclaw.ai）。文档描述的是功能边界，而用户真正容易踩坑的地方，则集中在队列、会话生命周期和记忆这三件事上。

手机在沙发上，笔记本在桌面上：到底哪里会出问题

现实中常见的双设备场景，往往并不是两个人，而是一个人把手机当遥控器，把 Mac Mini 或 VPS 当主机，通常还会通过 Telegram 操作。有位用户的描述很直接：通过 Telegram 请求“我的 OpenClaw Agent Monica 在我的 Mac Mini 上本地安装 mem0”（x.com）。

当第二台设备或第二个人加入同一个 Agent 后，用户报告过的故障主要有四类：

消息悄悄消失。社区里最值得记住的一条经验是：启用 queue mode，确保消息不会静默丢失；同时用 active-tasks.md 保存持久状态以便崩溃恢复，再配合会在重启时重新读取它的 Boot.md（x.com）。缺少这套组合时，Agent 正在处理上一轮任务期间收到的消息，本质上只是存在丢失风险的对话文本，而不是已经保存的工作项。
压缩或重启后，指令蒸发。一位 Reddit 用户说得非常尖锐：

“这里没有持久化任务队列——当 Agent 说‘我会处理’时，那只是一个对话承诺。”——u/Brave_Nobody_6909，r/openclaw

同一讨论串提到，这些承诺会在压缩或重启后消失，Agent 也可能不再执行已经保存的运行手册。另一篇由维护者级别作者撰写的说明则揭示了背后的典型模式：当用户误解记忆处理机制时，Agent 可能“前 20 分钟表现完美”，随后“悄悄忘掉你的指令并开始失控”（x.com）。

会话在你不知情时重置。Telegram 频道曾采用 thread: { mode: "idle", idleMinutes: 180 } 这样的默认设置，会在闲置数小时后重置会话。一位用户在手机作为第二屏幕的场景中遇到遗忘问题后，把它改成了 4 天（x.com）。上下文溢出会让情况更糟：工具调用过多时，最后一条消息可能被重新注入，导致 Agent“反复回应同一件事”，随后“悄悄退化”（x.com）。
还没开始多人协作，配对就先坏了。一次升级后，已配对设备丢失了 operator.read/operator.write 权限范围，陷入无限配对循环，工具也无法使用；创始人的回应是：“这是我在修复一个潜在安全问题时用力过猛了”（x.com）。中文用户也遇到过同样的问题：设备报错 1008: pairing required，本地设备一直卡在 Pending 队列中，直到执行 openclaw devices list，再运行 devices approve <UUID> 才恢复（x.com）。

在线状态只能告诉你有人正在输入，但没有任何指示器能把排队中的消息自动变成已保存的任务。

一个 Gateway，一个信任域：共享会话、独立 Agent，以及所有权边界

OpenClaw 2.0 最重要的变化就是共享会话：其他人可以加入正在进行的工作，并保留原有上下文。独立评测认为，这标志着 OpenClaw 从单人操作转向协作工作（eesel.ai）。但在底层，官方文档中的两个概念才真正决定了你的配置方式。

多人模式指的是多个可信用户共同操作一个 Agent。每个共享会话都会记录三层信息：不可变的创建者（createdActor，只写入一次）、可以重新指定的所有者（类似 GitHub 的 assignee，可随时更改），以及记录实际发起过提示的参与者历史（docs.openclaw.ai）。在线状态可以显示查看者和输入者，但输入中的草稿不会发送给模型，也不会进入对话记录。由于多人的输入可能被合并到同一轮中，轮次归属明确被定义为尽力而为（docs.openclaw.ai）。实际使用时，如果第二个频道在 Agent 正在调用工具期间发送后续消息，这条消息会进入记录，但当前运行中的轮次仍会先完成；因此，第二条指令更像是在引导下一步，而不是中断当前任务（docs.openclaw.ai）。

多 Agent 模式指的是一个 Gateway 进程承载多个相互隔离的大脑。每个 Agent 都有自己的工作区、agentDir（认证配置、模型注册表）以及位于 <agentDir>/openclaw-agent.sqlite 的 SQLite 会话存储（github.com）。绑定规则会把每个入站频道事件路由到对应 Agent，匹配范围最具体的规则优先；不同 Agent 之间绝对不要复用同一个 agentDir，否则它们会互相覆盖 auth-profiles.json（stack-junkie.com）。一个最小示例是：{ agentId: "coding", match: { channel: "telegram", accountId: "coding-bot" } }，它会把一个 Bot 路由给一个 Agent。

请记住这句话：“一个 Gateway 就是一个信任域”（docs.openclaw.ai）。角色、所有者过滤器和头像，都不能隔离互不信任的用户；如果用户之间彼此不信任，就应该使用独立的 Gateway，最好再使用独立的操作系统用户或主机。

状态	一个共享 Agent（多人共享会话）	独立 Agent（多 Agent）
对话记录	共享；两台设备看到的是同一个线程	按 Agent 隔离，分别存储在 SQLite 中
上下文窗口	共享；引导内容会合并到正在运行的轮次中	隔离；默认无法跨 Agent 搜索对话记录
记忆 / 工作区文件	共享 `AGENTS.md`、笔记和 Wiki，除非按 Agent 分开管理	工作区彼此独立；只有通过 `~/.openclaw/skills` 或 `extraDirs` 才能共享技能（github.com）
模型凭据	可以使用每个人自己的账号；系统只显示标签，计费时仍可能使用共享的备用账号（docs.openclaw.ai）	每个 Agent 使用自己的 `agentDir`；OAuth 刷新材料默认不能直接迁移，需要显式选择共享（github.com）
Cron / 自动化	对 Gateway 可见；拥有 `operator.admin` 权限的管理员可以管理其他人的任务（docs.openclaw.ai）	只有在 `agentToAgent` 和可见性设置允许时，才能跨 Agent 访问（github.com）
待处理队列	整个会话共用一个队列	每个 Agent 都有自己的队列和路由

如果两台设备属于同一个人，选择左栏。如果是两个人，而且不应该经常看到对方的历史记录，选择右栏；如果必须对不可信用户实施访问隔离，就使用两个 Gateway。关于伴侣共享一个 Bot，Reddit 上的建议也基本一致：“创建 2 个 Agent，使用同一个认证配置，但一个针对你……另一个针对你的妻子”（u/mr-cto-apps，r/openclaw）。在另一个讨论共享单个 Telegram Bot 的帖子中，一位用户建议：“处于这种情况的大多数人，直接运行两个实例就好”（u/dertobi，r/openclaw）。即使 2.0 已经加入共享会话，这个建议对于需要彼此独立的私有工作仍然适用。

Agent 忙着工作时，你的第二条消息会去哪

可以把消息分成三个桶来理解。很多用户正是在这三个边界上混淆概念，最终丢掉工作。

第一桶：会话队列。Agent 工作期间发送的文本会追加到当前会话中。队列模式会让它等待，而不是直接丢弃；在线状态则告诉你 Agent 是否正在处理当前轮次。此时发送的消息会引导下一轮，而不会中断当前这一轮。输入中的草稿预览是临时的，永远不会进入上下文（docs.openclaw.ai）。第二台设备发送的消息最好简短且明确，例如“这件事完成后再做 X，不要重新启动 Y”，因为当多人的引导内容被合并时，文档明确表示轮次归属只能做到尽力而为（docs.openclaw.ai）。

第二桶：持久化任务。排队中的消息不等于持久化工作项。如果 Gateway 重启、会话发生压缩，或者你执行了 /new，对话里的承诺都可能消失。能在重启后保留下来的社区方案不是另一条消息，而是文件：用 active-tasks.md 保存崩溃恢复状态，再配合一个让 Agent 在会话和 Gateway 重启时读取它的 Boot.md（x.com）。记忆工具可以重新注入上下文，但一篇广泛传播的说明提醒说，被加载的记忆本身也可能被摘要掉：“记忆确实存在磁盘上，只是 Agent 失去了逐步读取它的能力”（x.com）。

第三桶：定时工作。Cron 和 Automations 只有在 Gateway 运行时才会执行；如果主机进入睡眠，定时任务也会停止（eesel.ai）。有用户报告称，Cron 运行期间会不断把会话历史灌入上下文，让 Agent“基本无法使用”，并建议按 Telegram 主题隔离上下文（x.com）。定时任务适合周期性工作，但绝不能拿来替代排队发送后续指令。

队列检查结果可能落后于实际状态：有讨论提到，请求明明能看到正在排队，但 /subagents 和 /tasks 却什么也没有显示（reddit.com）。因此，应该把第二桶中的文件当成重启安全检查点，而不是只相信队列界面显示的内容。

不会丢指令的双设备配置

下面这套配置适合一个人使用笔记本加手机，也适合两个可信队友共同操作一个共享会话。它参考了官方快速设置和生产运行手册（docs.openclaw.ai），同时加入了社区反复验证的防丢指令做法。

把 Gateway 放在始终在线的主机上，并通过身份访问。小型 VPS、办公室 Mac 或 Mac Mini 都可以。应将 Gateway 绑定到 loopback，再通过 Tailscale Serve 或 Cloudflare Access 暴露访问，不要直接开放公网端口，也不要让所有人共用一个 Token。基于身份的访问可以在会话和提交记录中标识每个人，并归属提交贡献；共享 Token 则会让所有人使用同一个所有者配置（docs.openclaw.ai）。
让两台设备加入同一个会话，而不是各自创建会话。在每台设备上打开 Control UI 或聊天频道，明确指定会话所有者（Control UI 中的 Assign to me / Assign to，或使用 sessions 工具的 assign_owner），交接时使用 @提及。私聊和群聊需要分别配置允许列表（docs.openclaw.ai）。重新指定所有者只会改变责任归属，不会改变与创建者绑定的共享权限或归档权限，因此最好保持创建者不变。
开启队列，并让任务经得起重启。把共享会话切换到队列模式，让轮次进行期间发送的消息等待处理，而不是相互竞争——用户报告称，不开启队列时消息可能悄悄丢失。在工作区中维护一个 active-tasks.md，每项承诺占一行，并标记 done / doing / next；再添加一个 Boot.md，指示 Agent 启动时读取它（x.com）。在依赖第二台设备之前，先确认模型确实能够响应，因为仅仅保存凭据并不能证明配置成功（docs.openclaw.ai）。
延长面向手机频道的会话生命周期。如果 Telegram 充当第二块屏幕，而线程使用前面提到的 thread: { mode: "idle", idleMinutes: 180 } 重置设置，就应该针对长时间任务延长时限（一位用户改成了 4 天），同时分开管理不同主题，避免 Cron 输出淹没共享上下文。
让每个人使用自己的模型账号。Gateway 配置可以保存个人凭据；新会话会优先使用个人默认设置，而不会改变 Gateway 的默认配置。其他用户看到的也只是人员级别的标签，不会看到邮箱或账号 ID（docs.openclaw.ai）。凭据必须通过受保护的 UI 或隐藏输入的终端提示录入，绝不要直接在对话中粘贴，否则它们会进入共享记录。
做一次端到端验证。从第二台设备在当前轮次进行期间发送一条消息，确认它被保留，并在当前轮次完成后得到处理；随后重启 Gateway，确认 active-tasks.md 能恢复这项承诺。官方生产检查清单的收尾方式也是如此：在宣布完成前验证完整流程（docs.openclaw.ai）。

避免共享上下文腐化的几条规则

用户描述的大多数上下文腐化问题，都可以用三条规则覆盖。

每次写入记忆都标注作者。最隐蔽的故障，是没有归属的规则不断积累，最后谁都不敢删除：“共享上下文使用六个月后，里面充满了没人知道来源的规则，所以没人觉得自己有权删除它们。”对应的建议是“每次写入记忆都记录作者”（x.com）。问题的根源，就是共享写入却没有作者信息。持久笔记开头标明是谁提出、何时提出，并每月清理一次。

降低信任级别的用户要放进沙箱。角色可以限制会话访问范围、允许使用的 Agent 和操作员权限；访客会话还可以通过 workspaceAccess: "none" 强制使用私有工作区，让文件和 Shell 工具无法直接进入共享 Agent 工作区（docs.openclaw.ai）。私密草稿应放在 Draft 会话中，但要记住：草稿不会出现在其他用户的侧边栏里，却始终对管理员可见（docs.openclaw.ai）。

知道什么时候该停止共享。一位运行多 Agent 的用户把上下文串扰称为“最大的实际挑战”，并表示各个 Agent 会“逐渐越界到彼此的领域”（u/BP041，r/openclaw）。中文社区的建议更直接：先调好一个 Agent，再按设备复制——“帮助它克隆到新设备”，让调优后的配置变成“每人一个”（x.com）；只同步记忆和点文件，不要同步凭据和正在运行的会话（x.com）。这也对应了官方文档提供的退出方案：使用按 Agent 隔离的 Memory Wiki 保管库（vault.scope = "agent"），明确指定共享 Markdown 目录，而不是跨 Agent 搜索对话记录；如果需要真正的隔离，就使用独立 Gateway（github.com）。

常见问题

两台设备可以同时共享一个 OpenClaw Agent 会话吗？

可以。两台设备加入同一个会话；上下文属于会话，而不是某台设备。指定所有者并开启队列模式，让第二台设备发送的消息等待处理（docs.openclaw.ai）。

为什么压缩、执行 `/new` 或重启后，指令会消失？

因为聊天消息并不是已存储的任务。压缩会总结上下文，/new 会启动全新会话，而重启会丢失内存中的状态。请把承诺写入 active-tasks.md，并用 Boot.md 在启动时重新读取（x.com）。

两个人应该共享一个 Agent，还是每人运行一个？

如果两个人需要同一个线程、同一套记忆和同一个队列，就共享一个 Agent。如果历史记录、凭据或权限不能混用，就每人运行一个 Agent（或者各自使用一个 Gateway）；多人功能并不能提供安全隔离（docs.openclaw.ai）。配置好 GitHub 归属后，共享引导还可以在提交记录中带上 Co-authored-by trailer（docs.openclaw.ai）。

共享一个，还是复制一个：30 秒做决定

你的情况	应该这样做
一个人，笔记本 + 手机	一个共享会话，开启队列模式，使用 `active-tasks.md` + `Boot.md`，延长闲置超时时间
两个可信队友，共同处理一项任务	一个共享会话，明确指定所有者，用 @提及完成交接，所有记忆写入都标注作者，并为初级成员配置访客沙箱
两个人，各自处理不同工作	使用两个 Agent（或两个 Gateway），通过 `~/.openclaw/skills` 共享技能，绝不要共享 `agentDir`
不可信用户或面向客户的访问	在独立的操作系统用户或主机上运行独立 Gateway；通过 Session Share 以只读方式暴露选定会话（docs.openclaw.ai）

队列模式可以避免两个输入者互相覆盖，但它并不能解决相互冲突的指令——合并后的输入仍然可能混杂。真正能让指令在重启后继续存在的，是文件。