为什么 Harness 比模型更重要 | YC Paper Club 深度解析

欢迎来到 YC Harness Club。我花了不少心思，和 Gemini 迭代了大约 10 次才成功生成 Harsha 骑着龙虾的图片。虽然 Gemini 最初并不愿意配合，但我们最终还是搞定了。

首先，大家觉得 YC Paper Club 的全新视觉设计怎么样？

这原本只是我随口向 YC 设计负责人 Ev 提出的一个想法，两天后她就做出了现在的成果，效果非常惊艳。坐在后排的 Ev，请接受大家的掌声。

非常令人兴奋。那么，我们为什么要在今晚专门探讨 Harness？

harness 仅仅是一个包装器、支架或提示词工程，为什么它值得专门用一个晚上来讨论呢？

这里有一个一个月前的 Reddit 帖子，表达了较为激进的观点：这种提示词工程是否属于顶级机器学习会议，对此持保留态度。 还有另一个主流观点认为，上下文工程并不是一个研究问题。 因此，harness 长期以来一直被贬低为水准不高的研究。 然而，harness 1 和 harness 2 之间的差异能实实在在地带来 18% 的性能提升。正如 Seth 所说，这就是能让 ARC-AGI 成功运行与否的关键区别。显然，这非常值得投入一定程度的研究。 如果你观察经典的发布日期与代理运行时间的图表，就会发现很多进展实际上都归功于 harness。我将其称为静态 harness 时代，即 harness 本身不具备自我改进能力。 而在最近的六个月里，所有的发展都集中在自我改进的 harness 上，我们将逐步了解这些内容。

我在 Trajectory 首席执行官的演讲中看到了这张图表，我非常喜欢它。它谈到我们一直在衡量困惑度，这在某种程度上与智商和模型的智能程度相关，因此我们不断推动智商维度往更高水平发展。 但我们并没有充分利用测试时经验（test time experience）。我们在生成所有的测试时经验并进入了一个新领域，却没有实现快速适应。 如果你还记得我们做过的前几次 YC 论文俱乐部活动，我一直在做一个实验：随着在线样本数量的增加，在只有 batch size 为 1 的情况下如何进行学习？我们并没有那种结构。 我们有上下文学习（ICL），但一旦 ICL 在加载了大约 40 或 50 个样本后达到饱和，它在验证集上就不会有任何提升。此时你必须转向小秩 LoRA、大秩 LoRA，接着是 SFT。我们拥有这么多不同的训练流程，这其实挺奇怪的，而这正是 harness 真正大放异彩的地方。

ARC-AGI 展现出的核心要点是：它能够以多快的速度适应新问题、新分布并在其中表现良好。因此，ARC-AGI 实际上...

Arc AGI 实际上参与了我的冬令营（Winter 26），我们帮 Greg 一起研究。正如我上次所提到的，这些游戏投入了大量的思考和注意力，以确保从游戏一到游戏二的所有技能都是正交的，从而能够隔离流体智力的测量。 Claude Opus 是最早在由 Greg 和 Chollet 掌控、其他人无法访问的私有保留测试集上进行验证的模型之一，他们取得的最高成绩是 30%。 仅仅通过一些 harness —— 这种根本不值得进行研究的简单封装和脚手架 —— 我们就能达到 95% 的准确率，而英伟达的 AVO 则达到了 100%。Prime Agent 和英伟达都是最近刚刚发布的。

另外我还想补充一点，当卡帕西（Karpathy）在 3 月份推出他的自动研究员工具时，我对其进行了 fork 并进行了一番把玩。我当时唯一想做的事情，就是制作一个小型的用户界面，来看看究竟发生了什么并对其进行追踪。

我其实是不小心构建出了这个测试框架，本来只是想做个用户界面来看看进展并进行跟踪。 具体的操作方式是：你先指定一个目标。我给过一个真实的例子，比如“扩散大语言模型比不上自回归大语言模型，但如果我把扩散模型集成并分片成多个，由于扩散模型相比自回归模型在每个GPU上的算术强度很高，通过分片聚合或许能取得更好的结果”。 然后，我把这个目标输入给我的代理团队、我的代理蜂群，再提供一些种子想法，比如将集成规模分片100倍、10倍、5倍或其他数量。 接着指定一个评估指标，可能比如用GSM8K和GPT-2设置等。随后会有一个范围界定代理去查找相关的论文和GitHub代码库。 它会将任务交由一个名叫Chris Ré的首席研究员代理，接着转给名叫John Schulman的研究代理，然后他会开始开展工作。 他会做一些处理，并把任务交给一个委员会寻求帮助，也就是我切入的环节——我和Yaso会给出一些反馈，接着代理会继续完善，而Chris Ré则会随时关注进展，每隔一小时左右催促一下。 之后任务会流转到一个作者代理，由其宣布开始或停止、冻结想法、开始编写消融实验，并着手撰写论文。 这个系统演变成了带有范围界定代理的架构，同时配有一个驾驶舱，你可以在任何地方通过Tailscale等工具查看这个URL，随时了解进展并直接与之对话。 如果你在里面构建了完整的1B体量内容，它甚至会自动发送电子邮件更新，并且开始真正发表一些我读过的论文。

这些论文质量其实挺不错。它们在三四月时还没那么好，到了五月或者其他时候就有所提升。 现在我基本上是给八个 H100 节点提供八个创意，每个节点有八张 H100 显卡，让它们持续运行。之后我来看看进展，它们就会把论文交给我。我们现在面对的局面确实挺惊人的。 真正改变的其实只是你在它之上添加的脚手架，好让它能够运作。我并没有在这上面花大量时间，但这基本上是我开展很多研究的方式，至少在最初的创意阶段是这样。 我通常会给出六个不同的想要尝试的想法，然后放手不管，让它自己去跑。因此，仅仅因为在完全相同的权重文件上增加了控制框架，我们现在能做的事情就非常惊人了。

我在准备这次阅读时，花了整个周末回顾经典文献，从 Self-Refine、Reflection、Voyager 到 Toolformer。我想要尝试梳理一个五分钟的简史，看看我们是如何走到这一步的。 我认为这挺重要的，而且现在很多刚进入 AI 领域的人可能缺乏这种背景。 所以这不会按时间顺序来，按那个顺序教或展示其实并不合理。我会跳过许多论文，并且对论文进行非常粗粒度的简化，在此致歉。

