OpenClaw 2.0 发布：从个人智能体迈向企业级共享基础设施

今年早些时候我们所见到的 围绕 OpenClaw 的病毒式热潮 ——这是一款开源 AI 框架，可将强大的语言模型转变为自主工作者，用户可通过其最喜爱的通信渠道（Telegram、iMessage、WhatsApp、Discord 等）向其发送消息——已从其 2026 年 3 月的峰值大幅降温。

但上周末，OpenClaw 的创始人 Peter Steinberger 及当前联合开发团队向全世界——尤其是企业界——提供了重新关注它的理由，宣布推出 OpenClaw 2.0，该版本被标榜为迄今对该框架及周边平台最重要的一次更新。

OpenClaw 2.0 旨在将最初主要作为个人智能体框架的产品，转变为日益面向团队、共享基础设施和企业工作流的设计。

OpenClaw 2.0 引入了重建的浏览器界面，将对话、文件、审批、配置及实时智能体活动整合至一个统一的工作区；新增共享云会话与多用户协作功能；并扩展了安全模型，强化沙箱隔离、基于角色的权限控制、审批管控、密钥管理及审计能力。

这些新增功能共同推动 OpenClaw 更趋近于一种组织可为员工部署的基础设施，而不再仅是单个开发者在本地运行的强大智能体。

它们同时也凸显了一个围绕该项目的紧迫竞争性问题：OpenClaw 是否已解决曾催生 NanoClaw 等更新替代方案的安全性与隔离性顾虑？

在能力层面，答案正日益趋向肯定——但并非默认即如此。

OpenClaw 希望成为共享智能体层

此次更新以正式名称 v2026.8.1发布，涵盖安装、消息传递、记忆、技能、模型、自动化、浏览器与原生应用、插件及安全性等全部方面。

Steinberger 将 OpenClaw 2.0 的开发描述为一次“用产品自身构建产品”的实践。

‘两个月前，我们启动了“用 OpenClaw 构建 OpenClaw”的使命’，Steinberger 于 8 月 31 日早间在 X 平台发文称 。

他指出，在此期间，OpenClaw 逐步将其团队从各自独立的本地编码框架迁移至 team.openclaw.ai —— 一个能感知团队成员正在从事哪些工作的共享智能体环境。

‘多人协同编码 + 借助节点与云会话实现无限算力，已彻底改变了我们的构建方式，’ Steinberger 写道，并补充称本地框架如今‘感觉像是过去的遗物’。

这一说法指向 OpenClaw 企业级定位中一项更为重要的变革。

AI 编码智能体的主流模式通常是个体化的：开发者在终端、IDE 或桌面应用程序中运行一个智能体，授予其对代码仓库的访问权限，并允许其在该环境中执行任务。

OpenClaw 2.0 正在推动一种不同的方向：智能体会话可演变为持久化工作区，其生命周期超越单一终端或单个员工；可与同事共享，可在其他机器或云工作者上执行，并可通过浏览器进行监督。

对企业而言，这有可能将智能体从员工级生产力应用转变为共享运营层。

全新用户界面有望将 OpenClaw 的适用范围拓展至开发者之外

重新设计的控制用户界面（Control UI）是该战略的核心。

OpenClaw 已放弃以概览（Overview）为优先的网页应用模式，转而将对话设为主要界面：对话线程位于侧边栏，当前活跃对话占据主工作区；文件、审批、设置及正在进行的智能体活动均围绕其保持可访问状态。

该设计有意使 OpenClaw 更贴近员工已熟知的交互模式，例如 OpenAI 的 ChatGPT、Anthropic 的 Claude、谷歌的 Gemini 及其他对话式 AI 产品。

这降低了企业采用的重要门槛。开源智能体框架往往因其暴露底层配置、终端、工具及运行时控制而具备强大能力；但这些相同特性也可能使其难以在工程部门之外部署。

OpenClaw 2.0 试图在保留底层控制能力的同时，在其之上叠加一层对话式界面：员工可向智能体下达任务，而无需将终端视作首要产品界面；但 OpenClaw 并未隐藏其底层运作过程——控制用户界面可呈现会话文件、终端活动、基于 Git 的变更、拉取请求（pull-request）状态、浏览器活动及交互式仪表板。

此次发布还更加强调智能体执行过程中的可观测性：工具调用与其结果配对更清晰；文件变更可显示为聚焦的差异（diff）；命令活动更易于检查；长时间运行的后台任务可与对话并列保持可见。这一组合对企业应用至关重要。

