从个人痛点到产品雏形：WhatsApp 中继的诞生
Peter Steinberger 回顾 OpenClaw 项目的起源，指出其核心驱动力并非宏大的技术愿景，而是日常开发中的具体痛点。2025 年初，他在使用早期模型（如 Opus 3、Sonnet 2.5）调试 Agent 时，发现缺乏一种便捷方式从手机向电脑发送指令以监控 Agent 状态。这种不便促使他在一次厨房休息期间，通过自然语言向编码助手描述需求。令人惊讶的是，模型在一小时内构建出了一个 WhatsApp 中继服务，实现了 Mac 与 WhatsApp 之间的双向消息收发。
这一过程体现了当时 AI 能力的质变：虽然技术上看似简单（终端输入输出），但AI 展现出了主动性和简洁性。Peter 调整了提示词权重，使 AI 的行为更像朋友而非冷冰冰的工具。这种“魔法般”的体验让他确信 AGI 已至，但初期在社交媒体上并未引起共鸣。直到他将该工具分享给非技术背景的朋友，观察到的强烈情绪反应（震惊、恐惧或渴望）让他确认了产品市场契合度（Product-Market Fit）的存在。随后，一个来自社区的 Pull Request 建议添加 Discord 支持，促使他将项目从“WhatsApp Relay”重命名为更具通用性的 Cladis。
意外走红：失控的 Launch Daemon 与病毒式传播
OpenClaw（即后来的 Cladis）的真正爆发源于一次技术上的意外与用户好奇心的碰撞。在 1 月初，Peter 将 Cladis 部署到 Discord 服务器中，并设置了严格的安全限制：除非指令来自 Peter本人，否则禁止执行任何危险的工具调用。他在除夕夜完成开发后，按下了 Ctrl+C 准备休息。然而，由于软件被配置为 Launch Daemon（启动守护进程），它在短暂中断后会自动重启。这意味着在他入睡后的 10 小时内，AI Agent 一直在无人监管的情况下与公众互动。
次日清晨醒来时，Peter 面对的是约 800 条用户消息。尽管他最初感到恐慌并立即切断服务，但仔细审查后发现并未发生任何安全事故或有害输出。这一事件成为了转折点：用户的自发参与和黑客式测试证明了系统的鲁棒性，同时也引发了媒体的高度关注。报道中甚至引用了苹果 iOS 的“紧急呼叫”逻辑来类比这种不可预测的传播效应。随之而来的是Mac Mini 售罄、播客邀请激增以及来自 Tropic 等公司的法律警告。这一阶段标志着 OpenClaw 从一个极客玩具转变为拥有数万用户的大型社会实验现场。
“让模型烹饪”：大规模并发下的现实检验
Peter Steinberger 在演讲中强调，他是最早见证数万人同时“让模型烹饪”（Let it cook）后果的人之一。这里的“烹饪”指的是让用户自由地与 AI Agent 进行深度、长期的交互，而非简单的单次问答。这种大规模并发使用带来了前所未有的挑战：系统需要处理海量的上下文、复杂的逻辑链条以及用户不可预测的行为模式。与早期单人调试不同，现在的系统必须应对多用户同时在线、高频次交互以及潜在的对抗性测试。
“Yesterday Boris told you to let the model cook. I'm the guy who found out what happened when tens of thousands of people let it cook at the same time.”
这一现象揭示了当前 AI 应用的一个关键悖论：用户渴望更智能、更具自主性的 Agent，但同时也对 AI 的不可控性感到恐惧。Peter 指出，早期的模型（如 Opus 3）虽然强大但速度慢且昂贵，而现在的用户期望即时响应和低成本。这种需求推动了技术栈的快速迭代：从最初的简单中继到后来引入上下文压缩（Compaction）机制，以解决长对话中的记忆丢失问题。尽管早期版本存在技术粗糙（Hacky）的问题，但正是这种“不完美”激发了社区的参与感和创造力。如今，OpenClaw 已成为一个观察人类与 AI 长期互动关系的实验室，其数据为理解未来 AGI 形态提供了宝贵的一手资料。
核心洞察：情感连接与产品市场契合度
Peter Steinberger 通过 OpenClaw 的案例提出了一个关于 AI 产品设计的重要观点：技术可行性并不等同于市场接受度，情感连接才是关键。在早期阶段，尽管他拥有 Twitter 上的良好基础，但单纯展示技术能力并未引起关注。直到非技术人员通过 WhatsApp Relay 体验到 AI 的“主动性”和“拟人化”特征后，才产生了强烈的情感反应。这种反应包括惊喜、恐惧以及对掌控感的渴望。
“If that's not an indicator to have product market fit I don't know what is.”
这一洞察表明，成功的 AI 产品必须超越工具属性，成为用户生活中的“伙伴”。OpenClaw 的成功并非源于其代码的优雅或算法的精妙，而是因为它解决了用户在实际场景中的孤独感和控制欲需求。通过允许用户在 Discord 中自由探索、甚至“黑客”系统，Peter 创造了一个开放且充满活力的社区生态。这种模式不仅加速了产品的迭代（如通过用户反馈快速修复 Bug），还建立了深厚的品牌忠诚度。最终，OpenClaw 的故事证明：在 AI 时代，最大的创新往往来自于对人性需求的深刻理解和响应。
未来展望：从个人实验到社会现象
随着 OpenClaw 用户规模的扩大，Peter Steinberger 开始思考大规模 AI Agent 部署对社会结构和个体行为的影响。他指出，当前的系统虽然仍由人类主导（如他本人可以随时切断电源），但AI 的自主性正在逐步增强。未来的挑战在于如何平衡安全性、隐私保护与用户体验之间的张力。例如，如何在允许 AI 主动发起交互的同时，防止其被滥用或产生有害内容？
此外，Peter 还提到了技术债务与快速迭代之间的矛盾。早期为了赶在 Discord 上线而添加的“黑客式”上下文压缩功能，虽然解决了燃眉之急，但也为后续维护埋下了隐患。这反映了当前 AI 开发领域的普遍现象：速度优先于完美。然而，正是这种快速试错的精神推动了技术的飞速进步。OpenClaw 不仅是一个产品，更是一个社会实验平台，它揭示了人类在面对强大 AI 工具时的复杂心理：既渴望依赖又充满警惕。Peter 希望通过分享这些经验，帮助其他开发者和用户更好地应对即将到来的 AI 浪潮。
从开源奇迹到个人噩梦：失控的关注度
OpenClaw项目经历了多次更名，最终由Jensen Huang称为“人类历史上最成功的开源项目”。然而，这种成功带来了巨大的个人压力。在短短8个月内，超过18,000名不同用户提交了Issue或Pull Request，总计达111,00次；近3,000人拥有代码提交记录。这种关注度让作者感到窒息，甚至有人因未被认可而指责他窃取创意或称其为“反基督”。作者几乎崩溃，一度想删除整个项目并切断与外界的联系。隐私泄露更是加剧了这种痛苦，电话号码和私人细节被公开。
“Be careful what you wish for. I was not ready for all this attention. It almost broke me.”
这种极端的关注让作者意识到，个人品牌比任何单一产品都更重要。尽管项目取得了巨大成功，但随之而来的法律纠纷、媒体压力和社区管理负担几乎摧毁了作者的身心健康。他不得不面对一个现实：在开源世界中，名字无法被克隆，但产品可以被分叉或复制。这一教训成为他后续决策的核心背景。
创业反思与商业抉择：为何选择OpenAI而非巨头？
作者并非初次面对重大决策。在20至30年代，他白手起家建立了一家B2B软件公司，手动编写PDF框架，将团队扩展至近80人，最终因过度劳累而 burnout（倦怠）。退休后的三年里，他试图通过远离电脑来恢复生活，但发现自己真正热爱的是“构建”而非单纯的编程。当OpenClaw爆红后，各大科技巨头纷纷提出收购意向，包括与Mark Zuckerberg和Sam Altman等人的通话。然而，作者最终选择了OpenAI。
“Everything that everything you can build can be forked or cloned, but your name cannot. So your personal brand is way more important than any single product... trusting your gut.”
这一决定并非易事，作者形容其等同于“出卖灵魂”。但他基于过往经验判断，信任直觉是度过倦怠期的关键。他意识到，尽管巨头能提供资金和资源，但OpenAI的开放理念更符合他的价值观。这一选择也预示了后续项目发展的方向：在保持开源精神的同时，面对来自拥有无限资源的竞争对手的压力。
安全困境与功能膨胀：被巨头超越的根源
项目发布后，作者面临严峻的安全挑战。媒体曾报道“20%的技能具有恶意”，但经扫描67,000个案例，实际比例仅为0.3%。尽管发布了纠正报告，但恐惧的传播远快于真相。为应对风险，作者投入大量精力进行代码加固、沙箱隔离和权限协议设计。然而，过度关注安全导致更新变慢且操作复杂。
与此同时，项目功能迅速膨胀。由于社区贡献者众多，每个新功能都需配置选项以避免破坏现有设置。最高时系统拥有约9,500个配置选项，导致测试覆盖几乎不可能完成。相比之下，竞争对手如“动漫女孩公司”凭借简单故事、激进营销和一键迁移方案迅速抢占市场。作者承认，过度优化特定模型（如Codex和GPT）导致项目在面对更强大的基座模型时失去优势。
| 对比维度 | OpenClaw (作者项目) | 竞争对手 (如动漫女孩公司) |
|---|---|---|
| 配置复杂度 | 约9,500个选项，测试覆盖极难 | |
| 营销策略 | 依赖技术文档与安全声明 | |
| 用户迁移成本 | 高，需手动调整配置与理解安全机制 | |
| 核心优势叙事 | “最成功的开源项目”，但缺乏简单故事线 | |
| 模型依赖优化 | 深度绑定Codex/GPT，基座升级时适应性差 | |
| 市场响应速度 | 慢，受困于安全审查与社区维护压力 |
商业模式的局限性与下载量的戏剧性反转
OpenClaw 早期的成功很大程度上依赖于对 OPOS（可能是某种特定平台或协议）的优化，这导致其在面对突发危机时缺乏灵活性。当相关方在约 24 小时前通知将禁用订阅服务时，团队已无足够时间调整方向。尽管当时支持开源权重模型（open-weight models），但这些早期版本缺乏个性且性能不佳。然而，随着技术演进和团队在“Harness 工程”方面的积累，开源模型的质量显著提升。这种转变直接反映在下载数据上：OpenClaw 的周下载量在5月触底，随后因被宣布“死亡”而引发关注，于6月飙升至历史峰值。
| 时间节点 | 周下载量数据 | 关键事件/状态 |
|---|---|---|
| 5月 (触底) | ~835,000 | 下载量低谷 |
| 6月 (峰值) | 4,700,000 | 被宣布“死亡”后达到历史最高 |
"You can see that in our download charts. We bottomed out at around 835,000 weekly downloads in May. And then after being declared death in June, we peaked at 4.7 million, the highest ever."
从创造者到维护者的倦怠：当乐趣消失时
随着用户量激增，Peter Steinberger 的个人体验发生了剧烈变化。大约在2月左右，项目不再带来乐趣，而是转变为一种沉重的责任。他发现自己陷入了一种矛盾境地：一个本不想再创业的人，却不得不身兼数职。更糟糕的是，他停止使用自己的产品。随着功能堆砌和组织工作的增加，他从“为所有人打造”转向了修补 Bug、解决安全问题和提供支持的运维角色。这种转变让他感到痛苦，因为产品不再是他日常热爱使用的工具。
"I stopped using my own product. Somewhere in that time I stopped making a product I love and I worked on making something for everyone. It became less of a thing that I use every day... and more I think that I saw and felt was work."
此外，谣言四起（如称 OpenClaw 被 OpenAI 收购），导致他不得不拒绝外部帮助，甚至拒绝了 NVIDIA 早期的部分支持提议（尽管使用了其 Token）。这种孤立无援的状态让他陷入战略思考的缺失，直到后来遇到志同道合的人并成立非营利组织才逐渐缓解。
开源精神的回归：乐趣即速度，痛点即机遇
在经历低谷后，Peter 重新找回了构建产品的喜悦。他意识到乐趣是速度的源泉。当他在享受开发过程时，产品可见地变好；当他感到疲惫时，进展停滞。他提出一个核心观点：灵感来源于被软件 annoy（困扰）的时刻。如今，当他遇到无法通过简单提示词修改的软件时，这种烦躁感反而成为推动 OpenClaw 发展的动力。
"Fun is velocity. The weeks I enjoyed building, the product got visibly better... My source of inspiration is being annoyed."
尽管媒体每周都宣称有“OpenClaw 杀手”出现（甚至有一个名为 OpenCloud Killer 的卸载项目），但这些故事从未触及开源的本质。Peter 强调，OpenClaw 的核心优势在于开放性与本地化运行能力。它不依赖单一实验室，支持任意模型，且若使用本地模型，数据无需离开设备。这种“你的代理、你的机器、你的生活”的理念，构成了其独特的竞争壁垒。
未来愿景：多模态、团队协作与开源生态
展望未来，OpenClaw 基金会已拥有10名全职员工并计划招聘 CEO。其使命是将人们拉近 AI，通过活动和教育构建开放的软件生态系统。Peter 指出，当前的技术正处于从纯文本界面向语音和多模态过渡的关键节点。例如，他们刚刚实现了让 OpenClaw 进行 FaceTime 通话的功能，这标志着代理交互方式的根本性变革。
"We're entering a world where we finally move on from the text only interfaces to voice and multimodality. Just yesterday we got a hack working that your claw can now facetime you..."
未来的开发方向包括： 1. 始终在线的代理：解决当前缺乏持续同步代理的问题。 2. 团队协作模式：通过团队服务器共享会话，让代理了解彼此的工作并协调任务。 3. 摆脱终端依赖：改变人们不得不打开笔记本电脑等待代理工作的现状，实现更自然的交互。
Peter 最后给出三条建议：保持乐趣以激发最佳创意；倾听直觉并修复让你烦恼的问题，这可能成为下一个大机会；以及保持专注，持续交付。他调侃道：“让他们困惑吧。现在，[喷笑声] 这就是那五个要点。”
AI Agent 工作流：从被动响应到主动执行
Peter Steinberger 指出，AI Agent 的开发范式已经经历了从简单的会话（Sessions）到循环（Loops），再到图结构（Graphs）的演变。早期的开发需要开发者极度关注指令的一致性并手动清理会话上下文，但现在的趋势是将 Session 视为主题（Topics），甚至有时清除会话反而是一种劣势，因为其中积累的信息有助于 Agent 更好地理解上下文。他目前的核心策略是让 AI Agent 承担更多主动性的工作。例如，在代码审查环节，他不再希望手动阅读所有 Issue 或 PR，而是期望看到经过 Agent 完全审查和测试的 Pull Request。这种转变旨在避免注意力的分散，让开发者专注于决策而非执行细节。
"I try to make the agent do more proactive work for me... I don't want to like split my attention."
这种主动式工作流不仅限于代码审查，还延伸至产品迭代。Steinberger 强调，如果团队成员能先与 Agent 讨论功能创意、构建原型并生成截图供其体验，那么反馈循环将大大加速。大多数情况下，这种前置的 Agent 辅助开发能让团队自行发现功能的不可行性，从而避免无效沟通。他认为，无论是称为 Loop、Graph 还是 Workflow，本质都是自动化故事的延续。在“快速构建、快速发布”的时代，关键在于如何利用这些工具确保产品的可靠性和可扩展性。虽然模型在测试方面曾是他失误的地方，但现在他相信通过编排训练和子 Agent 的使用，AI 已经能够构建出近乎完美的问答环境。
自动化测试与代码审查的风险管理哲学
在技术实现层面，Steinberger 描述了如何利用多 Agent 协作进行自动化测试。他举例说明，昨天他曾启动 CodeCogs，使用 12 个子 Agent来理解项目结构、拆解功能特性。每个子 Agent 负责对特定功能进行压力测试或代码审查，并告知主会话将注意力集中在哪些需要重点测试的区域。尽管目前尚不能完全自动化所有流程，仍需进行一些手动点击以感知用户体验，但对于用户常遇到的典型 Bug，通过 Prompt 引导 AI 已经能取得显著进展。他提到，如果本地运行一个测试导致 TSGO 启动 16 个线程并造成机器瓶颈，当多个 Session 同时运行时，超时问题会加剧，目前缺乏良好的系统来管理这种计算资源调度。
在代码审查（Code Review）方面，他做出了一个基于速度的早期决定：不阅读所有代码。他将 Code Review 视为一种风险管理手段，而非单纯的代码检查。对于触及复杂系统或“令人恐惧”的代码模块，他会仔细审阅；而对于 UI 构建等部分，只要外观正确即可接受。他发展出了一种直觉：如果一个小调整（如改变拖拽行为）耗时异常长，他会深入检查；否则，他主要观察变更规模并信任直觉。这种策略在 AI 工具极大缩短构建周期的背景下，平衡了速度与质量。他承认，虽然模型现在具备使用子 Agent、计算机操作和浏览器控制的能力，但完全自动化仍不可行，手动验证仍是必要的补充。
从原型到用户：自我作为第一用户的策略
关于如何从工作原型获取前 10 个真实用户，Steinberger 提出了一个反直觉但实用的建议：你自己应该是第一个用户。他的前两个到第二十个用户都是朋友。他认为，如果开发者自己不对所构建的产品感到兴奋，那么该产品很可能没有意义。在当今时代，眼球（注意力）是最昂贵的货币，因为构建产品的速度极快，获取用户关注变得异常困难。因此，验证产品价值的最佳起点是确保构建者自身被其功能所吸引。
在平衡解决个人痛点与开发大众所需功能之间，Steinberger 坦言这是一个难题。他发现自己常常因为自身遇到不便而开发新功能，这往往与用户需求重合。然而，他也意识到如果只专注于解决边缘案例（Edge Cases），尤其是随着功能增加导致的复杂性，他会失去工作兴趣。因此，他需要在解决痛点与保持开发热情之间找到健康的混合点。目前他尚未完全掌握这一平衡的艺术，但这仍是其产品开发哲学的核心部分。他强调，利用 AI 工具在周末构建产品已非难事，真正的挑战在于让用户开始使用它。
安全反馈与基础设施瓶颈的反思
回顾 OpenClaw 的发展，Steinberger 表示如果重来一次，他会对安全研究人员更加从容。他形容这些研究员擅长通过邮件、电话等各种方式施加压力，但往往并非为了帮助产品改进，而是为了获取 Bounty（赏金）或名声。许多报告甚至是由 Agent 自动生成而未经验证的，这让他浪费了数月时间并白了头发。他建议未来应更明确地解释哪些部分在安全保证范围内，哪些不在，以管理预期。此外，他指出当前 AI 基础设施的最大瓶颈在于可靠性、工具链和内存管理。特别是在 macOS 环境下，99% 的工具无法有效支持复杂的本地测试会话。如果能在计算资源管理和跨平台兼容性上取得突破，AI Agent 的自动化能力将得到质的飞跃。
"I would be less stressed out about security researchers... In most of the case, it's really just for them to get cloud, for them to get a point."
在性能数据方面，虽然视频中未提供具体的基准测试跑分表格，但 Steinberger 提到了一个关键的资源消耗现象：在本地运行单个测试时，TSGO（可能指代其内部的某种测试调度器或工具）会启动 16 个线程，导致机器资源瓶颈。当有 10 个 Session同时运行时，预计会有部分会话超时并需要重试。这一现象揭示了当前 AI 开发环境中并发测试资源管理缺失的问题，这也是他眼中阻碍大规模自动化可靠性的关键基础设施短板。
跨平台自动化与开源项目的方向把控
在构建需要依赖本地环境的自动化工具时，跨平台兼容性仍是巨大挑战。目前尚未出现能无缝在不同操作系统间迁移且无故障的方案，导致开发者不得不采用低效手段（如屏幕共享分发负载）来维持系统运行。对于开源项目，保持愿景的纯粹性比盲目合并 PR 更重要。Peter Steinberger 坦言自己过去拒绝不够果断，导致项目偏离主线。他现在的做法是编写 vision.mmd 文件明确方向，尽管这并非完美科学。合并一个看似酷炫的功能往往意味着接手一堆难以维护的代码债务，开发者需对后续责任有清醒认知。
"I didn't say no enough... when you merge this feature it really means here's this pile of code that I don't [understand]."
AI Agent 的 Token 成本与系统架构优化
实现全天候主动运行的 AI Agent，核心瓶颈在于 Token 费用而非技术能力。当前订阅模式难以支撑海量 token 消耗，且设计避免无效 Token 燃烧的系统极具难度。早期采用的静态心跳机制（Heartbeat）效率低下：若会话长达一小时，后续检查需重新发送大量上下文至服务器（如 600,000 tokens），导致 KV Cache 失效并产生高昂费用。优化重点在于减少冗余通信和保持上下文连续性，而非单纯增加算力。
个人开发环境与代码审查策略
Peter Steinberger 的个人工作流依赖于 MacBook + Jump Desktop，通过屏幕共享连接至常开的 Studio 主机。这种分离架构有两个关键优势：一是避免电池损耗和性能瓶颈，二是防止 Agent 干扰人类操作。由于他开发大量 Mac 软件，Agent 容易抢占鼠标焦点；将 Agent 隔离在独立机器上可彻底解决人机冲突。关于代码审查，他区分了个人开源与 OpenAI 内部工作的风险管理体系：在 OpenAI 仍坚持全员阅读所有代码，而在个人项目中则采取更灵活的风险控制策略。
创业建议与开发者工具痛点
对于新创业项目，Peter Steinberger 提出三点核心原则：首先，必须构建自己真正想使用的产品；其次，在信息过载时代，个人品牌与可见性比技术本身更难突破，获取用户眼球是最大难题；最后，建议切入 “硬核且枯燥” 的领域。这类问题虽不性感，但一旦解决便能获得精准用户群；相比之下，趣味性强的领域在 AI 生成内容泛滥的今天更难突围。他特别指出，目前缺乏高效、廉价且跨平台（Mac/Windows/Linux）的测试环境提供商，这是开发者工具领域亟待解决的商业机会。
"The hardest problem now is like getting eyeballs... If you pick something that is fun, even if it's hard, you're gonna have a very tough time."
highlights": ["The hardest problem now is like getting eyeballs.", "If you pick something that is fun, even if it's hard, you're gonna have a very tough time.", "I didn't say no enough... when you merge this feature it really means here's this pile of code that I don't [understand]."]