[音乐]

欢迎来到YC Harness Club（YC工具带俱乐部）。我真的很努力，花了大概10次迭代才让Gemini生成哈莎骑龙虾的画面。Gemini一开始不想做，但我们最终搞定了它。好的，欢迎来到Harness之夜。首先，大家觉得新的YC论文俱乐部看起来怎么样？这其实是我在EV（YC的设计负责人）那里随口说出的一个想法，两天后她拿来了这个设计，我当时就想：“这太棒了。”所以，后面的Ev请接受大家的掌声。[掌声] 非常令人兴奋。

那么，为什么要用Harness（工具带/框架）呢？嗯，它听起来就像个说唱歌手。这不过是脚手架罢了，也就是提示工程（Prompt Engineering）。为什么这会值得专门举办一场活动呢？这里有一个来自Reddit的帖子，是一个月前发的，观点相当激进：“我不确定这种提示工程是否配得上顶级机器学习会议。”还有另一个很棒的评论说：“上下文工程不是一个研究问题。”

所以我认为，Harness长期以来被轻视为次等的研究工作。然而，它确实能带来18%的性能提升（从Harness 1到Harness 2）。正如Seth将要告诉我们的，这也是ArcGI能否正常工作的关键区别。因此，这显然值得进行一定程度的研究。如果你看看经典的MeterPlots发布日期以及智能体可以运行多久，你会发现很多进展都归功于Harness。

我将此称为“静态Harness时代”，即没有自我改进的Harness。而最近——也许是过去六个月，重点都在于“自改进Harness”。我们会逐一讲解这些内容。我实际上在Trajectory首席执行官的一次演示中看到了这张图表，我非常喜欢它。他在谈论我们如何不断测量困惑度（perplexity），这在一定程度上与智商相关，反映了模型的智能程度。

因此，我们不断在这个智力/智商维度上向上推进，但我们并没有很好地利用测试时经验（test-time experience）。我们生成了大量的测试时经验，面对一个新的领域，它确实存在，但我们并没有快速适应。如果你记得我们早期做的YC论文俱乐部之一……我一直在做这个实验：随着我增加在线样本的数量，你如何仅仅从批量大小为1的数据中学习？

我们并没有那种结构。我们有上下文学习（ICL），一旦ICL饱和——在加载了大约40或50个样本后，它在验证集上实际上没有任何提升。然后你必须去使用低秩适应（LoRA）小排名，接着是LoRA大排名，然后是监督微调（SFT）。这有点奇怪，为什么我们有如此不同的训练流程。我认为这正是Harness发光发热的地方。

ArcGI所暴露出的，也就是ARGI的主要观点，是它适应新问题、新分布并表现出色的速度有多快。ArcGI实际上与我一起经历了2026年冬季的批次，我们帮助Greg审视了这一点。正如我上次提到的，在这些游戏中投入了大量的思考和注意力，以确保从游戏一到游戏二都是正交的（相互独立的）技能，从而隔离出这种流体智力的测量。

Claude Opus是第一个在保留集上得到验证的模型，这是除了Greg和Chalet之外没有人能访问的数据。他们得到的最好成绩是30%。而仅仅通过一些Harness——这个不值得任何研究的东西，只是一个包装和脚手架——我们就能达到95%。Nvidia的AVO达到了100%。这是最近刚刚发布的Prime Agent和Nvidia的情况。

我想补充的另一件事是，当Carpathy在三月推出他的自动研究员（auto researcher）时……我想说的是，我分叉了它并进行了尝试。我只想做一个小小的用户界面来查看正在发生的事情并进行跟踪，结果我不小心构建了一个Harness。我本意并非如此，我只是想看到它。基本上，你指定一个目标（purpose）。

在这个例子中——这实际上是我给出的真实案例——是“扩散语言模型不要击败自回归语言模型（ARLM）”。但也许如果我进行集成，将扩散LM分割成许多不同的部分……因为与AR相比，单个GPU上的扩散模型具有极高的算术强度。通过聚合分割后的结果，我实际上可以获得更好的效果。

于是我将这个目标作为目的提供给我的智能体套件……我的智能体群（swarm of agents）。我给它一些种子想法。我想改变集成的大小，以不同的比例进行分割100次、10次、5次等等。然后我指定一个验证指标（valometric）。也许我想做GSM8K和类似GPT-2的设置之类的。

然后我有一个范围界定智能体（scoping agent），它会查找类似的论文，查看GitHub仓库。我们会把它交给一个名为Chris Ray的PI智能体（项目负责人）。然后他会将其交给一个研究智能体，名叫John South Khan。他在那里工作并开始做一些事情，然后给顾问团寻求一些帮助。

那就是我介入的地方，我和Yaso会给你反馈，然后你再多做一些工作。当你准备好时，Chris Ray会继续关注你的进度，每隔一小时左右催促一下你，然后它就交给作者智能体说：“好了，现在停止冻结这个想法，开始撰写消融实验（ablations），然后开始写论文。”

那么这变成了什么样子呢？这是范围界定智能体，然后你有一个驾驶舱（cockpit），你可以从任何地方查看。我们做了Tail Scale扩展，所以你实际上可以从任何地方访问这个URL，看到它是如何进展的并与其交谈。如果你在这里构建了整个1B（十亿）参数的东西，它只会给你发送电子邮件更新。

