5亿Token，AI重构了一款FPS

10月9日，开发者 momo5502 发布了一篇题为《500B Tokens Later: Letting AI Agents Decompile a First-Person Shooter》的实验记录：他让 AI Agent 长时间参与一款第一人称射击游戏的反编译与重构，累计消耗约 5000亿 Token。

这不是“让 AI 写一个类似《反恐精英》的小游戏”，也不是把几段自然语言需求丢给模型后生成一个能玩的 Demo。它面对的是一套已经编译完成、缺少原始源代码的游戏程序，需要从二进制、运行行为、崩溃信息和编译结果中，逐步推断出原有的程序结构。

**反编译是从可执行文件和机器码中恢复高级语言逻辑的过程。**它与普通代码生成最大的区别在于：模型没有一份清晰的需求文档，也没有可直接阅读的函数名、变量名和注释，只有大量不完整、难以验证的线索。

这场实验最值得关注的地方，不是“5000亿Token”这个足够吸睛的数字，而是它暴露了 Agent 编程的真实形态：当任务从写函数升级为重建一套复杂软件系统，瓶颈已经从模型会不会写代码，转向模型能否长期记忆、持续验证、管理上下文，并在错误反馈中不断收敛。

这不是复制画面，而是恢复程序行为

游戏反编译的目标不是重新画出几个地图，而是尽可能恢复原程序的行为、数据结构和执行逻辑。

一款第一人称射击游戏通常包含渲染、输入、碰撞、物理、音频、地图加载、AI、网络同步、资源管理等多个子系统。玩家看到的只是屏幕上的准星、墙体和敌人，但程序内部可能有成千上万个函数，以及大量互相依赖的状态变量。

**游戏重构是用新的源代码重新实现旧程序行为的工程过程。**只要角色移动速度略有变化、碰撞盒尺寸不一致、武器后坐力计算不同，玩家就会立刻感知到“这不是原来的游戏”。

反编译的难点在于，编译器会把很多人类可读信息抹掉。源代码中的：

• UpdatePlayerMovement() 可能只剩下一段机器码；
• weapon_recoil 这样的变量名可能变成栈上的一个偏移量；
• 多个函数可能被编译器内联，原本清晰的模块边界被打散；
• 优化编译会改变执行顺序，让反编译器输出的伪代码与原始代码差异很大；
• 同一个数值可能同时代表速度、角度、时间或资源索引，必须结合上下文判断。

这就像根据一座已经建成的城市，反推出原始建筑图纸。你可以通过道路、管线和建筑之间的关系猜出城市结构，但很难仅凭一条街道判断某栋楼最初为什么这样设计。

AI Agent 实际做了什么

**AI Agent 是能够自主拆解任务、调用工具、读取反馈并循环执行的模型系统。**在这项实验中，Agent 的价值并不只是生成代码，而是把反编译工作拆成大量可以反复验证的小步骤。

典型流程大致包括以下几类工作：

1. 分析二进制文件：识别函数、字符串、跳转关系、全局数据和资源引用。
2. 生成候选实现：根据反编译结果，写出更接近原始逻辑的 C、C++ 或其他语言代码。
3. 编译并运行：把生成的代码重新编译，启动游戏或对应的测试程序。
4. 比对行为：观察是否崩溃、画面是否正确、角色是否能移动、武器和碰撞是否符合预期。
5. 处理回归问题：修复一个模块后，继续检查它是否破坏了此前已经正常工作的部分。
6. 维护工程状态：记录哪些函数已经完成、哪些推断仍然不确定、哪些测试失败，以及下一步应该处理什么。

其中最关键的是“验证”。如果只有生成，没有编译和运行，模型很容易写出语法正确但逻辑完全错误的代码；如果只有单元测试，没有真实运行，渲染、输入和资源加载等问题又可能被遗漏。

Agent 更像一个速度极快、但需要不断被实验结果纠正的初级工程团队。它可以在短时间内尝试大量假设，却不会天然知道哪一个假设符合原程序。

5000亿Token意味着什么

**Token 是模型处理文本、代码、日志和工具输出时的基本计算单位。**5000亿 Token 并不等于模型写出了5000亿个有效代码字符，其中相当一部分会被消耗在重复读取上下文、分析日志、修复失败构建、重新解释工具输出和讨论下一步计划上。