早期 Harness 的演进

最初的 harness 是 2019 年 2 月的 GPT-2，它并不是一个端到端的序列循环。当时基本上是靠 Top-P 采样加上环境，这就是 harness 的全部，其实并没有多少东西，没有工具调用，没有技能，什么都没有，这就是 V0 版本的 harness。 举个 GSM8K 的例子，你作为一个数学老师，这就是我们以前用过的角色设定（persona）那套东西。 其中包含上下文：苏西有五块钱，花掉了三块，她现在有多少钱？当时并没有思维链（chain of thought），仅仅是用四个井号、两个状态结束符和序列结束符构成了 GSM8K 的格式。 我们测量四个井号之后发生的内容，以此得出准确率，如果错了就记正一或负一。

在过去的六年里，整个行业的发展方向都是在静态 harness 中赋予其更多功能。 于是我们想，如果把这些内容作为大量示例再反馈到上下文中会怎样？比如这里有一个示例，现在把它换成四个输入和一个输出，基于之前的例子，模型会觉得“这说得通，这有助于学习”。实际上这就是 2020 年 7 月少样本学习（few-shot learners）论文的做法。

接着我们有了思维链。当时的想法是，直接预测两个井号可能比较困难，我们要做的，是将计算和逻辑分散到更多的 token 上，训练它逐步推导得出结果，而不是直接输出那个数字。这就是思维链的创意，非常酷。

这些全部都是上下文创新、输出空间创新以及动作空间创新。随后我们迎来了 Toolformer 和 WebGPT——WebGPT 实际上比 Toolformer 问世更早——也就是赋予模型工具调用能力的想法。

工具的使用实际上只是一个指定了各种参数的 JSON 对象。比如与其在权重文件中计算 5 减 2，不如直接调用 Python 的减法函数，让它告诉你结果是 2。这非常酷，你可以在系统提示词中暴露出所有的工具，这就是工具的来源。

你可以把系统中的所有工具都在系统提示词中展示出来。

接着我们有了 MEGPT，最酷的工具之一就是能够读取和写入你自己的上下文。在此之前，我们能做的只是不断地向上下文追加内容。现在我们思考，如果赋予你对上下文本身的创建、读取、更新和删除（CRUD）权限会怎样？我们会单独分出这样一个小区块称为记忆，你将能够对它进行更新。

随后 Voyager 提出，我们有了这些工具，但如果我想把这些工具串联起来完成一项任务，并学习它，然后如何把它提炼回系统提示词中以实现永远学习呢？

这就是技能诞生的背景。他们在 Minecraft 上实现了这一点，这就是 Voyager 论文，一篇非常酷的论文。这在很大程度上就是现在技能的定义：我有一个 skills.md 文件，里面有我可以去搜索的名称，还有具体的程序步骤。

然后是 InterCode 的概念，同样属于行动空间创新。如果我能直接输出代码，那么基本上我就可以即时拥有工具或即时技能。我其实不太确定它是否应该被视为一个工具，因为工具从技术上讲是一个 API。我输出的是一个函数作为工具还是技能？我其实到现在还不确定。

然后 ReAct 最先出现，接着是 Self-Refine 和 Reflection。但这种理念是：如果我有多个拥有不同角色的智能体，它们可以互相帮助并在上下文中实现自我完善，那么我就能变得越来越聪明。因此，我会采取一些行动。

在这个例子中，我把三和五弄颠倒了。我把它发送给内部评估器，问它这样对不对。评估器说不对，看起来不对。我既可以继续在这里循环，也可以前往实际的环境中获取奖励信号。 我去找反思机制，它会说：“嘿，你其实把这两个弄颠倒了，回去吧。”然后我可以改进结果。 这是最早的关于多智能体以及让智能体对其自身输出进行反思并加以改进的想法之一。

多智能体的这个概念甚至走得更远，我可以生成工具之一，即生成一套子智能体，它们持久存在于这些持久化的 ripple 中并保持运行。我可以与它们交互并拥有子智能体列表，调用它们并不断地向启动子智能体中添加内容。接着 RLM 让这一切变得更加疯狂，允许它以递归的方式进行。 它公开了这个 RLM 查询，所以我可以不断地递归调用 RLM 查询来解决更大类别的问题。 每当叶子节点需要时，我都可以调用 LM 查询来生成该 LM 智能体。 然后我拥有这个运行所有这些的主编排器智能体，这就是我所称的 Harness v1。整个过程就像是静态的 Harness，我没有在改进系统提示词，也没有在更新 Harness 本身。 当然，我们必须要在最上面加入 GStack，它是让我们能够实现这一切的关键。所以我们要感谢 Gary，非常喜欢 GStack。 不过还有其他一些同样值得提及的项目。

总结所有这些，基本上就是：你有一些智能体规范、一些系统提示词。你可以指定允许多少轮对话、允许多少次工具调用——你不会希望允许无限次。你指定一个工具列表、技能列表、子智能体列表，这基本上就是 V1 的核心，然后你把它放进一个循环中。 这可以根据提示词来触发，比如我要求它在我的 Slack 频道中做某事——我们一会儿会听到关于 QM 的介绍，我每天都在使用它，制作它的团队今天也在这里，非常令人兴奋——或者它处于某个 Crunch 阶段，每小时自动醒来并决定开始工作，就像其他人一样。 因此，这里包含一些会话管理、一个循环以及上下文编译，也就是我们实际在创建上下文的过程。

把所有这些内容输入到大语言模型（LM）的调用中，然后我会得到相应的操作结果。接着，我可能需要也可能不需要调用一些工具，并将结果追加回上下文中。这基本上就是 harnesses v1。

最酷的部分、也是我们看到大量进展的最令人兴奋的部分，是允许 harness 自身进行学习。我们要么在学习系统提示词，要么在学习 harness 本身，这非常奇妙。

其中一个非常著名的案例——我本想请他们来聊聊，但他们今晚在旧金山举办一场 150 人的 DSPY 见面会，所以没能赶来。不过我之前和他们做过播客，这是一个非常棒的社区。这就是 DSPY 吗？

它的核心概念是：演示（demonstrate）、搜索（search）、预测（predict）。他们有一个基础理念，即拿出一个训练集（一小部分示例），然后去学习最优的系统提示词。通过不断地迭代。