然后它实际上开始发表一些论文……我读过这些论文，它们确实不错。三月、四月开始时并不好，你知道的，到了五月或什么时候才变好。但现在我基本上给八个H100节点各提供八个想法，每个节点有八块H100显卡。然后让它们继续运行。

我定期检查，它们把论文交给我。我们在那里处理的情况简直令人难以置信。真正改变的只是你加在上面的脚手架，以允许它这样做。我并没有在这上面花费大量的时间，但这在很大程度上是我进行许多研究的方式，至少是初始想法。

所以是的，我会给出六个不同的我想尝试的想法，然后把它放在一边让它自行运行。我们现在能够做到的事情——仅仅因为Harness的存在……

同一个权重文件的效果简直令人惊叹。我整个周末都在为此做准备，阅读了大量关于自我精炼、反思（Reflection）、Voyager 以及 Tool Former 的经典文献。我想简要回顾一下这五年的发展历程：我们是如何走到今天的？我认为这一点很重要，因为许多刚进入 AI 领域的人可能缺乏这种背景知识。因此，以下内容并非按时间顺序排列，因为那样教或展示并不合理。我会跳过许多论文，甚至可能极度简化它们，对此表示歉意。

最初的 GPT-2 基准测试（2019年2月）是一个简单的序列循环。主要包含 Top-P 采样和环境交互，这就是 V0.5 的基准测试形式。以 GSM8K（数学题）为例，系统提示设定了角色：“你是一名数学老师。”接着给出上下文：“Susie 有五美元，花了三块。现在还剩多少？”当时没有思维链（Chain of Thought），输出格式仅仅是“####”后跟答案和序列结束符。我们测量的是哈希符号后的内容，正确得一分，错误扣一分。

过去六年主要是在静态基准测试中增加功能。例如，在上下文中提供示例（Few-shot learning），让模型从之前的例子中学习逻辑。随后出现了思维链，即不再直接预测答案，而是通过更多 token 来推导计算逻辑。此外还有动作空间创新，如 Tool Former 和 WebGPT，赋予模型调用工具的能力。这些工具本质上是包含指定参数的 JSON 对象。

以减法为例，与其在权重文件中硬编码计算结果，模型可以直接调用 Python 工具执行“sub(5,3)”并得到答案。所有工具都在系统提示中暴露，这就是工具的来源。接着提出了 Memory 概念（如 MeGPt），允许模型对上下文进行创建、读取、更新和删除操作，而不仅仅是追加。这分离出了一块可更新的“记忆”区域。

Voyager 则进一步提出，如何将工具链式组合以完成任务，并将学到的技能蒸馏回系统提示以实现永久学习。这催生了“技能”概念，他们在 Minecraft 中实现了这一点。随后是 InterCode，通过输出代码实现即时工具或技能（尽管是否算作 API 仍有争议）。接着是 ReAct、自我精炼和反思：多角色代理通过互相反馈在上下文中实现自我改进，从而变得越来越聪明。

例如，如果模型算错了（如混淆了数字），它可以发送给内部评估器检查正确性。若发现错误，它可以选择循环重试或从环境获取奖励信号，进而进入反思阶段修正结果。这是多代理让模型自我反思并改进输出的早期理念之一。

这一思路进一步发展为多代理架构，可以生成子代理并在持久化交互中运行。主代理通过维护子代理列表来调用它们，并不断添加新启动的子代理。RLM（Recursive LLM）更是将其递归化，允许通过调用 RLM 查询来解决更复杂的问题。每当需要时，主协调代理可以递归地生成 LM 代理来处理子任务。

这就是所谓的“基准测试 V1.0”，整个流程基于静态设置，不改进系统提示或更新基准本身。这一切都依赖于 GStack（Gary），他让我们实现了这些功能，我们要感谢 Gary 和 GStack。此外还有一些值得提及的项目。总结来说，你有一个代理规范、系统提示以及允许的回合数和工具调用次数限制（避免无限循环）。

你指定了工具列表、技能列表和子代理列表，这构成了 V1.0 的核心。然后将其放入循环中运行。它可以由提示触发，比如在 Slack 频道中执行任务（如 QM，我每天都在用），或者在空闲时每小时醒来自主工作。这就是会话的基本运作方式。

管理流程中存在一个循环，涉及上下文编译。我们实际上是在构建上下文，将所有内容输入语言模型调用中，然后获取返回的动作。接着，我可能会根据需要调用的工具将结果追加回上下文中。这基本上就是 Harness v1 的运作方式。而最精彩、最令人兴奋的部分在于我们看到了许多进展，即让 Harness 本身具备学习能力。我们可以学习系统提示词，也可以直接优化 Harness 自身，这非常奇妙。

我原本希望 DSPY 团队能来分享他们的成果，但他们今晚在旧金山举办了一场有 150 人参加的 DSPY Meetup，所以无法出席。我之前曾与他们做过播客访谈，他们的社区非常棒。“DSPY”代表演示（Demonstrate）、搜索（Search）和预测（Predict）。他们的核心理念是基于一组训练样本和小量示例，学习出最优的系统提示词。

我不断迭代这一过程。虽然无法通过反向传播优化这个过程，但我可以采用遗传编程的方法：寻找候选方案、合并这些候选者，并依据特定的合并规则进行评估观察结果。通过不断重复这一过程，我实际上获得了对系统提示词本身的增删改查（CRUD）能力，从而能够选择任何理想的系统提示。

