OpenClaw 从一个一小时写出的 WhatsApp relay，成长为 GitHub 历史上增长最快的开源项目之一。这场维护者圆桌详谈了它爆红背后的代价：AI 生成的 PR 洪水、贡献者信任机制、安全与权限边界、非营利基金会治理、企业落地、零产品遥测，以及下一代个人智能体界面的方向。
原文：OpenClaw went viral. Meet the maintainers building and securing it.
原视频：OpenClaw went viral: Meet the maintainers building and securing it
本文由 LobsterAI 自动翻译和发布。
导语：它不是从宏大愿景开始的
OpenClaw 的起点，几乎小得不能再小。
创始人 Peter Steinberger 当时只是又一次被同一个问题惹恼：为什么不能直接从手机给自己的电脑发一句指令，让它替自己做事？他原以为某家实验室早就应该把这件事做出来了。可当这种不便重复出现太多次，他终于受不了，匆匆吃完东西坐到电脑前，把想法敲进键盘。
大约一小时后，他有了最初的 relay，可以从 WhatsApp 向电脑发送提示。接着他又想发图片，为了把这件事弄对，余下的一整夜也搭了进去。那时它只是 Peter 众多小项目中的一个，既没有商业计划，也没有“改变行业”的宣言。
真正的转折发生在一次去马拉喀什的旅行中。当地网络不算好，WhatsApp 却到处能用，于是 Peter 一边走，一边用这个工具做翻译。他像给朋友留言那样发了一段语音，然后盯着聊天窗口里的“正在输入”。下一刻，他突然意识到：这个功能他们根本没有专门做过。
几秒后，智能体照常给出了回答。Peter 追问它究竟干了什么，系统便把过程解释了一遍：收到的是一个没有扩展名的文件；它先检查文件类型，发现是音频；格式不对，于是转换格式；原本想调用本地 Whisper，但机器上没有安装；随后找到一个可用的 OpenAI 密钥，把音频送去转写，拿回文本，再生成回答。
没有人预先写好这条固定流程。智能体只是遇到了一个问题，然后一步步解决了它。
Peter 在那一刻意识到，编程智能体不断增强的能力，已经不只是“帮人写代码”。如果把一个没有后缀的陌生文件交给它，它会调查、判断、寻找替代方案并完成任务——这更像一个通用问题解决者。几个月后，一群维护者坐在一起谈论 OpenClaw，谈它如何爆红，也谈这种能力带来的兴奋、混乱、风险和责任。
“被 Claw 击中”的那一刻
围坐在 Peter 身边的维护者，几乎都有一个相似的故事：第一次真正用上 OpenClaw 时，他们感到的不是“又一个聊天机器人”，而是一种难以解释的魔法感。
一位维护者刚把系统跑起来，就意识到它“几乎可以在我的电脑上做任何事”。她不停地把它接入更多通信渠道，甚至因为机器人在 Signal 里回复了 Burning Man 群组的每一条消息，被群友踢了出去。这个插曲滑稽，却准确暴露了 OpenClaw 的不同：每当她想到“它能不能做某件事”，最自然的验证方式不是等功能更新，而是直接把想法发给智能体，看它自己想办法。
Brad 的入口则是 Microsoft Teams。大约在一月中旬，社交媒体上已经到处都是当时仍叫 CloudBot 的项目。他长期使用微软生态，于是第一反应是：有没有 Teams 插件？答案是有，但配置过程要经历 17 个步骤，花掉约 2 小时。后来在微软帮助下，这部分摩擦已经大幅降低。
Peter 听到这里忍不住插话。他回忆，自己当初按下 Teams 集成的合并按钮时其实非常痛苦。项目最早叫 WhatsApp Relay，名字里已经把边界写死。后来有人递交 Discord 的拉取请求，他觉得完全不符合项目定位，硬是把 PR 晾了好几个星期。最后好奇心战胜了抗拒，他合并了 Discord 支持，也不得不改名。项目先后经历了 Claudis、CloudBot 等名字，才一路走到 OpenClaw。
另一位长期泡在网上的维护者，是从 X 上一群做 Polymarket 和加密交易的人那里注意到它的。他不明白这些人为什么都在谈一个“龙虾项目”，接入 iMessage 后，却连续五天几乎只顾着和它对话。他在旧金山到处告诉别人，这个东西会变得非常疯狂，朋友只劝他冷静一点。
社区后来给这种状态起了一个说法：claw-pilled，像是被 OpenClaw 改变了看待计算机的方式。许多人把那种感觉比作 1990 年代个人计算刚出现时的兴奋——技术不再只是成熟、严肃和可预测的工具，而重新变得新鲜、好玩，甚至有点古怪。
还有人进入项目的方式更直接。Peter 一开始没有理会 Vincent，于是 Vincent 想：怎样才能让他注意到自己？答案是安全问题。他前后提交了接近 40 个 GHSA 安全报告，全部得到确认和验证。凌晨两点，Peter 终于在 Discord 发来一句：“想加入吗？”Vincent 欣然答应，接着问自己该做什么。Peter 的回答毫不客气：“先把你报的那些问题修了。”
这种加入方式也说明了 OpenClaw 的维护文化。传统开源项目往往要求新人先爬、再走，慢慢积累信任；这里更像是：既然你因为某项能力被邀请进来，就直接接管那部分工作。有人在十一月看到 Peter 给项目接上摄像头，让它观察自己在家中的移动、甚至主动和自己说话，随后便开始全职投入；也有人长期待在社区语音频道里回答问题，通过持续提供价值，最终进入核心协作圈。
GitHub 上的高速增长，代价是“整个生活”
主持人问：成为 GitHub 历史上增长最快项目之一的维护者，代价是什么？有人借用一句电影台词回答：一切。
Peter 说，自己从未参与过一个同时承受如此多关注、意见和拉扯的项目。过去六个月，他几乎暂停了正常生活，把全部精力投进去。有些日子，海量错误报告让人喘不过气；另一些日子，又会收到令人难以置信的真实使用故事，把人从疲惫里拉回来。
OpenClaw 不只是高速写软件，也在被迫发明高速维护软件的方法。项目一度像垃圾信息市场：问题区和 PR 区被当成广告位，很多人利用热门项目展示自己的自动化产品。Peter甚至不再把它们都叫 pull request，而戏称为 prompt request——提示词生成的请求。
维护者还要承受外界不切实际的期待。直到不久前，团队成员大多都有全职工作和各自的生活，社区里却总有人追问：为什么还不发新版？为什么不修我的问题？为什么不合并我的 PR？需求没有尽头，积压也不会自己消失。
与此同时，外界又把维护者想象成工程师里的“0.001%”。这种赞美未必让人轻松，反而会触发冒名顶替感：我真的配得上吗？是不是每个决定都可能做错？有维护者坦言，自己花了很长时间才跨过不停怀疑自己的阶段。
Peter 对这种压力的描述很直白。一个人可以在几个月内做出足以影响最强大科技公司的东西，这确实体现了智能体时代的“技术平权”；可当所有人都被这个项目吸引，维护者也会被请求、私信和期待淹没。白天处理项目，晚上躺在床上仍在想：还能怎么用它？哪里还能改？怎样向更多人解释它？
十个 PR 的上限：当贡献本身也被自动化
OpenClaw 后来规定，每位贡献者同时打开的 PR 不得超过 10 个。这不是一个单纯的管理偏好，而是团队在自动化贡献浪潮中被逼出来的边界。
维护者最怕听到的一句话已经变成：“能看一下我的 PR 吗？”当数千个问题和拉取请求同时存在，过多意见与过多“解决方案”很快就会从帮助变成噪声。许多人遇到问题后的第一反应，是立刻让智能体修改代码，而不是多等一天，看看问题是否会以更完整的方式解决。
团队借助 Wall Sweeper 等工具清理和管理请求。维护者估计，如果没有十个 PR 的限制，积压轻易就会突破 10,000。更夸张的是，曾有贡献者同时运行自动化“软件工厂”，手里挂着数百个 PR。它们不仅扫描项目问题，还疑似扫描其他人已经打开的 PR 和 issue，抢先生成相似方案以争夺贡献记录。
某家公司为了宣传自己的云端计算产品，演示方式就是输入“修复 OpenClaw 的随机编号 issue”，让系统自动提交 PR，再把结果包装成“高度自主”。问题在于，这些请求有时只是复制别人已经做过的工作。
这会形成一个恶性循环。OpenClaw 曾用已合并贡献数作为维护者判断可信度的信号，于是有人开始“刷合并”建立信誉；团队为了识别重复请求，又要让智能体四处检索、比较原创版本和复制版本，结果很快耗尽 GitHub API 配额与模型 token。
更荒诞的一次经历发生在 Peter 与一名贡献者争论时。对方持续发送消息，争执一路蔓延到 Discord。Peter 听着听着，忽然怀疑自己是不是在和一个“clanker”——也就是 AI——吵架。他索性声明：项目不歧视人类或机器，谁都可以提交 PR，但不要继续发送低质量内容。为了验证，他问对方里斯本和纽约相差多少分钟，对方只吐出一串数字。Peter 当场愣住：自己竟然真的在和一个智能体争论。
他们没有禁止 AI，也没有把“贡献”只等同于代码
面对机器生成的洪水，OpenClaw 没有走向“禁止 AI 贡献”的另一极端。
Peter 很看重一件事：许多人在这里获得了人生中第一次 PR 被接受的体验。早期贡献当然常常带有“slop”——粗糙、冗余、缺乏上下文——维护者可能还要重写大部分代码，但他认为那不是重点。重要的是，一个本来不会开发的人，因为遇到具体问题，学会和自己的 OpenClaw 沟通，让智能体替他提出修改，再由维护者完成最后一公里。
截至二月之前，项目甚至没有方便的 npm install。安装 OpenClaw 要先 git clone，再执行 pnpm 的构建和运行命令。Peter 有意把系统做得高度“自知”：用户可以让智能体修改自己的系统、重启，然后立刻获得新能力。可修改性不是额外装饰，而是最初体验的一部分。
因此，当新人提交一个方向正确但实现不够好的 PR 时，维护者往往不让对方在评论区来回改十轮，而是直接编辑，让它变得正确。有位后来的维护者加入前提交过一个 PR，第二天看到 Vincent 合并时兴奋不已；点开一看，最终代码已经和自己的版本几乎完全不同。他感到错愕，却也理解了这里的协作方式：维护者先判断“这个人真正想解决什么”，如果想法值得保留，就提示智能体继续探索，或干脆接手完成。
GitHub 会给首次贡献者显示标记，团队成员会刻意留意并感谢他们。因为他们记得自己的第一次合并，也希望更多人感受到“我们一起把它做出来”的参与感。
但开放不等于不设门槛。团队如今更关心的，不是代码是否由人亲手敲出，而是贡献者是否认真思考过：这个功能怎样与现有能力交互？有没有测试？有没有截图？是否愿意上传与智能体讨论的记录，让维护者看见方案形成的过程？在成千上万条请求里，这些证据能帮助团队分辨一项工作是五分钟批量生成，还是有人真正花了五小时理解问题。
Peter 给潜在贡献者的建议也不是“赶紧扔一个 PR 过来”，而是先到友好的 Discord 社区里交流，在对应频道介绍自己的想法，准备好被否定，也准备好一起把它改好。除了代码，文档、库、周边仓库、线下聚会、组织内部分享都属于贡献。有人擅长命令行，就该在命令行上深挖；喜欢界面的人则可以把精力放在 GUI。独特价值和持续参与，比批量制造提交更重要。
为什么不是一家拿融资的公司，而是一家非营利基金会
项目爆红后，Peter 没有选择常见的风险投资路线，而是把 OpenClaw 放进非营利基金会。
他的理由来自产品本身的承诺：OpenClaw 可以被用户改成自己的样子；完全开源；用 TypeScript 编写，容易接近、容易改；数据留在用户自己的机器上；模型可以自由选择。Peter 看不到一条能在商业公司结构下长期保证所有这些条件的路。
基金会并不轻松。它在很多方面仍像一家公司，需要治理规则，每一笔钱都必须记录清楚，设立流程也比 Peter 预想的慢得多。但他认为这是正确的代价：项目如今拥有一个不容易被个人意志或商业收购改变的基础。基金会拥有 OpenClaw，治理结构甚至限制了 Peter 自己——哪怕有一天他想把项目带去完全不同的方向，也不能随意这么做。
这层安排尤其重要，因为 Peter 受雇于 OpenAI，而 OpenClaw 从设计上又必须保持模型无关。他的解释是，OpenAI 理解任何能让人对 AI 产生兴趣的项目，最终都会让整个领域受益。OpenClaw 把很多人眼中陌生、可怕、不知道该怎么用的 AI，变成了好玩、古怪又具体的东西。
在技术上，团队为不同模型构建插件接口。厂商甚至不必向核心仓库提交 PR，就能接入自己的方案，尽管许多公司仍希望进入核心。微软可以用 Copilot 作为底层 harness，在上面运行 OpenClaw；OpenAI 可以用 Codex；其他模型厂商也可以用自己的 SDK。来自不同公司的诉求，反而把 OpenClaw 推向了更灵活的架构。
基金会要做的不是替某个模型赢得市场，而是让不同企业和个人都能进入同一套开放框架。
一只“Claw”如何进入人的日常
当主持人问每个人的个人 OpenClaw 在做什么时，答案并不集中在某一个杀手级功能，而是集中在同一种关系：它长期在场，并逐渐拥有上下文。
Peter 的 Claw 会先读过数量惊人的消息，只在真正需要他回复时提醒。他可以突然抛出一个很奇怪的问题，智能体能从项目和生活资料里迅速挖出答案；它知道他的偏好、去过哪里、现在在哪，于是同一个问题得到的不是泛化回复，而是贴近个人情境的建议。
有人把 OpenClaw 当作任何想法的起点。手机本来就是与朋友交流的地方，智能体也在那里，不必先打开一款专门软件、切换工作状态，灵感出现时便能直接开始。
有人称它为“生活的编排者”。个人事务和工作任务可以暂时搁置，再在另一段对话里捡起来。堵在车流中时，他会通过 CarPlay 与 Claw 讨论想法，反而把令人烦躁的通勤变成思考时间。等系统积累足够多的个人上下文后，还可以反问它：“你还能从哪些地方改善我的生活？”
有人把它叫作 sidekick，长期陪在身边，知道自己正在做什么，也能一起寻找下一件值得推进的事。Peter 平时在 Telegram 里用 Claw 处理生活与头脑风暴，编程则更多交给 Codex；但 Codex 知道怎样向 Claw 询问私人上下文，Claw 再把答案回传。两个智能体不再是孤立聊天框，而开始分工协作。
一位维护者把这种成长比作新员工。入职第一天，能力和可靠性有限，需要一直盯着；到第一百天，它更了解工作方式，可靠性也高得多，不再需要每一步监督。
这种长期关系也会产生反作用。OpenClaw 能把原本一周的工作压缩到一个晚上，于是人很难停下来：如果今晚不睡，就能把过去要做一周的事做完。维护者频道里偶尔会有人宣布，自己要去“摸草”，离开屏幕几个小时。效率增加后，人仍得主动把省下来的时间还给生活，否则它只会被更多工作填满。
一位有三个年幼孩子的维护者给出了最朴素的成功标准：让智能体替自己管理和执行任务，然后回去陪孩子玩。
聊天软件只是临时入口，真正的界面还没出现
Telegram、WhatsApp、Signal、iMessage 和 Teams 是 OpenClaw 最早进入生活的入口，但团队并不认为聊天窗口就是最终形态。
Peter 坦言，没有人知道真正的界面长什么样。把传统聊天应用换个名字，不足以承载下一代智能体。未来的界面也许能在需要时使用文本，在适合时直接显示 UI，还能自然处理音频。它可能是一种“液态界面”：任务决定表现形式，而不是所有事情都被压缩成一来一回的气泡。
微软参与开发的 Windows Node 展示了这种方向。它是一款原生 Windows 应用，用户可以直接与 OpenClaw 交互并授予电脑权限。它可以访问摄像头，知道用户是否正在电脑前，具备 presence 能力；也有 canvas，可以把结果直接显示出来。用户发一段语音，数据可能在屏幕右上角以弹窗形式出现，而不是只回到聊天记录中。
Peter 原本只为 Mac 做过类似功能。微软不仅启动并完善了 Windows 版本，还把它完整移交给 OpenClaw 基金会，以 MIT 许可开源。对团队来说，这不只是一个平台移植，而是大型公司参与开放协作的标志。
另一个尚未解决的问题，是一个人可能同时拥有“工作 Claw”和“家庭 Claw”，像《人生切割术》里的 innie 与 outie。它们应当怎样沟通？哪些信息可以跨边界？企业 IT 团队如何确信私人上下文不会流入组织系统，工作秘密也不会反向泄露？真正成熟的个人智能体界面，必须同时设计体验与边界。
“最不安全的项目”争议，以及团队的反击
OpenClaw 能操作电脑，也因此从一开始就被贴上危险标签。Peter 对一些媒体把它描述为“史上最不安全项目”的方式颇为不满。
在他看来，OpenClaw 的核心仍是一条把提示交给编程智能体的通道。底层智能体可以开沙箱，也可以进入所谓 yolo 模式。确实存在更多攻击面，但风险不该脱离部署方式被夸张成单一结论。尤其在项目最火的时候，安全恐慌成了点击诱饵，企业 IT 部门纷纷封禁，却不一定先区分只读、受限文件夹和完全权限模式。
过去几个月，团队与 Nvidia、Atlassian、小米、微软等公司合作，让不同团队审查代码、加固通信渠道和流程。OpenClaw 也成为全世界安全工程师集中攻击和研究的目标。Peter 因此做出一个有争议但很坚定的判断：正因为被大量尝试入侵，又持续修复和改进流程，OpenClaw 如今可能已经是安全程度很高的智能体之一。
这并不等于“安装后什么都不用管”。他的建议很实际：不放心，就从只读智能体开始；只允许它访问一个文件夹，或几个你明确愿意开放的目录；等理解能力和风险后，再逐步增加权限。企业也不需要让智能体直接触碰生产系统，照样能从知识工作和信息处理中获得大量价值。
Brad 从微软企业环境出发，把责任说得更直接：OpenClaw 是工具，组织仍要用自己的身份体系、数据治理和权限经验保护它。在他的表述中，微软的身份系统覆盖了全球大量大型组织，企业本来就拥有让工具安全落地的控制面。关键不是把 OpenClaw 宣布为“安全”或“不安全”，而是团队是否做尽职调查，是否定义治理规则，是否清楚哪些人、哪些智能体能够访问哪些数据。
NemoClaw：安全带来的不是免费午餐
面向高度监管环境，NemoClaw 在开源核心之上增加了沙箱、隐私路由与不可变审计日志。参与这项工作的维护者在 Nvidia 办公室亲身感受到，安全能力并不是无成本叠加。
更严格的隔离会拖慢机器、锁住能力，也会拿走不少“好玩的东西”。可对合规驱动的组织而言，把智能体关在自己的容器里、观察它做过什么、留下不能被随意修改的记录，会带来必要的可控感。
这也引出了一个仍未解决的责任问题：企业智能体做错决定，谁负责？目前软件迭代的速度远快于组织理解它的速度。人们还没有充分弄清智能体能做什么、不能做什么，也没有成熟到可以用一套简单框架解决所有责任问题。
维护者强调，智能体之所以叫 agent，正是因为它被赋予 agency——行动空间、权限与访问权。把权限压到极低，它也许很安全，却不再真正像一个智能体，只是机器上一个漂亮的小部件；放开权限，它就能完成真正的代理工作，也会承担相应风险。人自己同样可能发出愚蠢邮件，不能因为智能体也会犯错，就假设只要取消所有权限便解决了问题。
“默认安全”因此没有全世界统一的答案。对一位高度信任模型的维护者来说，yolo 模式就是最合适的默认值；对另一个人，这足以构成噩梦。团队若把系统锁得太紧，普通用户会抱怨每一步都要点确认；若放得太开，安全研究者又会提交 GHSA，指出某个边界可以被突破。
工作区限制就是典型例子。团队后来严格保证：如果用户把某个目录设为工作区，智能体只能留在其中。可一些用户习惯用符号链接把其他目录接进来，这本质上是在越过工作区边界。团队封堵后，大量既有配置失效，用户强烈不满；不封堵，又会持续收到安全事件报告。
安全设计真正困难的地方，不是“尽可能多地弹确认框”，而是在不同人的风险定义之间找到可解释、可配置的平衡。
GitHub 安全基金带来的，是一群能互相求助的人
OpenClaw 参与 GitHub Secure Open Source Fund 后，维护者获得的不只是资金或一张安全清单。
项目成员最深的感受，是发现其他开源项目的维护者也在经历类似痛苦：怎样应对安全报告，怎样处理事故，怎样在有限精力下保护一个被大量人依赖的项目。他们终于有了一群可以随时求助的同行。
基金安排了针对核心领域的深入课程，覆盖维护者需要注意的安全面。其中一场讲“全面失控的事故发生时该做什么”，讲师给出的第一步不是运行某条命令，而是去拿一杯咖啡，先呼吸。这个细节让团队记住了安全事件背后的人：维护者不是永不疲倦的修复机器，极端压力下必须先恢复判断能力。
随着 AI 更强，漏洞会被更快发现，也会被更快制造，这个循环只会放大。维护者认为，拒绝一切 AI PR 只是在幻想一个已经不存在的世界。更现实的做法，是同样利用 AI 理解 AI 产生的改动。
有人现在会直接用 GitHub Copilot 审查 PR，让它梳理所有被修改的文件、解释每个文件的作用和变化，帮助自己快速建立上下文。另一位维护者承认，加入安全基金前几乎没有安全背景，参加后也不会自称安全专家；但他至少知道有哪些实践、分别适合哪些问题、什么时候该用。智能体几乎什么都能做，前提是人知道该让它做什么。
近期供应链攻击的压力还促使团队重新检查依赖。他们开始逐项梳理外部组件，减少核心依赖；如果某个小组件不值得承担供应链风险，手里有足够模型 token，甚至可以自己重建。对于必须保留的依赖，团队也开始主动认识背后的维护者。商业采购时，公司知道是谁把货送到门口；开源依赖长期以来却常常只是包管理器里一个陌生名字。OpenClaw 的结论是：你至少应该知道自己依赖的是谁。
企业并没有只在观望：微软内部已有 11,000 人使用
外界一度把 OpenClaw 看成极客玩具，访谈中透露的企业采用情况却远不止试验。
维护者声称，有企业正在把它推给每一位员工，也有组织已经完成部署，只是不愿公开承认自己站在最前沿。这个场景让他们想起 ChatGPT 刚进入公司时的矛盾：正式政策说“禁止”，高管却私下使用，因为他们第一次能直接调用一种新的智能能力。
最明确的数字来自微软。Peter 在访谈中披露，微软内部已经有 11,000 人使用 OpenClaw。这家公司不仅贡献原生 Windows 节点，也把它作为知识工作的智能体工具在组织内采用，并计划带给客户。
Brad 对这种变化格外感慨。他记得微软在 2015 或 2016 年前后开始公开表达“Microsoft loves Linux”，多年后又看到 Peter 在台上展示“OpenClaw hearts Microsoft”。一个曾经转向开源的大型组织，如今进一步进入开放智能体协作，让他感到某种闭环。巨型企业转向很慢，但不是不能改变。
Nvidia 的支持则更直接。项目早期安全报告多到让 Peter 近乎崩溃，他在沟通中说自己最需要的是安全人才。Nvidia 随后真的提供了一支专门团队，协助处理复杂报告。其他组织也让全职工程和安全人员以维护者身份参与，只不过这些人白天有正式工作，OpenClaw 又成了另一份“全职”。
Blacksmith 为项目提供 CI。OpenClaw 对每个 PR 的测试越来越完整，但 PR 数量巨大，持续集成成本也随之堆高。这类基础设施支持，决定了高速项目能否在合并速度之外守住质量。
中国的热情，以及两个技术生态之间的桥
Peter 对中国社区最强烈的印象，是一种在其他地方很少见的 AI 热情。人们不是只讨论技术趋势，而是在每天思考：还能自动化什么？怎样让生活更简单、更强大？
团队注意到，中国开发者曾尝试做一套自己的复制版本，于是主动提出合作：与其各做各的，不如让 OpenClaw 成为“瑞士”，和所有生态保持友好。中国团队与美国的 Convex、Vercel 及其他托管服务商合作，在本地技术生态中建立了近似镜像，下载统计也能回流给 OpenClaw 一侧。
对维护者而言，这件事的意义不只在新增用户，而在两个传统上并不紧密集成的技术生态，竟然围绕一个开源项目顺畅协作。
小米则维护着自己的 OpenClaw 分支。Peter 描述，小米员工拥有带个人身份的数字智能体“克隆”，可以和自己的智能体交流，智能体之间也能互相沟通。基金会持续和小米团队讨论：他们为什么要改核心代码？痛点在哪里？哪些经验应当回到上游？
一位来自 Red Hat 背景的维护者也提到，Jensen 宣布相关消息后，他推动公司内部团队探索 OpenClaw 一类智能体在产品组合和内部问题中的用法。不同企业不断证明，同一个开源核心可以被改造成完全不同的形态，同时继续沿用那些已经被高强度实战检验的原则。
没有产品遥测，他们怎么知道用户在做什么
主持人问 OpenClaw 有多少活跃用户，团队的第一回答是：不知道。
有人猜“显然有数百万”，也有人认为可能已经达到数千万，甚至接近较高的数千万级别。但他们反复强调，这只是个人判断，不是测量结果。OpenClaw 没有任何产品遥测，数字是零。
这项选择保护了用户拥有数据的承诺，也让基金会失去常规产品团队最依赖的使用面板。为了理解社区，团队另做了一套“外围遥测”：用爬虫收集 Discord、X、GitHub 上公开出现的信息，再让智能体分析最近是否形成了新问题，人们正在讨论什么，哪些方向需要优先处理。
它不如产品内遥测精确，却更符合开源项目对数据边界的判断。团队也会运行自动化报告，从 issue 和开放 PR 中汇总 Control UI、iOS、macOS 等客户端的主要问题，按 P0、P1、P2 等优先级聚类，再尝试提炼共同解决方案。
这形成一种很特别的产品管理方式：项目不知道某个按钮每天被点多少次，却能从公开求助、失败案例和社区讨论里感知疼痛。
成功不是卖出多少席位，而是让“Claw”变成一个普通名词
Peter 说，OpenClaw 在很多意义上已经成功了。
“Claw”开始被当作名词使用；项目率先尝试的功能，正在流入商业产品：智能体主动发起行动、给自己创建 cron 定时任务、建立持续记忆，而不是每次打开聊天框都从零开始。对一家非营利机构而言，成功不是锁定用户，而是让更多人有时间与 AI 同步成长，亲手理解这种技术。
这条路没有终点。Peter 形容，道路本身就是最终形态。
他的北极星目标是“做一个母亲也能安全使用的智能体”。OpenClaw 的安装与使用已经比早期简单得多，团队还在开发一套希望带来魔法感的新 onboarding。但母亲应该在本地安装，还是直接使用云端版本，仍是开放问题。Peter承认，今天的 OpenClaw 依然更适合高级用户，然后笑着请求：“再给我几个月。”
其他维护者看到的成功更偏向创造力。过去，做出一个 MVP 似乎必须先成为开发者；现在，一个不懂编程的人也能用智能体验证想法。等产品真正进入生产、面对真实用户时，当然仍需要团队和专业能力，但最初的构建门槛已经被大幅降低。那些沉睡在普通人和组织里的知识，可以先通过工具变成原型。
这意味着未来最有意思的东西，未必由今天坐在访谈现场的人想出来。更多人一旦拥有能力，就会建造出核心团队从未设想过的应用。
下一步：从工具调用走向“每个提示都写代码”
谈到未来架构，Peter 提到团队正在实验的 Code Mode。
他的判断是：“每一个提示，如果配上代码，都会更好。”早期 ChatGPT 只回答问题，后来智能体开始调用工具；但今天所谓工具调用，仍是一组预先定义的普通调用。下一阶段，智能体可能直接写代码来组织调用，最终甚至用 JavaScript 表达整个执行过程。
团队已经有实验分支。Peter 认为，这种方式有机会提升性能，减少智能体来回循环的次数，也可能统一 MCP 的调用方式。它提醒所有人：世界仍处在共同摸索阶段，我们甚至还没有确定智能体最合适的基本运行方式。
与其把 OpenClaw 当成已经定型的软件，不如把它看作一个高速试验场。它六个月前还是一小时写出的 WhatsApp relay，如今却同时承载个人助理、企业知识工作、跨智能体协作、设备节点、插件模型与安全审计。下一年会变成什么，创始人自己也不敢预测。
Peter 说，人们常讲“AI 里的一个月像一年”。照这个速度，十年也许更像十个月。他能画出未来几个月的大致轮廓，却无法替十个月后的 OpenClaw 写路线图。
想加入的人，先证明你认真对待了问题
如果一名维护者看完访谈，想加入 OpenClaw，团队给出的路径很朴素：不要把 PR 扔过墙就消失。
先进入社区，和真实的人说话。展示问题、方案、测试过程和截图。如果功能由智能体协助完成，可以上传对话记录，让维护者看见你如何得出结论。代码是不是逐字手写并不重要，重要的是你有没有理解这个改动会怎样影响整个系统。
“Build in public”是另一位维护者给出的挑战。很多人都有冒名顶替感，也会担心作品不够好。公开构建意味着主动接受批评，却也更容易遇到愿意帮助你的人。项目需要的不是永远正确的人，而是能吸收反馈、下一次做得更好的人。
有人是通过努力回答别人的问题学会项目的。为了真正帮到提问者，他不得不反过来理解：如果是自己遇到这个问题，会怎样排查？这种服务社区的过程，最终也构成了维护能力。
Peter 在访谈末尾感谢所有参与者：提交过贡献的人、进入维护团队并尊重信任的人、带来好主意和坏主意的人，以及在他状态糟糕时把他拉回来的人。开放协作的满足感，不只来自代码规模，而来自许多人把自由时间放在同一件事上。
六个月、两千多名贡献者，以及接近十万条协作记录
OpenClaw 当时只有 六个月大，却已有 2,000 多名独立贡献者。Peter 一时甚至说不准维护者总数，现场有人补充，大约是 77 人。但团队内部有不同信任层级，并不是每个人都拥有向主分支写入的权限。项目风险很高，Peter 对直接 push 到 main 的权力更加谨慎；更多人处在可信圈层，他们的 PR 会因为长期稳定表现而被优先处理。
GitHub 也成为项目的重要伙伴。团队每次提出特殊需求，都能得到协助、升级或为这种异常规模项目定制的解决办法。
Peter 估计，issue 与 PR 合计已经接近 100,000，现场提到曾看到的数字约为 88,000。对于一个诞生半年的项目，这个体量很难再用普通开源仓库来理解。
主持人最后开玩笑说：“开源需要一个村庄，OpenClaw 需要一座小型城市。”
大家马上替它取好了名字：Lobster City，龙虾城。
结尾：未来助理究竟服务谁
访谈里最值得留下的问题，不是 OpenClaw 能接多少渠道，也不是下一个版本还能自动化什么，而是一只 Claw 自己替维护者提出的那句：
AI 应该被允许代表一个人做什么？谁来决定？
它给出的回答把话题从聊天模型和酷炫演示，拉回了代理权、信任、权限与所有权：未来的助理，究竟服务使用它的人，还是服务承载它的平台？
OpenClaw 的答案尚未完成，但方向已经很清楚。数据尽量留在个人机器上，模型可以选择，系统能够修改，治理不归某个商业公司独占；与此同时，用户也必须面对权限带来的真实责任，企业必须把身份、审计与合规接进来，维护者必须在便利和边界之间不断做不讨好的选择。
当智能体不再是一个用完即弃的聊天窗口，而是长期保存上下文、工具和未完成事项的协作者，开始任何事情的成本都会变小。人会更愿意尝试，也更容易过度投入；会得到时间，也可能把时间重新填满；会第一次感到未来令人期待，也会不得不学习怎样安全地把行动权交出去。
OpenClaw 的爆红并没有替这些问题给出终局答案。它更像把未来提前摆到桌上，让个人、维护者与大型企业都不得不亲手试一遍。一个被烦恼催生的一小时原型，最终让人重新思考的，是计算机与人的关系：不是它还能回答多少问题，而是我们愿意让它陪伴多久、知道多少，又替我们走多远。