이미지: @PrimeIntellect (X) 화면 갈무리 · METAL LAB 편집
摘要
- Prime Intellect公开了其开源智能体框架（harness）Prime Agent的完整技术报告。该文档最初于8月5日发布，这是8月24日的修订版。
- 报告摘要指出，Prime Agent将ARC-AGI-3的RHAE Best@1得分从30%提升到95.5%，并在长上下文编程、GPU内核生成、模拟器搭建以及nanoGPT自主极速训练等任务中，表现与现有框架相当甚至更好。
- 常驻IPython REPL、保留历史记录/记忆/技能的Continual Harness、可直接对话协作的递归子智能体，以及供人工查看会话的Agents View，构成了该系统的四大支柱。
- 발표 주체
- Prime Intellect (X 게시, 2026-08-26)
- 문서
- 기술보고서 'Prime Agent: A Self-Improving RLM Harness' — 최초 공개 2026-08-05, 현재 버전 2026-08-24
- 핵심 수치
- ARC-AGI-3 RHAE Best@1 30% → 95.5%
- 평가 영역
- 장문맥 코딩, GPU 커널 생성, 에뮬레이터 구축, 자율 nanoGPT 스피드런, Factorio
- 저자
- Seth Karten 외 11명 (논문 표기 소속: 프린스턴대·Prime Intellect·MIT)
- 교신 주소
- seth@primeintellect.ai, altzhang@mit.edu
- 구성 요소
- 영속 IPython REPL, Continual Harness, 재귀 서브에이전트, Agents View
- 코드
- github.com/PrimeIntellect-ai/prime-agent (오픈소스)
在同一个基准测试中，得分从30%跃升到95.5%。Prime Intellect表示，这个数字并非来自更换模型，而是来自更换包裹模型的执行层。该公司在X上宣布，已公开其开源智能体框架Prime Agent的完整技术报告，报告摘要写明ARC-AGI-3的RHAE Best@1指标从30%提升到了95.5%。
harness是什么，凭什么能让分数翻三倍
harness是把语言模型接入实际任务时，运行在模型之外的执行层。调用工具、读写文件、执行代码、在出错时恢复运行，以及决定对话记录要保留到什么程度——这些工作全都在这一层完成。报告的引言部分把语言模型定义为"有边界的序列处理器"：它只能依靠自身权重和当前打开的上下文中的信息来决定下一步动作。这篇论文的出发点，就是用harness填补"一台计算机能做的事"和"一个模型能做的事"之间的空白。
所以基准测试分数从来都是模型和harness共同作用的结果。只要一次工具调用出错导致会话崩溃，成绩单上记录下来的就只是一次失败。报告写道，Prime Agent"能防止harness的失误被误判为模型的失误"（引自Prime Agent技术报告摘要）。目标是把测得的分数尽量拉近模型真正的能力上限。
8月5日发布，8月24日修订
Prime Agent本身是在8月5日发布的。当时Prime Intellect将其介绍为面向编程和长时间自主运行任务的框架，设计要点包括程序化工具调用、把上下文当变量处理、多智能体消息传递，以及能自我修复的框架状态，但当时并未附带任何基准测试数据。这次的报告正是填补了那个空缺。论文封面标注的信息是：初次发布于8月5日，当前版本为8月24日。
论文共有11位作者，标注的所属机构有普林斯顿大学、Prime Intellect和MIT三家。通讯地址列出了seth@primeintellect.ai和altzhang@mit.edu两个邮箱。据这篇帖子介绍，报告在公司博客文章的基础上做了扩展，把讨论的核心放在了"该如何设计harness、又该如何评估harness"这个问题上。
四个组成部分
摘要描述的结构分为四个组成部分。
| 组成部分 | 作用 |
|---|---|
| 常驻IPython REPL | 在整个会话期间持续运行的Python执行环境，遵循递归语言模型（RLM）的抽象方式，把上下文当程序处理，并执行测试阶段的运算 |
| Continual Harness | 在多个任务轨迹之间保留对话历史、记忆、技能、提示词和子智能体规格 |
| 递归子智能体 | 智能体之间无需中介、直接沟通协作 |
| Agents View | 供人查看和管理以守护进程方式运行的会话的界面 |
关键之处在于，上下文不再被当作一大段文本，而是被当作程序处理的变量。做法不是把长长的日志原样塞进模型，而是在REPL里对其裁剪、摘要，只取出需要的片段来用。设计原则是：执行、恢复、验证、资源核算这些标准化的工作交给harness来完成，制定策略的工作则交给模型。
X上的那篇帖子把创新点编号列成了四项，其中"智能体式上下文管理"和"swarm与depth-n+ RLM"这两项内容完整可见，第三项"Verifiers支持"的说明在句子中途被截断。剩下的条目最好还是以正文内容为准。
测试场景：从游戏到内核之间
测试项目的清单挺特别：长上下文编程、GPU内核生成、模拟器搭建，以及自主nanoGPT极速训练。最后一项比拼的是把一个小型GPT训练到指定性能所需的最短时间，而且全程由智能体自主完成，人不插手。摘要指出，在这些领域，Prime Agent的表现与各模型自带的原生框架或业内常用框架相当，甚至更好。
游戏也被纳入了测试。在工厂建造游戏Factorio里，经过反复迭代改进，可以不间断地推进科技树，而且配上专门的子智能体后，任务还能被拆分成多条并行线来处理。这似乎是因为，比起编程基准测试，这种场景更能体现出把一个需要几个小时才能完成的目标拆解、并沿多条路径同时推进的能力。
想亲自试试
代码已经以开源形式发布在github.com/PrimeIntellect-ai/prime-agent仓库，这是论文摘要中标明的代码地址。由于harness是可以随意替换模型的一层，用同一个任务、只更换harness来对比运行结果，就能比较容易看出差异出在哪里。比较可行的做法是：先把仓库下载下来，启动一个REPL会话，扔给它一个自己熟悉的任务，再通过Agents View查看会话具体卡在了哪个环节。
编辑视角
不管30%到95.5%这个数字本身能不能全信，这份报告真正触碰到的是过去一年里智能体基准测试分数的可信度问题。我们一直把"某模型在SWE-bench上拿了多少分"这样的发布当作模型能力值来读，但如果同一个模型换个执行层，分数就能大幅波动，那这个发布的其实不是模型的分数，而是"模型+harness"这个组合的分数。这也是为什么这篇论文的标题干脆把harness本身立为评估对象。我们的信息网络里最近也接连出现了类似的动向：有人试图量化智能体编程评测中的基础设施噪声，也有人在讨论把"大脑"和"手"分离开来扩展托管型智能体。这说明好几个团队正同时在啃同一个问题。
从实务角度该怎么看这件事？答案是：修整harness，比换更强的模型更该优先做。接入过编程智能体的团队大多会卡在同一个地方——不是模型答不上来，而是工具调用出岔子、冗长的日志把上下文吃满、会话中途崩溃又没法救回来，任务就这样卡住做不完。这种状态下换成更贵的模型，token成本会翻两三倍，完成率却提升有限。Prime Agent把执行、恢复、验证、资源核算这四项列为标准化环节，正是冲着这个痛点。其中资源核算——统计每个子智能体消耗了多少token的功能，在演示里不起眼，但真正投入运营时，它决定的是每个月的账单金额。
对国内团队来说，眼下最实用的是Continual Harness这个概念。现在大多数智能体流水线的运作方式是，一个任务结束，对话记录连同从中摸索出的门道就一起消失了。而这套设计让历史记录、记忆、技能、提示词和子智能体规格都能保留在任务之间，用在企业内部的重复性工作上效果会很明显——如果是每周都要生成同一格式的报告，从第二周开始下达的指令就能变短。相反，现在还不到用swarm的时候。同时启动多个子智能体并行运行的方案，在Factorio这类目标明确、验证能自动完成的环境里跑得很顺，但在验证标准只能靠人眼判断的工作中，并行化反而会直接变成检查工作量的增加。
接下来几周内，固定harness比较模型的评测，以及反过来固定模型比较harness的评测，很可能会陆续出现。模型发布文里注明"这个分数是用哪种harness测出来的"，也会逐渐成为惯例。至于最终由Prime Agent来定这个标准，还是另一回事，但从现在起，分数旁边不标注执行层名称的发布，读起来都会显得像是残缺的一半。
评论