OpenClaw 2.0 Multiplayer：自托管AI助手多人协作的边界隔离实践

如果有两个人要同时使用同一套自部署 AI 助手，会发生什么？

听起来很简单：多加一个会话窗口、多拉一个账号进来，好像就行了。但真正用过单人模式的人会立刻撞上一面墙——两个人的日程其实写进了同一份待办清单，A 让 Agent 记住的“预算按 5 万做”，B 在另一个会话里提问时也被自动带了出来。要命的是，A 手动批准过的那条高风险命令权限，B 这边也可能默认生效。

OpenClaw 2.0 的 Multiplayer 多人协作功能，解决的正是这个非常具体的工程问题：它不是单纯加了一个“多窗口”交互界面，而是把一个可以自托管的 Agent Runtime，从“服务一个用户”变成“在同一套运行时里服务多个参与者，同时把工作区、记忆、审批和 Skill 边界都分开”。

在这篇文章里，我会先用一个相对完整的视角讲清楚 OpenClaw 2.0 Multiplayer 到底改变是什么，接着给出可上手的环境准备、安装配置、Skill 编写方式，以及多人模式下最容易踩的坑。如果你已经单人跑通过类似的自托管 Agent，那么这篇内容可以直接帮助你快速进入多人协作模式。

1. 多人协作到底解决什么问题？

1.1 单人模式下看不到的三类隐患

先说说大多数人第一次把自托管 Agent 从“个人工具”推向“团队工具”时的真实困境。

第一种是上下文污染。单人模式下，会话和会话之间虽然有一定隔离，但长期记忆、工作区文件、审批规则往往都挂在同一个 Agent 账号下。两个人同时使用时，A 说的“帮我记住明天下午有客户会议”，很可能在 B 的会话里被当成有效记忆调用。更隐蔽的是，如果 A 让 Agent 总结某个项目文档，B 的会话也拿到了同样的上下文，这就不是效率问题了，而是信息边界问题。

第二种是权限不可分。自托管 Agent 通常需要执行命令、读写文件、调用外部 API。单人模式下，审批规则是“你批准过就记住”，到了多人使用时，这个“全局放行”会产生很大风险。A 是开发人员，经常需要让 Agent 执行git push；B 是运营人员，可能只需要查询天气和写周报。如果规则不做区分，A 不小心批准的某个命令，会让 B 这边也拥有同样的执行能力。

第三种是协作语义缺失。两个人同时维护一个项目空间时，谁改了什么、谁批准了什么、哪个任务对应哪个用户，在单人模式下都是缺少记录的。Agent 只是“被动地”执行指令，它并不清楚当前说话的人是谁，也不知道该以哪套记忆和权限来处理请求。

1.2 Multiplayer 带来的是“运行时级”的区分

OpenClaw 2.0 的 Multiplayer 模式，核心思路是让 Agent Runtime 具备“参与者（Participant）”概念。每个参与者拥有自己的会话入口、工作区目录、记忆作用域和审批规则。

举例来说：

• 同一个家庭里，父母和孩子可以共用一台主机上跑的 Agent。父母拥有完整日程管理和家庭开支记录权限，孩子只被允许查询作业、设置提醒，不能触碰家庭财务管理类 Skill。
• 一个小型研发团队里，不同工程师可以拉同一个 Agent 进群，但各自的工作区目录是分开的。Agent 不会把张三项目里的待办事项推荐给李四，除非两个人都主动加入同一个“共享空间”。
• 在一个需要审计的场景里，每一条危险命令审批、每一次敏感文件读取都可以追溯到具体参与者，而不是一句笼统的“用户已批准”。

所以如果你问 Multiplayer 真正的价值是什么，我的判断是：它把 Agent 从“一个人私有的软件”变成了“一个可以设置边界、划分角色、审计轨迹的团队基础设施”。想用好这个功能，重点不是研究多人聊天怎么接，而是先学会配置工作区隔离和记忆边界。

1.3 什么人最适合读这篇文章

如果你符合以下任意一条，这篇文章值得读完：

• 已经用 OpenClaw 或类似框架自托管过 Agent，想让家人或团队成员也接入；
• 准备从 2.0 开始部署，想直接一次性规划好多人协作的目录结构和权限模型；
• 遇到过多用户共享 Agent 后记忆串线、权限越界、Skill 互相干扰的问题；
• 需要评估把自托管 Agent 引入团队工作流时的安全边界，尤其是审批和审计能力。

