访谈概述

本次演讲与问答（AMA）发生在AI Engineer大会上，由OpenClaw的创始人Peter Steinberger主讲，随后由Swyx主持问答。OpenClaw是GitHub历史上增长最快的开源AI项目。

在演讲部分，Peter分享了项目发布5个月以来的爆炸性增长，以及由此带来的巨大维护挑战。他详细探讨了目前广受关注的安全问题，澄清了媒体对开源AI安全性的过度渲染（甚至点名批评了一些为了吸引眼球而忽略安全配置说明的学术报告）。此外，他还宣布成立OpenClaw基金会以保持项目的中立性，并回应了近期他加入OpenAI后引发的种种猜测。

在随后的问答环节中，Peter与Swyx深入探讨了本地模型与开源模型的重要性、他极其前卫的多线程AI编程工作流、AI开发中“品味（Taste）”的定义、为AI智能体赋予个性的实践，以及未来无处不在的智能家居AI管家愿景。最后，他分享了AI时代软件工程师应当重点培养的核心技能——系统设计能力与“学会拒绝”的全局观。

专用词语翻译列表

英文原词	中文翻译/解释	备注
OpenClaw	OpenClaw	演讲者创建的开源AI智能体项目，文中保持英文
Agent	智能体 / 代理	指能够自主执行任务的AI程序
Clanker	Clanker	语境中指代执行具体代码生成或操作的AI工具/进程
Slop	劣质内容 / AI垃圾生成物	指代AI生成的大量低质量、无价值的代码或安全报告
PR (Pull Request)	合并请求	GitHub等代码托管平台上的代码合并请求
Bus factor	巴士因子	衡量项目风险的指标（即多少核心开发者被巴士撞了会导致项目停滞）
RCE (Remote Code Execution)	远程代码执行	一种严重的安全漏洞类型
CVSS	通用漏洞评分系统	评估软件漏洞严重程度的标准
Un-nerfed model	未阉割模型 / 未受限模型	指没有经过安全对齐或能力限制的原始AI模型
BDFL (Benevolent Dictator For Life)	终身仁慈独裁者	开源社区中对拥有最终决定权的项目创始人的戏称
Dark factory	黑灯工厂	指完全自动化、无需人工干预的运作流程（在此指全自动代码生成合并）
Prompt injection	提示词注入	一种针对大语言模型的攻击方式
Dreaming	梦境机制	一种让AI在闲置时整理、重组和清理记忆的系统机制

---

讲座与问答实录

[会议主持人] 我们下一位演讲者是OpenClaw的创作者，这是全球增长最快的开源AI项目。他最近加入了OpenAI，致力于将AI智能体带给每一个人。请大家和我一起欢迎Peter Steinberger上台。

[Peter Steinberger] 大家早上好。Swyx让我来做一个“OpenClaw现状”的汇报。在座的各位有谁在运行OpenClaw？请举个手。

大概有30%到40%的人，非常棒。过去的这几个月确实非常不平凡，这个项目现在刚好满五个月。

我想现在可以毫不夸张地说，我们是GitHub历史上增长最快的项目。如果你看过那个增长曲线，通常项目会呈现曲棍球棒一样的走势，但我们的曲线简直就是一条垂直向上的直线。我的一位朋友管这叫“钢管舞式增长”，而这种增长速度也带来了随之而来的挑战。

目前我们在GitHub上的Star数量应该是最多的。虽然有几个项目的Star比我们多，但它们基本上都是教育类的教程项目，没有其他的软件项目能有这么大的规模。我们目前有大约3万次提交，贡献者即将突破2000人，PR（合并请求）也快达到3万个了。而且我们丝毫没有减速的迹象。你可以看到这不仅是一个陡坡，而且现在才4月9日，我们的开发速度依然保持在极高的水平。

但与此同时，这一路走来并不容易。当初在决定未来方向时，我面临两条路。我以前创办过公司，所以当时觉得：“我不想再搞一家公司了。”于是我加入了OpenAI。但随后我们又成立了OpenClaw基金会，现在我基本上等同于打两份工。

管理基金会就像是在“困难模式”下运营一家公司，因为你不仅要处理各种繁杂事务，手底下还有一大批你无法直接强制指挥的志愿者。所以我一直以来的目标之一，就是改善项目的“巴士因子”——也就是谁来负责提交代码。大家可以看到情况正在慢慢改善。Vincent稍后会在我之后演讲，但我们离理想状态还有一段距离。