虽然我无法通过该过程进行反向传播，但我可以使用一种叫做遗传编程的技术。在这个过程中，我寻找候选方案、合并候选方案，并利用某种合并规则进行评估，观察结果，然后持续不断地工作。这基本上赋予了我对系统提示词本身的 CRUD（增删改查）能力，允许我选择任意的系统提示词。

而 Darwin 机器则更进一步。不仅允许更改系统提示词，还允许更改 harness 本身，也就是正在运行的 harness 代码。

你可以想象一下，其运行机制是这样的：你拥有一个由许多不同智能体组成的档案库（包含 harness 和系统提示词）。你从中进行采样，将它们输入系统，并在某个适应度函数上评估它们的表现。

然后将其添加回这个档案状态中。这里我略过了自我修改的部分。

实际上，你拥有一个元 harness（meta harness），它允许智能体修改自身的 harness，从而使其变成一个不同的 harness。接着这个过程不断循环，随着时间的推移，你最终会得到越来越优秀的智能体。而作为主要 harness 的元 harness，其作用就是生成更多的 harness，这真是一个非常具有元概念的想法。

这就是输出空间，你可以在其中配置多智能体上下文编译，并对所有这些内容进行 CRUD 操作。因此，它只是在 harness 代码中不断添加越来越多的 CRUD，包括你在这里看到的绿色部分、元提示词、所有智能体的系统提示词以及智能体的数量。

你在这里看到的绿色部分、元提示词、所有智能体的系统提示词，以及智能体的数量，都是这个元控制框架随着时间不断发展和扩充的内容。 这篇论文的一位主要作者今晚也来到了现场，这非常让人兴奋。大家可以去和他多聊聊关于持续控制框架的话题，我个人非常喜欢这个方向。 他们甚至还更进一步，为内存的类别添加了一些额外的色彩，增加了历史记录的相关内容。他稍后会详细展开讲解这个内存的细分结构。 但我觉得最酷的部分是针对传统的强化学习研究者。我看到Robert坐在后面，他肯定会很喜欢这种Dagger风格的在线学习，你可以实际去更新权重文件本身。也就是说，你基于刚学到的一小部分示例，对大语言模型进行测试时训练，我认为这是一个非常重要、极具潜力的研究方向，我们应该把它做出来。 好了，这就是全部内容，大家最近怎么样？

今晚我们原本有三位作者，但Ben今天早上食物中毒没能赶来，非常遗憾，不过我们还有三位非常优秀的作者。 第一位是Seth，他是普林斯顿大学的博士生，师从Shein，同时也是Prime Intellect的研究员以及Prime Agent的作者。 第二位是John Sadvalone，这是我们第一次有嘉宾返场，我们对此感到非常兴奋。他是Chris（来自Aelia）门下的博士生。 他与我所在的Hazy实验室的Ivonica共同开发了Open Jarvis，这是一个个人开源Jarvis系统，我觉得非常酷。 接下来是Josh和Rean。Josh刚刚晋升为YC Labs的负责人，这非常令人兴奋，我认为大家应该为他送上一些掌声。 他们将讨论QM。在YC，我们一直使用一种通用的Agent，而他们在一个月前推出了QM。它在实际功能上有显著的提升，而且极为实用，我每天都在使用它。好了，这就是我要说的全部，非常感谢大家。

大家好，很高兴今晚来到这里。我叫 Seth，今天将向大家介绍 Prime Agent，这是一个具备自我改进能力的大语言模型控制壳层（RLM harness）。 我今晚的主要目的，是试图说服大家在思考如何构建控制壳层时，采取一种非常回归第一性原理的方式。所以我们一开始会从非常、非常基础的概念讲起。 我很喜欢刚才关于背景文献的介绍，我觉得这与我对这个问题的思考非常契合。 如果只看原始的大语言模型本身，它其实只是一个序列处理器。它具有一些固定的权重和可见的上下文，通过输入一些 Token 并输出一些 Token 来做出下一个决策。 如今我们不再仅仅以这种方式看待大语言模型：我们为其提供可访问的文件、无尽的程序和工具，甚至可以给正在运行的其他大语言模型会话发消息、创建子代理来完成各种酷炫的事情。但归根结底，它本质上依然是输入 Token、输出 Token，本质上是一个在做预测的神经网络。 而控制壳层本身，就是大语言模型与世界之间的那一层，它添加了持久化状态、工具和计算能力等功能。 这里有一张图表，展示了我们从人类的视角如何看待 Prime Agent。你在计算机上打开 Prime Agent，就像使用 Cloud Code、Claude Code、Pi 等工具一样。 接着你会进入代理视图（Agents View）。这个视图概览了你所有并行会话中运行的所有代理，并提供你所使用资源的精简摘要，你可以随时跳进去查看。 进入之后，你会处于根会话（Root Session）中。这个根会话基本上是管理所有不同子代理的项目协调器。你不需要主动要求它启动子代理，它会在需要时自动调用子代理，并且这些调用都是通过程序化方式完成的。

因为这一切都基于递归语言模型（Recursive Language Model）的原理：所有的工具、记忆和子代理都运行在一个 IPython Shell 中，并且我们通过这些消息范式来暴露进一步的协调功能，以便你对它们进行管理。这些代理随后可以直接与你的环境进行交互。

环境既可以是你电脑上的程序和文件，也可能是用于自动研究的 H200 节点集群。每个代理都由你电脑上的一个持久化守护进程支持。这样一来，当你合上笔记本电脑或者用 Ctrl+C 中断会话时，它仍然在后台运行，你必须手动停止会话才能中断它的运行。 此外，我们还从持续框架中暴露了其他功能，使其能够对前面提到的所有组件执行实时的增删改查操作，从而管理其内存、技能、子代理、持久性，并持久地更新自身的系统提示词。 我喜欢把我们正在构建的所有这些上下文看作类似于 L1、L2、L3 的缓存。这就是我们正在处理的最易获取的信息，也就是模型能够以最快速度检索到的信息——模型权重。

