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 pushB 是运营人员可能只需要查询天气和写周报。如果规则不做区分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 和 MemoryRuntime可以理解成整个 Agent 的运行底座。OpenClaw 以本地或云服务器作为宿主机启动之后Runtime 负责加载模型、调度 Skill、维护会话和记忆、执行审批规则。Runtime 相当于操作系统内核而不是某一个具体的聊天界面。Workspace是 Agent 的“办公桌”。很多实际任务都需要读写文件、生成中间产物这个目录就是它们工作的物理空间。单人模式下默认是一个全局目录多人模式下应该调整为按参与者或按项目拆分的目录避免文件互相覆盖。Skill是给 Agent 扩展能力的“技能包”。一个 Skill 通常包含描述文件、执行脚本和可能的依赖。Skill 解决的问题是不让 Agent 在一个对话里通过“灵光一闪”完成复杂任务而是用一套可复用、可测试、可分享的能力模块去完成某个特定领域的工作。Active Memory主动记忆是 Agent 跨会话保持长期信息的能力。普通对话上下文只存在于单次会话中关掉就没了Active Memory 会把值得长期记住的信息清理、结构化、写入特定空间。在多人模式下Active Memory 需要引入作用域概念否则极易串内容。2.2 Exec Approvals 和 Runtime MetadataExec 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/用户名/.openclawWindowsC:\Users\Administrator\.openclaw该目录下通常会看到~/.openclaw/ ├── workspace/ # 默认工作区 ├── exec-approvals.json # 命令执行审批规则 ├── skills/ # 技能包目录如果启用 ├── memory/ # 长期记忆存储 └── logs/ # 运行日志在单人模式下这些目录可以简单粗暴地使用。但准备上 Multiplayer 之前建议把所有参与者相关的子目录提前规划好避免后期迁移成本。4. 安装、初始化与升级注意事项4.1 最小安装流程因为项目处于快速迭代中安装方式可能在不同版本之间有差异所以这里不把某一条命令当作永远不变的真理而是梳理一个通用的最小流程准备一台能长期运行的机器确认网络、磁盘和内存满足模型推理至少达到基本可用从官方仓库获取当前版本的安装方式脚本安装、便携包或容器部署都行如果使用 Windows建议先确认 PowerShell 执行策略安装完成后初始化配置并启动 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...看到这条提示代表系统检测到旧版本的审批文件希望进行迁移。对于生产环境操作顺序应该是备份旧的审批文件查看迁移提示完整内容执行迁移命令检查新规则确认没有把过宽的放行规则带进新版本。备份命令可以参考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 记忆污染的真实场景设想一个简单流程Alice 对 Agent 说“记录一下下周二的发布会预算上限是 5 万元。”Agent 把这条信息写入了 Active Memory。Bob 在同一台机器上问“我们发布会预算有多少”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.mdAgent 在写入记忆之前先由框架判断这条信息属于哪个命名空间再落盘查询时则需要传入当前会话的参与者身份只从对应命名空间召回内容。6.3 什么时候应该共享记忆我观察到不少团队使用 Multiplayer 时有一种误解以为把所有人的记忆都放到共享空间协作效率更高。实际上真正值得放到共享空间的记忆只占少数例如项目目标、里程碑和验收标准团队约定好的术语表需要多人共同维护的排班表或房间公告。而个人偏好、草稿、思考过程、未确认的计划放在共享空间里不仅制造噪音还可能带来错误决策。更好的协作方式是保留各自私有记忆同时通过“共享项目空间”去同步真正需要同步的结论。这就回到了第 5 章反复强调的先隔离再共享。7. 用 Skill 构建多人协作工作流如果你已经顺利配置好了参与者和工作区下一步是让 Agent 在特定场景里真正可用。Skill 正好承担这个职责。7.1 什么是 Skill为什么 Multiplayer 需要 SkillSkill 可以理解成 Agent 的一套“可运行能力包”。和普通对话指令相比Skill 有清晰的输入输出有可重复执行的脚本逻辑有确定的适用边界。在多人模式下通过 Skill 来封装任务比直接发一句“帮我做某事”可靠得多。原因在于Skill 默认需要接收显式参数比如用户名、动作、内容Skill 的代码可以放在某个确定目录下天然与工作区结合Skill 的行为可以通过 manifest 描述便于审计和复用。例如一个简单的“房间状态登记”Skill 可以帮助同一个共享空间的参与者更新当前值班状态、登记谁修改了房间公告。7.2 Skill 最小项目结构假设我们创建一个room_statusSkillskills/ └── room_status/ ├── manifest.yaml └── run.pymanifest.yaml声明这个 Skill 的元信息name: room_status description: 查看和更新团队共享空间的状态 arguments: - name: action description: update 或 query required: true - name: owner description: 操作者名字例如 alice 或 bob required: falserun.py是实现逻辑的脚本这里刻意把“谁在操作”作为显式参数接收而不是在代码里写死某个用户这会让 Skill 具备多参与者复用能力import datetime import json import sys DATA_FILE room_status.json def load(): try: with open(DATA_FILE, r, encodingutf-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, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) 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_asciiFalse)) 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 时社区和实际操作中最常见的几类问题我整理成了下面的表格。问题现象可能原因排查方式解决方案启动后报unknown model: deepseek模型 ID 与本地模型服务中的名称不一致先看本地模型服务列表再对比配置文件里的model字段将配置改为实际模型的准确 ID或在别名中补充映射出现legacy exec approvals exist ...警告旧版本审批文件需要迁移到新规则备份旧文件后查看完整迁移命令再执行按提示迁移不手工删除旧审批文件多个参与者之间互相看到对方文件工作区目录没有按参与者拆分查看 Runtime Metadata 中的 workspace 路径为每个参与者分配独立 workspace 目录并重新加载配置两个参与者共享了对方记忆Active Memory 没有区分命名空间检查 memory 目录下是否存在多个命名空间按参与者或共享空间拆分记忆目录并设置对应的作用域PowerShell 安装脚本无法运行系统执行策略限制查看 PowerShell 错误信息以管理员身份调整当前进程执行策略或改用官方推荐的安装方式已修改 Multiplayer 配置但行为未变配置未重新加载或启动时加载了错误的目录对比启动时的 Runtime Metadata 和实际配置文件路径重启前确认加载路径并在日志中确认配置生效上面的问题中最隐蔽、最容易多花时间的是第二个和第三个。审批文件迁移问题核心是一个误会有些人看到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 直接访问网盘、操作邮箱、管理支付。这个路线风险很高。更稳的推进方式是分阶段第一阶段只开放一个共享工作区和日程查询 Skill所有命令执行保持默认审批运行时观察记忆是否串线、审批是否影响效率、日志是否有异常第二阶段再逐步放开更多 Skill并针对不同参与者细化审批角色只有经过验证的低风险操作才考虑设置成自动放行。10. 总结多人协作的关键不在“多人”而在“边界”OpenClaw 2.0 推出 Multiplayer确实把自部署 Agent 的协作形态往前推了一大步让同一个 Runtime 可以服务多个参与者而不是各自维护一套重复部署。但对使用方来说需要转变观念从“怎么让更多人连上来”变成“如何在可共享的能力之上建立清晰的工作区、记忆和审批边界”。如果你刚接触这个功能可以先做三件事验证自己是否理解了多人协作修改配置文件为两个参与者分配独立的 workspace并确保加载后的 Runtime Metadata 显示正确路径分别在两个参与者的私有会话里写入不同的 Active Memory然后在另一方会话里查询确认不会串线创建一个简单的共享 Skill并让它只在共享工作区中写入共享 JSON 文件观察两个参与者能否协同更新同一份状态同时私有文件保持独立。做完这三个实验你对 Multiplayer 的理解就不再停留在“多个窗口”的层面而是真正理解了 Agent 协作运行时的隔离与共享机制。后续无论是接入消息渠道、配置多模型还是编写更复杂的团队级 Skill都会顺畅很多。这篇文章建议收藏备用也欢迎在实际部署中多观察 Runtime 日志你会发现很多问题的答案其实早就写在了元数据和审批文件里。