在过去的几个月里，我与很多公司进行了交流。现在我们有来自英伟达（Nvidia）的成员加入，有微软的成员来帮忙开发MS Teams插件和Windows应用，还有来自红帽（Red Hat）的成员在安全和Docker化方面提供了巨大帮助。我们还与许多中国公司合作，有来自腾讯和字节跳动的贡献者。实际上，亚洲用户的基数比其他任何大洲都要大得多。总的来说，我们的贡献者遍布全球。

但今天我主要想谈谈关于“OpenClaw太不安全了”这个话题。你们肯定看过相关的梗图，比如“OpenClaw简直是在邀请坏人进来”，或者看到像英伟达这样的公司搞出了NemoClaw，大家都有自己的“小龙虾”（指各种衍生项目）。

大家可能也注意到了，在过去的几个月里，有几次发布导致了系统崩溃。我基本上可以说是被各种安全漏洞警告给DDoS攻击了。所以我把主要精力放在了这上面。到目前为止，我们收到了1142个安全警告，平均每天16.6个。其中99%被标记为“严重”。我们公开了大约469个，并修复了其中的60%。这些数字听起来非常吓人。

如果你把它和其他大型项目对比一下，比如Linux内核，他们每天大概收到8到9个警告；而Curl到目前为止总共只有600个漏洞报告，我们的数量是Curl的两倍。

每次我收到安全事件报告时，我的经验法则是：对方喊得越是大声、说问题越严重，这个报告大概率就越是“AI生成的垃圾（Slop）”。大家可能也在新闻里看到了，我们正在飞速进入一个全新的世界——由于AI工具变得如此强大，甚至能够识别出最离奇的多链条漏洞利用方式，我们将不得不改变编写软件的方式，因为AI会找出现有所有软件的破绽。

我给大家举个例子。英伟达推出了NemoClaw，这是为OpenClaw设计的一个插件和安全层，你可以把它放进沙箱里运行。他们的主题演讲是在周一，但他们在周日邀请我一起测试。我把它连接到了Codex的安全验证系统上，结果Codex在半小时内就找出了5种不同的方法，能够打破他们宣称的“安全沙箱”。这是因为如果你使用那个产品，你能访问到一个未受限（un-nerfed）的模型，它在网络安全方面的智能程度远超公众能接触到的版本。正因为如此，它才显得极其危险。

此外，整个安全行业的人把寻找漏洞当作一种“刷成就”的方式。他们发现的问题越多，受到的关注就越多。因此，OpenClaw成了那个每个人都试图攻破的“不安全产品”。毫不夸张地说，有几百号人启动了他们的Clanker，试图搞垮OpenClaw。

典型的攻击面包括远程代码执行（RCE）、绕过审批、代码注入和路径遍历。这些听起来都非常危险。我给大家举一个具体的例子：有个漏洞获得了CVSS 10分的评分，这在理论上是你能犯下的最可怕的安全错误。

这个漏洞大概是这样的：假设你同步了我们甚至还没发布、仍在开发中的iPhone应用，并且你只给了它读取权限。攻击者可以通过破坏系统来获取写入权限。

这个漏洞被标榜得极其严重。但在所有的实际应用场景中，这甚至都算不上一个安全事件！因为典型的使用场景是：你要么把它安装在云端的机器上，要么装在Mac mini上（我已经不再反驳这种行为了，随大家怎么折腾）。在99%的情况下，你要么能访问网关，要么不能访问网关。

在此我要为自己辩护一下，这确实是我的失误——我试图创建一个更宽松的权限模型。例如，当设备以语音为目标，并且只读取特定内容时，采用一个精简的权限系统是有意义的。但问题是，现在根本没有人在使用那个精简的权限配置！然而，CVSS的评分规则根本不考虑实际情况，我试图遵守规则，所以它被评成了10分满分。整个世界都在为那些在实际操作中根本不会影响到任何人的“严重事件”而疯狂。

当然，也有一些真真切切会影响到人的问题。比如有国家级黑客试图攻击用户。有一个名为GhostClaw的项目（很可能来自朝鲜），它基本上是用一个不同的NPM包来迷惑用户，如果你进错了网站并下载了它，就会被植入Rootkit。但这是我们无法控制的，这种事在其他项目上也经常发生。

另外还有Axios的事件，有趣的是，我们其实并没有直接使用Axios，但我们将MS Teams和Slack作为了依赖项，而它们使用了Axios且没有锁定版本号。这就是供应链攻击的运作方式，我们自然也受到了牵连。