员工获得更简化的界面来委派工作；技术用户保有对对话背后工件及执行状态的访问权；管理员则获得一个集中化的位置来配置与监督系统。

重新设计的设置工作区现涵盖智能体、记忆、插件、MCP 服务器、设备、通信渠道及设备配对。OpenClaw 还整合了模型提供商管理，包括凭证状态，以及在提供商公开的情况下，模型可用性、配额、账户余额、预算及支出信息。

受限访问权限的浏览器用户可申请管理员权限，而非自动获得该权限；权限升级需由另一名管理员批准。

这些并非特别炫目的智能体功能；但对于将 AI 系统部署给数十或数百名员工的公司而言，它们可能是本次发布中最重要的新增功能之一。

多人会话将智能体上下文转变为共享上下文

OpenClaw 2.0 还将智能体从个人工作区扩展为协作式工作区。

共享云会话允许另一名员工在不丢弃智能体已积累上下文的前提下，加入正在进行的工作。

多用户网关（Multi-user Gateways）——即连接用户与智能体至工具、文件、凭证及其他资源的服务——可追踪对话创建者及经身份识别的参与者所提交的提示词。

所有者与管理员可决定另一用户是否可读取会话、提出修改建议、以草稿模式工作或直接参与。

该界面新增会话所有权、参与者归属、在线状态乃至输入指示器。对于编程团队而言，这引入了一种更接近协作式软件开发、而非传统 AI 聊天的工作流。

一名开发者可发起一项任务并允许智能体远程执行；另一名工程师可检查由此产生的变更；高级工程师或管理员可批准需要额外权限的操作；该项工作不必始终绑定于其起始的笔记本电脑或终端。

会话还可将在配对设备或云工作者上执行任务，同时维持更广泛的工作区。

对于正在试验长期运行智能体（agents）的企业而言，这一点意义重大。持久化智能体需要具备轮班交接、权限升级、监督机制及所有权转移等机制。否则，企业 merely构建出一批个人智能体，其状态将消散于各个用户的独立环境之中。

OpenClaw 正试图将该状态转化为协作式基础设施。目前，已有部分开源项目开发者之外的团队开始采用它。

他的团队此前已通过 Discord 使用 OpenClaw 智能体，开发者可在其中分配任务、运行命令并与其开发环境交互。但他表示，该模式仍感觉像是“向一个机器人发消息”：开发者可共享对某个智能体的访问权限，却无法真正共享该智能体的工作上下文。

他写道，新的多人协作 WebUI 改变了这一状况，因为两名开发者可同时打开同一实时会话，查看相同的历史记录与产出物，并在无需先导出或重建智能体已完成工作的前提下添加信息。“我们是在同一上下文中协同工作，”Colin 写道。

在一个示例中，另一名开发者接手了他此前负责的一个项目； Colin 并未准备传统的交接文档，而是直接加入该开发者已有的智能体对话线程，并将缺失的项目上下文直接添加进去。“会话本身即成为交接文档，”他写道。

对企业团队而言，这是一个有用的例证，说明持久化多人协作会话的重要性远不止于便利性：智能体上下文可转变为一种共享工作产物，而非困于某位员工私人对话中的信息。

Colin 的部署也同时体现了企业的应用潜力与现存的安全边界。其团队将 OpenClaw Gateway 部署在一台开发服务器上，该服务器可通过 GitHub 认证、Cloudflare Access 及 Cloudflare Tunnel 访问；Gateway 本身仅监听服务器的回环接口（loopback interface），而非暴露的公网端口。

但他明确警示，这并不意味着共享的 Gateway 构成了多租户环境。开发者彼此之间已就其背后的代码仓库、工具及智能体能力相互信任。正如他所言，Cloudflare 控制谁可进入工作区，而 OpenClaw 则追踪谁创建、拥有或贡献了相关工作；更强的隔离仍需依赖独立的基础设施。

安全性因而变得更具企业级特征。

这种转变相应地带来了一个安全问题：共享智能体可能具备比运行于开发者笔记本电脑上的智能体更广泛的组织级权限。

OpenClaw 2.0 通过显著更细粒度的控制机制予以回应。