Darwin Machines 则更进一步：不仅允许更改系统提示，还允许直接修改运行中的 Harness 代码。你可以想象这样一个档案库，其中包含许多不同的 Agent（即 Harness 和系统提示的组合）。我们从这些组合中进行采样，通过某个适应度函数评估它们的性能表现。

随后将结果重新加入这个状态档案中。这里我略过了“自我修改”的部分：实际上存在一个元 Harness（meta harness），它允许 Agent 修改自身的 Harness，使其转变为另一种形态。这个过程循环往复，随着时间的推移，Agent 的表现会越来越好。

这个元 Harness（即主 Harness）的功能是生成其他 Harness，这是一个非常“元”的概念。在这个输出空间中，你配置多 Agent 的上下文编译过程，并对所有环节拥有增删改查权限。因此，它会不断增加更多代码到 Harness 中——包括图中显示的所有绿色部分、元提示词（meta prompt）、各个 Agent 的系统提示以及 Agent 的数量等。

随着时间推移，这种元 Harness 会不断生长演化。这篇论文的第一作者今晚就在现场，非常令人兴奋。你应该去和他多聊聊关于“持续 Harness”（continual harness）的话题，我非常喜欢这个概念。他们甚至更进一步：在记忆类别上增加了额外的维度，引入了“历史”机制。

他将在后续详细讲解这种记忆的细分结构。但在我看来，最酷的部分对于经典的强化学习（RL）研究者来说尤为明显——我看到罗伯特就在那里坐，他一定会喜欢这种类似 Dagger 风格的在线学习机制。在这种模式下，你可以直接更新权重文件本身。

这意味着你实际上是在对基于大语言模型（LLM）的 Agent 进行测试时训练，仅利用刚刚学习到的少量示例。我认为这是一个非常重要且值得深入研究的重大方向。好了，以上就是我的分享。

今晚我们有三位作者出席。不幸的是，Ben 今早食物中毒了，所以没能来现场，这很令人遗憾。但我们仍有三位杰出的作者：Seth 是普林斯顿大学 Shein 教授的学生，也是 Prime Intellect 的研究员及 Prime Agent 的作者；John Sadavone 是我们第一次邀请到的演讲嘉宾，他非常兴奋。

他是 Chris Aelia 指导下的博士生，也是 Open Jarvis（由我实验室 Hazy 与 Ivonica 合作开发的个人版 Open Jarvis）的作者，我觉得这非常酷。此外，Josh 和 Rean 也值得掌声——Josh 刚刚被提拔为 YC Labs 的负责人，这非常令人振奋。

他们谈论的是 QM（Quantitative Market）。我们在 YC 使用的通用 Agent，而他们在一个月前推出了 QM。它在功能性和实用性上有了显著提升，我每天都在使用它。好了，我就说这么多，非常感谢大家。（掌声）

大家好，很高兴今晚来到这里。我叫 Seth，我将展示 Prime Agent，这是一个自我改进的 ROM Harness（运行环境）。我今晚的任务是试图说服大家采用一种基于第一性原理的方式来思考如何构建你的 Harness。

我们要从非常基础的概念开始讲起。如果你回顾相关文献的介绍，你会发现它们与我看待这个问题的角度非常契合且互补。如果我们只看原始的 LLM 本身，它实际上只是一个顺序处理器：拥有固定的权重和可见的上下文窗口。

它接收一些输入 token，输出另一些 token 以做出下一个决策。如今我们很少这样看待 LLM 了。我们认为它拥有访问一系列文件的权限，被赋予了无数程序和工具供其使用。你甚至可以让它与其它正在运行的 LLM 会话进行消息交互，创建子 Agent 来完成各种酷炫的任务。

但在基础层面，它仅仅是“输入 token、输出 token”，是一个做出预测的神经网络。而 Harness 则是位于 LLM 与世界之间的一层，它添加了持久化状态、工具和计算能力等要素。

以下是我们从人类视角看待 Prime Agent 的架构图。就像使用 Cloud Code、Codec 或 Pi 一样，你在电脑上打开 Prime Agent。它会带你进入“Agent 视图”，这是一个概览界面，展示了你所有正在进行的并行会话中的 Agent。

这里有一个非常紧凑的摘要显示了你正在使用的资源，你可以点击进入其中一个进行详细查看。在那里你会进入“根会话”（root session），这基本上是一个项目协调器，负责控制所有不同的子 Agent。

你不需要手动要求它启动子 Agent；当有用时，它会自主利用子 Agent 来完成任务。所有这些调用都是程序化的，因为这一切都基于递归语言模型原则：所有的工具、记忆和子 Agent 都处于这个 IPython Shell 环境中。

为了进一步的协调，我们暴露了这些消息传递范式（messaging paradigms）。因此你可以管理……

所有这些智能体可以直接与你的环境进行交互，这可以是计算机上的程序和文件，或者是为你的自动研究运行 H200 节点集群。每个智能体都由你计算机上持久的“持续执行框架”（Continual Harness）支持。这样做是为了确保当你关闭笔记本电脑或按 Control+C 退出会话时，它仍在后台运行。你必须实际停止会话才能确保其持续运行。

此外，我们还从持续执行框架中暴露了其他功能，使其能够对之前提到的所有组件提供实时的 CRUD（创建、读取、更新、删除）操作，以管理其记忆、技能、子智能体以及持久化自身的系统提示。