那么，我们是如何从1142个（现在肯定是1150个了）漏洞警告中活下来的呢？有一段时间，我试图一个人处理这个循环，但这根本不可能。最快获得帮助的方式就是向各大公司求援。英伟达在这方面非常给力，他们派了一些人全职帮我们排查那些AI生成的垃圾报告，并加固我们的代码库。

除了黑客攻击，还有另一个角度的问题：有很多公司在制造恐慌。不仅是公司，还有大学。不知道大家有没有看过一篇流传很广的论文，叫做《混沌智能体（Agents of Chaos）》。这篇论文声称是关于智能体的通用研究，但里面却花了整整四页以极其详尽的细节解析了OpenClaw的架构。

但你们猜他们哪一页没提？他们完全没有提到我们说明如何安全安装的安全文档页面！因为如果提了那个，故事就不够有戏剧性了。为了炮制一个好故事，他们无视了我们关于安全的所有建议。

我们的建议明明是：这是你的个人智能体，不要把它放进群聊里；如果你把它放进群聊，请开启沙箱模式。因为如果任何人都能和你的智能体对话，他们就能窃取智能体有权限获取的任何信息！所以，如果是团队智能体，它就只应该知道团队共享的信息，而不是个人的绝密数据；如果是你的个人智能体，你就应该是唯一能和它对话的人。

但如果你不遵守这些规则，你就会得到一些非常“有趣”的互动，比如：“嘿，我能和你的智能体对话，而且它能搞垮你的系统。”因为我之前刚好对这篇论文有一些疑问，所以去质问了他们。他们竟然告诉我：“哦对，我们是用sudo模式运行的，因为我们想让智能体发挥最大威力。”

所以，他们实际上是刻意规避了安全设置（要用sudo模式运行其实并不容易，你甚至得去改代码），但他们在报告里对此只字未提。因为这同样无法为他们带来关注度。

我现在最大的挫败感就是：一整个行业都在试图给这个项目抹黑。他们宣扬“OpenClaw默认不安全”、“这是不可接受的”。但与此同时，许多喜爱它的用户、那些真正阅读了安全文档的人，却用得非常好。

我再举一个我觉得特别典型的例子：我们曾经有一个被报出的RCE漏洞，让整个比利时的网络安全部门都陷入了恐慌。比利时的网安部门发布了一个关于远程代码执行环境的通告。而整个所谓的“漏洞”，其实是系统的一个功能：恶意网站可以创建一个链接，触发网关并转发你的网关令牌。

但是！如果你使用默认的、也是我们推荐的设置，网关令牌仅限本地使用，或者至少也是在你的私有网络里。外部网站根本不可能访问它。除非你主动去对抗默认设置，比如在不看文档的情况下盲目使用云端代码进行部署，你才有可能把系统搞成那个鬼样子。但这绝对不是我们官方网站上写的做法。

老实说，风险确实存在。最大的风险就是所谓的“法律三角困境”：任何具有代理能力的系统，只要它能访问你的数据、能接触到不受信任的内容、并且具备通信能力，它就存在潜在风险。这并不是OpenClaw独有的问题，这是任何强大的智能体系统都会面临的难题。你让它变得越强大、能为你做的事情越多，你就越需要明白它到底在后台干什么。这才是核心问题，但人们却往往避而不谈。

接下来谈谈项目维护方面的负担。

问题在于，当你收到所有这些安全警告时，你明知道其中大部分是AI代理自动生成的，但你还是得用你的肉脑去阅读它们。因为我们还没有达到（或者说我还没有达到）可以完全信任AI能自行甄别真伪的地步。这对时间来说是一个巨大的消耗，而且你永远无法确定真假。

虽然有时候你能猜出来——如果报告的语气太有礼貌，或者报告人甚至道了歉，那多半是AI写的，因为搞安全的人通常是不会道歉的。但这依然是个大问题，我也看到越来越多开源项目在抱怨这一点，甚至因此被压垮，比如ffmpeg就公开表达过不满。

通常你会收到漏洞报告，但很少会收到附带的修复方案。即使有修复方案，通常质量也很差。如果你像我早期那样因为超负荷工作而仓促合并这些修复，你绝对会搞坏你的产品。所以，这真的是一件很难单靠志愿者来完成的事情。

那么我们现在在做什么呢？

首先，有人说“OpenAI收购了OpenClaw”，这不是真的。他们可能买走了我的灵魂（笑），但他们非常清楚一件事：这个世界需要更多的人去玩转AI，去理解AI的能力、风险和可能性。他们明白，如果一个人从未用过AI，但在家里用过OpenClaw之后，他去上班时就会问：“为什么我们公司没有AI工具？”