这个数字首先说明，复杂软件重构并不是一次提示词能够完成的任务。即使模型本身已经足够强，反编译依然需要经历大量“猜测—编译—运行—失败—修复”的循环。

其次，它揭示了 Agent 系统中的上下文浪费问题。一个函数可能在早期已经分析过，但由于状态管理不完善，后续任务仍然需要重新读取相关文件；一段几百行的构建日志可能真正有用的信息只有一行错误位置，其余内容却被完整送入上下文。

再次，Token 消耗与工程价值并不成正比。模型可能花费数十亿 Token 讨论一个函数的命名，却没有让游戏向前推进一步。真正重要的不是“用了多少 Token”，而是每一单位 Token 是否带来了可验证的工程进展。

| 工作方式 | 主要特点 | 典型问题 | 适用场景 | |---|---|---|---| | 单轮代码生成 | 根据需求一次性输出代码 | 无法处理长期状态和复杂依赖 | 小型函数、独立脚本 | | 普通编码 Agent | 能修改文件并运行测试 | 容易陷入重复修复循环 | 中小型应用、工具开发 | | 反编译 Agent | 同时处理二进制、源码、日志和运行行为 | 推断不确定、验证成本极高 | 软件考古、兼容层、旧游戏重构 | | 人机协作工程 | AI 批量尝试，人类确定方向和验收 | 仍需要高水平人工判断 | 大型遗留系统、关键模块重写 |

它为什么特别适合游戏反编译

游戏是一个适合 Agent 反复试错的环境，因为它拥有相对明确的外部反馈。

角色能不能移动、枪械能不能开火、子弹是否命中、地图是否正确加载、画面有没有明显异常，这些结果都可以被测试程序、截图、日志和运行时监控捕获。与企业业务代码相比，游戏的很多错误更容易转化为可观察信号。

**可验证性是 Agent 处理复杂软件任务的核心条件。**只要系统能稳定回答“改动后变好了吗”，模型就有机会通过多轮迭代逼近目标。

但游戏也有自己的困难。视觉效果可以大致相似，底层逻辑却可能完全不同；一个看起来正常的场景，可能在特定角度、特定武器或多人同步条件下才暴露错误。尤其是物理和碰撞系统，往往存在大量边界条件，不能只靠几次人工试玩判断正确性。

因此，反编译项目通常需要多层验证：

• 编译验证：代码能否通过编译和链接；
• 运行验证：程序能否启动并进入目标场景；
• 行为验证：输入、碰撞、武器、AI 等功能是否符合预期；
• 差分验证：新旧程序在相同输入下的状态和输出是否接近；
• 回归验证：新修复是否破坏了之前已完成的模块。

如果缺少这些环节，Agent 可能只是把一个错误从渲染模块搬到了资源模块，看起来“改了很多代码”，实际并没有真正接近原程序。

与传统反编译相比，AI带来了什么变化

传统游戏反编译项目往往由少数熟悉目标平台、编译器和游戏引擎的开发者长期维护。以经典主机游戏为例，社区可能需要数年时间手工恢复函数、重命名变量、修正类型，并通过逐步替换的方式让新代码重新生成接近原版的可执行文件。

AI Agent 的变化在于，它可以同时探索更多候选方案。一个人可能会在某个函数上花几个小时，Agent 则可以快速生成多个版本、编译并比较结果。它也能更耐心地处理大量机械性工作，例如批量整理函数、补全类型信息、生成测试脚本和归档构建日志。

但 AI 并没有消除专业知识，只是改变了专业知识的使用方式。

人类仍然需要决定：哪些行为是项目真正要保持的，哪些错误可以接受；应该优先处理渲染、输入还是资源加载；某个反编译结果是否可信；测试用例是否覆盖了关键路径。换句话说，AI 降低了“写出大量候选代码”的成本，却没有自动解决“怎样判断代码正确”的问题。

这也是它与传统自动反编译器的区别。反编译器擅长把机器码转换成结构化伪代码，AI Agent 则可以把伪代码、运行日志、测试结果和工程任务串联起来。但如果输入信息有误，或者验证体系不完整，Agent 也会把错误解释得更流畅、更有条理。

5000亿Token不是效率范本，而是一张成本账单

这项实验最容易被误读成“只要给 AI 足够多的 Token，它就能重构任何软件”。事实恰恰相反：5000亿 Token 更像是一张成本账单，提醒开发者不要把暴力扩大上下文当成工程方法。

