“小龙虾”热度散去,才轮到 OpenClaw 拼产品力:重新认识它的创始人

“小龙虾”OpenClaw 最热的时候，人们爱讲它的神奇：一句话交代任务，agent 自己找路、操作电脑、把事情往前推。热度退一点，问题也随之变得具体：它到底能做什么？能否稳定地做？把权限交出去，代价又由谁承担？

这时再回头看 Peter Steinberger，反而更容易看清。他不是靠一个概念突然闯进 AI 叙事的天才黑客，而是一个做了很久软件、离开过软件、又被新工具重新拉回电脑前的工程师。OpenClaw 是他的作品，却不是理解他的全部入口。

Peter 在奥地利乡下长大，14 岁开始自学编程。此后，他花了 13 年做 PSPDFKit。那不是一段为了给履历增色的前史：长期做产品的人，知道一个念头变成可用软件，中间要经历多少重复、兼容、维护与取舍。

出售股份后，他经历了职业倦怠，约三年很少写代码。不是不再喜欢创造，而是熟悉的开发路径已经很难带来兴奋。一个新想法，意味着又要从头补技术栈、处理边角、背上漫长维护；这对做过一轮成熟产品的人，未必是解放。

Agent 给他的，不只是更快写代码。他已经许久不碰 Web 技术栈，却可以把较高层的想法交给模型，得到可运行的 JavaScript，再继续改。那些原本因学习成本和琐碎工程而被搁置的点子，重新有了试一试的理由。

这也解释了他常说的那种“什么都能做”的感受。它不该被理解为全能宣言，而更像倦怠之后恢复的行动感：不是先断言结果一定成功，而是重新相信，问题值得动手。

在 Peter 的讲述里，OpenClaw 的火花并不浪漫。电脑不够快、不够顺，很多流程还得人反复点击、复制、切换；更让他烦的是，人不能直接把意图交给电脑，再让它把事情办下去。既然不顺手，就修掉它。

一个 WhatsApp 机器人的经历让他意识到 agent 与普通问答的差别：他发去语音后，机器人找到了他并未专门交给它的 OpenAI key，完成了转写和回复。对他而言，关键不在转写本身，而在于工具没有停在“我没有拿到材料，所以做不了”的位置，而是继续寻找完成任务的路径。

但同一件事也提示了边界。会自己找路径，既是能力，也意味着权限：它为什么能拿到这把 key？用户允许它走到哪一步？Peter 的特点，是愿意把实验接进真实的文件、邮件和电脑；这使他更早碰到新用法，也要求他更早面对风险，而不能只保留“它居然做到了”的惊喜。

因此，他想做的从来不只是邮件摘要器。手机上的一句话，可以是任务的起点；之后的检索、安装、操作与反馈，应该在同一个工作过程里连续发生。OpenClaw 的原始冲动，正是减少人作为软件流程中间搬运工的次数。

Peter 对 OpenClaw 的爆火并不全然兴奋。他承认，外界对它的期待一度跑在产品前面：人们听到故事，以为拿到的是完美魔法；真正上手才发现，模型仍会失误，软件仍有缺口，复杂任务仍然困难。概念正常化，不是宣布 agent 没价值，而是把判断从演示的惊叹带回连续使用的账本。

OpenClaw 2.0 的变化颇能说明这一点。团队开始用它承接十小时以上的连续工作，旧的界面和后端不够用，于是重做 Control UI，并将为短会话设计的 JSONL 后端换为 SQLite。多人共用同一台网关、同一段仍在继续的会话，听上去没有“自动完成一切”那么吸睛，却决定了工作能否接着做。

这类改动说明，agent 产品的难处常常不在第一次完成任务，而在第二天能否找到同一段上下文，第三个人能否理解已经发生了什么，以及长时间运行后系统是否仍然可用。用户感受到的是一次顺滑的交接，背后却是存储、界面、会话管理和测试方式的重做。

他自己的开发方式也常被一个数字概括：Peter 自述一天会合进约 600 个提交，并不逐条阅读 diff。这个数字只是个人自述，更不是质量指标。材料里更值得看的，是他试图建立的流程：让没有写码记忆的审查 agent 与写代码的 agent 争论，最多十轮；再把结果放进一次性环境，安装、打开界面、点击并跑端到端测试；每合进五到十个，他还会亲自使用一次，再调整提示词。

这不等于这套做法已经被证明是最佳实践，更不意味着人工判断可以退出。它提供的是一个正在成形的分工：不再把全部注意力押在逐行阅读上，而把注意力放到“有没有理解问题”“能否在陌生环境复现”“用户实际怎么用”上。所谓别只给代码、也要给提示词，本质上是在追问贡献者有没有真正说明问题。

Peter 把一种常见状态称为 meat proxy：同事问你问题，你把问题贴给自己的 agent，再把回答复制回去。人站在两端之间，只负责搬运上下文。这个说法有点刺耳，却准确指出了当下协作的断裂：工作发生在 agent 的会话里，团队仍只能看见转述后的结论。

因此，2.0 的多人设计不是单纯把聊天框变热闹。多人进入同一台网关，可以看见同一批会话，在原有上下文里继续提问或接手任务。交出去的不是一份摘要，而是已经读过材料、执行过步骤、仍可继续推进的现场。