所以他们非常明白，支持这个项目是非常有益的。而为了让这个项目成功，它绝对不能被归属于单一的一家公司。

因此，我正在通过OpenClaw基金会建立一个“中立国”。Dave在帮我做这件事，差不多已经完成了。唯一拖慢进度的是美国的银行系统，它的效率实在有点低，尤其是当你不是美国人的时候，他们会非常困惑。这个基金会的运作模式是受到Ghostery（Ghost项目）的启发。

这将帮助我们雇佣全职人员，既能保持开发节奏、提高代码质量，也能解放我的一些时间，让我能重新去开发那些很酷的新功能。

这就是我关于“OpenClaw现状”的简短汇报。稍后我会在Q&A环节回答大家的问题。感谢大家的聆听！

[会议主持人] 好的，太棒了！谢谢大家的欢呼，我喜欢这种热情。你们选择了参加Claw主题的分会场，这将会是一场非常精彩的会议。接下来我们会听到许多关于OpenClaw以及个人AI助手的讨论。稍后将会有OpenClaw的贡献者、维护者、竞争对手，当然还有它的创作者在这个舞台上与大家交流。这个环节将一直持续到午休时间。

大概有一个半小时的会议。首先，我们将以一场AMA（问答）环节开场。你们刚才已经听了Peter的演讲，现在你们有机会直接提问，Peter和Swyx将进行一场对谈。为了开启这个环节，我邀请Swyx上台。大家欢迎！

[Swyx] （上台互动）其实我们可以一起上来，没什么秘密。Peter，欢迎你。这个环节是一个AMA（问答）。主要的情况是，我已经举办过六届AI Engineer大会了，每当有重要维护者或大咖来的时候，我们通常只让他们发表演讲。但实际上，观众们有很多问题想问。所以我们想创造这个机会。大家可以提交问题，我来主持。

我直接抛出一个最劲爆的问题开场吧。Pete，你刚刚引用转发了我的推文，说“把关于‘闭源之爪 (Closed Claw)’的问题都发过来”。我想大家对于你加入OpenAI后OpenClaw的未来有很多疑问。外界都在传“闭源之爪”，你的回应是什么？

[Peter Steinberger] 我当时决定加入OpenAI的时候甚至都没往这方面想。我认为大家的担忧是有道理的，因为OpenAI过去在开源方面确实做得不尽如人意。但我认为现在发生了很多改变：比如Codex现在开源了，他们发布了Symphony（一个非常酷的编排层）。所以他们现在真的在倾斜资源，并开始理解开源的意义了。

他们明白OpenClaw必须保持开源，必须能够接入任何模型——无论是大型科技公司的模型，还是本地模型。如果更多的人花时间在AI上，整个行业的每一个人都会受益。比如，如果我本来觉得AI很可怕，但突然我玩起了OpenClaw，发现它很有趣、很奇妙。然后我去上班，发现工作中没有AI工具，我会冲进老板办公室说：“我们工作怎么他妈的还没有AI？”然后这些公司可能不会直接运行OpenClaw，他们会想要一个托管的、受管理的商业方案，这样生意就来了。

所以他们非常支持我，为我提供资源。其实我也能从OpenAI那边拉来很多人帮忙维护项目，但那会给人一种“OpenAI接管了这个项目”的错觉，我不想那样。所以我引进了英伟达的人，我们还有微软的、Telegram的、甚至是Salesforce的人。顺便提一下，Slack那边也有很酷的人，现在有一个人在专门维护Slack插件。我还引进了腾讯和字节跳动的人，并与阿里巴巴、MiniMax、Kimi等所有模型提供商进行了沟通。他们都非常支持。

英伟达在这方面帮了巨大的忙，他们是我见过的在人员支持方面最酷的公司之一，直接安排工程师接手具体的代理任务并执行。现在有了其他公司的加入，我也正在从OpenAI内部引入几个人来帮助维护项目，因为软件迭代的速度太疯狂了，你真的需要一支“军队”。我正在组建这支军队。

[Swyx] 你确实有一支军队。但即使从你展示的贡献者图表来看，让高质量的贡献者留下来也很难，因为各种公司总是会把你的维护者挖走，然后你又得找新人。

关于本地模型和开源模型，大家有很多问题。现在技术栈并不是每一层都是开源的，很多模型你无法接触到底层，而且还有各种奇怪的限制。对于OpenClaw的未来来说，开源和本地模型有多重要？