每个人总是想把所有信息都放进模型权重里。但后来我们发现，也许我们并不会拥有所有信息，因为我们不想每次更新时都进行微调，那样成本非常高。因此我们有了活跃的输入上下文。 我们在输入端使用了大量的 token。我们可能会像之前那样加入一些上下文中的示例，来增强这些不同的能力，但在某个特定点上，我们的上下文会耗尽。 因此，我们见过的最早期的交互架构形式——至今仍被那些追求最简架构的人所使用——就是压缩（compaction）。因为压缩是一个非常通用的工具，能让智能体总结自身的上下文历史，从而突破上下文长度的工作窗口限制。 你可以这样设想：一旦超越了模型的直接输入和输出，进入到 L2 和 L3 缓存层级。 你可能对 L3 比较熟悉，它更多的是一种调度状态。如果你在使用文件系统，你可以从主内存中进行读写。 而在 L2 层面，我认为它介于活跃上下文和文件系统操作之间。你可能会有一个实时运行环境（live REPL），比如直接在 IPython shell 或 Jupyter notebook 中运行代码。所有这些变量都直接保存在你的 RAM 中。你的智能体随后可以对其进行程序化操作，直接在这些信息上运行各种程序，从而节省大量的 token，而不必将它们直接放入上下文中。 你还可以创建子智能体，原理是一样的，这基本上也是在节省上下文。因为你可以指派智能体去处理特定的一组信息以执行某些操作，最后再向你汇报结果。 这里有趣的是我们之前讨论过的活跃上下文压缩。你拥有上下文历史，这有助于随着时间推移不断更新它，以便你能够继续利用它。 但一旦超越了这一点，我们就需要思考该如何进行这些更新。我们讨论过 CRUD 操作，即除了创建和读取之外，我们如何在超出上下文长度的情况下，随着时间推移去更新和删除我们的上下文或状态？

我喜欢把这种 REPL 环境看作是智能体垃圾回收机制，我们在其中清理状态中的变量以及所使用的子智能体。

这可以看作是一种智能体垃圾回收（agentic garbage collection），我们清理状态中的变量以及可以使用的子智能体，从而确保每天不会让电脑的内存崩溃。 在此之上，我们还有提炼（refinement）的概念，即更新和删除存储在系统中的技能、记忆和提示词。这样可以防止你的硬盘空间耗尽。

这很大程度上体现了我们如何表达这一事物，以及如何随着时间对其进行修订。我非常喜欢并极力推动的另一个视角是，因为控制框架（harnesses）几乎正朝着我们所创建的智能体操作系统（agentic operating system）的方向发展。 如果更具隐喻性地来看，当你审视原始大语言模型时，它看起来更像是一个图灵机，拥有纸带（ticker tape），各种指令输入其中，然后执行一组操作并输出。但当你审视一个控制框架时，它看起来更像一台冯·诺依曼计算机。

然而，当你审视运行框架（harness）时，它看起来更像是一台冯·诺依曼计算机。你能够对外部内存执行读写操作，这使得它比图灵机本身所能表达的范围更加强大，并且能够解决另一类问题。 因此，关于如何构建一个优秀的运行框架，你的目标是让它具备你能想象到的最强表达能力。 在模型能够自我驱动的数据飞轮形成之前，一些早期的运行框架非常具体，包含规划、行动、批判等精确的特定步骤。 现在模型已经能够自己完成这些工作了。我们可以想象，我们不一定需要强加一个类似 React 的循环，模型在原生层面上就已经摸索出了这一点。 但它们尚未完全摸索出的是，它们必须具备调用紧凑（compact）功能的表达能力。 它们必须拥有 Python REPL（交互式解释器），以便运行程序。 它们还需要具备以编程方式创建子智能体、访问状态以及拥有不同反馈机制的能力，这些都是模型控制的表达能力特征。 如果你移除了其中任何一个，实际上就是移除了一种能力，否则它将无法完成相应的工作。

正如大家肯定都很熟悉我的合著者 Alex 撰写的 RLM 论文一样，那是一份非常棒的工作。 我们在 RLM 论文基础之上更进一步的地方在于，我们将这些子智能体视为持久的子会话。 因此，父会话可以启动一个新的 RLM 子智能体，每一个子智能体随后会被触发。它们运行某个任务，完成后向父会话的某个最终状态报告结果。 此时它们处于空闲状态，但仍在你的 RAM 中工作。在任何时候，父会话都可以向其中一个子智能体发送消息以继续工作，并且它拥有随着时间推移积累的良好上下文，这样就不会丢失信息，也不必重复使用在先前上下文中已经开发好的信息。

当然，我们也不希望占用大量内存，因此可以将它们卸载至不活跃状态。通过这种持久化的子代理设置，它们可以随时通过消息被召回。我之前的一篇论文讨论了持续控制框架（continual harness），其中涉及对整个框架状态的缓存。 这也是我们在编码代理中希望实现的一项功能，即利用我们所有的既往历史。你可以想象这样一组轨迹：在每个轮次中，它们会产生一些动作、结果或发生某些事情。

我们希望让代理能够利用所有这些信息，来更新未来框架的外观。我们需要改变系统提示词吗？我们需要创建一些技能吗？

我们希望暴露出这种能力，让代理能够利用所有这些信息来更新未来框架的形态。我们需要更改系统提示词吗？我们需要创建一些技能吗？

我所说的技能是指一组指令或一个程序，旨在实现某种特定的目标。 内存既可以是对重要事物的长期存储，也可以是我们刚才讨论过的、具有高度持久性的子代理规范。有没有某些子代理，因为其上下文很有用，是我们希望在以后重复使用的？

拥有这种随着时间推移进行反思或优化的能力，对模型来说非常强大。

虽然它们目前在这方面还不够完美，但这正是你希望在构建框架时融入的能力，使其能够比当前模型做得更好。

这样，你就可以获取这些推理轨迹，并利用它们来赋能下一代模型，使它们能够处理该框架，并逐步引导自己实现越来越高的性能。

Prime Agent 中最酷的功能之一——这也是我从开始从事这项工作以来就一直拥有的，并且是我添加的第一批功能之一——是能够在某种核心家庭设置（父母、孩子、兄弟姐妹）内的任意两个代理之间进行消息传递。 我之所以这样做，是因为我一直在琢磨：我自己该如何以最佳方式管理每天朝五个不同方向、无数个不同方向为我处理各种事务的所有代理？

