用 Rust 重写 Prime Agent

自我们在 8 月发布 Prime Agent [1] 以来，它已被下载超过 30 万次，并处理了超过 8 万亿个 token。今天，我们很高兴发布一个更快、更简洁、更可靠的 Prime Agent：它从底层起采用 Rust 重写。

在两周时间里，Prime Agent 编排了由超过 2,000 个 Agent 组成的集群，对自身进行了端到端重写。这些 Agent 运行在超过 10,000 个 Prime Sandbox 中，并通过 Prime Inference 的 GLM-5.3 端点处理了超过 2,000 亿个 token。此次 Rust 重写对 Prime Agent 的多 Agent 能力进行了压力测试，包括我们为大规模 Agent 集群、自主研究和强化学习构建的 Sandbox 与推理基础设施。

为确保与 TypeScript 版本实现功能对等，Prime Agent 调度子 Agent 对依赖关系进行拓扑排序，并使用有限状态机来组织循环计算与正确性检查。与此同时，我们重写了代码架构，以便于维护和开发。随后，我们使用运行时基准测试及真实的 Prime Agent 轨迹，对性能指标进行爬山优化并排查 Bug。现在，Prime Agent 的运行速度更快，资源消耗也低于大多数编程 Agent harness。

子 Agent 深度

父级	深度 1	深度 2	深度 3
Rust 实现	192.99B token1,981 个 Agent
性能爬山	35.70B token228 个 Agent

2025 年 10 月 1 日 15:59：2,209 个 Agent · 16,758 条 Agent 间消息 · 228.70B token 总计

为什么选择 Rust

TypeScript 帮助我们迅速发布了 Prime Agent，但它的类型是可选的，并且会在运行时消失；错误会以未经检查的异常形式传播；渲染和解析大型会话等 CPU 密集型工作会在单一事件循环中与键盘输入竞争；而每个进程都需要承担 JavaScript 运行时和垃圾回收器的开销。我们希望在保持当前发布速度的同时，随着代码规模扩大而以更高的标准约束代码，而 Rust 非常适合这一需求：

• **性能：**Prime Agent 是一个长期运行的守护进程，每个会话对应一个工作进程。没有垃圾回收器的原生代码，是我们获得大部分内存和启动性能提升的原因。
• **并发：**一个守护进程同时流式传输模型输出、执行工具调用、在 Agent 之间中继消息，并为所有已连接客户端提供服务。Rust 的 Send 和 Sync trait 让编译器能够检查哪些数据可以在线程间移动、哪些数据可以在线程间共享。
• **编译期保证：**穷尽式枚举、所有权和生命周期能够在代码运行前排除整类 Bug；Clippy 的严格 lint 还能增加数百项检查。当大部分代码由 Agent 编写时，这一点尤为重要。

除了这些明确的性能提升外，这次重写也让我们有机会重新思考设计选择。我们大幅提升了代码库的模块化程度，并从此次重写中获得了收益，包括 Windows 支持、会话崩溃隔离，以及更一致的守护进程协议。

Prime Agent 如何重写自身

我们的目标是让 Agent 尽可能自主地完成重写，并尽量减少人工干预。因此，人类所需完成的工作是建立合适的验证机制，以支持大规模自主部署。我们采用了与此前自动 Rust 翻译工作 [2] 类似的设置。每份规范覆盖一种不同类型的对等性：

• **TUI 对等性：**一套差分测试会将 TypeScript 与 Rust 二进制程序针对同一个脚本化模型并排比较，并对两者渲染的终端帧进行差异比对。它覆盖启动、斜杠菜单、工具调用、压缩、Agent 视图、会话恢复、子 Agent 和崩溃恢复等用户流程。
• **Harness 对等性：**对同一运行结果进行会话转录比对，并比较各二进制程序发送至模型提供方的请求，从而确保二者能够基于相同输入生成相同会话。
• **协议对等性：**针对守护进程协议中的全部消息类型，与 TypeScript 实现进行检查，以确保我们的 ACP 和守护进程协议 API 保持一致。
• **功能对等性：**由于脚本化流程无法覆盖整个界面，Agent 会逐组件审查 TypeScript 产品，并将每个组件分类为已匹配、部分匹配或缺失。

