Theo 的长时间 Agent 实验：验证、算力与成本

Opus 5.5 把我带进了一系列投入惊人的 agent 实验。这不是我平时针对实际项目给出的建议：这些任务可能每条提示词消耗数百美元，并运行数天甚至数周。我分享的是自己的经历，不是建议大家照搬。

我的实验包括用 Rust 实现 TypeScript 的 TS Rust，以及面向 Rust 子集的实验性编译器 Lust，后者旨在加速前者。我在自己的工作负载中观察到大幅提速，但这是具体项目的结果，不能保证适用于所有代码库。

这些项目中的 agent 累计运行了近 4000 小时。我先介绍 Skate 3 Bench：它与我原先通过问题识别滑板动作的基准很不一样。此前我观察到一些模型在公开题目上得分很高，却在未公开题目上表现不佳，因此将部分题目转为私有。

这个新实验运行了约四天，我只发了约 25 条提示词，其中许多只是重启后让它继续。我估计它消耗了超过 120 亿个 token，按 API 价格计算接近 5000 美元。它不再只是识别动作，而是构建了一个受 EA《Skate》启发的浏览器小游戏。

Claude 制作了基于 Three.js 的引擎、滑板场和手柄动作系统。动作由右摇杆的操作决定，而不是按一个跳跃键。这个游戏可以玩，我认为效果出乎意料地像样，但动画等细节仍有缺陷。

直接要求模型制作一个完美复刻版，不会得到这样的结果。另一个项目尝试根据反编译结果重建《Skate 3》；我的实验则从头构建另一款游戏。共同思路是让 agent 能反复改进，并衡量改进效果。

我用井字棋解释可验证奖励：训练系统可以判断某一步是否获胜，再奖励成功的行为。我把过程简化为两部分：模型从训练数据获得知识，并通过后续训练学习有用的行为，例如使用工具和验证假设。

编译器测试是更贴近实际的例子：给定 TypeScript 输入、预期 JavaScript 输出和诊断信息，程序可以判断成功或失败。带可验证奖励的强化学习在训练中使用可检查的结果；我的 agent 工作流借用了验证思路，但并没有重新训练模型。

对于 TS Rust，我给 agent 一些真实项目和固定版本的官方 TypeScript，然后比较输出与错误信息。我还故意引入错误，检查移植版本能否检测到。已有案例通过后，我就可以保留验证，同时加入可衡量的性能目标。

第一个可运行版本比官方 Go 实现慢，所以我要求 agent 在维持验证通过的同时，持续优化到两倍速度。明确的输入、输出和性能测量给了它具体方向；不过，通过选定测试并不证明所有情况下都完全等价。

游戏更难验证。我的目标描述了小型滑板场、手柄输入、右摇杆动作机制、镜头行为，以及与原游戏相近的视觉效果。我要求 agent 先完成玩法，并在适合时使用 Blender 制作模型和动画。

后来，我让它在特定场景截图，与原游戏画面比较，再让一组模型评判图片并给出下一轮反馈。我很惊讶这个并不完美的替代指标竟然能产生这样的结果；截图相似并不等于玩法优秀。

反馈循环也可能在错误细节上过度优化。我估计它花了约 800 美元的 token 让天空盒更相似。由于最初对照的是《Skate 3》，它不断把画面调亮；于是我把参考改成自己更喜欢其视觉风格的第一代《Skate》。

我的第一步是选择一个想要实现、而且足够繁琐、适合 agent 反复迭代的目标。人可能不愿做的大规模移植，如果能验证进展，就可能适合这种方式。但目标本身仍须值得投入，繁琐本身并不代表价值。

成本非常惊人。我估计 TS Rust 的用量按 API 价格折算约为 3.8 万美元，在我的设置中相当于约 500 至 800 美元的订阅用量；算力费用另计。这些都是特定套餐和使用方式下的个人估算，并不意味着额度无限，也不能当作通用价格对比。

最重要的一步是定义验证方式。TS Rust 可以比较编译器输出和诊断信息，包括人为引入的错误。对于较难客观衡量的项目，也可以让另一个 agent 评价结果；但检查方式越贴近真正想要的结果，循环就越有用。

