彼得·斯坦伯格（Peter Steinberger）不是AI圈的新人。他之前花了十几年时间，纯手工写过一个PDF处理框架，把一家B2B软件公司从零做到近80人规模，卖掉股份后彻底退休了三年。退休期间基本不碰电脑，就是普通人一样刷手机、参加聚会。他后来复盘说，自己一直以为退休后重新出发时会想写代码，但花了整整一年才想明白，自己上瘾的并非编程本身，其实是"做出东西"这件事。

于是在去年11月的一个雨天，他同时开着好几个编程agent去跑任务，肚子饿了想去厨房拿点吃的，又不放心agent会不会出岔子，可他手机上完全没办法看它们的进度、发指令。这份烦躁因此催生了一个通宵的小项目：一个能把消息在Mac和WhatsApp之间来回转发的中继工具。一小时后他就能用手机给电脑上的agent发消息了。这个小玩具，八个月后变成了开源智能体项目OpenClaw——巅峰时期周下载量470万，将近3000名贡献者提交了超过11万次代码变更。

验证产品的方式：不是"喜欢"，是情绪波动

斯坦伯格最初把这个中继工具分享给身边朋友的群聊，让大家直接跟它聊天。反馈很两极：有人觉得神奇，有人被吓到甚至有点抵触。但每次都有强烈情绪，可以说很少有人只是礼貌地说"还不错"。他后来意识到，这种强烈反应本身就是产品有戏的信号,尤其是当一些完全不懂技术的朋友因为被他劝退（"这个还不适合你用"）而生气的时候,那种"想要却被拒绝"的沮丧,反而是最真实的信号。

从中继工具到开源狂欢：一次PR引发的连锁反应

项目沉寂了一个月后,有人给这个WhatsApp中继工具提了个PR,想加Discord支持。斯坦伯格纠结了一阵,最后想通了,干脆把项目改名叫Claudius,做成支持多个消息渠道的通用工具。那时候项目还很粗糙,连上下文压缩（compaction）都没做好,对话长了就直接卡死。

真正的转折点其实是去年跨年夜前后。他连夜搭了个Discord服务器,把自己的agent放进去让大家围观、互动。第一晚他守了一整夜,凌晨七点终于撑不住去睡觉,顺手按了Ctrl+C想把程序关掉——结果因为程序是用launch daemon跑的,五秒后自动重启,继续在他睡觉的时候回复全世界的消息。十小时后他醒来,收件箱里躺着800条消息。项目就是在他熟睡的这十个小时里,彻底火了。

改名风波与"依赖别人商业模式"的教训

爆红之后,项目先叫Claudius,后来因为撞了商标问题被Anthropic要求改名（连带着项目原本用的龙虾梗图也一起下线了）,中间经历了一段没有正式名字的尴尬期,最终定名OpenClaw。黄仁勋后来公开评价它是"史上最成功的开源项目"。

改名只是一件小插曲，真正棘手的是项目当初深度绑定了某一家实验室的模型——他坦言当时Opus的效果确实是几个选项里最好的,项目的执行框架（harness）也是围着它优化的。结果这家实验室提前不到24小时通知,要停用某种订阅接入方式,项目一下被打了个措手不及,来不及调整架构。他把这条教训总结成一句话:你依赖的东西靠什么商业模式赚钱,最终会变成你自己的商业模式。这句话现在回头看依然成立——好在开放权重模型这一年多进步很快,给了后来者更多"不把鸡蛋放一个篮子"的空间。

安全举报的洪流,和被夸大20倍的数字

项目出圈后,安全研究者的举报邮件、电话、社交媒体私信一起涌来。当时媒体报道说项目里20%的技能（skills）存在恶意代码,吓坏了不少用户。斯坦伯格团队后来专门做了统计,扫描了全部6.7万个技能,真实比例大约是0.3%——差了将近70倍。他们把数据和方法整理成论文发出来,但纠错的传播力远远比不上最初那句耸人听闻的"20%"。为了应对压力,团队加了沙箱、权限白名单、审核协议,甚至专门用Python重写了一部分文件操作逻辑,防止agent跳出工作目录或者跟随恶意符号链接——但他后来承认,大部分普通用户根本不关心这些底层细节,他们只在乎"看起来安全",真正在乎的是软件别在更新时把自己原来的配置搞坏。

功能越加越多,配置项冲到近一万种

项目社区涌入大量贡献者,大家都想往里加自己喜欢的功能。加功能这件事因为有agent辅助写代码,变得异常容易,但每加一个功能,团队出于兼容性考虑都会配一个可开关的选项——滚雪球滚到最后,光是配置排列组合的数量就接近9500种。测试写得再全,也不可能覆盖所有情况。斯坦伯格因此反思说,这段时间他自己精力被开源社区、媒体采访、成立非营利组织的法律事务分散,对新功能的把关变得松散,这是项目在这段时间里质量下滑的直接原因。

周下载量从83万跌到"被判死刑",又冲上470万

同期,一家有"动漫风格形象"的竞争对手（斯坦伯格戏称自己"被一个动漫女孩打败了"）靠着更简单的营销故事和资本推动快速抢占声量,而OpenClaw团队还埋头在安全整改和功能维护里。项目周下载量在今年5月跌到83.5万的低点,6月甚至被媒体"判了死刑",结果两个月后反而冲上470万的历史新高——他的结论是,热度这东西就像天气,你能感觉到它要来,但控制不了它。

从"不再好玩"到重新找回节奏

大概从今年2月开始,斯坦伯格说自己不再享受做这件事了——它从一个自己每天都在用、离不开的工具,变成了一份责任,他甚至一度停用了自己一手做出来的产品。转折出现在5月前后,项目正式注册成501(c)(3)非营利组织,英伟达很早就主动伸出援手,派人接管了大量安全相关的工作,团队也逐渐凑齐了10个人的正式团队,准备再招一个CEO。他把这段经历总结成一句话:乐趣本身就是速度（fun is velocity）——他享受做的那几周,产品明显在变好;不享受的那几周,团队只是在堆配置项。

落地方案:这些教训能怎么用在你自己的agent系统上

把这些经历收拢成几条可以直接用的原则:

第一,先做给自己用。斯坦伯格提到,产品的第一个用户永远该是你自己,第二到第二十个用户是你的朋友——如果连自己都不兴奋,这个东西大概率做不起来。

第二,会话要按主题攒记忆,而不是按时间清空。他提到自己现在的用法已经从"一个任务一个会话"变成"一个主题一个会话",清空反而可能是种损失,因为里面攒的上下文本身就是隐性记忆。

第三,核心逻辑要跟具体模型解耦。24小时断供的教训是真实发生过的,任何长期依赖单一模型接口的系统,都该留一层可以随时切换供应商的缓冲。

第四,永远在线的agent卡在钱上,不是技术上。斯坦伯格提到,如果每小时都对着几十万字的历史上下文做一次"心跳检查",token成本高得离谱,而且大部分检查毫无意义。更现实的做法是把触发机制分层——便宜的规则判断做前置过滤,只有真正需要复杂推理的场景才唤起大模型。

第五,加功能前想清楚维护成本,而不是能不能做到。他反思自己后期没能守住这道关,才有了近一万种配置组合的技术债。写一个vision.md文件,明确项目现在是什么、要成为什么,是他后来才补上的一课。

从一个人深夜手痒的小工具,到近500万人每周都在用的开源项目,这中间最值钱的东西从来不是代码量,而是这些踩坑之后攒下来的判断力。这或许才是"个人AGI"这件事最终要落到的地方永远都是拥有一个多厉害的模型,而是拥有一套只属于你、越用越懂你的判断系统。