通过为每一种对等性提供客观检查，Agent 可以自行衡量进展，并在变更合并前捕获回归问题，这让我们得以减少人工审查。其余 Bug 与行为差异主要通过内部使用发现，并据此指导我们后续完善缺失功能、可靠性和界面细节。

我们在两台按需提供的 8 核 CPU 节点上运行所有编排器及其 Agent，每台节点可支持超过 100 个并发子 Agent 及其对应的 CPython 内核。此外，当数十个 Agent 同时运行时，编译、类型检查和差异比对会使任何单机达到饱和。因此，我们构建了一套工具，让 Agent 可以将繁重工作外包给 Prime Sandbox，从而对迁移工作进行高度并行化处理。

一个客观的 TUI 对等性验证器会比较 TypeScript 和 Rust 版本的终端帧，并高亮显示差异。

有限状态机的编排

一个根 Agent 编排整个重写过程，并将工作拆分为按拓扑顺序排列的任务。根 Agent 不编写任何产品代码，因此可以专注于监控每项任务、合并已完成工作，并在与我们共同处理优先级和决策时维持对整个重写项目的全局视图。我们还将代码生成与验证分配给不同的 Agent，因为编写代码的 Agent 在评估自身工作时会存在偏见。因此，编排器分配的每项任务都会经过四个 Agent：

• **规划者（Planner）：**创建整体状态机规范，包括功能设计、作为真实基准的 TypeScript 行为，以及验证器（对等性检查）。
• **实现者（Implementer）：**在专用 worktree 中编写 Rust 代码，以便多个功能可以并行开发。
• **审查者（Reviewer）：**以对抗性方式检查 Pull Request；它使用与实现者不同的模型，并处于独立上下文中，专门寻找变更不正确的证据。
• **验证者（Verifier）：**在全新的 Prime Sandbox 中编译并运行该功能的对等性检查与测试。

审查或验证失败时，功能会连同发现的问题一起返回给实现者；两者均通过后，PR 才会合并。我们正在将这种模式构建进 Prime Agent，用于编排由有限状态机构成的工厂，使这类工作流能够被一次定义、重复使用和持续更新。

架构重新设计

迁移至 Rust 也让我们有机会重构代码库。这正是长期收益的重要来源：

• **模块化：**代码被拆分为九个 crate，并通过 Cargo 强制执行单向依赖图。TUI 唯一的内部依赖是共享类型 crate。最大的源文件现约为 2,500 行，低于 TypeScript 版本的约 15,000 行；目前没有超过 5,000 行的文件，而 TypeScript 版本有四个这样的文件。
• **隔离：**每个会话都作为独立工作进程运行在一个小型 supervisor 之下，因此一个会话的失败不会影响其他会话。会话会持久化到磁盘，因此客户端可在重启后重新连接。
• **平台抽象：**传输、进程控制和文件锁定均位于平台特定接口之后，因此诸如 Windows 支持之类的能力，只需实现这些 trait，而无需重新改造守护进程。
• **单一协议定义：**客户端、守护进程和所有工作进程都针对共享类型 crate 中的相同消息类型进行编译，因此协议的变更会在所有使用该协议的位置受到检查。
• **目录驱动的模型：**我们将模型和 MCP 列表迁移至一个在运行时获取的独立目录，因此无需发布新的 Prime Agent 版本即可交付新模型和插件。

完善工作

虽然自主工作流的推进程度超出我们的预期，但对等性检查只能验证其实际覆盖到的行为。在主 RLM 循环实现对等后，我们将所有重写 Agent 都迁移到 Rust 上运行，从而能够大规模内部试用 Rust 版本（此时 Prime Agent Rust 已开始递归地改进自身！）。之后，我们将内部团队也迁移至 Rust 构建版本用于日常工作，这暴露了差分测试覆盖范围之外的 Bug 和缺失行为。在整个内部试用周期中，我们让 Agent 审查所有 Beta 用户的日志和轨迹，使其能够自动诊断并解决用户发现的运行时及 Agent 问题。我们还借此次重写机会重新设计了部分 UX/TUI 流程和面向模型的 API。

要将重写成果提升至发布质量，接下来的数周中仍需完成后续工作，包括完成特性迁移、修复 Bug、提升性能和打磨界面。Prime Agent 仍负责编写和测试这些变更，而人类则参与发现问题、指导变更，并审查所有结果。

