事件概述

一篇来自 Hacker News 的技术复盘记录了一个颇为特殊的工程案例：将《F-Zero X》的反编译项目 G-Diffuser 原生移植到 Nintendo 3DS，最终发布 v1.0.0。项目由一个人全程主导，用一个长期存活的 Claude 会话做编排，第一阶段由 147 个子代理参与构建，第二阶段投入了更多代理。

根据原文，整个项目分为两个阶段。第一阶段从 2026-08-11 到 09-03，共 24 个日历日、15 个活跃工作日，目标是把游戏跑在 New 3DS 上，达到 60fps 并支持立体 3D。第二阶段从 2026-09-07 到 10-19，共 43 天，原本不在计划内，后来增加了 Old 3DS 支持、原生渲染器和 64DD Expansion Kit。最终从一个源代码树产出三个主机构建：Old 3DS、New 3DS，以及带 Expansion Kit 的 New 3DS 版本。

性能方面，第一阶段结束时在 New 3DS 实机上跑完整 Grand Prix，帧率中位数为 59.6fps，第 10 百分位为 51.4fps，53% 的帧达到 60fps 上限。作为对比，最早的模拟器比赛只有 12–20fps，首次实机运行在 48–50fps。第二阶段则把 3D 60fps 扩展到了 Old 3DS 的多数 Grand Prix 赛道，但最重的赛道（Silence、Sand Ocean）仍可能触发帧跳过保护，降到稳定的 30fps。

成本数据也相当具体：仅第一阶段就消耗了 3.17B tokens，按公开 API 列表价格计算为 4,974 美元，涉及 250 个触及 3DS 移植的提交，以及 port/3ds 下 15,039 行代码和 48 个纯增量补丁。原文明确说明，这些硬件数字和成本数字测量截至 2026-09-03，并未针对 v1.0.0 重新跑过；第二阶段的开销在提供的材料中未说明。

关键技术点

反编译、运行时与移植层

项目栈由三层构成。底层是未改动的 F-Zero X 反编译项目（inspectredc/fzerox）加上一组补丁；中间是 N64 运行时 libultraship（Kenix3），同样保持上游未改动，只加了一个 13 行的 newlib 修复以便在 devkitARM 上构建；上层是 port/3ds，包含 citro3d 渲染后端、立体 3D、音频、输入、菜单、生命周期、渲染线程、性能分析器和打包逻辑。所有菜单和非比赛画面仍由 libultraship 绘制。

三个发布构建都从 SD 卡读取预烘焙的资源归档，游戏本身不附带 ROM 或磁盘镜像；Expansion Kit 需要用户自备磁盘镜像。

原生渲染器：围绕指令缓存重写

第二阶段最有技术含量的部分，是原生渲染器的引入。原文提到，团队最初构建了一个 retained-mode 渲染器，在模拟器里表现很好，但在实机上几乎没有提升。随后通过硬件性能计数器发现，真正的瓶颈是指令缓存未命中，而不是指令数量。于是渲染器围绕缓存重新设计：为每个比赛类别写一个很小的循环，并按照 16KB 指令缓存的大小来裁剪。这样做的结果是，2D Grand Prix 比赛的中位帧时间降到 16.5ms。

这一发现直接改变了 Old 3DS 的可行性判断。在此之前，Old 3DS 里程碑一度被放弃；之后通过并行代理把构建塞进 64MB 应用区域：RDRAM arena 减半、音频改为流式而非常驻、纹理上传设置上限。2026-09-29 首次在真实 Old 3DS 上测试时，面向 New 3DS 的 16MiB RDRAM 构建在启动时崩溃，而按内存配额构建的 -DGDX_3DS_O3DS=ON 配置成功启动并跑出约 10fps。随后通过缩小音频锁、帧跳过和原生渲染器，逐步把性能推上去。

立体 3D 与帧节奏

