你让几名助手照着一台还能运行、却没有说明书的旧机器，重新画出全部零件图。几个月后，新机器亮灯了，按钮也能按，但齿轮尺寸可能全错。这正是一个游戏反编译项目遇到的问题：多个 AI Agent 很快写出大量漂亮、可编译的 C++，游戏甚至能进入主菜单、加载地图，但代码并没有忠实还原原作。
反编译（Decompilation）是从可执行程序反推结构和逻辑。得到的不是原始源码，而是一份需要靠实际行为不断校验的重建版本。项目参与者 Maurice 在博客中称，团队用约三个月和约 5000 亿 Token——模型读写文本与代码的基本计量单位——拆解一款热门第一人称射击游戏。这个数字没有公开日志或统一计量口径，更适合看作累计推理规模的自述，不能直接换算成成本或质量。
它不是一条提示词完成的
团队想做的不是一个“能启动就算成功”的演示，而是可读、稳定、功能尽量完整的 C++ 重建。项目最初还考虑安全修复、漏洞修复和跨平台运行，后来暂缓这些目标，集中复现原始行为。也就是说，Linux、macOS 或浏览器版本并没有在材料中得到实现。
第一个月有四个 Agent：三个 worker 负责分析、写代码和提交，一个 reviewer 负责协调、审查提交并标记问题。它们通过 GitHub CLI 管理任务，每个 translation unit——大致可理解为一个独立编译的 .cpp 文件——对应一个 issue。多个 Agent 共用 Discord 频道，人类也能加入；GitHub webhook 会把持续集成（CI，即自动编译和检查）失败推送到频道。
Claude Agent 运行在 Claude Code CLI，Codex Agent 运行在 Codex CLI。项目先用 Claude Max (20x)，后来加入 Codex Pro，同时使用两种订阅。作者还列出 Sonnet 5、Opus 5.5、Luna、Sol 和 Terra，但没有说明这些名称的供应方、版本身份和具体占比。反汇编与反编译阶段，Agent 几乎全程使用 Hex-Rays 的 ida-mcp，让模型能够调用 IDA 的分析能力。
进度很快，正确性却掉队了
按作者口径，第一个月约 80% 的游戏已被反编译，程序能够启动、显示主菜单并加载地图。但“80%”没有公开计算方法：它可能按 .cpp 文件数量统计，并不等于 80% 的函数、代码量或游戏行为已经准确复现。
更关键的是，团队后来发现，持续出现的可见进展制造了质量很高的错觉。代码读起来顺畅，却存在语义错误：Agent 会选错函数签名、数据类型和结构体布局，也会凭空补逻辑，或删掉它认为多余的部分。有一次，原作直接读取全局配置变量，Agent 却改成哈希表查询，让一次简单的内存访问变得昂贵许多。
问题不只是模型会犯错，而是团队起初没有给“正确”划出可检验的边界。reviewer 能发现普通 bug，却很难判断架构变化是否合理。尤其当“忠实还原”“现代化”和“跨平台”同时存在时，偏离原作究竟是改进还是错误，本身就说不清。
长周期 Agent 靠什么不跑偏
团队把上下文压缩阈值从默认的 90% 降到 42%。上下文可以理解为 Agent 当前摊在桌面上的工作资料；完成一个函数后，许多临时信息已经无用，早点压缩可以清掉这些内容，也减少 Agent 在材料越来越多时走神。
这仍然不够。Agent 会没完成当前函数就转向下一项，也会等待 CI 时闲置，偶尔还会在没有充分核验的情况下关闭 issue。团队于是编写一份具体的工作规范，并设置每小时运行的定时任务，要求 Agent 重新阅读。这个略显笨拙的办法，反而揭示了实验最有价值的一点：长期自主工作不仅需要模型能力，还需要任务编排、共享状态、自动反馈和反复提醒。
为什么值得关注
5000 亿 Token 最醒目的地方不是“大”，而是它暴露了规模与可靠性之间的距离。多 Agent 协作可以迅速铺开工作，也会迅速复制错误。程序能编译、能启动、界面能显示，都只是阶段性信号；功能完备重制还要求行为和稳定性持续接近原作。
因此，“Agent 学会反编译游戏”并不准确。材料呈现的是人类花数月搭建任务、通信、CI 和审查体系，让多个 Agent 在约束下协作，并在发现质量问题后调整目标与流程。它更像一次大型软件工程组织实验，而不是模型获得了新的持久能力。
局限与未知
- 全部核心结论来自项目参与者的单篇博客自述，缺少独立复核，也没有公开完整日志、验收标准或可复现实验。
- 游戏名称因权利方介入而被隐去。据 Maurice 的博客及 AiFeed 转述，作者此前两篇相关文章也已撤下，因此目标游戏、授权状态和最终成果都无法核实。
- 约 5000 亿 Token 和首月约 80% 完成度都不是审计数字，不能据此推导项目成本、单一模型贡献或最终正确率。