审批现在可绑定至特定请求、命令、会话及人员。命令权限可限制于特定参数与工作目录。对于脚本驱动的执行，OpenClaw 可验证待执行脚本是否仍与最初经审核的版本一致。

会话可在不同权限级别下运行，包括只读模式、受保护模式、工作区模式及完全访问模式，其中最高权限级别仅限管理员使用。

企业还可定义操作员角色，要求由特定身份创建的会话必须在沙箱环境中执行。OpenClaw 表示，这些要求无法通过提升执行权限或主机覆盖（host overrides）绕过；若所需沙箱无法配置，则执行失败，而非静默降级至主机执行。

凭证获得额外保护。

OpenClaw 的团队范围密钥存储（Secret Store）将受保护密钥与智能体可访问的普通环境数据加以区分。对于受支持的请求，受保护凭证可被注入至 Gateway 托管的 HTTPS 请求中，而无需将该凭证直接暴露给模型。

OpenClaw 还可引用外部系统，包括 1Password 和 Vault。

审计功能已围绕执行身份、审批、会话操作及外发消息大幅扩展。插件安装可触发与待安装具体构件（artifact）相关的能力审查。

这些控制措施回应了企业在部署智能体时不可避免面临的问题：谁发起了某项操作？由哪个智能体执行？其可访问哪些资源？谁批准了该操作？当工作在人员或机器之间转移时，这些权限将如何变化？

NanoClaw 在安全性方面仍采取不同路径。

OpenClaw 的更新也使它与开源、面向企业友好的竞品之间的对比 NanoClaw 变得更加细致入微。

NanoClaw 是围绕“AI 智能体需要更强隔离性与更简明安全边界”这一理念涌现的若干后续项目之一。其架构将操作系统级隔离置于设计核心。

NanoClaw 在 Docker 容器内运行智能体，将这些容器限制为仅挂载显式声明的文件系统，并以非特权用户身份运行其进程。会话与智能体组可保持隔离状态，而非自动共享文件与对话历史。

其凭证架构遵循相同原则。受支持的外发请求可经由 OneCLI 的 Agent Vault 透传，从而允许网关注入凭证，而非将凭证置于智能体容器内部。NanoClaw 还提供一种可选的出口锁定（egress-lockdown）模式，即将智能体置于内部 Docker 网络中，并将受支持的外部流量经由网关路由。

OpenClaw 2.0 现在可复现该加固模型的诸多要素。它支持 Docker 与 Podman 沙箱、按智能体及按会话划分的沙箱作用域、可配置的只读或读写工作区访问权限、基于角色的沙箱强制策略、远程执行节点以及一次性云工作节点（disposable cloud workers）。

关键区别在于初始设定姿态（starting posture）。OpenClaw 的文档明确指出，沙箱化与执行审批默认处于关闭状态。其基础配置假定单一可信操作员，并允许主机执行，除非管理员另行配置更强限制。NanoClaw 则将隔离性视为智能体执行结构更根本的组成部分。

那么，OpenClaw 2.0 是否在安全性上与 NanoClaw 达成对等？

就可用控制措施而言，它已比以往接近得多；但在默认设置与架构哲学层面，答案是否定的。企业可将 OpenClaw 配置为高度加固的环境，但必须主动做出该决策。

一个 Gateway 仍对应一个信任域。

另一项限制对大型组织尤为关键。OpenClaw 表示，Gateway 应被视为单一信任域。

其新增的多用户权限旨在规范可信用户间的协作，不应被视作互不信任租户之间的硬性隔离。

对于需要更强隔离性的组织——例如在业务部门、客户或其他安全域之间——OpenClaw 建议采用独立的 Gateway 实例，称为“单元（cells）”，各自拥有独立的状态、凭证与工作区。

用于管理这些单元的集群工具（fleet tooling）目前仍处于实验阶段。

这一区别对于考虑将OpenClaw作为集中运营服务的企业而言可能具有重大意义。

单个Gateway内部基于角色的访问控制，可能足以满足一个受信任的工程部门或内部团队的需求；但这与面向多租户的平台截然不同——后者旨在隔离彼此之间应被假定为互不信任的客户或用户。

NanoClaw自身有其特定的配置要求和限制，即便其更强的出站网络锁定功能也仍是可选的。但其更小的架构和以容器为中心的执行模型，可能对那些希望获得更窄、更易推理的安全边界的组织更具吸引力。

OpenClaw正针对一个更广泛的问题进行优化。