性能爬山优化

在实现功能对等后，我们希望优化 Prime Agent 在所有用户流程中的运行时性能。我们采用了与重写相同的方法：为 Agent 提供一种可客观衡量自身进展的方式。我们构建了一个衡量 Prime Agent 多项运行时指标的基准测试 harness，并让 Prime Agent 通过经过充分论证的改进，对其速度和资源使用进行爬山优化。

性能基准测试会在每项测试专用的、全新 4 核 8 GB Prime Sandbox 中，对 Rust 和 TypeScript 版本的 Prime Agent，以及其他 Agent harness 进行评估。该测试包含噪声检查机制，任何过于不稳定、无法比较的结果都会被剔除。Agent 在由屏幕模拟器驱动的真实终端中，针对脚本化模型运行，因此计时结果反映用户实际体验，并排除了推理时间。

在该 harness 建立后，第二个编排器以单一目标运行了三天爬山循环：在不破坏对等性的前提下改善基准测试结果。每次实验均遵循以下流程：

1. Agent 对基准测试进行性能分析，以定位时间和内存消耗位置，将成本最高的项目转化为假设待办事项，再由编排器分配给工作 Agent。
2. 工作 Agent 在同一 Sandbox 上构建当前代码和候选变更，并以交替顺序运行它们，同时运行相邻基准测试以发现其他部分的性能回归。
3. 两个审查 Agent 分别使用不同的前沿模型，检查行为是否仍与 TypeScript 匹配、变更所声称保持一致的输出是否仍字节级相同，以及面向模型的接口是否出现回归。
4. 变更合并，下一次实验以新的基线进行测量。

我们刻意没有为这一循环设定数值目标，因为固定阈值往往会变成停止点。只要仍存在可测量的收益，Agent 唯一的目标就是持续改善基准测试，同时不破坏对等性。在整个爬山周期中，该循环记录了超过 144 份实验和审计记录，并合并了超过 69 项有效变更，从而提升性能。以下是我们在重要领域观察到的一些显著改进：

指标	TypeScript 版本	爬山前的 Rust	爬山后的 Rust
冷启动	输入就绪延迟		快 14.18 倍
热启动	输入就绪延迟		快 13.34 倍
大型会话内存	进程树 RSS · 10 MiB 会话		缩小 4.76 倍
安装体积	完整安装		缩小 2.89 倍
Agent 视图	视图切换延迟		快 6.09 倍

大部分提升来自三类变更：将工作从启动和渲染路径中移出、用事件驱动的等待替代轮询循环，以及在大型会话加载完成后尽快释放内存。

结果

总体而言，我们的 Rust 重写和后续性能爬山优化，让 Prime Agent 的速度大幅提升、资源效率显著改善。相较 TypeScript，达到可输入状态的时间约快 14 倍，启动后内存占用减少超过 80%；Prime Agent 已跻身最快的编程 Agent harness 之列。

	Prime Agent（Rust）	Prime Agent（TypeScript）	Claude Code v2.1.289	Codex CLI v0.160.0	Pi v1.0.3	Hermes Agent v0.21.5
首次绘制从启动到首次可见输出	23.6 ms ± 0.6快 30.63 倍	722.8 ms ± 15.1	264.6 ms ± 5.8	296.8 ms ± 2.7	306.3 ms ± 6.7	1,715.3 ms ± 10.3
可输入时间（冷启动）从全新启动到可输入	55.8 ms ± 4.9快 13.22 倍	737.8 ms ± 13.9	348.4 ms ± 8.2	324.6 ms ± 4.9	317.7 ms ± 8.0	2,094.5 ms ± 23.5
可输入时间（热启动）重复启动到可输入	42.4 ms ± 4.3快 12.96 倍	549.6 ms ± 10.0	345.1 ms ± 6.2	321.3 ms ± 9.2	240.4 ms ± 5.9	2,097.1 ms ± 40.8
安装体积安装占用的磁盘空间	59.6 MB ± 0.0缩小 2.89 倍	172.1 MB ± 0.0	492.4 MB ± 0.0	446.8 MB ± 0.0	456.0 MB ± 0.0	960.1 MB ± 0.0
内存（RSS）启动后整个进程树	106.0 MB ± 1.3缩小 5.73 倍	607.4 MB ± 0.9	226.9 MB ± 0.4	344.4 MB ± 3.1	138.1 MB ± 0.7	194.6 MB ± 0.3

