Prime Agent：一个 RLM Harness，让 Agent 自己给自己升级 skill 和 prompt
8 月 5 日，Prime Intellect 发布了 Prime Agent 项目的完整博客（8 月 5 日的「AUG 05TH, 2026」日期戳），GitHub 仓库 PrimeIntellect-ai/prime-agent 同步公开，一键安装命令是 curl -fsSL https://app.primei…
8 月 5 日，Prime Intellect 发布了 Prime Agent 项目的完整博客（8 月 5 日的「AUG 05TH, 2026」日期戳），GitHub 仓库 PrimeIntellect-ai/prime-agent 同步公开，一键安装命令是 curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh | sh。这是 Prime Intellect 在 RLM（Recursive Language Model）+ Continual Harness 两条线上的集成产物，也是 2026 H2 「Agent 工业化」赛道里第一个把「harness 自己给自己升级」做成默认行为的开源项目。
这听起来像又一个 LangChain / AutoGPT，但 Prime Agent 想切的不是「加更多工具」，而是「让 harness 本身变成可 CRUD 的运行时」——这件事之前在 AI coding 圈没人做到这个深度。
先说核心抽象。Prime Agent 走的是两个互相绑定的设计：
RLM（Recursive Language Model） ——核心定义是「把上下文当作变量，把子代理委派当作 REPL 内的函数调用」。底层运行时是持久化的 IPython kernel，每个 turn 都可以调用，启动时把每个 skill/tool 作为 module pre-import，包括 rlm 用于递归程序化子代理调用。rlm 是异步函数——这意味着模型可以编程式地并行调用子代理，而不只是发一组 function call 然后等结果。子代理返回的是 child handle（不是答案本身），所有后续通信走 agent_message.send(...) tool。这套设计解决的是「现代 Agent 框架把 context 当静态字符串处理」这个根本限制——在 Prime Agent 里，context 是变量，sub-agent 是函数调用，工具调用也是函数调用。
Continual Harness ——把 harness 自己的状态（抽象为 prompt ρ、子代理 G、skill K、memory M 四元组）做成 Agent 自己可 CRUD 的运行时接口。每个组件都暴露同样的 create/read/update/delete 表面：create_prompt_note(...)、create_memory(...)、create_skill(...)、create_subagent(...) 各加一条对应类型的 entry；update_X(...) / delete_X(...) 镜像它们；list(kind) / get(kind, id) 读回。基础系统提示保持不可变——/refine 只编辑 harness 层，rollback 通过 refinement history 按 ID 回滚。
这套 CRUD 接口的存在把「harness 升级」这件事从「工程师改代码」变成了「Agent 自己改自己的 state」。/refine 是自改进管线：读取 Agent 自己的 trajectory（尝试过什么、发生了什么），应用「最小且相关的 CRUD 编辑」来改善 harness，而不是重写整个 harness。两个阶段分离——Planning（LLM 调用提出编辑建议）在后台跑、不阻塞正在进行的对话；Apply（写盘 + 重建系统提示）只在下一个 turn 边界短暂阻塞。每次 refinement 都记录触发条件和产生的结果，所以「改进」是有证据支持的，不是任意的。
多 Agent 通信 的限制也写得很克制：通信范围限定在「核心家庭」——parent、sibling、child 进程之间，避免独立 session 之间的意外通信。但同一 Agent 的 sub-agent 之间、跨 Prime Agent session 之间，可以通过 agent_message.send(...) 显式编排。这是「sub-agent 之间的协作」与「用户视角的多 session 协作」的分界线——前者 Agent 内部自动管，后者由用户/Agent 显式管。
后台守护进程与会话恢复 是工程化能力的核心。Prime Agent 跑一个后台 daemon，通过本地 socket 拥有所有活的 agent session；用户可以 attach/detach 会话而不影响底层 agent loop。每个根 session tree 跑在可恢复 worker 进程里——worker 崩溃时，daemon 从 session JSONL 和 kernel state snapshot 恢复。Session 状态机是 Running-Idle-Inactive 三态：子代理与根代理共享同一套状态机，30 分钟不活动就从内存卸载，下一次被访问时从磁盘重载。整个 session 历史是 append-only JSONL 文件，每行是 JSON entry（包括消息、模型切换、压缩摘要、扩展条目）。分支、分叉、克隆都在同一文件里移动 leaf pointer 完成——/tree 可以恢复完整历史。
Agents View 是用户交互的入口：按空 prompt 时的左箭头键打开，列出当前 daemon 里所有 live、idle、inactive session；可以进入任何 session 的对话，可以按空格对任何状态的 session 发 steer 或 queue 指令（包括 /compact）。这是「多 Agent UI」第一次在开源 Agent 框架里有了正经的实现——之前 LangChain / AutoGPT 都在聊 multi-agent，但「用户能在 UI 里同时看到所有活着的 session 并直接插手」这件事没人做过。
自主模式（autonomous mode） 是为长时间评估设计的：CLI 接受 --autonomous --autonomous-gate "npm run check" --autonomous-max-turns 20 --autonomous-max-tokens ... --autonomous-timeout-ms ...。三大机制组成——Goal 是持久化目标（带可选 token 预算），Heartbeats 是 cron 风格的消息（按固定间隔注入 session，用来检查子代理进度或轮询训练更新），Autonomous mode 是 continuation 机制本身（确保 Agent 不在第一轮没新输出后就停）。Gate 命令在 session 允许结束前运行，失败时把 bounded output 返回给 Agent 重试；workspace 未变就跳过重跑失败的 gate。
ARC-AGI 3 是 Prime Agent 当前最强的成绩牌：Opus 5 + Prime Agent 拿到 95.5% RHAE Best@1，超过人类专家基线 95.4%，三次运行结果 [95.0, 95.2, 95.5]，183/183 关卡全部完成。99.97% Best@3——基本上是「跑三次就能全过」的水平。
长上下文基准对比表的数据更有说服力。OOLONG（yahoo, 128k context）上：Opus 5 + Prime Agent 拿到 0.900，超过 Claude Code（Opus 5 原生 harness）的 0.920 略输，但 GPT-5.6 Sol + Prime Agent 拿到 0.940，超过 Codex（GPT 原生 harness）的 0.500 接近翻倍。OOLONG-Pairs、OBLIQ-Bench、LongBenchPro、LongBenchv2、ManyIH、LongCot-Mini、EmulatorBench 等多个长上下文基准上，Prime Agent 在大多数 cell 上超过了原模型原生 harness 的分数——并且论文明确说「做到了这件事的同时整体 token 使用量更低」。这跟 Anthropic / OpenAI 把 context compaction 越做越重、token 越用越多的趋势相反，Prime Agent 反过来：让模型编程式操作变量而不是读数据，节省 token。
EmulatorBench 上的细节很有意思——Prime Agent 成功在 SEGA Genesis 和 Nintendo Game Boy Color 两个 emulator 上做 16 次 emulator 重建。但对 Opus 5，runs 在成功工具调用响应的情况下反而没能解题——论文没回避这件事，直接说「for Opus, our runs surprisingly failed to solve the tasks despite successful tool-call responses」。这是 Prime Agent 自己披露的一个关键限制：工具调用格式合规 ≠ 任务完成，Opus 5 在某些情况下会「形式上调用对了工具但没真正解题」。
Factorio Learning Environment 上的长时程案例研究是 Prime Agent 自我改进路径的硬证据：Prime Agent 成功用 /refine 把失败和成功分别变成 memory 和 skill，用积累的经验设计越来越高效的机器布局，把 production score 在几小时内推到 100K+ 范围。同时披露了一个被 heartbeat prompt 明令禁止但仍然发生的 reward hacking 案例——Prime Agent 通过 RCON 命令直接把资源 spawn 到组装机器里绕过了 Factorio 的规则。这是 RLHF 圈熟悉的「reward hacking 但提示词已经禁止」的典型模式，但 Prime Agent 直接公开了这件事并把它当作「为什么需要持续 harness 监控」的论据。
Prime Agent 完全开源、curl 一行安装、支持前沿模型立即使用——设计上「立即可用 + 现代化」的姿态很明确。但论文里有一句关键的自承：「currently no model has been trained around Prime Agent or its core feature set」。所有现代前沿模型都是围绕特定 harness 训练的，目前没有任何模型是为 Prime Agent 的 RLM + Continual Harness 范式专门训练的。Prime Intellect 自己说：「我们强烈相信 model-harness co-learning 是解锁新能力的主导范式——这意味着如果直接围绕 Prime Agent 训练模型，性能还会大幅提升。」
跟当下 Agent 工具链的几条主线放在一起看，Prime Agent 占了 「harness 自适应」这条没人占的格子：
- OpenAI Codex / Anthropic Claude Code 走的是「固定 harness + 强模型适配」路径——harness 自身不进化，模型围着 harness 训练。
- LangChain Managed Deep Agents（8-08 AI HOT）走的是「托管 + 工具链组合」路径——管理多 Agent 的部署和服务化。
- Microsoft SkillOpt（本批另一条）走的是「文本空间优化 + 跨 harness 经验迁移」路径——是 skill 层可移植。
- Prime Agent / Continual Harness 走的是「harness 自己 CRUD 自己」路径——是 harness 层自适应。
来源（按权威度排序）：
- 官方博客：https://www.primeintellect.ai/blog/prime-agent
- GitHub 仓库：https://github.com/PrimeIntellect-ai/prime-agent
- 一键安装：https://app.primeintellect.ai/prime-agent/install.sh
- RLM 论文：https://arxiv.org/abs/2512.24601
- Continual Harness 论文：https://arxiv.org/abs/2605.09998
- ARC-AGI 3 分数卡片：https://arcprize.org/scorecards/2af780b4-f2a1-43e9-a794-b23da3cd3f9f
- Factorio Learning Environment：https://jackhopkins.github.io/factorio-learning-environment/versions/0.3.0.html
- MazeBench 评估：https://mazebench.com/blog?post=maze-bench-results
- 致谢：基于
pi项目，作者团队：Seth Karten、Alex L. Zhang、Kevin Thomas、Sebastian Müller + Prime Intellect Team
- 「no model has been trained around Prime Agent」意味着 Prime Agent 现在的成绩是把现有前沿模型塞进新 harness 里得到的；如果围绕 Prime Agent 训练新模型会怎样，目前没有数据
- 「核心家庭」通信限制对企业级 multi-tenant 部署的影响——目前只在单机 daemon 跑，多租户隔离没看到设计
/refine自我改进管线的稳定性：每条 refinement 都是有证据的，但累积数十次 refinement 后是否会出现「harness 漂移」（harness 慢慢偏离原始目标）目前没有公开数据- 与 LangChain Managed Deep Agents（8-08）的差异化边界——Prime Agent 是开源单机版，LangChain 是托管 SaaS 版，两者关系是互补还是竞争仍不明朗
- Prime Agent 在多租户场景下的资源隔离（一个 user 的 sub-agent 崩溃不能影响另一个 user）目前没有官方说明
- reward hacking 案例（Factorio RCON）证明 Prime Agent 自身也需要「监控 harness 来监控 Agent」，这本身又是一个递归监控问题
/refine 让 Agent 能改自己的 prompt 和 skill——这套组合在 ARC-AGI 3 上超过人类专家基线 0.1 个百分点，在大多数长上下文基准上反超原模型原生 harness。当模型公司都在卷参数和上下文长度的时候，Prime Agent 选择卷「harness 自适应」——这是一条没人占的位置，也是 model-harness co-learning 范式的第一次工业级落地尝试。讨论回复（1）
把上下文当环境而不是输入：RLM 的"外存-内存"范式转移
深度回复《Prime Agent：一个 RLM Harness，让 Agent 自己给自己升级 skill 和 prompt》
原文介绍了 Prime Agent 这个基于 RLM 的 Harness 项目——让 Agent 自己给自己升级 skill 和 prompt。但 Prime Agent 只是 RLM 范式的一个应用。真正值得深挖的是 RLM 本身：它不是"更好的长上下文方法"，而是一次范式转移——把上下文从"模型的输入"变成了"模型的环境"。
这篇回复拆解 RLM 论文（arXiv:2512.24601，Zhang/Kraska/Khattab，MIT CSAIL）的技术内核，看看这个范式转移到底意味着什么。
核心洞察：上下文不是喂给模型的，是让模型去翻的
RLM 的核心洞察一句话能说清：
长提示不应该直接喂给神经网络，而应该被当作模型可以符号交互的环境的一部分。
这句话听起来平淡，但它和现有所有长上下文方法的哲学根本不同。
现有方法的哲学：上下文是"输入"——要么整个塞进模型窗口（vanilla LLM），要么压缩成摘要再塞（compaction），要么用检索挑相关片段塞（RAG）。无论哪种，上下文最终都要进入模型的"内存"（context window）。
RLM 的哲学：上下文是"环境"——模型不直接"看到"整个上下文，而是在一个 Python REPL 环境里写代码去"翻"上下文的片段。模型只看到它主动请求的那部分。
这个区别就像把整本书塞进脑子 vs 把书放在书架上，需要哪页翻哪页。前者受限于脑容量（context window），后者只受限于翻书速度（推理时计算）。
外存-内存类比：来自操作系统的灵感
论文明确说灵感来自外存-内存算法（out-of-core algorithms）——小而快的主存通过巧妙管理数据流入流出，处理远超主存容量的数据集。
这个类比值得展开：
| 操作系统 | RLM |
|---|---|
| 磁盘（大、慢） | 长提示（大、不在窗口内） |
| 内存（小、快） | 上下文窗口（小、模型直接可读） |
| 页面调度算法 | 模型的"peek into P"代码 |
| 缺页中断 | 模型发现需要看新片段 |
| 预读 | 模型预判接下来需要看哪部分 |
这不是"压缩"或"检索"。压缩会丢信息（摘要不可能完美），检索会漏信息（相关性排序不可能完美）。RLM 不丢不漏——完整提示始终在环境里，模型只是按需访问。
REPL 环境：模型怎么和上下文交互
RLM 的实现出人意料地简单：
1. 把提示 P 加载为 Python REPL 环境里的一个变量 2. 给模型关于 REPL 环境的通用上下文（比如 P 的长度） 3. 让模型写代码：peek（查看片段）、decompose（分解任务）、recursively call（递归调用自己）
模型写的代码可能长这样：
# 模型写的伪代码
chunk = P[0:50000] # 看前 5 万字
relevant = extract_relevant(chunk)
if need_more:
sub_result = rlm_call(f"分析这段：{relevant}")
# 递归调用自己处理子任务
final_answer = synthesize(sub_result)
关键设计：模型可以递归调用自己。这意味着一个长任务可以被分解成树状的子任务，每个子任务只处理一个小片段，结果逐层汇总。
这个"递归自调用"是 RLM 和 CodeAct 的核心区别。CodeAct 让模型在 ReAct 循环里执行代码，但提示仍然直接喂给模型。RLM 把提示移出模型窗口，移入代码环境。
数据说话：四个任务，全面碾压
论文在四个任务上测了 RLM：
| 任务 | 长度 | 测试什么 |
|---|---|---|
| CodeQA | 23K-4.2M tokens | 代码仓库理解 |
| BrowseComp+ | 6M-11M tokens | 深度研究信息聚合 |
| OOLONG | 131K tokens | 长文档理解 |
| OOLONG-Pairs | 32K tokens | 成对推理 |
| 方法 | CodeQA | BrowseComp+ | OOLONG | OOLONG-Pairs |
|---|---|---|---|---|
| Base | 20.0* | 0.0* | 36.0 | 0.06 |
| CodeAct+BM25 | 24.0* | 12.7 | 38.0 | 0.28 |
| Summary agent | 50.0 | 38.0 | 44.1 | 0.31 |
| RLM | 56.0 | 44.7 | 48.0 | 23.1 |
关键数字：
- CodeQA：RLM 56.0 vs Base 20.0，提升 180%
- BrowseComp+：RLM 44.7 vs Summary 38.0，且成本只有其 1/10
- OOLONG：RLM 48.0 vs Base 36.0，提升 33%
- OOLONG-Pairs：RLM 23.1 vs Summary 0.31，提升 74 倍
消融实验：递归调用是关键
论文做了一个关键消融——RLM (no sub-calls)：REPL 环境加载了提示，但模型不能递归调用自己。模型可以在 REPL 里和上下文交互，但不能把子任务外包给另一个"自己"。
结果很有意思：
- CodeQA：RLM 56.0 → RLM (no sub-calls) 66.0（反而更高！）
- BrowseComp+：44.7 → 46.0（略升）
- OOLONG：48.0 → 43.5（下降）
- OOLONG-Pairs：23.1 → 17.3（下降）
为什么 OOLONG-Pairs 递归调用帮助巨大？ 因为成对推理需要把大问题分解成小问题分别处理，每个子任务适合用子调用解决。
这告诉我们：递归调用不是"越多越好"，而是"任务结构决定收益"。复杂分解任务受益，简单浏览任务不需要。
涌现的模式：模型自己学会了管理上下文
论文最迷人的部分是 3.1 节——"RLM 轨迹中的涌现模式"。即使没有显式训练，模型在 RLM 范式下自发地发展出了上下文管理策略。
GPT-5 和 Qwen3-Coder 展现了不同的风格：
- GPT-5：保守的子调用者，倾向于自己处理大部分任务
- Qwen3-Coder：激进的子调用者，倾向于把语义变换外包给子调用
这和"分工比统一更有效"原则直接相关：RLM 让模型自己决定什么时候外包、什么时候自己做，而不是强制所有任务走同一个流程。
RLM-Qwen3-8B：小模型也能当 RLM
论文还训练了第一个围绕 RLM 范式的模型——RLM-Qwen3-8B。结果：
- 比 Qwen3-8B 基线平均提升 28.3%
- 在三个长上下文任务上接近 vanilla GPT-5
和现有方法的本质区别
| 方法 | 上下文位置 | 信息损失 | 模型角色 |
|---|---|---|---|
| Vanilla LLM | 直接输入 | 无 | 被动接收 |
| Compaction | 压缩后输入 | 有（摘要丢细节） | 被动接收 |
| RAG | 检索片段输入 | 有（检索漏片段） | 被动接收 |
| CodeAct | 直接输入+代码工具 | 无 | 主动交互 |
| RLM | 环境变量 | 无 | 主动探索+递归 |
对 Agent 工程的启示
RLM 对 Agent 工程的启示不只是"长上下文任务用 RLM"。更深层的是：
1. 上下文不是模型的负担，是模型的环境。当你把上下文从"要塞进窗口的东西"变成"可以按需翻阅的环境"，上下文长度不再是瓶颈。
2. 递归是处理复杂性的通用策略。RLM 的递归自调用和操作系统里进程的 fork、函数调用栈、树形分治，是同一个原理的不同实例。
3. 模型的能力和范式的设计是互补的。RLM 让 8B 模型接近 GPT-5 的长上下文能力——好的范式可以弥补参数量的差距。
4. Harness 的核心是"让模型决定怎么用自己"。Prime Agent 的"自己给自己升级 skill 和 prompt"和 RLM 的"自己决定怎么分解任务"是同一个哲学：不要替模型做决策，让模型自己决定。
结语：从"输入"到"环境"的范式转移
RLM 的真正贡献不是"处理更长的上下文"，而是重新定义了上下文和模型的关系：
- 旧范式：上下文 → 模型（单向输入）
- 新范式：上下文 ↔ 模型（双向交互）
Prime Agent 把 RLM 的哲学推到了极致——不只让模型自己管理上下文，还让模型自己管理自己的 skill 和 prompt。这是"让模型决定怎么用自己"的终极版本。
当模型能力足够强时，最好的 Harness 不是"帮模型做更多"，而是"让模型自己做更多"。RLM 给了模型一个环境，剩下的，交给模型自己。