我当时一直在琢磨，如何管理每天朝五个不同方向、有无数个任务在帮我干活的代理。如果它们能直接共享联系人并相互协调，效果会好得多。事实证明，这对于典型的软件工程和长视距任务也非常棒。 我们设计运行环境时考虑的最后一个方面是长视距性能。我想运行一些任务，而不必全程 babysit（悉心照料）我的代理，等我准备好回来查看时，可以看看进展如何。这也是我在许多评估中发现明显缺乏的一个视角。很多时候，如果你运行一个模型的时间不够，或者说模型在消耗一定预算后停止工作，而另一个模型消耗更多预算继续工作。首先，你甚至没有使用相同的固定开销来比较模型；其次，这可能掩盖了你所忽视的性能。我看待长视距性能评估的方式是，我想看看实际的平台期在哪里——在什么点上，当我投入更多的测试时间 token 时，性能只会得到增量收益。 在分享完我们创建 Prime Agent 的设计理念之后，我将展示几个实验。我们将讨论测试时间扩展、我们的测试时间结果，以及它是否真的有用，以及为什么它对我们在这些长视距上下文中处理的信息管理很有用。

当面对这些几乎属于超长视野的任务时，我们需要思考如何维持数天甚至更久（比如一周或更长时间）的多日工作，以及在此类持续运行的设置下，当产生修正时究竟会发生什么。接下来展示的是一个大家可能都见过的结果。 我们在其中增加了一个额外的数据点，这是最初结果中没有包含的，主要是为了跨框架进行对比。我们一直在寻找目前大家在运行框架时最关心的最佳评估基准，后来发现应该做 ARC-AGI。 我想起之前用连续框架（continual harness）跑过一些结果，使用 Gemini Flash（或者说 Gemini Pearl）得到了 20% 的准确率。所以我认为我们至少能拿到 20%。 很多人会觉得很酷，我们这个甚至没有针对 ARC-AGI 进行特殊结构化设计通用框架，居然能取得不错的表现。 于是我上网查找一个好的系统提示词，因为要确保不会丢失信息。我找到了另一个名为 Prolong 的社区排行榜，直接拿了他们的系统提示词，抛开其他不管，直接扔进了 Prime Agent 里面。运行之后，我天，第一次运行居然达到了 99.9% 的准确率。 但查看日志后发现我作弊了。因此我意识到必须做好适当的沙盒隔离，把环境正确搭建起来。为此我又花了一天时间去处理。 之后我重新测试，天哪，使用 GPT-4o 取得了 78% 的成绩，这将是一个非常棒的结果。然后我们回过头来，想对比一下其他模型。 我们再次采用了那个通用的提示词，大意是：使用世界模型来解决 ARC-AGI，以下是你可以采取的行动。此外还有 Prime Agent 的通用系统提示词，例如你可以使用 ripple、调用子代理，并且可以以编程方式使用它。 我检查了运行轨迹，它基本上是通过多次调用代码来检查不同的场景，分析图像并进行图像处理。这其中有很多非常酷的操作，展现出了合理的推理能力。

它似乎在进行合理推理的同时，利用了我们拥有的 Ripple，这也是能够构建出这个系统的主因之一。 接着我运行了其他几个测试。我们用 GPT-4o 得到了 25.7% 的结果，这非常酷。你可以对比一下我们测试前一周的情况，OpenAI 的结果说明在做评估时，测试框架（harness）非常关键。我们使用的是 responses API，得到了这个结果。 我们运行了 Terra 并获得了几乎……虽然这个我们没有运行到完成，但相比之下我们得到了非常好的结果。 而且我们已经达到了高于某些 GPT-SoL extra high 的水平，这太疯狂了。

然后我们用了 Opus，达到了 95.5%，我们觉得这太离谱了。 我们还对比了许多其他测试框架。有些人问我：“你用 Claude Code 运行过这个吗？”我用过。不幸的是，结果不太理想。因此与其呈现糟糕的结果，我不如直接引用 Claude Code 原有的结果，而且其他人后来用与 Prime Agent 类似配置运行也取得了更好的成果。不过有趣的是……

有趣的是，许多非常受欢迎的评测框架在 Prime Agent 表现好的时候并不一定表现出色。比如以 Air Agent 为例，我们花钱非常快，不得不将其停掉，因为在性能没有提升多少的情况下花费了大约 5000 美元。这并不是说这是他们能做到的最好水平，但成本确实很高。我认为成本与性能的比例非常重要，而能够以程序化方式处理上下文是节省成本的方法之一。 我们还运行了一系列长期评测，比如 Oolong 以及即将发布的 Emulator Bench（这是一种 Program Bench 的替代方案）。我们发现，在不同的模型对比中，它与这些其他的框架（如 You 等）相比主要持平或略好，当时的设置包括使用 GLM 5.2 到 Opus 5 和 5.6 的 Pimono Cloud Codecs。

我认为另一个非常酷的项目是名为 Emulator Bench 的 Program Bench 替代方案，我们尝试在其中复现计算机系统的整个模拟器，或者在这个案例中创建类似 Game Boy Color 的设备并进行测试。我们发现非常有趣的是，由于它在 RLM 中具有这种 REPL 访问权限，它能够利用这些程序来进行实验循环设计，从而在将最终解决方案提交给评分器之前，以一种更具表现力和更自由的方式尝试各种方法。 我们还在 GPU 内核上尝试了这一点，在 Soul 和 Kimico 不同的模型上都获得了大致相当的结果，一个更好，一个更差，总体上打平，因此我们并没有对任何单一的特定评测结果进行过拟合。

对于长期运行的实验，有趣的是我们做了一些与 Nano GPT Speedrun 相关的主动研究实验，但将其规模扩大了。我们决定为其提供 8 个 H200 显卡运行一周，看看会发生什么。你可能会觉得，Prime Agent 表现会好得多，对吧？