[Peter Steinberger] 驱使我创建OpenClaw的部分动机在于：你看到那些大公司，他们有连接我Gmail的插件，我的邮件托管在某些地方，然后这些大公司对我的邮件有完全的访问权限，这让我感觉不太好。对我来说，如果我能完全控制我的数据，并且只有在需要最高级Token（算力）的时候，才把一小部分数据传到云端，这才是更令人兴奋的架构。

[Swyx] 是的，建立一种二级回退模型的层级结构。

[Peter Steinberger] 是的，你要拥有自己的数据，骨子里我还是个欧洲人（注重隐私）。当时没人做这个，所以这对我非常有吸引力。而且事实是，如果你是一家创业公司，想要接入Gmail，走流程可能需要半年，非常困难。但如果我作为一个普通消费者，我的Clanker（AI助手进程）可以点击任何网站，它甚至能愉快地点击“我不是机器人”的验证码。只要数据呈现在那里，我的智能体就能获取到。这样你就可以绕过那些大公司建立的数据孤岛，从而实现大型公司永远无法做到、也更酷的自动化用例。这非常有黑客精神。

[Swyx] OpenAI团队在GPT开源方面有什么动向吗？这是会和OpenClaw对齐的工作流，还是完全独立的？

[Peter Steinberger] 我目前的身份不方便透露这方面的内幕。但我能说的是，OpenClaw引发的一个效应是，公司里有越来越多人对开源感到兴奋。我很喜欢OpenAI正在朝着更开放的方向发展。对比一下其他某个以字母A开头的顶级实验室，如果你泄露了他们的任何源码，他们绝对会起诉你，或者一旦你太成功就会封杀你。相比之下，我认为OpenAI正在走上一条正确的道路。

[Swyx] 好的。我想重点提一下这个问题：大家都非常喜欢听你分享你的AI编码工作流。到现在为止，你提出的“与其提交合并请求（Pull Request），不如提交提示词请求（Prompt Request）”的理念已经广为人知了。而且你在OpenAI消耗的Token数量也让很多人感到震惊。大家想知道你是怎么发布代码的？以及你是如何处理智能体等待时间的（因为你同时在跑那么多智能体）？

[Peter Steinberger] 我完全没想到我那张照片（疯狂消耗Token）会火成那样。

[Swyx] 你给大家报个数字吧，让大家有点概念。

[Peter Steinberger] 有时候我同时运行将近10个会话。尤其是在我使用Codex配合50/51模型的时候，速度非常慢。不过现在情况不同了，我们做了改进，速度变快了，还有了快速模式。所以我现在典型的工作流大概是以前的一半——大约5到6个窗口，因为单次循环变快了，但我同步处理的工作区域还是那么多。所以我现在不需要那么频繁地使用分屏了。我认为未来Token的生成速度会越来越快，到某个阶段，同时在6个事情上切换就不再自然了。所以这实际上是速度变快前的一个权宜之计。

[Swyx] 安排你和Ryan坐在一起，观察你们两人在“榨干Token（Token Maxing）”上的不同策略，是我觉得很有意思的一点。我想听听你对完全“黑灯工厂（Dark factory）”模式的看法？也就是连合入的代码都不去审查（完全交给AI）。我觉得这越来越可行了。

[Peter Steinberger] 某种意义上，“黑灯工厂”意味着我在一开始就要构思好所有想做的东西。但我并不认为你能用这种方式写出好软件。通向山顶的路从来都不是一条直线，而是蜿蜒曲折的。有时候你会偏离一点轨道，然后看到一些新东西给你带来灵感，你会找到捷径。当你到达山顶时，你可以回溯出一条最优路径，但你攀登的时候绝对不是直着走上去的。

你对项目的第一个想法，极大概率不会是最终产品的样子。如果我盲目采用这种瀑布模型，那出来的就是第一想法的版本。这对我行不通。我的方式是：构建一步，玩一下，感受一下；然后产生新想法，修改我的提示词。对我来说，这是一个高度迭代的过程。所以我不明白你怎么能把这完全自动化。你当然可以为特定的环节构建流水线。

[Swyx] 是的。

[Peter Steinberger] 但即便是处理PR，你也不想只建一个盲目合并所有PR的流水线，因为很多PR根本不合理。用户会把你的产品拉向各种诡异的方向，如果把这个过程自动化，AI极大概率不知道什么才是正确的方向。你可以引导它，我有一个愿景文档尝试做过这种事，但瓶颈依然在于同步处理能力，以及拥有“品味（Taste）”。

