2000多个AI智能体重写一个软件,启动快了14倍

大家好，我是霜空。

10月9日，Prime Intellect公布了一次软件重写的完整记录。2000多个AI智能体用了两周，把自己正在使用的Agent软件改写成Rust，团队又花了后面几周继续打磨，随后公开发布。新版本接受用户输入的启动等待缩短到原来的约十四分之一，内存占用也降了下来。

AI已经能参与改写运行自己的软件。 这句话里的“自己”究竟指什么，需要讲清楚。有人负责写代码，有人专门找错，所有改动还要经过一套对照测试。人类在这条生产线上承担了哪些工作，决定了我们能从这次实验里学到什么。

我把发布说明和公开代码记录对了一遍。最有意思的一份材料，是一个优化会话列表的改动，它把一项扫描操作从一秒多压到了二十毫秒左右，却也留下了测试失败和额外内存开销。两千多个智能体究竟忙了些什么，可以从这里看。

图1　重写与性能优化期间的智能体会话网络

它重写的究竟是什么

Prime Agent是一套开源的编程与研究工具。它调用语言模型，让模型读文件、执行程序，也允许模型派出子智能体。用户交给它一个长任务，它负责保存过程，接收工具结果，把分散的工作接起来。

模型决定接下来做什么，Agent软件负责让这个决定在电脑上执行。软件卡住、历史记录丢失、子任务的结果送不回来，模型能力再强也会受影响。Prime这次改写的对象，就是承担这些工作的程序。

被改写的是Agent软件，公开材料没有展示模型权重在这次工程中自行升级。 Prime原有的技术论文把模型权重、当前对话和外部保存的状态分开。程序能够调整提示、记忆与可复用的操作方法，这些变化会影响下次工作，但各自的变化发生在不同位置，不能合成一个模糊的“AI自己变聪明了”。

它采用的RLM方法也值得解释。大块材料可以留在持续运行的Python环境中，模型按需要检索、筛选，再把有关的片段拿进对话。子智能体有各自的上下文，处理结果还能继续交给上级。长任务因此可以拆开推进，主智能体不必每一步都重新读完所有日志。

图2　模型权重、当前上下文与外部保存状态的关系

此次记录中累计出现2209个智能体会话，包含改写和性能优化两个阶段，2209是过程中的累计数量，不能理解成同一时刻有2209个AI一起工作。 一项任务可以先派规划者，再换实现者，失败后继续派新会话，数量就会增长。

累计数量说明工程规模，能否合作还要看交接方式。Prime的公开实现允许相关智能体直接发消息，也把会话树展示给人看。人可以进入某个会话检查历史，补充要求，再离开。长任务跑到中途，保留这些入口很有用，否则主智能体只收到一句“已经完成”，很难判断下面发生过什么。

代码谁写，谁说了算

这次工程里，一个根智能体负责拆任务、看进度和合并结果。根智能体不写产品代码。 它把工作交给下面的智能体，自己留出精力处理依赖关系，并与人类一起讨论优先顺序。

一份功能改写会经过四种角色。规划者先说明旧版本的行为以及怎样检查结果，实现者在单独的工作目录里写Rust代码。接着，审查者换一个模型和上下文，专门寻找改动出错的理由，验证者则在新的沙箱里编译并运行测试。

写代码、审代码和跑验证由不同智能体承担。 写代码的模型刚花了一段时间解释自己的方案，很容易继续沿着同一套解释往下走。另一个上下文重新看改动，更有机会发现它默认成立的条件其实没有被证明。

图3　功能改写经过规划、实现、审查和验证

审查或验证不过关，任务就带着问题返回实现者，修改后重新检查。两边通过才合并。一次失败会改变任务的下一步，检查结果必须能阻止有问题的代码进入共同版本。 如果测试只是附在完成报告后面，模型仍然可以宣布胜利，工程就少了一项约束。

旧程序在这里提供了很好的参照。团队给TypeScript版和Rust版相同的脚本输入，把终端画面并排比较，检查菜单、工具调用和恢复会话等流程。程序向模型服务发出的请求也要对照，界面相似还不够，后台行为同样要接得上。

这类测试比让模型评价“功能已经齐全”更具体。菜单差了一个位置，就会在对照画面里留下差异。某条输入在旧版能恢复会话，新版却恢复失败，验证者就有一件明确的事需要报告，实现者也知道该改哪里。

配置文件里有一个细节，能看出这种对照有多细。旧版输出的JSON字段按插入顺序排列，Rust这边用的数据结构如果默认按字母排序，内容虽然相同，输出的字节就会变化。新配置专门保留了原有顺序，让会话和通信记录继续按旧方式输出。改写语言时，这些差异都得有人检查。