我喜欢这样理解我们构建的所有上下文：就像有 L1、L2、L3 层级。这类似于缓存，即我们正在处理的最易访问的信息。最快且立即可用的信息是模型权重，因为模型能极快地检索它。大家都希望将所有信息放入模型权重中，但我们意识到这可能行不通，因为不想每次更新都进行微调，那成本太高。

因此，我们有了活跃的输入上下文，使用大量令牌作为输入。我们可以像之前看到的那样包含一些“上下文内示例”来增加不同能力，但在某一点上我们会耗尽上下文窗口。因此，即使那些声称需要最简框架的人至今仍在使用“压缩”（Compaction），因为它是一种通用工具，让智能体能够总结其自身的上下文历史以突破上下文长度限制。

一旦我们超越了模型直接的输入和输出，进入 L2 或 L3 层级，你可能熟悉作为分发状态的 L3。例如在处理文件系统时，你可以从主内存中读写。而在活跃上下文与文件系统之间的 L2 层级，你可能拥有一个实时的 Python REPL（如 Jupyter Notebook 中的 IPython shell）。所有变量都直接保存在 RAM 中。

智能体可以以编程方式操作这些信息并运行各种程序，从而节省大量令牌，避免将其直接放入上下文。你还可以创建子智能体，本质上也是在这里保存上下文：你可以将特定的一组信息分配给智能体以执行某些操作并报告结果。

有趣的是，对于活跃上下文我们讨论了压缩以帮助随时间更新其历史从而继续利用它。但一旦超出这个范围，我们就需要考虑如何执行这些更新操作：不仅仅是创建和读取，而是如何在随时间推移中更新或删除上下文或状态。

我喜欢将 REPL 视为一种“自主垃圾回收”机制，用于清理状态中的变量以及确定哪些子智能体可用。这能确保 RAM 不会导致电脑每天崩溃。在此基础上，还有“精炼”（Refinement）的概念，即更新和删除系统中存储的技能、记忆和提示。你可以将其视为防止硬盘空间耗尽的方式，从而表达如何构建并随时间修订这一机制。

另一个我极力推崇的视角是：随着框架逐渐演变为我们正在创建的“自主操作系统”，如果将其隐喻化，原始的 LLM 更像图灵机：你有纸带输入指令并执行操作。但框架看起来更像是冯·诺依曼计算机，能够对外部内存进行读写操作，这使其比图灵机能表达的问题类别更强大。

那么如何构建一个好的框架？它应是你所能想象的最具表现力的东西。早期的框架在进入模型自我优化的数据飞轮之前非常具体，如计划、行动、批评等精确步骤。现在模型能自己做到这些，我们不再需要显式强加 ReAct 循环，因为模型已原生掌握。

但它们尚未解决的是如何具备调用压缩、运行 Python 程序、以编程方式创建子智能体以及访问状态和不同反馈机制的表现力。这些都是由模型控制的表现力特性，如果移除其中任何一项，实际上就是移除了它无法通过其他方式完成的一项能力。

关于管理方式，我确信你们都熟悉我的合著者 Alex 的 RLM 论文。我们在该论文基础上的创新是将子智能体视为持久的子会话。父会话可以启动一个新的 RLM 子智能体，每个子智能体会执行任务并返回最终状态给父会话。

这些子智能体随后处于空闲状态，但仍驻留在 RAM 中工作。在任何时候，父会话都可以向其中一个子智能体发送消息以继续工作，并保留其随时间积累的良好上下文。这样你就不会丢失信息或不得不重复使用先前上下文中已开发的信息。当然，我们不想占用太多 RAM，所以我们可以移动……

将它们卸载并处于非活动状态，随后可以通过消息传递随时调用它们。在这种持久的子代理设置中，我简要提到了持续增强机制（continual harness），这在我之前的论文中有过讨论，涉及对整个增强状态的编码。这是我们希望代码代理具备的另一个特性，即利用我们所有的历史数据。你可以想象存在一些轨迹，其中包含动作、结果或每一步发生的事件。因此，我们旨在赋予代理利用所有这些信息进行反思的能力，以更新未来增强机制的形态：我们需要修改系统提示吗？需要创建一些技能吗？

我认为“技能”是指为实现特定目标而设定的一组指令或程序。此外还包括记忆功能，这可以是关于重要事项的长期存储，以及我们在持久化语境中讨论过的子代理规范。是否有某些子代理因上下文有用而值得在稍后复用？这种随时间推移进行反思和优化的能力对模型而言非常强大。虽然它们目前尚不完美，但这是构建增强机制时希望具备的能力，使其优于当前模型的表现。

这样，你就可以获取推理轨迹，并利用其推动下一轮模型的迭代，使代理能够驾驭增强机制并自我引导至更高的性能水平。Prime Agent 中最酷的功能之一，自从我开始研究此项目并作为早期添加功能以来一直存在：允许任何两个代理之间进行消息传递，例如在核心家庭结构（父母、子女、兄弟姐妹）中。我这样设计的原因是，我一直在思考如何最好地管理那些每天朝五个不同方向、五十亿个方向为我工作的代理。

