OpenClaw 2.0 详解:持久 Session、弹性算力与对象化授权如何连成一套 Agent 平台

OpenClaw 的正式版本号仍然是 v2026.8.1，官方给它加上的发布名才是 “OpenClaw 2.0”。这个细节很重要：它不是另起炉灶的 v2.0.0，而是一次规模足以改变产品性质的常规版本发布。官方博客称，项目在七周内合入超过 16,000 个 PR，涉及 933 位贡献者，其中 569 位是首次贡献者。

但数字不是这次更新最值得讨论的地方。Peter Steinberger 随后给了一个更准确的产品注脚：团队花两个月逐步放弃成员各自使用的本地 coding harness，转向 team.openclaw.ai 上的共享 Agent。它知道每个人正在做什么，也负责统一编排；节点和 Cloud Sessions 提供的弹性执行，让本地 harness 在他的使用语境里显得像过去式。

把发布说明、Cloud Sessions、Dashboard、Memory、Automation、Secrets 和 Update 文档放在一起看，2.0 的主线并不散：先缩短第一次对话，再把 Session 变成耐久状态；把执行放到可替换的机器；把监督做成持久界面；最后用对象化授权支撑长期运行。

2.0 首先把“能不能尽快开始第一轮对话”当成产品问题。官方给出的入口包括现有 ChatGPT 或 Claude 订阅、API key，以及本地模型。它降低了首次配置的摩擦，但并不意味着所有 provider、权限和运行环境都会自动替用户决定。

更深的变化在浏览器端。过去，Web UI 容易被理解为聊天客户端；2.0 将它重做为第一等入口。用户可以精确搜索过去的对话，查看不会因刷新而丢失的 progress card，也能在 Web、原生应用和消息渠道之间收到结构化问题。任务进行到一半需要人选目录、确认方案或授予某项能力时，监督不必退回一段难以追踪的文字对话。

图 1｜OpenClaw 2.0 重做后的浏览器应用：默认直接进入对话与工作界面

这为后面的 Dashboard 和 Cloud Session 埋下了伏笔：如果 Agent 要运行几个小时、跨设备继续或交给团队查看，聊天记录就不能再是唯一界面。

Cloud Session 的官方定义很克制：它是普通 Session 的一种远程 placement。真正的架构变化隐藏在这句话里。

Gateway 持有四类关键状态：conversation、经过 reconcile 的 workspace、model credentials 和 placement records。命令、文件操作与工具工作可以放到远端执行，但模型请求仍由 Gateway 代理，provider credential 不需要落到 cloud worker。这使得“会话是谁”与“这一次在哪台机器运行”成为两个问题。

目前可以把 placement 分成三类：

两种远端恢复路径也不同。cloud worker 可以被自动替换；paired device 离线时，Session 会等待设备重新连接。无论哪一种，“远端”都不自动等于“隔离”：是否启用容器、workspace 在哪个时点完成 reconcile、远端机器拥有什么系统权限，都需要单独判断。

因此，官方语境里的 “infinite compute” 更适合理解为一种产品体验，而不是算力无限的技术承诺。它成立的工程条件是：placement 可替换，Session 可恢复，credential 不随 worker 漂移，workspace 有明确的 reconcile 点。

OpenClaw 的 worker-turn 与 Codex remote-exec 可以使用同一组 remote destinations。这条能力改变了竞品比较的方式：OpenClaw 与 Codex 并非只能二选一。

一种更合理的组合是：OpenClaw Gateway 持有长期 Session、身份、入口、自动化和权限；Codex 负责代码库里的执行、变更总结、diff 与 review 交付。前者决定任务如何连续，后者决定代码工作如何完成。对于既需要消息入口、长期任务和远程节点，又重视专业 coding loop 的团队，这种分层比寻找“一个 Agent 包办所有事”更现实。

Dashboard 属于 thread，而不是某一条消息。即使用户执行 /new 或 /reset，Dashboard 仍然保留。Agent 可以生成并更新稳定命名的 widget，也可以固定 MCP apps 和 A2UI 界面。

图 2｜OpenClaw 团队在共享多人工作区中运行的 Dashboard

这意味着 Agent 的输出不必永远是 Markdown。项目状态、审批列表、研究资料、表单和操作面板都可以成为 Session 的长期表面。一个任务可以在聊天里讨论，在 widget 中呈现状态，再通过 structured question 等待人类选择。

这种便利并未建立在“生成的 UI 默认可信”之上。Widget 默认处于硬沙箱，只能渲染且不能联网。network、data、actions 和 prompt 能力必须声明；授权会绑定 exact bytes 或具体 revision。Widget 内容改变后，系统依据 policy 再次审查。这里形成了 2.0 很有代表性的安全原则：授权给一个可校验对象，而不是笼统地信任“这个 Agent”。

