OpenClaw 2.0 装得更快，权限债也更贵了

OpenClaw 2.0 今天正式放出来了，版本号是 v2026.8.1。

发布页上的新东西多到离谱。会话可以跑去配对设备和云端 worker，网页刷新后还能接着看进度，Agent 能用遮罩卡片向你要凭据，团队可以共享 session、分配 owner、给操作者套不同角色。第一次安装也不再像闯密室，新的引导流程会带着你选模型、配本地运行时、导入 Claude Code 或 Codex 的记忆。

好家伙，几乎每个功能都在解决真问题。

但我把更新页往下翻，最想圈出来的不是界面，也不是远程 worker，而是官方反复写的那句边界声明。一个 Gateway，只算一个信任域。

这句话有点扫兴，却比所有新按钮都值钱。

OpenClaw 2.0 的正式发布说明把安装、共享、凭据、自动化都做顺了。顺手的代价是，更多会话、机器、账号和 secret 开始汇到同一个控制面。以前你只担心自己的笔记本，现在还得知道谁能进 Gateway，谁能唤起 Agent，Agent 又能碰到哪些文件、浏览器登录态和远程节点。

OpenClaw 2.0 不只是一次大更新。

它更像一张权限债的账单。

OpenClaw 2.0 官方发布页，正式版本号为 v2026.8.1。

安装简单了，危险也更靠近

先看那些真的让人舒服的变化。

新版的 guided onboarding 会用结构化选项带用户完成首次设置。Web 和 macOS 端能直接处理本地模型下载，检测机器上更合适的模型，还提供偏轻量的本地推理模式。已有 Claude Code、Codex 或 Hermes 记忆时，安装流程会发现它们，再由用户决定是否导入。

这部分确实有点子牛逼。过去装个人 Agent，最劝退人的常常不是模型，而是散落在环境变量、配置文件、网页登录、Gateway 重启里的十几个小坑。任何一个环节没对上，收尾拿到的都是一句非常平静的 connection failed。

OpenClaw 2.0 把这些坑收进向导，普通人更容易跑起来。可「更容易跑起来」和「更安全地长期跑」是两件事。

一台只在本机聊天的 OpenClaw，权限面还算直观。等你打开远程 session，把工作放到云端 worker，接入 Slack、飞书或 Telegram，再给它浏览器、文件系统和自动化权限，Gateway 就不再是一个聊天窗口后面的进程了。它握着渠道连接、凭据、策略、会话状态和工具入口，是整套系统的控制面。

官方安全文档把默认模型写得很明确。OpenClaw 面向的是一个操作者，或者一群互相信任的同事。团队成员可以共享一个 Gateway，因为大家原本就在同一信任域里。若两个人不能互相看到文件、凭据和工具结果，就不该靠侧边栏里的 owner 名字隔离他们，而该拆成独立 Gateway，最好连 OS 用户或主机也分开。

一座 Gateway 控制塔连接设备、云端、消息与凭据，边界外的参与者需要被真正隔离。

很多朋友可能会把权限控制理解成门禁卡。A 能看三间房，B 能看两间房，角色配好了就万事大吉。

真实情况更像共用一间机房。角色能告诉大家哪台机器归谁，能阻止不少误触，却没有把电源、网络和地板下的线缆变成三套。一个能调用 shell、浏览器和网络的共享 Agent，收到谁的消息都可能产生工具调用。群聊里一句看似普通的话，也可能把别人的上下文、共享状态或设备能力卷进来。

怎么说呢，协作功能越好用，这条线越容易被忘掉。

这次升级最容易翻车的两条线

如果已经在跑旧版，别只盯着新功能。发布说明里有两条破坏性迁移，足够让自动化在凌晨安静地躺平。

一条是 OpenProse。内置插件和 /prose 命令被移除了，已有 .prose 源文件会保留，旧配置则要清理并迁到上游 Agent Skill。官方给出的入口是 OpenProse 迁移说明。