虽然我们无法将收益明确归因于特定框架还是模型本身，因为这是一项非常艰巨的任务，但我们可以检查所观察到的大量行为。 非常有趣的是，我们看到像 deep 6v4、GLM 5.3 和 Kim K3 这样的模型，这些模型显然比我们的第一版结果更新一些。 我们利用这些模型进行了所谓的“环外实验”（out of loop experiments）。我们尝试在 CPU 上运行实验、查看参数化、进行超参数搜索并分析数据，从而不必把所有时间都花在运行昂贵的 H200 实验上，因为这占用了绝大部分时间。换句话说，它们在运行非核心实验来进行优化。 当我们塑造 Prime 代理所需的表达能力时，这是一种非常酷的行为。你可以借助非常出色的自动研究功能，因为你可以想象，如果它擅长自动研究，那么在有真人参与回路来引导实验时，它的表现会更好。 最后，我们还进行了为期 7 天的阶乘运行流媒体测试，总共使用了 633 个代理，跨越 2300 万输出 Token，以便在科技树中取得稳定的技术进步，随着时间的推移不断向前发展。 这里的主要优势之一在于，我可以使用这些子代理，它们可以分工负责工厂中的不同任务，从而进行研究、构建、收集资源，并制造出下一阶段设计工厂所需的物品。 同时，它还可以利用过去发生的事情来进行改进，以帮助未来在超长上下文下的运行，使其不会陷入停滞。最有趣的事情之一就是它不会卡住，即使在我们的阶段结束时，它仍然在不断推进技术进展。 这有点类似于 Gemini 玩宝可梦（Gemini plays Pokemon）那种结论。如果你觉得今天有什么有趣的地方、或者想把什么实际的要点加入你自己的框架中，我认为你应该考虑代理式上下文管理（agentic context management）、群集（swarms），深入研究 RLM（递归大模型），并尝试运行标准化的评估。 今天展示的所有结果都可以通过我们 Prime Intellect 的验证器（verifiers）软件包来运行。最后，向我的合作者们致谢，他们非常优秀，和他们合作非常愉快，谢谢大家。

[掌声]好了，接下来我们请 John。

大家好！我非常高兴能在这里介绍我们在斯坦福大学一直致力于的一个项目。这个项目是我与共同第一作者 Ivanka Orion 以及我们的导师 Hazeni 和 Christopher Ray 共同合作完成的。

个人人工智能目前无处不在，但今天它主要还是基于云端的。我们看到了许多不同的框架和项目，专注于处理日常写作、研究、编码和日程安排。 然而，像 OpenClaw 和 Hermes agent 这样的项目，通常依赖云端大语言模型来提供大部分智能支持并处理绝大多数查询。

这意味着什么？这首先意味着成本相当高昂。如果把一年的 API 费用累计起来，你会花掉成千上万美元。 其次，它并不具备隐私性。你往往会将自己最私密的数据发送到云端的大模型，并且你未必清楚所有这些数据最终流向了何处。 此外，它还要求你“租用”智能，而不是直接开箱即用地拥有它。

此外，本地大语言模型消耗的能量往往比在笔记本电脑上运行少几个数量级。随着本地大模型终于发展到足够成熟的水平，能够实际处理人们关心的许多查询，我们看到了这种转变。 目前现有的本地大模型，仅仅落后于过去的最先进前沿模型大约 6 到 12 个月。例如，像 Qwen 3.8 27B 这样的本地大模型，其性能大致与过去在 2025 年 8 月时的最先进模型 Claude 4.6 Opus 相当。 随着笔记本电脑和工作站的硬件加速器变得越来越好，这一差距似乎正在进一步缩小。就在本周，我们看到了苹果发布了全新的 Mac Mini，这表明苹果以及英伟达都重新聚焦于专门为个人使用场景构建加速器。

在这个项目中，我们希望探索一个核心问题：能否在完全保留在本地设备上的同时，构建个人 AI 栈的核心部分——即模型推理、智能体执行、内存和学习。这些部分目前大多依赖云端，但我们的目标是与仅依赖云端的 AI 栈保持竞争力。

为此，我们提出了 Open Jarvis。这个名字不需要过多解释，但我们希望探索在完全免费且保护安全、隐私和质量的前提下，究竟有多少功能可以在本地设备上完全运行。

为了构建 Open Jarvis，我们希望创建最简单的原语集合，用以定义任何形式的工具套件或个人 AI 栈。第一个原语是你需要使用的任何用户界面；第二个原语是围绕可组合推理、使用不同种类的智能与工具的实际智能体逻辑。

对于智能部分，它是你用作维持一切运转引擎的任何大语言模型。这可以是 Qwen、GLM、OSS 或 Gemma 3N。

接着是运行它所需的实际推理引擎，例如 Ollama、Llama.cpp、vLLM、SGlang，以及你运行它所需的硬件。这可以是 Apple Silicon、Nvidia，或其他任何你需要的硬件。

为了让所有这些智能体和智能真正发挥作用，你需要一组可以通过标准 MCP 协议运行的工具和内存。

此外，你还需要某种原语集合来进行实际的学习，无论是基于提示的技术（如 Dify、DSPy），还是基于权重的技术（如 GRPO、SFT 和 LoRA）。你需要某种方法让这个智能体随着时间推移不断改进，从而变得更加个性化和高效。

为了展示 Open Jarvis 的外观，我们尽量采用了人们已经习惯的标准接口。我们希望让用户能够通过桌面端进行交互，并像平时一样正常运行它，同时看到它在资金和能耗方面节省的成本。

我们还希望赋予用户运行各种持续性智能体的能力。这些智能体可以通过 Cron 定时任务保持持久运行，并日复一日地执行标准协议。基本上，我们希望让它能够与人们已经习惯运行的所有工作流进行即插即用式的集成。

我们希望能够无缝对接人们已经习惯运行的各种工作流。同时，我们希望让人们在设备上获得大语言模型的初体验，就像当年人们第一次体验 ChatGPT 或 Claude 那样。

快速过一下的话，这里有一个很好用的方式来设置新的持久化任务。我们有各种不同的组件，需要某种方式来进行实际优化。因此，我们希望通过为这些大模型创建五个核心要素的简单规范，让他们完成优化，从而尽可能不干预大模型本身的运作。

我们发现，通过这个完整的优化循环，我们不仅大幅降低了资金成本和延迟，还显著提升了这些任务的整体质量。这一配置旨在简化为人们在构建这些大语言模型框架时最关心的五个核心要素：智能、引擎、围绕其构建的实际智能体逻辑、运行所需的工具或学习系统，以及针对整个规范的整体优化。

为了帮助弥合本地与云端大语言模型之间的鸿沟，我们认为一个有趣的方法是让云端大语言模型去手动并自动优化整个本地技术栈。这是一个利用云端大语言模型的能力来诊断、提出修改建议并进行把关的好方法，能够为本地大语言模型改进解决方案，同时在实际部署这些本地技术栈进行推理时，又不会产生那些云端大语言模型的成本。

