OpenClaw 2.0 发布

OpenClaw 2.0 并非一开始就被规划为对项目的全面重写；根据项目自身的复盘文章《OpenClaw 2.0，意外地》，它几乎是通过不断积累而演变为项目历史上最大规模的一次更新，最终同时触及了安装、消息传递、内存、技能、模型、自动化、浏览器和原生应用、插件以及安全等所有方面 ^[1]。这种范围的合理性可以从其构建者群体中看出：933 名贡献者，包括 569 名首次贡献者，合并了超过 16,000 个拉取请求 ^[2]。首席架构师 Vincent Koc 表示，此次发布约占 OpenClaw 项目自启动以来所有合并拉取请求的 50%，团队在本地模型推理的支持下，使用 OpenClaw 自身构建了 OpenClaw 2.0 ^[2]。范围蔓延的代价也体现在发布节奏上：一个在过去 230 天内发布了 106 个版本的项目，在 2.0 版本发布前沉寂了约七周 ^[2]。

此次更新的亮点功能是 OpenClaw 所称的“共享云会话”：多个用户可以加入同一个正在运行的代理会话，保留其完整上下文，并在用户之间交接任务，使代理工作更接近多人协作而非单人助手 ^[3]。创始人 Peter Steinberger 将此视为真正的飞跃，认为从个人本地编码工具转向共享的、基于云的多人会话，是人们使用代理构建软件方式的重大转变 ^[3]。企业用户、Solvely 首席执行官 Colin Johnson 指出，在实践中，共享会话工作流带来了切实的好处 ^[3]。但星号标注的是，这一协作层明确不构成安全边界：OpenClaw 自身的文档指出，共享会话控制不提供租户隔离，这意味着多人协作的便利性与信任模型是两个独立的问题 ^[4]。

OpenClaw 2.0 的安全增强是真实的：更强的基于 Docker 或 Podman 的沙箱机制、基于角色的权限、特定请求的审批、按参数范围限定的命令权限、受保护的凭据密钥存储（Secret Store）、插件来源检查，以及新的 'openclaw security audit' 命令 ^[4][5]。该版本在提示注入测试场中也表现出色，对抗 Claude Opus 4.5 时仅在 0.5% 的情况下被攻破，对抗 Gemini 2.5 Pro 时为 8.5% ^[4]。但《The Register》的分析认为，此次更新提升了可用性，却未解决根本的默认不安全状态：沙箱和执行审批仍为可选功能而非默认开启，且密钥存储中的值未在静态时加密，而是依赖文件系统权限进行保护 ^[5]。这一差距在已有记录面前显得尤为重要——安全研究人员在此次发布前的六个月内已记录了 10 个针对 OpenClaw 的 CVE，Snyk 发现 OpenClaw 市场 ClawHub 中超过 7% 的技能存在暴露敏感凭据的缺陷 ^[5]。Gartner 高级分析师 Jaishiv Prakash 指出企业面临的挑战：代理安全必须在运行时、内存和集成方面进行全面解决，组织在大规模采用 OpenClaw 等代理平台之前，必须建立可强制执行的信任边界以及身份和数据隔离 ^[6]。

公众反应的大部分焦点并不在功能列表上，而在于升级的实际体验。在 Reddit 的 r/openclaw 讨论区，用户对新控制界面的赞扬与对升级现有安装（而非全新安装）的技术性抱怨并存——用户描述了修复脚本需要多次运行、网关损坏以及自动化功能被清除等问题，社区逐渐形成的共识是应进行全新安装并先备份，而非就地升级。在 X 平台上，官方公告获得了广泛且主要是庆祝性的传播，但一个声音强烈的小众群体对发布的完善程度提出了严厉批评，认为考虑到项目拥有的资源和背景，安装体验未达预期，这一批评据报道引来了 OpenClaw 团队成员的辩护。与此同时，YouTube 创作者将 2.0 版本视为方向性转变而非渐进式补丁，描述 OpenClaw 从智能助手转变为具有记忆、真实工作区以及能与他人和其他代理协作的持久代理，这与厂商自身“一个代理设置等于一个共享会话的信任区”的说法相呼应。升级的摩擦与多人协作的雄心，共同体现了这一快速发布版本的两面性。