这一更具模块化的代码库及更强的编译期检查，也将帮助我们更快地交付新能力，并在错误影响用户之前发现更多问题。

下一步计划

随着 Rust 迁移完成，我们正将同样的细致关注投入 Prime Agent 的每个环节：从日常系统交互到跨多个 Agent 的复杂工作。基础设施改进已经完成，我们正在加速推进能力建设和评估工作，并将这次重写背后的多 Agent 工作流提供给你。

Prime Agent 还将更紧密地融入 Prime Intellect 生态系统，使你能够通过云端 Agent 集群、推理、轨迹、Sandbox、评估、托管训练等能力，跨越整个技术栈开展工作。

随着这次重写，我们还发布了具备原生 Windows 支持的 Prime Agent（Beta），并支持通过 homebrew 安装。Prime Agent 仍然是开源项目，并可通过一条命令安装：

Rewriting Prime Agent in Rust

Since we launched Prime Agent [1] in August, it has been downloaded more than 300,000 times and has processed over 8 trillion tokens. Today, we're excited to ship a faster, cleaner and more reliable Prime Agent, rewritten from the ground up in Rust.

Over two weeks, Prime Agent orchestrated a swarm of over 2,000 agents to rewrite itself end to end, operating across 10,000+ Prime Sandboxes with over 200 billion tokens from Prime Inference’s GLM-5.3 endpoint. The Rust rewrite stress-tested Prime Agent’s multi-agent capabilities, including the sandbox and inference infrastructure we’ve been building to power large-scale agent swarms, autonomous research, and reinforcement learning.

To ensure feature parity with the TypeScript version, Prime Agent orchestrated subagents to topologically sort dependencies, with finite state machines structuring looped computations and correctness checks. In parallel, we rewrote the code architecture for easier maintenance and development. We then used runtime benchmarks and real Prime Agent traces to hillclimb performance metrics and triage bugs. Now, Prime Agent runs faster and uses fewer resources than most coding agent harnesses.

Subagent depth

ParentDepth 1Depth 2Depth 3

Rust Implementation

192.99B tokens
1,981 agents

Performance Hillclimb

35.70B tokens
228 agents

Oct 01, 15:592,209 agents · 16,758 agent-to-agent messages · 228.70B total tokens

Why Rust

TypeScript helped us ship Prime Agent quickly, but its types are optional and disappear at runtime, errors travel as unchecked exceptions, CPU-heavy work like rendering and parsing large sessions competes with keyboard input on a single event loop, and every process pays for a JavaScript runtime and garbage collector. We want to keep shipping as fast as we do, while holding the code to a higher standard as it grows, and Rust suits that well:

• Performance: Prime Agent is a long-running daemon with a worker process per session, and native code without a garbage collector accounts for most of the memory and startup gains we’ve made.
• Concurrency: one daemon streams model output, runs tool calls, relays messages between agents and serves every attached client at once. Rust's Send and Sync traits let the compiler check which data can move between threads and which can be shared.
• Compile-time guarantees: exhaustive enums, ownership and lifetimes rule out whole classes of bugs before the code runs, and Clippy's pedantic lints add hundreds more checks, which matters when agents write most of the code.

In addition to these clear performance gains, the rewrite gives us the opportunity to rethink our design choices. We have significantly modularized our codebase, and are reaping the rewards of this rewrite, including Windows support, session crash isolation, and a more consistent daemon protocol.

How Prime Agent rewrote itself

Our goal was for agents to perform the rewrite autonomously with as little human intervention as possible. Thus, the human work required was to setup proper verification to enable autonomous deployment at scale. We followed similar setup to previous work on automatic Rust translation [2]. Each specification covered a different kind of parity:

• TUI parity: a differential test suite compares the TypeScript and Rust binaries side by side against the same scripted model and diffs the terminal frames each one renders. It covers user flows, including launch, slash menus, tool calls, compaction, agents view, session resume, subagents and crash recovery.
• Harness parity: the same run diffd session transcripts and the requests each binary sends to the model provider, so both produce the same sessions from the same inputs.
• Protocol parity: all message types in the daemon protocol are checked against the TypeScript implementation, ensuring our ACP and daemon protocol APIs are consistent.
• Feature parity: since scripted flows cannot cover an entire interface, agents audited the TypeScript product component by component, classifying each as matching, partial or missing.

