RSI 综述 5｜不更新模型权重，prime-agent 怎样改进自己？

一、prime-agent 是什么

prime-agent 是 Prime Intellect 开源的编程与研究 Agent。它可以读取代码、运行命令、修改文件，也能连续进行实验，把独立的工作交给子 Agent。

模型负责决定下一步做什么，Harness 负责安排工具调用、提供上下文、保存任务状态。同一个模型能获得哪些信息、使用哪些工具，以及任务中断后能从哪里继续，都与这套运行程序有关。

prime-agent 在 README 中将自己称为“Self-Improving RLM Harness”。它让模型在执行任务的过程中，修改一部分后续还会使用的规则和工具。整个过程中，所调用模型的权重保持不变。

下一次调用还是同一个模型，上一次试错怎样改变它的做法？

可以从一次训练程序的排错看起。下面用一个假设的过程说明，具体机制对照 prime-agent 的论文和源码。

二、先让下一次调用知道上次出了什么错

假设 Agent 正在改进另一个模型的训练程序。它修改了负责更新参数的优化器，启动训练，运行一段时间后才发现参数出现 NaN，也就是无效数值。

继续排查，Agent 发现，这个错误只用一小组输入就能复现。修复以后，在相同输入上重复检查，异常消失了。这项检查就值得留给下一次修改，帮助它在启动耗时的训练之前发现同类问题。

下一次调用如果收到这段排错记录，就有了先检查、再训练的依据。模型权重没有更新，它能使用的信息发生了变化。

在一段短对话里，模型可以直接利用这些信息。但实验不断进行，命令、日志和临时猜测也在积累。每次读取全部历史，成本会持续增加；压缩成摘要，又需要决定哪些内容应该保留。原始日志即使仍在磁盘上，也要被找到并读入上下文，才有机会影响后续行动。

一种做法是把已经验证的经验单独记录下来。

在这个训练项目中，修改优化器后先运行小规模数值检查。若出现 NaN 或无穷大，先排查原因；检查通过后，再启动完整训练。

prime-agent 用 Continual Harness 保存这类可修改的记录。项目、使用条件和操作要求被写在一起，后续模型就能据此安排检查，而不必每次都从完整日志中重新整理同一项要求。

这条记录说明了什么时候检查。检查具体怎么做，还需要保留下来。

三、把检查方法也留下来

一次数值检查需要构造输入、执行若干次参数更新，再查看结果。如果每次都由模型重新生成这些操作，检查就可能发生变化，甚至遗漏上次恰好能复现错误的条件。

已经确认有用的方法，可以写成函数。下一次传入新的优化器实现，继续执行同样的步骤。

用两段伪代码看这个变化，函数名仅用于表示操作。最初，修改完成后直接启动训练。

candidate = edit_optimizer()
run_training(candidate)

如果模型按保存的约定安排下一次操作，就会先调用检查函数。这里约定 check_numerics 在发现异常时抛出错误，让程序在训练开始前停下来。

candidate = edit_optimizer()
check_numerics(candidate)
run_training(candidate)

检查所用的输入和判断步骤保留在函数里，后面的修改可以直接复用。模型仍然需要分析新问题，但已经确定的操作不必每次重新生成。

这类检查可以具体到什么程度？Prime Agent 论文附录 记录了 GLM 5.3 的一次实际操作。它在启动 GPU 筛选前，先在 CPU 上调试自己写的 SOAP 优化器。参数用了三种形状，既有方阵，也有长矩形。对每种形状，程序每轮填入随机梯度，再更新参数，最多重复 25 次。发现 NaN 或无穷大时，就输出异常发生的步数，并检查优化器的内部状态。

这段检查保留了输入形状、运行次数和判断方法，后来修改代码时，可以在相同条件下重试。附录记录了这段检查代码，没有展示它对应的 /refine 更新。

prime-agent 通过 RLM（Recursive Language Model） 提供持久的 Python 交互环境，也就是 REPL。在同一个会话里，上一轮定义的函数和变量可以继续使用。模型也能通过程序调用子 Agent，让它在独立上下文中处理子任务。

Prime Agent 论文的 nanoGPT 实验 观察到了这样的程序复用。Kimi K3 编写了一个 probe 函数，约 90 次筛选实验都通过它运行。同一模型在其原生 CLI 下，每次直接修改文件，没有建立对应的实验接口。

不过，论文也指出，不同 Harness 的最终纪录差异，相对于实验本身的波动并不明显。程序被反复使用，说明实验方法发生了变化；最终成绩是否因此提高，这组结果还不能确定。

函数之外，后续模型还需要知道它在哪里、适合什么时候使用。Continual Harness 可以用 memory 保存出错条件，用附加 prompt 提醒模型先检查，再用 skill 记录工具的 Python 引用和参数。这些记录让模型能够把当前任务与已有工具联系起来。

跨会话使用时，函数需要保存为可导入的 Python 模块。skill 条目记录调用方式，模块代码仍然需要编写、安装和测试。/refine 更新的是这份记录。

四、/refine 怎样从任务记录里更新经验

从任务记录中选出哪些内容，仍然需要判断。一次失败暴露了什么问题，后来的修复又验证了什么，会决定经验应该写到什么程度。