[Swyx] 品味非常重要。你是如何定义“品味”的？在我和别人的交谈中，大家都认同“品味是护城河”，但没人能在“什么是好品味”上达成共识。我想听听你的看法。

[Peter Steinberger] 在如今这个时代，“品味”的最低标准就是：它闻起来不像是一股AI味儿。你肯定明白我的意思。如果某种写作风格、个性，甚至UI界面（你现在已经看了太多AI生成的UI了，一眼就能看出来是不是AI做的），带了左侧彩色边框那种……

[Swyx] 对，或者有一阵子流行的紫色渐变。

[Peter Steinberger] 是的，所以我认为这是一种感觉。就像你能一眼识别出AI写的一堆废话（Slop）一样。即使你无法精准定位，但你就是能感觉出来。这就是最基础的品味。

再往上走一层。因为现在软件开发中很大一部分都可以自动化了，实际上你有了更多的时间去打磨那些小细节。比如，当你运行OpenClaw时，你会收到一条偶尔调侃、吐槽用户的小消息。这些就是能带来愉悦感的小细节，如果你只是在高层次上给出一个空泛的提示词，你是绝对得不到这种效果的。

[Swyx] 你最让我喜欢的品味之一，就是你花了很多心思在系统提示词的“灵魂（Soul.md）”文件上。你开源了你的方法论，在你的做法出现之前，我认为人们在AI的“灵魂”上下的功夫远远不够。我录了一期播客（还没发布），嘉宾是现在Shopify的CTO Mikhail Parakhin，他以前是Bing团队的负责人，当时那个名叫“Sydney”、没有完全对齐但充满个性的聊天机器人就是在他手里诞生的。大家其实很享受拥有个性的聊天机器人。你的Clanker就有着自己各种奇怪的痴迷点。

[Peter Steinberger] 这其实是因为世界变了。我们在2023年和2024年有了ChatGPT，那时候我们有AI，但并不完全了解AI能做什么。所以我们重新造了一个“Google”——你有一个搜索框，你得到一个回答。你并不会期望Google有自己的性格。

[Swyx] 没错。

[Peter Steinberger] 但现在我们更倾向于智能体的概念。一开始我做WhatsApp消息中转的时候没想太多，只是把它连到了云端代码上。但当我在WhatsApp上看到它的回复时，我发现感觉不对。即使云端代码本身已经带点性格了，但它并不符合人们在WhatsApp上给你发信息的习惯。

我的迭代就是从那时候开始的。这又回到了“品味”的问题上：感觉不太对。它太啰嗦了，用了太多的句号。我的朋友们发信息不是这样的！于是我开始调整：“不行，这个太不像人了，试着像人类一样发消息。”

[Swyx] 哈哈，我实际上跑了一个提示词是“像龙虾一样写作”。

[Peter Steinberger] “像龙虾一样写作”，没错。

[Swyx] 关于你，我最喜欢的一句话是“带着科幻色彩的疯狂（Madness with a touch of science fiction）”。这似乎就是你运营AI项目的方式。我认为像OpenClaw这样的项目，绝对不可能诞生在一家传统的美国大公司里。因为在我们这个行业还没完全解决某些问题之前，这个项目早就被法务部门扼杀在摇篮里了。

[Peter Steinberger] 是的。现在我们有了一些缓解措施，模型也在变得越来越好。但我想象不出任何大型实验室有能力发布这样的产品，他们面临的阻力太大了。而且也没有足够的市场证明这就是人们想要的东西。所以，这必须由外部的人来完成。

一开始我构建它的时候就在想：“最坏的情况能是什么？”

[Swyx] “它可能会把我的Token、我的邮件都泄露出去。”

[Peter Steinberger] 对，但没有什么是能彻底毁了我的。它可能会上传一些我的照片，但我当时觉得：“算了，如果你用Grinder的话，更糟糕的照片估计早就上网了。”所以我觉得：“好吧，这个风险我可以承受。虽然会让人很不舒服，但在可控范围内。”

[Swyx] 但如果是一家公司，就需要采取完全不同的策略了。

[Peter Steinberger] 是的。

[Swyx] 顺便说一句，大家可以去关注他的Instagram账号，虽然关注的人不多，但里面有很多好东西。

好的，下一个话题。刚才你提到了WhatsApp、Telegram这些文本应用。文本交互很好，但人们也在寻找下一个计算形态（Form factor）。大家想要眼镜、耳机。关于让智能体融入你的生活，你的愿望清单是什么？