通过云端语言模型来诊断、提出修改建议并进行把关，从而为本地语言模型创建改进的解决方案，是一种利用云端模型能力的好方法。与此同时，当你真正在推理阶段部署这些本地技术栈时，又不会产生云端模型的成本。 我们发现，经由 Claude 或 ChatGPT 等云端语言模型进行优化的 Open Jarvis 配置，比那些直接开箱即用的本地技术栈要有效得多。因为你可以针对不同的工作负载，量身定制特定的语言模型和所需的评测框架。 我们还发现，即使使用当今的端侧语言模型，我们在个人 AI、个人用例、编程以及智能代理任务等不同工作流中，也能够与云端语言模型相媲美。虽然仍有许多任务是本地规模的语言模型尚显不足的，但随着这些语言模型通过更好的蒸馏变得更加高效，以及我们获得了用于运行它们的更好加速器，这种差距正在日复一日地惊人缩小。

即使使用当今的语言模型，我们在实际运行成本上也能实现800倍的降低，同时延迟也大幅减少。

我们还发现，无论选择哪种云端大语言模型，它在优化这些本地开源 Jarvis 配置的整个智能代理循环方面都非常有用。

研究表明，Opus 系列（如 Opus 5）以及 GPT 5.6 Soul 自然是最好的选择。但有趣的是，你也可以选择 Gemini、其他更大的大模型系列（如 Kimi 和 GLM），并利用它们来优化这些本地配置，从而在后期的本地推理中获取效率和性能的提升。

我们还发现，整个 Open Jarvis 测试框架的优化成本比其他替代方案更低，因为其他方案可能需要更多的数据或更多的大模型调用。

这套规范和原语在本地大语言模型设置中最为有效，因为它将整个优化循环以及一整套大模型抽象从云端模型的干扰中剥离出来，专门用于优化整个系统，使其变得真正快速、高效。

展望未来，我们很高兴能继续推进这个项目。我们认为在不久的将来，人们日常的推理调用会有很大一部分——甚至可能是绝大多数——转向本地设备、本地笔记本电脑或本地工作站，而不是像今天这样一切都推向云端标准。

我们认为这些趋势将持续下去，因为加速器和语言模型都在不断改进。

因此，如果你对技术栈中的任何环节感兴趣，无论是更好的本地大模型、更好的加速器，还是用于在数据中心之外部署的更好推理引擎，请随时与我们联系，我们非常乐意交流（屏幕上展示了项目的二维码）。如果大家待会儿还在附近，我们很乐意聊聊，谢谢大家（现场掌声）。

好的，接下来是我们的 YC 项目环节，有请 Josh 和 Rean。

我是乔希（Josh），这位是里根（Rean），我们正在开发 QM，这是 YC 的开源工作代理 harness。 QM 是一个为 YC 的每位员工提供类似 OpenClaw 助手的系统，该助手完全可定制，并可通过 Slack 或我们在这里看到的 Web UI 使用。 每个人都在自己的个人上下文中与 QM 一起工作，该上下文拥有自己的沙盒文件和定时任务，他们还可以在类似 Slack 频道的协作环境中与 QM 一起工作。 人们将 QM 用于相当广泛的事情，比如大量的自动化工作，像邮件分类。 以及法律和财务工作流程，它非常擅长编辑文档和从我们的内部数据库中提取数据，它还可以启动实时的内部 Web 应用程序并协助规划活动等事务。 但它的设计初衷是在日常生活中为某人在 YC 可能遇到的各种任务提供广泛的帮助。

你可能想知道我们为什么要构建这个，这其实是一系列内部代理项目的结果，这些项目这些年来不断发展，所有这些项目都真正乘着模型日益强大的东风。

我们构建的第一个内部代理是在2025年1月左右，内部称之为“通用代理”。它的架构相当简单，本质上就是一个带有工具的系统提示词循环，采用一刀切的通用模式。 当时所有人都在和同一个代理交互。虽然它的架构简单，但在回答数据相关的问题时，表现却出奇地好。 不出所料，随着底层模型能力的提升，通用代理擅长的领域范围也在不断扩大。后来我们把它接入了 Slack，添加了定时任务（crons），并赋予了它更多工具，让它能够在更多领域发挥作用。

到了2025年6月，我们的许多工程师开始使用 Claude Code 和 Codex。我们意识到可以在虚拟机（VM）中非常轻松地运行这些工具，于是将其接入了 Slack 标签。对于只想运行一次性代码变更的人来说，这是一个相当强大的媒介。 我们还将它配置为运行持续集成（CI）流水线，并启动开发环境进行测试。因此，用户可以直接描述遇到的bug或想实现的功能，机器人就会去实际解决它。对于那些甚至从未在生活中修改过代码的人来说，这非常强大。 除此之外，我们还有一个小型的反馈循环：观察机器人的失败案例和出错环节，然后更新代码库中当时的 agents.mmd 文件，确保我们在观察实际使用情况时，系统能不断改进。

今年1月，许多合伙人开始使用 OpenClaw。需要了解的是，YC 的合伙人极其忙碌，他们要在办公时间之间处理大量收到的电子邮件并始终在阅读申请。因此，任何能为他们提供额外赋能的工具对 YC 来说都极具价值。OpenClaw 的特别之处在于，它是许多人使用的第一个拥有自己计算机的智能体。这种特性使其具备了以往智能体范式所不具备的高度可定制性，几乎就像一个个人助理。

到了4月，问题变成了：我们能否在不为每位 YC 员工购买 Mac Mini 的情况下，将这个系统提供给他们每个人？最终，我们在虚拟机中配置了由 50 多个 Hermes 智能体组成的集群。这些智能体确实相当有帮助，但人们需要进行大量配置才能从中获得价值，而且管理这个集群本身就很困难。这有点像打地鼠的游戏，我必须通过 SSH 登录到这些单独的实例中去修复它们。

后续的问题随之产生：既然我们已经从这些智能体系统中获得了巨大价值，那么让我们构建一个新东西，试图解决运行这支庞大的 Hermes 智能体集群所带来的一些缺点，同时保留个性化以及人们真正从中获得价值的特性。

从整体趋势来看，正如乔伊向你们展示的那样，模型正在呈指数级提升。我们开始看到，赋予模型越来越多的能力能带来令人印象深刻的回报。 OpenCloud 为代理提供了自己的计算机，我们开始从中看到非常惊人的回报。因此在今年大约5月时，我们开始思考：如果我们沿着这条思路继续推进，究竟能走多远？

