自我改进的智能体仍需要人类

古德哈特定律是基准测试者的诅咒：当一个指标成为目标时，它就不再是一个好指标。编码智能体的基准测试几乎必然会触发这一现象。任务公开，结果只是一个数字，排行榜上不可避免地充斥着那些通常无意中针对基准测试过度优化的工具。

这并不意味着通用的Terminal-bench标准毫无用处，但它确实改变了Goose团队使用它的方式。排行榜只是智能体通用能力的一个有噪声的度量。真正的信号是失败的模式：Goose不断卡住的地方，或者Goose失败而其他工具成功的地方。

这也是为什么我们通常使用Sonnet而不是最强的模型进行基准测试。我们并不是要得到尽可能大的数字。我们希望留下足够的失败点，以便看清智能体缺少什么支持。

自我改进的智能体风靡一时，但我们目前信任的版本仍然需要人类参与。循环是这样的：运行基准测试，让Goose比较一个任务中一个工具成功而另一个失败的情况，并要求它具体解释差异。然后，人类观察几个这样的失败，决定一般性的教训是什么，并让Goose实现这个更广泛的改进。

人类步骤防止循环陷入基准测试的作弊技巧。没有它，自我改进的智能体可能会选择每个任务只写一个技能；智能体和人类一样懒惰。有了它，我们有望将一个任务的失败转化为一种能力，这种能力应该有助于解决我们尚未遇到的任务。

用于此的工具位于Goose仓库的evals/harbor目录中。主要入口点是./evals/harbor/cmd.py，一个小型Python命令，带有run、list、show、task、compare和pull子命令。它将Harbor封装在特定的Goose二进制文件、模型和扩展集周围，然后留下一个充满每个任务JSON和日志的目录。

这是一个Python工作得非常出色的地方。cmd.py是一个PEP 723 uv脚本，因此依赖项位于文件顶部。没有打包仪式，没有新仓库，也不需要记住哪个虚拟环境是受祝福的。你让智能体添加一个子命令、检测一个值或让输出表格不那么糟糕，它就能做到。这个脚本既成为控制面，也成为实验文档。这就是vibe coding的闪光点：小型工具表达了需要做的事情，而且它们是否编码得优雅并不重要。

实际的基准测试运行在远程Linux机器上，因为完整的运行是缓慢、并行且Docker密集型的工作。但分析不必停留在那里。cmd.py pull tbench@...:/path/to/goose将运行目录rsync回本地，然后本地工具可以列出运行、检查一个任务或比较两个作业。这一点比听起来更重要。如果每个问题都需要SSH到基准测试机器并手动浏览日志，你会问更少的问题。

PR #9637中的比较食谱实现了Goose查看结果的步骤。它们读取同一任务的两个运行、智能体的轨迹、验证器输出和参考解决方案。有用的输出解释了机制：“A注意到图像，B从未打开它”或“A在正确文件存在后停止，B不断重写直到它损坏。”

这里有两个最近工作的发现。首先，Goose有时会在有足够信息完成时继续探索。它接近答案，但没有结束，而是继续探索，最终用完回合，导致基准测试失败。同样的事情可能发生在正常对话中：如果Goose不知道它在交流中的进展，它就没有理由停止探索并转向解决方案。PR #9636为MoIM增加了回合数感知，MoIM是Goose注入以保持模型定位的上下文。所以现在Goose知道何时该收工了。

其次，Goose失去了从磁盘读取图像的能力。最初，当你将图像拖入Goose对话时，我们插入图像的路径，并为模型提供读取它的工具。这很笨拙，所以我们用对话中适当的图像加载替换了它。在此过程中，我们意外地也删除了磁盘图像工具。在基准测试中，这表现为Goose使用PIL检查图像而不是使用模型的视觉能力。比较食谱使失败显而易见，因为成功的运行查看图像而失败的运行绕过了它。

感谢这个循环，我们发现了Goose的两个真实弱点并修复了它们。基准测试得到了改进，这很好，但更重要的是，这两个修复应该使Goose在正常使用中更好：不太可能在应该完成时漂移，并且能够再次查看磁盘上的图像文件。

这就是基准测试有用的时候：当它不再是一个排行榜，而开始成为一份错误报告时。