第一，必须建立明确的状态管理。项目需要保存函数完成度、依赖关系、未决假设、失败原因和测试结果，而不是让模型每次从头阅读整个代码库。

第二，需要把大任务拆成可验收的里程碑。例如先恢复启动流程，再处理输入系统，之后是资源加载、渲染和游戏逻辑。每个阶段都要有可重复执行的测试，而不是以“感觉能跑”为验收标准。

第三，需要建立模型分工。高能力模型适合处理架构推断、歧义分析和关键模块；成本更低的模型可以负责代码整理、日志摘要和机械化重命名。所有任务都交给最昂贵的模型，通常既浪费钱，也不一定更快。

第四，需要压缩工具输出。构建日志、反编译结果和运行时追踪数据都应该先经过结构化摘要，只保留错误位置、调用链、关键变量和差异结果。否则 Agent 很容易被无关上下文淹没。

第五，需要让人类尽早介入高风险判断。一个错误的类型推断可能在几十个函数中扩散，越晚发现，返工成本越高。人类最有价值的工作不是逐行替 AI 写代码，而是及时阻止错误方向继续扩大。

对开发者意味着什么

**Agent 编程的上限取决于反馈闭环，而不仅是模型参数规模。**对于普通开发者，这个案例有三点现实启发。

第一，未来的编码 Agent 不会只围绕编辑器展开。反编译器、调试器、构建系统、测试框架、模拟器和运行时监控，都将成为 Agent 的“手脚”。没有工具权限的聊天机器人，无法完成这类长期工程。

第二，工程师需要更重视测试和可观测性。一个没有日志、没有稳定构建、没有回归测试的项目，即使接入最强模型，也只会得到更快的混乱。AI 时代的基本功不是写更多提示词，而是把软件变成可被机器验证的系统。

第三，Token 预算会成为新的工程指标。未来团队可能像管理云计算资源一样管理 Agent 任务：为每个阶段设定上下文上限、失败重试次数和预期产出，分析哪些 Token 用在了有效推理上，哪些只是重复劳动。

法律和版权边界不能被忽略

**反编译技术可行，不代表重构后的软件可以自由发布。**如果目标游戏仍受版权保护，获得二进制文件、提取资源、重新分发代码和发布可运行版本，可能分别涉及不同的法律问题。

开源项目、研究用途、兼容性实现和商业发行之间也不能混为一谈。即使新代码是 Agent 重新生成的，只要它依赖原始游戏的资源、数据或受保护表达，仍然需要审慎评估授权边界。

因此，这类实验更适合作为软件工程和程序分析研究来观察，而不是被简单包装成“AI 自动复刻商业游戏”的成功案例。技术上能做到什么，与项目最终能否公开、能否商业化，是两套完全不同的问题。

结语：真正的突破是长期工程自动化

这次实验真正改变的，不是“AI突然学会了做游戏”，而是 AI Agent 开始进入过去由少数专家和志愿者长期维护的软件考古领域。

5000亿 Token 证明了模型已经可以参与非常复杂的程序理解任务，但同样证明了当前 Agent 仍然昂贵、低效，并且高度依赖验证系统。它能快速生成假设，却不能自动保证假设正确；它能连续工作数天，却可能在错误方向上坚持数千亿 Token。

对开发者来说，最值得复制的不是“给模型更长上下文”，而是这套方法论：把复杂任务拆开，把每一步变成可运行的实验，用工具收集反馈，用状态文件管理长期记忆，再由人类在关键节点做判断。

如果未来模型能够减少重复上下文、稳定维护工程状态，并把反编译结果与运行时差分验证结合起来，那么类似任务的成本才可能从5000亿 Token降到普通团队可以承受的规模。

在那之前，AI Agent 更像一支不知疲倦的研究助理，而不是能够独立交付大型软件的资深工程师。它已经足够强，值得被认真使用；但还没有强到可以免除工程纪律。

参考来源

1. GitHub：游戏反编译项目检索——用于了解游戏反编译项目、工具链和社区实践。
2. GitHub：反编译工具相关项目检索——用于了解二进制分析与反编译工具生态。
3. momo5502，《500B Tokens Later: Letting AI Agents Decompile a First-Person Shooter》，发表于2026年10月9日——本文讨论的核心实验记录，原文标题和实验数据以作者原文为准。