我们非常喜欢“释放潜能”（unhobling）这个视角。不知道你们是否读过2004年（注：应为2023或相关版本，按原文）发布的《态势感知》（Situational Awareness）。 那是一个测试时计算（test time compute）开始兴起的时代，我们也是第一次开始为代理提供工具。当时有一种直觉：在许多情况下，模型所具备的智能其实比我们实际使用的要多。 如果我们真正推动前沿进展，为代理提供它们可以利用的各种能力作为资源，奇迹就会开始发生。 我们在 QM 中实现这一点的第一种方法，基本上是将系统的“大脑”从沙盒中提取出来。在使用 Hermes 和 OpenClaw 时，代理实际上拥有自己的计算机。 这虽然功能强大，但也让代理被困在了那台计算机内部。仅从我们尝试管理该系统的角度来看，这就会带来一些问题——当系统里有哪怕几十个这样的实例时，它几乎立刻就会变得难以管理。 另一个问题是，所有的会话都被困在了那台计算机里。因此我们的做法是，将所有内容都卸载到 Postgres 中。来自人们与代理的所有对话都被集中起来，然后我们将这些内容暴露给代理本身，这样它就能查看整个系统中汇聚的各种上下文。 此外，我们不再将沙盒视为代理居住、在许多方面被困住的“家”，而是将沙盒转变为一种资源——代理可以根据需要随时调用它，这样受到的限制就少得多了。

另一个开始涌现的想法是，你可以积累一个庞大的评估集，包含人们与智能体对话的所有轨迹。原则上，你可以考虑对其进行持续优化，并建立一个自动化的改进循环。 我们在这方面取得了混合的结果。我的看法是，如果你只是派出一大批旨在修复遇到所有漏洞的智能体，并在其中使用大模型作为裁判，你就会开始遇到一种类似“主角综合征”的情况。智能体所做的修复往往只看到大象的某一部分，实际上它们可能无法看清整个系统。因此，让人类继续参与其中依然非常重要，尽管我们非常期待这个过程能最终完全实现自动化。

另一件相当显主要的事情，就是把智能体连接到公司里我们所能触及的所有资源上。我们在 YC 恰好有一个运行良好的命令行界面，它把许多系统连接在了一起。对于其中没有包含的内容，我们基本上允许直接添加任意的 API 密钥以及类似的东西。 此外，我们还希望确保其能力能够媲美在笔记本电脑上工作的普通员工。例如设备代码 OAUTH，我们会将其存入钥匙串中并为你自动刷新。所以，它理想情况下应该模拟一个人在电脑前的工作体验。

我们在数据库中主要将其保持为只读状态，但允许通过人工审核的批量更新写入。具体运作方式是：Agent 会提交一份修改数据库的计划，由人工进行大致审阅，确保没有异常操作后，才会真正执行写入。 我们观察到一个现象：我们开始习惯于直接对这些计划进行快速批准。这有点像大家早期使用 Cloud Code 时，可能对工具的使用审查得非常仔细，但随着时间推移，最终会对 Agent 建立起更多的信任。这是我们在未来几个月会非常密切关注的事情。

正如我刚才所说，我们倾向于将系统中的沙盒视为 Agent 的一种资源，而不是 Agent 实际居住的地方。 在 QM 中，Agent 默认会使用特定的沙盒，也就是分配给它正在对话的用户的那个沙盒。但总体而言，还存在一些 Agent 可以汇聚并与之进行协作的环境。 另一个关键点是，如果 Agent 正在处理较重的开发工作负载，它可以去寻找资源更多的机器；如果处理的是较简单的任务，它就会选择功率较低的沙盒。将这个决策权交由 Agent 本身而不是硬编码在框架中，是一件非常强大事情。

同样地，允许 Agent 接入它自己的运行时环境，让它能够自主选择与其合作的提供商，就能摆脱某些困境。我相信大家在使用 Fable 时也遇到过：如果尝试做 AI 研究或网络安全等工作，经常会遭遇各种拒绝。而当 Agent 能够控制运行时，它在需要避免这种情况时，就可以随时切换到另一个模型。 正如前面的情况一样，在不同的沙盒提供商之间进行切换通常也很有用，而我们能够非常轻松地做到这一点。作为一个总体原则，我们一直试图保持框架极其轻量。 我们认为系统核心由这三种工具组成：在远程沙盒中执行、从对象存储中读取和写入、以及发布内部应用（这是一个相当简单的基于 Git 的系统）。 此外，我们还有用于交互记忆、定时任务（cron）等功能的其他工具。但我们真的只是把这些看作是对系统中粗糙边缘的暂时修补。

磨合工具：设定目标预算

核心在于上面这三项，我们尽量保持其精简，并将其打造为一种迎接AGI的测试框架（harness）。

不过由于我们尚未达到那个阶段，在实际中遇到了一些问题。其中之一是，我们试图将代理（agents）置于拥有各种可用工具的高效环境中，但它们常常过早放弃。

因此，我们在过去一个月左右尝试了一项实验，称之为**“磨合工具（grind tool）”，或者说为目标设定预算**。这样一来，代理在达到一定的实际耗时（例如几个小时）或一定的Token消耗之前，是不被允许放弃任务的。

这样做能带来更好的研究成果、更优质的报告以及类似的效果。看到OpenAI和Anthropic用非常相似的技术攻克数学领域的公开难题，其实非常有意思，而且这同样适用于普通的办公室工作。

我们发现的另一个情况是，这个测试框架本应在多人协作以及Slack中运行，但由于其训练过程的产物，即使我们在系统提示词中作了清晰说明，代理有时仍会对自身所处的环境感到非常困惑。因此，为其提供局部的交互支撑（local affordances）一直非常重要。

另一大问题是，智能体确实不理解社会语境。 具体来说，如果我告诉 Regan 一个信息，他凭直觉就能知道这个信息在什么地方可以分享。 或者至少具备良好的心智框架，但要在智能体身上重现这一点需要做实际的工作。例如，特权信息很容易泄露到不应该出现的语境中。 因此，你可以放入智能体大脑中的信息，实际上受限于你的权限系统有多完善。 幸运的是，YC 拥有一个现有的软件系统，具备多年来构建的细粒度权限管理功能。 但很多人并没有这样的系统，因此需要付出努力来支持细致的知识共享。

感谢大家的聆听，大家可以尝试一下开源的 QM。 编程智能体在搭建它方面相当不错，如果遇到任何问题，欢迎随时提交 issue，我们会进行查看。 我们也在招聘，如果其中的任何内容引起了你的共鸣或者让你觉得兴奋，欢迎随时给我们发邮件。