默认 memory-core 使用 SQLite，支持关键词、向量和混合检索。上下文压缩前的 memory flush 默认开启，用来把值得保留的信息写回长期存储。Dreaming 则在后台整理与巩固记忆，并把过程写入 DREAMS.md 供人审查。

所以，“越用越懂你”在 2.0 中不是模型权重悄悄自训练，而是几种明确的数据动作：Session 产生经验，检索把相关经验带回上下文，flush 在压缩前保存，Dreaming 整理和提升，审查记录让人能够发现污染或错误积累。

OpenClaw 还可以从 Codex、Claude Code 和 Hermes 导入特定的 Markdown 记忆，但不会顺带导入凭据、配置、Skills 或原始 transcript。它解决的是知识迁移，而非整个 Agent 状态的无损克隆。

/loop 是最容易理解的入口：它可以在当前 conversation 上建立 recurring turn。但完整 Automation 由 Gateway scheduler 持久化，支持一次执行、固定间隔、cron、命令退出和 stream triggers。这里的差别类似“重复发送一句话”和“运营一个可以追踪、恢复和投递结果的 job”。

Agent 创建 Automation 时会冻结显式 tool policy。对于 recurring exec，用户可以对某个 exact operation 给 standing grant；job 或 operation 发生变化后需要重审，授权也可以撤销。这样，无人值守运行不必退化成“以后所有命令都默认允许”。

一个稳妥的顺序是：先手动跑通单次任务，确认输入、工具和交付；再冻结最小 tool policy；最后才把它变成 /loop 或 scheduler job。Gateway 必须持续运行，长期任务的故障、结果和撤销路径也要在自动化之前设计。

2.0 允许 Agent 发起 credential request，但真正的 secret 只由人类在受信任的 masked UI 中输入。值不会进入 chat、transcript 或 model context，Agent 也没有代填 secret 的写入动作；聊天中只能出现安全链接。

如果开启可选 egress proxy，protected secret substitution 还能限定在批准的目标 host。代理未启用时，protected entries 不会被注入 shell。它和配置文件中的 SecretRef 属于不同路径，不能混为“只要进 secret store 就到处可用”。

把几个安全面放在一起，可以看到 2.0 的授权对象已经分化：

这些 team roles 适合受信任团队内的运营分权，并不等于 hostile-tenant isolation。跨机器、跨时间和外部动作越多，权限越需要缩小到对象、版本和目的地；这不是附加限制，而是长期 Agent 能运行的前提。

Plugin 更新会检查 provenance 和 capability changes。--yes 不会自动接受能力变化；--accept-capabilities 只接受本次精确能力面。这个规则把供应链风险放进了正常升级流程，而不是等异常发生后再追溯。

旧用户升级还要注意三项 breaking change：

Fleet、Swarm 和 A2A 1.0 也出现在 2.0 中，但仍属于 Experimental、Labs 或 opt-in。它们说明 OpenClaw 正在继续向多 Agent 协作扩展，不宜写进稳定生产能力清单。

Hermes 与 OpenClaw 是最接近的一组。Hermes 同样模型中立、可自托管，拥有记忆、Skill 学习、多渠道、cron、browser/voice、MCP、subagents 和 Bot Mode。它的魅力在于把“个人 Agent 越用越贴合自己”做成轻量、开放的学习闭环。

OpenClaw 的重心则更靠近 Gateway state、remote placement、共享界面和长期运营。如果目标是一个人的长期助手，且希望更自由地切模型、低成本部署，Hermes 很有吸引力；如果任务需要跨机器 placement、团队查看同一 Session、持久 Dashboard 和细粒度 recurring grant，OpenClaw 的系统形态更完整。两者都不能因为“自托管”三个字就跳过隔离设计：Hermes 官方以 single-tenant 为信任前提，OpenClaw 的 operator roles 也没有承诺恶意多租户隔离。

Claude Code 的扩展面集中在 repo engineering：CLAUDE.md、Skills、MCP、subagents、hooks、plugins 和权限系统。权限支持 deny、ask、allow 与多种 mode；Hooks 可以在工具、Session、权限和 teammate 生命周期执行确定性逻辑或模型检查。Agent Teams 提供多 Agent 路线，但仍是 experimental 且默认关闭。

Codex 则把执行分为 Local、Worktree 和 Cloud。Cloud 任务可以在隔离、可复现环境中并行运行，并从 Web、GitHub、GitLab、Linear、Slack 等入口发起，最后交付 summary、diff 或 PR；自定义层有 AGENTS.md、memory、Skills、MCP 和 subagents，本地执行有 OS-level sandbox 与 approval policy。

