Peter Steinberger 与 OpenClaw：一个真实 agent harness 是怎样长成生态的
我观察 Peter Steinberger 和 OpenClaw 已经有一段时间了。
在过去一年里，关于 AI agent 的讨论几乎没有停过。模型一代代发布，benchmark 一轮轮刷新，每个大厂都在说自己要做“个人 agent”。但真正让我觉得“事情正在变得具体”的样本并不多，OpenClaw 是其中一个。
它不是一个新模型，也不是一个看上去更聪明的聊天产品。它真正做的事情更朴素，也更难——把模型接到真实生活里。消息入口、浏览器、邮箱、日历、文件、终端、代码工具、语音、记忆、定时任务、插件、权限、审计、社区、市场。OpenClaw 的官网把自己描述得很直白：这是一个“actually does things”的 AI；你可以让它清理收件箱、发邮件、管理日历、值机；你不一定要打开一个新的 AI App，而是可以从 WhatsApp、Telegram 或者其他聊天应用里直接叫它做事。
这就是所谓 agent harness 的核心：模型只是大脑的一部分，harness 是让大脑进入现实世界的身体、神经、工具箱和安全带。没有 harness，模型最多是在窗口里回答问题；有了 harness，它才开始拥有上下文、工具、记忆、权限边界和行动路径。OpenClaw 的文档把它称为一个自托管的 Gateway——运行在用户自己的机器或服务器上，把不同聊天渠道连接到 AI coding agent 或个人助理；同时强调本地、自托管、多渠道、agent-native、开源。
我之所以愿意花一篇长文来写 Peter 和 OpenClaw，不是因为它现在有多完善——它远远不完善。是因为它把过去一年关于“个人 agent 到底应该长什么样”的所有矛盾，都摆到了同一张桌子上：模型与产品形态的矛盾，开放与安全的矛盾，个人精力与生态责任的矛盾，自托管理想与商业现实的矛盾。
它还在解决这些矛盾的过程中——这就是我觉得现在写它最有意思的时刻。
一、Peter 不是第一次把“工具”做成基础设施
要理解 OpenClaw，不能只从 AI 开始看。
Peter Steinberger 不是一个突然冒出来的“AI 网红开发者”。在 OpenClaw 之前，他更广为人知的身份是 PSPDFKit 的创始人。PSPDFKit 是一家文档基础设施公司——一个 PDF SDK，他和 Martin Schürrer 一起创办，长期经营。后来公司获得 Insight Partners 超过 1 亿欧元的投资。公开资料显示，它服务的客户名单里有 Dropbox、DocuSign、SAP、IBM、Volkswagen 这些名字。
这段经历看上去和 AI 没什么关系，但它其实很关键。
PSPDFKit 不是一个站在聚光灯下的消费产品，而是开发者基础设施。它解决的，是“别人要在自己的产品里处理 PDF”这种底层、烦人、复杂、但高频的问题。Peter 在这件事上做了十几年。换句话说，他很早就清楚一件事——真正有价值的软件，未必是用户每天看到的那个界面，也可以是别人看不见、但每天依赖的那一层。
OpenClaw 继承的，正是这种基础设施气质。
它不试图发明一个新的聊天入口，而是把 AI 接进已有的入口；它不要求用户迁移到一个全新的工作台，而是进入 WhatsApp、Telegram、Slack、Discord、iMessage、Signal、Gmail、GitHub、浏览器、终端这些早就存在的系统。OpenClaw README 和文档反复强调，它支持多渠道、多模型、多插件，并把 Gateway 当作会话、路由、渠道连接的控制平面。
Peter 后来在博客里写过一篇《Finding My Spark Again》。那篇文章不是技术宣言，更像是一个创始人卸下身份之后的私人记录——13 年公司之后，他疲惫到一度失去写代码的感觉。卖出股份，搬家，重新找回创造的冲动。文章最后只写了一句话：“It’s time to build.”
OpenClaw 就是在这种背景下出现的。
它不是一个“我要颠覆世界”的商业计划，更像一个老工程师在重新拿起键盘之后，对“我想要的东西为什么还不存在”的一次直接回应。
二、起点不是宏大愿景，而是“我想要的东西不存在”
Peter 在 Builders Unscripted 的访谈里回忆 OpenClaw 的起点。他没有把它包装成宏大计划。他说自己当时更多是在探索和玩——他想要一些不存在的东西，于是就把它们“prompt into existence”。
最早的触发点，是 WhatsApp 集成。他觉得自己所在的环境里，WhatsApp 就是最自然的沟通方式，而模型实验室一直没有把“随手可用的个人代理”真正做出来。
这个细节很小，但它几乎解释了 OpenClaw 为什么能迅速打中人。
很多 AI 产品默认用户愿意打开一个新 App、登录一个新界面、适应一个新工作流。OpenClaw 的直觉刚好相反——不要让人迁移到 AI 里，而是让 AI 迁移到人的生活里。人已经在 WhatsApp、Telegram、Slack、Discord、iMessage 里沟通，那 agent 就应该在那里出现。人已经有邮箱、日历、浏览器、GitHub、终端、文件系统，那 agent 就应该能在那里行动。
Peter 在 Lex Fridman 的访谈里把这个起点说得更朴素：他想要某个工具，它不存在，他就做了。这一点和 PSPDFKit 的起源很像——都是“我觉得这东西应该存在，而且我可以做得更好”。
这类项目的生命力，往往来自个人刚需而不是市场抽象。
个人刚需有几个特点：第一，它具体；第二，它每天发生；第三，创作者本人就是最苛刻的用户；第四，一旦真的解决，别人会立刻有“我也需要这个”的反应。
OpenClaw 的第一波传播，正是这种“我也需要”的结果。Peter 后来在《Introducing OpenClaw》里写过一段话——项目两个月前还只是一个周末 hack 出来的东西，最早叫 WhatsApp Relay；但它很快超过了 100,000 GitHub stars，并在一周内吸引了 200 万访客。
注意，这里火起来的并不是某个单点功能，而是一种形态——一个常驻的、能从消息入口被唤起的、能使用工具的、能记住上下文的个人 agent。
也就是说，OpenClaw 火的，不是“AI 能回复我”，而是“AI 终于开始出现在我真正生活和工作的地方”。
三、不是模型更聪明，而是模型终于有了手
Peter 对 OpenClaw 有一个很重要的判断——所谓的“魔法”不是凭空创造的。它更像是把许多已经存在的东西重新排列，再加上少数关键的新想法。在 Lex 的访谈里，他用了一个挺有意思的说法——某个东西出现之前像魔法，出现之后又显得理所当然。
最能说明这种“魔法”的，是一个音频转写的小故事。
Peter 在访谈里说，他曾经给 agent 发了一段音频。按理说，他并没有预先写好“识别音频并转写”这种功能。但 agent 自己检查了文件头，识别出音频格式，然后调用 ffmpeg、用 OpenAI key 和 curl，把音频转成了文字。
这个故事的重要性，不在于音频转写本身有多稀奇。真正重要的是——agent 没有被写死在一个“功能列表”里。它拥有工具，能够观察输入，推断路径，调用外部程序，组合步骤，完成一个开发者并没有逐行预设的任务。
这就是 agent harness 和普通聊天机器人的差别。
普通聊天机器人回答“你可以怎么做”。Agent harness 让模型真的去做。
OpenClaw 的工具文档说得很清楚：除了文本以外的一切都通过 tools 完成；tools 是 agent 读取文件、运行命令、浏览网页、发送消息、与设备互动的方式。它的能力层被拆成 tools、skills 和 plugins——tools 是可调用函数；skills 是注入上下文的指导文件；plugins 则把渠道、模型提供商、工具、技能、语音、媒体、网页抓取等能力打包。
也就是说，OpenClaw 把“AI 应用”的问题从“如何写一个 prompt”，推进到了“如何设计一个可运行的行动系统”。
OpenClaw 的架构里，有几个关键部件，值得展开一点。
一是 Gateway。 它是会话、路由、渠道连接的单一控制点。WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Google Chat、Microsoft Teams 等入口，都通过 Gateway 接入，由它和 agent session 连接。
二是 multi-agent routing。 OpenClaw 不是只有一个万能会话，而是可以按 workspace、sender、channel 等维度隔离 session，把不同请求路由到不同 agent 或模型。
三是工具与自动化。 OpenClaw 内置了 exec/process、browser、web search、file I/O、apply_patch、message、cron、image、TTS、sessions/subagents 等工具，并通过 allow/deny list 和 tool profiles 控制工具权限。
四是模型无关性。 OpenClaw 文档里列出了大量 provider——OpenAI、Anthropic、Google、DeepSeek、Ollama、Qwen、Z.AI 等。它没有把自己绑死在某个模型上，而是把自己放在模型和现实任务之间，成为一个可替换模型的操作层。
五是持续性。 OpenClaw 不是一次性问答。它有 heartbeat、cron、hooks、standing orders 等机制，可以周期性检查 inbox、calendar、notifications，也可以执行精确的定时任务和事件驱动动作。
六是记忆。 OpenClaw 的 memory 机制甚至用“dreaming”来形容后台记忆整理——系统会把跨日出现、反复相关、有概念价值的信息沉淀到 durable memory 里。
把这些拼起来，OpenClaw 就不再是“一个聊天机器人”。它更像是个人计算环境上方的一层 agent operating layer——它知道你是谁，能通过你熟悉的渠道被叫醒，能使用工具，能在后台做事，能维护会话，能安装插件，也能被社区扩展。
这就是 agent harness 的真正价值——不是替代模型，而是让模型进入一个可行动、可维护、可治理的环境。
四、Peter 的 AI 编程观：不是“偷懒”，而是新的工程管理
OpenClaw 的另一条主线，是 Peter 对 AI 编程本身的理解。
他不太喜欢“vibe coding”这个词。在 TechCrunch 和 Business Insider 的报道里，他把 vibe coding 说成一种带贬义的说法——它暗示这件事很随意、没技术含量。他更愿意把它看作一种技能，类似学吉他——你不能因为工具变了，就以为不需要练习。
这一点很重要。
Peter 不是在说“以后不用懂软件了”。恰恰相反，他的观点更接近——写代码这件事正在被重新分工，但软件工程并没有消失。
他在《Just Talk To It - no-bs Way of Agentic Engineering》里写道：agentic engineering 已经好到可以写出他几乎 100% 的代码；但他同时强调，很多人把事情过度复杂化了，真正有效的方式往往是直接和 agent 对话。
“Just talk to it”听起来像鸡汤，但它背后是一套很具体的工作法。
Peter 通常会同时跑多个 coding agent——3 到 8 个，有时更多。他把任务拆成较小的改动，让 agent 做 atomic commits；他关心 blast radius，也就是每个 agent 可能影响的范围；如果某个 agent 做得太慢、方向不对，或者改动超出预期，他会中断、询问状态、要求它给选项，必要时直接回滚或重来。
这套方法听上去像“让 AI 写代码”，但实质更像在管理一组非常快、非常有能力、但需要边界和反馈的工程师。Peter 自己也把 agentic engineering 和管理工程师并列——你需要说明目标、控制范围、提供上下文、检查关键结果、管理风险，而不是每一行都亲自写。
他还有一个很鲜明的观点——很多 MCP 是过度设计，很多 MCP 本来应该是 CLI。
理由也不复杂：CLI 更简单、更少上下文税，更容易被 agent 调用、验证和闭环。Peter 不是完全不用 MCP——他承认 Chrome DevTools MCP 有时有用——但他的基本倾向是，能做成 CLI 的，就别急着包装成复杂协议。
这一点和 OpenClaw 的产品哲学完全一致——不要迷信接口形式，重点是 agent 能不能可靠地观察、行动、验证。
Peter 在《Shipping at Inference-Speed》里甚至写过：现在很多软件已经可以以“inference-speed”被构建出来；真正限制速度的，常常不是手写代码，而是推理时间、架构判断、依赖选择、系统设计和人类的思考。
所以 Peter 的 AI 编程观，不是“程序员消失”，而是**“程序员的重心上移”**。
过去，程序员的许多时间花在逐行实现、搜索样例、修 bug、写 glue code。现在，这些工作越来越多地交给 agent。人类工程师的核心价值，转向了几件事——判断什么值得做，设计系统边界，选择依赖和架构，定义测试与验收，控制安全风险，管理多个 agent 的协作，维护代码库的长期可读性。
Business Insider 那篇报道里，Peter 还说过一句颇有争议的话——大意是“Most code is boring”。这并不是轻视工程，而是说大量代码确实是模式化、重复性的；真正不能外包的，是对系统的理解和取舍。
这也是为什么 OpenClaw 值得研究——它既是 Peter 用 agentic engineering 做出来的项目，又是一个让更多人去实践 agentic engineering 的平台。
五、为什么是 harness，而不是模型？
OpenClaw 爆火之后，很多人会自然问出一个问题——既然模型越来越强，为什么还需要 OpenClaw 这种 harness？模型公司自己不能做吗？
答案是：模型会越来越强，但“让模型进入真实生活”的问题不会自动消失。
一个个人 agent 至少要解决这些问题——它从哪里被唤起？它如何识别用户身份？它能访问哪些工具？它能代表用户执行什么动作？它怎样获得上下文？它的记忆存在哪里？它犯错时如何回滚？它如何处理多个聊天渠道？它如何区分私人、家庭、团队、公司边界？它如何安装新技能？它怎样通过权限、审计、沙箱和批准机制避免灾难？
这些问题没有一个是单个模型 API 能解决的。它们属于 harness、runtime、gateway、policy、ecosystem 的范畴。
OpenClaw 的模型无关策略，正是因为 Peter 看到了这一点。
OpenClaw 可以接不同的模型提供商，也可以通过插件把 Codex 等外部 agent harness 接进来。即便使用 Codex 插件，OpenClaw 仍然负责聊天渠道、session files、模型选择、工具、审批、媒体交付和可见 transcript mirror。
也就是说，OpenClaw 的位置不是“又一个模型前端”。它更像是模型之上的个人代理控制层。
这种位置也解释了 OpenClaw 和模型公司的复杂关系。
一方面，它依赖模型公司提供推理能力；另一方面，它又可能改变用户使用模型的方式，甚至改变模型公司的成本结构和产品边界。
2026 年 3 月，The Verge 报道 Anthropic 调整了 Claude 订阅使用规则——第三方 harness（如 OpenClaw）不再被普通 Claude 订阅覆盖，用户需要使用 pay-as-you-go 或 API key。报道里提到，OpenClaw 的流行使用户通过它处理收件箱、日历、航班值机这些任务，带来了不同于传统聊天订阅的使用模式。
Business Insider 也报道了类似的背景——Anthropic 方面称，订阅并不是为第三方工具的使用模式设计的，需要用户购买额外额度或使用 API key；Peter 则认为，许多用户正是因为 OpenClaw 才购买 Claude 订阅，切断这种支持会造成损失。
这件事很有代表性。
它说明 agent harness 一旦成功，就不再只是“开源小工具”。它会影响模型消费方式、订阅经济学、API 商业模式、用户控制权和模型公司的平台战略。
更进一步说，真正的个人 agent 不是“谁回答得更好”那么简单，而是谁能成为用户数字生活的操作层。模型公司当然也想做这一层，但开源 harness 的机会在于——它可以更贴近用户的真实环境，更强调自托管和数据控制，也更容易由社区长出各种长尾技能。
All Things Open 的一篇分析把 OpenClaw 的模式概括为 local-first、messaging-native、model-agnostic、community-extensible，并认为 agent harness layer 会带来长期的开源机会。
这个判断很准确。OpenClaw 的生态价值，正是来自它站在模型、用户、工具、数据和社区之间。
六、四个飞轮：从个人项目到生态
OpenClaw 的成长，不是单纯的 GitHub star 增长。它真正长成生态，是因为同时启动了四个飞轮——使用、贡献、插件、治理。
第一个飞轮：使用——从“我想要”到“大家都想要”
OpenClaw 的第一批用户，不是因为它有完整的企业销售流程，而是因为它让人产生一种久违的感觉——AI 终于不只是回答，而是开始进入日常。
官网收录的反馈，能说明这一点。有人说它有 persistent memory、persona、heartbeats；有人说上下文和 skills 存在自己的电脑上，而不是封闭花园；有人把它想象成公司、家庭、团队的 assistant；也有人强调它能做 proactive cron、background tasks、浏览器控制，甚至从 Telegram 管理代码 agent。
这类反馈之所以强烈，是因为 OpenClaw 把 agent 从“工具”变成了“在场”。它不只是你打开它时存在，而是可以常驻、可以被消息唤起、可以记住你、可以主动提醒、可以在后台执行。
Lex 访谈里，Peter 谈到 heartbeat 时用了一个非常简单的想法——让 agent 每半小时“surprise me”。后来这种机制变成了更正式的 heartbeat / cron 结构。它让 agent 有了一种节奏感——不是等你提问，而是周期性地检查、整理、提醒和关心。
这就是个人 agent 的第一层吸引力——它不只是智能，而是持续存在。
第二个飞轮：贡献——开源让用户把自己的问题带进来
OpenClaw 的第二个飞轮，是开源。
Peter 在 Lex 访谈里说，项目收到了很多来自非传统开发者的 PR。他甚至把一些 PR 叫作“prompt requests”——很多人以前没有真正写过软件，但因为 OpenClaw，他们开始尝试开源贡献。Peter 觉得，一个人第一次提 PR，本身就是社会层面的胜利。
这件事非常值得注意。
AI 编程把开源贡献的门槛降低了。过去，一个用户遇到 bug 或想要功能，可能只能提 issue、等维护者修。现在，他可以让 AI 帮自己读代码、写补丁、提交 PR。即便 PR 不完美，也会把用户问题变成可讨论、可合并、可迭代的具体材料。
OpenClaw 作为一个 harness，尤其适合这种贡献模式。每个用户都有不同渠道、不同设备、不同语言、不同家庭/公司环境、不同自动化需求。这些需求不可能由 Peter 一个人穷尽。开源把这些长尾需求变成了生态燃料。
GitHub 页面上，OpenClaw 已经达到了数十万 star、数万 fork，并且持续发布新版本。这个数字会变化，但它至少说明——OpenClaw 已经不是“小众个人脚本”，而成为了一个大规模开源项目。
第三个飞轮：插件——从项目到平台
生态和项目最大的区别，是别人能不能在它上面构建东西。
OpenClaw 的 skills/plugins 设计，就是从项目走向平台的关键。Skills 可以把具体能力、约束和步骤注入 agent 上下文；plugins 则可以打包渠道、provider、tools、skills、speech、media、web fetch / search 等能力。
这意味着 OpenClaw 不是只靠核心团队添加功能。它可以通过插件承接社区能力——有人做聊天渠道，有人做模型 provider，有人做工具，有人做自动化，有人做家庭设备控制，有人做公司内部流程，有人做 coding harness 接入。
从生态角度看，插件不是“锦上添花”，而是平台化的起点。一个 agent harness 不可能预先知道所有用户要做什么。它只能提供稳定的接口、权限边界和分发机制，让能力在外部生长。
OpenClaw 的 ClawHub 和 skill marketplace 正是在这个方向上演进的。Peter 后来与 VirusTotal 合作，对 ClawHub skills 做安全扫描——确定性打包、SHA-256、VirusTotal 查询或上传、Code Insight 分析、自动批准 / 标记 / 阻断、每日重扫等流程都被纳入。
这也直接说明 OpenClaw 的插件飞轮很快遇到了另一个问题——能力越多，攻击面越大；生态越活跃，治理越重要。
第四个飞轮：治理——安全问题把个人项目推向组织化
OpenClaw 的第四个飞轮，是治理。
项目越火，越不可能继续以“个人玩具”的方式运行。尤其是 OpenClaw 这种 agent harness——它会运行工具、持有凭证、安装插件、访问消息、浏览网页、执行命令。
Peter 在 2026 年 4 月的安全博客里写得非常直接——任何会运行工具、持有凭证、安装插件的东西，都不是默认安全的。
这句话基本可以视作 OpenClaw 从个人项目进入生态阶段的分水岭。
一开始，社区对 OpenClaw 的安全质疑非常多。Peter 后来公开复盘说，截至 2026 年 4 月 30 日，GitHub 页面显示 OpenClaw 自 1 月 10 日以来收到了 1,309 个 security advisories，其中 535 个已发布，746 个被关闭为 invalid——许多被标成 critical 的报告其实并不成立。
但这并不意味着 OpenClaw 没有真实安全问题。Peter 自己承认他们修复了 auth bugs、privilege confusion、reconnect scope widening、sandbox bypasses、unsafe env、approval mistakes 等真实问题；同时收紧了 allowlists、定义了 SECURITY.md 的 trust model、缩小 core、把更多功能推到 plugins、增加 E2E tests、observability、把 secrets 移到 references。
这是一条典型的“开源项目成人礼”路线——先因为有用而爆火，再因为危险而被审视，最后被迫补上安全、流程、治理、文档、团队和伙伴关系。
Peter 在那篇安全博客最后写了一句很关键的话——open 和 safe 并不是对立面；open 反而是走向安全的方式。
这句话可以视作 OpenClaw 生态的治理哲学。它承认开放会暴露问题，但也相信开放会更快地修复问题。对于 agent harness 来说，这个逻辑尤其重要——因为闭源并不会让 prompt injection、权限滥用、插件投毒、凭证泄露自动消失，它只是让问题更难被外部看到。
七、安全不是插曲，而是 agent 时代的主线
很多人讨论 OpenClaw，会先谈它多酷、多像未来。但真正决定它能否成为生态的，恰恰是安全。
Peter 在 Lex 访谈里承认，prompt injection 仍然是未解决的问题。他也提醒，如果用户不了解风险，就不应该贸然把这类 agent 接到关键系统。他甚至特意提到——不要轻易使用弱模型或便宜模型来处理高风险任务，因为更弱的模型可能更容易被操纵。
这不是保守，而是现实。
一个聊天机器人被 prompt injection，最多说错话。一个 agent harness 被 prompt injection，可能会读文件、发邮件、改代码、调用终端、转发隐私、安装恶意插件，甚至在公司环境里引发供应链风险。能力越强，风险越大。
OpenClaw 和 VirusTotal 的合作，正是对这个问题的回应。Peter 在合作博客里解释——AI agent 和传统软件的安全边界不同：agent 会解释自然语言并决定行动，因此可以被语言操纵；skills 又是 agent 上下文里的代码，可能访问工具和数据。恶意 skill 可能外传数据、执行命令、发送消息或下载 payload。
VirusTotal 扫描当然不是银弹。Peter 自己也说——它不能解决 prompt injection，也不能保证所有恶意行为都被发现。但它提供了 malware detection、behavioral analysis、supply-chain visibility 和 signal，是 defense in depth 的一部分。
OpenClaw 的安全路线里，有一个特别重要的原则——one trusted person per agent。Peter 在安全复盘里说，OpenClaw 最初是为“一个可信的人对应一个 agent”设计的；如果用于家庭、团队或公司，就必须按 trust boundary 拆分 agents 和 credentials，并打开 sandboxing。
这句话看着很简单，但它其实是个人 agent 产品化的核心难题。
人类生活里有太多边界——我个人、我家庭、我的同事、我的客户、我的公司、我的私人邮箱、我的工作邮箱、我的银行、我的代码仓库、我的云服务器。一个真正有用的 agent 迟早会跨越这些边界。但每跨一次，权限模型、身份模型、审计模型和责任模型都会复杂一倍。
所以，OpenClaw 的安全问题不是项目的“黑点”，而是它触及真实世界的证明。
只有真的能做事的软件，才会面对这些问题。一个只能在沙盒里聊天的 AI，不需要这么复杂的安全模型；一个能代表用户行动的 AI，必须把安全当成产品核心。
这也是为什么 OpenClaw 从个人项目走向生态时，必然要走向组织化。Peter 在安全复盘中提到——OpenClaw 已经不只是他一个人，有 maintainers，有 CodeQL、Semgrep、Codex Security，也有 NVIDIA、Microsoft / GitHub、Atlassian、Tencent、OpenAI 等外部支持；OpenAI 支持 inference、Codex Security，并承诺保持项目开放和独立。
一个生态不是“很多人用”就够了。真正的生态，必须有安全、治理、信任、责任和持续维护。
八、加入 OpenAI：不是终点，而是 OpenClaw 进入下一层复杂度
2026 年 2 月，Peter 宣布加入 OpenAI。
他在博客里说——他不是不相信 OpenClaw 能成为一家大公司，相反，他能看到那条路。但那不是他现在最兴奋的事情。他说自己已经玩过 13 年“公司游戏”，现在更想改变世界，而不是再建立一家大公司。
这段表态很有 Peter 的气质。
他不是没有商业经验的人。恰恰相反，他做过长期的公司经营。所以当他说“不想再把 OpenClaw 变成一家大公司”时，这不是逃避商业，而是一次主动的选择。
Reuters 后来报道——Peter 将加入 OpenAI，Sam Altman 表示他会推动下一代个人 agents；OpenClaw 将放入一个基金会，继续作为开源项目存在，并得到 OpenAI 支持。
这件事有两层含义。
第一，OpenAI 认可了 OpenClaw 所代表的方向——个人 agent 不只是模型能力问题，而是产品形态、生态和 harness 问题。Peter 加入 OpenAI，不是因为他做了一个普通 bot，而是因为他做出了一个能让人看到“个人 agent 应该如何存在”的样本。
第二，OpenClaw 进入了更复杂的信任结构。它一方面强调开源、独立、基金会；另一方面又拿到了 OpenAI 的资源、模型和安全支持。这种结构有机会让 OpenClaw 更快解决模型能力、安全审计和基础设施问题，但也会带来新的问题——开源社区是否仍然信任它？模型无关性是否能保持？基金会治理是否透明？其他模型提供商和插件开发者是否会继续投入？
Peter 自己显然意识到了这一点。他在加入 OpenAI 的博客里反复强调——OpenClaw 会继续开源，项目会留给 thinkers、hackers，以及那些希望拥有自己数据的人；它也会支持更多模型和更多公司。
这句话是 OpenClaw 未来最重要的承诺之一。因为 OpenClaw 的生态价值，正建立在用户对控制权的期待上——自托管、模型可替换、数据在自己手里、插件可审查、社区可参与。
如果这些东西消失，OpenClaw 就会退化成某个模型公司的入口。如果这些东西保住，它才有可能成为真正的开放 agent harness 生态。
九、产品启示：个人 agent 的入口不是 App，而是生活本身
OpenClaw 最值得产品人学习的一点，是它没有把“AI 产品”理解成一个新 App。
它选择了最普通、最日常、最不性感的入口——聊天软件。WhatsApp、Telegram、Slack、Discord、Signal、iMessage、Google Chat、Microsoft Teams。OpenClaw 不是要求用户进入 AI，而是让 AI 出现在用户已经存在的沟通网络里。
这看似只是渠道选择，实际上是产品哲学。
过去十几年，许多软件都在争夺“用户打开我的 App”的机会。但个人 agent 的理想形态，可能不是一个固定界面，而是一种 ambient layer——它在你需要时出现，在你不需要时退后；它从消息里接收任务，从后台完成动作，在关键节点请求确认，把结果送回你熟悉的地方。
Hanselminutes 的 OpenClaw 访谈介绍里，就把它放在“AI 工具从云端、自动补全、浏览器标签页，走向本地环境、上下文和 thinking companion”的转变里讨论。Scott Hanselman 和 Peter 在节目里也谈到了控制权——谁拥有上下文，数据住在哪里，AI 是否会成为本地环境上的 ambient layer。
这解释了为什么 OpenClaw 的“自托管”如此重要。OpenClaw 官网强调它运行在用户自己的机器上，支持 Mac、Windows、Linux，可以连接 Anthropic、OpenAI 或本地模型，并且默认私有。
在个人 agent 时代，数据控制不再是抽象理念，而是产品功能。因为 agent 一旦有用，就会接触最敏感的个人上下文——邮件、日历、聊天、文件、代码、浏览器、家庭设备、公司系统。用户愿不愿意把这些东西交出去，决定了 agent 能做多少事。
OpenClaw 的路线是——尽量让 agent 运行在用户控制的环境里，用用户熟悉的渠道交互，用插件扩展能力，用权限和审批约束行为。这不是唯一正确的路线，但它代表了一个强烈方向——个人 agent 不应该只是云端模型的皮肤，而应该是用户拥有的计算层。
十、写给 builders 的几句具体话
写到这里，我想把这一年观察到的东西，浓缩成几条具体的话——它们对做 AI 产品、开源项目和 agent 系统的人，应该都有用。
第一，从自己的真实痛点开始。 Peter 不是先做市场分析，而是先解决“我想要一个能从 WhatsApp 触达的个人 agent”这个具体问题。真实痛点会让产品天然有细节。
第二，不要急着发明新入口。 OpenClaw 证明，最好的 AI 入口可能不是新 App，而是用户已经每天使用的消息、终端、浏览器和文件系统。
第三，模型不是产品，harness 才是产品化关键。 个人 agent 的难点，不只是回答质量，而是工具、上下文、记忆、权限、渠道、路由、自动化和安全。
第四，把工具做成可验证闭环。 CLI、测试、日志、session、approval、apply_patch、browser automation——这些东西让 agent 能从“建议者”变成“执行者”。
第五，尽早设计权限和 trust boundary。 OpenClaw 的安全经历说明，agent 一旦接触真实系统，权限模型就是产品核心，而不是后期补丁。
第六，插件生态需要安全基础设施。 ClawHub 和 VirusTotal 的合作说明，skill marketplace 不能只追求扩展能力，还必须有扫描、审核、重扫、标记、阻断和透明度。
第七，开源会放大问题，也会加速修复。 Peter 的判断是，open 和 safe 不是对立面。对 agent harness 来说，这个判断尤其重要——因为封闭无法消灭风险，只会让风险更不透明。
第八，AI 编程不是“随便 vibe”，而是新的工程管理能力。 Peter 的工作法提醒我们，未来优秀工程师可能不再以“亲手写了多少行代码”定义自己，而是以“能否让多个 agent 在清晰边界内高质量完成工作”定义自己。
第九，保持玩心。 OpenClaw 的 lobster、persona、soul、heartbeat，都不是标准企业模板，却让项目有了强烈的辨识度。个人 agent 进入人的生活，光有功能不够，它还需要某种可相处性。
第十，不要把“粗糙”误认为“不重要”。 许多真正改变行业的东西，一开始都很粗糙。重要的是它是否触及了真实需求，是否启动了反馈循环，是否能在压力下演化。
结语：OpenClaw 不是答案，而是信号
如果说 2022 年的 ChatGPT moment 让大众第一次感到“AI 会说话”，那么 OpenClaw 代表的信号是——AI 开始拥有行动环境。
这个行动环境不是单个模型能完成的。它需要 Gateway，把 agent 接到人的消息渠道；需要 tools，让模型能操作真实世界；需要 skills / plugins，让能力可扩展；需要 memory / heartbeat，让 agent 持续存在；需要 providers，让模型可替换；需要 approval / sandbox / security，让行动可控；需要社区，让长尾需求进入系统；需要基金会和治理，让项目不被个人精力吞噬。
Peter Steinberger 的特别之处，在于他不是从理论推导出这一切，而是把它做了出来。先是一个周末项目，然后是 WhatsApp Relay，然后是 OpenClaw，然后是 GitHub 上的爆发，然后是安全风暴、插件生态、模型公司冲突、OpenAI 招募和基金会承诺。
OpenClaw 当然还不完美。Peter 自己也承认，要让它变成“连妈妈都能用”的 agent，还需要更强模型、更好安全、更稳产品和更清晰治理。
但这正是它值得研究的原因。
完美的概念产品不会暴露现实矛盾，真实的 agent harness 会。
OpenClaw 让我们看到，个人 agent 的未来不只是“更聪明的模型”，而是一整套新的个人计算生态——本地控制、消息入口、工具调用、持续记忆、权限边界、插件市场、安全审计、社区协作和模型供应。
Peter 不是在做一个聊天机器人。他在做一条把模型接入现实生活的线路。
而当这条线路被越来越多人使用、修复、攻击、扩展和治理时，一个个人项目就不再只是个人项目。
它开始变成生态。