一个代理人花了三周时间对公开的 Street Fighter III: 3rd Strike 反编译进行工作，涉及约 30 万行 C 语言代码、图片，提交次数在上文的文档中。之所以整棵树都被触及，是因为斯德哥尔摩大学希望拥有两份行为相同的同一游戏的拷贝，一份保持原样（即已经是反编译的状态），另一份提升到我们评分体系中的 10 分，以便学生以后能够在两份上都添加功能，并进行比较。该研究尚未进行，此次运行仅是生成干净拷贝。大约花费 4,000 美元的代币，其后是 2,903 条提交、726 个文件以及超过 25 万行实际变动的代码。我原本以为到第一周结束时游戏会出错，因为每次我看到代理人清理大型 C 代码库后，它总会出现能够编译通过但第一次真实路径运行时就崩溃的情况。他们并没有把绿色构建视为检查标准。回放跟踪会在每一帧对回滚状态进行哈希，因此如果拳击出现帧延迟或击勾框漂移，哈希值会改变，该尝试会被抛弃。他们完成后可以坐下来与之交互，并且它运行的方式与任何人进行重构之前的运行方式一致。我会保留的手册是这些，包含 22 条配方和另外 82 条笔记。其中很多是普通的，比如把函数抽出来、把嵌套条件改为守卫条件、把长参数列表封装进一个对象。随后它开始为只在本游戏中真的存在的形状命名，因为同样的布局不断出现。Shared Index Range 是指那些只在起始和结束位置上不同，但整体工作相同的循环。Action Parameter 是指控制流的复制，真正的区别在于调用的是哪个函数。Uniform Step Table 是把几乎相同的调用折叠进一个表中的模式。提示中并没有直接给出这些名称。什么都没做的尝试以及导致文件更糟的尝试都会被放进同一本手册，因此下一次会话在打开类似文件时，不会去寻找已经失败的提取内容。Sonnet 和 Terra 会在文件上升到一定程度后停止，分数不再上升，文件中仍有未解决的问题。Opus 可以回顾已尝试过的内容，把配方写下来并标注条件，然后继续前进。Codex 与 Sol 可以做出合理的修改，但仍然不擅长记录自己刚刚完成的工作，导致下一次会话无法继承。导致累积的因素是手册本身；较小的模型在保持它方面表现不佳。循环追踪的目标是我们的 Code Health（代码健康度）评分，它在文件中可以通过 MCP 看到。在未修改的文件上运行两次，评分保持不变，这也是为何糟糕的提取很明显。树的起始分数约为 5.6，最终他们将其提升到了 10。我不会把一个老旧的 C 代码库交给代理人，让它再过三周再看。帧哈希是允许这种情况在一款每帧都决定是否能发出动作的游戏中出现的原因。如果唯一的检查仅是测试套件变绿，我就不相信那个 10 分，也就不相信游戏仍然能运行。我的问题是，你会让代理人彻底重构多大规模的代码库，以及在看到它之前，你需要它展示什么才会相信行为没有改变？