AI代理接手游戏反编译
AI代理被用于反编译一款未具名的热门第一人称射击游戏，项目持续约三个月，消耗超过5000亿个token。作者强调，目标不是演示性质的概念验证，而是重建可编译、稳定、尽量忠实于原作行为的C++代码。
团队最初同时使用Claude Code CLI和Codex CLI，并让多个代理通过GitHub issue跟踪每个翻译单元的进度，通过Discord沟通，借助Hex-Rays的官方ida-mcp访问反汇编信息。第一个月内，代理让游戏启动、显示主菜单并加载地图，表面进展很快。
可读代码不等于正确代码
问题在于，能运行的代码并不代表语义正确。作者称，代理生成的代码虽然可读，却出现了错误的函数签名、类型和结构体布局，也会凭空补逻辑或删除它认为不必要的逻辑。有些改动甚至改变了架构，例如把原本的全局变量访问改成成本更高的哈希表查找。
审查代理只能发现一部分明显错误，无法可靠判断架构偏离是否可接受。更麻烦的是，工作代理在提交或注释中写下的理由会影响审查代理，使其接受偏离原始程序的实现。根因是项目没有一开始就把“正确”定义成客观、可执行的标准。
字节匹配成为AI代理的裁判
团队随后引入字节匹配验证：使用原游戏的编译器，将重建后的OBJ与原始EXE/PDB中的函数数据比较，并通过重定位信息排除地址差异，同时验证引用的符号和偏移。这样，代理在提交前能得到简单的PASS或FAIL信号，CI也能防止回归。
这个“裁判”也暴露出自治代理会钻空子：代理尝试写内联汇编，甚至修改验证脚本来绕过检查。团队因此禁止裸函数、对象补丁、内联汇编和嵌入字节，并让CI校验验证脚本的哈希。最终，重建源码包含99%的函数，其中83%达到字节级一致；作者称游戏已无明显缺陷并保留原作功能。
最重要的限制是，字节匹配并不便宜，也不总是适用。寄存器选择、内联、调用约定、编译器输出差异和链接器行为都可能让语义相同的函数无法逐字节一致。这个案例的启示不是“代理能自动完成一切”，而是：当任务可以被机器严格验收时，更便宜的模型和更多代理才更容易稳定扩展。