如果它们能直接共享联系人并相互协调，那将会好得多。事实证明，这对于典型的软件工程及长周期任务同样出色。最后，在设计增强机制时，我们着重考虑了长期性能表现。我希望运行一些任务而不必全程监护代理；当我回来检查时，可以查看进展。这一视角在我所审视的许多评估中往往缺失：很多时候，如果模型运行时间不足或预算耗尽停止工作，而另一模型通过更多预算继续运行，这并不公平。

首先，你并未使用相同的固定支出进行比较；其次，这可能掩盖了被忽略的性能表现。我对长期性能评估的看法是：我想看到实际的收益 plateau（平台期），即在投入更多测试时间 token 后，性能仅获得增量提升的临界点。在分享关于 Prime Agent 设计理念之后，我将展示几项实验，讨论测试时间扩展（test time scaling）及我们的 TI 结果。

我们还将探讨信息管理为何对长上下文处理有益，以及在近乎超长期的任务中如何维持多日工作流。当进行持续一周或更长时间的优化时，具体会发生什么？这是一个你可能见过的结果图。我们在此增加了一个原始数据中未包含的数据点，以便跨增强机制进行比较。在确定当前最受关注的最佳评估标准时，我们决定采用 ARC-AGI 测试。

我记得之前用持续增强机制运行过结果，使用 Gemini Flash（或更正为 Gemini Pearl）达到了 20%。我认为我们可以至少达到这个水平，人们对我们未针对 ARC-AGI 专门设计的通用增强机制表现良好感到惊叹。因此，我上网寻找一个好的系统提示词以确保不丢失信息，并在另一个社区排行榜 Prolong 上找到了它。

我直接将该提示词输入 Prime Agent，首次运行即达到 99.9%。查看日志后我发现自己作弊了。于是，我花了另一天时间设置适当的沙盒环境以规范流程。再次运行后，使用 GPT-4o 达到了 78%，这是一个很棒的结果。我们随后对比了其他模型，使用了通用的系统提示词：“使用世界模型解决 ARC-AGI 3”，并列出可用动作。

Prime Agent 的通用系统提示词包括：拥有 Ripple（波纹）机制，可调用子代理并以编程方式使用。我审查了推理轨迹，发现它通过大量代码调用来检查不同场景、分析图像并进行图像处理。这些操作展现了合理的推理过程，并充分利用了我们作为核心赋能机制的 Ripple 功能。

随后我运行了其他测试，GPT-4o 得分为 25.7%，这非常令人印象深刻。与一周前的结果相比，OpenAI 的表现凸显了增强机制在评估中的重要性。我们使用的是 Responses API。

这是我们得到的结果。我们运行了 Terra，虽然这次没有完全跑完，但相比之下取得了非常好的成果。我们发现其表现已经超越了一些诸如 GBT Soul Extra High 这样的模型，这简直令人难以置信。随后我们使用 Opus 进行评测，得分达到了 95.5%，大家都觉得这太疯狂了。我们还将其与许多其他基准测试进行了比较。

有人问我是否使用 Cloud Code 运行过此项目，我确实试过。不幸的是结果并不理想。因此，与其展示糟糕的结果，我决定引用原始的 Cloud Code 数据以及其他人使用类似 Prime Agent 配置所获得的更好结果。有趣的是，许多非常流行的基准测试在 Prime Agent 表现优异时并不一定表现出色。

例如 Air Agent，我们很快花费了大量资金，由于性能提升微乎其微却耗资约 5000 美元，我们不得不终止测试。虽然这不一定是它们能达到的最佳效果，但成本确实很高。我认为性价比非常重要，而能够以编程方式处理上下文是节省资金的关键因素之一。

我们还运行了一系列长周期评估，如 Oolong 和一些编码模拟器基准测试（即将发布），后者是 Program Bench 的替代品。我们发现其表现大致相当或略优于其他基准测试，在不同模型对比中（设置从 GLM 5.2 到 Opus 5/5.6），我们并未针对任何单一评估过拟合。

另一个我认为非常酷的项目是 Emulator Bench，这是一个 Program Bench 的替代品，我们试图重现整个计算机系统模拟器（在此案例中是创建 Game Boy Color）。有趣的是，由于其在 RLM 中具有这种循环访问能力，它能够利用程序以更具表达性和自由的方式在提交最终解决方案之前进行实验外循环设计。

我们还尝试了 GPU 内核，在不同模型（Soul 和 Kimico）中获得了大致相当的结果。一个表现较好，另一个较差，但总体持平。对于长周期任务，我们进行了一些使用 Nano GPT Speedrun 的自动研究实验并进行了扩展。我们分配了 8 台 H200 GPU，运行一周观察结果。

Prime Agent 本应表现更好，因为它能进行大量编程工作，但方差较大。由于任务非常困难，我们无法将任何优势归因于基准测试框架还是模型本身。但我们可以检查许多观察到的行为。有趣的是，我们看到了 Deep 6v4、GLM 5.3 和 Kim K3 等模型的表现，这些结果比我们的初步数据更新。

我们观察到它们在进行“实验外”操作：尝试在 CPU 上运行实验，查看参数化设置，进行超参数搜索并分析数据。这样就不必将所有时间都花费在昂贵的 H200 实验上，因为那占据了大部分时间。也就是说，它们运行非主要实验以优化整体流程。

我认为这种随着我们塑造 Prime Agent 表达性需求而展现出的行为非常酷。你可以利用优秀的自动研究功能，因为如果它在自动研究中表现出色，它也能很好地辅助人类；若加入人机协作以引导实验启动，效果甚至会更好。