With an objective check for every kind of parity, the agents could measure their own progress and catch regressions before changes merged, which let us cut back on human review. Remaining bugs and behavior differences were largely found through internal use, which guided our follow-up work on missing features, reliability and interface polish.

We ran all orchestrators and their agents on two 8-core on-demand CPU nodes, each supporting over 100 concurrent subagents and their respective CPython kernels. Additionally, since compilation, type-checking and diffing would saturate any single machine when dozens of agents are running at once, we built out utilities for our agents to outsource heavy work to Prime Sandboxes, allowing us to heavily parallelize our port.

An objective TUI parity verifier compares terminal frames from the TypeScript and Rust versions and highlights differences.

Orchestration of Finite State Machines

A single root agent orchestrated the rewrite and divided the work into a topological ordering of tasks. The root agent wrote no product code, keeping it free to monitor every task, merge finished work, and maintain an overview of the rewrite while working with us on priorities and decisions. We also kept generation and verification in separate agents, since an agent that writes code is biased when evaluating it. Therefore, each task assigned by the orchestrator moved through four agents:

• Planner: creates overall machine specification, including the feature design, ground-truth TypeScript behavior, and verifier (parity check)
• Implementer: writes the Rust code in a dedicated worktree so features can develop in parallel.
• Reviewer: inspects the pull request adversarially, using a different model and in a separate context from the implementer, looking for reasons the change is wrong.
• Verifier: compiles and runs the feature's parity checks and tests in a fresh Prime Sandbox.

A failed review or verification sends the feature back to the implementer with the findings, and the PR merges once both pass. We are building this pattern into Prime Agent to orchestrate a factory of finite state machines, so workflows like this one can be defined once, reused, and updated.

Architecture re-design

Porting to Rust also gave us a chance to restructure the codebase. This is where much of the long-term benefit comes from:

• Modularity: the code is split into nine crates with a one-way dependency graph that Cargo enforces, and the TUI’s only internal dependency is the shared types crate. The largest source file is now ~2,500 lines, down from ~15,000 in TypeScript, with no files over 5,000 lines compared with four in TypeScript.
• Isolation: each session runs in its own worker process under a small supervisor, so a failure in one session leaves the others running, and sessions persist on disk so clients can reattach after a restart.
• Platform abstraction: transport, process control and file locking sit behind platform-specific interfaces, so something like Windows support came down to implementing those traits rather than rewiring the daemon.
• One protocol definition: the client, the daemon and every worker compile against the same message types in the shared types crate, so a change to the protocol is checked everywhere it is used.
• Catalog-driven models: ported our model and MCP lists to a separate catalog fetched at runtime, allowing us to ship new models and plugins without a Prime Agent release.

Refining the work

While the autonomous workflow went further than we expected, the parity checks only verified the behavior they exercised. Once parity on the main RLM loop was achieved, we moved all our rewrite agents onto Rust, allowing us to dogfood the Rust version at scale (and now Prime Agent Rust was recursively improving itself!). Later, we moved our internal team onto the Rust build for daily use, which exposed bugs and missing behavior outside the coverage of the differential tests. Throughout our dogfood cycles, we had agents review logs and traces from all beta users, allowing us to automatically diagnose and resolve runtime and agent issues identified by users. We also took the rewrite as an opportunity to redesign some of the UX/TUI flows and model-facing API.

Bringing the rewrite to release quality took follow-up work over the following weeks, from finishing feature ports and fixing bugs to improving performance and polishing the interface. Prime Agent still wrote and tested these changes, while we had humans in the loop involved in finding problems, directing the changes, and reviewing all results.

Hillclimbing performance

With feature parity achieved, we wanted to optimize Prime Agent runtime performance across all user flows. We approached it the same way as the rewrite: by giving the agents an objective way to measure their own progress. We built a benchmark harness that measures Prime Agent performance across a variety of runtime metrics, and let Prime Agent hillclimb its speed and resource usage with well-deliberated improvements.