另一条更容易漏，旧的 codex/* 与 openai-codex/* 模型路由要迁到 openai/*。影响的不只是一个配置字段，还包括 provider 配置、存下来的 session 与 automation route。迁移工具会尽量保留原来的 Codex 运行意图，遇到冲突则留给操作者处理。

升级后至少该跑这一组命令。

openclaw doctor --fix
openclaw update repair
openclaw security audit --deep

doctor --fix 负责修能确定修复的配置，update repair 找回缺失的官方 provider 包，security audit --deep 再对正在运行的 Gateway 做一次探测。它们不是三个许愿按钮。命令返回零，也不代表旧自动化已经按预期走到正确模型，更不代表共享会话自动获得了租户隔离。

坦率讲，最靠谱的验收仍然很土。挑一条低风险自动化，手动触发一次，核对它用了哪个模型、读了哪个 workspace、请求了哪些权限、把结果发去了哪里。再换一个没有权限的账号，确认它真的进不来。

程序员对迁移最熟悉的错觉，是 schema 改完，业务就算改完。数据库没报错，用户路径照样可以死在半路。Agent 系统更麻烦，因为路径不只经过代码，还经过会话记忆、模型选择、工具策略、凭据和外部渠道。少看一层，故障就会躲进下一次定时任务。

外部插件也得补一眼。完整 tagged changelog写明，任意可执行插件源现在需要显式 --force。ClawHub、内置包、官方目录和有追踪记录的更新可以跳过来源警告，但仍要确认它请求的能力。插件 SDK 还有一批入口将在 9 月 1 日进入移除门槛，映射表在 SDK 迁移指南。

眼下还能启动，不等于下次更新还能启动。

这句话不新鲜，但每次都有人用生产环境替大家复习。棒棒的。

共享不是隔离，隐私也不是隐身

OpenClaw 2.0 的共享体验进了一大步。session 可以设置可见性、成员和 owner，系统会记录谁创建了会话，团队角色还能限制可访问的 Agent、别人的 session 与 operator scope。部分角色可以要求新建会话必须进 sandbox。

这些能力很实用。产品经理能看到任务进展，工程师可以接手，审阅者知道谁改过哪段代码，大家不用在三个群里问「现在跑到哪了」。

可官方在发布记录里紧跟着补了一句，这些是 collaboration controls，不是 hostile-tenant isolation。

多用户模式文档说得更直白。session ownership、侧边栏可见性和在线状态属于可用性功能，不是安全边界。只要一个人能操作某个 Agent，他就共享了这个 Agent 被授予的能力。如果参与者彼此不可信，应该拆 Agent、拆 Gateway，或拆主机。

这里有个很实用的判断法。

如果你愿意把同一台已登录公司后台、云控制台和私人邮箱的电脑交给这群人轮流使用，那他们大概处在同一信任域。如果你不愿意，就别因为 UI 里有 owner 和成员列表，突然觉得共享 Gateway 没问题。

私信上下文也有类似的坑。OpenClaw 默认把不同渠道的私信汇入 main session，方便同一个人在手机和电脑之间连续聊天。个人助理场景很顺。多人共享收件箱却可能让不同发送者进入同一段滚动上下文。

这时可以把 session.dmScope 调成 per-channel-peer。

{
  session: {
    dmScope: "per-channel-peer"
  }
}

它能把每个渠道与发送者的对话上下文分开，减少消息串线。注意，它隔的是聊天上下文，不是主机权限。几个人若仍共享同一个 Gateway、同一套凭据和同一个有 shell 权限的 Agent，安全边界并没有凭空长出来。

Incognito thread 也很容易被名字骗到。新版让这类会话的 transcript 和 compaction state 只放在 Gateway 内存里，重启后消失。听起来很隐私，实际限定不少。模型 provider 的处理、诊断日志和工具显式写入仍按各自规则发生。Agent 把内容写进文件、发进群、提交到仓库后，重启 Gateway 不会帮你擦掉这些痕迹。

隐身窗口只管一扇窗。

别指望它顺便抹掉整栋楼的监控。

给自己留一把能拔掉的钥匙

OpenClaw 2.0 在 secret 处理上做了几件靠谱的事。

Agent 可以用遮罩卡片请求凭据，值不进入聊天文本或模型上下文。受保护的 secret 可以通过代理只替换到批准过的目标 host。团队凭据存储会把 secret 和普通环境变量区分开，secret 保持只写。长期自动化的授权也绑定到精确操作，任务或操作一变，就要重新批准。

这类设计比「把 key 塞进 prompt，再祈祷模型别说出来」强太多。厉害了。

但这里仍有三个问题要靠操作者回答。

谁能请求这把钥匙。钥匙能打开哪扇门。任务结束后，哪条通道会被关掉。

如果答案只是「团队里应该不会有人乱来」，那不是权限策略，只是同事关系不错。

升级前可以给自己做一张很小的边界表。左边写入口，谁能从 Slack、飞书、网页和本机 CLI 触发 Agent。中间写能力，哪些 session 能读文件、跑 shell、控浏览器、发消息和启动 subagent。右边写出口，secret 允许去哪些域名，结果允许写进哪些仓库、群聊和数据库。

不用画得像安全审计报告，十分钟就够。任何一格写不出来，就先别把对应能力开到共享环境。

然后跑一遍 openclaw security audit --deep。如果准备给不互相信任的人使用，别继续研究怎么调 role，直接看 多租户部署说明，一人一套 Gateway cell 才是正确方向。实验性的 Fleet 能帮忙管理 cell，但实验功能就按实验功能对待，别拿它替代备份和故障演练。

我自己的判断可能有点保守。OpenClaw 2.0 越来越像一套真正的 Agent 操作系统，安装、会话、凭据、远程机器和多人协作都开始成体系。也正因为这样，权限不再是设置页里一个角落的小开关，而是产品主路径的一部分。

模型犯错通常浪费一次回答，权限边界犯错却可能替它把错误送到所有能到达的地方。

所以这次升级最该记住的，不是新版装得有多快。

是每多接一台机器、一个群、一个账号，都要知道那把钥匙最终挂在谁腰上。