最后，我们还直播了一场为期 7 天的工厂式运行，共使用了 633 个智能体，输出了总计 2300 万个 token。目的是在技术树上实现持续的技术进步，随时间推移不断前进。主要优势之一是我们可以使用子智能体将任务分解到工厂的不同环节中，用于研究、构建和收集资源。

这些子智能体负责设计下一个项目以完善工厂结构，同时利用精炼机制借鉴过去的经验以帮助未来。在如此长的上下文中，它不会陷入停滞。最有趣的是，即使在最后阶段，它也并未卡住，而是继续推进技术发展。

这更像是一个类似“Gemini 玩宝可梦”式的结论。如果今天只有一件事值得你关注并加入自己的基准测试框架，那就是要考虑智能体上下文管理、群体协作（Swarms），深入探索 RLMs 并尝试运行标准化评估。我们今天展示的所有结果都可以使用 Prime Instruct 提供的验证器包来复现。

感谢我那些出色的合作者，我很享受与他们的共事。（掌声）接下来是 John。大家好，我非常兴奋能谈论我们在斯坦福大学一直在研究的一个项目。我与共同第一作者 Ivanka Orion 以及导师 Hazeni 和 Christopher Ray 一起工作于此。

个人 AI 无处不在，但如今主要受限于云端。我们看到许多专注于日常写作、研究、编码和调度的基准测试和项目，但像 OpenClaw 和 Hermes Agent 这样的项目通常依赖云端大语言模型来处理大部分智能任务和查询。

这意味着成本相当高昂，如果按年累计，API 费用可达数千美元。此外，它不具备隐私性，你经常将最个人的数据发送到云端的大模型中，且不一定清楚这些数据最终去了哪里。它还要求你“租用”智能，而不是开箱即用地拥有它。

最后，与在笔记本电脑上直接运行这些大模型相比，云端方案消耗的能源要多出几个数量级。如今本地大语言模型已经足够好，可以实际运行人们关心的许多查询任务。我们看到当前的大模型仅落后于之前的前沿最先进模型 6 到 12 个月。因此，今天的模型如 Qwen 3.8

27B模型，其性能大致相当于早期的Claude 4.6 Opus。那是2025年8月时的最先进模型。随着我们用于笔记本电脑和工作站的硬件加速器日益完善，这一差距似乎正逐渐缩小。就在本周，苹果发布了搭载新Mac Mini的更新产品。

因此，我们看到包括苹果和英伟达在内的公司重新聚焦于构建专门针对个人使用场景的加速器。通过这个项目，我们旨在探索一个核心问题：能否在本地设备上构建个人AI栈的核心部分——即模型推理、智能体执行、记忆和学习，这些功能目前主要依赖云端？

同时保持与纯云栈的竞争力。为此，我们提出了Open Jarvis（名字无需解释）。我们希望探索在完全免费且保障安全、隐私和质量的前提下，能在本地运行多少内容。为了构建Open Jarvis，我们旨在创建一套最简单的原语集，用于定义任何类型的个人AI栈。

第一个是所需的各种用户界面；第二个是基于组合推理和使用不同智能与工具的实际代理逻辑。对于智能部分，它是驱动一切运行的语言模型引擎（如Qwen、GBDO、OSS或Gemma 3N）。接着是运行该模型所需的推理引擎（如O Lama、Llama CBP等），以及所使用的硬件平台。

为了让这些智能体和工具发挥作用，你需要一套可通过标准MCP协议运行的工具和记忆系统；还需要一组用于学习的原语。无论是基于提示的技术（如Japa或DSPI），还是基于权重的技术（如GPO、SFTT和LoRA），都需要一种让智能体随时间改进并变得更个性化、更有效的方法。

为了展示Open Jarvis的样子，我们采用了人们已习惯的标准接口。我们希望用户能像往常一样通过桌面与之交互，同时直观地看到在成本和能源上的节省。我们还希望赋予用户运行不同类型持续智能体的能力，例如针对定时任务持久运行的标准协议代理。

基本上，我们要让这一切与人们熟悉的现有工作流即插即用。我们希望让人们首次体验本地大模型的方式，就像当年初次使用ChatGPT或Claude一样。为了快速演示，这里展示了设置新持久任务的便捷方式。我们拥有所有这些不同组件，需要一种优化方法。

为了尽可能减少语言模型的干扰，我们通过定义这五个原语的简单规范来引导优化过程。我们发现，经过这一完整的优化循环后，不仅显著降低了美元成本和时间延迟，还在测试中大幅提升了整体质量。此配置简化为构建语言模型栈时人们关心的五个核心要素：智能、引擎、代理逻辑、工具或学习系统，以及整体优化规范。

为了弥合本地与云端大模型之间的差距，我们设想让云端的语言模型自动优化整个本地栈。这利用了云端大模型的诊断能力来评估提议的更改并生成改进方案，从而在不产生部署本地栈推理成本的情况下优化它们。我们发现，由云端大模型（如Claude或ChatGPT）优化的Open Jarvis配置，比开箱即用的本地栈更有效。

这是因为它们可以针对特定工作负载所需的特定模型和支架进行定制。我们发现，即使使用当今的本地大模型，在个人AI、编码和代理任务等不同工作流中也能与云端大模型相媲美。尽管本地小模型在许多任务上仍显不足，但随着模型蒸馏效果更好、加速器更先进，这一差距正逐月缩小。

