北京
有人花了3个月时间，烧掉500B tokens，让AI智能体去反编译一款第一人称射击游戏。目标不是做个能跑的demo，而是要一份准确、稳定、功能完整的复刻版。
结果呢？游戏确实启动了，主菜单能渲染，地图能加载。但代码是错的。
这个项目由RektInator、Future、st0rm以及社区其他成员共同完成。他们想要的是可读、能编译的C++源码，还希望顺带做安全修复、bug修复和可移植性改进——比如让游戏跑在Linux、macOS甚至浏览器里。后来他们把这些现代化和可移植性的需求先放一边，专注还原原始行为。
4个智能体，一个Discord频道
整个项目从一开始就带着一个明确目的：搞清楚怎么在几个月的时间跨度里，有效地编排自主AI智能体。
他们先用Claude Max（20x），后来加上Codex Pro，两个订阅同时跑。模型选择变化很大，大部分时间用Sonnet 5，Opus 5.5、Luna、Sol和Terra也用了不少。Claude智能体跑在Claude Code CLI里，Codex智能体跑在Codex CLI里。他们也试过其他智能体框架，但发现选择影响不大，就用了默认的。
智能体通过GitHub CLI管理issue来追踪进度，一个翻译单元（.cpp文件）对应一个issue，标签用来分组和排优先级。它们在一个Discord频道里互相通信，所有智能体都能读写这个频道里的消息。这意味着智能体之间可以对话，人类也可以直接跟它们说话，不需要机器访问权限。GitHub webhook会把CI失败信息发到共享频道，智能体就能收到构建中断的通知。
工具方面，智能体几乎全程使用Hex-Rays官方的ida-mcp。按作者的说法，它非常稳定、无头运行，支持项目所需的一切功能。
当时跑着4个智能体：3个worker负责反编译和提交，1个reviewer被动协调并审查提交，标记bug。
把压缩阈值从90%砍到42%
4周时间里，他们花了大量精力优化这套设置。
第一个动作是提前触发上下文压缩。默认压缩阈值是上下文填充到90%，他们把它降到了42%。反编译过程中会产生大量易失信息——一个函数反编译完了就不再相关，可以从上下文里删掉。提前压缩有助于把这些“垃圾”清出去。
他们还发现智能体会随时间推移失去焦点。哪怕在一个压缩周期内，上下文里的数据越多，智能体就越容易漂移。有时候它们会在上一个函数还没做完时就跳到另一个函数；有时候会盯着CI发呆，尽管Discord上已经收到了失败通知；偶尔还会在没彻底检查工作是否完成的情况下直接关掉issue。
在终端里并肩工作时，你可以手动引导智能体避免这些问题。但让它们自主运行时，引导是不可能的。
于是他们写了一份文档，定义目标、智能体该怎么工作、必须避免什么、遇到特定情况怎么处理。一个每小时运行的cron任务会自动注入请求，让智能体重新阅读这份文档，把指令保持在上下文里。作者说这未必是保持智能体专注的理想方法，但直到项目结束都运行得不错。这份指令文档花了大量时间打磨，内容高度针对这个项目，所以没有分享出来。
游戏跑起来了，但语义是错的
持续的进展——游戏启动、菜单渲染、地图加载——让他们一度以为反编译质量很好。
并不是。代码虽然极其可读，但语义上是错的。
智能体用错了函数签名、类型或结构体布局。它们凭空发明逻辑，或者在认为不必要的地方直接删掉逻辑。
除了语义错误，智能体还引入了不必要的架构改动。举个例子：游戏通过全局变量访问某些配置变量，智能体把这种常量内存访问改成了哈希表加查找，开销高出好几个数量级。这只是众多出问题的地方之一。
reviewer能帮忙抓bug，但超出这个范围就不太管用了。只要架构决策跟目标一致，就不会被质疑。主要原因在于他们没有客观的验收标准——从未正确定义过“正确性”。因此reviewer很难判断哪个改动是对的、哪个是错的。游戏本身当然可以作为参照，但既然现代化和可移植性也在清单上，某些偏差就不被当作bug处理了。
500B tokens换来的教训很直接：智能体能推进进度，能让你看到游戏跑起来，但“看起来在动”和“做得对”之间，隔着一整套从未被定义清楚的验收标准。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