The performance benchmark evaluates Prime Agent in Rust and TypeScript, as well as other agent harnesses, on a fresh 4-core, 8 GB Prime Sandbox per benchmark, with noise checks that withhold any result too unstable to compare. Agents run in a real terminal driven through a screen emulator against a scripted model, so timings reflect what a user sees and exclude inference.

With the harness in place, a second orchestrator ran a hillclimbing loop for three days with a single objective: improve the benchmark results without breaking parity. Each experiment followed the same procedure:

1. Agents profile the benchmarks to find where time and memory go, turning the largest costs into a backlog of hypotheses that the orchestrator then assigns to workers.
2. Workers build the current code and the candidate change on the same sandbox and run them in alternating order, along with neighboring benchmarks to catch regressions elsewhere.
3. Two reviewer agents, each on a different frontier model, check that behavior still matches TypeScript, that output stays byte-identical wherever the change claims it, and that nothing regresses on the model-facing surface.
4. The change merges, and the next experiment measures from the new baseline.

We deliberately gave the loop no numeric targets, since a fixed threshold tends to become a stopping point. The agents' only objective was to keep improving the benchmarks without breaking parity for as long as measurable gains remained. Over the hillclimb cycle, the loop logged over 144 experiment and audit records, merging over 69 valid changes that boosted performance. Below are some significant improvements we’ve seen in important areas:

TS VersionRust before HillclimbRust after Hillclimb

Cold start

Input-ready latency

14.18× faster

Warm start

Input-ready latency

13.34× faster

Large-session memory

Process-tree RSS · 10 MiB session

4.76× smaller

Installed size

Complete installation

2.89× smaller

Agents view

View-switch latency

6.09× faster

Most of the gains came from three kinds of change: moving work off the startup and render paths, replacing polling loops with event-driven waits, and releasing memory as soon as large sessions finished loading.

Results

Overall, our Rust rewrite and following performance hillclimbing has made Prime Agent significantly faster and more resource efficient. With time to input roughly 14x faster than TypeScript and using over 80% less memory after startup, Prime Agent is amongst the fastest coding agent harnesses available.

| Prime Agent (Rust)| Prime Agent (TypeScript)| Claude Code v2.1.289| Codex CLI v0.160.0| Pi v1.0.3| Hermes Agent v0.21.5
---|---|---|---|---|---|---
First paintLaunch until first visible output| 23.6 ms±0.630.63× faster| 722.8 ms±15.1| 264.6 ms±5.8| 296.8 ms±2.7| 306.3 ms±6.7| 1,715.3 ms±10.3
Time to type (cold)Fresh launch until typing works| 55.8 ms±4.913.22× faster| 737.8 ms±13.9| 348.4 ms±8.2| 324.6 ms±4.9| 317.7 ms±8.0| 2,094.5 ms±23.5
Time to type (warm)Repeat launch until typing works| 42.4 ms±4.312.96× faster| 549.6 ms±10.0| 345.1 ms±6.2| 321.3 ms±9.2| 240.4 ms±5.9| 2,097.1 ms±40.8
Installed sizeDisk space used by installation| 59.6 MB±0.02.89× smaller| 172.1 MB±0.0| 492.4 MB±0.0| 446.8 MB±0.0| 456.0 MB±0.0| 960.1 MB±0.0
Memory (RSS)Whole process tree after startup| 106.0 MB±1.35.73× smaller| 607.4 MB±0.9| 226.9 MB±0.4| 344.4 MB±3.1| 138.1 MB±0.7| 194.6 MB±0.3

This more modular codebase and stronger compile-time checks will also help us ship new capabilities faster and catch more mistakes before they reach users.

What's next

With our Rust port in, we’re bringing the same attention to detail to every part of Prime Agent, from everyday systems interactions to complex work cross many agents. Now that infrastructural improvements are out of the way, we are accelerating on capabilities and evals, and making the multi-agent workflows behind this rewrite available to you.

Prime Agent will also be more tightly knit into the Prime Intellect ecosystem, allowing you to work across the stack with cloud agent swarms, inference, traces, sandboxes, evals, hosted training, and more.

With this rewrite, we are also releasing Prime Agent with native Windows support (beta) and installation through homebrew. Prime Agent remains open source and installs with one command:

curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh | sh

or on Windows:

irm https://app.primeintellect.ai/prime-agent/install.ps1 | iex

If you'd like to work on Prime Agent, we are hiring.

References