用于 RSI 研究的基础设施：运行并评估自我改进型智能体

研究中的智能体修改了自己代码里的搜索工具，完成了一项之前失败的任务。它现在能完成其他任务吗？改进后的版本，还能继续找到有用的改动吗？要回答这些问题，就需要反复改程序、跑实验、对比结果。Beeuni 提供一台计算机，让智能体使用你的代码、工具和评估脚本完成这些工作。

递归自我改进（RSI）研究系统能否改进自身，也包括能否更好地产生下一次改进。智能体实验可以让它修改代码、指令或工具，测试改动，再用有效的新版本继续尝试。下面以搜索工具为例，说明 Beeuni 怎样帮助你完成这个过程。

给 Beeuni 代码，再提出一个具体问题

连接存放智能体和测试的代码库。告诉 Beeuni 怎样安装依赖、用什么命令运行评估，以及允许修改哪些部分。第一个问题可以很小：搜索工具能不能只返回相关函数，而不把整个文件发给模型？

允许智能体改什么，取决于你的研究问题。你可以研究换一套指令能否改善规划、新的搜索实现能否减少无用阅读，或者调整记忆处理方式能否帮助后续任务。每项实验要区分清楚。修改模型权重则是另一类实验，需要相应的训练方法和算力。

Inspect the file-search tool in this repository.
Run the existing coding-task tests before changing it.
Try returning matching functions with their file paths and line numbers.
Keep the model and test settings unchanged.
Run the same tests again. Save the patch, raw logs, and a comparison report.
Do not change the tests or merge the code.

Beeuni 可以阅读实现、执行安装命令，再通过终端运行测试。遇到缺少依赖或测试崩溃，它可以查看报错并排查原因。你可以在会话中跟进过程，也可以打开它生成的文件。

先跑原来的工具，再试修改后的版本

先让 Beeuni 运行没有改动的智能体，保存哪些任务通过、哪些失败，以及具体报错。如果测试程序记录了模型用量、工具调用次数或耗时，也一起保存。这样，修改后就有了可以对照的结果。

接着让智能体修改搜索工具，再执行同一条测试命令。两次对比保持模型、任务列表和限制不变。让它结合日志解释每一项结果变化。Token 减少了值得关注；如果精简后的搜索结果漏掉重要代码，导致原本通过的任务失败，也要查清原因。

你提供测试任务和评分脚本，让 Beeuni 运行并整理这些文件。怎样才算改进，仍由你的实验标准决定。

从失败任务中找下一步该改什么

假设新工具处理小文件没有问题，但遇到跨文件调用的辅助函数就失败了。你可以让 Beeuni 查看这项失败任务，找出遗漏的信息，再提出更有针对性的修改。例如，在搜索结果中补上相关函数名，而不是重新返回所有文件的全文。

接受改动前，先审核补丁和报告，然后换其他任务测试。只通过促使你修改工具的那个例子，说服力还不够；还要看智能体能不能完成没有拿来反复调试的任务。最终评分所用的测试，不应放在智能体可以修改的文件中。

浏览器智能体也可以这样测试。给 Beeuni 一个测试应用，让它查找某个订单并修改配送备注。它可以操作浏览器、检查修改结果，并保存失败时的证据。对比下一个版本前，先重置应用的测试数据，让两个版本从同一个订单状态开始。

用自己的程序安排多轮实验

多轮实验需要一个安排流程的程序，通常称为控制器。它选择智能体版本、要求修改、启动测试，再决定下一步。某一轮中接受测试的修改版，就是候选版本。控制器可以通过 API 或 TypeScript SDK启动和查看 Beeuni 会话，版本选择规则仍由你的研究代码负责。

每个会话有自己的执行环境。测试两种工具实现时，不必让它们覆盖同一份工作文件或依赖。还要确认计算机内启动的程序确实使用了指定代码版本。如果脚本只在启动时加载代码，修改后应重启脚本，避免测到的还是旧实现。

先安排少量实验。在控制器中限制尝试次数、并发会话数、运行时间和模型用量。达到限制时，让它停止相关任务，并检查进程确实结束。这些规则决定了实验在选定一个版本前，可以花多少资源寻找改进。

让不同版本在相同条件下接受测试

如果智能体能看到标准答案或修改测试，它可能得分更高，却没有更会完成任务。最终评分应单独运行，隐藏答案不能放在智能体可访问的文件中，评分代码也不能让它修改。Beeuni 可以运行开发测试、收集输出，再由你的评估程序单独评分。浏览器实验还要重置共享应用的数据：换一台计算机，仍然会看到外部应用里留下的记录。

对比任务成功率、报错、耗时，以及测试程序记录的工具调用和模型用量。任务集、模型设置和执行限制应当可比，不确定的结果要重复验证。某项改动可能减少 Token，却漏掉辅助函数；也可能靠更多模型调用完成更多任务。报告需要把这些代价一起列出来。

找到改动本身也有成本。提出和测试不同版本的尝试，应与最终选中版本的运行成本分开记录。最后的智能体可能每项任务更便宜，但发现这个版本的过程花费很高。判断实验结果时，两项都要看。

留下足够信息，才能解释一轮实验为什么失败

任务答错和模型 API 不可用，需要不同的处理。让 Beeuni 先保留原始报错和日志，再做总结。结果中应区分答案错误、缺少依赖、模型请求失败和超时。明确哪些情况可以重试，不要把每次失败都悄悄重跑到通过为止。

保存修改前后的代码版本、指令、启动命令、依赖、测试集版本、评分代码版本和每项任务的结果。同时记录每次改动来自哪个旧版本。Beeuni 可以帮你把这些信息与补丁、日志放在一起，方便回看为什么接受或拒绝某个版本。

删除实验计算机前，把有用的补丁和报告保存到你选定的代码库或存储位置。这样，每项结果都能追溯到产生它的代码和命令，被你放弃的尝试也有记录。

检查改进后的版本，能否更好地继续改进

选定版本后，先用没有参与调试的任务评估它。再让它继续提出改进，与原始智能体的尝试作比较。在相同预算下，它能否更经常找到有用改动、减少尝试次数，或更少破坏原有表现？完成更多任务是一项结果；产生后续改进的过程是否也变好了，是 RSI 研究还需要回答的问题。

Darwin Gödel Machine 论文研究智能体修改自己的代码并测试改动。Self-Refine则研究不额外训练、通过反馈修改答案。这个区别有助于明确实验对象：你改进的是一次回答、智能体的工作方式，还是它找到下一次改进的能力？Beeuni 可以帮助修改代码、执行命令和查看结果。研究方法由你设计。需要训练模型时，可以阅读用 Beeuni 运行微调任务。

想试试这个搜索工具实验，只需要先准备一个代码库和一条能正常运行的测试命令。Computer 指南介绍了怎样在 Beeuni 工作时查看环境和进程输出。