对完全没有部署过 Agent 的读者，我的建议是先按第 3 章把单人环境跑通，再进入 Multiplayer 配置。

2. OpenClaw 2.0 核心概念速览

为了避免后面实操时对术语产生误解，先花点篇幅把高频概念讲清楚。

2.1 Runtime、Workspace、Skill 和 Memory

Runtime可以理解成整个 Agent 的运行底座。OpenClaw 以本地或云服务器作为宿主机，启动之后，Runtime 负责加载模型、调度 Skill、维护会话和记忆、执行审批规则。Runtime 相当于操作系统内核，而不是某一个具体的聊天界面。

Workspace是 Agent 的“办公桌”。很多实际任务都需要读写文件、生成中间产物，这个目录就是它们工作的物理空间。单人模式下默认是一个全局目录，多人模式下应该调整为按参与者或按项目拆分的目录，避免文件互相覆盖。

Skill是给 Agent 扩展能力的“技能包”。一个 Skill 通常包含描述文件、执行脚本和可能的依赖。Skill 解决的问题是：不让 Agent 在一个对话里通过“灵光一闪”完成复杂任务，而是用一套可复用、可测试、可分享的能力模块，去完成某个特定领域的工作。

Active Memory（主动记忆）是 Agent 跨会话保持长期信息的能力。普通对话上下文只存在于单次会话中，关掉就没了；Active Memory 会把值得长期记住的信息清理、结构化、写入特定空间。在多人模式下，Active Memory 需要引入作用域概念，否则极易串内容。

2.2 Exec Approvals 和 Runtime Metadata

Exec Approvals（命令执行审批）是安全防护机制。Agent 在执行命令或者调用敏感 API 前，需要根据授权规则决定是否放行。授权规则通常位于本地目录下的配置文件里，例如 Linux 环境常见的/root/.openclaw/exec-approvals.json。

我们经常在一个真实场景里看到类似提示：

legacy exec approvals exist at /root/.openclaw/exec-approvals.json

这是从旧版本升级到 2.0 时，检测到了旧版授权文件。此时不要直接删除文件。正确做法是先把文件备份，再按新版提示迁移或重建审批规则，详见第 8 章。

Runtime Metadata（运行时元数据）描述的是 Runtime 当前状态，例如工作区路径、启用的模型、已加载的 Skill、审批策略、运行版本。当你排查“为什么 Agent 打开的是旧 workspace”或“为什么模型配置没有生效”时，第一件事就应该是查看 Runtime Metadata，而不是盲目重启。

2.3 Multiplayer 不是简单的“多账号登录”

我在文章开头强调过这个概念，这里再从工程层面解释一句：传统软件的多账号登录，通常只是把前端会话分离，数据表里加一个user_id字段；但 Agent 场景中，参与者会通过自然语言发出任务指令，而每个任务可能涉及文件读写、命令执行、模型调用和长期记忆写入。如果不把用户维度贯穿到工作区、记忆、Skill、审批这些更底层环节，那么即使前端能区分“是谁在说话”，后端依然是一锅乱炖。

所以审查 Multiplayer 配置时，不用太关心界面上有几个用户头像，真正应该关心的是：这个参与者进程能访问哪些目录？它调用 Active Memory 时读到的是谁的空间？它想让 Agent 执行命令时，走的是哪套审批策略？

3. 环境准备与部署形态选择

3.1 支持的操作系统

从社区里常见的部署反馈看，OpenClaw 大体可以覆盖 Linux、macOS 和 Windows。不同系统只是安装方式与目录习惯的区别，核心概念一致。

• 本地 Linux 或 macOS：适合开发调试，也适合常开的小主机。
• 云服务器：适合需要 7*24 小时在线、给多人提供稳定入口的场景。注意安全组不要随意暴露管理端口。
• Windows 环境：很多用户会通过 PowerShell 来安装，社区里已经有openclaw powershell安装相关提问。这类环境要注意 PowerShell 执行策略可能会阻止脚本运行。

从工程稳定性角度，我更推荐在 Linux 或使用容器方式部署多人模式，因为文件权限、用户切换、后台进程管理都更自然。