New 3DS 构建保留了第一阶段达到的原生 60fps 帧节奏；Old 3DS 则通过不同路径达到相近结果。v1.0.0 在无 ini 配置时，两个构建都默认使用原生渲染器，即 [perf] preset = auto。New 3DS 第一阶段使用的渲染线程/逐绘制立体路径仍然编译在内，可通过显式 ini 启用，但不再是默认路径。

3D 方面，原文提到使用逐眼重新提交和独立的 swap-pacing 模式，在多数 Grand Prix 赛道上达到 59–60fps。Old 3DS 的最重赛道仍可能触发帧跳过，稳定在 30fps。

代理工作流与成本口径

原文专门设有 “Agentic workflow” 和 “Cost” 页面。第一阶段横跨 24 个日历日，但只有 15 个活跃日，期间因为每周计划额度耗尽暂停了三次。第二阶段写了 199 条内部进度笔记。成本页面明确说明了哪些被计价、哪些没有；第一阶段的 token 和成本数字使用 Fable 的公开列表价格（10/50 美元每百万 token，含 1 小时缓存写入）计算。原文未说明第二阶段对应的 token 与费用。

对数据科学或 AI Agent 落地的意义

这个案例对 AI Agent 工程化的启发，主要不在“代理数量”，而在工程纪律。

第一，长时程任务需要可观测的中间状态。项目不是让代理自由发挥，而是按阶段拆目标：先跑起来，再上实机，再做产品级，再攻生命周期和性能，最后做多核。每个阶段都有明确的性能指标和日期，这使代理的输出可以被检验，而不是只能凭感觉判断“好像做完了”。

第二，性能优化必须让硬件数据说话。retained-mode 渲染器在模拟器里赢，在实机上不赢；硬件计数器指出指令缓存才是瓶颈，才促成了原生渲染器的重写。对数据科学和 Agent 落地而言，这意味着评估环境要尽量接近真实生产环境，离线 benchmark 的优势不能直接外推。代理可以生成大量候选方案，但取舍必须依赖真实测量。

第三，人负责方向，代理负责执行。原文中有一个关键细节：pose-replay 回退方案已经构建并可用，但被搁置，原因是项目主导者坚持“我们应该追求真正的 60fps”。这类目标设定和价值判断，目前仍需要人来完成。代理适合并行探索、实现和验证，不适合替代产品方向决策。

第四，成本需要被显式披露。3.17B tokens、4,974 美元、250 个提交、15,039 行代码，这些数字让“一个 Claude 会话加 147 个子代理”从叙事变成了可比较的工程账本。对计划把 Agent 用于大型代码库改造的团队来说，这种成本透明度比单纯的 demo 更有参考价值。

我的技术点评

这是一篇质量很高的工程复盘，优点在于它没有把“AI 代理完成移植”包装成魔法。相反，它给出了阶段划分、性能表格、失败方案和被搁置的方案，也明确标注了数字的时效性和成本口径。尤其是“模拟器里有效、实机上无效”的 retained-mode 渲染器，以及“指令数不是瓶颈、指令缓存才是”的转折，都是真实系统优化中常见的反直觉时刻，值得做性能工程的人细读。

但也要看到边界。首先，这是一个单一案例，原文没有提供与其他移植项目的对照，因此不能据此推断代理工作流的普遍效率。其次，成本数字只覆盖第一阶段，第二阶段 43 天的开销未说明；如果要做完整的经济性判断，这个缺口很关键。再次，项目依赖特定的反编译基础、libultraship 运行时和 devkitARM 工具链，换一个代码库或平台，代理编排的难度可能完全不同。最后，法律与分发边界在原文中被明确处理：不附带 ROM 或磁盘镜像，Expansion Kit 需要用户自备镜像，README 含法律声明。这一点在游戏移植类项目中不可忽略。

总体而言，这个案例更值得学习的不是“147 个子代理”这个数字，而是背后的方法：用真实硬件指标驱动决策，用阶段目标约束代理输出，用人守住方向，用成本账本约束叙事。对 AI Agent 落地来说，这比任何“全自动”口号都更有参考价值。

原文链接

  • 原文：https://