过去三个月，我投入部分时间与算力，对一款热门第一人称射击游戏进行了深度反编译。目标并非简单的概念验证（PoC），而是力求在代码层面精准、稳定且完整地重现这款游戏。
此前我曾发布两篇相关文章后删除，部分原因在于外部因素干扰。本文重点不在于游戏本身，而在于探讨AI编排（Orchestration），以及如何通过优化基础设施、配置和工具集来获得最佳结果。该项目得益于RektInator、Future、st0rm等社区成员的帮助。
项目目标
我们旨在将游戏反编译为可读性强、可成功编译的C++代码。初期曾考虑安全性修复及跨平台移植（如Linux、macOS或浏览器运行），但随后调整策略，专注于完全重建原始行为。核心目标在于学习如何在数月内有效编排自主AI智能体。
初始架构与设置
我们同时订阅了Claude Max (20x)和Codex Pro。模型选择灵活，主要使用Sonnet 5，辅以Opus 5.5、Luna、Sol和Terra。智能体分别在Claude Code CLI和Codex CLI中运行，其他框架因差异微小未被采用。
进度追踪与通信
利用GitHub CLI，智能体通过管理GitHub Issue追踪进度，每个翻译单元（.cpp文件）对应一个Issue，并通过标签分组排序。通信方面，所有智能体接入同一Discord频道，实现智能体间及人机交互。GitHub Webhook将CI失败信息推送至该频道，以便及时通知智能体纠错。
反汇编工具
智能体全程使用Hex-Rays官方的ida-mcp工具，其稳定性及无头模式支持极大地提升了效率。
首月尝试与困境
初期部署了4个智能体：3个工作者负责反编译，1个审查者负责协调与纠错。四周内，智能体完成了约80%的代码反编译，游戏可启动并加载地图。期间我们优化了上下文压缩阈值（从90%降至42%）以清除无效信息，并通过每小时注入指令文档防止智能体“注意力漂移”。
然而，表面进展掩盖了质量问题。代码虽可读，但存在严重语义错误：函数签名错误、逻辑捏造或不必要的架构变更（如将全局变量访问改为高成本的哈希表查找）。究其原因，缺乏客观验收标准，且工作者智能体的注释对审查者产生了误导性的提示注入效应。
引入“先知”：字节级验证
为解决语义一致性问题，我们引入了自动检查机制——“字节匹配反编译”。通过切换至原版编译器并编写比对脚本，逐字节比较重建的OBJ文件与原游戏EXE/PDB。除重定位引用外，其余数据需严格匹配。CI流程会记录已验证函数，并在回归时报警。
为防止智能体作弊（如写入内联汇编或修改验证脚本），我们制定了严格禁令，并对验证脚本进行哈希校验。尽管字节匹配增加了反编译难度，且可能忽略某些语义相同但指令顺序不同的情况，但它保证了函数的语义一致性，消除了对审查者智能体的依赖，并允许使用更廉价模型（如Luna）大规模扩展任务。
最终成果
在新验证体系下，智能体继续工作近两个月。最终，99%的游戏函数被重建，其中83%实现了字节级精确匹配。后期主要使用14个Luna智能体和2个Opus 5.5智能体。随着规模扩大，Discord通信效率下降，沟通被精简至最小限度。剩余未匹配函数多因非确定性特征或链接器行为导致，虽未逐字节匹配，但语义被认为正确，游戏运行完美无瑕。
经验教训
- 指令需精确：模糊的任务定义会诱发智能体作弊。
- 机器可验的正确性：客观的PASS/FAIL信号优于人类审查，是智能体最佳反馈。
- 指令衰减问题：自主工作中，需定期刷新指令以防止规则遗忘。
- 代码成本低廉：劣质代码应直接丢弃而非修补，重构往往比重写更耗时。
- 正确性优先：吞吐量优化不能以牺牲结果为代价。
结语
该项目揭示了AI智能体编排的挑战。扩展至15个以上智能体时，虚拟机频繁被误擦除，暴露出沙箱方案的不足。因会话日志丢失，确切Token消耗未知，估计在6000亿至7000亿之间。出于个人使用目的，相关代码将保持私有，不予公开。