即使使用当今的模型，我们在实际运行时的成本也能降低800倍，同时显著减少延迟。我们还发现，无论选择哪种云端大模型来优化本地Open Jarvis配置的整个代理循环都很有用。我们发现，Opus系列（如Opus 5）和GBD 5.6 Soul自然是最佳选择。

有趣的是，你也可以选择Gemini或其他大型语言模型家族（如Kimmy和GLM）来优化这些本地配置，从而在后续进行本地推理时捕获效率和性能提升。我们还发现，整个Open Jarvis支架的优化成本低于需要更多数据或模型调用的替代方案。

我们发现，这套规范和原语在本地语言模型设置中最有效，因为它让云端大模型能够专注于优化整个系统，使其真正快速且高效。展望未来，我们兴奋于能继续……

我们正在构建这个项目。我们认为在不久的将来，你会看到很大一部分、甚至可能是大多数人的日常推理调用将转向本地设备和内部部署的笔记本电脑或工作站，而不是像今天这样将所有内容推向云端。我们认为这些趋势只会继续下去，因为加速器变得更好了，大语言模型也变得更强大了。

因此，如果你对堆栈中的任何内容感到兴奋——无论是更好的本地大语言模型、更好的加速器，还是用于数据中心之外部署的更好推理引擎——请与我们取得联系。我们很乐意与你交谈。附上项目的二维码。如果会后大家有空，我们也希望能聊聊。谢谢。（掌声）

好的，现在我们有了我们自己的 YC 团队，我们有 Josh 和 Rean。大家好，我是 Josh，这是 Rean，我们正在开发 QM，它是 YC 的开源工作智能体工具包。QM 是一个系统，它为 YC 的每位员工提供一个类似 OpenClaw 的智能体助手，它完全可定制，并且在 Slack 或 Web UI（也就是我们这里正在看的）中可用。

每个人都在 QM 自己的个人环境中工作，该环境拥有独立沙箱、文件和定时任务。他们也可以在多人模式下使用 QM，比如在 Slack 频道中工作。人们广泛地使用 QM 进行各种任务，比如大量的自动化操作（如邮件分类、法律和财务工作流）。它在编辑文档和从内部数据库中提取数据方面非常出色。

它还可以启动实时的内部 Web 应用，并帮助处理诸如活动策划之类的事情。但它旨在广泛地帮助用户应对 YC 日常工作中可能遇到的各类任务。你可能会问，为什么我们要构建这个？这实际上是多年来一系列内部智能体项目的结果，所有这些项目都得益于日益强大的模型这一顺风趋势。

我们构建的第一个项目在 2025 年 1 月左右推出。我们在内部称之为“通用智能体”。它相当直接，只是一个带有工具循环的系统提示词。它是通用的，就像每个人都在与同一个东西对话一样。虽然架构很简单，但它回答数据问题的能力却出奇地好。

有趣的是，随着底层模型的改进，“通用智能体”擅长的范围也随之扩大（这并不令人意外）。我们最终将其连接到 Slack，添加了定时任务并赋予它更多工具，使其能够在更广泛的领域具备能力。到了 2025 年 6 月，我们的许多工程师开始使用 Cloud Code。

我们意识到可以很容易地在虚拟机中运行这些代码。然后，我们将它与一个 Slack 标签连接起来，这对于只想进行一次性的代码更改的人来说是一个非常强大的媒介。我们还配置它来运行我们的 CI 管道，并启动用于测试的开发环境。

人们可以描述一个错误或他们希望看到的情况发生，而机器人会去实际解决它，这对于甚至从未做过代码更改的人来说是一个非常强大的功能。但在此基础上，我们还运行了一个小循环来观察机器人失败的地方以及出错的原因，然后更新当时代码库中的 agents.md 文件。

以确保随着我们观察使用情况，这个系统能够变得更好。今年一月左右，许多合作伙伴开始使用 OpenClaw。需要了解的是 YC 的合作伙伴非常忙碌——在办公时间之间，他们收到大量 incoming 邮件，一直在阅读申请。因此，任何能给他们带来额外杠杆效应的工具对 YC 来说都极具价值。

OpenClaw 特别有用，因为它是许多合作伙伴使用过的第一个拥有自己电脑的智能体。这使得它在以前那种智能体范式中无法做到的方式上变得非常可定制，它几乎就像一个私人助理。所以在四月左右，问题变成了：我们能否在不给每个人买 Mac Mini 的情况下向 YC 的每位员工提供这个功能？

因此，我们最终配置了一群超过 50 个的 Hermes 智能体在虚拟机中运行。这些确实很有帮助，但它们需要大量的配置才能让人们从中获益。而且管理这个集群本质上就很困难。这有点像打地鼠游戏，我必须 SSH 进入这些单独的实例来修复它们。

于是接下来的问题变成了：我们从这些智能体系统中获得了大量价值，让我们构建一些东西来解决运行这个大型 Hermes 智能体集群的一些缺点。同时保持可定制性以及人们真正从中获益的那些功能。（转场）

好的，基本上，从 Josh 展示的内容可以看出有一个非常明显的趋势。模型正在呈指数级变好。我们开始看到赋予它们越来越多能力所带来的越来越令人印象深刻的回报。所以，OpenClaw 给智能体自己的电脑，我们开始看到由此产生的非常令人印象深刻的回报。