3.2 模型接入：云端 API 还是本地“零 Token”模型

模型是 Agent 大脑。OpenClaw 2.0 相关讨论里出现了大量“多模型”“零 Token”和“NVIDIA NIM”关键词。

先说“多模型”。从实际使用需求看，合理的策略不是只绑定一个大模型，而是按任务类型区分模型。简单会话和总结摘要可以交给速度快、成本低的模型；代码生成和复杂推理则交给更强的模型。多人模式出现后，还可以按参与者角色来区分模型优先级，不过这只是配置层面的绑定，不需要在代码层做特殊处理。

再说“零 Token”。这是最近自部署 Agent 社区里很受关注的方向，本质上是通过本地模型实现不依赖云端 Token 的 Agent 服务。本地模型的接入方式一般有两种：

• 使用 Ollama 这类本地推理服务，暴露一个 OpenAI 兼容接口；
• 使用 NVIDIA NIM 方式部署的模型服务，也是通过标准化接口接入。

值得强调的是，“零 Token”不等于“零配置”。很多用户在安装后收到这样的报错：

agent failed before reply: unknown model: deepseek

这类报错绝大多数不是 Agent 框架坏了，而是本地模型服务里根本没有叫deepseek的模型 ID。模型 ID 拼写、服务地址、模型别名设置都需要逐一确认。第 8 章会给出完整排查路径。

3.3 目录约定：.openclaw与 workspace

无论操作系统是什么，OpenClaw 都倾向于把配置集中放在用户主目录下的.openclaw目录里。从社区反馈中常见的路径可以归纳为：

• Linux：/root/.openclaw或/home/用户名/.openclaw
• Windows：C:\Users\Administrator\.openclaw

该目录下通常会看到：

~/.openclaw/ ├── workspace/ # 默认工作区 ├── exec-approvals.json # 命令执行审批规则 ├── skills/ # 技能包目录（如果启用） ├── memory/ # 长期记忆存储 └── logs/ # 运行日志

在单人模式下，这些目录可以简单粗暴地使用。但准备上 Multiplayer 之前，建议把所有参与者相关的子目录提前规划好，避免后期迁移成本。

4. 安装、初始化与升级注意事项

4.1 最小安装流程

因为项目处于快速迭代中，安装方式可能在不同版本之间有差异，所以这里不把某一条命令当作永远不变的真理，而是梳理一个通用的最小流程：

1. 准备一台能长期运行的机器，确认网络、磁盘和内存满足模型推理至少达到基本可用；
2. 从官方仓库获取当前版本的安装方式，脚本安装、便携包或容器部署都行；
3. 如果使用 Windows，建议先确认 PowerShell 执行策略；
4. 安装完成后，初始化配置并启动 Runtime。

一个合理的安装后检查动作是：

# 确认版本 openclaw version # 如果提供了启动自检，可以先运行 openclaw doctor

如果 CLI 没有doctor子命令或者版本较低，只要启动日志里没有异常，也可以直接进行下一步。

4.2 使用本地模型时的模型配置思路

以 Ollama 为例，先拉取模型：

ollama pull deepseek-r1:8b

然后在配置中把模型供应商指向本地服务。很多自托管框架现在都兼容 OpenAI 格式，所以配置通常是：

# 配置示意：请以实际版本生成的模板为准 model_providers: local: type: openai_compatible base_url: http://127.0.0.1:11434/v1 api_key: "not-needed" models: - id: "deepseek-r1:8b" aliases: - "deepseek"

这里真正容易出错的一步是模型 ID。Ollama 中执行ollama list可以查看到模型 ID。如果模型实际名字是deepseek-r1:8b，你却把配置写成model: deepseek，框架通常不会自动猜测全名，所以会直接报unknown model: deepseek。

如果你使用的是 NVIDIA NIM 方式，思路是一样的：确认服务地址和模型名，然后用 OpenAI 兼容方式接入。

4.3 从旧版本升级到 2.0 时的审批文件迁移

升级场景中，最常见的提示是：