OpenClaw最大的优势可能在于其控制平面。

其权衡取舍在于产品广度。

NanoClaw强调相对较小的代码库、容器隔离，以及通过代码和技能实现的定制化。其第二代架构支持所有者（owner）、管理员（administrator）和成员（member）三种角色，且一个独立的监控仪表板可提供对部署情况的可见性。

OpenClaw 2.0正试图构建一个更为广泛的运行环境。

其控制UI整合了员工交互、实时执行、文件管理、审批流程、终端、代码审查、模型提供商配置、设备管理以及共享会话等功能。

这使得OpenClaw在需要不仅安全地执行智能体，还需围绕该执行建立可用控制平面的企业中具备潜在优势。

安全团队关注隔离能力；平台团队还需部署、身份认证、模型配置、审计及策略执行能力；员工需要一个真正可用的界面；管理者需要一种方式来了解当前正在运行的内容；而开发者则需要在出现问题时能访问底层文件和工具。

OpenClaw 2.0正日益尝试通过单一系统服务于所有这些利益相关方。

OpenAI扮演什么角色？

OpenClaw称，共有933名贡献者参与了此次发布，其中包括569名首次贡献者；此次发布包含超过16,000个拉取请求（pull request），约占该项目历史上所有已合并拉取请求总数的一半。

有趣的是，此次发布并非由Steinberger的雇主OpenAI对外公布。请回顾一下， 这位奥地利开发者于2026年2月14日宣布， 他将加入OpenAI，致力于将智能体技术推广至更广泛的受众；OpenAI首席执行官Sam Altman次日公开证实了这一消息。

但OpenClaw并未并入OpenAI。Steinberger当时表示，OpenClaw将移交至一家基金会，并“保持开源与独立”，而OpenAI将为该项目提供支持。OpenClaw目前称其由OpenClaw Foundation（一家独立的501(c)(3)非营利组织）负责托管，OpenAI则与Microsoft、GitHub、NVIDIA、Atlassian、Tencent及其他组织共同列为合作伙伴。

根据目前可获取的公开信息，OpenClaw 2.0因此应被理解为OpenClaw Foundation的发布版本，而非OpenAI的产品或OpenAI软件发布版本，尽管Steinberger受雇于OpenAI，且OpenAI在资金与组织层面为该项目提供了支持。

企业就绪性如今取决于配置。

OpenClaw 2.0并未消除自主智能体所关联的安全风险，其自身文档亦明确指出了若干限制。

例如，密钥存储（Secret Store）中的值本身在静态状态下并未加密，而是依赖于文件系统保护；受保护的凭据替换（Protected credential substitution）无法覆盖所有可能的执行路径，包括某些原始套接字（raw sockets）、容器、远程节点以及提供商原生的运行环境（provider-native harnesses）；其多用户权限属于协作控制机制，而非针对恶意租户的隔离机制。

这些注意事项应防止企业将OpenClaw 2.0解读为默认即安全的智能体基础设施。但它们同时也表明，围绕该项目的讨论已发生显著变化：当前的相关比较已不再仅仅是OpenClaw与NanoClaw之间的简单对比，而愈发演变为一种以容器为先、受限的系统（如NanoClaw）与一种经刻意加固的OpenClaw部署方案之间的对比——后者可为员工与管理员提供范围大得多的使用体验。

NanoClaw仍对优先考虑较小攻击面、以容器为先的执行方式以及架构简洁性的组织保有强劲主张。

OpenClaw则押注于另一方向：企业最终需要一个既能作为运行时又能作为工作场所的智能体平台。

OpenClaw 2.0提供了构建该环境所需的诸多基础组件——沙箱机制、权限管理、受保护的凭据、审批流程、身份认证、审计功能以及隔离式部署——同时还配备了一个浏览器界面，旨在让那些永远不会通过终端配置智能体的员工也能便捷使用该系统。

剩余的重要注意事项是：企业必须将这些 基础组件 转化为 策略。OpenClaw 2.0并不会自动使OpenClaw达到企业就绪状态，但它确实使开箱即用的企业级OpenClaw部署变得容易得多。

而正如Steinberger对其自身开发流程的描述所暗示的那样，OpenClaw的长期抱负或许更为宏大：它并非旨在为每位员工再提供一个AI助手，而是将智能体本身定位为共享基础设施——一个持久化的层级，在其中人员、模型与计算资源协同开展同一项工作。