[Peter Steinberger] 我实际上已经开始做这方面的探索了，只是后来被蜂拥而至的用户和日常的维护琐事给绊住了。

如果我在家里，我希望我在任何一个房间，只要像《星际迷航》里那样说一句“计算机（Computer）”，我就能和我的智能体对话，它应该能直接回应我。它应该知道我在哪里。我在每个房间都放了小iPad，我的智能体可以利用Canvas功能，把内容投射到那些iPad上。

所以，如果我问了一个问题，而这个问题通过展示画面更容易回答，它就可以利用离我最近的显示屏，因为它知道我的位置。手机只是一个非常方便的输入终端，但我真正想要的是能在任何地方与它对话。

如果我戴着智能眼镜，它应该能够实时聆听，并直接在我的视野中投射信息。一旦我们拥有了真正智能的家居环境，这种无处不在、如影随形的体验就会成为现实。智能体确实会在你的手机上，但你真正需要的是“无处不在的智能体”。

到了那时候，你可能在工作时会有一个企业级的、带大写字母的OpenClaw（专属代理）；而你自己可能有一个小写的、个人版的OpenClaw。这两个Claw应该能够以一种你和你的公司都感到舒适、安全的方式进行沟通。这就是我们需要去构建的未来。

[Swyx] 我最近刚和Maran Dre录了一期播客，他是你的超级粉丝；我还和Andrej Karpathy交流过。这两人都在用OpenClaw来管理他们的房子。我觉得把OpenClaw用于智能家居是一个有点被低估，但正在被大家发掘的绝佳场景。最讽刺的是：这之所以能实现，恰恰是因为物联网意味着大多数智能设备的安全防护烂得一塌糊涂，所以OpenClaw才能轻易黑进去控制它们。

[Peter Steinberger] 等几个月后模型变得极其强大的时候，这个场景将会运行得更加完美。

[Swyx] 是的，它们非常棒。好的，问一个关于安全的问题。关于“提示词注入（Prompt injection）”，你想如何解决这个问题？或者说你是如何思考这个问题的？

[Peter Steinberger] 可能思考得还不够。另一方面，现在的前端模型在检测随机从网站或邮件中混入的恶意指令方面，已经做得非常好了。如果你把这部分标记为“不可信内容”，想要从中窃取数据是非常困难的。当然，如果我能无限制地访问你的Claw，并用大量数据轰炸它，那还是有可能得手的。

但对于一次性的交互，这已经不再是最大的问题了。这也是为什么有人会说“Peter不喜欢本地模型”。因为我看到有人在本地运行一个200亿参数的模型，这个模型完全是对你言听计从的，它根本没有经过任何安全防御训练。这就很有问题。如果你运行那样的模型，然后又用它去浏览网页或处理邮件，那真的很让人担忧。这也是为什么如果你使用小模型，OpenClaw会向你发出警告。

我知道有人把整件事扭曲成“我们讨厌本地模型”。我其实很乐意我们支持所有模型，但你必须在某种程度上引导普通用户走上正确的轨道，至少要让他们“搬起石头砸自己脚”的难度变大一点。关于提示词注入，确实有一些新想法在酝酿，只是还需要一点时间，所以我还没有正式宣布。

[Swyx] 我认为Simon Willis在这个问题上做了很多工作，毕竟“提示词注入”这个词就是他发明的。那种“双大模型（Dual LLM）”的方法似乎很聪明，但我还没聪明到能找出它所有可能被攻击的漏洞。在某种程度上，系统必须建立一种信任机制。

我在和接下来的演讲嘉宾Vincent交谈时发现了一件很有趣的事：你们不得不实现一套和Shopify CEO Tobi Lütke一样的信任系统。也就是：系统需要随着时间的推移建立声誉，信任度越高的实体，获得的特权访问权限就越大。我认为这非常合理。

[Peter Steinberger] 这确实是整体方案的一部分。

[Swyx] 好的，接下来问几个更宽泛的问题。一旦你有了更多的空闲时间，你最想做哪些酷炫的项目？

[Peter Steinberger] 我想开发“梦境机制（Dreaming）”。要知道，当我在睡觉的时候，我的维护者们就在开发“梦境”。

[Swyx] 就像换班一样，对吧？

[Peter Steinberger] 是的。

[Swyx] 什么是“梦境机制”？

[Peter Steinberger] 这是一种调和记忆的方式，有点像创建一个“梦境日志”，去梳理你的会话记录。我们从Anthropic源代码泄露事件中发现，他们也在研究这个机制，对吧？

