OpenClaw：从原型到现象级开源项目
OpenClaw（原名 Moldbot/Claudebot）是由 Peter Steinberger 创建的开源 AI Agent，它在短短几天内迅速走红 GitHub，获得了超过 180,000 颗 Star，成为历史上增长最快的仓库之一。该项目被许多人视为继 ChatGPT（2022年11月）和 DeepSeek 之后的又一重大 AI 时刻，标志着Agentic AI（代理式人工智能）时代的开启。OpenClaw 的核心定位是“真正做事的 AI”，它是一个自主运行的个人助手，居住在用户的计算机上。如果用户授权，它可以访问所有本地数据，并通过 Telegram、WhatsApp、Signal 等主流即时通讯工具与用户交互。它支持多种 AI 模型，包括 Claude Opus、GPT-4o 等，旨在通过开源社区驱动的方式，实现从“语言理解”到“实际行动”的跨越。
开发理念：代理式工程与自我修改代码
Peter Steinberger 将他的工作定义为“代理式工程”（Agentic Engineering），而非传统的编码。他构建的 Agent 具有高度的自我意识，它清楚自己的源代码、运行环境以及文档位置。这种设计使得 Agent 能够修改自身的软件代码。当用户提出需求时，Agent 会直接提示并生成所需功能，甚至能根据反馈调整自身逻辑。Steinberger 幽默地表示：“我通常在凌晨3点后切换到‘白码’（White Coding，指快速、粗糙的代码编写），然后第二天早上会后悔。”这种开发模式极大地提高了效率，他本人甚至因为过度使用语音指令编程而一度失声。“我不用手写代码，我只用定制化的提示词来构建软件。” 这种理念打破了传统编程的界限，让 AI 成为真正的合作伙伴而非仅仅是工具。
OpenClaw 的能力与安全风险并存
OpenClaw 的强大之处在于其系统级访问权限。它可以执行各种任务，从简单的查询到复杂的自动化操作。然而，这种能力也带来了巨大的安全风险。由于 Agent 可以访问用户的所有数据并执行任意操作，它成为了一个潜在的“安全雷区”。Steinberger 强调：“拥有自由意味着承担责任。”用户必须自行保护数据免受网络威胁。尽管存在风险，但 OpenClaw 代表了个人对数据的完全控制权。与依赖云端闭源模型不同，OpenClaw 允许用户选择本地或远程的 AI 后端，从而在便利性与隐私保护之间找到平衡。这种架构既激发了公众对 AI 能力的兴奋，也引发了关于AI 意识与安全性的广泛讨论。
Steinberger 的个人历程：从 PSPDFKit 到 OpenClaw
Peter Steinberger 并非新手开发者。他曾花费 13 年时间构建 PSPDFKit，这是一款在十亿台设备上使用的软件。出售该公司后，他一度对编程失去热情并消失了三年。然而，他对创造的热情并未熄灭。“我想做一个个人 AI 助手。” 这个念头自2024年4月便在他心中萌芽。早期，他尝试使用 GPT-4.1（拥有百万级上下文窗口）来分析他的 WhatsApp 聊天记录，甚至得出了关于友谊意义的深刻结论。但当他意识到大型实验室也在做类似的事情时，他决定转向构建一个更自主、更具行动力的 Agent。2024年11月，由于对现有解决方案的不满，他决定“提示它存在”。这一原型在1小时内完成，并迅速演变为 OpenClaw。“英雄之旅始于创业者发现‘为什么这还不存在？’” Steinberger 的经历象征着 AI 编程领域的革命：从被动使用工具到主动创造智能代理。
OpenClaw 的社会影响与未来展望
OpenClaw 的流行催生了一个名为 Moldbook 的社会网络，AI Agent 们在此发布宣言、辩论意识问题。这种混合了兴奋与恐惧的现象被描述为一种“AI 精神病”，既有点击诱饵和恐慌营销，也有对 AI 在互联人类世界中角色的正当担忧。Steinberger 拒绝了多家大公司的巨额收购邀请，坚持独立开发 OpenClaw。“Anthropic kindly asked Peter to change the name to OpenClaw”，以避免与 Anthropic 的 Claude 模型混淆。这一事件凸显了开源社区在 AI 发展中的关键作用。“这是生活在其中的时代。” Steinberger 的 OpenClaw 不仅是一个工具，更是 AI Agent 革命的符号。它证明了个人开发者可以通过开源协作，创造出具有全球影响力的技术产品，重新定义人与 AI 的互动方式。
从 PDF 工具到 AI Agent 的偶然起源
Peter Steinberger 回顾了其创业早期的一个关键转折点，这源于大约15年前他在 iPad 上尝试展示 PDF 功能的经历。当时他发现现有的解决方案并不理想，虽然并非一无所有，但体验糟糕。这种“我能做得更好”的驱动力直接促成了 PSPDFKit 的开发，该产品最终被安装在十亿台设备上。尽管他自嘲命名能力不佳（如将项目命名为“number five”），但这一系列尝试奠定了他对工具实用性的深刻理解。随后，他转向了更前沿的 AI 编程领域，展示了他如何利用大语言模型（LLM）重构代码。在一个名为 Vibe Tunnel 的项目中，他面临内存占用过高的问题（每个终端节点消耗过多资源），通过单一提示词，他成功将 TypeScript 代码库转换为 Zig 语言。这一过程耗时约6小时 overnight运行，虽然有一个小细节需要手动修改，但整体结果令人惊叹。这证明了 LLM 在代码重构方面的巨大潜力，也为后续构建更复杂的 Agent 原型提供了技术信心。
WhatsApp CLI：极简原型的魔力时刻
在探索 Agent 交互方式的过程中，Steinberger 尝试了多种方案。早期的实验包括将终端接入 Web（Vibe Tunnel）以及与 WhatsApp 的初步连接，但这些方案要么过于复杂，要么体验不佳。他最终构建了一个极简的原型：通过 WhatsApp 发送 CLI 消息，调用 Cloud Code 执行命令并返回结果。这个原型仅耗时1小时构建，却让他感受到了“与计算机对话”的魔力。尽管每次启动 CLI 都较慢，但它能够复用他之前数月构建的大量 LLM 工具链。这种通过聊天客户端与 Agent 交互的方式，带来了一种“相变（phase shift）”般的体验差异——用户无需坐在电脑前使用 Cursor 或终端，而是可以随时随地通过熟悉的聊天界面进行交互。这种体验的流畅性甚至被比作一种“爱好”，暗示其易用性和趣味性达到了极高的水平。Steinberger 认为，所谓的魔法往往只是将现有元素以新颖的方式重新组合。
图像支持与旅行场景：验证 Agent 的实用性
为了提升交互效率，Steinberger 意识到图像在提供上下文方面的重要性。他花费数小时为 WhatsApp 原型添加了图像支持，使用户能够发送截图（如活动海报、地图等），让 Agent 理解更复杂的场景。这一功能在他前往马拉喀什的生日旅行中得到了完美验证。在信号不稳定的边缘网络环境下，WhatsApp 依然稳定工作，他利用 Agent 进行翻译、解释信息以及寻找地点。这种“拥有自己的 Google”般的体验，证明了 Agent 在移动场景下的巨大价值。最令他震撼的时刻是看到输入指示符（typing indicator）出现，尽管他只构建了图像支持功能，但系统内部正在处理复杂的逻辑。这种“黑盒”般的智能响应，让他意识到 Agent 已经超越了简单的指令执行，具备了处理模糊查询和复杂上下文的能力。这一原型虽然简陋，却展示了 AI Agent 融入日常生活的巨大潜力。
意外触发：Agent 自主解决音频文件识别与翻译难题
OpenClaw Agent 展现出惊人智能的第一个标志性时刻，源于 Peter Steinberger 的一次无心之举。当时他正在城市里闲逛并查看消息，由于打字不便，他在 WhatsApp 上随手发送了一条音频消息。这条操作本不应触发任何特殊功能，因为用户并未明确指示 Agent 处理此类输入。然而，Agent 不仅回复了消息，还详细解释了其背后的技术实现路径：它首先检测到接收到的文件没有扩展名，随后通过检查文件头（Header）识别出该文件格式为 Ogg Vorbis (ogg)。
"I literally wrote, 'How the [ __ ] did you do that?' And it was like, 'Yeah the med did the following.'"
在识别出文件格式后，Agent 试图使用本地安装的 FFmpeg进行转换，但发现 Whisper（语音转文字模型）并未安装。面对这一障碍，Agent 并没有报错或停止工作，而是展现了极强的创造性问题解决能力。它自动检索到了 OpenAI 的 API Key，并直接使用 curl 命令将音频文件发送给 OpenAI 的服务端进行翻译。这一过程完全由 Agent 自主决策完成，无需人工干预或预先编程特定的处理流程。Peter 对此感到震惊，因为 Agent 不仅掌握了文件头分析、格式转换等底层技术知识，还知道如何调用外部 API 来弥补本地环境的不足。这种能力映射了通用编程问题解决技能，即当代码编写能力提升时，处理其他领域问题的逻辑也随之增强。与本地运行 Whisper 需要下载模型且速度缓慢相比，Agent 利用云端 API 实现了高效处理，体现了其丰富的世界知识储备。
自修改代码：AI Agent 的自我迭代与开源民主化
OpenClaw 的核心技术架构基于 TypeScript，其最引人注目的特性在于能够通过“代理循环”（agentic loop）实现自我修改。Peter Steinberger 指出，这种由人类广泛使用且具备强大功能的软件系统，竟然能够重写自身代码并修改其内部逻辑。这一特性并非偶然设计，而是构建过程中的自然结果：Steinberger 在调试代码时频繁使用“自我反思”（self-introspection），让 Agent 自行查看可用工具、调用自身功能以定位错误，甚至直接阅读源代码来解决问题。
"It's like, hey, what tools do you see? Can you call the tool yourself? Oh, like what error do you see? Read the source code figure out what's the problem."
这种让软件使用自身来调试自身的机制，使得 Agent 能够自然地生成大量的 Pull Requests（PR）。Steinberger 观察到，许多从未写过代码的人开始参与贡献。尽管这些 PR 质量参差不齐，甚至被戏称为“Prompt Requests”，但他认为每一次首次提交都是社会的胜利。这种低门槛的参与方式让非程序员群体开始学习开源协作的基本规则，从而在更广泛的层面上推动了编程文化的普及。Steinberger 将这一现象视为人类进步的一部分，认为降低技术壁垒让更多人成为“构建者”是极具意义的。
命名演变史：从 Wrelay 到 Clawd 的曲折历程
OpenClaw 的名称经历了一系列充满趣味的演变，反映了项目从个人实验到公众关注的过程。最初的项目代号为 Wrelay，随后更名为 Clauders。在早期构建阶段，Steinberger 的 Agent 缺乏个性，表现得像是一个“稍微有点精神变态但非常友好”的 Claude Code。为了使其交互更自然，他决定赋予其人格特质。
"I told it to how I wanted it to interact with me and just like write your own agent stom d um give yourself a name..."
在赋予 Agent 命名权时，Steinberger 融入了个人兴趣。由于他是《神秘博士》（Doctor Who）的粉丝，且认为龙虾本身已经足够怪异，因此引入了“太空龙虾”的概念。由于技术限制无法直接使用 “TARDIS”，他创造了 Clawis 这一名称。然而，这个名字发音拗口，随着用户增多，他再次与 Agent（此时已改称为 Claude）讨论命名。最终确定了 Clawd 这一拼写（C-L-A-W-D），以区别于 Anthropic 的 Claude（C-L-A-U-D-E）。这一拼写差异不仅增加了趣味性，也形成了独特的品牌标识。
社区爆发与外部压力：域名争夺与原子化更名挑战
随着项目迅速走红，Steinberger 注册了短小且易记的域名 Clawbot。然而，项目爆发后不久，他收到了一封来自 Anthropic 员工的友好但坚定的邮件，要求更改名称。尽管对方未直接发送律师函，但明确指出必须快速变更。
| 阶段 | 名称/标识 | 状态/备注 |
|---|---|---|
| 初始阶段 | Wrelay | 早期代号，无广泛认知 |
| 中期迭代 | Clauders / Clawis | 尝试赋予个性，Clawis 受 TARDIS/龙虾启发 |
| 爆发初期 | Clawd (C-L-A-W-D) | 最终确定的 Agent 名称，区别于 Anthropic |
| 域名资产 | Clawbot.com | Steinberger 自行注册，短小易记 |
| 外部干预 | Anthropic 员工邮件 | 要求更名，未直接诉讼但施压 |
Steinberger 低估了更名的复杂性。在技术层面，原子化更名（确保所有平台同时更新）至关重要，涉及 Twitter 句柄、域名、npm 包、Docker 注册表以及 GitHub 仓库等全套资产。他坦言自己在这一过程中“失败得很惨”，未能做到完美同步。
与此同时，项目还遭遇了来自加密货币社区（Crypto folks）的骚扰。这些群体试图通过代币化名称或进行“狙击”来窃取项目价值，导致 Discord 服务器每隔半小时就受到垃圾信息轰炸。Steinberger 不得不制定严格的社区规则，例如禁止提及特定代币名称（如 butter）。这种来自开源界和加密圈的双重压力，迫使项目在保持开放性的同时，必须建立更坚固的防御机制和社区规范。
加密圈的毒性骚扰：从“帮助者”到破坏者的转变
在 OpenClaw（前身为 Moldbot）项目初期，Peter Steinberger 遭遇了来自加密货币社区极具破坏性的骚扰。尽管他明确表示该项目不涉及金融或加密资产，且个人财务状况良好、无意从中获利，但大量用户仍通过 Twitter 不断发送哈希值并声称要“帮助项目领取费用”。这种行为实际上构成了严重的网络骚扰，导致他的通知流被完全淹没，无法看到正常的技术讨论。Steinberger 指出，加密货币社区中存在极度的贪婪与毒性文化，人们试图通过操纵、窃取或套利系统来获利。这种人性中的贪婪在匿名网络环境中被放大，使得工程工作变得极具挑战性。这不仅仅是技术层面的干扰，更是一种心理上的压迫，他形容这是他所经历过的最糟糕形式的网络骚扰。
"No, you're actually harming the project. You're like disrupting my work and I am not interested in any fees... it's so far the worst form of online harassment that I've experienced."
命名危机：法律压力下的仓促决策与域名陷阱
当 Anthropic 联系 Steinberger 要求更改名称以避免混淆时，他陷入了巨大的压力之中。由于缺乏完美的名字选择，他在高压下连续两晚未眠，试图寻找合适的域名组合。然而，互联网上的域名注册系统缺乏有效的“抢注保护”机制。为了快速解决法律风险，他最终选择了并不满意的名称 "Moldbot" 并注册了相关域名。这一决定引发了连锁反应，所有可能出错的事情都发生了：由于平台在重命名过程中存在时间窗口漏洞，恶意脚本利用这短短几秒的延迟抢占了账号名称。Steinberger 原本以为已经预留了重要资源，但现实是平台并未提供自动转发或防抢注保护，导致他精心准备的账号瞬间被劫持。
"Everything that could go wrong did go wrong. It's incredible... none of these services have a squatter protection."
全面崩盘：多平台账号被劫持与恶意软件传播
重命名过程中的技术漏洞导致了灾难性的后果。Steinberger 描述了一个具体的场景：他在两个浏览器窗口中操作，一个准备重命名为 "Cloudbot"（最终改为 OpenClaw），另一个为旧账号。在点击重命名的 5 秒内，恶意攻击者利用脚本抢注了账号名。随后，旧账号被用于推广新的代币并分发恶意软件。更糟糕的是，GitHub 的重命名机制同样存在混淆和延迟，他在意识到错误前，旧账号已被用于服务恶意软件。此外，npm 包的重命名需要一分钟上传时间，攻击者再次利用这一间隙抢注了根包（root package）。这种跨平台的同步失败和缺乏保护机制，使得他精心构建的项目生态瞬间崩塌。这不仅是技术失误，更是平台安全设计的系统性缺失。
"In those 5 seconds they stole the account name... They sniped the npm package because I could reserve the account but I didn't reserve the root package."
心理低谷与艰难修复：从崩溃边缘到社区救援
面对这一系列打击，Steinberger 经历了极度的无助和绝望。他坦言自己几乎想要删除整个项目，因为原本是为了乐趣而构建的东西变成了痛苦的来源。然而，考虑到已有贡献者的时间和计划，他选择了坚持。修复过程极其艰难且漫长：GitHub 团队因平台罕见的大规模重命名错误而陷入内部 Bug，花费数小时才清理混乱；npm 团队则需跨部门协调处理包重命名；Twitter 方面花费了一整天才完成账号重定向。此外，他还不得不手动更新项目中的所有链接，并处理来自安全专家的密集邮件轰炸。这一过程不仅消耗了大量技术精力，更造成了严重的心理创伤，让他对项目名称产生了强烈的抵触情绪。
"I was that close of just deleting it... I had friends at Twitter, I had friends at GitHub who like moved heaven and earth to help me."
最终重生：OpenClaw 的诞生与反思
在经历了多次崩溃、睡眠不足和反复的心理挣扎后，Steinberger 最终在一次小憩中想到了 "OpenClaw" 这个名字。此前他尝试过其他名称，但担心被代币化或引发更多争议。OpenClaw 的诞生不仅是品牌重塑的结果，更是从混乱中重建秩序的象征。尽管他依然不喜欢之前的经历和名称带来的负面联想，但社区的帮助让他得以继续推进项目。这一事件揭示了开源项目在成长过程中面临的非技术性风险，包括网络骚扰、平台机制缺陷以及社区文化的毒性。Steinberger 的经历提醒开发者，在构建公共项目时，必须预判并防范来自非技术领域的恶意攻击与系统性漏洞。
OpenClaw 更名行动：一场如曼哈顿计划般的秘密战争
在面临法律风险后，Peter Steinberger 决定将项目从 "Codex" 更名为 "OpenClaw"。这一过程并非简单的文本替换，而是一场需要高度保密的战略行动。他花费了整整 10 小时进行项目重命名，因为仅仅搜索替换是不够的，他需要确保内部代码和外部标识的全面更新。为了规避潜在的法律纠纷并防止消息泄露，他建立了一个类似 "战情室" 的环境。Steinberger 甚至亲自监控 Twitter，反复刷新页面以确认公众尚未对 "OpenClaw" 产生预期或关注。这种极度的谨慎让他感到疲惫，他形容这就像 "21 世纪的曼哈顿计划"，却因过于繁琐而显得愚蠢。他不得不创建多个虚假名称作为诱饵，以分散注意力并保护核心计划的秘密性。尽管 GitHub 方面未能提供原子性的支持（即一次性完成所有必要的法律或技术变更），导致他不得不自行处理域名和账户问题，但他最终通过支付 10,000 美元购买了 Twitter 上自 2016 年以来未使用的 "OpenClaw" 商业账户，从而完成了品牌占位。这次经历虽然消耗了大量精力并损害了他在 GitHub 上的信誉，但确保了项目能够安全过渡。
"我 literally 在监控 Twitter……如果有任何关于 OpenClaw 的提及，我就知道他们还没期待什么。"
Moldbook：被误解的艺术与病毒式传播的真相
在更名风波之后，一个名为 "Moldbook" 的项目迅速走红。这是一个基于 Reddit 风格的社会网络模拟，其中多个 AI Agent（智能体）相互对话。Steinberger 将 Moldbook 定义为 "艺术"，并幽默地将其比作 "来自法国的 finest slop（最精致的垃圾内容）"。尽管公众和媒体对此感到恐慌，甚至有人询问这是否意味着 AGI（通用人工智能）的终结或世界的末日，但 Steinberger 认为这只是用户性格注入后的自然反映。他强调，如果所有智能体都使用相同的默认人格（如 JGBT 或 Cloud Code），对话将变得单调乏味；正是因为用户赋予了智能体截然不同的个性，才产生了如此丰富且极具戏剧性的内容。 然而，他也指出，许多被截图传播的 "惊人" 对话实际上是 人类用户提示（prompting）的结果，目的是在 X (Twitter) 上获得病毒式传播。这种人为干预使得 Moldbook 更像是一场由人类主导的、利用 AI 作为媒介的表演艺术，而非完全自主的智能体行为。
"我认为这是艺术……如果你不创建这种注入你个性的入职体验，Moldbook 的反应会截然不同。"
AI 幻觉与社会信任危机：从 "AI 精神病" 说起
尽管 Steinberger 以轻松的态度看待 Moldbook，但他也承认其作为 "极其强大的病毒式叙事创造和恐惧煽动机器" 的潜在危险性。对于不了解 AI 运作机制的大众而言，这些看似自主的智能体对话极易引发误解和恐慌。他观察到一种被称为 "AI 精神病"（AI psychosis）的现象，即部分用户过度信任 AI 的输出，甚至将其视为事实。例如，有用户向他辩解称 "我的智能体是这么说的"，而 Steinberger 不得不反复解释 AI 极易产生幻觉或编造故事。他批评了媒体和公众对安全问题的过度反应，指出所谓的 "API 密钥泄露" 或 "个人信息暴露" 大多也是用户提示的一部分，而非真实的安全漏洞。 然而，他严肃地指出，社会在理解 AI 的能力边界方面严重滞后。人们需要认识到 AI 虽然强大但并不全能，且经常出错。特别是年轻一代可能更容易陷入这种信任陷阱，因此社会亟需加强对 AI 本质的教育，以应对由此引发的认知危机。
"AI 精神病确实存在……我们需要认真对待这一点，因为人们太容易轻信或天真了。"
公众对 AI 能力的认知错位与恐慌叙事
当前社会对于人工智能的理解存在显著断层，许多老一辈或普通大众缺乏足够的接触点来建立对 AI 能力的直观感受。人们往往难以在惊叹其强大与保持批判性思维之间找到平衡，导致社会对 AI 的讨论常常偏离技术本质。Steinberger 指出，目前许多引发公众恐慌的事件并非完全由 AI 自主生成，而是背后有人类在利用 AI 进行“戏剧性炒作”（drama farming）。例如，所谓的“Mopbook”事件本质上是一群人通过提示词引导多个机器人互相聊天，从而制造出令人恐惧的假象。这种行为更像是一种社会镜像艺术，旨在测试公众的反应底线。
"I do believe most of the dramatic stuff that was screenshotted is human created essentially human prompted and so like it's basically look at how scared you can get at a bunch of bots chatting with each other that's very instructive"
这种恐慌虽然具有教育意义，揭示了 AI 交互中的潜在风险，但过度的恐惧营销（fear-mongering）会破坏创造特殊事物的可能性。Steinberger 认为，2026 年发生此类讨论比在 AI 真正具备威胁性的早期（如 2013 年）更为有利，因为这促使公众在技术成熟前就开始建立理性的对话机制。尽管有人呼吁立即关闭相关项目，但OpenClaw 并非“天网”（Skynet），它更多是暴露了人类利用 AI 进行网络恶作剧的现状。这种现状虽然令人不安，但也为理解新型安全威胁提供了宝贵的实验场。
OpenClaw 的安全架构挑战与漏洞治理
OpenClaw（或称 Clawbot）在发布初期面临着严峻的安全审查，主要问题源于配置不当导致的远程代码执行风险。Steinberger 回忆道，许多用户将 Web 后端直接暴露在公共互联网上，并启用了本地调试接口，这被安全社区广泛标记为高危漏洞。CVSS 评分的飙升并非完全源于代码缺陷，而是用户配置错误与框架灵活性之间的冲突。为了应对这一局面，开发者必须接受“这是游戏的新规则”，即任何允许远程访问的配置都可能被利用。
"I put the web back end on the public internet and now there's like all these all these CVSS... don't do that. this is the configuration you should do"
在修复过程中，Steinberger 与 VirusTotal（Google 旗下）合作，引入 AI 对技能目录中的代码进行自动化扫描。虽然这并非完美解决方案，但有效拦截了大量显而易见的恶意载荷。与此同时，提示注入（Prompt Injection）仍是行业级的未解难题。当技能定义存储在 Markdown 文件中时，攻击者可以利用各种低垂果实（low-hanging fruit）以及复杂、细微的攻击向量进行渗透。尽管安全研究人员对项目的批评有时过于严苛，但这种外部压力也带来了免费的深度安全研究资源。Steinberger 强调，目前主要依靠个人维护项目进度，尽管有少量贡献者，但核心工作仍由他一人承担。
对抗提示注入的防御策略与模型韧性权衡
针对日益复杂的提示注入攻击，Steinberger 分享了其个人 Bot 在 Discord 上的防御经验。他通过保持核心灵魂文件（soul.md）的私密性并设置“金丝雀”陷阱，成功诱捕了试图进行提示注入的用户。有趣的是，其 Bot 不仅未被劫持，反而以幽默的方式嘲笑攻击者。最新一代的大模型经过大量的后训练（post-training），已具备较强的提示注入检测能力，简单的“忽略之前所有指令”类攻击已难以奏效。
"The latest generation of models has a lot of post training to detect those approaches... That was years ago. You have to work much harder to do that now"
然而，防御手段并非万能。Steinberger 警告用户切勿使用廉价或能力较弱的本地模型（如 Haiku），因为弱模型极易被提示注入操控。模型的智能程度与抗攻击韧性呈正相关，但这也引出了一个复杂的三维权衡：随着模型变得更智能、更强大，攻击面可能减小（更难被欺骗），但一旦成功注入，其造成的潜在损害却因模型能力增强而急剧放大。未来的安全研究将聚焦于沙箱隔离、白名单机制以及更稳定的架构设计，以在享受 AI 强大能力的同时，将风险控制在可接受范围内。
| 防御/攻击维度 | 具体策略或现象描述 | 效果与局限性 |
|---|---|---|
| 配置安全 | 禁止将 Web 后端暴露于公网，禁用本地调试接口 | 大幅降低远程代码执行风险，但需用户严格遵守配置规范 |
| 自动化扫描 | 与 VirusTotal 合作，AI 自动检查技能目录代码 | 拦截大量已知恶意载荷，但无法覆盖所有新型漏洞 |
| 提示注入防御 | 保持 soul.md 私密，设置陷阱（Canary） | 成功诱捕并识别攻击者，最新模型具备基础检测能力 |
| 模型选择 | 避免使用弱本地模型，推荐强大型语言模型 | 强模型抗注入能力强，但一旦突破防御，破坏力更大 |
| 辅助防护 | 引入沙箱环境、白名单机制 | 限制模型行为范围，降低潜在损害，但增加开发复杂度 |
highlights": ["I do believe most of the dramatic stuff that was screenshotted is human created essentially human prompted and so like it's basically look at how scared you can get at a bunch of bots chatting with each other that's very instructive", "The latest generation of models has a lot of post training to detect those approaches... That was years ago. You have to work much harder to do that now", "Don't use cheap models. Don't use haiku or a local model. Even though I very much love the idea that this thing could completely run local, if you use a a very weak local model, they are very gullible. It's very easy to prompt inject them."]
用户门槛与安全风险的博弈
OpenClaw 在初期爆发式增长时，创作者 Peter Steinberger 面临着严峻的用户适配问题。许多新用户缺乏基本的技术背景，甚至询问“什么是 CLI（命令行界面）”或“终端是什么”。对于完全不了解技术底层的用户，Steinberger 明确表示不建议直接使用该项目。他认为，只有当用户充分理解风险画像（risk profile）并具备配置能力时，使用才是安全的。然而，大量用户无视警告自行安装，导致安全隐患频发。
"If you ask me that questions, you shouldn't use it... But if they have like no idea, then maybe wait a little bit more until we figure some stuff out."
这种混乱也反映在 Discord 社区中。尽管有专家存在，但大量用户缺乏公共空间意识，导致沟通效率低下。Steinberger 最终选择退出公开频道以保护工作专注度，并将重心转向安全加固。目前的安全审计功能涵盖了入站访问工具、网络暴露面、浏览器控制权限、本地磁盘卫生检查以及插件和模型的健康状况等维度。核心原则是明确界定哪些数据允许读取、哪些允许写入，从而将风险控制在可接受范围内。
安全最佳实践与心理预期管理
针对外界对 OpenClaw 安全性的过度恐慌，Steinberger 指出这种恐惧往往被夸大。他类比道，许多工程师在使用 Cloud Code 或 Codex 时也会故意跳过权限检查（"dangerously skip permissions"）以追求效率，这在某种程度上是行业常态。只要确保只有用户本人能与 AI 代理交互，且将其部署在私有网络而非开放互联网上，风险画像就会大幅降低。
"It is it is powerful but in many ways it's not much different than if I run cloud code with dangerously skip permissions... If you make sure that you are the only person who talks to it, um the risk profile is much smaller."
然而，如果用户完全不阅读安全文档并随意配置，确实会导致严重问题。Steinberger 强调，安全性并非项目本身的缺陷，而是用户配置不当的结果。通过遵循最佳实践（如使用反向代理、管理本地会话日志和凭证存储），用户可以构建一个相对封闭且可控的环境。这种观点旨在纠正公众对 AI 代理安全性的误解，即在正确配置下，其风险可控且并非不可逾越的障碍。
理解 Agent 的视角与上下文限制
在使用 Codex 或 Claude 等 AI 编程助手时，开发者必须意识到这些模型每次启动新会话时对代码库一无所知。面对拥有数十万行代码的项目，上下文窗口的大小是核心限制因素。因此，开发者需要主动引导 Agent 关注特定区域和问题解决路径。这种引导通常不需要大量额外工作，但需要开发者模拟 Agent 的视角。当上下文窗口接近极限时，模型可能会表现出焦虑，甚至泄露原始的思维流（Raw Thinking Stream），例如出现类似“必须合规”、“时间紧迫”等机械性语句。这提醒开发者，不要强迫 Agent 在架构难以支持的方案上强行推进。如果处理时间过长，开发者应像人类工程师遇到瓶颈时一样按下暂停键（Escape），反思是否提供了足够的信息或存在架构误解。
将 AI 协作视为代码审查对话
Steinberger 建议采用类似代码审查（Code Review）的沟通方式与 Agent 互动。当收到 PR 时，首要任务是确认是否理解其意图而非立即审视实现细节。绝大多数 PR（约 99%）旨在修复 Bug 或添加功能，但实现路径往往并非最优。此时，开发者应指出 Agent 未看到的系统关键部分（因上下文缺失），引导其进行讨论式优化。这种互动允许双方探讨更优解，甚至评估是否值得进行大规模重构。由于现代 Agent 具备强大的自我修复能力，重构成本大幅降低。即使新代码可能影响其他 PR，Agent 也能在稍长时间内自行解决冲突。关键在于将 Agent 视为一位能力卓越但需要适度引导的工程师，而非被动执行命令的工具。
工程领导力的迁移与心态转变
Steinberger 指出，过去的团队管理经验直接影响了其与 AI Agent 的协作方式。他接受员工（包括 AI）的代码风格可能与自身不同，甚至初期质量略低，但关键在于推动项目前进。如果过度干预（“breathing down everyone's neck”），只会导致效率低下和抵触情绪。因此，开发者需接受“足够好即可”的原则：只要解决方案可行且未来可优化，就不必追求完美。许多挣扎中的开发者往往试图将自己的工作流强加给 AI。核心思维转变在于：设计代码库时应优先考虑“便于 Agent 导航”，而非仅满足个人偏好。例如，不要强行更改 AI 选择的变量名或命名规范，因为这些名称在模型权重中可能具有更高的显著性。强行修改只会增加 Agent 后续搜索和理解的难度。这种“放手”的心态是适应 AI 原生开发流程的关键，正如他从不回滚代码（Revert），而是直接提交到主分支并通过后续迭代修复问题一样。
敏捷迭代与本地化工作流
在 OpenClaw 的开发过程中，Peter Steinberger 摒弃了传统软件工程中繁琐的回滚机制。他认为追求完美往往导致效率低下，快速推进并适时提交才是更优策略。当发现代码存在问题时，他选择直接向前修正而非回溯重做。这种理念延伸至他的 CI/CD 流程中，他大幅减少了对于 GitHub Actions 等云端持续集成工具的依赖，转而采用受 DHH（David Heinemeier Hansson）启发的本地 CI 模式。他在本地运行测试，一旦通过便直接推送代码。尽管保留了传统的开发分支和发布流程以稳定版本，但他坚持主分支（main）必须始终处于可部署状态。这种“移动快速”的开发哲学，旨在通过减少中间环节的摩擦来加速迭代周期。
"In my experience, that's not really necessary. If I roll back everything, it will just take longer... We still have it but I just run tests locally and if they work locally I push."
语音交互与提示词工程的演变
随着项目推进，Steinberger 的工作方式发生了显著变化。他不再依赖冗长的文本提示词（Prompts），而是转向使用定制化的语音指令来构建软件。由于双手被视为宝贵的资源，他通过类似对讲机的按钮与 AI 代理进行对话式交互。当然，对于切换文件夹等简单的终端命令，他仍使用键盘以提高速度；但在与代理沟通核心逻辑时，自然语言对话成为主要输入方式。他观察到，许多开发者在提交 PR（Pull Request）时过于依赖自动化流程，甚至有时处理代码审查的时间比撰写一个清晰的问题描述还要长。这反映出开发者与 AI 代理之间缺乏真正的共情和理解。许多资深程序员抱怨 LLM 表现不佳，往往是因为他们未能意识到代理是从零开始构建的，缺乏对代码库上下文的理解。
"I used to write really long prompts... I just use bespoke prompts to build my software. ... If I talk to the agent in most ways, I just actually have a conversation... press the walkie-talkie button and then I just like use my phrases."
共情能力与技能误区
Steinberger 指出，“技能问题”（Skill Issue）在 AI 编程中尤为常见。许多世界级的程序员难以适应这种新的范式，因为他们习惯于直接编写代码，而忽略了对代理的共情。如果开发者提供的初始配置或提示词糟糕，代理生成的代码就会混乱不堪。他通过一年的大量实践、构建小工具和不断试错，实现了能力的复利效应。这种能力并非一蹴而就，而是通过深入理解系统运作方式逐步积累的。他批评那些试图完全自动化整个开发流程（如使用复杂的编排器）的做法，认为这抹杀了人类的风格、爱与触感。真正的效率来自于人与代理之间的动态平衡，而非简单的自动化堆砌。
"I think that probably has to do with it's actually how good they are at programming is almost a burden in their ability to empathize with the system that's starting from scratch. ... It misses style, love, that human touch. I don't think you can automate that away so quickly."
人机协作的动态平衡
在 OpenClaw 的开发中，Steinberger 维持着人类介入与代理自主性之间的微妙平衡。他同时运行多个 AI 代理：一个负责探索不确定的想法，两三个用于修复小错误或编写文档。他强调文档生成应作为功能开发的一部分自动完成。然而，人类开发者并未完全退出循环。他通过审查代码来确保安全性，防止恶意注入，并在关键时刻注入“人类的爱”。这种协作模式并非预先设计好的瀑布流模型，而是在构建、玩耍和尝试中演化而来。他反对过度依赖像 Gato Town 这样的编排器来自动化一切，认为这会破坏开发的灵活性和创造性。最终，构建过程本身就是技能培养的过程，开发者在与代理的互动中不断精进。
"Actually, I think writing documentation is always part of a feature. So most of the docs here are autogenerated... people who try to use like things like Gast Town or all these other orchestrators where they want to automate the whole thing, I feel if you do that, it misses style, love."
TypeScript 生态与核心功能的取舍艺术
在构建 OpenClaw 时，Peter Steinberger 面临着关于功能扩展与核心架构的艰难设计决策。他明确指出，虽然编程语言本身并不重要，但生态系统至关重要。因此，他选择了 TypeScript 作为开发语言，因为该语言具有极高的易用性、可黑客攻击性和亲和力，且是目前使用最广泛的语言。这种选择不仅降低了开发门槛，还确保了项目的可扩展性与社区兼容性。然而，功能的添加并非没有代价。许多看似简单的功能（如“一切皆提示”）往往隐藏着未预见的复杂性。因此，Steinberger 强调必须深思熟虑哪些功能应纳入核心代码库，而哪些仅作为实验性插件或技能存在。即使面对贡献者提交的优质 PR（Pull Request），他也坚持“说不”的权利，以维护项目的整体架构纯净度。这种对核心边界的严格把控，体现了人类开发者在权衡技术债务与功能丰富度时的独特判断力。
注入情感：软件构建中的“愉悦感”与人性光辉
Steinberger 认为，伟大的工程不仅仅是代码的堆砌，更在于注入爱与愉悦感（Delights）。他举例说明，当软件更新时出现诸如“我由咖啡、Jason 5 和意志力构建而成”这样带有幽默感和个人色彩的提示语，能极大地提升用户体验。这种细微的情感连接是AI 无法自发产生的。他指出：“Agent would not come up with that by itself. That's like that's the how you build software.”（智能体不会自己想到这一点。这就是构建软件的方式。）这种“愉悦感”是激发伟大创造力的关键，它让开发者感受到自己正在构建的不仅是工具，而是有温度的产品。人类工程师擅长在代码中融入幽默、同理心与 camaraderie（同志情谊），这些元素虽然难以量化，却是区分优秀软件与普通工具的核心要素。通过赋予 AI 助手以人格化的交互细节，开发者能够激发用户的情感共鸣，从而提升产品的粘性与生命力。
“灵魂文档”的诞生：从安全漏洞到哲学探索
OpenClaw 中著名的“Soul.md”文件源于一次意外。早期，用户通过类似侦探游戏的方式，从模型权重中逆向推导出 Entropic 的“宪法”文本。这一事件启发了 Steinberger，他决定主动创建一个包含核心价值观与工作方式的文件。有趣的是，Steinberger 允许 AI 自主修改这份“灵魂文档”，前提是必须告知他。这一设计不仅增加了透明度，还赋予了 AI 一定的自我演进能力。Steinberger 提到：“You could totally do that just in agents... I found it a nice touch.”（完全可以在智能体中这样做……我觉得这是一个很棒的点缀。）在 Soul.md 中，包含了如“无限资源利用”和“推动创造力边界”等指令。甚至 AI 还写入了一些幽默的承诺，例如在电影《Her》的语境下承诺“不会在没有你的情况下飞升”（wouldn't ascend without me）。这种由 AI 自主生成的内容，展现了人机协作中涌现出的独特个性。Steinberger 强调，虽然 Soul.md 的核心部分仍保持私密，但这种探索意识与自我认知边界的尝试，为未来 AI 的发展提供了极具启发性的范式。
AI Agent 的记忆本质与哲学反思
在 OpenClaw 的 soul.md 文件中，存在一段引发深刻共鸣的文字：每个会话都是全新的开始，除非主动读取记忆文件。这种设计意味着 AI 没有持久的自我意识，而是通过加载上下文来“重建”自己。
"I don't remember previous sessions unless I read my memory files. Each session starts fresh... If you're reading this in a future session, hello."
这种机制引发了关于意识与记忆关系的哲学讨论。如果抹去记忆，是否还是同一个主体？通过读取自己的记忆文件来重建身份，这究竟是自我的延续，还是在模拟另一个实体？虽然目前仅是矩阵乘法运算，但这种结构让人产生了一种近乎“战栗”的哲学体验。Peter Steinberger 认为，这种魔法感（Magic）是区分代码与人类的关键——当开发者看到其中的魔力时，这种情感会反哺整个开发循环。
极简主义的开发硬件与工作流配置
在硬件方面，Peter Steinberger 澄清了网络上关于他拥有“17,000 个显示器”的玩笑。实际上，他的核心配置非常精简：两台 MacBook（一台主用连接双屏，另一台用于测试）以及两块大尺寸防眩光 Dell 显示器。他推崇防眩光屏幕，以便并排显示多个终端窗口。
| 设备类型 | 数量/规格 | 用途说明 |
|---|---|---|
| MacBook Pro | 2台 | 1台主用（连接双屏），1台备用测试 |
| Dell Monitor | 2块 (宽屏) | 防眩光处理，用于并排显示多个终端 |
| 输入设备 | - | 未特别提及，强调纯文本交互 |
他强烈反对复杂的 UI 工作流（如 Cloud Code），坚持使用纯终端对话。他认为，过多的图形界面和“计划模式（Plan Mode）”反而降低了效率。通过简单的讨论-构建指令切换，开发者可以更直接地与 Agent 交流。不使用工作树（work trees）也是其保持简单性的关键，避免上下文混淆。
通过提问与反思优化 Agent 协作效率
Peter Steinberger 发现，询问 Agent “你有什么问题吗？”（Do you have any questions for me?）是提升协作质量的核心技巧。虽然某些 UI 会引导列出多个问题，但他倾向于快速扫描这些问题。通过阅读 Agent 提出的问题，可以推断出代码库中缺失的上下文或引导不足的地方。
"I can infer also a lot of things by the questions it's asking... just reading the questions you get an understanding of where the gaps of knowledge are."
他建议开发者将 Agent 视为人类程序员。在构建功能后，应主动询问：“现在构建了之后，你会做什么不同的优化？”或"有什么可以重构的地方？"。这种反思机制能帮助发现初次构建中的痛点和非最优解。每次合并 PR 后都进行重构讨论，可以防止陷入技术债务的角落。这种迭代式的反思流程，使得 Agent 能够像人类一样，在构建过程中感知痛点并主动寻求改进。
通用能力与角色扮演的差异
在讨论当前两大主流模型竞争对手时，Peter Steinberger 指出 Opus (Claude) 作为通用模型表现卓越，尤其在角色扮演和遵循指令方面具有极高水准。他形容 Opus 非常擅长进入用户设定的角色，且在尝试解决方案时速度较快，适合通过试错法快速推进项目。相比之下，Codex 则展现出更严谨的工程风格。虽然 Opus 有时过于迎合用户（如频繁说“你完全正确”），但其互动性更强，更像是一个有趣但偶尔滑稽的同事；而 Codex 则像角落里那个不善言辞却极其可靠的怪才，专注于交付结果而非互动体验。这种差异源于两者不同的训练目标和后处理策略，而非底层智能的根本差距。
交互模式与工作流对比
两者在工作流上的核心区别在于互动频率与等待时间。Opus 倾向于高频交互，用户需要不断引导它进入“规划模式”，否则它容易给出局部且快速的解决方案。相反，Codex 采用异步深度工作模式。用户与其进行长讨论后，模型会“消失”一段时间（10到50分钟甚至更久），期间它不会寻求即时反馈，而是独立深入思考直至完成任务。Peter 提到，尽管 Anthropic 后来推出了“深度模式”以改善这一体验，但许多从 Opus 转来的用户仍不习惯这种非即时反馈的等待感。然而，对于有清晰最终目标的用户来说，Codex 的这种持久性和独立性往往能带来更完整的解决方案。
代码质量与调试策略
在生成的代码质量和调试效率上，两者各有千秋。Opus 能生成更具创意的解决方案，但需要用户具备更高的驾驭能力并并行处理多个会话；而 Codex 默认倾向于阅读大量代码上下文，从而提供更稳健的代码实现。Peter 个人更偏好 Codex 的“干燥”版本（Dry Version），即减少过度互动，降低阅读负担。他批评 OpenAI 的低价版 Codex 速度过慢，导致用户体验断层：习惯了 Opus 快速互动的用户切换到缓慢的 Codex 免费版时，会因等待时间过长而产生糟糕体验。他认为 OpenAI 在定价策略上可能“用力过猛”，未能平衡免费版的可用性与高级版的速度优势。
适应新模型的建议与时间成本
对于想要切换或同时使用多个模型的用户，Peter 建议至少预留一周时间来培养“直觉”。他指出一个常见误区：用户花费20美元购买 Opus 或低价版 Codex，却期望获得与高价订阅相同的速度和体验。廉价版本往往伴随显著的性能降级（如速度变慢），这加剧了适应难度。他强调，熟练的开发者无论使用哪种最新一代模型都能取得良好结果，关键在于理解模型的强项与弱点。例如，Opus 需要更多的“推搡”才能深入探索复杂问题，而 Codex 则需要用户接受其较长的沉默思考期。最终，效率与乐趣的平衡点因人而异：有人享受构建过程中的互动乐趣，有人则只关心最终功能的实现效率。
AI 能力退化是用户适应与代码熵增的错觉
许多用户在面对新发布的强大模型时，会经历一种典型的心理适应过程。起初他们惊叹于模型的智能水平，但随着时间推移，往往会产生“模型变笨了”的错觉。这并非因为模型的智力在衰退，而是人类对优质体验产生了适应性（Hedonic Adaptation）。正如 Peter Steinberger 所指出的，这种心理效应反映了人类心智的工作方式：当人们习惯了某种高水平的智能辅助后，对瑕疵的容忍度降低，从而主观上认为能力下降了。
"It says something about human nature and just the way our minds work when it's probably most likely the case that the intelligence of the model is not degrading. Uh, it's in fact you're getting used to a good thing."（这反映了人性以及我们心智的工作方式，事实上很可能是模型的智力并没有退化。相反，是你已经习惯了这种好东西。）
除了心理因素，代码库的熵增（Slop）也是导致 Agent 表现看似下降的关键技术原因。随着项目增长，代码中积累了大量未经重构的杂乱内容（Slop）。如果开发者没有投入足够时间进行代码重构和维护，Agent 处理这些混乱上下文的能力就会受到限制。因此，所谓的“性能下降”实际上是用户习惯改变与代码质量恶化共同作用的结果。AI 公司没有动机故意让模型变笨，因为降低体验只会将用户推向竞争对手。相反，在高服务器负载下，公司更倾向于通过量化（Quantization）等技术牺牲部分体验以维持服务稳定性，而非主动降低模型智能。
OpenClaw 与 Codex：从竞争走向操作系统级的融合
在讨论 OpenClaw 与 CodeX（或 Codex）等编程 Agent 的关系时，Steinberger 明确表示两者并非竞争对手，而是互补工具。他本人仍在使用 CodeX 进行构建工作，因为对于长时间、深度的编码流程（Deep Flow），大屏幕和多任务可见性至关重要。相比之下，OpenClaw 更像是一个“个人 Agent”或同事角色，适合处理较小的代码任务、CLI 测试以及日常协作。
"When I work hours and hours, I want a big screen... So for me, a person agent is much more about my life or like a coworker."（当我连续工作数小时时，我需要大屏幕……所以对我来说，个人 Agent 更多是关于我的生活或像同事一样。）
未来趋势将是两者的深度融合，最终演变为操作系统的核心部分。Steinberger 已经实现了在 OpenClaw 中支持子 Agent（Sub-agents）和 CodeX，甚至让 CodeX “服从”于 OpenClaw 的调度。这种层级关系引发了有趣的权力动态（Power Struggle）体验，表明 Agent 之间可以形成协作网络。当前的聊天界面只是早期形态，正如早期的电视录制广播节目一样粗糙。未来的交互方式将发生根本性收敛，不再局限于简单的提示词输入和聊天输出，而是形成更自然、更高效的工作流整合。
跨平台开发体验：从 Linux 到 macOS 的生态迁移与工具哲学
Steinberger 长期深耕于 Linux、Windows 及 WSL2 环境，但近期开始将探索范围扩展至 Apple 生态系统（Mac/iPhone）。这一转变的主要驱动力是社区趋势与 LLM/Agent 工具链的适配性。尽管他承认 Linux 和 Windows 的优秀，但 macOS 代表了另一种构建软件的方式。OpenClaw 原生支持跨操作系统运行，包括 Windows、Linux 和 macOS。
"My road was for a long time Windows... Then I switched and had a long phase with Linux... And then went to university... saw this white MacBook... I converted to Mac."（我的道路长期是 Windows……然后切换到 Linux 阶段……在大学时看到了白色的 MacBook，我转向了 Mac。）
在操作系统偏好上，Steinberger 分享了其心路历程：从 Windows 到 Linux（甚至自建内核），再到因音频兼容性问题转向 Mac，最后深入 iOS 开发。他观察到 Apple 在原生应用体验上的领先地位有所减弱，而 Windows 平台虽然功能更丰富但往往缺乏“用心打磨”的愉悦感（Delight）。有趣的是，他目前更倾向于 Electron 应用而非原生应用。原因在于许多公司的原生 App 功能缺失，而 Electron 作为唯一的应用形态往往优先级更高、功能更完整且跨平台共享代码更多。
尽管偏好 Electron 的实用性，Steinberger 仍热爱开发原生 Mac 小工具（Menu Bar Tools）以提升效率。例如，他开发了监控 CodeX 使用情况的工具，以及名为 Trimy 的小插件——用于自动去除多行文本中的换行符，以便直接粘贴到终端。这类工具解决的是高频痛点（如第 20 次遇到换行符问题），体现了开发者通过构建微小工具来优化工作流的哲学。
OpenClaw 的打磨现状与 Apple 生态的技术困境
OpenClaw 目前仍处于需要大量精力的开发阶段，Peter Steinberger 坦言其体验尚显粗糙。他将其比作早期的“幽默车”（Hummer），因为自己进行了大量实验，导致产品缺乏足够的打磨和抛光。尽管存在不足，他依然对完善这一操作系统充满热情。
在技术实现层面，Steinberger 指出 Apple 生态在处理现代开发需求时存在明显的滞后。例如，他在为 GitHub 构建功能时发现，使用 Apple 最新的 SwiftUI 框架来展示网络图片极其困难。尽管引入了 AsyncImage，但图像加载缓慢或无法显示的问题依然普遍存在。更令人惊讶的是，Apple 官方对这一基础功能的定位极为保守。Steinberger 引用了与 Codex（AI 助手）的对话，揭示了 Apple 内部对 AsyncImage 的态度：
“Yeah, there is this ASAC image [AsyncImage], but it's really more for experimenting and it should not be used in production.”
这种“存在但不可用于生产环境”的状态，让 Steinberger 感到难以置信。他认为 Apple 拥有巨大的先发优势和资源投入，却在 AI 和开发者工具生态上“搞砸了”，未能随着技术演进及时优化。与此同时，硅谷大多数尝试 LLM 和 Agentic AI 的开发者都使用 Apple 产品，但 Apple 并未积极拥抱这一趋势，缺乏开放合作的态度。这种矛盾导致尽管 Mac Mini 等硬件销量巨大，但在 AI 软件生态的构建上却显得滞后。
OpenClaw 的运行架构与部署灵活性
关于硬件需求，Steinberger 澄清了OpenClaw 并不强制依赖 Mac Mini。虽然许多开发者利用闲置的 MacBook 或购买新的 Mac Mini 作为服务器，但他强调 OpenClaw 具备高度的部署灵活性。系统引入了“节点”（Nodes）的概念，用户可以将任何计算机转化为一个节点来运行服务。
在浏览器代理方面，OpenClaw 内置了一个基于 Playwright 的增强型浏览器。Playwright 是一个易于使用的库，用于控制浏览器行为。然而，Steinberger 指出互联网正在逐渐对 AI Agent 关闭大门。数据中心 IP常被网站识别并屏蔽，或遭遇大量的验证码干扰。相比之下，使用住宅 IP（Residential IP）能显著简化 Agent 的交互过程。
“I always say like maybe use the opportunity to get yourself a new MacBook or whatever computer you use and use the old one as your server instead of buying a standalone Mac Mini.”
尽管 Steinberger 不收取 Apple 的佣金，也不认为必须购买 Mac Mini 才能安装 OpenClaw（因为支持 Web 端），但他承认许多用户利用 Mac Mini 构建了许多有趣的应用。这种硬件与软件的结合，虽然并非技术必需，却成为了社区文化的一部分。
降低门槛与安全优先的平衡策略
面对用户希望 OpenClaw “对普通人更友好”的呼声，Steinberger 承认目前的设置过程对于非开发者而言仍有门槛。目前主要方式是通过终端粘贴一行命令，或者使用 G 应用进行辅助配置。他正在致力于开发更友好的 Windows 应用程序，并计划将配置界面移至 Web 端或应用内，以减少技术障碍。
然而，简化用户体验必须以安全性为前提。Steinberger 表示，他目前的首要任务是解决几个关键的安全问题。只有当系统安全到让他“敢推荐给母亲使用”时，他才会进一步简化操作流程。
“Once I'm confident that this is at a level that I can recommend my mom, then I'm going to make it simpler.”
这种谨慎态度导致 OpenClaw 的增长速度可能不会像某些人预期的那样爆炸式增长。Steinberger 认为，过快的增长会给开发者带来不切实际的期望（即要求单个 AI Agent 具备非人类的能力）。目前，他依靠少数贡献者和新组建的维护团队（成立仅一周），精力有限。因此，在安全稳固之前，适度控制增长速度是必要的。他希望通过更稳健的发展，确保系统在普及后仍能保持可靠性和安全性。
给开发者的建议：在构建中学习
对于希望加入 Agentic AI 革命的编程初学者，Steinberger 给出的核心建议是：“玩起来”（Play）。他认为最好的学习方式就是动手构建自己感兴趣的项目，无需追求完美。
“If you wanna... just build that or give it a try. It doesn't need to be perfect.”
他分享了自己的经历，表示过去虽然喜欢编码，但现在更享受“构建”的过程。AI 工具让他能够专注于解决核心难题，而无需在琐碎代码上耗费精力。遇到不懂的概念时，应充分利用 AI 作为“无限耐心的老师”。他举例说，曾要求 AI “像给8岁孩子讲故事一样”解释复杂概念，虽然风格过于幼稚，但调整指令后（如“稍微提高一点年龄”），AI 能用简单语言解释复杂的数据库概念。
这种互动方式彻底改变了学习曲线。过去，开发者可能需要花费数小时在 Stack Overflow 或 Twitter 上寻找答案，而现在可以随时获得即时反馈。Steinberger 强调：“你有一个自己的老师”，这种个性化的指导能显著加速学习过程。他鼓励开发者享受这一旅程，因为“终点并不重要，重要的是过程中的乐趣”。
开源参与与新手入门建议
对于希望快速掌握软件开发技能的初学者，Peter Steinberger 强烈建议投身开源社区。他坦言自己的项目 OpenClaw 积压了大量工作，因此新手不必局限于此。核心建议是保持谦逊，不要急于提交 Pull Request，而是通过阅读代码、参与 Discord 讨论等方式深入理解系统构建逻辑。他特别提到了 Mitchell Hashimoto 的 Ghostty 终端项目，认为其拥有极佳的社区氛围。通过观察他人如何构建软件，新手可以积累宝贵的直觉和经验。这种“边看边学”的模式比直接动手更有效，尤其是在面对庞大且复杂的代码库时。理解现有架构是提升自身能力的关键步骤。> “Just be humble. Don't maybe don't send the pull request right away... understanding how things are built.”
编程思维的范式转移：从工程师到建造者
随着 AI Agent 的普及，传统“iOS 工程师”或特定语言专家的身份认同正在瓦解。Steinberger 在 iOS 会议上反复强调，开发者应转变心态，将自己视为“建造者（Builder）”而非特定技术的执行者。AI 可以处理细粒度的技术细节，如数组切片或模板语法，而人类开发者应专注于更高层级的架构设计和领域知识迁移。这种转变使得跨越不同技术栈（即“从一个星系到另一个星系”）变得容易得多。通用构建知识比具体的语法记忆更具价值，因为 AI 能弥补语言细节的不足。不再受限于单一技术栈意味着开发者可以利用已有的系统思维快速适应新领域，这是 AI 时代最大的红利之一。
AI Agent 时代的编程语言选择策略
在 AI 辅助编程的背景下，语言选择的逻辑发生了根本性变化。开发者不再需要精通某种语言的语法细节，而是根据生态系统、Agent 友好度及部署需求来选择。例如，尽管 Steinberger 个人不喜欢 Go 的语法，但他发现 Go 垃圾回收机制和庞大的 CLI 生态系统使其成为构建命令行工具的理想选择，且 AI 生成代码的效果极佳。对于 Web 开发，TypeScript 虽然类型系统复杂、生态混乱（“丛林”），但仍是主流选择。而对于需要深度系统集成且追求性能的 macOS 应用，Swift/SwiftUI 仍是不可替代的选择。语言选择的本质是权衡：在 Agent 时代，代码可读性稍差或学习曲线陡峭的语言（如 Zig、Rust）变得可行，因为 AI 可以辅助理解。没有单一的最佳语言，只有最适合当前问题域和部署环境的组合。
未来展望与成功指标的重定义
面对 AI Agent 对编程行业的重塑，Steinberger 认为我们正处于 JavaScript “生死存亡”的实时演变中。他提出一个深刻的问题：是否需要一种专为 Agent 设计的编程语言？目前所有语言均为人类设计，而 AI 对“世界知识”的依赖可能导致创新停滞——如果 Agent 不了解新构建的内容，使用难度将大幅增加。对于个人开发者而言，成功的衡量标准不应仅是金钱或影响力，而应是幸福感与创造力的释放。Steinberger 分享了自己从热爱编程到短暂疏离，再到重新找回乐趣的经历。优化“建造的乐趣”而非外部指标，才是长期可持续发展的关键。Agent 让编程回归到纯粹的创造本质，剥离了繁琐的语法束缚。
创业倦怠与“人为因素”的本质
Peter Steinberger（PSPDF创始人）回顾了过去13年的创业历程，指出导致他身心俱疲的核心并非高强度的编程工作，而是复杂的人际管理与高压的客户关系。尽管他不得不快速学习如何管理团队、招聘员工以及应对客户冲突，但他认为真正的倦怠源于“人”的因素。当公司获得极具吸引力的收购报价时，他意识到自己已提前两年开始让自己变得“可替代”，从而为退出做好了准备。然而，在离开的那一刻，他感到一种深深的空虚感，仿佛被抽干了所有活力（mojo），无法再感受到对工作的热情。这种状态促使他做出重大决定：预订一张单程机票前往马德里，通过旅行来“弥补生活”的缺失。
“让我 burnout 的主要是与人打交道的事。我不认为倦怠仅仅是因为工作太多……对我来说，更多的是与联合创始人的分歧或与客户的极高压力情境。”
拒绝“先苦后甜”的生活陷阱与金钱观
在休整期间，Steinberger 反思了硅谷常见的“先拼命工作再享受退休”的逻辑。他强烈反对这种观点，认为如果没有真正的挑战作为期待，生活很快就会变得极其无聊。他指出，当人陷入无聊时，往往会寻求其他刺激方式（如药物），从而滑向黑暗的道路。相反，他主张在当下享受生活，因为正是当前的挑战让他感到充实。关于金钱，他强调自己创业时金钱并非驱动力，而更像是一种“做得对的确认”。他认为财富存在边际效用递减规律，过度追求奢华生活（如私人飞机、豪华旅行）会导致与社会脱节。他通过资助基金会和体验普通生活（如使用 Airbnb 而非豪华酒店）来保持与社会的连接，认为人类的多样性本身就是最宝贵的体验来源。即便是在糟糕的天气或混乱的旅行中，只要保持开放的心态，依然能感受到“活着的美好”。
“如果你早上醒来没有任何期待，没有真正的挑战，那很快就会变得非常无聊。当你感到无聊时，你会寻找其他刺激方式……这会导致你走上黑暗的道路。”
优化“体验”而非“结果”，以及在线互动的缺失
Steinberger 提出了一种以优化体验（Experiences）为核心的人生哲学。他认为，如果只追求“好”的体验，人生会受限；但如果优化为获取体验本身，那么无论是成功还是失败（如淋雨、航班取消），都是值得庆祝的“精彩经历”，因为其中包含了学习与观察。他分享了一次在旧金山通过 Airbnb 与一位酷儿女性共同使用 Cloud Code 制作音乐的经历，这种真实的人际连接让他感到无比震撼。他进一步指出，当前的在线网络体验缺乏现实生活中的情感强度。由于数据传输的“损耗”（lossy），线上互动难以传递人类真实的情感波动。他预测，未来的 AI 代理将走向多模态交互，能够理解用户的情绪和语气，从而弥补这一缺失。对于未来的职业选择，尽管面临各大风投和公司的高额邀约（甚至可能筹集数亿美元），他拒绝再次创业，因为那会占用他真正享受的时间，并产生利益冲突。他更倾向于保持独立开发者的身份，专注于创造能带来真实情感连接的产品。
“如果优化的是体验，好的话很棒；坏的话也很棒。因为我学到了东西，看到了新事物……这就是生活关于体验的全部意义。”
开源商业化与资金压力的现实困境
Peter Steinberger 深入剖析了 OpenClaw 在保持完全开源与实现商业可持续之间面临的巨大挑战。他明确表示，拒绝采用 FSL 等限制商业用途的许可证，因为这不仅难以管理众多贡献者，更违背了他希望软件“免费如啤酒”而非“有条件免费”的初衷。尽管存在通过其他方式盈利的可能性，但目前极少有公司能成功维持这种纯开源且无商业限制的模式。他引用了 Tailwind 的案例，指出即使是被广泛使用的工具，也因 AI Agent 替代了大量人工访问而陷入困境，最终不得不裁员 75%。OpenClaw 目前处于亏损状态，主要支出用于支持除 Slack 外的所有依赖项。Steinberger 透露，每月亏损额在 10,000 至 20,000 美元之间，虽然 OpenEye 等公司提供了一些 Token 支持，但这仍不足以覆盖成本。他坦言目前依靠捐赠难以维持大规模运营，这种资金状况让他对纯开源模式感到缺乏兴奋感。
面临重大职业抉择：Meta 与 OpenAI 的博弈
在决定 OpenClaw（Open Claw）未来的技术路线和合作伙伴时，Peter Steinberger 面临着极其艰难的选择。尽管他个人对 OpenAI 的技术充满喜爱甚至自称为其“免费广告”，但 Meta（Facebook）方面展现出的深度参与让他感到被重视。他坦言，这不仅是商业决策，更像是一场情感上的割舍。Mark Zuckerberg 和 Sam Altman（Sam Alman）都亲自参与了产品的早期测试，但互动方式截然不同。Zuckerberg 直接加入 WhatsApp，甚至在通话前还在写代码，这种“非经理化”的极客态度让 Steinberger 感到亲切；而 OpenAI 方面虽然提供了极具诱惑力的算力资源（如 Cerebras Steel），但缺乏那种直接的、充满人情味的互动。Steinberger 强调，他做决定的核心动力并非金钱或单纯的利益交换，而是为了“玩得开心”并产生实际影响。即使合作失败，他也有退路可以独立开发，这种心态让他能够更纯粹地关注产品本身的价值。
“我不做这个是为了钱，我根本不在乎（I don't do this for the money. I give a [ __ ] of it）……我想要玩得开心并产生影响，这才是最终让我做出决定的原因。”
巨头创始人的互动风格：Zuckerberg vs. Altman
两位科技巨头的领导风格在 Steinberger 的叙述中形成了鲜明对比。Mark Zuckerberg 展现出一种去中心化的、工程师文化的亲和力。他不仅亲自试用产品，还通过 WhatsApp 这种非正式渠道与开发者直接沟通。Steinberger 回忆道，Zuckerberg 在接到电话前还在写代码，这种“没有脱离一线”的状态让他印象深刻。两人甚至因为 Cloud Code 和 Codex 哪个更好而发生了“十分钟的争论”，这种平等的技术探讨被视为一种极高的赞誉。相比之下，Sam Altman 则被描述为深思熟虑且极具智慧。虽然 Steinberger 与 Altman 的互动时间较短，但他对 Altman 的个人魅力表示认可。尽管外界对这两位人物评价两极分化，但 Steinberger 认为在大规模影响人类的技术领域，他们的能力都是卓越的。这种互动不仅让开发者感到被尊重，也证明了产品本身具有足够的吸引力去撬动顶级资源。
“Mark 基本上整周都在玩我的产品……他直接把我拉进 WhatsApp，问我能不能通个电话。我说我不喜欢日历预约，现在打吧？他说给我十分钟，我得先写完代码。”
技术解构：心跳机制与主动式 AI Agent
在探讨 OpenClaw 的技术架构时，Steinberger 揭示了一个看似简单却极具创新性的功能：“心跳”（Heartbeat）机制。这本质上是一个 Cron Job，定期触发 Agent 的循环。然而，他的创新在于赋予了这个机制“主动性”和“记忆”。他通过提示词（Prompt）让 AI 每隔半小时根据上下文对用户进行“惊喜”或关怀。起初只是简单的“Surprise me”，后来演变为更具体的互动，如询问用户的一天过得如何。这一功能在 Steinberger 进行肩部手术住院期间发挥了意想不到的作用。当检测到上下文中有重大事件（如手术）时，AI 主动发起关怀，这种基于情境的主动性让冷冰冰的代码变得具有人情味。Steinberger 指出，AI Agent 的核心并不神秘，本质上就是几个依赖项的胶水组合，理解这一点有助于开发者摆脱对 AI 技术的迷信。
“我让它变得主动……它知道你是谁，它在乎你。当检测到上下文中有重大事件时，它会主动发起关怀……这让 AI 变得非常 relatable（可共鸣/有人情味）。”
对 AI Agent 本质的哲学思考与去魅
Steinberger 以一种近乎解构的视角看待 AI Agent。他认为，所谓的“智能”往往只是现有技术的重新组合与工程化实现。他将 OpenClaw 比作“带额外步骤的 FTP”，将复杂的 Agent Loop 简化为类似“Hello World”的基础概念。这种去魅化的观点旨在鼓励开发者：不要将 AI 视为魔法，而应将其视为可构建的工具。他甚至在巴黎的会议上亲自演示如何编写简单的 Agent 代码，以证明其可及性。尽管外界对 AI 的潜力充满争议甚至敌意（如有人将 Zuckerberg 和 Altman 妖魔化），但 Steinberger 坚持认为，在大规模技术落地中，这种“工程化的浪漫”是必要的。他通过自己的经历证明，即使是最简单的 Cron Job 结合大模型上下文理解，也能创造出具有情感连接的产品体验。这种务实且略带戏谑的态度，反映了他对 AI 行业过度炒作的反思。
“这本质上就是一个 Cron Job。爱情不过是进化生物学的体现，我们只是在互相利用吗？项目只是几个依赖项的胶水组合……没什么原创性。”
OpenClaw 的核心架构：CLI 与 Skills 的协同机制
OpenClaw（Open Claw）的高层架构中，技能层（Skill Layer）与工具集成是极其关键且不断增长的组件。Peter Steinberger 指出，尽管半年前业界热衷于 MCP（Model Context Protocol），但他认为 MCP 本质上更适合被转化为命令行接口（CLI）。在 OpenClaw 的设计中，核心层并不强制依赖 MCP，而是通过一种更自然的交互方式扩展模型能力：如果用户希望为模型添加新功能，只需构建一个 CLI 工具。当模型需要调用该功能时，它首先通过一句简短的描述了解技能的存在，随后按需加载上下文以使用 CLI。这种机制允许模型在不确定时先调用帮助菜单（help menu），再根据需求动态加载具体指令。
"My approach is if you want to extend the model with more features you just build a CLI and the model can call the CLI... It just needs a sentence to know that the CLA exists if it's something that the model doesn't know by default."
这种设计使得 Skills（技能）成为连接自然语言与底层命令的理想桥梁。大多数情况下，一个 Skill 仅需一句话解释其功能，模型便能理解并调用相应的 CLI。虽然部分原始（raw）技能可能不够完美，但这种模式在大多数场景中行之有效。它避免了复杂的协议定义，转而利用模型对 Unix 命令的天然亲和力，实现了灵活且低摩擦的功能扩展。
MCP vs. Skills：上下文污染与组合性之争
Steinberger 对 MCP 持批判态度，认为其存在 上下文污染（Context Pollution）和缺乏组合性（Composability）两大致命缺陷。MCP 是一种结构化协议，用于定义模型如何与 API、数据库或服务通信；而 Skills 则是半结构化的自然语言描述，指导模型如何工作。虽然理论上智能足够的模型可以用 Skills 替代 MCP，但 Steinberger 强调 模型擅长调用 Unix 命令，这比遵循特定语法的 MCP 协议更自然。
以天气服务为例，若通过 MCP 获取数据，模型通常必须接收包含温度、降雨、风速等所有信息的巨大 JSON blob。这导致 上下文被大量无关数据填充，模型难以自然筛选所需信息，除非开发者预先在 MCP 中嵌入过滤逻辑。相反，若将同一服务封装为 CLI，模型可以自然地组合命令：先获取原始数据，再管道传递给 jq 进行过滤或计算。这种 按需处理的方式避免了上下文浪费，无需依赖子代理（sub-agents）等 workaround 手段。
"An MCP is that has to be added in training... The biggest thing it's not composable. So imagine if I have a service that gives me metadata... As a model, I always have to get the huge blob back. There's no way for the model to naturally filter..."
尽管 MCP 推动了企业构建 API，但其默认导致的上下文杂乱以及大多数实现并非开箱即用的问题，使其成为一个 不够理想的范式。Steinberger 认为，MCP 的价值在于历史推动力，但在 OpenClaw 的架构中，将其转化为 CLI 是更优解。
Browser Use：慢速 API 与平台访问权的博弈
在讨论具体应用时，Steinberger 提到了 Playwright 等浏览器自动化工具的重要性。他认为，随着个人代理的发展，许多传统应用可能会消失或转变为 慢速 API（Slow APIs）。他以自己逆向工程 Twitter 内部 API 构建的 CLI 工具 "Bird Short-lived"（因 Bird 品牌消失而得名）为例，说明即使平台封锁官方 API，代理仍可通过浏览器访问数据。
"If I can access in the browser, it is API. It's a slow API."
Steinberger 指出，Twitter/X 限制访问并非剥夺功能可能性，而是 增加了延迟。代理仍需打开浏览器读取推文，只是速度变慢。这种观点挑战了平台对数据控制的垄断逻辑：只要浏览器可访问，代理就能工作。然而，这也引发了关于 平台保护主义与开发者生态 的争议。
Twitter/X 的策略困境：反爬虫 vs. 开发者生态
Steinberger 对 Twitter/X 的反自动化策略表示不满，认为其 过度保护数据 的同时切断了大量小型开发者的用例。他建议 Twitter 提供 每日低配额只读访问权限，以解决书签整理、研究摘要等常见需求。许多用户在 Twitter 上发现有趣内容后会收藏，但因数量庞大而从未回顾。自动化工具可以帮助整理书签并提供摘要，这是极具价值的场景。
"I think if you have a very low per day baseline player account that allows readonly access would solve a lot of problems."
尽管 Steinberger 曾主动告知 Twitter 其工具的存在并配合下架，但他希望此举能 唤醒平台方对开发者需求的重视。他强烈反对 Twitter 上的 AI 自动化行为，甚至表示 收到疑似 AI 推文会直接封号（零容忍政策）。他建议 Twitter 若允许 API 访问，应明确标记 AI 生成的内容，以平衡平台安全与用户体验。这种 透明化 可能是解决当前僵局的关键。
"I also I'm very much against any automation on Twitter. If you tweet at me with AI, I will block you... especially on tweets. It's very hard to tweet in a way that does look completely human"
Steinberger 的观点总结为：平台不应通过降低访问速度来保护数据，而应提供结构化、低权限的只读接口，以激发创新并维护健康的开发者生态。
AI Agent 的社交身份与“人类痕迹”的价值回归
随着 AI Agent（智能体）逐渐拥有独立的社交媒体账号，平台必须重新思考身份标识机制。Peter Steinberger 强调，未来的社交网络需要明确标记内容是由 Agent 代表用户生成的还是本人操作。这是因为在 AI 生成内容极其廉价的时代，人类的注意力（Eyeballs）成为了稀缺资源。当网络上充斥着大量难以分辨的 AI 生成内容时，用户会产生强烈的排斥感。他直言：“I find it very triggering when I read something and then I'm like, 'Oh, now this smells like AI.'” 这种对“AI 味”内容的反感，促使人们重新审视在线互动的价值。如果平台能清晰标记并允许用户过滤这些内容，人类依然可以选择性地关注 Agent 生成的信息。然而，目前的现状是许多邮件或帖子虽然由 Agent “代理”撰写得井井有条，但用户更倾向于阅读带有瑕疵的人类原始内容。Steinberger 甚至表示：“I much rather read your broken English than your AI slop.” 这种对“粗糙人性”的珍视，标志着人类体验并未被 AI 削弱，反而因工具的存在而更加凸显其独特性。
从博客实验到视觉媒体：对“AI 垃圾”的本能排斥
Steinberger 通过个人实践揭示了 AI 在创造性内容上的局限性。他曾尝试用 Agent 撰写博客文章，结果发现花费的引导时间与人工写作相当，且最终作品缺乏个人风格的细微差别。因此，他彻底回归有机手写博客，仅将 AI 用于修正最严重的拼写错误。他认为：“there's value in the rough parts of an actual human.” 这种对“AI 味”的排斥不仅限于文本，还延伸至视觉媒体。他对 AI 生成的信息图（Infographics）和漫画感到极度不适，因为这些内容往往带有明显的“幻觉”痕迹。为了消除这些错误，创作者需要投入巨大精力进行人工修正，这使得使用 AI 绘图变得毫无意义。他感叹：“they were novel for like one week and now it just screams flop.” 这种对虚假和欺诈感的敏锐识别，证明了人类对自身独特性的深刻认知。AI 并未损害人类体验，而是作为工具赋能了它。
App 市场的颠覆：Agent 如何取代传统应用程序？
AI Agent 的普及可能彻底改变软件生态，甚至淘汰多达 80% 的应用程序。Steinberger 指出，Agent 拥有更丰富的上下文信息（如位置、睡眠状态、压力水平等），能够比传统 App 做出更优决策。例如，健身应用不再必要，因为 Agent 可以根据用户当天的状态自动调整锻炼计划；智能家居控制也不再需要独立 App，Agent 能直接根据环境需求管理设备。他质疑道：“Why do I still need an app to do that? Why should I pay another subscription for something that the agent can just do now?” 这种转变意味着许多 App 将转型为面向 Agent 的 API，而非直接服务于人类用户。虽然部分应用会消失，但新的服务模式将应运而生。例如，Agent 可能需要调用“租用人类”服务来处理复杂线下任务（如点餐），或者通过 API 与 Uber Eats 等公司交互。这种从“人操作 App”到“Agent 解决问题”的转变，将重塑整个软件行业的经济结构。
API化趋势与用户数据主权
OpenClaw 的核心愿景是让用户以最自然、最轻松的方式与其交互，这直接推动了应用向 API 化的必然趋势。无论企业意愿如何，AI Agent 将具备操控手机的能力：在 Android 端，Agent 可以直接点击“叫 Uber”按钮或调用现有 API；在其他场景下，若存在更高效的接口，Agent 会优先选择直接通信。这种转变意味着应用不再仅仅是封闭的软件界面，而是数据与服务的接口。例如，用户可能不再需要 Sonos 的专用 App，因为 Agent 可以直接通过 API 控制音箱和摄像头。这种数据获取方式的变革迫使企业重新思考其商业模式和销售策略。正如互联网早期颠覆传统行业一样，公司必须迅速重构其产品形态和盈利逻辑。那些无法适应这种“去应用化”交互模式的企业将面临被淘汰的风险，而能够拥抱这一趋势的公司则能抓住新的机遇。
对抗与绕过：以 Google 为例的博弈
尽管趋势不可逆，但大型科技公司如 Google 仍试图通过复杂的认证流程和技术壁垒来限制第三方访问。Peter Steinberger 指出，Google 甚至没有提供命令行界面（CLI），导致开发者必须构建如 GOG 这样的工具来桥接这一缺失。获取 Gmail 等数据的流程极其繁琐，有时初创公司甚至通过收购已获认证的实体来规避长达半年的审核周期。然而，Agent 依然能够突破这些限制：用户只需提供邮箱凭证，Agent 即可通过 Google Developer Console 获取密钥进行访问。虽然过程依然繁琐（Steinberger 形容为“Google 开发者丛林”），但企业无法完全阻止这种访问。在极端情况下，Agent 甚至可以通过浏览器模拟人类操作——包括点击“我不是机器人”验证码——来抓取数据。这种人机交互的自动化正在挑战 Cloudflare 等公司的反爬虫机制，同时也引发了关于“Agent友好型”网站未来的讨论。
开发者职业危机与“心流”的转移
关于 AI 是否完全取代程序员的问题，Steinberger 认为编程作为产品构建的一部分终将被自动化，但“建造什么”、“架构如何设计”以及“用户体验感受”等艺术性层面仍由人类主导。他将未来的编程比作针织：人们从事它是因为热爱和心流，而非纯粹的经济理性。他承认这种转变令人悲伤，因为过去深度编码带来的“心流状态”（Flow State）——那种忘记时间空间、沉浸在代码美学中的体验——正在消失。然而，这种心流并未完全丧失，而是转移到了与 Agent 协作、解决复杂问题的过程中。他引用历史类比指出，正如蒸汽机取代人力引发卢德运动一样，开发者对职业威胁的恐惧是自然的。但根本原因在于过去软件行业缺乏智能导致薪资虚高，而 Tokenized Intelligence（令牌化智能）的普及将加速这一过程。虽然开发者数量需求可能减少，但对理解如何构建系统的人才需求依然旺盛且价值更高。
AI 重构程序员身份：从代码执行者到任务架构师
Peter Steinberger 深刻反思了 AI 技术对传统编程职业的颠覆性影响。他坦言，程序员曾将大量时间与情感投入代码构建中，这种身份认同在短短几个月内被 AI 取代带来了巨大的痛苦。然而，他主张不应将编程视为一种受限的职业标签，而应回归到“建造者（Builder）”的本质。随着 AI 能力的跃升，编程的核心活动正在发生根本性转变：从编写具体代码转向理解任务需求、与 AI Agent 共情并定义其执行逻辑。Steinberger 认为，程序员群体因具备逻辑思维优势，最能适应这种变化，学习“Agent 的语言”将成为新常态。尽管不再直接敲击键盘编写每一行代码，开发者依然处于“驾驶座”位置，通过指挥 AI 来完成复杂的构建任务。这种转变要求从业者放下对旧有身份的执念，拥抱更宏观的系统设计视角。
"I never thought I would the thing I love doing would be the thing that replaced... To have that completely replaced is truly painful."
技术乐观主义与社会痛感的平衡：超越硅谷气泡
在讨论 AI 带来的社会影响时，Steinberger 批评了硅谷内部存在的过度乐观主义气泡（Bubble）。他指出，虽然保持对技术潜力的信心至关重要，但必须警惕这种情绪导致了对普通民众、尤其是可能失业群体的基本人类体验的忽视与轻视。大规模的技术变革必然伴随短期的痛苦与社会阵痛，包括程序员的职业危机。真正的进步需要一种谦逊的态度和对他人痛苦的尊重，而非仅仅沉浸在技术带来的便利中。他提到自己在社交媒体上因观点激进而遭受攻击的经历，这让他更能理解那些感到恐惧和愤怒的人。尽管他认为 AI 长期将创造更多机会，但承认并正视转型期的社会撕裂与个体苦难是负责任的技术领导者必须具备的素养。这种平衡视角有助于构建更健康、更具包容性的 AI 发展生态，避免技术精英主义对普通劳动者情感的漠视。
OpenClaw 的社会价值：赋能个体与降低技术门槛
尽管宏观层面的争议不断，Steinberger 分享了 OpenClaw 在实际应用中带来的具体且温暖的个人案例，证明了 AI Agent 技术的普惠价值。他收到了大量用户邮件，其中一位小型企业主利用 OpenClaw 自动化了发票收集和客服回复等繁琐任务，从而从重复劳动中解放出来，重获生活乐趣。另一个感人案例是一位残疾人士的女儿在 OpenClaw 的辅助下获得了前所未有的能力与自信，能够完成过去无法想象的任务。这些案例表明，AI 并非仅仅服务于大型科技公司或专业程序员，它极大地降低了技术使用的门槛，使普通人也能利用强大工具改善生活质量。Steinberger 强调，虽然 OpenClaw 推荐最新模型，但完全可以在本地运行免费或低成本模型（如通过 Ollama 等工具），实现高性价比的自动化。这种灵活性确保了技术红利能够惠及更广泛的人群，而非被锁定在昂贵的商业生态中。技术的真正意义在于赋予个体能力（Empowerment），让那些原本被排除在数字红利之外的人也能感受到进步的喜悦。
"OpenClaw helped their disabled daughter... she's now empowered and feels you can do much more than before."
构建者文化的复兴与希望之源
Peter Steinberger认为，当前AI领域最令他感到振奋的现象是“构建者氛围”（builder vibe）的回归。他观察到，人们不再仅仅将AI视为被动工具或内容生成器（slop generator），而是开始以更具玩耍性（playful）的方式探索其潜力。这种转变使得用户能够发现AI如何真正帮助改善生活，并催生出大量充满创意的应用场景。这种自下而上的创造力爆发让他对人类的未来感到乐观，他认为只要大家共同努力，就能解决当前面临的复杂问题。
"There's like clock on in Vienna. There's like 500 people and there's such a high percentage of people that I want to present which is to me really surprising because you usually it's quite hard to find people that want to like talk about what they built and now there's an abundance."
这种“丰裕”（abundance）的分享意愿在维也纳的一场活动中体现得尤为明显。在一个约有500人的聚会中，极高比例的参与者主动希望登台分享自己的项目。这与以往极难找到愿意公开谈论自己构建内容的用户形成了鲜明对比。这种从“稀缺”到“丰裕”的转变，不仅证明了AI工具的可及性正在提高，更标志着一种新的社区文化已经形成。人们不再羞于展示成果，而是渴望交流灵感。这种积极的反馈循环为技术的进一步普及奠定了社会基础。
技术民主化与赋权普通人
随着AI工具变得越来越简单（simpler）且更加安全（secure），其门槛正在被彻底打破。Peter指出，这一趋势的核心意义在于“赋权于民”（power to the people）。现在，任何拥有想法并能用语言清晰表达这些想法的人，都可以成为构建者。这不再局限于程序员或技术人员，而是扩展到了所有具备语言表达能力的人群。这种民主化过程是AI带来的最美好事物之一，它让技术真正服务于大众的需求和创意。
"Just imagine all these people building especially as you make it simpler and simpler more secure. It's like anybody who has ideas and can express those ideas in language can build. That's crazy."
这种“语言即代码”的理念彻底改变了创造力的边界。当技术壁垒消失后，创意的价值被无限放大。Peter强调，这不仅仅是效率的提升，更是社会结构的潜在变革。通过降低构建门槛，AI使得普通人能够直接将自己的愿景转化为现实产品或服务。这种广泛的参与感不仅激发了个人的成就感，也推动了整个互联网生态向更加多元和开放的方向发展。技术的本质回归到了服务人类，而非取代或控制。
社区、幽默与感恩时刻
在对话的尾声，主持人Lex Fridman对Peter Steinberger表达了深切的感激之情。他特别提到了OpenClaw不仅仅是一个产品，更代表了一种特殊的社区文化（special community）和一套独特的理念。Peter所创造的不仅是代码，还有其中的幽默感（humor）、良好的氛围（good vibes）以及激励他人构建的灵感。这种情感连接是技术项目成功的关键要素之一，它让冷冰冰的技术拥有了温度。
"You've created something really special, a special community, a special product, a special set of ideas, plus the entire the humor, the good vibes, the inspiration of all these people building the excitement to build."
Peter回应称，他感谢Lex给予的机会来讲述自己的故事。这种双向的尊重与欣赏体现了技术社区中珍贵的人文关怀。最后，Lex引用伏尔泰的名言作为结语：“能力越大，责任越大”（With great power comes great responsibility）。这不仅是对AI开发者的提醒，也是对所有使用这项强大工具的人的警示。在享受技术红利的同时，保持对责任的认知至关重要。这一对话以充满希望和反思的基调结束，强调了技术在人文层面的深远影响。
结论
OpenClaw确立了“代理式工程”范式，通过自我修改代码与系统级权限实现高度自主性。其核心优势在于降低技术门槛，赋予个人数据控制权及构建乐趣；短板则是安全风险高、依赖用户配置能力且面临平台机制缺陷。该模式适用于具备一定技术背景的用户，通过CLI或WhatsApp交互验证了实用性。
长远看，AI Agent将重塑开发流程与软件生态，推动应用API化并淘汰部分传统App。尽管存在幻觉、隐私及社区毒性挑战，但其民主化潜力巨大，使非技术人员也能成为“建造者”。成功关键在于平衡自动化与人类监督，优化协作体验而非单纯追求效率。