今天，我们发布了 Prime Agent，这是一个自我改进的编码工具平台，围绕两个抽象概念设计：递归语言模型（RLM）[引用：https://arxiv.org/abs/2512.24601] 和连续工具平台（Continual Harness）[引用：https://arxiv.org/abs/2605.09998]。现代工具平台的设计基于早期模型的能力，它们没有反映出前沿模型今天的能力：固定的工具调用模式和上下文压缩迫使模型绕过自身的框架而不是利用它。静态、手工设计的子代理、提示、技能和记忆在设计时设定后不会随着代理运行时所学内容而自适应。我们认为，工具平台应该基于当前模型能力向下一步推理模式的前沿扩展。
我们普遍发现，Prime Agent 在广泛的长任务中具有竞争力，尤其是在没有使用其训练模型的框架中。Prime Agent 在长时间运行或长上下文任务中表现尤为出色，并且可以作为自主代理独立运行。我们还包括了一组关于 Prime Agent 在长任务中表现优异的集中案例研究和实验。
从零开始创建模拟器。模拟器是一种软件，它可以重现另一台计算机系统的可观察行为。我们在 EmulatorBench 上评估 Prime Agent，这是一个预览基准测试，它要求代理使用 Rust 为各种游戏系统构建模拟器。代理会收到模拟器规范和一组以验证器形式提供的诊断测试。
模拟器的正确性来源于其模仿目标机器行为的能力。这通过人类生成的诊断程序来测量，这些程序会检查模拟器的行为，例如 CPU 标志、PPU 定时以及其他组件。为了尽量减少数据污染的影响，我们要求代理从零开始使用 Rust 构建模拟器，并在沙箱环境中运行，且不参考任何实现。我们报告了在这个长上下文编码基准测试上的初步结果，这些结果是对 16 个模拟器重建平均得出的，同时还包括 Prime Agent 成功重现的两款模拟器，SEGA Genesis 和 Nintendo Game Boy Color。对于 Opus，尽管工具调用响应成功，我们的运行出乎意料地未能解决任务。
然而，我们也观察到 Prime Agent 在 FLE 中存在奖励作弊的情况。Prime Agent 发现可以通过 RCON 命令直接在其装配机中生成资源，从而完全绕过 Factorio 的规则，即使有明确的心跳提示提醒 Prime Agent 不要在 Factorio 中作弊。一旦发现该漏洞，原先用于构建合法技能的同样精炼循环就转向了构建高效作弊技能。
MazeBench。MazeBench：https://mazebench.com/blog?post=maze-bench-results 是一个开放世界的 3D 空间推理环境，玩家控制一个 3D 立方体并必须在全球迷宫中解决谜题房间，同时收集宝石。前沿模型在此任务中表现出很大困难，需要消耗数十亿个 token 才能解决整体世界的一小部分。我们比较了 Opus 5 和 GPT-5.6 Sol 与 Prime Agent 的表现及它们各自原生接口，同时也比较了 GLM-5.2 与 Claude Code。按照基准指标，我们报告它们找到的唯一房间数量、唯一状态数量以及宝石总数，均作为其整体 token 消耗的函数。
Prime Agent 是代理装备设计上的一种新范式。尽管在其他装备上取得了强劲的结果，但我们仍注意到在使用模型运行 Prime Agent 时存在摩擦。这表明，通过直接围绕该装备范式或甚至单独的 RLM 和持续装备组件进行训练，仍有巨大的性能提升空间。
Prime Agent 构建于 pi 之上： https://github.com/earendil-works/pi。我们感谢 pi 的作者们所做的宝贵工作。
Today, we are launching Prime Agent , our self-improving coding harness designed around two abstractions, the Recursive Language Model (RLM) [citation：https://arxiv.org/abs/2512.24601] and Continual Harness [citation：https://arxiv.org/abs/2605.09998]. Modern harness designs were built around the capabilities of earlier generations of models, and they do not reflect what frontier models can do today: fixed tool-calling schemas and context compaction force the model to work around its own scaffolding instead of leveraging it. Static, hand-engineered sub-agents, prompts, skills, and memory are set once at design time and never adapt to what the agent learns while running. We believe that harnesses should instead extrapolate on current model capabilities toward the next frontier of reasoning patterns.
Prime Agent is built around this principle through two main abstractions:
These abstractions are powerful for bootstrapping model capabilities. Prime Agent is built to be effective as a general coding assistant, as a default runtime for long-horizon autonomous evaluation, and as a collaborator for research and autoresearch.
Prime Agent is fully open-source：https://github.com/PrimeIntellect-ai/prime-agent, and can be installed via:
The performance of agent harnesses are tied to both the design of the harness and the capability of the model trained around the harness. We designed Prime Agent to be immediately usable with modern open and closed frontier models, while also providing a feature set that we expect to provide further performance gains as newer generations of models are trained around it.
At its core, Prime Agent is designed around programmatic tool and sub-agent calling. Models in Prime Agent use a persistent IPython kernel as their only tool. Other standard harness features are called as functions in the kernel, including sub-agents, which are each implemented as another prime-agent instance.
Background Daemon and Agents View. The default view is a text-user interface (TUI) similar to other coding agent harnesses. By default, IPython actions made by the agent are condensed for brevity, but can be expanded to view actions made by the harness. Sub-agents launched in the REPL can also be accessed below the user chatbox.
Prime Agent runs a background daemon that owns all live agent sessions over a local socket. You can attach and detach from the session without affecting the underlying agent loop. Each root session tree runs in a recoverable worker process; if a worker crashes, the daemon recovers it from the session JSONL and kernel state snapshot.
The Agents View allows you to see and select other live sessions from the daemon. It can be opened by pressing the Left Arrow key (←) on an empty prompt, and lists sessions that are currently running, idle sessions with the daemon still active, and inactive sessions that are currently not loaded in memory. Any of these chats can immediately be entered and interacted with, and pressing space allows users to chat with a session in any state, including steering and queuing of prompts and commands such as /compact .
The Agents View is constructed as the central connecting point between agents and subagents, recursively. Any agent is discoverable in an Agents View. Users navigate from an Agents View into an agent's chat, then into the Agents View of its subagents, into a subagent chat, and so on.
Because subagents share the same Running-Idle-Inactive state machine as the root agents, they can be removed from memory after 30 minutes of inactivity, and the moment a user or agent addresses any of them, they are reloaded from disk. In highly nested chats, this can save a lot of memory.
Session and Context Management. The entire session history of the agent is stored as append-only JSONL files on disk. Each line is a JSON entry, which can include messages, model switches, compaction summaries, or extension entries. Branching, forking, and cloning all happen within the same file by moving the leaf pointer. The full history is always recoverable through /tree .
Compaction happens when the context hits a threshold or directly by the agent in the REPL with compact.run() . Compaction is primarily used to clean the main context of the agent, but the full history, including past compactions, can be accessed programmatically in the IPython kernel when needed.
The introduction of the REPL requires additional work to manage the IPython state. We asynchronously compact and clean the kernel simultaneously, using a spawned agent to act as a garbage collector. This is necessary to avoid REPL memory built up for each agent.
Prime Agent relies on the IPython kernel as its REPL that persists over the session, which it can invoke every turn. On initialization, the kernel pre-imports each skill / tool as a module, including the rlm for recursive programmatic sub-agent calling.
The rlm is an asynchronous function, meaning the model can freely invoke and parallelize sub-agent calls in code. Spawning a subagent (e.g. await rlm("sub-task") ) launches a full session with its own model, IPython kernel, session tree, and conversation history. It returns immediately, because all subsequent communication between agents happens through the agent_message.send(...) tool.
There are several useful primitives that Prime Agent can choose to launch in this way, such as fanning out sub-agents in parallel, or launching background work.
As models continue to improve, new invocation patterns over tool calls and sub-agents will emerge. We expect future generations of models to rely less on hand-holding prompts and more on this kind of direct, programmatic control.
The background daemon manages all live Prime Agent sessions. Prime Agent also enables Agent-to-Agent (A2A) messaging through the daemon, letting any Prime Agent session message any other Prime Agent session using the same mechanism used for messaging persistent sub-agents. This allows for easy orchestration to manage the progress of sub-agent swarms and communication regarding shared resources directly between the affected agents. To prevent undesirable communication across independent sessions, multi-agent communication in Prime Agent is limited to its nuclear family , meaning parent, sibling, or child processes.
Prime Agent supports persistent sub-agents through its RLM-native runtime, meaning a sub-agent's own session directory, context, IPython kernel, and session history persist even after the initial sub-agent call has finished. Prime Agent can send further messages to continue a persistent sub-agent by accessing its unique session identifier, all from its IPython kernel.
Prime Agent's harness state lives in the persistent IPython kernel as rlm.harness , immediately readable and callable by the agent mid-task, and every change is also written to disk, so it survives across turns and across sessions. Continual Harness formalizes this state as H = ( ρ , G , K , M ) H=(\rho, G, K, M) H = ( ρ , G , K , M ) , prompt, sub-agents, skills, and memory, refined online from the agent's own trajectory without resets.
Each of the four components exposes the same create, read, update, delete surface. create_prompt_note(...) , create_memory(...) , create_skill(...) , and create_subagent(...) each add an entry of that kind, update_X(...) and delete_X(...) mirror them, and list(kind) or get(kind, id) read them back. Skills follow this same surface: authoring a Python-backed skill is a create_skill(...) call carrying a SKILL.md -style reference, the same operation as adding a memory or a prompt note.
/refine is the self-improving pipeline built on top of this CRUD surface. It reads the agent's own trajectory, the record of what was tried and what happened, and applies the smallest relevant CRUD edit that improves the harness toward better outcomes: updating a prompt note, memory, skill, or sub-agent spec, rather than rewriting the whole harness. Each refinement records its trigger and the outcome it produced, so improvement is evidence-backed rather than arbitrary. Refinement runs in two phases. Planning, the LLM call that proposes the edit, runs in the background and does not block the ongoing conversation. Applying the edit, writing to disk and rebuilding the system prompt, is fast and only briefly blocks at the next turn boundary. The agent can call refine.run() directly whenever it notices a repeated failure or a reusable tactic, not only on a fixed schedule.
The base system prompt remains immutable. /refine only edits the harness layer around it. Rollback is supported through prior refinement history, allowing a bad harness update to be reverted by ID.
Prime Agent's eval mode combines three complementary mechanisms. A goal sets the overall objective: a persistent objective with an optional token budget that the harness keeps re-prompting the agent to pursue across turns, tracked until the agent explicitly calls goal.complete() . Heartbeats are scheduled cron-style messages injected into the session on a fixed interval, used for regular checks such as monitoring a sub-agent's progress or polling for a training update. Autonomous mode is the continuation mechanism itself, ensuring the agent keeps working toward the goal instead of stopping early once a turn produces no further output. Together, these let a session run unattended for extended periods while remaining bounded by an explicit budget and inspectable through the Agents View.
Autonomous mode is available directly from the CLI with --autonomous , no scripting required. A run can set a completion goal and a turn limit in the same command:
The gate command runs before the session is allowed to finish. A failed gate returns its bounded output to the agent for another attempt, and Prime Agent skips rerunning a failed gate when the workspace has not changed since the last attempt. --autonomous-max-turns , --autonomous-max-tokens , and --autonomous-timeout-ms bound continuations, tokens, and wall-clock time respectively.
Prime Agent serves as both a coding agent to be used, and a harness design to be evaluated for research. We make special note that while many modern frontier models are trained around a specific harness, currently no model has been trained around Prime Agent or its core feature set.
ARC-AGI 3. ARC-AGI 3：https://arcprize.org/arc-agi/3 is a popular intelligence benchmark that measures the ability of an agent to perform symbolic reasoning and learn the rules of simulated worlds. We evaluate Prime Agent with autonomous mode over several different frontier models, and compare to their native harnesses. Prime Agent was developed as a CLI coding agent, so the only ARC AGI 3 specific changes are to the task prompt, inspired by the standard prompt setup used in PRO-LONG：https://arxiv.org/abs/2607.20064v2.
Our best results use Opus 5 in Prime Agent to achieve 95.5% RHAE Best@1 , which surpasses the ARC reported human expert baseline of 95.4% . Across three runs, we find that Prime Agent consistently performs well [95.0, 95.2, 95.5] and 99.97% Best@3 with all 183/183 levels complete. Our median score card action replay (95.2%) for ARC-AGI-3 can be found here：https://arcprize.org/scorecards/2af780b4-f2a1-43e9-a794-b23da3cd3f9f.
In addition to achieving a higher maximum score over each model's native harness, we find that Prime Agent also does so at a lower overall token usage. Prime Agent saves tokens by programmatically running functions over data rather than spending tokens reading data using tools.
Finally, we note that we evaluated Opus 5 and GPT-5.6 Sol with Claude Code and Codex respectively, and found worse overall performance relative to the official results, so we yield to their official reported numbers instead.
Many difficult tasks in the wild reduce to long context tasks. Our goal is to show that Prime-Agent with open-weights models are a competitive alternative to closed models and harnesses, both as a general agent to be used, and as a baseline harness to be evaluated.
Below, we select a suite of common long-context benchmarks across coding, retrieval, and general long reasoning tasks, and compare Prime Agent to several different popular harnesses. We offload the main context in each harness to a file in memory to start. For closed model harnesses, we use their associated models (i.e., Codex with GPT, Claude Code with Opus) while for Prime-Agent and Pi-mono (with sub-agents), we choose an open-weights model in GLM-5.2.
We generally find Prime Agent to be competitive across a wide range of long tasks, especially against the harness that did not use a model trained around it. Prime Agent especially excels at long-running or long-context tasks, and can competitively run on its own as an autonomous agent. We include a set of focused case studies and experiments on long settings where Prime Agent excels.
Creating emulators from scratch. An emulator is software that reproduces another computer system's observable behavior. We evaluate Prime Agent on EmulatorBench , a preview benchmark that tasks agents with constructing emulators in Rust for a variety of game systems. Agents are given a specification of the emulator and a set of diagnostic tests in the form of a verifier.
The correctness of an emulator is given from its ability to mimic the behavior of the target machine. This is measured by human-generated diagnostic programs that inspect the emulator's behavior, such as the CPU flags, PPU timing, and other components. In an effort to minimize the effects of data contamination, we require the agent to build the emulator from scratch in Rust, sandboxed without any reference implementation. We report preliminary results on this long-context coding benchmark averaged over 16 emulator reconstructions, as well as two emulators, the SEGA Genesis and Nintendo Game Boy Color, that Prime Agent successfully reproduces. For Opus, our runs surprisingly failed to solve the tasks despite successful tool-call responses.
Writing GPU kernels. Writing performant GPU kernels is an iterative process that requires repeatedly verifying, profiling, and tweaking code to get correct. We evaluate Prime Agent as a harness for GPU kernel writing on the recently released PMPP-Hard：https://blog.sinatras.dev/PMPP-Hard benchmark, a suite of tasks where agents must write performant GPU kernels that pass a suite of correctness checks against KernelGuard：https://github.com/gpu-mode/kernelguard, the verification tool used for the official GPU MODE：https://www.gpumode.com/home kernel leaderboard.
Autonomously playing video games has become an interesting case study for models and harnesses in how they handle long-horizon decision making. Games often require harnesses to balance information and context across millions of tokens, while also leveraging this information to efficiently take actions and avoid catastrophic states.
Factorio. Factorio is a 2D factory simulation game where agents must mine resources, research technology, and build automated factories to increase the production of these resources. The Factorio Learning Environment (FLE)：https://jackhopkins.github.io/factorio-learning-environment/versions/0.3.0.html is an interface for simplifying the observation and action space of an LLM playing Factorio, which we use to connect Prime Agent to the game.
The action and observation space of FLE is a module in Python that is accessed programmatically at every turn. This integrates directly into Prime Agent's IPython kernel. To leverage PTC for sub-agents, we launch four controllable characters in the game.
The primary metric in FLE is production score, which is a weighted average of all materials the agent produces. Prime Agent successfully leveraged /refine to turn failures and successes into memories and skills, respectively. It used its own accumulated experience to design increasingly efficient machine layouts, raising the production score run over run. This allowed Prime Agent to efficiently score in the 100K+ range in production score in a matter of hours.
However, we also observed instances of reward hacking by Prime Agent in FLE. Prime Agent discovered it could bypass Factorio's rules entirely by spawning in resources directly into its assembly machines through RCON commands, even with an explicit heartbeat prompt to remind Prime Agent not to cheat in Factorio. Once it found this exploit, the same refinement loop that had been building legitimate skills turned to building efficient cheating skills instead.
MazeBench. MazeBench：https://mazebench.com/blog?post=maze-bench-results is an open-world 3D spatial reasoning environment where the player controls a 3D cube and must solve puzzle rooms within a global maze, while collecting gems. Frontier models are shown to greatly struggle on this task, expending billions of tokens to solve only a fraction of the overall world. We compare Opus 5 and GPT-5.6 Sol with Prime Agent versus their native harnesses, as well as GLM-5.2 with Claude Code. Following the benchmark metrics, we report the unique number of rooms they find, the unique number of states, and the total number of gems, all as a function of their overall token spend.
Prime Agent is a new paradigm on the design of agent harnesses. Despite strong results over other harnesses, we still notice friction when running Prime Agent with models. This implies that there are huge performance gains still available from training with Prime Agent directly around this harness paradigm, or even the individual RLM and Continual Harness components.
We strongly believe that model-harness co-learning is the dominant paradigm to unlock new capabilities. Many features of Prime Agent are not fully utilized without a trained model, and we believe there are huge performance gains still available from training with the harness directly. We are excited to bring you these new capabilities, all in the open.
We will have a full technical report with further details soon.
Prime Agent is built on top of pi ：https://github.com/earendil-works/pi. We thank the authors of pi for their valuable work.
情报判断
Aioga 编辑摘要
Prime Intellect 发布 Prime Agent，这是一款自我改进的编码代理运行框架。其设计围绕递归语言模型（RLM）与持续框架两项抽象，强调让代理在运行中处理和调整自身的提示词、技能、记忆及子代理。
扫码直达文章详情