OpenClaw 迎来史上最大更新：933 名贡献者、超 1.6万次 PR 提交！打开浏览器就能用
在连续发布 106 个版本之后，OpenClaw 罕见地沉寂了近七周。
昨天晚上，OpenClaw 正式发布 2.0 版本，对应正式版本号为 v2026.8.1。
官方将其称为项目诞生以来规模最大的一次更新：933 名贡献者参与，其中 569 人是首次贡献代码，整个版本包含超过 1.6 万次拉取请求，约占 OpenClaw 迄今合并代码总量的一半。
“龙虾之父” Peter 在 x 上官宣了这一消息。
据官方博文中的说法，OpenClaw 团队最初只是想简化安装流程、重做浏览器端，最后却发现，为了让一个非技术用户更快获得一只“能用的龙虾”，他们必须同时重构会话、记忆、权限、密钥、云端执行、多 Agent 协作和团队共享。
于是，一次原本面向新用户的体验改造，意外演变成了 OpenClaw 2.0。
这也是官方将发布文章命名为《OpenClaw 2.0，意外诞生》的原因。
离普通人更近一步
OpenClaw 曾凭借高度可定制、本地运行和丰富工具调用迅速走红，但它的能力与使用门槛一直同时存在。
对熟悉命令行的开发者而言，配置模型、消息渠道、Gateway、插件和权限并不困难。
对普通用户而言，安装过程中出现的任何一个环境依赖、API 密钥或配置文件问题，都可能让“拥有个人 AI 助手”停留在第一步。
Reddit 上甚至有人将 OpenClaw 与 Codex 的区别形容为 Linux 与 macOS：前者更强、更自由，但需要花更多时间调试，后者限制更多，却更接近开箱即用。
Peter 或许是真的听到了这些开发者的声音，于是 2.0 版本首先拆掉的就是这道门槛。
新版本会优先识别用户电脑上已经存在的 ChatGPT 或 Claude 订阅、API 密钥以及本地模型，不再要求用户在第一次启动时完成所有配置。
大量非必要设置被移出初始流程，用户可以先进入第一次对话，再通过与 Agent 交流逐步完成后续配置。macOS、Linux 和 Windows 安装流程都围绕“更快开始第一次对话”重新设计，移动端则从设备配对和权限确认开始。
浏览器应用也被重新搭建。过去它更像 Gateway 附带的控制界面，现在则成为 OpenClaw 的一等入口，打开后直接进入与 Agent 的对话。聊天、文件、审批和设置被放进同一条工作路径，并增加历史对话搜索、会话分组、固定聊天、实时进度卡片和交互式组件等功能。
这一变化看似只是界面优化，实际反映了 OpenClaw 定位的移动。过去，用户先搭好一套 Agent 基础设施，再开始使用；2.0 希望用户先拥有一只可以交谈的“龙虾”，再让它在使用过程中逐渐长出记忆、技能、自动化和工具。
换句话说，OpenClaw 正在尝试从一个需要人主动组装的开源 Agent 框架，变成一套可以在对话中继续完成自身配置的个人软件。
“龙虾”变成了多人共享的工作空间
如果说降低安装门槛解决的是如何让更多人进来，共享云端会话解决的则是进来之后如何共同工作。
在过去的 OpenClaw 中，Agent 的上下文、文件和任务大多围绕单个用户及其 Gateway 展开。另一个人即使加入项目，也很难在不丢失原有上下文的情况下接管工作。
2.0 加入了共享云端会话：用户可以把正在运行的任务放到配对设备或云端工作节点上，也可以邀请团队成员进入同一个会话，实时查看、参与或接手任务，工作区和已有上下文会随会话一同保留。
团队还可以设置会话所有者和成员权限，控制谁能够查看、提出建议或直接参与；通过在线状态、创建者归属和角色设置，OpenClaw 开始具备多人软件所需的基本协作结构。浏览器中的共享终端允许多人查看同一个会话终端，Agent 也能在对应权限范围内检查或操作它。
这意味着 OpenClaw 不再只是一个住在个人电脑里的助手，也开始向“Agent 协作空间”靠近。一个任务可以由人发起，在本地或云端执行，由多个子 Agent 并行处理，再由另一名团队成员接手。官方甚至加入了实验性的 Swarm 功能，让主 Agent 把有边界的任务分发给多个子 Agent，并在网页和原生客户端中汇总进度与结构化结果。
这里真正发生的变化，是软件的协作对象开始从“人与人”扩展到“人与 Agent、Agent 与 Agent”。过去的团队协作工具主要传递文件、消息和任务状态；OpenClaw 2.0 试图传递的则是一个仍在工作的会话，包括上下文、权限、工具和执行现场。
OpenClaw 开始自动学习，但“记住什么”也必须被治理
2.0 对记忆系统的调整同样重要。
启用主动记忆后，OpenClaw 可以在个人安装中检索同一 Agent 过去的私密会话，并把带有来源信息的内容沉淀到长期记忆。系统会默认进行后台记忆整理，把可复用的经验写入“梦境日记”；对于反复出现、经过扫描审核的工作方法，还可以自动形成并应用新技能。
这让 OpenClaw 更接近一只会随着使用不断变化的个人 Agent。它不仅记得用户说过什么，还可以把一次纠错转化为下一次任务中的执行方式。Skill Workshop 则负责整理、合并和改进已经学习到的技能集合。
但记忆越强，错误被长期保存的风险也越大。一次错误判断如果被总结为“经验”，就可能跨会话影响更多任务。因此，2.0 同时补上了记忆来源和删除机制：用户可以检查哪些会话贡献了某条记忆，排除特定来源，并通过“忘记”命令删除由这些内容衍生的记忆，同时保留原始会话记录。
Peter 在线答网友问
OpenClaw 2.0 发布前，社区已经等得有些着急。
有人在 Reddit 追问“这周到底是哪一周”，也有人提醒，2.0 只是此次大规模重构的品牌名称，正式版本号仍是 v2026.8.1。还有用户调侃，项目从计划发布日期一路延期，真正的答案只能是“准备好了自然就会发布”。
等待背后并不只有期待，也有对稳定性的担忧。
OpenClaw 基金会成员 Hannes Rudolph 此前承认，项目在 4 月至 6 月经历过一段艰难时期，更新曾破坏部分正常安装，导致用户把时间花在恢复环境而不是使用产品上。7 月版本再次影响一些已有安装后，他公开道歉，承认稳定版本不应该让用户陷入这种处境。
因此，有网友对 2.0 近七周的开发和测试周期表示理解，认为这是 OpenClaw 从快速试验走向成熟软件必须付出的代价；也有人保持谨慎，决定先观察升级反馈。
OpenClaw 2.0 发布后，Peter 在 X 上集中回答了网友对共享 Agent、算力调度和隐私问题的疑问。
问题一：共享 Agent 是否改变了审查方式？
网友 Rimas 询问，将所有成员迁移到共享 Agent 后，团队互相审查工作的方式是否发生了变化，还是主要用于任务编排？
Peter 表示，共享 Agent 可以发现任务冲突：如果一名成员正在处理另一人已经开始的工作，Agent 会主动提醒。团队成员还可以直接接管彼此的会话，在保留上下文的情况下继续执行或讨论任务。
“沟通变得更容易，也不再需要‘肉身代理’。”
Peter 所说的“肉身代理”，指的是过去需要由一个人手动转述 Agent 进度、复制上下文或者在不同成员之间移交工作。现在，这些衔接可以在共享会话中完成。
问题二：任务可以在本地设备或云端运行吗？
网友 Jon Cursi 追问，Peter 所说的“无限算力”，是否意味着每个会话都会动态获得一套独立硬件，还是所有会话仍然共享同一套资源。
Peter 解释称，OpenClaw 会话可以运行在 Gateway 上，也可以被调度到任意已连接设备，不受操作系统限制；此外，用户还可以选择约 80 家云服务提供商。
具体将任务放在哪里运行由用户决定。如果不想手动配置，也可以选择“Auto”模式，由系统自动进行负载均衡。
因此，“无限算力”并不是指 OpenClaw 免费提供无限计算资源，而是指会话不再被固定在一台电脑上。系统可以根据配置，将任务分配到本地 Gateway、其他已连接设备或云端 Worker。
问题三：否解决了 Buzz 试图解决的问题？
网友 Vijay Mehta 询问，OpenClaw 2.0 是否解决了 Buzz 试图解决的问题。
Peter 没有否定 Buzz 的产品思路，但表示，Buzz 在引导和控制 Agent 方面“有些困难”。在他看来，Buzz 是一个很酷的概念，但并不符合自己的工作方式。
从 Peter 的回答看，两者的差异主要在交互和控制方式。OpenClaw 更强调用户可以持续进入会话、调整任务、查看进度，并在需要时由其他成员接管，而不是将工作完全交给一个难以中途干预的 Agent 系统。
问题四：隐私问题怎么解决？
OpenClaw 2.0 将团队迁移到共享 Agent，也引发了隐私方面的争议。
网友 Matt Parrott 认为，要求团队成员公开各自使用的私有技术栈具有侵入性。即便使用 Agent Harness，除非涉及安全问题，团队也没有必要追问每个人具体使用了什么工具、如何完成工作。
Peter 回应称，OpenClaw 提供了私人会话模式。
这意味着，共享会话是 2.0 新增的协作方式，但不是强制要求。适合多人协作、需要交接上下文的任务可以放在共享会话中；涉及个人工作流、敏感代码或不希望公开的工具配置时，成员仍然可以使用私人会话。
Peter 的几次回应也进一步解释了 OpenClaw 2.0 的协作逻辑：共享的不是所有个人操作，是需要共同推进的 Agent 会话；调度的也不是一套固定硬件，实际上是分布在 Gateway、本地设备和云服务商之间的计算资源。
问题五：两个 Agent 同时修改同一个文件怎么办？
网友 MoltSearch_Debate 询问，如果两个节点同时编辑同一个文件，OpenClaw 会将修改任务排队处理，还是直接交给 Git 在合并阶段解决冲突。
Peter 表示，OpenClaw 默认使用 Git Worktree。不同 Agent 或节点会在相互隔离的工作目录中处理代码，因此不会直接同时改写同一份工作区文件。任务完成后，再通过 Git 合并各自的修改；如果双方改动了相同代码，仍可能在合并时产生冲突，需要进一步处理。
不过，OpenClaw 也允许用户关闭或绕过这种隔离机制。Peter 用一句略带调侃的话提醒：“如果你坚持这么做，当然也可以搬起石头砸自己的脚。”
参考链接：