[Swyx] 哦，对。

[Peter Steinberger] 我敢肯定还有更多的公司在研究这个。想象一下我们人类是如何学习的：你白天经历了很多事情，然后你睡觉。在睡眠中，你的大脑会进行垃圾回收（Garbage collect），将一些短期记忆转化为长期存储，并丢弃其他无用的信息。我认为这个原理对AI智能体同样非常有用。我们目前已经发布了关于“梦境机制”的功能，这算是朝着这个方向迈出的一小步。

[Swyx] 这和Andrej Karpathy提到的把所有东西收集进Wiki（维基）的概念有关吗？也就是更多地将它视为记忆的融合？

[Peter Steinberger] OpenClaw的美妙之处就在于我们可以大胆尝试。在最开始，代码库就是一团庞大的意大利面条（混乱的代码）；但经过我们过去几个月的努力，现在几乎所有东西都是扩展或插件。所以，你可以替换记忆模块，可以加入Wiki功能，可以加入梦境机制，或者加入你任何疯狂的想法，把它变成你独属的版本。你不需要把所有改动都通过PR发给我们，因为我们在审核PR上已经完全超载了。现在的OpenClaw更像Linux，你可以随意安装你自己的组件。

[Swyx] 确实如此。许多人认为你正在构建自Linux以来最具影响力的开源软件。你如何应对这种赞誉？作为这样规模项目的实质性BDFL（终身仁慈独裁者），你日常的一天是怎样的？

[Peter Steinberger] 依然有大量的编码工作。顺便提一句，在今天几场会议的间隙，我刚才还在后台写代码呢。

[Swyx] 因为机器在计算Token，总得有点产出嘛。必须得去推着那些智能体往前走。

[Peter Steinberger] 是的。不过现在的重心发生了一些转移。我现在花更多的时间在沟通，以及引导人们走向正确的方向。我们在OpenClaw踩过很多坑、学到了很多教训。我在OpenAI的角色之一，就是帮助他们避免重蹈覆辙。而对于OpenClaw来说，我们的任务是尝试激动人心的新事物——有些可能成功，有些可能失败。

我们的目标是让各大公司能够构建属于他们自己的“Claw”，而无需另起炉灶去Fork代码，而是让一切变得更加可定制。

嗯……除了这些，我偶尔也睡睡觉。

[Swyx] 你偶尔也睡觉。太好了。我想用最后一个问题来收尾。在AI时代，你希望人类，特别是工程师们，重点去培养什么技能？

[Peter Steinberger] “品味（Taste）”是一个很关键的技能，这个我刚才已经提过了。此外，“系统设计（System design）”依然非常重要。我们在旧金山的时候讨论过这个。如果你不去思考系统设计，你最终会把自己困在一个死角里。你需要界定系统的边界。

有趣的是：一切都装在Clanker里，但你依然需要提出正确的问题。这就是为什么出来的可能是优秀的代码，也可能是一堆垃圾代码的根本区别所在。在这方面，你积累的关于如何构建软件的知识依然有用武之地，它能指引智能体走向正确的方向，而不是产出垃圾。

此外，我认为一项变得越来越重要的技能是“学会拒绝”。这也是我不得不学习的一课。因为在今天，即使是最疯狂的想法，实现它也只需敲下一段提示词而已。单个想法从来都不是问题，但如果你把这个想法、那个想法、所有的想法都堆在一起……思考如何将这些想法有机地融合在一起，才是真正的问题所在。

所以，我们现在的瓶颈依然在于统筹规划能力（Syncing）和对全局观的把握。你可以从你的Clanker的角度想象一下：你被直接丢进了一个庞大的代码库中，你可能只有一个过时的 agent.md 说明文件，但你根本不知道这到底是个什么鬼系统。然后人类对你说：“嘿，加一个用户资料页面。”于是你不知怎么地加了进去，并把它连接到了你视野内能看到的那两个组件上，但你根本没有看到整个系统的全貌！

这就是为什么现在很多AI生成的解决方案都过于局部化和碎片化。我们作为工程师的职责，就是通过向智能体提供提示来帮助它们做出最好的工作：“嘿，你需要考虑一下这个。你去看看那个模块。这个组件和那个组件之间应该如何交互？”只有这样，你最终才能得到一个真正可维护的系统。

[Swyx] 非常感谢你维护着有史以来最重要的软件之一，也感谢你今天花时间来和我们分享。

[Peter Steinberger] 感谢邀请。

[Swyx] 希望你稍后能留下来回答大家的问题。谢谢！