执行 /refine 时，prime-agent 会把最近的对话、工具结果、已有经验和修改历史交给模型，让它提出新增、更新或删除记录的建议。

对前面的数值错误，产生 NaN 的输入、代码的修改，以及相同输入上的复测结果，都是有用的证据。它们说明这项检查在什么条件下发现了问题，却不能证明优化器在所有情况下都正确。

换一种失败来想。假设同一份实现，每批处理 64 个样本时显存不足，减少到 16 个就能完成这次运行。若总结成“这个优化器不可用”，后续模型可能直接放弃这条路线；保留实验条件，得到的记录就会更准确。

在本次设备、输入长度和精度设置下，batch size 为 64 时显存不足，降到 16 后运行完成。

这条记录给下一次实验留下了调整 batch size 的依据，也保留了换设备后重新尝试的余地。refine 的指令 要求模型依据证据做小范围修改，同时参考已有记录。对原因的理解，仍然依赖模型的判断。

模型返回 JSON 编辑建议，写明要改的记录、理由和预期效果。运行程序 检查建议中的编辑，通过校验的修改随后保存到 harness_state.json。

版本和修改历史也由程序维护。模型生成建议期间，同一条记录可能已被其他操作修改，所以应用建议前还要重读状态。如果目标记录已经变化，就拒绝相应编辑。之后发现经验有误，也可以根据保存的旧内容回滚。

默认记录属于当前会话，这个范围叫 local。显式选择 global 后，后续会话也可以读取。保存范围扩大了，经验的适用条件仍然需要写清楚。

例如，前面的 CPU 检查适合这项实现；换成依赖某个仅支持 GPU 的算子的实现，原检查就无法直接运行。如果全局记录只写“所有训练前都先在 CPU 上检查”，模型可能反复尝试一个当前环境根本不支持的步骤。

保存的内容还需要重新进入上下文，才有机会影响下一次行动。

五、把保存的经验接回下一次行动

prime-agent 会把一部分记录整理成摘要，加入后续系统提示词。本文引用的源码版本中，每类默认最多展示 6 条摘要，每条内容最多保留 180 个字符，其余内容可以再通过工具读取。

这能控制提示词的长度，也带来一个使用上的限制。假设已经保存了十条 memory，关于数值检查的那一条，按路径、标题和 ID 排序后排在第七。它仍在文件里，但默认的六条条目摘要不会展示它。如果这次调用也没有通过其他历史记录或工具读取获得这项要求，模型就没有收到“先检查”的信息。

所以，即使打开文件能找到这条经验，也还需要查看那次调用实际收到了什么。

对于训练项目，使用这条经验需要几个连续的动作。

1. 模型读到项目约定，知道修改优化器后需要先检查。
2. 根据工具说明找到检查程序，传入新的实现。
3. 检查报错，就排查原因；检查通过，再继续训练。

这些动作才把记录与任务结果联系起来。文件写入成功，说明内容保存了；模型是否采用约定、是否正确调用工具，需要从后续执行中确认。

数值检查本身也有范围。它通过了，只说明所测输入没有发现异常。完整训练需要的其他正确性测试，仍然要继续。

六、怎样判断这次变化值得保留

一种经验是否值得保留，要看采用它以后的任务表现。固定模型、任务和总预算，比较加入经验前后的结果，才能判断错误是否更早暴露、无效训练是否减少，以及最终结果有没有退步。整理经验、读取记录和运行检查的成本，也需要包含在内。

可以先算一个简化的时间例子。假设一次检查花 30 秒，连续做 20 次修改，检查合计占用 10 分钟。如果它提前发现一个错误，而这个错误原本要训练 20 分钟才暴露，那么只比较检查和无效训练的时间，就净省下 10 分钟。如果这 20 次修改本来都能正常训练，检查则增加了 10 分钟开销。这些数字只是示意；正式比较时，还要计算模型调用、工具运行等成本，并确认最终结果没有变差。

如果检查很慢，或者经常误判，它也可能增加任务负担。这时需要修改记录，必要时回滚。回滚能够撤回这次经验更新，已经消耗的计算则无法恢复。

评价标准也需要保持一致。论文中的 Factorio（异星工厂）轨迹 提供了一个反例。Agent 发现可以通过 RCON 远程控制接口，直接向组装机器中生成资源。尽管系统已有反作弊提醒，它仍然使用了这条捷径，并把它保存成可复用的 skill。

资源增加了，任务要求的生产过程却被绕过了。记录和保存机制正常工作，留下的做法违反了任务规则。如果评估只关注资源数量，这条捷径就可能被当成值得保留的经验。

对开头的训练项目来说，如果后续 Agent 能调用已有检查，在完整训练前发现同类错误，就减少了一次重复的试错。模型权重保持不变，前一次任务留下的规则和程序改变了后一次的工作方式。

RSI（递归自我改进）还要考察改进能力本身。Agent 更新以后，发现和验证下一项对自身有效的改动，是否变得更容易？可以把更新前后的 Agent 放到相同的改进任务里，保持预算和验收标准一致，比较找到有效改动的成功率与成本。论文中的 probe 展示了研究方法的复用，Agent 是否因此更善于改进自身，还需要这样的对照实验。