这两款产品适合把“改代码—验证—审查”做深。OpenClaw 的比较优势不在未经 benchmark 证明的单次编码质量，而在把 coding harness 放进跨入口、跨机器和跨时间的 Session。尤其是 Codex remote-exec 已有官方组合路径，最值得先尝试的往往是分工，而非替换。

Grok Bot 把 Agent 做成持久具名 teammate，运行在账号级 persistent cloud computer 上。它能使用 browser、filesystem、terminal、connectors、MCP 和 computer use，也能把演示固化为 skill 或 routine，再与其他 Bot handoff。对于不想维护 Gateway、节点和云资源的人，这条路径更短。

代价也写在官方架构里：同一账号下的多个 Bot 共享一台 cloud computer、文件、浏览器会话和应用登录。它们可以有不同 screen，但不是彼此独立的安全边界。OpenClaw 的取舍相反：需要自己管理 Gateway，却能决定 worker、placement 和组合方式。这里应该比较便利与控制，不应该凭部署方式武断推断隐私优劣。

DeepSeek Harness 仍是 developer preview，也是一套 locally-first、开源的 coding agent/runtime。它建立在 Cordis kernel 上，model、tools、Skills、sessions、sandboxes、storage、loops、scheduling 和 UI 都由插件组合。

它用 append-only session log 记录模型输入、推理、tool calls、subagent scheduling 和 context injection；同一条 event stream 支持 resume、fork、search 和 replay，并提供 Standard、Code/PTC、Minimal、Creator 等模式。对要研究 Agent loop、替换组件、重放过程或发明新 harness 的工程师，这种可组合性和可追踪性非常有价值。

OpenClaw 2.0 选择了另一种产品化方向：把多入口、Session operations、remote placement 和权限治理装配成可直接运营的上层。前者更像实验台，后者更像控制室。

macOS、Linux 和 WSL 的官方推荐安装命令是：

curl -fsSL https://openclaw.ai/install.sh | bash

Windows PowerShell 使用：

iwr -useb https://openclaw.ai/install.ps1 | iex

安装后先完成三项验证：

openclaw --versionopenclaw doctoropenclaw gateway status

不要在第一天同时打开 Cloud Sessions、外部 action、长期 Automation 和大量 Plugin。更稳妥的顺序是：本机 Gateway 跑通一次低风险 Session；确认历史与工作区；创建一个只读 Dashboard；接入一个 paired device 或 cloud worker；最后才增加 /loop、standing grant 和 protected secret。

如果需要自有机器作为 Session Host，再运行：

openclaw connect <join-url> --service --session-host

接入后要单独检查 slot 数、container isolation、workspace reconcile 和设备离线后的恢复行为。

升级前先看状态与计划：

openclaw update statusopenclaw update --dry-run

确认备份后再执行：

openclaw updateopenclaw doctor --fixopenclaw gateway status

如果升级状态不一致，可以用 openclaw update repair 收敛。cleanup 会永久删除用于回滚的原件，所以必须放在 Session history、Gateway、provider routes、Plugin capabilities 和关键 Automation 全部验证之后，并先查看 dry-run。升级完成的判据不是命令返回成功，而是耐久状态与权限边界仍然可解释、可恢复。

OpenClaw 2.0 的功能很多，但它们都在回答三个所有权问题：Session 状态由谁持有，执行机器能否被替换，授权绑定在哪个对象上。

如果三者混在一个本地进程里，Agent 很容易启动，也很难跨时间运营；一旦机器离线、成员变更或 Prompt 被修改，连续性和信任边界一起丢失。2.0 让 Gateway 保留状态，让 placement 承担执行，再让 Widget revision、Automation operation、Secret destination 和 Plugin capability 分别取得授权。Cloud worker 因而可以消失，长期任务却不必重新成为一场陌生对话。

这也解释了为什么它不需要在所有维度赢过 Claude Code、Codex、Hermes、Grok Bot 或 DeepSeek Harness。一个 operating layer 的价值，本来就不在替代所有执行器，而在让不同执行器进入同一套可持续运行的秩序。

如果你的任务只是在一个 repo 内完成一次修改，Claude Code 或 Codex 往往更直接；如果你要的是可自托管的个人学习型助手，Hermes 值得优先比较；想用最少配置获得托管队友，可以研究 Grok Bot；准备改造 Agent loop 本身，DeepSeek Harness 的插件化事件系统更合适。

OpenClaw 2.0 的适用点出现在另一条线上：同一个 Agent 需要跨渠道接收任务，跨设备或云 worker 执行，在 Dashboard 中被团队看见，通过 Automation 持续运行，又不能把 secret 和授权变成一张无限通行证。此时，Session 不再只是聊天记录，而成为整个系统的耐久控制对象。

这就是 2.0 最实质的变化：机器可以替换，任务可以延续；能力可以扩大，授权仍然要缩到具体对象。