2000 个智能体把 Agent 重写成 Rust：编排流水线拆解

2000 个智能体把 Agent 重写成 Rust：编排流水线拆解

原文：Prime Intellect Blog - 《Rewriting Prime Agent in Rust》（https://www.primeintellect.ai/blog/prime-agent-rust）

一、先看规模

Prime Agent 在 8 月上线，到现在下载超过 30 万次、处理超过 8 万亿 token。10 月 8 日，官方发布了用 Rust 从零重写的版本。重写过程是这样的：两周内，Prime Agent 编排了 2000 多个智能体，运行在 10000 多个 Prime Sandbox 上，通过 GLM-5.3 端点消耗了 2000 多亿 token，把整个项目从 TypeScript 端到端迁到 Rust。

对外传播的重点通常是"Rust 更快"，但对做 Agent 的人真正有参考价值的是另外两件事：怎么让一群智能体自己判断"这一步做完了"，以及怎么让写代码的智能体和验证代码的智能体彻底分开。

二、第一步不是写代码，是先定义"做完"

自动化迁移最容易翻车的地方是：智能体特别擅长宣布自己完成了。

所以这个项目先把"完成"变成机器可判定的检查。原文说得很直接：人类唯一必须做的工作，就是把验证搭好，让大规模自主交付变得可能。他们定义了四类对照检查，官方称为 parity：

1. TUI parity：把 TypeScript 和 Rust 两个二进制放在一起，跑同一段脚本化的模型，逐帧比对终端渲染结果，覆盖启动、斜杠菜单、工具调用、上下文压缩、agents 视图、会话恢复、子智能体和崩溃恢复等用户流程。
2. Harness parity：比对两个版本产出的会话记录，以及各自发给模型供应商的请求，确保同样的输入产出同样的会话。
3. Protocol parity：守护进程协议里的所有消息类型都对照 TypeScript 实现校验，保证 ACP 与守护进程协议的接口一致。
4. Feature parity：脚本化流程覆盖不了整个界面，所以智能体逐个组件审计 TypeScript 版本，把每个组件标成匹配、部分匹配或缺失。

这四类检查的作用是：智能体有了可测量的进度信号，能在改动合并前自己接住回归，人也就能少做人工评审。

三、单根编排者：指挥的手不写代码

整个重写由一个 root agent 编排，它把工作拆成拓扑排序的任务，自己一行产品代码都不写。原因很实在：只有不写代码，它才有带宽盯住每个任务、合并已完成的工作，并维持全局视图。

每个任务都要经过四个角色的流水线：

角色	做什么
Planner	写出这条任务的机器规格，包括功能设计、作为基准的 TypeScript 行为和验证方式
Implementer	在独立 worktree 里写 Rust 代码，让多个功能可以并行推进
Reviewer	用不同的模型、在独立的上下文里对抗性地审查这个 PR，专门找这个改动为什么是错的
Verifier	在全新的 Prime Sandbox 里编译并运行该功能的 parity 检查和测试

评审或验证失败，就把结论退回给 Implementer；两者都通过才合并。

这里有一条值得抄走的经验：写代码的智能体在评价自己的代码时是有偏的。所以生成和验证必须落在不同的智能体、不同的模型、不同的上下文里，而不是同一个 Agent 自查自改。

四、顺手把架构也重排了

迁移不只是翻译语言，也是重新划分边界。官方列出的长期收益主要来自结构：

• 拆成九个 crate，依赖图单向，由 Cargo 强制保证；最大源文件从 TypeScript 的约 15000 行降到约 2500 行，TypeScript 里有 4 个文件超过 5000 行，Rust 版一个也没有。
• 每个会话跑在自己的 worker 进程里，由一个小 supervisor 看管，单个会话崩溃不影响其他会话；会话状态落盘，客户端重启后可以重新挂上。
• 传输、进程控制、文件锁被放在平台特定接口后面，所以支持 Windows 基本就是实现这几个接口。
• 客户端、守护进程、worker 编译同一套共享消息类型，协议一改处处受检。
• 模型与 MCP 列表搬到运行时拉取的 catalog 里，上新模型不用发版。

五、性能爬山：刻意不给数字目标

功能对齐之后，他们开始优化运行时性能，做法和重写一样------给智能体一个客观的测量手段。

他们搭了一个 benchmark harness：每次基准测试都在全新的 4 核 8GB Prime Sandbox 里跑，用真实终端配屏幕模拟器驱动脚本化模型，计时反映用户实际看到的延迟，并且排除推理耗时。测量对象既有 Rust 版和 TypeScript 版，也有其他 agent harness。

然后第二个编排器跑了三天的爬山循环，每轮实验的流程是：

1. 分析 benchmark，找到时间和内存花在哪里，把最大开销转成假设清单，由编排器派给 worker。
2. 在同一沙箱里交替运行当前代码和候选改动，同时跑邻近 benchmark 抓其他地方的回归。
3. 两个评审智能体各自使用不同的前沿模型，检查行为是否仍与 TypeScript 一致、声称字节级相同的输出是否真的一致、面向模型的接口有没有退化。
4. 合并改动，下一轮从新基线开始测量。

一个细节值得注意：他们没有给爬山循环设定数值目标，理由是固定阈值很容易变成停止点，智能体只要够到就算完。循环的唯一目标是持续改进 benchmark，同时不破坏 parity。

三天里记录了一百四十多份实验与审计记录，合并了 69 个有效改动。结果大致是：冷启动输入就绪快 14.18 倍，热启动快 13.34 倍，大会话内存占用小 4.76 倍，安装体积小 2.89 倍，agents 视图切换快 6.09 倍。官方同时提醒：外部 harness 的对比数据来自他们自研的 runtime 套件，目前没有统一基准，横向比较需要谨慎看待。

安装方式官方给了两条命令：

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

Windows 上是：

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

六、可以搬到自己项目里的五点

1. 先把验证器写出来，再放开自动化。人做的工作从写代码变成定义什么叫对。
2. 生成者不自评。评审要换模型、换上下文，专门找错。
3. 编排者不写代码。指挥权和实现权分开，才能保住全局视野。
4. 分阶段切换。主循环的 parity 一达成，他们就把重写用的智能体本身切到 Rust 版本上跑，让新代码在真实使用中暴露问题。
5. 差异测试只覆盖它跑到过的行为。剩下的 bug 和缺失功能，最终还是靠内部日常使用和用户 trace 找出来，所以上线后的 trace 复盘要留预算。

七、30 秒讲法

一句话：让 2000 个智能体重写一个项目，难点不在模型能力，而在把"什么叫完成"翻译成机器可判定的检查、把生成与验证分给不同的智能体和模型、再给性能优化留一个能自己跑的爬山循环。做完这三件事，人的工作就只剩下定义目标、看结果和处理异常。

最后说明：以上数字与流程细节来自 Prime Intellect 官方博客，其对比基准为团队自研套件，具体版本与结果以官方页面为准，未验证最新版本。