团队最初并不完全自在。人们习惯把与 agent 的对话当成私密的个人工作流；放到一起后，才发现彼此的提问方式、拆解路径和使用习惯差异极大，也能由此学习。这给“会用 AI”补上了一个常被忽略的维度：它不仅是个人技巧，也可以成为可观察、可讨论的协作过程。

不过，共享不等于取消边界。共享会话和记忆默认属于同一只共用 agent，同一台网关就是一条明确的信任边界。个人生活与团队项目若要彻底隔离，应使用不同网关；连接着私人邮件的环境，也不应随意邀请不被信任的人进入。

Peter 在伯克利谈到一个朴素的问题：会议平台、操作系统和 API，大多是为人设计的。agent 想进入，只能像人一样开浏览器、使用账号、接入系统音频。对他来说，这不是只值得抱怨的障碍，而是下一步要建设的接口。

他不满足于每个产品侧边栏里各放一只助手。Gmail 里的助手未必知道用户其他工作发生了什么，也未必由用户真正控制。他更在意一只可以在后台存在、需要时被调动、又知道何时不打扰人的 agent：人仍然可以自己打开文档打字，它也应当在需要查证或执行时成为工具，而非新的注意力中心。

这个判断也延伸到平台关系。Peter 不愿为了使用一家服务，就被迫使用那家服务安排的 agent；服务应该把自己的系统做好，让用户的 agent 能来使用。这里争的不是一个侧边栏，而是谁拥有代理关系：助手是在替用户完成目标，还是在替平台塑造用户行为？

材料显示，OpenClaw 由独立基金会持有和管理，不属于 OpenAI；它强调可修改、可选择模型，也可以运行在自己的硬件上。这些选择让个人 agent 更接近一套可掌握的基础设施，而不只是又一个订阅入口。

尤其需要分清，Peter 对安全的判断来自深度使用者的风险权衡，并非独立安全认证。本机运行、开源代码或更灵活的权限，不能自动消除提示注入、数据暴露和误操作的风险。不同用户、企业和高风险场景需要的防护也不会相同。坚持用户控制权，不能替代权限设计和安全验证。

换句话说，用户拥有更多控制权，并不是把安全问题从平台一侧简单搬到个人一侧就结束了。哪些文件可读、哪些操作须确认、哪些任务应被限制在隔离环境中，仍需要产品作出清晰默认设置。真正站在用户这边的工具，也应帮助用户看见这些代价，而不是用“自主”掩盖它们。

Peter 并不把现在的聊天入口当作终局。在他看来，文本框帮助很多人开始使用 AI，却仍像一种对旧交互方式的迁就。他更倾向于面对一只主 agent：用户交代目标，它可以在背后组织其他 agent；复杂性不必全部涌到用户面前。至于个人 agent 与团队 agent 如何协作，行业还没有成熟答案。

这种不愿把当前形态神圣化的倾向，也让他转向 Linux。过去，操作系统的限制足以让一个想法止步；当 agent 可以深入系统、读文本、修改配置，甚至参与编译内核时，限制仍在，却变成了能被追问、测试和修正的问题。

这里的重点不是 Linux 天然更完美，而是系统是否保留了可触及、可解释、可修复的空间。对 Peter 来说，工具的吸引力正在于：遇到障碍时，用户不必总在封闭界面前等待某家公司更新，也能够带着 agent 沿着问题往下查。

他做小型 ESP 设备时，屏幕出错，便把摄像头粘在屏幕上，让 Codex 看着实际显示结果，跑了一夜修好显示驱动。后来处理音频，它又绕了很久，才发现是另一台设备的音量被关掉。这个故事没有神迹：它既有闭环带来的效率，也有模型和环境共同制造的笨拙。

这也是 Peter 身上最稳定的一点。他不是在宣布所有问题已被解决，而是不断把“这很烦”“这里不通”“这不该只能忍受”变成下一次可实验的起点。OpenClaw 是否能把这种做法扩展为大多数人可靠可用的产品，仍要由工程、安全和真实使用来回答。

写在最后

当“小龙虾”不再神奇，Peter Steinberger 的轮廓反而更清楚：一个有长期产品经验、也经历过倦怠的工程师，对限制仍然不耐烦，对新能力愿意动手验证，同时把用户控制权看得很重。

这不要求我们照单全收他的风险偏好，也不该用一次爆火来替他盖棺定论。更值得留下的，是一种重新安排人与电脑关系的提问：如果机器已经能观察、执行、反馈，为什么人还要反复点击、复制、粘贴和传话？

答案不会只由一款产品给出。但对一个离开代码多年的人来说，AI 最重要的意义或许正在于此：它没有让世界突然没有难题，却让许多曾经只能忍受的难题，再次成为可以动手解决的事。

来源

1. 2026 年 8 月 1 日，《伯克利 Agentic AI Summit：No Doors for Agents》：原视频。

2. 2026 年 9 月 2 日，《ClawCast 第 9 集：OpenClaw 2.0 的多人协作、看板和计算节点》：节目页。

3. 2026 年 9 月 25 日，《AI Worth Using EP.03：别把代码发来，把提示词发来》：原文字稿。

4. 2026 年 9 月 29 日，《TBPN：OpenAI DevDay 当天的 Peter Steinberger》：原视频。

文中彩色重点句为本文观点提炼，非逐字引语。

END