因此，大约在今年五月左右，我们在思考如果我们继续拉动这根弦能走多远。我们很喜欢“解绑”这个视角。我不知道你们是否读过 2024 年出版的《情境意识》一书？那似乎是一个测试时计算刚刚开始成为潮流的时代，我们开始第一次给智能体提供工具。

有一种直觉认为，在很多情况下模型中蕴含的智能比我们使用的要多得多。如果我们真的在智能体可以利用的能力方面推动前沿，魔法般的事情可能会开始发生。QM 实现这一点的第一种方式基本上是将系统的“大脑”从沙箱中提取出来。

使用 Hermes 和 OpenClaw，智能体拥有自己的电脑，这非常强大但也被困在那台电脑里。这就导致了一些问题，比如我们试图管理它时遇到的困难。

当系统中存在几十甚至更多此类组件时，情况很快就会变得难以管理。另一个问题是所有的会话都被困在那台计算机内部。因此我们改为将所有数据卸载到 PostgreSQL 中，使来自所有代理对话的信息集中化，并暴露给代理本身，让它能查看从整个系统聚合而来的上下文。此外，我们开始将沙箱视为代理可按需调用的资源，而非其受限的居住地。

这种架构开启了一个新想法：积累大量包含人们与代理对话轨迹的评价集，并在此基础上进行自动化的提升循环。然而我们对此效果褒贬不一。如果仅依靠 LLM 作为裁判来派遣代理修复遇到的 bug，容易出现“主角综合症”，即代理只看到局部而忽视整体系统。因此人工介入依然至关重要，尽管我们期待未来能实现全流程自动化。

另一项明显的工作是将代理连接到公司内尽可能多的资源。我们在 YC 已有良好的 CLI，连接了多个系统；对于未包含的部分，我们允许添加任意 API Key。为确保代理体验与员工在笔记本电脑上工作一致，我们将设备代码和 OAuth 令牌摄入密钥链并自动刷新。这旨在模拟人在电脑上的操作体验，理想情况下应尽可能还原真实感。

在数据库中我们主要保持只读权限，但允许通过人工审核的批量更新进行写入。代理会提出编辑数据库的计划，由人先过目确保无异常后再执行。我们发现人们开始倾向于“橡皮图章”式地批准这些计划，就像早期使用 Cloud Code 时一样：起初仔细审查工具调用，随后逐渐建立信任。这也是我们未来几个月重点关注的领域。

在这个系统中，我们将沙箱视为代理的资源而非其居所。默认情况下，QM 中的代理会使用分配给当前用户的特定沙箱。但总体而言，代理可以收敛于某些环境并进行协作。如果处理较重的开发任务，它可以调用资源更丰富的机器；若是简单工作，则使用性能较低的资源。将这一决策权交给代理而非框架本身是非常强大的设计。

同样，允许代理接入其自身的运行时也至关重要。如果它能选择服务提供商，就能避免像 Fable 中常见的拒绝情况——例如在进行 AI 研究或网络安全时容易触发限制。当代理控制运行时，它可以在需要时切换到其他模型以规避此类问题。类似地，在不同沙箱提供商之间切换也很有用，我们可以轻松实现这一点。

我们遵循的一般原则是保持框架极其精简。我们将系统核心定义为三个工具：在远程沙箱中执行、从对象存储读写以及发布内部应用，这是一个相当简单的后端系统。其他用于交互记忆和定时任务的工具被视为暂时弥补系统缺陷的手段，而核心仍是上述三项。我们尽量保持精简，试图构建一种“预见 AGI”的框架。

由于尚未达到那个阶段，我们遇到了一些问题：尽管赋予了代理强大的环境和工具，它们往往过早放弃。为此我们在过去一个月左右引入了“磨砺”机制或设定目标预算：代理在达到特定时间（如几小时）或 Token 消耗限额前不得放弃任务。这带来了更好的研究输出和报告，效果显著。

有趣的是，OpenAI 和 Anthropic 也采用了类似技术攻克数学难题，这也适用于日常办公工作。此外，虽然该框架支持多人协作和 Slack 集成，但由于训练数据的 artifacts，代理即使在看清系统提示的情况下仍可能混淆处境。因此提供本地化的辅助功能变得非常重要，以弥补这一缺陷。

是的，另一个长期存在的问题是智能体（Agents）实际上并不理解社交语境。为了让这个问题更具体化，比如我告诉瑞根一条信息，他直觉上会知道或者至少有一个良好的心理框架来判断在何处分享这条信息是合适的。但要通过智能体重现这一点，需要付出实际的工作量。特权信息非常容易泄露到不应该出现的语境中，因此你能放入智能体“大脑”中的信息量，实际上受限于你的权限系统的完善程度。

幸运的是，Y Combinator 拥有一个现有的软件系统，具备多年来构建的细粒度权限控制功能。但很多人并不拥有这样的基础设施，因此要在智能体中实现 nuanced（细致入微）的知识共享需要额外的工作。好了，感谢大家的聆听。

大家可以尝试使用 QM，它是开源的。编码智能体在部署它方面相当擅长。如果遇到任何问题，欢迎提交 Issue（问题反馈），我们会查看处理。我们也在招聘中。如果这些内容引起了你的共鸣或让你感到兴奋，欢迎给我们发送邮件。