Prime Agent技术报告公布，ARC-AGI-3得分从30%升至95.5%

同一个基准测试上，得分从30%跳到了95.5%。Prime Intellect解释说，这不是换了模型，而是换了包裹模型的执行外壳所带来的结果。该公司在X上宣布，已公开自家开源智能体执行框架Prime Agent的完整技术报告，报告摘要中写道，ARC-AGI-3的RHAE Best@1指标从30%升到了95.5%。

执行框架为何能让分数翻三倍

执行框架（harness）是语言模型对接实际任务时，在模型之外运行的执行层。调用工具、读写文件、运行代码、出错后恢复、决定保留多少对话记录——这些全都发生在这一层。报告导言把语言模型定义为"有边界的顺序处理器"：模型只能凭借权重和当前打开的上下文里的信息，来决定下一步动作。论文的出发点是，一台电脑能做的事和一个模型能做的事之间存在空白，而这个空白正是由执行框架填补的。

因此，基准测试分数向来是模型和执行框架的合作产物。一次工具调用出岔子导致会话崩溃，成绩单上就只会记为失败。报告写道，Prime Agent"防止执行框架的失败被误判为模型的失败"（引自Prime Agent技术报告摘要）。目的是让测量值更贴近模型的真实能力上限。

8月5日首发，8月24日修订

Prime Agent本身是在8月5日发布的。当时Prime Intellect将其定位为面向编程和长时间自主任务的执行框架，主打编程式工具调用、把上下文当变量处理、多智能体消息传递、能自我修复的框架状态，但当时并未公布基准数据。这份报告正是补上这块空白的文档。论文封面标注首次发布为8月5日，当前版本为8月24日。

作者共11人，论文标注的所属机构是普林斯顿大学、Prime Intellect和麻省理工学院三家。通讯地址列了seth@primeintellect.ai和altzhang@mit.edu两个。据发布文章介绍，这份报告是在公司博客文章基础上扩展而成，把讨论重心放在了"该如何设计执行框架、又该如何评估它"上。

四大组成部分

摘要描述的架构分为四个部件。

部件	作用
持久化IPython REPL	贯穿整个会话的Python执行环境，遵循递归语言模型（RLM）的抽象方式，把上下文当程序处理，运行测试阶段的计算
Continual Harness	跨多个任务轨迹保留对话历史、记忆、技能、提示词和子智能体规范
递归子智能体	智能体之间无需中介、直接协作交流
Agents View	供人查看和管理以守护进程方式运行的会话的界面

关键在于，上下文被当作程序处理的变量，而不是一整块文本。系统不是把冗长的日志原样塞给模型，而是在REPL里做裁剪、摘要，只取出所需片段。执行、恢复、验证、资源核算这些标准化工作由执行框架负责，制定策略的任务则交给模型——这是设计原则所在。

X上的帖子把创新点分成了四条，其中"智能体式上下文管理"和"群体协作与depth-n+递归语言模型"两条完整可见，第三条"对Verifiers的支持"在句子中间被截断，其余内容还是要看正文才准确。

测试范围——从游戏到内核

测量对象的清单很特别：长上下文编程、GPU内核生成、模拟器搭建、自主nanoGPT竞速训练。最后一项是比拼多快能把一个小型GPT训练到指定性能的任务，且全程由智能体自主完成，无需人工介入。摘要写道，在这些领域中，Prime Agent的表现与各模型自带的执行框架或广泛使用的执行框架持平或更胜一筹。

游戏也被纳入测试范围。在建造类游戏Factorio中，系统能通过反复迭代不间断地推进科技树；配上专门的子智能体后，还能把任务拆分并行处理。这种设计似乎是想说明，比起编程基准测试，这类环境更能体现把耗时数小时的目标拆解、多线并进的能力。

想亲自试试

代码已作为开源项目发布在github.com/PrimeIntellect-ai/prime-agent仓库，这也是论文摘要中标明的代码地址。由于执行框架是可以替换模型的一层，把手头正在用的编程智能体换成这套框架来跑同样的任务，比较起来会比较容易看出差异出在哪里。比较实际的做法是：拉取仓库、启动REPL会话，扔给它一个熟悉的任务，再通过Agents View查看会话卡在了哪个环节。

编辑视角

不管你是否照单全收30%到95.5%这个数字，这份报告真正触动的，是过去一年里智能体基准测试分数的可信度问题。我们过去一直把"某模型在SWE-bench上拿了多少分"这类发布当作模型本身的能力指标来读，可如果同一个模型换个外壳分数就大幅波动，那这个发布的其实不是模型的分数，而是"模型+执行框架"这个组合的分数。这正是论文标题把执行框架本身当作评估对象的原因。我们的信息网络里最近也接连出现了类似尝试：量化智能体编程评测中的基础设施噪声、把"大脑"和"手"分开来扩展托管型智能体的讨论。这说明不同团队正在同时钻研同一个问题。

对实际工作而言，这条新闻该怎么读？答案是：换模型之前，先把执行框架整顿好。用过编程智能体的团队大多会卡在同一个地方——不是模型不知道答案，而是工具调用出岔子、冗长日志吃掉上下文、会话中途死掉又没法救回来，导致任务无法完成。这时候如果换用更高级的模型，token成本会翻两三倍,可完成率却提升有限。Prime Agent把执行、恢复、验证、资源核算列为标准化项目,正是精准命中了这个痛点。尤其是资源核算——计算每个子智能体各消耗了多少token的功能，在演示里不起眼，但在实际运营中却直接决定了每月的账单。

对韩国团队来说，眼下最有实用价值的是Continual Harness这个概念。目前大多数智能体流水线的运作方式是：一个任务结束，对话记录连同其中积累的窍门一起消失。而这套设计要在任务之间保留历史记录、记忆、技能、提示词和子智能体规范，用在公司内部的重复性工作上效果会很明显。如果是每周都要做同一种格式报告的任务，到第二周开始，指示就能变短。反过来说，还为时尚早的是群体协作模式。同时启动多个子智能体并行运行的架构，在像Factorio这种目标明确、验证自动化的环境里跑得很好，但在验证标准全凭人眼判断的业务中，并行化只会变成审核负担的增加。

未来几周内，应该会陆续出现固定执行框架、比较不同模型的评测，以及反过来固定模型、比较不同执行框架的评测。同时，在模型发布文档中注明"用的是哪种执行框架测出的分数"，也会逐渐成为一种惯例。Prime Agent能否借此成为行业标准是另一回事，但从今往后，不标注外壳名称、只公布分数的发布，恐怕都要被当成不完整的信息来看待了。