接下来要为 agent 提供所需工具。浏览器游戏可能需要图形环境、Blender、浏览器和足够的算力；随着任务和并行 agent 数量变化，需求也会改变。如果无法运行相关检查，即便定义了验证方式，工作仍会被卡住。

TS Rust 暴露了算力瓶颈。我把多台本地电脑和两台 VPS 接入工作流，让 agent 通过 SSH 执行构建和检查。但它们仍经常排队等待资源，单次构建也可能耗时很长。

随后我使用 Blacksmith 承担部分任务。Blacksmith 是赞助商，我也一直用它做 CI；我为 TS Rust 测试花了超过 2000 美元算力费，远高于另计的 CI 账单。我不建议认为 CI 平台天然适合所有交互式 agent 循环。

按我的统计，把工作转到云端任务后，一次 agent 运行累计等待算力的时间从超过 12 小时降到约 1.2 小时。不过，构建本身仍需要 20 至 40 分钟。这个剩余瓶颈催生了 Lust 实验。

另一项对我有帮助的服务是 Boat，它可以按需创建临时虚拟机。我非常喜欢它，甚至投资了这家公司，因此读者需要了解这层财务关系。它对我的吸引力在于：可以为 agent 灵活提供算力，而不必一直按峰值准备资源。

我演示了用 CLI 创建沙箱、通过 SSH 连接并打开 Linux 桌面。套餐限制并发沙箱数量和启动次数，实际使用也另行计费。我从每月 20 美元的套餐逐步升到 100 和 500 美元；这是拍摄时我描述的价格与条款。

快照尤其有用：agent 可以先克隆并构建一次仓库，保存环境，之后从这个快照启动新机器进行测试。多个子 agent 需要独立算力时，这能避免重复大量设置。

改用之前，共享构建机只有四个工作槽位，负载下检查流程需要 40 至 70 分钟。使用多台 Boat 机器后，我展示的对比显示检查时间中位数约为 353 秒，每日合入的变更约为此前三倍。这是我的项目观察，不是受控的产品基准测试。

我把这些机器用于波动较大、临时性的工作，而不是用来承载面向用户的生产应用。agent 的需求可能大幅变化，弹性容量可以减少等待，也不必为了所有可能的峰值购买足够多的自有硬件。

下一步是询问 agent 什么在阻碍它们。我让一个会话持续追求目标，另一个定期检查历史和瓶颈。过多 Rust 构建导致机器崩溃时，agent 建立了队列；接着我询问如何缓解排队，并提供了更多算力。

提供工具和询问瓶颈是一个循环，而不是一次性的设置。随着 agent 推进，限制资源可能发生变化。消除一个瓶颈也可能提高 token 消耗，因此我能运行多少工作，同时取决于算力和订阅额度。

有时瓶颈本身会变成一个新项目。Lust 的出现就是因为 TS Rust 编译太慢。它只支持 Rust 的一部分，并高度针对这个工作负载；我不认为它能在任意应用上普遍替代 Cargo。

展示的例子中，某个 Linux 发布构建用 Cargo 约需 17 分钟，而 Lust 在磁盘预热后约需 12 秒。我给 agent 的目标是大幅加速构建，并让产物性能差距控制在 20% 以内；它报告称已接近目标。两个工具生成的二进制不同，有限测试仍需要仔细验证。

我觉得令人兴奋的是，我们依赖的工具也可以重新审视和重建。我预计模型成本会随时间下降，但这是我的预测，不是保证，而且算力仍有真实成本。尽管如此，学习设计反馈循环，可能在这些极端实验之外也有价值。

我不建议大家现在都用这种方式构建项目。尽管我学到了很多，也乐在其中，但过程昂贵、混乱且非常耗精力。我原本只是想在 isolate 中运行 TypeScript 环境，最后却走到了编译器和操作系统；这些取舍是否值得，读者应自行判断。

即使你负担不起这些实验，或者不想经历同样的混乱，我也希望你能从中获得乐趣。对我来说，有意思的收获是：可验证的目标、合适的工具和对瓶颈的持续关注，可以让 agent 在一条提示词之后继续工作很长时间。