图4　旧版、新版与差异画面并排显示

不过，对照测试能证明它实际走过的流程。 没有覆盖的输入与故障仍然需要有人发现。通过主要流程后，团队让智能体转用Rust版本继续工作，再让内部成员日常使用它。这些使用过程暴露出测试之外的缺失，后面还要补功能、修问题和调整界面。

一次扫描怎样从一秒降到二十毫秒

改写完成后，Prime又给智能体一套性能测试，让它们继续找耗时和内存开销。公司记录了三天的优化过程，留下超过144项实验与审计记录，合并了69项以上有效改动。每次改动要在同一沙箱里与旧代码交替测，还要检查相邻操作有没有变慢。

公开的2856号代码改动，把这件事讲得很清楚。程序列出已保存的会话时，原来的缓存处理反复遍历一个越来越长的列表。会话数量增加，这种做法要付出的工作量增长得很快，扫描本身就会拖慢操作。

改动把记录访问先后顺序的方式换成了有界索引，保留已有的缓存规则。在4096份复制会话构成的压力测试里，热扫描从1031.23毫秒降到19.79毫秒。这一次具体操作的耗时减少了98.1%。 一千份不同会话的测试也有改善，说明它处理的是一个可以重复测到的问题。

这份记录没有只写一个漂亮的百分比。4096份会话时，改动多用了约968KiB内存，测试还核对输出校验值与缓存顺序。它也写明，最终启动对比没有可归因于该改动的提升。扫描快了，其他操作的成绩仍要分别测，不能顺手全部算成收益。

测试失败也留下来了。一次完整测试遇到了时序与连接问题，记录说明哪些失败在原版本也出现，哪些单独跑能够通过。有一组性能测试甚至在准备阶段失败，未完成的测量被列为不可用。没有测出来的项目，就不能记成性能提升。 这种记录比一张总分表更能帮助后来的人判断结果。

回到整个版本，团队报告的一组冷启动对比从736.1毫秒降到51.9毫秒，约快14倍。这里量的是程序启动后多久能接受输入，14倍对应框架启动等待，不代表模型推理或文字生成快了14倍。 日常打开工具会更利索，遇到需要模型长时间思考的题目，等待仍由另一部分决定。

人类先写验收，后来继续找问题

这个项目让人类工作的位置变得很清楚。工程开始时，团队先建立验证办法，说明原有行为怎样被检查。模型随后负责大量实现与修改，人类仍参与发现问题、调整方向和审查结果。两周的大规模改写之后，发布质量还花了后面几周继续打磨。

“两周重写”与“达到公开发布质量”是两个阶段。 时间线分清以后，这次成果仍然很有分量。一套实际使用的工具完成了语言迁移，还经过继续使用和优化，已经比生成一个能展示的原型向前走了许多。

普通开发者能直接得到的收益也已经落地。新版本保持开源，并提供Windows原生支持的测试版。对长任务来说，会话能否恢复同样要紧，Prime的后台进程允许终端断开后继续工作，用户重新接入时可以查看留下来的状态。速度与恢复能力会一起影响一个人愿不愿意把更长的任务交给它。

后续维护也有了一份更容易分工的代码。公开的Cargo配置把程序分成九个包，共用类型与终端界面各自有明确位置，模型调用和会话管理也分开列出。审查一个界面改动时，开发者能先沿着有关的包往下看。参与维护的人增加以后，这种边界也方便继续划分任务，减少为了改一处而重新理解整套程序的工作。

图5　智能体会话可以保留，用户能够检查并重新接入

复制这次工程的门槛也很具体。公司称，过程使用了一万多个沙箱，消耗超过2000亿token，主要通过其GLM-5.3推理服务完成。公开材料没有给出这次重写的完整费用账，不能凭token总量判断它比人工开发便宜多少。大量调用、并发测试与人的投入，都要计入一项工程的代价。

小团队也不必从两千个智能体开始。公开项目说明里的自主模式有调用与时间预算，结束条件也需要事先定义。一个独立功能是否完成，应该由它要满足的要求决定，预算用完只说明这次运行结束了。能把一个功能的改动范围和验收办法说明白，就已经具备了试一次分工协作的条件。

这件事里我最看重的，是那个负责验收的人仍然有具体工作可做。终端截图哪里对不上，某条请求有没有变化，失败能否复现，优化有没有把别处拖慢，这些问题都能落在记录上。人类把验收写清楚，才有机会减少逐行盯代码的时间。 剩下多少人力能够省下来，要等更多真实项目给出自己的账。

本文使用摸鱼小李的公众号排版 Skill，感谢摸鱼小李。