开场前（基本没有讲话）
开幕演讲｜Georgios Konstantopoulos（Paradigm）：如何驾驭 AI 海啸
大家早上好！Frontiers 第二天开始了。昨天晚上我们过得挺精彩。
昨天的日落非常壮观。今天我想谈谈如何驾驭一场海啸——显然这就是科技行业眼下正在经历的事。不过开始之前，先说一下我们那个 Signal 群。希望大家都加入了；还没进群的话，我再把二维码展示五秒。今天上午安排了演讲，午饭后是开放式黑客松和共同工作。今天场地大概能用到晚上九点或十点，星期三也一样，只是到下午五点。黑客松非常自由，我们没有给组队定规矩。你想组一个十人团队，那就组；如果找不到队伍，想和自己的 Agent 伙伴单干，也完全可以。黑客松的目标是挑战自己的极限，做以前没做过的事，挑一个过去不会去做的业余项目。
做一点你的老板平时不允许你做的疯狂事情。挑战极限真的很重要。我们和 Amp 的 Quinn 是多年的好朋友，也非常喜欢他们的产品，他可能会给所有人提供一些使用额度，那就太棒了。今天的演讲阵容非常强，不光因为有 Paradigm 和 Tempo 的朋友，而是因为有在座的每一个人。昨天我们聊了 Amp、机器人、AI、GPU 上的 Rust、用于去中心化推理的 Rust、训练和强化学习。这里有人在做最先进的共识系统，有人研发了一门可能终结 Rust、也可能不会的全新编程语言，还有人只靠文字提示就能打印出机械臂。如今能做的事情有点不可思议。
而我们请来了这些领域里最顶尖的人。有多少人知道我放在这里的这个更新？看来有一些。我们长期投入了大量精力建设开源工具栈，最近我也开始开发偏 AI 的工具，比如 Cent 和 Nanocodex，稍后会谈到。研究方面，我们团队的 Dan 和其他人不断发表实验性成果，试图更清楚地了解这些系统究竟如何表现。几个月前，我们还和 OpenAI 合作，研究如何为智能合约攻击构建评测；这显然是一个重要问题。但我想先带大家回到起点：2023 年的 Rust Ethereum Day。那时我们举办这场活动的理由非常简单。
我们在做 Rust，也在做以太坊，就觉得把所有朋友叫到同一个房间里吧。它很快演变为今天的 Frontiers。2024 年举办了一届，2025 年我们又把 Midway 那家大型俱乐部改造成活动现场。Frontiers 真正的灵感来自 Scaling Bitcoin，我有幸在 2019 年参加过。那场活动早在 2015 年就提出了一个口号：面向工程师和学术界，没有赞助商，没有展位，没有干扰。我希望大家真正想一想这一点。Frontiers 的目标就是排除干扰，专心动手做东西、沉下心学习，做你平时根本抽不出时间做的事。所以，当你坐在这里，而外面的世界——至少旧金山的世界——越来越疯狂时，不妨放慢一点。
放下手机，可能也把电脑合起来一会儿。我希望大家认真听今天的演讲，而不是始终盯着自己的笔记本，因为这些内容大多是第一次公开分享。我们一直鼓励讲者真正透露一点他们正在做的前沿东西，也希望听众尊重他们的付出。感谢大家。我们也在活动周边上花了很多心思。你们看到的家具是定制的，平面设计是定制的，我们甚至做了一份报纸，还有经过 PSA 评级的活动卡片。几乎每一样东西都是特意为这里做的。这些设计承载着大量心血。在这个人人疯狂消耗算力、却没法认真关注事物的时代，我们仍然愿意投入这样的精力。
这场活动筹备了好几个月。请大家给活动设计团队、All Vision 团队和所有参与者掌声！好，回到故事开始的地方。房间里有人用过这个项目吗？天哪，比我预想的多得多。
看来还有人参加过 Rust Ethereum Day。对我来说，Rust 之旅开始于 2020 年，当时我在做 ethers-rs 库。动机是大家都在用 Python 写交易机器人，而大约 2019、2020 年，加密金融生态里曾经因为各种机器人离线而发生许多故障。所以我想：做一个用于开发机器人的 Rust 库吧。效果还不错。大约一年后，我们又做了 Foundry。如今它基本成了部署智能合约的默认工具之一，通过它部署的合约所承载的资金达到一千亿到一千五百亿美元级别。你们知道，钱一旦丢了，通常很难找回来。因此，我们深入进入软件安全领域，开始思考什么才叫高可信的软件。再过一年，又出现了大家熟悉的名字。
原稿这里把一处项目名听写成了“Judge UBT”，名称存疑。几个月后，Reth 项目公开宣布了。Reth 是我职业生涯中最难忘的项目之一。它让我们不仅理解交易机器人和安全软件，还真正深入了持久化分布式数据库。之后一切都变得越来越疯狂：新的 Agent harness 出现了，我们启动了 Tempo，OpenAI 开始攻克一个又一个数学问题。世界的变化越来越快。也正因此，今年 Frontiers 的意义是放慢速度。外面的人都在发疯，我们这两天要保持清醒；让 Agent 去疯狂干活，让它们承担那些疯狂的尝试，而我们则在这里认真想象更美好的未来，不要在浪潮里迷失。我们选择这个地方也有部分这样的原因。旧金山很美，天气很好。
世界上有很多负面情绪，但这个房间里没有。这是我今天最重要的一张图：只是一条指数曲线，但它准确描述了正在发生的事。指数增长意味着一件很简单的事：忘掉你过去熟悉的规则。随着基础设施不断演化，很多东西都会被重新拆解。例如论文发表的增长。我们团队的 Storm 最近发表了关于论文发表爆发式增长的研究，显示新论文的产出速度比以往任何时候都快。计算机科学、生物学、安全，几乎所有领域都是如此。论文出现的速度已经超过我们核验它们的能力。OpenAI 一口气放出七百篇数学论文，数学界都被震住了。这种情况到处在发生。Token 消耗也在指数增长。如果你——准确说是你公司的 Token 用量——还没有沿这条曲线上升，大概该想办法让它上升了。
当然，为了财务部门着想，你可能不希望账单的增长曲线也完全一样。最近几周，有多少人尝试重新编译某个游戏或闭源软件？我猜明年整个房间都会举手。无论是 Adobe Photoshop、我自己做的小录音软件、逆向工程，还是其他任何想做的软件，都在变得可能。支付也在指数增长。机器支付、Link 支付，以及各种人们正在打造的 Agent 钱包，都在快速发展。人们构建 Agent，Agent 要在现实世界里执行操作，而这些操作最终会遇到支付门槛。只要有一道付费门槛，就存在付款穿过它的机会。我认为这样的曲线会持续下去，这也是我们去年与 Stripe 启动 Tempo 项目的部分原因。
Pull Request 的数量也在指数增长。有人在 Twitter 上发布了一个叫“Are You Going Exponential?”的网页，输入 GitHub 用户名，就能看你的产出是否正在指数增长。我认为大家真应该拥抱这种变化。回头想想过去的程序员：我们会说五六十年代、七十年代的人居然手写汇编、手工制作穿孔卡，真不可思议。以后的人可能也会这样看今天的我们：居然还得用键盘往电脑里敲字。这才刚刚开始。但指数增长还有另一面，那就是曲线的方向和斜率。代码质量可能正在受到冲击，Pull Request 审查流程可能遭到挑战。每首音乐听起来都差不多，电影都像一个模子刻出来的，项目和用户界面也越来越相似。
一场巨浪正朝这里的每一个人扑来。今年四月，我在 Stripe Sessions 谈过一场由机器和 Agent 驱动的海啸。它迫使我们重新思考基础设施应该怎样运作、流程应该怎样设计、该招什么人、招多少人、成为优秀从业者是否还需要上大学等所有问题。接下来是另一张最重要的图：执行成本正在下降。执行成本下降会带来很多后果，其中一项反作用，就是审查成本反而会增加。Quinn 今天也在现场。尤其是金融软件，测试与审查更值得关注。
说到执行成本下降和审查成本上升，有一个家伙可能有自己的答案，那就是 Rust。举手看看：2024 年之前写过 Rust 的有多少？2024 年之后写 Rust 明显更多的呢？我原以为人数会更多。我们喜欢 Rust，首先当然因为性能。它能编译为原生代码，编译器可以自动向量化，也能避免不少其他语言带来的问题。它在内存管理方面提供自动化的安全机制，真的帮你避开许多痛点。第二点是安全性。Rust 官网强调，这是一门帮助开发者编写高效、安全代码的语言。这实际上是 Rust 的核心。
正因为如此，很多年前我们才能交付 ethers-rs、Foundry 以及后来那些 Rust 项目。那时我们根本不懂手动内存管理、模糊测试器等复杂技术，但我们知道，Rust 可以成为很好的老师，让我们理解安全系统该是什么样子。Tokio 的创造者今天也在现场，大家之后可以去找他聊聊，感谢他们团队的工作。Rust 还有一个常被低估的特性：编译器很严格，最终会为 AI Agent 生成大量有价值的反馈 Token，让 Agent 进入很好的反馈循环。大家应该都知道，Rust 的错误信息可能是业内最好的——当然，碰上十层嵌套泛型的时候除外。我们正在开发一个编译器项目，也使用了 Rust 编译器的一些 crate。
这让 Rust 非常适合 Agent。你对 Agent 说“用 Rust 给我实现这个”，做出来的东西通常运行得快，也不太会因为低级错误崩溃。我还可以让它参考自己在 AI 出现之前写的代码，保持较高的质量标准。第四个特别被低估的优点是跨平台。我们过去主要针对普通 CPU 写程序；如果设置 RUSTFLAGS="-C target-cpu=native" 之类的本机目标优化，有时几乎白捡 10% 性能，因为编译器会使用机器特有的指令。Rust 可以编译到嵌入式设备。你还可以通过 Embassy 等 crate，在嵌入式设备里写异步 I/O。当然，还能用 Rust 编写 GPU 代码。VectorWare 的 Christian 今天会展示这方面一些非常有趣的成果。
这里最重要的是：Rust 棒极了，只要有机会，大家就应该在技术栈里尽可能使用它——除非编译时间实在太长。大家大概都熟悉这个老梗，Rust 流行起来之后它又火了。我还错过了把另一个场景放到幻灯片上的机会：当很多 Agent 同时在一个项目上工作，Cargo 被锁住，谁也编译不了。编译时间管理有很多坑。你可能需要把项目拆成多个 crate；端到端测试也可能要采用 mod 组织，而不是把一堆独立的测试二进制挤在一起。
但这些问题都有解。
Rust 甚至让过去的怀疑者也转变态度。著名开发者 DHH 曾对 Rust 深恶痛绝，他在 Lex Fridman 的播客里也说过类似的话。最近他改观了：只要你永远、永远、永远都不需要亲自看 Rust 代码，这门语言就真的非常好。当然这话可以有不同解读。你看某些高度模板化的 C++，也会觉得它根本没法读；如果你来自 Ruby 或 TypeScript 世界，Rust 代码确实可能不那么友好。今天 VxLang 的 Aditya 也在场，会讲下一代编程语言可能是什么样：它们追求性能、内存安全、Agent 友好、GPU 支持，甚至不依赖特定硬件拓扑，同时还要解决编译耗时问题。
这是一个非常有趣的时代：因为有了 Agent，我们甚至能随时造一门新语言。如果你讨厌 Rust 编译慢，可以直接 fork 一份语言，对 Agent 说“把它改快”，没准它真能办到。这就是今天这个世界美妙的地方。我也有兴趣资助 Rust 编译器本身的优化工作，而且愿意公开投入资源。所以如果你或朋友正在做这方面研究，演讲后请来找我。我们有资金，也有可用于性能基准测试的真实代码库。最后说回今天的主题：世界在疯狂变化，你说让我保持清醒、使用 Rust、发挥创造力，可我还得有工作，还得赚钱，还得做有意思的事。到底该怎么办？
我的第一条建议就是：好好玩。比如业余时间我在做 Nanocodex，重新想象如果 Codex 是一个库会是什么样。我也做了一个小音乐应用，借此练习逆向工程。我觉得今天在场的每个人首先都应该这么做。这正是实现业余项目的好时机。家里的空调、电视有点毛病，过去一直懒得折腾？现在甚至可以直接对机器说：扫描我本地网络的所有设备，用蓝牙、RFID 或一切可用手段，把这玩意给我修好。它们真的可以很好地完成这类任务。
所以现在就应该享受创造。有孩子的人可以给孩子做点有趣的小玩具，几乎任何想法都可以尝试。今天是个令人兴奋的时代，请专门留出一点时间玩起来，或者就用手机上的 ChatGPT App 做点东西。我真不愿看到所有人只是感叹“AGI 要来了，不是带我们玩就是来杀我们”。我宁可选择开心创造的那一边。第二条建议是选对环境。现在最重要的是身处真正重视技术、重视 AI 的环境。这不是什么创新部门开会讨论“我们该不该做 AI”，而是一次彻底重塑技能的机会。如果你所在的环境还没有理解这一点，就应该认真考虑自己的处境。
第三条是：你工作的公司应该给你近乎无限的 AI 预算。这听起来残酷，但确实是今天的现实。如果公司对你的 Token 消耗严加管控，我认为它会很难与那些资金更充裕、敢于放开使用的公司竞争。这并不是说不需要透明度。我们也会持续衡量并分析员工的消耗，但会授权他们大胆地花钱，因为顶尖人才常常正是在这里发挥出最好的表现。还有一条：忘掉过去那些你自以为懂的东西。别和技术、观念、模式或者所谓最佳实践结婚。眼下所有人都还在重新摸索，许多事情从零开始被重新发明。
无论别人试图向你兜售“正确做法”，还是你自己下意识地想“按照标准流程我就这么做”，都先克制一下。遇到机会不妨想：要是把整个代码库交给 Agent，让它连续折腾一整晚甚至一整周呢？要是停止常规代码审查和 Pull Request 流程呢？这些都是值得实验的方向，不应该把既有做法抓得太紧。你可能会惊讶，一个更愿意承担风险的人能做出什么。很久以前，Kali Linux 把我带入了编程世界。它有一句很棒的话：“你越安静，能听见的就越多。”我觉得现在也适用。别人跑得越快、越失控，你反而更应该慢下来。速度不仅有大小，也有方向；当执行成本变得极低、速度的量级几乎可以免费获得时，就更应该有意识地选择方向。
要选对方向，就必须放慢下来思考。我的同事 Arjun 很久以前送过我一本好书《七种力量》（Seven Powers）。它讲网络效应、规模经济、品牌等非技术因素。当执行趋近免费，这些因素反而是让业务形成防御壁垒的关键。你需要明白，重要的不只是执行，还有方向；要拉远视角，选择你要参与的游戏，弄清自己在哪、边界在哪里、有哪些限制、竞争对手如何攻击你、你又如何保护自己。所有事情里最重要的一点，是抵抗不断分心的冲动。
如果你只在一个项目上坚持两天，投入三天的人就可能超过你；而坚持一个月、六个月的人……（此处原始转录存在较长缺口，句子未完整收录。）
今天这个房间里，每个人在某种意义上都是新手。此刻没有高级、初级、Staff 或其他职级之分。接下来今天和明天，我们都可以一起动手做东西，希望能有好成果；即使没有，也把它当成一次轻松的冥想吧。外面的世界可能正在失控，但我们不必如此。谢谢大家，祝我们度过美好的一天。哦，我们还有提问时间。具体能回答几个我也不确定，但可以问几个。
一个问题，或者一个观点也行。
你刚才说应该放下过去关于代码审查的一些做法。我很好奇，这怎么适用于金融软件？在这种软件里，精确性和对系统行为的掌握尤其重要。
我明白。这里要考虑几个维度：你写的软件是不是直接处理资金？它是有状态还是无状态？上线之后能不能修补？比如加密行业的软件既涉及金融、又有状态，很多情况下还无法修补，相当于把难度调到最高。因此我的做法是：风险较低的代码库，可以放开手大胆实验；更难、更关键的代码库，我们则在重新设计整套测试基础设施。比如我们正在对 Tempo 节点做确定性模拟测试，本质上是通过系统性模糊测试来检验整个系统。
如果没有这些测试，我暂时还不能放心减少人工审查和手动测试的工作量。因此在那些“最高难度”的代码库里，目前确实还做不到完全放手；但 TypeScript 前端这样的系统，我们可以这么干，也确实在这么干。对于有状态、涉及金融、上线后无法修复的系统或者智能合约，我的思路就是：必须先把测试工具提升到新的水平。
接下来该怎么办？（录音中问题残缺。）
“代码质量”也许会变成过去时代的产物。你可能要重新想象它究竟是什么意思。想一想，你如今通过 Agent 来使用几乎所有代码，不一定直接阅读代码。过去一年你读过多少汇编？或许你读过；我们在加密项目里为了极致性能确实读过汇编。但大多数人不会。所以，压缩后的 TypeScript 看起来很糟，对吧？代码质量可能会变成一个老梗。
现在默认让 Claude Code 或 Codex 写代码，它们似乎更倾向于 TypeScript，至少我自己的体验如此。如果你推荐 Rust，那么在 vibe coding 的时候，Rust 有什么优势？性能会更好吗？
简单说，就算 Rust 代码看起来很烂，性能通常还是会更好。这就是最直接的答案。
我觉得创造力很多时候来自摩擦：有边界、有约束，才需要想出绕开限制的办法。现在我们开始一个业余项目，几乎感觉不到摩擦，无非是提示、等待、管理 Agent。怎样主动引入一些摩擦，让人真正创造并面对有趣的约束呢？
我不知道。我同意你：美感常常来自深度沉浸，而你不再亲手写代码、只是从更高层俯瞰时，确实会失去一些沉浸感。
这的确是个挑战，我还没有解决方案。我觉得它和前面所说的注意力涣散问题是同一个根源。也许时不时亲手写一点代码，能让自己保持真实的感觉，但我也不确定。再来最后一个问题。那边请说。这个问题我未必最有资格回答，但我觉得它问到了关键点。（此处转录缺少完整提问。）
我们办这些精彩演讲，某种程度上也是出于自己的私心：就是想向大家学习。谢谢所有人，祝今天愉快。
让我们给 Quinn 一点掌声！
Quinn Slack（Amp）：我们如何用 Amp 构建 Amp
嗨，大家好！我是 Amp 团队的 Quinn。今天会尽可能互动，大家随时可以喊话、打断。
我早就习惯被一大群人喊来喊去。我有三个孩子，而且我们和 Tempo、Paradigm 的团队共用一个 Slack 频道，他们对什么事都特别挑剔。
我想带大家看看我们究竟怎样开发 Amp。它是现在比较重要的编程 Agent 之一。不过开始之前，我听说大家都想要免费额度。那我们边讲边现场做一个功能吧。谁经常用语音听写和 Agent 交流？对，听写是最棒的。我们做一个特别快的改动：只要用户在 Amp 新建会话，消息里出现 frontiers 2026 这个字符串，就在转录界面出现一段符合 Paradigm Frontiers 风格的炫酷动画。点击它就能领取 50 美元额度。我会把兑换码设成类似 Amp Frontiers 的特殊拼写，也便于传播。还有，我现在正在 Amp Design Talk 这个会话里给大家演讲。功能部署到 main 并上线后，能不能在我正在展示的幻灯片底部出现一个小提示？整个过程就放在 Amp Design Talk 线程里操作。
我觉得没必要亲自审查这个，直接推到 main 就好。好，让它自己工作；演讲过程中我们再看看进展。我还把幻灯片做成了这个样子。有人看着头疼吗？我也不太确定，等会儿看看实际效果。先介绍 Amp：没听说过的朋友可以把它理解为 Claude Code 或 Codex 的替代品。当然，现在人人都在做同一类产品，我们必须有自己的特色。这是我见过竞争最激烈的市场。对你们和你们的公司来说，选择哪个 Agent 是非常大的决策。很多人的做法是每个都用一点，足足用七种。稍后我会谈到为什么我觉得这不是好决定。我们采取了尽可能极端的路线。Amp 关注的就是把趋势推向极限：如果快进到几年后的世界，我们今天会怎么建立公司、怎么构建产品？
很显然，从 Amp 创立开始，我们就决定用 AI 来打造 AI 产品。现在这似乎不那么有争议了，但仍有人说“凡是 AI 写出来的东西都是垃圾”。可我们做出了一个用户觉得相当令人愉悦的产品。我们希望成为一个明证：即使用 AI 开发，照样能做出精致、好用、令人喜欢的东西。AI 不等于粗制滥造。我们还把公司组织成了自己认为未来公司应该有的样子。Amp 是一款重要的 Agent 产品，而整个团队只有 21 个人。对一些小创业公司来说，21 人听起来可能不少，但其他做 Agent 的公司有五百人、一千五百人。我看到一个竞争对手说他们星期一新入职了 19 人——那几乎就是我们公司的全部人数。这太疯狂了。
我不明白，如果公司有那么多人，你怎样形成恰当的反向压力，迫使团队真正理解什么叫所有工作都交给 Agent 来完成？
我们用 Amp 来构建 Amp。今天就分享一些对我们很有帮助的内部做法。这些方法并非 Amp 独有，其他 Agent 理论上也能实现，或者迟早会复制。先交代一下技术背景：Amp 是一个基本采用 TypeScript 的代码库，只有一部分 iOS 代码例外。代码很多，但我们不怎么在意代码总量。我们几乎不停地部署。正如 GK 刚才说的，我们不进行代码审查——从来没有。我们觉得这是最愚蠢的做法之一。GK 展示了一张 PR 数量指数上升的图，但有一点我不同意：我认为 PR 数量很快会大幅下降，因为 Pull Request 会拖慢速度。我们每天部署 90 次。从推送代码到所有用户都用上新版本，只需要七分钟。
我们并不提供自托管版本，也服务大型银行。如果加入代码审查，七分钟可能莫名其妙就变成一天。尤其审查的是 Agent 写的代码，人工代码审查几乎是一个人一天里最痛苦的事。好，这就是我们的应用背景。下面讲几种有帮助的 Agent 用法。很多方法在一两个月前还做不到。第一件事是：你不应该站在那里等 Agent。应该给它非常长的“绳子”，也就是尽可能大的自主空间。如果你特别介意 Agent 响应有多快——当然我刚才为了做现场演示也在等——通常说明你给它的任务范围还不够大，没有让它做足验证，只在整个流程的一小部分使用了 Agent。
应该把范围扩大。让 Agent 不仅帮你执行，还参与决定做什么、怎么做；完成开发之后，继续让它负责发布、跟进生产情况、确认问题确实解决。让它有更长的自主执行链条，并不断挑战自己这么做。构建和使用 Agent 最难的地方之一，是像 GK 刚才说的，始终保持开放。你必须不停地问自己：“我还能怎样做得更好？”有时候真的很累，但我想在场的人也不会愿意回到过去。我还有一个战术：不要和 Agent 一步一步反复迭代。别每次都说“改这里，再改那里”。
因为那样每个来回你都得等。更好的做法是，一次让 Agent 返回一整份备选菜单。原则上你也能让人类这样做，但如果让一个优秀的人花三四天做出一堆方案，明知最后只会留下其中一个，他可能直接辞职；如果他不介意，你大概也不会想雇他。Agent 则很适合同时探索多个方案。你只需要看完说“选 C”。我就是这样设计 Amp 语音听写时那个小波形动画的。为了把微小却有趣的细节做好，我根本不知道该从哪里下手，就让 Agent 先提出很多版本，再从中挑选。还有一个特别有用的思路：问自己，什么才算无法反驳的证明？
做个思想实验：Agent 改了一大堆代码，diff 很大，你没读过。假设它拿出一笔十亿美元的保证金，保证改动完全正确，而且有 GK、Jamie Dimon 等人背书；如果出问题，这十亿美元就归你。你是不是就会安心点击上线？当然这只是思想实验，我们并没有真的这么做。但它说明，理论上 Agent 可以向你提供足够有说服力的证明，让发布决策变得容易，并让证明的责任落在它身上。我举个真实例子：Amp 里有个图标会轻微抖动，我想确认这个问题是否彻底修好。
我让 Agent 逐帧检查视频，向我证明每一帧里图标都没有移动。我的提示词其实就是随手乱写的，不存在什么神奇提示技巧，只要清楚说明你想要什么。Agent 自己分析视频每一帧，给出可核查的证据，我一眼就能大致判断有没有问题。所以要向它索取不可反驳的证明。如果你不知道该怎样证明，Agent 通常也很擅长帮你设计证明方式。另一个办法是小规模评测。模型在实验室里接受过很多 AI 研究相关训练，因此很擅长做各种小型 eval。尤其系统里有非确定性环节，需要验证效果时，你完全可以让 Agent 自动运行多组测试，并把实验条件控制好。
我觉得各家先进模型在这方面都挺厉害。我们每次修改系统提示词、工具或指令，就让 Amp 使用本地开发版本跑三次、十次，不需要上千次，看看是否真的管用。这是一段听写出来的提示词，看着很乱。我们想看到的是表格里的某一列出现零。对于开发任何 Agent 系统，这都特别有用，因为这些系统本身具有非确定性，必须实际运行，观察不同模型的反应。
还可以把实验扩展到更多维度。刚才可能只测了一个模型；如果你的产品要支持很多模型，就对不同模型都跑一遍。再说我个人的习惯：我几乎一直使用语音听写。使用 Agent 的本质，就是把脑子里想要的东西传达给它。有些人说自己有三百个 Skill，有很多秘技，我觉得这些所谓技巧没有那么神。关键就是弄清你想要什么，然后完整传达。只靠键盘打字，有点像拿吸管呼吸。你得习惯直接说话。如果你在办公室里不好意思听写，那恰好是一个不去办公室上班的理由。有一次我在飞机上用小麦克风讲话，空乘还来找我。
因为周围乘客投诉，担心我在干什么奇怪的事。但不管在哪里，都要想办法用语音。我自己有时也会遇到问题：比如在纽约参加线下活动时，很难对着设备说话。但总体来说还是要尽量听写。我只用最新、最强的模型。GK 刚才也说了，要尽可能进入一家给你近乎无限 Token 预算的公司。如果一家公司给员工开高工资，却舍不得给他们足够的 Token，那简直太蠢了。就像福特汽车工厂雇佣工人，却让工人自己掏钱买螺丝和电动工具一样，完全说不通。确实有便宜模型，在某个已知任务上可以证明它成本更低，但它可能有 10% 的时候会做错，而你不知道错的是哪一次。
实际上绝大多数 Token 消耗、绝大多数 AI 支出，以及人们通过 AI 创造的大部分成果，都集中在最新模型上。在座很多人都身处竞争非常激烈的领域，对手很可能已经在用最强模型，你也必须这样。如果纯粹为了玩，可以试别的模型；不过为了玩得开心，也可能更想用最新的。我还注意到，人们正越来越多地离开电脑，在 iPad、手机乃至手表上工作。我认为你应该建立这样一种能力：无论在哪里，都能把脑海里的想法传达给 Agent。顺便一提，那是 Puck，我们的吉祥物形象。
不论身在何处，都应该能给 Agent 发送任务。工作用一个编程 Agent、生活里另用一个私人 Agent，到了外面又只能操作其中之一，这体验很糟糕。两者之间的边界实际上正在瓦解，应该能在任何地方无阻碍地传递意图。
零摩擦非常重要。Agent 看似已经降低了很多摩擦，但如果你还必须始终把笔记本打开——
或必须进入某个特定应用，那仍然是实实在在的摩擦，会阻止你像本来应该的那样频繁使用 Agent。先看看刚才那个任务。好，领免费额度的小提示已经在工作了，我把它放大一点。接着讲。回想 Agent 使用方式的变化，真的不可思议。年初在编辑器里使用 Agent 的举个手？不少。用 CLI 的呢？我们已经砍掉了编辑器扩展，甚至砍掉了 CLI；现在团队自己不再用它们。今年才过了一段时间，工作流就已经变了两次。基本上可以粗略地说，Agent 现在都运行在云端。因为迁到云端之后，它不仅可以做更多事，还能自己建立多个工作环境来跑小规模 eval。
Agent 可以自行启动工作，不再绑在你的笔记本上。我从来没见过哪个产品需要这么频繁地重新发明自己。现在我们全部运行在云端，把云上的 Agent 工作空间称为 Orbs，其他公司可能叫 Cloud Agents。通过原生 App、网页、手表等入口操作它们。以上是我们个人怎样使用 Agent。接下来讲公司怎样工作。原则很简单：Agent 擅长构建，而且越来越擅长更多事情，那么未来公司究竟会是什么样？我们没有路线图。有些基础设施公司接到我们的需求，会说“我去问问 PM，看看能不能排到第三季度的路线图”；另外一些公司直接说“今晚给你上线”。前一种公司我觉得根本活不下来。
我们绝不想变成前一种。我们每周只开一次会，代码也几乎没有归属边界。代码归属是另一个巨大障碍。假设公司非常支持 Agent，可你负责的代码一旦涉及别人的模块，就得去各团队申请权限。这种事最能消耗人的精力，也把 Agent 的能力锁死了。Google 曾经推崇大型统一代码树，还有一个理念：把测试做好，做到即使一个又笨又恶意的人来改代码，也没法轻易把系统弄坏。你应该用类似方式思考为 Agent 准备的代码库。你不真正“拥有”某一块代码，而应该确保你修改过的东西，未来 Agent 也能理解如何不犯错。
这需要把人的意图写进代码或紧贴代码的文档：为什么当初这么做、为什么要这样设计？让未来的 Agent 能查到。这样任何队友都可以解决任何地方的问题，这也是我们能保持 21 人团队的重要原因。我们还有一个听上去挺玄学的原则：去做能给你带来能量的事。
Orbs 的使用量一直大幅增加。随着模型变强、我们能给它们越来越长的执行链条，整个团队的开发速度提升得极快。有一段时间我们不得不彻底重建 Amp。记不记得大约三四月份那会儿，Amp 好像什么也干不好，又慢又没用？Tempo 的朋友一定记得。对此我很抱歉。但我们最终走出来了，几乎把整个产品重建了一遍。传统软件公司不会轻易干这种事，但现在这种技术变革就是会逼着你这么做。我们还大量使用 Feature Flag（功能开关）。以前这东西到处留下历史包袱，代码里布满废弃开关；想新加一个，还得了解很多地方。
如今 Agent 很擅长处理功能开关。我们觉得一个新功能不错，就先发布，让愿意尝鲜的用户自己开启。我们还给 Agent 一定范围的生产数据库只读访问权；涉及额外权限时，可以申请必须经人批准、仅持续三小时的临时授权。通过这套机制，它能看到哪些用户开启了功能、用户行为如何变化、是否完成更多任务、有没有报错。它还能访问 GCloud 日志。如果用户打开又关闭了功能，我们也能知道。接着 Agent 可以给用户发邮件征求反馈，分析他们回复的内容，再给他们 10 美元免费额度。围绕功能开关形成了一整套流程。
因为模型现在很擅长写带 Feature Flag 的代码，还能自主发布，所以很多操作都可以变成自助式甚至自动化。一个线程的代码推送完成后，我们也不急着关闭它，而是让它继续监控变化。
举个例子：Amp 最近增加了对更多 BYOK（自带密钥）选项的支持。各种服务商的 API 端点都不一样，很麻烦，也容易出错。我只要告诉 Agent：“有这么多用户想要这个功能，先选哪十个用户开放？”开放之后，再问“这些用户在用哪些服务商？遇到过问题吗？花了多少钱？”如果没有这套机制，这类工作大概需要额外招聘产品经理和不少工程师，还会显著拖慢速度。是的，我们真的不用 Pull Request。这里有谁用自己那可怜的人类大脑审过代码？来举手。我的意思只是和现在的模型相比，绝不是冒犯大家。
上周审查过 PR 的有多少？好。谁觉得这简直蠢透了，只是机械照搬过去的流程？真的有人从代码审查中获得快乐吗？哦，这里有一位！太好了，你可以负责审我们所有的代码。刚才有人问，金融代码怎么能没有代码审查？我们观察到一个很有意思的现象，至少大型银行如此。我不确定在这个房间里提银行会不会有人朝我扔东西，不过还是说吧。
真正放不下那些旧流程的，恰恰是过去因为擅长写软件而自以为非常了不起的软件公司。但现在，单纯擅长写软件已经没那么重要了。
他们死守陈旧的软件开发流程。反而大银行对这些东西没什么感情，只想赚钱。他们不在乎有没有 Code Review，只在乎监管方能否接受，以及最终是不是好产品。很多非软件公司也是这样，不会对代码审查怀有感情。那些在 2022 年风光过的软件公司才更容易固守旧办法。今天要带走一条建议的话，就是回公司试一试：先让 20% 的 PR 不经人工代码审查，按风险打分，再逐步扩大比例。我们看到，很多人还在 PR 评论里提问、用审查机器人反复沟通，那就像马车时代的习惯一样。
当然，我们不是完全不希望队友反馈，只是可以直接邀请同事加入 Agent 会话，不需要经过 PR。我展示的这个案例里，一次改动可能出现了问题。我们说“先发布，密切观察上线情况”。这是真实线程，结果日志确实发现了 Bug，于是我们撤回了改动。稍后也会展示一个邀请更多人一起参加的案例。
我们把用户使用产品、遇到故障、报告 Bug、内部排查和修复整个流程连通了。用户报告 Bug 时，我们得到带有诊断信息的包。这里有人在 Amp 报过 Bug，之后收到邮件的吗？你们看到的是用户端，我们这边会收到诊断记录。点击“I'm feeling Pucky”或者“Ultra Pucky”——那是我们吉祥物的名字——就会启动一个 Amp 线程，里面带上必要的诊断信息。只在相应线程范围内访问该用户会话数据，以及相关日志。接着 Agent 自己分析问题、找出原因，我们就能交付修复。
对用户来说，有时十五分钟甚至更快就修好了，体验真的很好。Agent 还被允许发送邮件，但邮件的文字必须经过人工审查并最终确认。我们会说：“嗨 Alex，谢谢你的反馈”，再送一点免费额度，把反馈闭环做好。我们根本没有专门的客服团队，也不想再增加一个。因为大家都用 Amp，我们可以把公司的工作方式整个围绕它来打造。日志检查、缺陷上报、支持系统都集成在 Amp 里。它能发邮件、发额度；遇到事故，它也知道怎样去 Grafana 排查到底哪出了问题。
统一使用一个 Agent 有巨大的优势。OpenAI 内部都在用 Codex，Anthropic 内部用 Claude Code；一些公司却七种 Agent 混着用，不停切换，有时还只是因为某个工具 Token 不够或者预算限制。其实如果持续投入同一个 Agent，能从它身上得到更多价值：可以围绕它构建自动化，把公司整体组织起来。我知道，这听起来极其利己——毕竟我是做 Amp 的。但我的观点是，选哪一个不重要，用好一个比同时用七个更好。这里一个特别酷的功能是多人协作。团队所有人都在同一套 Agent 里，才能真正把同事拉到同一个线程。
过去有事会在 Slack 讨论，内容和执行工具是割裂的；或者放在 PR 里讨论，也不理想。现在大家直接在 Agent 会话里聊天，每个人都可以向 Agent 提问，在这里共同做决策。如果你们分别使用七种 Agent，甚至用的还是运行在个人电脑上的 Agent，就没法把别人轻松拉进同一个工作上下文。你突然需要同事帮忙，却无从着手。这就是我理解的未来。再往上看一级：未来公司的形态是什么？因为只有 21 人，而且已经盈利，我们有条件做些更激进的实验。
昨晚团队里刚发了一条消息，我不是为了今天的演讲而安排的。它恰好体现了我们对这场 Agent 浪潮的理解：它会彻底改变公司结构、工作方式，以及人在公司里的角色。逻辑如果推演到底，就会发现不愿改变的公司终将被真正贯彻这些原则的对手击败。我们希望拥有 21 位像联合创始人一样投入的人。这样就不必天天计较 Token 花费，也不用反复担心“这个人可信吗”。
以前我一听“心理安全感”，还会想“这到底是什么鬼话？”但现在我懂了：团队里每个人都敢试、敢失败、敢实验、敢和别人争论，这是一种高度开放的氛围。那些在 2022 年就膨胀成大公司的组织很难做到；最近才成立、却按传统岗位一下招来很多人，员工入职时间不同、持股很少、没有太多利益关联的公司，也很难让大家拥有这种安全感。它们很可能被另一种每个人都真正关心公司命运的组织击败。回头看前面的幻灯片，我们几乎每个人周末也都在努力工作。
如果对手员工人数是我们的三十、四十、五十倍，收入却跟我们差不多，那我非常欢迎这种竞争。我们也相信“软件已死”，虽然还没看到尸体。很多传统工作流工具明显不太对劲，但我们其实一直在创造各种定制软件。比如我现在展示的幻灯片，就是我们自己开发的小工具做的。你可以看到所有幻灯片都在这个界面里。为自己制造软件已经变得特别容易。做业余玩具固然有趣，但把你专门为自己开发的工具直接嵌入日常工作更有意思。这也可以成为你们黑客松的一个创意。喜欢这个幻灯片应用的话，可以去 amp.store 自己改造、混搭，我们正在那里做一些小实验。那么“软件已死”到底是什么意思？
我说的并不是软件包会消失，而是过去二十年里，大量聪明人和他们的智力被锁在“为软件公司开发软件”这件事里。未来不会再这样。那些聪明人将转向真实经济：制造业、金融业，以及真正生产实体东西的公司，去解决真实问题。过去有那么一段特殊的历史时期，人们可以只为其他软件公司造软件而获得巨大回报。我认为那段时期已经结束了。死守它的人恐怕不是你想共事的、真正拥抱 Agent 的人。我对这个转型非常兴奋。来，让我们鼓掌。好，看看刚才的改动——已经推到 main 了。
应该马上就能在 Amp 的任意会话里输入 frontiers 2026，看到一个漂亮的界面并领取免费额度。真希望它再快一点。不过我刚才说过，要给 Agent 更长的绳子，我们让它做了更多验证。还有时间问问题吗？（主持人宣布演讲结束。）谢谢 Quinn。黑客松期间我们还会一直使用 Amp。
很棒的软件！谢谢 Quinn。
Suraj Nair（Physical Intelligence）：通用而高性能的机器人智能
下一位是来自机器人公司 Physical Intelligence 的 Suraj Nair。他们在研究通用模型、机械臂等东西，其中有些我也未必能完全理解，希望大家今天能学到东西。Suraj，交给你了。哦，先把翻页器给你。让我们欢迎他！
谢谢！大家好，我是 Suraj。今天会讲一个稍微不同的话题。
我想聊机器人，具体来说，怎样让机器人具备既通用又高性能的智能。Physical Intelligence 从成立第一天起，使命就是为机器人打造一颗通用大脑：同一个模型，可以控制任何机器人、在任何环境执行任何任务。这在技术上意味着什么？我们开发的模型通常叫 VLA，也就是视觉—语言—动作模型。一般而言，VLA 从一个预训练基础模型开始，通常是 VLM（视觉语言模型），再把它适配成能端到端控制机器人的系统。具体说，一个原本接收图像和文本、输出文本的模型，要被训练成接收机器人的世界视觉观测和文本指令，最后输出能驱动机器人在真实世界行动的控制信号。
比如“折一件衬衫”，模型就要生成接下来几秒内的关节角度等动作。训练完毕后，可以用闭环方式运行，每秒推理两次、五次，持续感知、反馈并操控机器人完成任务。这就是 VLA 的一般框架，也是我们在做的模型。2024 年秋天，也就是公司创立约七个月后，我们第一次尝试了这样的模型，叫 π₀（Pi Zero）。那时我们刚收集了第一个多样化机器人数据集，大约一万小时的数据。有了 π₀，机器人开箱即用可以完成一些简单任务，比如收拾餐桌；也可以再微调或后训练，让它完成极具挑战性的任务，或者高效适应以前从没见过的新任务。
当时 π₀ 给了我们惊喜：这种训练范式竟然能获得如此高的灵巧性和能力。一个模型端到端控制机器人：先移动到洗衣机前、打开门、拿出衣服放进篮子，把篮子搬到桌前，再一件件开始折叠。机器人当然还远不完美，但要知道就在几年前，让端到端模型直接控制机器人完成这样的连续任务，还近乎难以想象。看到这里，你可能会问：为了做这个演示，我们是否必须在这间具体的屋子、这个具体环境和任务上收集数据？
简短的答案是：是的。实际上，你如今看到的几乎所有机器人演示都差不多——先在要展示的那个任务、那个环境里采数据，再让机器人接受测试。这不太令人满意。因为回到我们最初的目标，我们真正想要的是通用模型：机器人能够进入任何环境执行任务，包括从未见过的房间。这引出了下一个挑战：能不能让模型在陌生环境里完成刚才类似的工作？为什么难？举一个看似非常简单的动作：打开柜门。
不同环境里的柜子形状、开合方式都不同，要求的底层灵巧动作差异很大。机器人要完成同一件事，可能必须采用完全不同的物理策略。任务链越长，问题越复杂。因此我们需要在底层运动控制上实现很强的泛化能力。怎样做到？和很多端到端模型一样，我们主要依赖多样化数据。具体有几种来源。先看右边：我们采集多样化机器人数据，把固定式机器人和移动机器人带进各种场景，收集它们在几十个不同卧室里折衣服的数据。
这就是大量真实环境下、不同移动与固定机器人产生的数据。我们还把它与 π₀ 阶段积累的、来自不同机器人形态以及实验室的跨本体数据组合起来。多样化机器人数据是第一块重要拼图。第二块是互联网数据。标准的视觉语言、视觉问答任务涉及各式各样的场景，你可以让模型做物体检测或图像描述，从而教会它跨环境理解场景。我们沿用与 π₀ 类似的训练流程，但使用数量更多、来源更广的数据。接着让机器人进入那些我们从未采集过数据的房屋。这就是我们 2025 年 4 月发布的 π₀.₅（原稿自动识别为 Pi 5）。
视频里 Chelsea 正在给机器人指令，让它在一座全新的房子里完成许多任务，有的连续十分钟：清理厨房、到处移动、把叉子盘子放入水槽、擦掉洒出的东西等等。另一个场景里，我们的同事 Laura 让机器人整理它从未见过的卧室。我们看到，它不仅能泛化到陌生环境，还能在新场景里执行有一定难度的灵巧动作，比如整理床铺。这是重要里程碑：端到端机器人模型第一次在没有见过目标房屋训练数据的情况下，开箱就能完成这类任务。多样化数据究竟怎样帮助了模型？我们进一步研究了不同训练房屋数量与性能之间的关系。
这张图的纵轴是机器人在陌生房屋里的表现，横轴是训练数据中包含多少个独立地点。第一点并不意外：训练场景越多样，模型对陌生房屋的泛化越好。特别有意思的是，当训练混合数据包含大约一百个不同房屋时，模型已经能达到使用目标环境数据时差不多的表现。图中的绿色柱子代表“作弊”条件——假设我们事先也拥有目标测试环境的数据，模型会有多好。只靠大约一百个不同房屋的多样化训练数据，就追平了在目标环境采数据的效果，这让我们非常意外。
但性能仍有缺口。即使在目标环境里采过数据，模型的表现距离我们想要的高可靠性依旧有一段距离。我们开始思考：怎么进一步提升性能和速度？尤其能否通过让机器人从自己的错误里学习来做到？用一个任务说明高可靠性有多难：我们想让机器人制作浓缩咖啡，成功率超过 90%。这个过程有很多难以建模的细节。例如研磨咖啡时要掌握准确时机，压粉、把手柄装进咖啡机时需要非常精密、对力度敏感的操作，最后还要处理装满液体的杯子。
这些东西很难用明确规则写出来。高可靠性的策略必须反应灵敏、能够适应变化，识别失败模式并从错误中恢复。我们想探索的核心就是：怎样让它学会从失误里恢复？左边的例子是质量不错的常规遥操作示范数据：一个人控制机器人，把任务正确执行出来。通常我们会想让模型模仿这种理想动作，但其实数据里也会有各种失误。
即使专家采集的遥操作数据，也会有掉落咖啡手柄、洒出牛奶之类的错误。如果能同时从这些失败中学习，就太好了。模型自己在真实场景中的自主运行记录也是一样：放手让模型尝试，观察成功和失败，里面包含大量关于何种动作有效、何种无效的信息。我们还可以让人监控机器人的自主执行，看到它要犯错时介入并提供纠正。总之，我们想要一种方法，能吃下所有这些数据。
包括遥操作数据、自主 rollout 记录、对自主策略的人工干预；其中既有高质量动作，也有错误和恢复过程。利用这一切，训练出高度可靠的策略。这就是我们去年秋天发布的 π*₀.₆（原稿识别为 PiStar 06）的核心想法。细节今天不展开，之后欢迎提问。简单说，用前面那些多样化的遥操作和评估数据，不仅训练一个策略，还训练一个价值函数（value function）。这是强化学习方法：价值函数估计从某一状态出发，到完成目标还有多大进展，也就是“我距离任务成功还有多远”。
有了价值函数，就能评价每个具体动作是让我们更接近目标，还是更远离目标。带来正向进展的动作叫正优势（positive advantage），相反则是负优势（negative advantage）。好处是有了这种标签后，你就可以把所有数据——连错误的动作也一起——喂给模型，只不过训练时要加条件。以前模型看到衬衫和“折叠衬衫”指令，就预测一个动作；现在可以说“要产生正优势，就预测这个动作；如果产生负优势，就对应另一个动作”。
这样模型就能学习范围广得多的状态和动作分布，推理时再指定“我要高优势的行为”，自然会得到表现更好的策略。这个方法就是 π*₀.₆。我们发现它确实能带来非常可靠的执行。例如办公室里的一台机器人连续工作了大约 13 个小时，给大家做咖啡。大家下楼取咖啡，再回去工作，它就全天自主运行。我们还与旧金山 Mission 区的 Dandelion Chocolate 合作，让机器人制作、折叠和贴标巧克力包装盒，使用相同方法训练出能连续运行数小时的策略。
那台机器人可以连续几个小时制作 Dandelion 的包装盒。
最后，我们还想确认：这种高可靠性方法，会不会牺牲 π₀.₅ 阶段获得的泛化能力？模型即使速度和可靠性提高了，也应该能处理陌生环境、陌生物体。所以我们再次让机器人在一个从没采过数据的房屋里折叠刻意留出的新衣物。结果它仍然可以一篮接一篮地折衣服，连续工作数小时。量化这类方法的好处时，我们不能只看成功率，还要看速度，因为强化学习方法也会让策略变快。所以我们测量了吞吐量：加入由评估驱动的自主执行数据后，吞吐量基本提高了一倍。
此后，我们把 π₀、π₀.₅ 和 π*₀.₆ 的一些思路结合起来，通过后训练让模型完成很多复杂灵巧任务：移动机器人打开门再通过门口；制作烤芝士三明治；削皮、切蔬菜；以及像装配纸风车这样非常精细的任务。到这里，我们对“针对单个任务训练一个专家策略”的能力已经很有把握。但所有这些案例都需要针对任务做额外微调。
我们每次先取一个预训练模型，再针对具体任务进行后训练。可回到最初愿景，我们希望一个模型就能泛化到所有任务，不必为每件事都训练一个专家。这会大幅扩展实际用途。实现它的路线，在其他领域已经被反复验证：扩大训练数据的规模和广度，同时确保模型真正有能力吸收这些数据。在数据层面，答案就是“全部都用”：π₀.₅ 和 π*₀.₆ 阶段收集的多样机器人数据、不同硬件形态在各种环境中完成任务的数据、模型自主与现实世界交互的数据、互联网数据。
还可以把人类第一视角视频当作另一种“机器人形态”的数据，混合进训练。数据侧的核心就是尽可能兼收并蓄。但随后出现一个技术挑战：怎样让模型有效拟合如此庞杂的数据？我们今年春天最新工作 π₀.₇（原稿多次识别为 Pio 7）的关键方法之一，是多样化条件输入（diverse conditioning）。什么意思？不再只给模型一个“折叠衬衫”的文字指令和一帧观测，而是给它更丰富的上下文，让模型能根据这些信息调整行为。
比如除了“折衬衫”，还可以给它一张目标图，表示“我要最终达到这个状态”。也可以提供各种元数据，例如前面提过的优势条件，描述动作质量或速度。训练时，我们随机选取、组合这些不同类型的条件。还会给模型更长的上下文记忆：不是只看当下这帧图像，而是例如同时看过去十秒的图像。更丰富的上下文帮助模型有效拟合训练分布。直观来说，条件越明确，模型需要拟合的行为分布就越不那么多模态、越容易学习。
这也让推理阶段更灵活。你可以只说“折衬衫”，可以给它目标图让它达到那个状态，也可以要求快一点或慢一点，模型变得很容易引导。π₀.₇ 最先让我们兴奋的一次测试，是回到 π*₀.₆ 做过的任务：多样化衣物折叠、浓缩咖啡、包装盒制作。过去靠微调专家模型达到的速度和性能，π₀.₇ 竟然用同一套预训练权重、一个模型全部追平。换句话说，一个预训练通用模型就达到了专家后训练模型的表现。
其他复杂任务也有相同趋势。我们又测了做花生酱三明治、切削蔬菜、倒垃圾等。所有这些任务，单个 π₀.₇ 模型开箱即用的效果，都能匹敌各自微调后的专用模型。接下来要追问：究竟是什么让它做到了？实验显示，多样化条件输入非常关键。图的纵轴是模型表现，横轴是训练中使用的数据比例；数据按我们估计的质量由高到低排序。
随着横轴向右走，训练数据越来越多，但新加入的数据质量也越来越低。如果不加条件、天真地把所有样本混在一起训练，不告诉模型样本 A 和样本 B 哪个好、哪个差，那么增加数据带来的收益很小；加入低质量数据之后，效果甚至会略微变差。而图中黄色曲线代表有正确元数据条件的训练：不仅整体性能更好，而且能有效利用更多低质量数据，因为模型知道自己应该如何理解不同样本。
在最终任务表现上也类似：去掉元数据，性能明显下降；如果去掉模型自主执行收集的数据，也会下降。这说明让模型自主与现实世界交互，并从自己的经验中学习，是不可缺少的。前面提到，把所有技能装进一个模型还有利于泛化。其中一个改善很明显的指标叫跨本体迁移（cross-embodiment transfer）。训练数据里有许多不同机器人做不同任务，但有些任务可能只有机器人 A 的数据。
我们想知道，机器人 B 没见过这种任务的数据，能不能直接做？这就是衡量模型能否在不同硬件形态之间迁移知识。我们展示了几个任务，左边是源数据涉及的机器人，右边是被评估的另一种机器人。π₀.₇ 在所有这些跨本体迁移任务上表现都好得多。其中一个我特别喜欢的案例是折衬衫：几乎所有折衬衫数据都来自一种体积比较小的双臂机器人。我们从没有在那台双臂 UR5 工业机器人上收集过折衬衫数据，它的机械臂更大，配置差异也很明显。
可 π₀.₇ 直接就能在这个完全不同的本体上完成折衣服任务，这让我们很兴奋。图中的黄色柱子就是它的效果。如果在推理时进一步利用多样化条件输入，不光给“折衬衫”文字指令，还给一张目标图片，效果就更好了；黄色虚线柱代表这种条件。另一个明显提升是开放式语言指令遵循能力。我们把机器人放进从未见过的环境，提出各种天马行空的口头要求，看它能完成多少。
例如“把意大利面拿到台面上”“去把辣椒蒜酱拿过来”等，尽可能提出广泛而开放的指令，再统计有效执行比例。π₀.₇ 在这方面也取得了很大的能力飞跃。总结一下：π₀.₇ 让我们得到一个相当强的通用模型。它可以开箱即用，在一套权重里同时实现很强的泛化和接近任务专家的性能、灵巧性。现在我们也看到越来越多公司在真实世界尝试使用这些模型。左下角是前面 Dandelion Chocolate 的机器人；还有一批合作伙伴在包装、衣物折叠等真实场景中应用 π 系列模型。
用途甚至延伸到了操控重型机械。这里展示的只是众多合作公司的一个很小子集。如果你在做机器人公司、想合作，欢迎联系。除了我们自己能用模型做什么，更令人兴奋的是看到越来越多人拿模型解决真实问题。顺便说，我们团队也在招募许多不同岗位的人才。
我有两个问题。你们取得的进展，有多大比例来自模型本身，又有多少来自承载模型的机器人硬件？我看到倒数第二张图，同一个模型换到不同机器人上，性能就会变化。第二，如果你们给模型换上一台更好的机器人，比如更多执行器、操作更灵巧，会不会形成飞轮，进一步加速模型进步？
绝对会。这是非常好的问题。我们的目标本质上是打造一个几乎不依赖具体硬件的模型，让它真正理解物理世界中的智能和行动。因此我们才收集那么多不同本体的数据。机器人硬件生态还在快速变化，我们希望自己的模型能够适用于各种平台，包括未来几年才会发明出来的硬件。不同机器人之间能迁移知识，本身就是很大的好处。
第二个问题，确实如此。我希望看到一种生态：针对不同用途和任务，总有人会设计在那个场景中真正高效的硬件；而我们的模型能控制这些硬件，它们产生的数据再反馈回模型，让模型整体变得更强。这正是我们希望出现的飞轮。
传统编程模型不仅靠模型本身提升，harness 工程以及围绕 harness 的强化学习也有很大进步。机器人领域是不是类似？围绕你们模型的外围软件长什么样，创新正在发生在哪里？
这确实是个有意思的问题。瓶颈究竟在哪里，仍有不少未知。很长一段时间里，包括目前某种程度上，瓶颈仍然是底层运动控制：如何在高频率下控制执行器，通用地完成灵巧、动态动作。这一直是我们的重点。但随着底层能力提高，越来越多人在不同场景里使用这项技术，机器人模型外围肯定也会出现某种 harness。具体长什么样？
一种可能是更高层的语言任务规划。我们也探索过：高层模型不直接操控机械臂，只负责决定步骤，比如“我要整理厨房，首先得把地上的盘子捡起来”。这就是一种 harness。以后还可能有更复杂的方式，比如查询数据库：“我已经装配完这个零件，把状态记录一下。”这里面有大量值得探索的空间。谢谢。
简短问一下。数据经纪公司的数量正在爆发，有些增长速度堪称历史最快。数据特别是机器人数据很值钱。你们怎么看未来？已有数据是否足以打造非常有用的机器人，还是数据需求会持续增长？会不会趋于平台期？
我觉得这是一个开放问题。还需要大量研究才能知道，再增加一个数量级甚至多个数量级的数据，到底能带来什么收益。不同数据源应该怎样配比，比如遥操作、模拟和第一视角视频，各自该占多少？这些还有太多未知。真正重要的是最终什么组合能带来最好的模型。
所以这方面依然有大量研究工作要做。
我想听听你对语言的看法。VLA 里的 L 就是 Language。语言显然是人类下达指令所必需的，你前面也谈过一点。但机器人在内部理解世界和推理时，到底需要多大程度的语言参与？和世界模型等其他模型相比，你认为 LLM 今后会继续发挥什么作用？
很好的问题。语言显然是人和机器人交互的天然接口。接下来另一个问题是：如果机器人要在内部进行推理，应该在什么表示空间完成？不同空间各有权衡。我一点也不意外，最后可能是多种方式混合最有效。
比如，可以在文本空间推理任务处于哪个阶段；也可以像 π₀.₇ 所展示的那样，在图像等视觉空间推理，先生成一张未来目标状态图。π₀.₇ 也有这样的目标图生成器：收到人的文字指令，先预测“我应该达到的未来画面”，再把这张预测图交给控制模型。这实际上就是以图像为推理空间。不同任务可能适合不同表示，模型需要灵活地在各种模态中思考与推理。谢谢。
Sam Herring（Nous Research）：Hermes Agent，一款与你共同成长的开源 Agent
接下来是 Nous Research 的 Sam Herring。他们打造了 Hermes Agent，也做了不少去中心化训练和推理研究。值得聊的话题很多，欢迎 Sam。
大家好！2026 年 Paradigm Frontiers，星期二快乐。谢谢邀请。我是 Nous Research 的机器学习工程师 Sam Herring，在后训练团队工作。最近我也在旧金山做了不少开发者关系工作和演讲，想把 Hermes Agent 的魅力介绍给大家。举手看看，有多少人听说或使用过 Hermes Agent？哇，很多！看来各位已经很熟悉了。今天也许会讲一些大家知道的内容，但我想回顾 Hermes Agent 的历史，看看我们是怎样走到这里的。Hermes Agent 是一个开源 AI Agent 框架。我们的口号是：“与你共同成长的 Agent”。
我们大约从去年开始做 Hermes Agent，具体可能是秋天。最初只是内部慢慢开发的项目，并不知道会走向哪里。直到今年二三月份左右公开发布，事情突然起飞了。
Hermes Agent 可以在几乎任何机器上运行，支持 Mac、Windows、Linux，很快还会推出移动端应用。我们内置了大量工具和 Skill，但对于用户该如何组合技能、选择记忆方案等，我们希望尽量保持开放。任何你想集成进 Hermes Agent 的东西，都应该由你决定。我们还接入了很多消息平台，最初从 Telegram 和 WhatsApp 起步，也有 iMessage 连接器。用过 Hermes 的人都知道，你几乎可以通过无数渠道连接它。开源社区对 Hermes Agent 的采用和贡献让我们非常高兴。Nous Research 一直以开源为荣。公司在 2023 年成立时，做的就是开源模型的后训练工作。
当时主要是 Llama 和早期 Mistral 模型，我们开始建立工具调用的范式，设计自己的工具调用解析器。我们有一种判断：大语言模型的未来，很大一部分会发生在 Agent 的函数调用场景里。别忘了，在 2023 年，今天这样的 Agent 还不存在。整个社区和行业花了几年时间，许多进步逐渐叠加，才到了今天。工具调用范式，再加上我们很早就大量使用合成数据，推动了滚雪球般的进步。说回 Hermes Agent 的历史：当时 OpenClaw 已经出现一段时间，我们只是想给内部工作流找一个更好用的工具。
那时我们对 OpenClaw 的运作方式不太满意。团队里有一位联合创始人，某个周末突然特别想做自己的版本，于是就动手了。
（此处自动转录缺少几句完整内容。）公开发布之后，社区的采用和支持让我们非常受鼓舞。大家为它提交了成千上万行代码。
经过反复重构和优化，代码规模估计也有了很大变化。我们最初想做的是一个非常灵活、容易上手的 Agent，并没有预先设定某个唯一用途，只是有些地方不喜欢 OpenClaw 的设计。我们也不是一开始就特别强调速度，而是希望搭建的积木可以自由组合，并且能在未来继续扩展。它应该真的是“你自己拥有的 Agent”。重点是：它运行在你的机器上，数据放哪里由你决定，记忆放哪里由你决定，推理服务商由你决定，没有供应商锁定。这意味着最大限度的自由。几周前有人拿我们的竞争对手做了个类比，说那些把内部实现封闭起来的 Agent，就像 MacBook。
Mac 开箱即用、速度快、非常省心。身边不懂技术的人往往更愿意买 Mac，不需要管里面究竟发生了什么。反过来，Hermes Agent 更像 Linux：自己动手组装、自己解决问题，全部控制权都在你手里。这就是我们一直坚持的理念：任何人都可以按照自己的意愿，随时去做自己想做的事。还有一件尤其重要的事。
我们当然会提供默认工具和默认 Skill，方便那些不愿意折腾的人开箱就能用。但除此之外，我们不应该替用户做太多选择。最糟糕的是，你被迫困在一个不适合自己的方案里，而外面其实有更好的选择。这样的设计自然推动 Agent 生态不断演化，对我们来说也很成功。社区的采用和喜爱程度说明，人们很喜欢把 Hermes 变成自己的东西：fork、换皮肤、修改功能等。我可以一直讲这一点，但还是往下说。我们也在不断改进代码库和基础设施，努力让 Hermes Agent 的测试与运行结构更加稳健。
越来越多公开构建版本落到用户手里，各种边界情况不断冒出来，对全团队都是巨大的工程挑战。我想谈谈自己的 Hermes 使用经历。大约四月份，Hermes 还是个主要供内部使用的工具，尚未完全公开，我本人也用得不多。经理和联合创始人一直鼓励我试试。于是有一天我正在 Twitter 上聊天，有人说希望上传一张图片，就能找到主题、审美和风格最接近这张图片的在售衣服。
那张图未必是衣服。那位网友当时拿的是一件具有复杂花纹的陶器，希望找到和这种纹样相似、实际能够购买的服装。技术上，从一张陶器或艺术品图片去找相似图片，有无数种做法。比如 OpenAI 的 CLIP（对比语言—图像预训练）可以把图片映射到嵌入空间，再寻找相似图片。难点是需要获得真实的、正在出售的服装图片。我当时想，要是不用 Agent，先设计、再实现，大概需要两个星期。可我们正在 Twitter 上即时聊天，我很想马上证明这个想法是可行的。于是我想：这不就是试用 Hermes 的最好时机吗？
我在自己的电脑上启动 Hermes，交给它这个服装搜索任务。（原始转录此处丢失部分操作细节。）
最后得到的方案还可以继续完善，例如更广泛地覆盖品牌和设计师，但作为概念验证已经非常棒了。现在我想找新衣服、或者 Google 图片搜索很难搜到某个很细的审美风格时，还会用它。这相当于把图片相似搜索和购物搜索结合了起来。再讲个趣事：Hermes Agent 帮我找到了我的车。我在旧金山有两辆车，第二辆是一种开罚单用的小车。如果你去过旧金山，可能见过 SFMTA 开着那种三轮、三角形的小车四处巡逻。我非常想拥有一辆。二月份我第一次公开演示 Hermes Agent 时，就让它去政府拍卖网站帮我找。
最终我在五月份买到了它。从那以后我几乎天天开着在城里跑，非常喜欢。这故事说明了一个早期 Agent 用例：我只需要告诉它“每天去政府拍卖网站检查，找到这款非常特定的车”。以前我可能花几天写个自动脚本，再配上 cron 定时任务；但我根本不想管这些。Agent 模式让你直接把想法交给机器，让它持续为你完成工作。这也解释了我们为什么走到今天，市场上出现了成百上千种 Agent harness。过去六个月里，我自己的日常使用方式也发生了变化：起初做编程时我还是完全依靠 Claude Code 等工具。
我当时没意识到 Hermes 本身也可以成为那么出色的编程 harness。它有长期记忆，又能随着使用不断创建、完善 Skill。我的很多编程偏好和代码风格，它会逐渐记住。随着时间过去，我越来越不需要重复说明想让它怎样做。这个体验真像魔法，整个工作流也变得更高效。我觉得最酷的还是 Skill。作为研究人员，我需要执行某些固定任务，比如收集与当前阅读文献相关的论文，覆盖某个具体细分领域，形成一份文献综述。我可以把这样的流程保存成自定义 Skill。
需要时 Hermes 就能重新调用它。大家都用 Agent，应该都知道 Skill 是什么；我想强调的只是，我们很早就做出了一些设计决定，让 Hermes 可以主动为你编写 Skill。现在我甚至不用特意说“把这个写成一个 Skill”。一次会话结束后，它常常自动把流程保存下来，下次就能复用。比如当初帮我找车的流程，如果哪天我想找另一种车，我只要替换车型，Hermes 就知道从前用过怎样的搜索方法。最后想聊一下早期一个很酷的想法：递归式自我改进。
我们很早就开发了内部强化学习框架，并把它集成进 Hermes。我希望 Hermes 不仅能调用模型，还能发起训练任务。比如对它说：“帮我训练这个模型，并监控训练；如果效果不错，训练结束后我们再决定下一步。”这里真正有意思的是：假设 Hermes 当前运行一个模型，你可以在本机、其他设备或云端集群上，同时训练同一个基础模型的新版本。我当时也用过 Thinking Machines 的 Tinker 库。当训练结束后——
比如 Hermes 正在使用 Qwen 模型，而云端正在对这款模型进行新任务训练——你就把训练后的权重下载回来，替换 Hermes 里使用的权重，再继续让它工作。这种闭环很早就让我们看到，递归自我改进可能在一个 Agent 内部形成怎样的流程。我很高兴自己参与了这部分探索。如今社区用 Hermes 做很多事。看过 Nous Research Twitter 的朋友知道，我们每次发布的视频、公告里的视觉素材、艺术作品，包括音乐，几乎都由 Hermes 驱动工作流制作。创意团队通过 Hermes 把自己的想象力落地，真的很棒。家庭自动化也是一大应用。
有用户把智能家居设备和电脑打通，让 Hermes 自己摸索控制方式。还有人喜欢做小分析，例如家里装了智能宠物门，想统计自家狗一天进出多少次。
除了编程、创意与智能家居，大家还用 Hermes 做水电煤账单管理、邮件整理和一大堆其他日常任务。所以它远不只是 SWE 领域的编程工具。上周我们正式发布了 Hermes Bench 和 Hermes Index——一套 Agent 基准测试集合，让你比较不同模型在 Hermes 内的表现，根据价格和能力选择适合自己的模型。Hermes Bench 还有我们内部保留、没有公开的测试集，专门覆盖非软件工程任务，其中甚至包括网站视觉设计等。
我没把相关幻灯片加进来，有点可惜。但如果你们想了解，之后可以找我或者 Nous 团队任何人聊。我们正在思考怎样让用户看到模型在 Hermes 里的真实表现。前面也提到，Hermes 是很好的研究助手，可以做深度研究。我四月份发表了一篇论文，而那篇论文的实验，大部分是我和朋友在酒吧喝酒时远程完成的。我每隔二三十分钟就在 Telegram 上给 Hermes 发消息：“嘿，再试试这个实验。”它帮我运行，等我回家再整理实验结果、综合分析并完成论文。
我每天都非常感激 Hermes 带来的魔法。幻灯片最后还写了黑客松：我们经常举办线上 Hermes 黑客松。如果你有想做出来、分享给世界的点子，欢迎关注 Nous Research 的社交媒体，了解什么时候可以参与，说不定还能拿到一点奖励。最后我想介绍一下怎样开始使用 Hermes。这套幻灯片也是 Hermes 帮我做的，所以有些内容现在已经过时了。其实我主要想借它讲自己的经历，以及我们是怎样起步、又往哪里去的。
幻灯片顶部有安装命令，过去只需要在命令行输入就能启动。那是 Hermes 还只有一种安装方式时的内容。现在我们有更多选择：可以去 Nous Research 官网下载，也可以从 Hermes Agent GitHub 仓库获取源代码、自己构建、提交 PR，或者通过社区板块反馈问题、提交缺陷和修复。我们有完整文档，也有 Discord、Telegram 群让开发者交流。Nous Research 这家公司本身就诞生于一个公开的 Discord 社区。2022、2023 年，我们是一群热爱训练开源模型的人，后来大家聚在一起想：如果成立一家公司，筹一点资金，把大家做模型后训练的能力真正用于更大的事业，会怎样？
于是公司就从 Discord 社区里长出来了。我们完全远程办公，成员分布在世界各地。一路走来，连我们自己都没预见到会走到今天。做 Hermes Agent 时更没想到它会变成如今的样子。这几年确实非常神奇。我特别喜欢和社区的人交流他们正在用 Hermes 做什么，从中学到很多关于人们真正想从 Agent 获得什么的知识。我们的后训练团队，最初就是训练模型起家；现在核心工作之一是训练在 Hermes 里表现更好的模型。建立 eval 和 benchmark，也正是为了回答这个问题。
如果我们知道怎样衡量模型在 Hermes 内的能力，又有一支精于后训练开源模型的团队，还拥有自己的工具调用格式、合成数据技术，以及 Agent 领域强化学习环境的经验，那么怎样把这些知识组合起来，训练出更好的模型？
但做 Agent 基准测试时，我越来越想知道：你到底是在测运行模型的 harness，还是在测模型本身？这也是当前 Agent 评测仍是灰色地带的重要原因。至少存在两个变量：模型，以及围绕它的执行框架，可能还有更多。你在衡量二者组合完成任务的表现，所以结果很难简单归因。对我们来说，有些实验相对容易着手。（这里原稿有部分语句缺失。）
例如 steering vector、采样策略，以及模型完成一次前向传播、准备选择下一个 Token 时的一些机制：当它作为 harness 底层的语言模型运行，我们怎样进一步提升智能？公司里有很多研究人员深耕这些不同方向。好，感谢各位听我分享，我们可以进入提问。谁想问关于 Hermes Agent 的问题？
先说一句，你的艺术风格太夸张了，但我喜欢。（原稿此处的具体问题未完整转录。）
好问题。先说一下，我身上穿的就是 Hermes 周边，大家也可以去拿。不过针对你问的记忆方案，我自己没有非常固定的偏好。我其实挺喜欢我们目前默认自带的版本。之前用过 Honcho，我也很喜欢他们的产品。但公司希望除了默认开箱体验，不要替用户预设太多立场；让所有人有能力自行组合和扩展。默认方案是为了让人第一次安装就能有好体验，我们非常重视从安装到第一次感受到“魔法”的时间（time to magic）。但不同的人在生活或工作中的需求不同，各种记忆方案也有不同优劣，我们不希望把大家锁死。
所以就是这样。
你怎么看 Agent Swarm，也就是智能体集群？它们真的值得那么高的关注吗？我看有些用法会造成很大的浪费。
“浪费”这个说法挺有意思。如果你说的是用树状子 Agent 分而治之，把大问题拆解成更小的问题，那我觉得非常有用。未来甚至可能用一个大模型统筹 Hermes Agent，再把专门任务分配给由更小模型驱动的子 Agent。对一些问题来说，这既节省成本，也节省时间。至于多个 Hermes 实例跨设备互相通信，确实可能有帮助，也可能没什么用。
我对 Agent Swarm、或者 Hermes 在多台机器上自我复制这类构想没有非常坚定的观点。这不是我平时特别关注的方向，虽然最近的新闻确实让这类话题越来越受关注。我更愿意着眼于 Hermes 能带来怎样的生产力和创造力。创始人——原始转录把名字听成了类似“Technia Markov”，需要另行核实——估计任何时候都在不同电脑上同时运行十到二十个 Hermes 实例。那就是他的 Swarm。他的生产力比我认识的绝大多数人都高。
你们做 eval，而且 Hermes 是开源 Agent，可以用各种闭源和开源模型。想知道你们默认使用什么模型？比如写代码、做研究、去酒吧和朋友聚会时，各用什么？也请给大家一点配置建议。
这真是个好问题。我说的只是个人偏好，团队不一定同意。像 OpenAI 和 Anthropic 的高端模型都非常出色，做复杂任务的能力可能是最强的。但我个人一直很喜欢小米的 MiMo 系列，比如 MiMo V2、MiMo V2 Pro。小米团队很早就投入了大量 Agent 数据，尤其是长上下文、长时间跨度的 Agent 强化学习合成数据，明显提升了模型能力。按价格来看，这些模型的性能非常有竞争力。我尤其喜欢它们的一点，是它们作为工具的性格。
Claude 或 GPT 有时候会把我带向别的方向：我本来正在解决一个明确的问题，它却建议“要不要顺便试试这个”“你可能还该考虑那个”。如果我主动要求头脑风暴、帮我探索理论，那当然很好；但如果我只是让它完成一个具体任务，我就希望它按我的要求做事。模型的建议可能非常有说服力，容易把人带跑偏。我发现 MiMo 最不容易这样，因此我喜欢它更像纯粹工具的行为方式。这是我的个人推荐：小米 MiMo。中国开源模型整体都很不错。想比较价格与性能，不妨看看 Hermes Index。谢谢 Sam！
感谢大家！接下来进入下一场。
Christian Legnitto（VectorWare）：让普通 Rust 代码直接运行在 GPU 上
下一位是 VectorWare 的 Christian Legnitto。四年前我就试过把他招到 Paradigm，三年半前又试过让他带 Reth 团队，三年前还试过让他带 Ithaca 团队。最后我们投资了他的公司 VectorWare，虽然不是一开始设想的合作形式，但总算走到了一起。他正在推进一些我见过最酷的 Rust GPU 工作，几乎把 Rust 编译器推向极限。欢迎 Christian！
谢谢介绍。讲 Rust 之前先讲讲我自己。这会是一场技术味比较浓的演讲，希望大家跟得上。我在 GitHub 上叫 LegNeato，是 Rust GPU 和 Rust CUDA 相关项目的维护者，可以让 Rust 代码运行在 GPU 上。我偶尔也给 Rust 编程语言本身贡献代码。我的胡子很长了，我在硅谷也待了很久，做过操作系统、浏览器、移动开发工具，还在 Robinhood 做过金融业务。说起来有个不算有趣、反而挺痛苦的故事：GameStop 事件期间，我正好是 Robinhood 负责应急事件的指挥人。那不是什么愉快的经历。现在我创办了 VectorWare，专攻 Rust、GPU、编译器，以及那些很有趣、带着操作系统味道的技术。
现在似乎所有人都在用 Agent 写 Rust，这是好事。大家总算看见了光。
与此同时，所有人也开始用 Agent 给 GPU 编程了。过去只有一小群专业人士会写 GPU 程序。普通开发者可能用 PyTorch，把那些深藏在象牙塔里的工程师写好的 GPU 算子当乐高积木拼起来。现在 AI 非常擅长 GPU 编程，人们开始打开这只黑箱：这是一种极其珍贵的硬件，它支撑着机器人、AI 和机器学习的进步。我想直接释放它的能力，提高效率，或者用新硬件做出新的东西。很多人不知道，Rust 其实已经能用于 GPU 编程。过去 Rust 当然能与 GPU 交互：CPU 上跑 Rust，另外用 CUDA 或其他语言写 GPU 端代码。
Rust 过去主要负责调度 GPU。很多大型实验室的推理系统都是这样。但“把 Rust 代码真正编译后直接放到 GPU 上运行”以前做不到，现在可以了。而且有很多项目在实现这一点，我稍后解释。NVIDIA 自己就有两个相关项目，我维护其中一些开源项目，另一些背后有创业公司。现在你跟 Agent 说“帮我用 Rust 写一个 GPU 程序，把它优化快一点”，它可能挑选其中任意一种方案。说实话，我自己也不知道它会选哪个，因为还没有明显赢家。这些项目的思路大体相似：从 GPU 硬件出发，再往回建立编程语言支持。
GPU 有什么特别的？首先，它没有操作系统。GPU 编程某种意义上接近裸机，像 DOS 时代。你得面对 kernel launch（内核启动）、warp、lane、tensor core 之类的概念。它还有多种内存，各自具有不同的代价。CPU 上通常把内存看作一整片空间，GPU 的不同内存层次则有不同性能权衡。现有项目就是先面对 GPU，再想怎样把 Rust 放上去。Rust 包含编译器以及程序员实际使用的语言部分，但原生 Rust 不理解 GPU，需要自己实现代码生成后端。除此之外还有标准库，提供文件系统、网络等能力。Rust 的一个独特之处，是你可以一层层剥离它，只保留适合当前硬件的部分。
GPU 没有操作系统，所以不能直接用网络、文件系统；这些部分可以拿掉，核心 Rust 仍然能跑。嵌入式领域也是这么干的：小设备可能根本没有文件系统或操作系统，但 Rust 核心照样能工作。然后，为了真正操作 GPU，这些项目会加入 intrinsic，也就是直接控制硬件的低层接口。用 intrinsic 编程相当痛苦，几乎就比写汇编高一个层次。因此大家再加一层类型和其他抽象，用定制语法配置硬件参数。我这里的每一列都代表一个把 Rust 运行到 GPU 上的项目。内容很多，大家看不清也没关系，重要的是它们结构基本相同。
如果你关心 AMD，就不能用某些 NVIDIA 专用项目；关心 NVIDIA 或 Android，也可能要换另一套。它们各自演化，不只是因为硬件要求不同，也因为抽象的设计理念不同。在 CPU 上写 Rust，你一般只需要一个 main 函数，运行时就从那里开始；GPU 没有天然的 main。每个项目都需要定义自己的启动入口，以及怎样设置网格、线程等参数。
（此处原始转录有缺口，涉及各项目怎样暴露 GPU 运行入口和硬件控制参数。）
Agent 已经很擅长写 Rust，因此它们写 GPU 上的 Rust 也相当不错。再退一步，为什么要让 Rust 直接运行在 GPU 上？或者说，为什么普通软件开发者也应该关心 GPU？如今几乎每台设备都有功能强大的 GPU。和过去“不能假设用户设备有 GPU”的年代完全不同，你口袋里的手机都配着相当不错的 GPU。以前最后一块没有普遍装 GPU 的地方是数据中心。现在 AI 浪潮让整个数据中心都围着 GPU 建设。等于有一大片免费的计算地产在那里，蕴藏着巨大的算力。我们相信，未来大量软件都会迁移到 GPU 上获益。与此同时，CPU 的设计也越来越像 GPU，苹果芯片等平台都出现了一定程度的趋同。NVIDIA 原本是 GPU 公司，现在也在做 CPU。各种多核计算单元正在汇聚。
这些计算资源未来无处不在，我们希望用 Rust 来编程。原因和 CPU 上使用 Rust 一样：性能、安全和开发体验。现有 Rust GPU 项目虽然可用，但存在一个问题：我们有 CPU Rust，也有 GPU Rust。为了适配 GPU，开发者不得不另外建立 GPU 专用抽象、去掉一些特性，等于在某种程度上 fork 了 Rust。这不一定是坏事，也不独属 GPU 领域。Agent 让语言分叉和定制可能变得更加常见。以后写 Rust 时，不管面向 CPU 还是 GPU，一旦遇到痛点，你可以对 Agent 说“这是开源编译器，去改一下”。我们预期 Rust 会出现许多子生态，GPU 目前就是其中之一。
但现有项目隐含着几个假设：GPU 很古怪；GPU 需要特别对待；绝大多数 Rust 代码是为 CPU 写的，不能在 GPU 上直接使用。这源于“GPU 优先”的设计方式：从硬件能力出发，想办法把 GPU 的特殊性暴露给 Rust。这很好理解，因为主导相关工作的都是 GPU 工程师，不是普通 Rust 程序员去学习 GPU、再给语言加支持。而 VectorWare 在探索另一条路线。
如果我们反过来，从语言本身开始呢？采用“Rust 优先”的设计，先接受 Rust 的编程模型，再把它带到 GPU，而不是先看 GPU 再改 Rust。尽可能保留 Rust 原本的语义：当 GPU 硬件语义与 Rust 语义冲突时，优先选择 Rust，即使意味着 GPU 上的实现未必绝对理想。我们把 GPU 当作 Rust 的一个编译目标。仔细想想，Rust 本来就支持许多不同目标：Linux 与 Windows 完全不同，Nintendo Switch 又很不一样；底层芯片架构差异更大。语言在生成机器码之前会通过抽象机器，而 Rust 已经支持许多不同抽象目标。所以它本来就有处理古怪底层平台的能力。
而且 CPU 难道不古怪吗？对称多处理器、超线程、SIMD，还有 CPU 上的性能核和能效核；网卡也很古怪，连接着不同协议和物理介质，背后运行着你不一定了解的处理器；磁盘控制器也一样。Rust 的设计一开始就能够应对这些差异。第一条原则：尽可能实现零成本抽象。第二条原则：允许程序员在需要时突破抽象。比如你不喜欢默认内存分配器，就能换掉。第三条原则：提供可以主动开启的硬件专用优化开关，让程序员自己决定是否牺牲兼容性。一般的 Rust 代码同时能跑在 Windows 和 Linux，但你也可以说“如果是 Windows 就走这条路径”“如果是 ARM 芯片就走另一条”，甚至写内联汇编。这像一层层剥开的洋葱，复杂度可以逐级增加，让你选择要付出的代价。这恰恰是 Rust 的核心设计，我们也在沿用。
我们起步时的假设是：GPU 并不奇怪，GPU 不需要被特殊对待，Rust 已经具备足够多的工具。而且外面有海量优质 Rust 代码，既快速又安全，是许多人多年积累的成果。直接丢掉这些代码，就等于丢掉使用 Rust 的大半价值。这意味着，我们必须让 Rust 标准库在 GPU 上工作，不能造一个完全分裂的生态。可这很难，因为 GPU 没有操作系统：没有文件系统，没有网络，没有线程，连 TTY 都没有，GPU 上甚至不能直接 print。
我特别喜欢用 printf 调试。那么怎么办？CPU 上有操作系统，我们把这些操作代理给 CPU 不就行了？VectorWare 把这叫 host call。GPU 上仍然写普通 Rust 代码，例如调用“打开文件”。它把请求通过总线发送到 CPU，由 CPU 真正打开文件，再把文件描述符返回。这听起来是不是很糟、很黑魔法？但 GPU 事实上一直就是这么工作的。CUDA 在 GPU 上打印信息时，也是先写进缓冲区，由 CPU 取出来完成输出。游戏行业处理 GPU 资源也早就用过类似方式：渲染一个模型，需要先从 CPU 一侧加载，再交给 GPU。
所以把 GPU 无法实现的操作交给 CPU，没想象中那么取巧。事实上，CPU 上的软件也经常如此：编程语言并不需要了解磁盘控制器、文件系统究竟怎么工作，也不需要了解文件是在本地还是网络上。它调用一个抽象接口，由底层负责处理并返回句柄。这种结构非常强大，几乎所有编程语言都依赖类似机制。
关键在于：Rust 标准库提供一个稳定的外观接口（facade），接口后面具体怎么实现并不重要。我们利用这一点：GPU 能做的就在 GPU 做，例如计时、计算；不能做的转给 CPU。Rust 本来就有这样的抽象。真正难处理的例外是并发。GPU 和 CPU 的并发方式差别很大，而 Rust 的并发模型也与 GPU 硬件有显著差异。Rust 里有进程、线程、SIMD、async/await 等概念；GPU 上则是 kernel launch、grid、block、warp 和 lane。我们要把这些语义不同、数量还不完全相同的层次对应起来。过去正是这个原因，CPU 的普通 Rust 代码没法直接搬到 GPU 上。
看 GPU 是怎么运行代码的。假设配置五个 block，每个 block 有四个 warp，它会把同一段代码同时分发到各处运行。这就是 GPU 的魔法：同一份代码瞬间在多个地方执行。如果再启动另一个内核，比如四个 block、每个三个 warp，硬件会找空闲资源调度；因为这次只要求三个 warp，还会空出一部分资源。在 VectorWare，我们试图让 CPU 与 GPU 的并发世界相互映射时，意识到一件事：GPU 特有的 warp、block、grid，其实某种意义上更像硬件核心。用 Python 或 Rust 编程时，你通常并不直接编程物理 CPU 核心，而是由更下层来管理。所以这些概念应该藏到编程语言抽象下面，而不是直接塞进语言里。
我们因此把硬件的 warp、block 等从语言层设计中划掉了。另一个发现是，Rust 的 async——
或者说 Future，只是描述并发的一种方式，必须有更上层的执行器负责驱动它们、决定在哪个线程上同时运行。我们眼下设计的恰恰是那个底层驱动层，所以不能把 Future 作为最底层的并发基础。想象一个操作系统调度器：线程是由调度器提供的，你不能要求一个依赖调度器才能运行的异步结构反过来成为调度器本身。因此 Future 也从映射中去掉。Rust 还有 coroutine 等机制，实际使用并不普遍，也先去掉。
现在两边都剩下三个层次，至少数量相同了，尽管语义仍然相差很大。看看能否逐层对应。Rust 软件侧有进程、进程里的线程、线程里可执行的 SIMD，SIMD 又有 lane。GPU 硬件侧有 kernel launch，里面有很多 warp，每个 warp 又包含多个线程 lane。它们都是分层结构，而且层数一致，看起来很有希望。可语义到底能否匹配？首先，能否把 Rust 进程对应到 GPU kernel launch？进程运行、退出、释放资源，而 kernel launch 也具有这样的生命周期，很多方面似乎一致。
但并不是所有进程语义都能完全对应，仍有问题要解决。继续向下，能否把 Rust 线程映射到 GPU warp？多数预期特性 GPU 也能支持，但最底部有个差异：Rust 线程可以在运行时再启动新线程；GPU 启动后，所有 warp 可能已经都在跑程序了，没有闲置位置可供新增。你不能说“我已经运行 N 个线程，现在要运行 N+1 个”，因为硬件资源一开始就已经并行铺开。所以这也必须解决。最后一层是 CPU 的 SIMD 和 GPU 的 lane，这两个竟然匹配得非常好。事实上 GPU lane 在一些方面比 CPU SIMD 还强，因此可以一一映射。
困难的核心在于：普通 Rust 启动后只期待一个主线程，而 GPU 启动时会出现大量“主线程”；Rust 主线程可以再创建其他线程，但 GPU 所有 warp 都可能正忙。它们指向同一个根因：GPU 默认就是并行的。于是我们想到一个办法，谈不上多伟大，但挺有效：单线程本来就是并行的一种特殊情况。GPU 天生并行，不代表所有单元都必须做有用的工作，对吧？让其他线程空转不就行了。具体过程是：CPU 发起内核启动，GPU 按原来的方式让相同代码在所有单元上运行，这个硬件行为不能改变。
但代码自己可以判断：“如果我是第一个，那我是真正的主线程；其余只是假的主线程。”假线程进入自旋循环，暂时什么都不做。从外部看，GPU 虽然启动了许多并行线程，但只有一个线程真正工作。这样我们就恢复了 Rust 对“单个主线程”的语义要求。如果 Rust 程序调用 thread::spawn，空转的 warp 就被唤醒，开始执行有用的代码。反过来，当主线程需要等待，也可以进入自旋。这意味着相同的 Rust 代码无需改动，就能同时在 CPU 和 GPU 上运行。比如 main 一开始在 warp 0 上执行；当它创建新线程，warp 1 醒来参与工作。
此时有两份工作在并行。接着 warp 0 再创建线程，warp 2 也醒来。当 warp 0 执行到末尾，需要等待其他线程，它就原地自旋。思路非常简单，却帮我们拿回了很强的通用性。性能会如何？实际上可以达到手写 CUDA 的水平，属于零成本抽象。如果代码一上来就启动尽可能多的线程，再在其中利用 SIMD，速度和手写 CUDA、手写 PTX 相当，甚至在某些场景更快。我们还可以按需牺牲一点兼容性，贴近硬件使用更高级的技巧。
比如明确告诉编译器“我现在就在 GPU 上”，使用 GPU 专用功能，甚至直接写原始汇编和 PTX。这样做的好处是什么？大量现成的 Rust 库和二进制程序能够直接在 GPU 上运行。理论上 crates.io 上几乎整个 Rust 软件生态都可以被利用，运行远比过去 GPU 能承受的复杂程序。并发能用，而且从一开始就继承 Rust 的借用检查器与内存安全，而不是后来再把一堆不安全操作糊进去。Agent 特别擅长写 Rust，也擅长优化 Rust；对它们来说，这不过是另一种目标平台的 Rust，API 甚至一样。它们能不断对 GPU 代码进行爬坡式优化，因为训练权重里已经有大量相关知识。我们计划把这些支持逐步合并进 Rust 上游。如果成功，一夜之间 Rust 就可能成为最大的 GPU 编程生态。
因为 Rust 开发者、Rust crate 的数量远多于直接编写 GPU 代码的开发者和库。靠这个小技巧，每一个 Rust 开发者都能成为 GPU 开发者。不过不是没有代价。第一，我们也许会错过某种更根本、更适合 GPU 的编程模型，因为选择 Rust 就要受 Rust 语言边界约束。第二，为 CPU 设计的库虽然能工作，但也许 GPU 专用库更好。第三，代码尺寸和寄存器压力可能变得难以承受。传统 GPU 代码规模可能只有一至四 MB，而我们生成的东西有时会膨胀到 150、200 MB 或更大。现在大家已经可以尝试了。它还没开源，我们希望未来开放；代码目前还不成熟，真正进入 Rust 上游也会花很长时间。但我会在 Signal 群里分享一个 Docker 镜像。
如果你有一台 NVIDIA GPU 的 Linux 机器，现在就可以拿未经修改的 Rust 代码直接放到 GPU 上运行，自己试一试、改一改。谢谢大家，也欢迎了解 VectorWare。
我们回答两个问题，一人一个。尽量技术一点，问难一点！
你们只专注 NVIDIA，还是也会支持 AMD？
好问题。这项工作的本质没有任何 NVIDIA 专属限制。我们认为未来是多核、多厂商的。越来越多公司开始垂直整合，OpenAI 等公司都在研发自有芯片。因此我们希望编程语言层成为可以操作不同硬件的统一抽象。理论上这套方案完全可以用于 AMD，只是目前 NVIDIA 是最主要的市场和硬件环境。
很好的问题。最后一个！这听起来有点像面向硬件的 OpenRouter。
你说把 SIMD 转成 GPU 代码，具体是把 AVX 这样的 CPU 指令转换过去，还是走不同的途径？
Rust 在 SIMD 上方本来就有一层抽象。我们瞄准的是那个抽象，而不是机械地逐条翻译某种特定 CPU 指令。（后续答复原始转录不完整。）
……与具体平台无关。（原稿只剩一个不完整词。）
中场休息与直播填充画面
“我……”（不完整语句）
“视频就到这里了，感谢观看。如果你觉得这段视频有用……”（与实际大会进程不连贯，可能是自动识别到的填充音频。）
“待会儿见。”
Tempo 团队演讲：Centaur、Cyclops 与 Agent 时代的安全工程（原稿从演讲中途开始）
一些字段需要做特定的编码；熟悉以太坊的朋友知道，这涉及 ABI 解码。
我们发现 Tempo 实现并没有严格按规范执行 ABI 解码。但去看其他节点实现，似乎大家都没严格执行，于是想：这里是不是有某个原因？我们让 AI 检查整条链的交易活动，找出哪些交易在编码末尾额外附加了字节，为什么有人要这么做。它返回一张电子表格，把这些案例来自哪里逐项拆开，为我们的决策提供了大量信息。结果发现，用户其实把尾随字节用作交易标签，方便像备忘录一样做对账。因此我们决定保留这一行为：虽然按字面规范某种行为应该不同，但既有实现及实际用户习惯已经形成了有用功能。最后一个例子很有意思，我们就重点看一下。
可惜没时间把所有案例都讲完，不然我们光是在 Slack 里翻记录就能聊一天。最近我们越来越重视确定性模拟测试（Deterministic Simulation Testing，DST）。不了解的朋友可以把它理解为：对分布式、有状态的系统，把真实输入放进模拟环境，把 I/O、网络等替换为可控的模拟组件，再进行大量重复运行，挖掘那些古怪而难复现的 Bug。我们开始把 DST 用于 Reth 的一些组件。有位安全工程师报告说，他似乎找到了三个很严重的问题。我们直接把消息转到 Slack，对 AI 说：“检查这些问题是不是真的，帮我复现。”这里想强调一个具体功能。
可以随时指定 --model，针对任务调用更强或更轻量的模型。这种能力特别有用，因为某个 Bot 默认配置可能不足以处理你现在遇到的复杂问题；但你不必跑去改配置文件，在对话里直接指定就行。随后 Bot 复现了问题。Alexey 注意到它主动调用了 boxctl——我们开发的内部工具，能够跨裸金属资源临时创建机器，跑完测试或基准测试后再销毁。我们甚至没叫它用这个工具，它自己就知道应该这么做。它报告：三个问题全部按照原始描述复现成功。我们接着让它再做一步。
“能不能不依赖 DST，也写出可以放进代码库的回归测试？”它又完成了，而且直接把补丁文件发回 Slack，让我们从那里核查。这说明，只靠 Slack 对话，团队就能协同开展复杂问题求解、启动 PR、调度代码工作；过去很难这样做。工具是开源的，大家可以使用，有兴趣可以找我或 Tempo 团队的人配置好。正确配置之后，它真的像获得了超能力。但一个自然问题是：用了这么多大语言模型、开发速度这么快，如何确保代码安全？
怎么确保这些“狂飙式合并”的代码不出问题？这正是我们开发 Cyclops 的原因。Cyclops 是一款基于 LLM 的扫描工具，可以审查 PR、仓库、依赖项中的 Bug、漏洞和各种问题。它在我们的 Tempo 代码库里发现了大量缺陷，在合并前就把问题拦下，确保最终进入 main 并发布到生产的代码，质量比只靠人类检查时更好。它在内部怎样运作？配置之后，每次打开 PR，都会触发一个协调器，由协调器决定使用哪些模型，再同时派出一组模型扫描代码。这里完全可以配置。
你可以指定使用哪些模型、派多少 Worker，还可以针对不同类型的 PR 配置不同审查强度。如果是一个规模很大的 PR，就把所有火力都派上去；如果改动简单，就用更轻量的模型和少量 Worker。发现问题之后，Cyclops 还会循环验证：这到底是不是真的问题？是否和已发现的案例重复？最后把结果直接作为安全审查评论发布在 PR 上。工程师打开 PR 就能看到 Cyclops 已经启动审查，清楚地告诉你“这里有问题、这是建议的修复方式”。这样的用户体验很好，不会迫使你离开原本的代码发布工作流。和 Centaur 一样，Cyclops 的配置空间也很大。
新模型一发布，就能直接接入，不需要花很大力气升级整个工具。你可以指定任何想用的模型，甚至自托管模型，只要写进配置，用户端的流程就完全不变。看看一个真实 PR：Cyclops 开始安全审查，发现“负数提款会增加钱包余额”这样的 Bug。它不仅发现问题，还会继续监听后续修复。当工程师提交新代码后，Cyclops 会检查新改动是否修好了漏洞。确认完成，界面才显示“Safe to Merge”，附上完整报告：发现了什么、修复了什么、由哪些提交完成修复。
对 Tempo 而言，这与更严格的测试一起，已经成为最有效的工具之一。它几乎改变了整个研发过程，现在我们打开的每一个 PR 都会跑 Cyclops，未来进入正式版本的代码同样经过这一关。我们也一直统计它究竟有多大价值。比如最近我们推出的隐私方案 Tempo Zones，在外部审计报告里没有发现严重或高危问题。原因之一就是我们把缺陷发现工作前移了：PR 的迭代阶段确实发现过问题，但都在合并前修好了。
所以进入 main 的代码已经不带那些漏洞。它不仅对普通代码库有效，对 Tempo 的关键核心代码同样如此。工程团队因此更有信心，和外部审计机构合作时效率也更高。熟悉安全审计的人知道，外部审计发现问题、我们修补、再交回去复核的循环会非常昂贵而耗时。现在流程顺畅了许多。讲几个 Cyclops 找到的真实案例，并不是些鸡毛蒜皮的小问题。第一个是我们的 EVM 实现：一条路径通过解释器读取指令并执行，另一条通过 JIT 先把指令编译成机器码再执行。两条路径的结果应该一致，但 Cyclops 找到一个很隐蔽的条件，解释器和 JIT 会产生不同结果。
我们发现后就修好了。另一个是 Tempo Zones 里的内存耗尽问题，不那么容易注意到。Cyclops 能找到的不只是状态转换函数或预编译合约的正确性问题，也包括可能造成拒绝服务（DoS）的风险。最后这个案例更值得展开：Revm 是一个 Rust 实现的 EVM，Reth 和很多区块链项目都在用它。Tempo 也以 Reth 作为执行客户端。我们曾在 Tempo 一个 PR 里做了一个看似非常简单的改动。
具体是，检查用户余额是否足以完成某种冷加载（cold load）之前，先收取或检查一笔静态 Gas 成本，不满足条件就中止。过去代码总是假定用户有足够 Gas，直接加载账户；现在这个动作可能失败。Tempo 自己的代码没有问题，但 Cyclops 理解了改动与下游依赖的交互，发现依赖中的一个路径可能触发 panic，最终导致节点崩溃。而这正是实际情况。在 Revm 内部，有个 map_err 调用把失败映射成 journal load error，代码却预期底层一定返回数据库错误（DB error）。
但现在因为用户 Gas 不足，可能返回的是“cold load skipped”错误，不是数据库错误。于是代码直接 panic，把节点弄崩了。Cyclops 在 PR 合并之前就发现了这个风险，尽管 Tempo 新增的代码本身没有缺陷。我们还能把修复贡献给 Revm，让整个生态受益。到了下一个 Tempo 版本发布时，依赖里的问题已经解决了。这就是我们开发的部分工具和案例。
（此处原稿有一段语音缺失。）
我们团队一直在使用 LLM，为公司高速解决工程问题。这里展示的只是日常经常使用的几种工具，它们帮助我们更快交付 Tempo 的代码。欢迎演讲后找我聊 Centaur、Cyclops，或任何 Tempo 相关话题。谢谢大家！接下来可以回答几个问题。
我的问题是“规格漂移”（spec drift）。我看到你演示了怎样从 Slack 线程里的提示直接让 Centaur 生成 PR。但项目逐渐复杂之后，需要更多团队协调。我们在产品研发里遇到的挑战是：一开始明确了业务逻辑和业务结果，但许多细节需要讨论、需要对齐。模型却默认做出自己的实现假设，这些决定没有上升到业务规则层面供人确认，最后会出现严重偏差。你们使用什么技术或框架来减少规格漂移？
很好的问题。我们早期也遇到过类似情况。比如某些功能同时有 Solidity 参考实现、预编译合约实现，以及节点里的正式实现。时间久了，它们就会慢慢分叉；突然有一天发现差异太大，必须花很大功夫重新对齐。我们主要做两件事。第一，维护一个相对稳定的规格参考，叫 TIPS，即 Tempo Improvement Proposals（Tempo 改进提案）。它规定系统应当表现出的行为。每次协议有改变，就形成一份比较轻量的文档，模型可以查阅，知道预期行为是什么。内部也有审查过程，明确“我们究竟期望怎样运作”。
尤其状态转换函数或影响共识的关键代码发生破坏性变更时，我们也会同步更新提案。不同类型的代码需要不同平衡，但为工程师和 Agent 都提供一份轻量、明确、可引用的预期行为说明，是很有帮助的。当然像 Georgios 刚才说的，我们正在迅速发现哪些流程有效、哪些无效。三个月、六个月之后，做法也许会完全不同。Cyclops 确实会参照规格，但它主要检查实现是否符合规格，不会自己判断“规格文件本身在这里已经漂移了”。
如何发现团队内部恶意人员留下的后门或者 kill switch？假设对方故意隐藏，规格看起来正确、代码运行也很好，但仍有后门，甚至是不怀好意的 Agent 做了手脚。
Tempo 安全团队有更专业的人可以详细解释。我简短回答：我们有一个专门的安全团队，除了关心代码缺陷，也考虑依赖项供应链被入侵、基础设施和密钥访问等问题。公司设备与资源有非常广泛的日志和可观测性建设。不仅安全团队会监控，还有自动化工具会识别某些可疑迹象，再让人进一步调查。换句话说，除了保证代码没有 Bug，我们还监控 Tempo 组织本身的行为有没有异常。发现可疑迹象，安全团队就会深入排查。如果你想了解技术细节，我可以介绍更专业的同事。
是不是只能通过 Slack 使用？Cyclops 具体怎么接入？能不能不使用 Centaur、单独使用 Cyclops？
先回答后面的问题：它们完全独立。你可以单独使用 Centaur 做任何事情，也可以单独使用 Cyclops。只是我们发现两个一起用特别顺：Centaur 通过 LLM 激进地组织代码工作、创建 PR，Cyclops 随后审查，无论 PR 最初由人类还是 Agent 创建都一样，合起来形成一个非常快的闭环。至于入口，可以去看开源代码，它支持多种使用方式。我们自己天天用 Slack，所以那部分实现更完善。
我想问，你们为什么敢让 Centaur 访问那么多内部基础设施服务？毕竟等于通过 Slack 接口把公司的内部系统暴露出去了，怎样管理这些访问？
就这个问题而言，之前有一页幻灯片提到一个叫 Iron Proxy 的服务。它位于所有运行 LLM 的沙箱和它们需要调用的服务之间。
（与观众互动后继续回答。）
Iron Proxy 自己保管所有凭证。所以即使你从 Slack 里发消息说“AI，帮我开这个 PR”，背后确实需要某个具有读写权限的凭证，LLM 也不会真的看到它。它只是通过 Iron Proxy 代理调用相应服务。
因此 Agent 本身永远拿不到这些密钥。
其他服务接口会向 Centaur 集群做身份验证。Slack 只是使用签名 Webhook 连接；如果换成 API Key 认证，也很容易实现。所以整个体系并非把内部凭证直接暴露给模型。
演讲环节结束
好，演讲全部结束了。记得去领取周边！
（原稿末尾为零碎告别语，无法可靠完整还原。）谢谢大家。 ## 关键观点