在过去的三个月里，我花了一些时间和令牌反编译一款受欢迎的第一人称射击游戏。我们的目标并不是达到一个简单的概念验证状态。相反，我们真的希望对游戏进行准确、稳定和功能完整的重建。我博客的热心读者可能注意到，我之前写过两篇已经被删除的帖子。其他人可能现在会想我在说哪款游戏。对你们两个我只能说，企业美国来这里破坏了我们的乐趣。然而，这没关系。这篇帖子不是关于游戏，它也不太关于反编译的过程。它更多是关于 AI 编排以及如何优化基础设施、设置和利用以获得最佳结果。这个项目得到了 RektInator、Future、st0rm 和其他社区成员的帮助。非常感谢他们。我们的目标是什么？我们致力于将游戏精确反编译为 C++。除了显而易见的语义正确性外，我们还有很多其他要求：我们希望获得可读的 C++ 源代码，并且可以编译。鉴于游戏的年代，我们还想要安全性和错误修复，同时改善可移植性。能够在 Linux、macOS、浏览器中运行游戏将是不错的……后来我们推迟了现代化和可移植性，以专注于重建原始行为。显然，总体目标是在几个月的时间里学习如何有效编排自主 AI 代理。初始设置我们从 Claude Max (20x) 开始，然后添加 Codex Pro，并同时使用这两项订阅。模型选择变化很大。在大多数时间里，我们一直在使用 Sonnet 5，但 Opus 5.5、Luna、Sol 和 Terra 也被频繁使用。稍后会详细介绍。Claude 代理在 Claude Code CLI 中运行，Codex 代理在 Codex CLI 中运行。我们还尝试了其他代理工具，但选择几乎无关紧要，因此我们坚持默认设置。进度跟踪通过 GitHub CLI，代理管理 GitHub 问题以跟踪进度。每个翻译单元（.cpp 文件）有一个问题。此外，标签有助于分组和优先处理问题。通讯代理通过 Discord 进行沟通。所有代理都可以访问一个频道，并可以发布和阅读其中的所有信息。Discord 允许代理与代理之间的通信，以及人类与代理之间的通信。因此，其他参与者可以与他们交流，而无需机器访问。一个 GitHub 网络钩子将 CI 失败信息发布到共享频道，因此代理在出现问题时会收到通知。反汇编和反编译代理几乎整个时间都在使用 Hex-Rays 的官方 ida-mcp。它运行良好，超级稳定，支持项目所需的一切。我只能推荐它。第一个月当时我们有 4 个代理运行。3 个工作代理在反编译和提交，1 个审核代理被动协调和审核提交以标记错误。代理成功反编译了大约 80% 的游戏，并取得了可见进展。游戏启动，主菜单可见，我们能够加载地图。我们在这四周里花了很多时间优化设置：通过更早地触发压缩来减少令牌消耗。默认的压缩阈值是 90% 的上下文填充。我们将其降低到 42%。反编译包含大量易变信息：一个已经反编译的函数现在变得无关紧要，可以从上下文中删除。因此，更早的压缩有助于移除这种“垃圾”。我们还注意到代理随着时间的推移往往会失去专注。即使在一个压缩周期内，代理也可能漂移并失去专注，随着上下文持有的数据增多。代理有时会在完成上一个函数之前转移到另一个函数。尽管在 Discord 上收到失败通知，他们在观看 CI 时也会开始闲置。偶尔，他们会在没有彻底检查工作是否完成的情况下关闭问题。在终端中并肩工作，你可以引导代理防止这种情况发生，但是让他们自主工作时，无法进行引导。为了防止这种情况，我们写了一份文件，定义了我们的目标、代理如何工作、必须避免的事项以及如何处理特定情况。每小时的 cron 任务会自动注入请求，让代理重新阅读该文档，让指令在他们的上下文中保持新鲜。虽然这可能不是保持代理专注的理想方法，但它在项目结束时效果很好。花费了大量时间完善指令文件。由于内容极其具体于这个项目，因此在这里分享没有太大意义。然而……尽管我们在优化设置和基础设施方面付出了所有努力，但我们需要讨论工作的质量。持续的进展（游戏启动、菜单渲染、地图加载）让我们相信反编译的质量很好。事实并非如此。尽管代码极其可读，但它在语义上是错误的。代理使用了错误的函数签名、类型或结构布局。