legacy exec approvals exist at /root/.openclaw/exec-approvals.json. run `ope...

看到这条提示，代表系统检测到旧版本的审批文件，希望进行迁移。对于生产环境，操作顺序应该是：

1. 备份旧的审批文件；
2. 查看迁移提示完整内容；
3. 执行迁移命令；
4. 检查新规则，确认没有把过宽的放行规则带进新版本。

备份命令可以参考：

cp /root/.openclaw/exec-approvals.json /root/.openclaw/exec-approvals.json.bak.$(date +%Y%m%d)

不要直接在旧文件上做破坏性修改，因为审批规则一旦丢失，Agent 可能在新一轮启动中失去历史授权记录，导致后续操作全部需要人工批准，干扰真实工作流。

4.4 启动后先检查 Runtime Metadata

安装和配置完成后，启动 Runtime 并查看元数据。这一步看起来简单，却能避免很多“改了配置但不生效”的假象。

在多人模式下，建议重点核对以下信息：

• 当前工作区路径是否是预期路径；
• 已加载的模型列表是否包含目标模型；
• 是否开启了 Multiplayer 开关；
• 审批策略默认值是ask、allow还是deny。

不少用户出现“两个人明明用的是同一个配置，为什么行为不一致”的问题，原因往往就是其中某个参与者启动时加载了不同的 workspace 路径，这时只要对比 Runtime Metadata 就能快速定位。

5. Multiplayer 配置实战：工作区、记忆与审批

5.1 先规划目录结构，再写配置

很多用户配置 Multiplayer 时第一件事是打开配置文件加用户，这其实顺序错了。正确顺序是：先规划好文件系统层面的隔离，再告诉 Runtime 谁属于哪个工作区。否则即使配置了参与者，底层文件依然可能互相覆盖。

下面是一个适合“家庭/小团队”场景的目录设计：

~/.openclaw/ ├── workspaces/ │ ├── alice/ │ │ ├── .memory/ │ │ └── projects/ │ ├── bob/ │ │ ├── .memory/ │ │ └── projects/ │ └── family_room/ │ ├── .memory/ │ └── shared_docs/

• alice和bob是私有工作区，各自记忆和文件互不可见；
• family_room是共享空间，参与者只能在这里看到彼此主动放入的共享内容。

这种“私有工作区 + 共享空间”的模式，比把所有文件放在一个大 workspace 里再依赖权限控制更安全。因为默认情况下，Agent 不会跨目录读取，只有当你让它主动操作某个共享目录时，才有共享行为。

5.2 参与者配置示意

下面给出一份配置示意，用于说明 Multiplayer 模式下应该关注哪些配置项。请把我写的字段理解成通用思路的演示，实际部署时以安装后生成的配置文件为准：

# 文件路径示意：~/.openclaw/openclaw.yaml multiplayer: enabled: true participants: - name: alice role: owner workspace: ~/.openclaw/workspaces/alice memory_policy: private - name: bob role: member workspace: ~/.openclaw/workspaces/bob memory_policy: private - name: family_shared role: group workspace: ~/.openclaw/workspaces/family_room memory_policy: shared

这份配置传达的几个关键决策是：

• 每个参与者都有独立工作区，避免文件互相污染；
• memory_policy是private时，参与者的 Active Memory 不会被其他人直接读取；
• 当需要刻意协作时，可以设置一个family_shared这类共享工作区，但它并不默认绑定到私人生成任务里。

如果你看到某种方案把所有参与者都放在同一个 workspaces 目录下，请警惕。这种配置虽然配置量最小，但几乎必然在某个时刻产生上下文串扰。Multiplayer 的核心不是“大家都能用”，而是“该隔离的隔离，该共享的共享”。

5.3 审批规则示例：exec-approvals.json

审批规则文件负责定义命令和外部操作的安全边界。默认策略建议使用ask，即在遇到未明确放行的操作时询问参与者本人，而不是静默放行。下面是一个贴近实际但不代表所有版本的示意：

{ "default_policy": "ask", "rules": [ { "pattern": "git status", "policy": "allow" }, { "pattern": "git diff", "policy": "allow" }, { "pattern": "rm -rf", "policy": "deny" } ] }

在实际多人场景中，审批规则还需要考虑“参与者维度”。如果框架支持把规则绑定到具体用户，建议按用户抽象出不同角色，例如：

• owner：允许执行部署和配置变更类命令；
• member：只允许执行读取、提交代码类命令；
• guest：默认全部ask甚至直接禁掉命令执行。

这里有一个我们团队很重视的原则：审批规则能写具体命令就写具体命令，不要写一个大而全的"pattern": "*"然后放行。权限粒度越细，多人协作的崩溃半径越小。

5.4 多模型映射与通道配置

多人模式下，不同参与者可以映射到不同模型，这是“多模型”能力进多人场景后很自然的需求。

还是以 YAML 示意：

model_routing: default: local/deepseek-r1:8b participants: alice: cloud/gpt-4o-class bob: local/deepseek-r1:8b

这段配置表示：Alice 的请求默认走能力更强的云端模型，Bob 的请求走本地模型。你不需要关心底层是用什么推理引擎，只要在上层把模型路由配置好。像 NVIDIA NIM、Ollama 等不同模型来源，在配置文件中都可以当作不同的“模型供应商”来管理。

如果你只接了一个本地模型并希望做到零 Token 成本，那么所有参与者都指向同一个本地模型即可。按需分配模型是多人协作里很实用的性能平衡手段。

6. Active Memory 高阶玩法：多人记忆的隔离与共享

很多关于 OpenClaw 的高阶讨论都会指向 Active Memory。原因并不复杂：文件隔离相对容易，命令权限也可以靠审批规则兜底，但“长期记忆”天然是语义信息，它不像文件那样依赖路径，而是依赖概念关联。一旦两个参与者共享同一个 Agent 底座，记忆就很容易交叉污染。

6.1 记忆污染的真实场景

设想一个简单流程：

1. Alice 对 Agent 说：“记录一下，下周二的发布会预算上限是 5 万元。”
2. Agent 把这条信息写入了 Active Memory。
3. Bob 在同一台机器上问：“我们发布会预算有多少？”
4. Agent 直接把 5 万当成唯一答案给出来。

在记忆没有作用域时，这个行为看起来没有问题。但如果 Alice 和 Bob 属于不同业务部门，或者他们只是共用一台家庭服务器的两个成员，这就不是“资料共享”，而是隐私泄漏。

6.2 用作用域解决记忆串线

在部署多人模式时，可以按需要把记忆空间分成三类：

配置上需要意识到：不是所有模型都天然理解这些作用域。很多模型只是被动回答，它会“提”起它记忆里存在的东西，而不关心信息属于谁。因此，在 Multiplayer 模式下，不要把记忆功能完全交给模型自行判断，最好在框架层通过 Memory 内容的目录或命名空间来隔离。

一个比较实用的设计是把 Active Memory 按命名空间切分：

memory/ ├── namespaces/ │ ├── alice/ │ │ ├── agenda.md │ │ └── preferences.md │ ├── bob/ │ │ └── todo.md │ └── shared/ │ ├── team_goal.md │ └── room_notice.md

Agent 在写入记忆之前，先由框架判断这条信息属于哪个命名空间，再落盘；查询时则需要传入当前会话的参与者身份，只从对应命名空间召回内容。

6.3 什么时候应该共享记忆

我观察到不少团队使用 Multiplayer 时有一种误解：以为把所有人的记忆都放到共享空间，协作效率更高。实际上，真正值得放到共享空间的记忆只占少数，例如：

• 项目目标、里程碑和验收标准；
• 团队约定好的术语表；
• 需要多人共同维护的排班表或房间公告。

而个人偏好、草稿、思考过程、未确认的计划，放在共享空间里不仅制造噪音，还可能带来错误决策。更好的协作方式是：保留各自私有记忆，同时通过“共享项目空间”去同步真正需要同步的结论。这就回到了第 5 章反复强调的：先隔离，再共享。

7. 用 Skill 构建多人协作工作流

如果你已经顺利配置好了参与者和工作区，下一步是让 Agent 在特定场景里真正可用。Skill 正好承担这个职责。

7.1 什么是 Skill，为什么 Multiplayer 需要 Skill

Skill 可以理解成 Agent 的一套“可运行能力包”。和普通对话指令相比，Skill 有清晰的输入输出，有可重复执行的脚本逻辑，有确定的适用边界。

在多人模式下，通过 Skill 来封装任务比直接发一句“帮我做某事”可靠得多。原因在于：

• Skill 默认需要接收显式参数，比如用户名、动作、内容；
• Skill 的代码可以放在某个确定目录下，天然与工作区结合；
• Skill 的行为可以通过 manifest 描述，便于审计和复用。

例如，一个简单的“房间状态登记”Skill 可以帮助同一个共享空间的参与者更新当前值班状态、登记谁修改了房间公告。

7.2 Skill 最小项目结构

假设我们创建一个room_statusSkill：

skills/ └── room_status/ ├── manifest.yaml └── run.py

manifest.yaml声明这个 Skill 的元信息：

name: room_status description: 查看和更新团队共享空间的状态 arguments: - name: action description: update 或 query required: true - name: owner description: 操作者名字，例如 alice 或 bob required: false

run.py是实现逻辑的脚本，这里刻意把“谁在操作”作为显式参数接收，而不是在代码里写死某个用户，这会让 Skill 具备多参与者复用能力：

import datetime import json import sys DATA_FILE = "room_status.json" def load(): try: with open(DATA_FILE, "r", encoding="utf-8") as f: return json.load(f) except FileNotFoundError: return {"updated_at": "", "owner": "", "message": "暂无登记"} def update(owner: str): data = { "updated_at": datetime.datetime.now().isoformat(), "owner": owner, "message": "completed", } with open(DATA_FILE, "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) return data def main(): action = "" owner = "unknown" args = sys.argv[1:] for i, arg in enumerate(args): if arg == "--action" and i + 1 < len(args): action = args[i + 1] if arg == "--owner" and i + 1 < len(args): owner = args[i + 1] if action == "update": result = update(owner) else: result = load() print(json.dumps(result, ensure_ascii=False)) if __name__ == "__main__": main()

如果要在共享工作区里手动试跑这个 Skill，可以这样执行：

cd ~/.openclaw/workspaces/family_room python ~/.openclaw/skills/room_status/run.py --action update --owner alice python ~/.openclaw/skills/room_status/run.py --action query

这样做的一个好处是：Skill 的代码不感知 Agent 的会话层，它只是读取当前工作目录下的一份 JSON，所以只要 Multiplayer 配置正确，不同参与者进入同一个共享工作区时都能操作同一份状态文件。而如果工作区隔离正确，Alice 在私有目录下执行同一个 Skill，就不会影响family_room里的状态。

7.3 Skill 在多人场景的工程要求

给多人写 Skill，和给自己写 Skill，有一个很大的区别：自己用的时候可以懒一点，但多人用的情况下，Skill 必须做到“明确的输入、明确的输出、错误时能给出友好失败信息”。建议所有 Skill 至少做到：

• 不要使用某个参与者的个人路径，当前工作目录应该由 Runtime 按参与者注入；
• 所有写操作都记录操作者，避免事后无法审计；
• 输出格式保持结构化，便于 Agent 后续判断；
• 对更新操作设计成幂等，也就是重复执行不会产生冲突副作用。

如果一个 Skill 要由owner角色才能运行，需要有一种角色判断机制，没有的话宁可在入口校验环境变量，也不要在 Skill 内部硬编码“信任所有人”。

8. 常见问题与排查方法

部署 OpenClaw 2.0 Multiplayer 时，社区和实际操作中最常见的几类问题，我整理成了下面的表格。

上面的问题中，最隐蔽、最容易多花时间的是第二个和第三个。

审批文件迁移问题，核心是一个误会：有些人看到legacy exec approvals就觉得是安全漏洞，急着删掉规避报警。其实这个提示通常只是版本升级的正常流程。正确的做法是先备份，再按提示执行迁移。如果你不确定迁移命令影响范围，可以先在测试环境跑一遍，确认规则符合预期之后再上生产。

工作区路径问题，也同样容易被忽略。因为很多部署方式会以不同的用户身份启动 Runtime，比如 root 启动和普通用户启动加载的.openclaw路径是不同的。如果之前以 root 身份运行过，后面改成了普通用户，那么新进程很可能加载了一个全新的空配置目录，看上去“配置丢了”，实际上只是路径变了。排查时优先使用 runtime metadata 或启动日志确认实际加载路径。

9. 从“能跑”到“好用”的最佳实践

9.1 安全边界：审批规则和审计记录一定要有

多人模式的本质，是把一个原本私密的 Agent 能力开放给多人。开放范围越大，审批和审计就越重要。比较稳妥的做法是：

• 默认策略设为ask或deny，而不是allow；
• 只按具体命令前缀放行低风险操作；
• 高风险的写操作、文件删除、外发请求，全部要求人工确认；
• 定期检查审批规则日志，看哪些授权被实际使用过，把一个月以上没有用到的授权移除。

另外，不要把包含 Token、私钥、地址的敏感文件直接放进 workspace。需要使用时，通过环境变量或专门的 Secret 管理方式注入。多人场景里，任何写入 workspace 的内容都可能被 Skill 脚本读取，也可能被进入同一工作区的其他参与者访问到。

关于“一键部署”和所谓会员付费，也需要提醒一句：搜索 OpenClaw 相关内容时，偶尔会看到某些商业公司以“终身会员特惠”等方式售卖一键部署服务。对于这类第三方付费产品，请务必先确认项目本身的发布主体和官方渠道。自托管项目的核心价值之一就是代码和配置自己可控，花钱买来一个不可审计的“黑盒部署包”反而会带来比较大的安全隐患。

9.2 配置管理：用模板维护 Multiplayer 配置

Multiplayer 配置会随着参与者增加变得越来越长。不建议靠手改维护，比较适合把配置拆成模板 + 环境变量，例如：

• 基础配置模板放在 Git 仓库中；
• 每个参与者的私有路径、密钥通过环境变量注入；
• exec-approvals.json这类授权文件不要直接提交到 Git 仓库，否则等于把放行权限公开给所有能看仓库的人。

团队协作时，可以约定配置格式，例如把参与者列表单独放进一个 YAML，主配置引用它。这样新增成员时，Review 的差异范围会更清晰。

9.3 日志与审计：给每一步留下记录

多人协作模式下，建议打开操作日志。至少需要知道：

• 哪个参与者在什么时间发起了什么任务；
• Agent 为该任务调用了哪些 Skill；
• 是否有命令执行，执行结果是什么；
• 是否有 Active Memory 的写入或读取。

如果日志只有请求内容而没有参与者 ID，那就说明日志体系还没跟 Multiplayer 对齐。可以做一次小检查：切换参与者发同样一句话，看日志里能否区分来源。如果区分不了，这个问题必须排在新增功能之前解决。

9.4 渐进式上线：先共享低频场景，再放开高频能力

很多家庭或小团队把 Agent 引入协作后，容易因为一两个“惊喜”就迅速把各种能力全部开放，比如让 Agent 直接访问网盘、操作邮箱、管理支付。这个路线风险很高。更稳的推进方式是分阶段：

1. 第一阶段只开放一个共享工作区和日程查询 Skill，所有命令执行保持默认审批；
2. 运行时观察记忆是否串线、审批是否影响效率、日志是否有异常；
3. 第二阶段再逐步放开更多 Skill，并针对不同参与者细化审批角色；
4. 只有经过验证的低风险操作才考虑设置成自动放行。

10. 总结：多人协作的关键不在“多人”，而在“边界”

OpenClaw 2.0 推出 Multiplayer，确实把自部署 Agent 的协作形态往前推了一大步，让同一个 Runtime 可以服务多个参与者，而不是各自维护一套重复部署。但对使用方来说，需要转变观念：从“怎么让更多人连上来”变成“如何在可共享的能力之上，建立清晰的工作区、记忆和审批边界”。

如果你刚接触这个功能，可以先做三件事验证自己是否理解了多人协作：

1. 修改配置文件，为两个参与者分配独立的 workspace，并确保加载后的 Runtime Metadata 显示正确路径；
2. 分别在两个参与者的私有会话里写入不同的 Active Memory，然后在另一方会话里查询，确认不会串线；
3. 创建一个简单的共享 Skill，并让它只在共享工作区中写入共享 JSON 文件，观察两个参与者能否协同更新同一份状态，同时私有文件保持独立。

做完这三个实验，你对 Multiplayer 的理解就不再停留在“多个窗口”的层面，而是真正理解了 Agent 协作运行时的隔离与共享机制。后续无论是接入消息渠道、配置多模型，还是编写更复杂的团队级 Skill，都会顺畅很多。这篇文章建议收藏备用，也欢迎在实际部署中多观察 Runtime 日志，你会发现很多问题的答案其实早就写在了元数据和审批文件里。