夜雨聆风六个月前，它还像未来；几个月后，它已经开始被新产品、新叙事和新界面追赶。
OpenClaw 创始人 Peter Steinberger 在一场约 42 分钟的演讲与问答中，用五个问题复盘了项目诞生后的八个月：它为何看起来远不止八个月、他是否已经“卖身”、竞争者是否在关键处赢了、开发过程是否还保有乐趣，以及下一步究竟是什么。
表面上，这是一个开源项目的成长故事。更深一层，它记录了个人 Agent 从“能跑起来”走向“能长期运行”时，几乎必然遭遇的工程转折：入口、模型和提示词不再是唯一主角，安全、可靠性、依赖、成本与治理开始决定项目上限。
截至 2026 年 8 月 12 日，GitHub API 显示 OpenClaw 官方仓库约有 38.6 万 Star、8.1 万 Fork。项目已经由注册为 501(c)(3) 的非营利组织 OpenClaw Foundation 推进，官方定位也从一个聊天中继，扩展为运行在个人设备、接入日常沟通渠道的 AI 助手。数字仍在变化，但项目阶段已经很清楚：它已越过单次产品实验，目标指向个人 Agent 的公共底座。
下文会区分两个时间口径：“演讲中”指 Steinberger 对这八个月的现场复盘；“截至当前”指 2026 年 8 月 12 日仍可从项目官方仓库、文档与基金会页面核验的状态。
OpenClaw 的起点：消除一次具体摩擦
OpenClaw 的起点并不宏大。
Steinberger 当时同时运行着多个编码 Agent，却缺少一种自然的方式，从手机向 Mac 发送指令并查看执行进度。终端里的 Agent 已经能工作，但人一旦离开电脑，协作就中断了。于是，一个想法被直接输入新的终端会话：搭建 WhatsApp 与 Mac 之间的消息中继。
大约一小时后，消息已经可以双向传递。
中继本身并不复杂。“未来感”来自交互方式的变化：回复更简洁，系统可以主动联系用户，也不再要求用户时刻思考模型选择、上下文窗口和何时开启新会话。复杂性被藏到了熟悉的聊天界面之后。
OpenClaw 最早的产品价值由此变得清晰：缩短“产生意图”到“Agent 开始行动”之间的距离。
当产品被放进朋友群聊后，非技术用户给出了比功能列表更强的信号：惊讶、担忧，甚至因为暂时无法获得使用资格而生气。演讲将这种强烈情绪视为产品需求的证据。对于 Agent 产品，这种判断很重要——用户是否愿意让系统进入真实工作流，通常比一次演示是否顺利更能说明问题。
Peter 加入 OpenAI 之后，OpenClaw 仍保持独立
视频的第二个问题是：“Did you sell out?”
这句调侃直接触及 OpenClaw 的所有权与治理。Steinberger 回顾，自己此前用十多年创办并发展一家 B2B 软件公司，退出后又经历了长期倦怠。他后来才意识到，持续驱动自己的始终是创造产品，编程只是实现手段。当多家大型 AI 实验室找上门时，他最终依据自己的判断选择加入 OpenAI。
演讲还给出一条偏向个人职业发展的经验：产品可以被复制或 Fork，个人名字与长期信誉却无法被同样复制。因此，个人品牌的积累应早于真正需要它的时刻。
这里需要澄清：Steinberger 加入了 OpenAI，OpenClaw 项目并未随之被 OpenAI 收购。截至当前，OpenClaw Foundation 官方页面称，Steinberger 在 2026 年早些时候加入 OpenAI 后，仍在维护 OpenClaw；OpenAI 为项目提供推理支持，并承诺其保持开放和独立。基金会列出的机构支持方还包括 Offline Holdings、密歇根大学、Microsoft 与 NVIDIA。
这至少确认了当前公开治理口径：OpenClaw 由独立的非营利基金会承接，并以开放项目的方式运行。至于具体雇佣与合作合同，公开页面并未披露，不宜进一步推断。
从原型到产品，责任增长快过代码
项目加入 Discord 支持，并经历 Warelay、Clawdbot、Moltbot 到 OpenClaw 的名称演变后，外部参与迅速增加。演讲披露的阶段性数字是：八个月内，超过 1.8 万名不同用户提交过 Issue 或 PR，相关提交总量超过 11.1 万，近 3000 人在仓库中留下过 Commit。这些是演讲现场提供的历史口径，不应与今天的 GitHub 页面数字混用，但足以说明维护规模变化之快。
一次公开测试中，Steinberger 原本计划结束进程后休息，却因为守护进程自动重启，让 Agent 在无人看守的状态下继续面对约 800 条消息与多次攻击尝试。
这次意外没有造成严重后果，却暴露了一个根本变化：当 Agent 只有一个可信用户时，提示词和人工观察似乎足以形成保护；当陌生人、外部输入和真实工具同时进入系统，安全就不能再依赖模型“听话”。
演讲提到，项目随后加入了沙盒、允许列表、内置权限等多层防护。OpenClaw 当前的官方安全政策则进一步明确了信任模型：它是面向可信操作者的 local-first Agent 基础设施，并不把同一 Gateway 上互相对抗的多个用户视为默认安全边界；若需要真正隔离，应使用独立 Agent、Gateway 或主机边界。
安全讨论由此落到具体边界上。判断一个 Agent 系统是否安全，首先需要回答三个问题：
谁被允许向 Agent 发出指令？ Agent 被允许调用哪些工具、访问哪些数据？ 一旦输入、插件或模型出错，哪一层能阻止影响继续扩大？
免责声明无法替代可执行的边界，提示词也无法承担权限系统的职责。只要 Agent 能操作文件、浏览器、账户和终端，身份验证、审批、沙盒、最小权限与审计就必须进入产品能力，不能停留在文档附注中。
用户越多，软件越难：功能之后才开始计费
演讲中有一句非常适合开源维护者的判断：在 AI 编程时代，新功能可能只差一次提示，真正的成本却发生在发布之后。
演讲称，项目在高峰时一度累积了约 9500 个配置选项。每个开关都可能与历史行为、操作系统、消息渠道、模型供应商和其他开关形成新的组合。配置数量看起来只是在做加法，测试空间却在做乘法。最终，即使写出大量测试，也难以覆盖全部排列。
这就是演讲所说的“拥有用户的软件更难开发”。用户带来需求，也会把项目此前没有见过的边界条件集中暴露出来：有人把 Agent 当杂货助手，有人用它开发软件，也有人专门寻找社会工程和工具调用的突破口。
项目早期依靠另一股力量高速前进：开发者本身就是第一用户，朋友构成最初一批测试者，真实使用不断产生反馈，乐趣与专注又反过来提高迭代速度。但当产品开始试图服务所有人，创始人反而一度停止使用自己的产品，工作内容也从“创造想要的能力”变成修漏洞、处理安全报告、提供支持与协调社区。
两条路径同时存在：
- 产品飞轮
通过真实痛点、自用和快速反馈制造速度； - 维护熵增
通过功能、配置、兼容性和组织成本消耗速度。
成熟项目并不能消灭第二条路径，只能用边界控制它。OpenClaw 当前的 VISION.md 已把这种边界写得相当具体：安全默认值、稳定性和首次使用可靠性优先；核心保持精简，可选能力优先进入插件；一个 PR 聚焦一个问题；改动超过约 5000 行的 PR 只在例外情况下审查。
其中有一个值得复用的工程判断：核心中的每个工具、提示词片段和配置项，都会对几乎所有用户、所有模型请求持续征税；未安装插件的用户不承担这类全局税。插件本身当然仍有维护与安全成本，但成本只落在选择这项能力的范围内。所谓“拒绝功能”，很多时候是在校正能力所在的层，把可选需求留给扩展接口。
真正危险的锁定，来自依赖方的商业模式
OpenClaw 的另一个转折来自模型依赖。
演讲回顾，项目虽然支持多种模型，但较长时间内仍围绕某个表现最好的模型进行了大量优化。当供应方以很短的通知期改变订阅策略时，框架没有足够时间完成迁移。由此得到的总结非常直接：
依赖方的商业模式，就是你的商业模式。
这个判断同样适用于消息平台、操作系统自动化接口、身份系统、远程执行环境、插件生态与硬件资源。任何一层如果只有单一供应方，供应方的价格、配额、审核规则和产品路线就会变成系统的隐含约束。
“支持多个模型”只是第一步。真正的可移植性至少包括：
提示与工具协议不过度绑定单一模型的特殊行为； 关键任务能在不同模型上做回归测试； 成本、延迟和能力下降时存在明确的路由与降级策略； 本地模型可用于隐私敏感或需要离线运行的任务； 记忆、权限与工具层不随模型供应商一起迁移。
OpenClaw 官方目前把“支持主要模型供应商”列为后续优先事项，并将本地运行与个人数据控制作为产品方向。这项工作的深层目标，是把 Agent 的长期所有权留在用户和系统运营者手中。
“始终在线”需要补齐整套系统
演讲中，Steinberger 把下一阶段的目标概括为“始终在线、始终同步的 Agent”。截至 2026 年 8 月，OpenClaw 已经完成了其中的基础设施部分：官方文档将 Gateway 定义为 always-on 控制面，它可以保存会话与记忆，运行 Heartbeat 和 Cron，并在进程重启后恢复中断的任务。
接下来的难点，是让这种持续运行产生有效行动。Agent 需要判断何时值得唤醒、每次应该加载多少上下文，以及哪些操作可以在长期授权下安全执行。触发过于频繁会浪费 Token，携带的上下文过少会丢失任务状态，权限过宽又会扩大风险。目标由此从“保持进程在线”推进到“低成本、可信地持续工作”。
Steinberger 对“循环、图、工作流”等术语也持务实态度：它们描述的都是接收触发、做出判断、执行任务的自动化结构。工程上的差距最终会落在可靠性、成本、安全和扩展能力上。
至少有四类问题仍需同时处理。
1. 可靠性：一次成功还远远不够
Agent 需要面对测试超时、工具偶发失败、设备离线、会话恢复和跨机器迁移。演讲中的实际工作流已经会并行启用多个子 Agent，对不同功能做压力测试与代码审查，再互相传递测试重点；但涉及图形界面、真实操作体验和不同操作系统时，仍需要人工点击与独立执行环境。
完整的 Agent 基础设施需要任务队列，也需要资源调度、可恢复执行、幂等、观察性和失败后的清理机制。
2. 成本：主动性很容易变成无效轮询
一个静态心跳可以让 Agent 定期醒来，却不一定让它真正主动。如果每次检查都重新加载长上下文，缓存失效后会产生大量无用 Token 与计算开销。有效唤醒才是重点：何时值得启动模型、应该携带哪些最小上下文、哪些检查可以交给规则或轻量模型。
3. 安全：运行时间越长，授权窗口越大
临时会话的风险通常随会话结束而收敛；始终在线的 Agent 则长期持有入口、记忆和工具。它必须明确区分来自用户的指令、外部内容和其他 Agent 的消息，并让高风险操作经过权限检查或审批。主动性越强，结构化授权越重要，单纯增加人格化提示解决不了这类问题。
4. 协作：把完整的决策材料交给人
Steinberger 在问答中描述了一种新的协作预期：当注意力已经转向其他工作时，Agent 最好直接交付经过实现、测试和审查的 PR，避免留下整串问题等待人类回答。功能是否采用仍由人决定，但 Agent 应尽量把决策材料准备完整。
这代表人机协作接口正在从“问答”转向“验收”。对工程团队而言，任务定义也要随之变化：除了说明要做什么，还要写清验证方式、允许修改的范围、风险边界和完成证据。
对 Agent 开发者更有价值的五条经验
把这场复盘压缩为可执行的判断，可以得到五条经验。
第一，第一位用户必须足够接近开发现场。
最短反馈回路来自高频真实使用。演讲给出的路径是：开发者先成为第一用户，早期的第 2 到第 20 位用户来自熟人。值得复用的是“先自用、再用可信关系获得高质量反馈”的顺序；20 人只属于 OpenClaw 的早期情境，不构成通用门槛。
第二，先解决反复发生的摩擦，再讨论宏大叙事。
WhatsApp 中继的价值来自一个很具体的改进：消除每天都会发生的工作中断。“个人 AGI”的宏大叙事反倒没有起决定作用。持续令人烦恼的问题，往往比一次头脑风暴更接近有效需求。
第三，把代码审查视为风险管理。
AI 生成代码的阅读深度不必处处相同。认证、权限、数据迁移和执行边界需要严格审查；低风险界面调整可以更多依赖测试、截图和运行结果。潜在影响决定审查强度，代码是否出自模型只是次要因素。
第四，尽早写下项目不做什么。
开源项目最难的能力之一是说“不”。愿景文件、贡献规则和插件边界承担着实际治理作用，可以在维护者注意力有限时，为每次合并提供一致的判断依据。
第五，保留乐趣，但不要把乐趣误当作治理。
演讲反复强调“好玩”与速度的关系：享受开发的阶段，产品改善得更明显。乐趣可以驱动探索，却不能代替测试、安全边界和长期所有权。更健康的组合是用乐趣寻找方向，用工程约束守住结果。
结语：个人 Agent 的竞争，正在从模型能力转向系统能力
OpenClaw 的八个月，恰好覆盖了 Agent 产品最典型的一次相变。
最初，价值来自一个足够聪明的模型、一条消息通道和一个真实痛点；爆发之后，决定项目能否继续向前的却是另一组能力：能否在多模型之间迁移，能否让工具权限可控，能否让上下文持续而不过度消耗，能否把社区贡献转化为结构清晰的生态，以及能否在主动行动后交付可验证的结果。
因此，下一代个人 Agent 未必首先表现为更复杂的流程图。它更可能表现为一种几乎感觉不到系统存在的连续体验：入口就在日常沟通中，任务可以跨设备继续，模型可以替换，敏感数据可以留在本地，关键行动受到约束，失败能够被发现并恢复。
从这个角度看，OpenClaw 的观察价值集中在爆红之后：它提前暴露了个人 Agent 成为基础设施之前必须偿还的一批典型工程债。
欢迎关注 AI觉醒观测者，持续追踪 LLM 与 Agent 前沿动态。
