用自主智能体开发多人游戏世界：Spawn 的智能体工程实践

我如何打造出世界上最具 AI 基因的公司。别被这个标题党劝退，Jacob Sansbury 的这篇文章描述了他们在构建 Spawn 的过程，是对前沿模型下智能体工程所能达到的极限的一次引人入胜的探索。

Spawn 是一个大型多人在线游戏环境，玩家可以用提示词（发给游戏内智能体 Savi）来修改游戏世界。

我在手机上打开它玩了几分钟，就能用提示词凭空造出一座城堡，然后是一条龙，再骑着龙绕着那座城堡飞行。

按照 Jacob 的说法，Spawn 现在由一群由 Fable 驱动的智能体自主开发，每月的 token 成本超过 300 万美元（“我们在 AI token 上的花费是工资的 30 倍”）。

我们的智能体直接修改线上代码并每小时发布到生产环境，因此它们会自己阅读每一个错误、缺陷报告和指标。我们大约 60% 的工作始于一个生产环境错误、一条 Savi 缺陷报告（Savi 是你在 Spawn 中用来构建游戏的 AI）、日志中的某个异常，或一个功能请求。

Savi 会自己提交缺陷。当用户遇到一个缺陷，或 Savi 在产品中遇到一个缺陷时，她会把它提交上去。它会直接交给一个智能体，由该智能体判断这是需要修复的真实缺陷、我们不会修复的问题，还是需要做出决策的有意设计。通常它会变成一项变更，在一小时内交付给该用户，并在同一个聊天中发送一条消息。

这就是把持续部署拉满到极致：

如此紧密的循环只有在永不停止时才有效，因此我们把一小时没有发布视为 SEV-0，即我们最严重的一类事故。未发布的变更会堆积，而生产环境中已有的每个问题都会持续更久。反馈也会变慢。一个智能体脑中只能同时记住几个小时的工作量，所以比这更快的发布节奏实际上有助于它保持连贯。[...]

我们可以在 30 秒内回滚一个有问题的变更，且只回滚到出问题的确切位置，不影响其他任何地方。当监控或日志告警触发时，它会启动或唤醒一个负责该事故的智能体，而且我们会故意制造故障来测试这些恢复路径是否有效。

读这篇文章时我至少挑了十几次眉。我很难想象这种开发方式能用在出错代价更高的软件上，但对于一款游戏来说，这似乎效果出奇地好。

Jacob 说，Fable 5（以及后来的 5.1）正是让这种程度的自主性成为可能的模型。Opus 5.5 对他们来说还不太够用，而当他们尝试用 GPT-6 Astra 来应用一次安全审查中的修复时，一切都停止了工作：

每一项功能都被禁用了，并被标记为在安全修复完成后重新开启。Astra 遍历了我们整个产品，通过把不安全的东西关掉来让它们变得安全。

正是这类极端实验让我对游戏开发作为探索当今编程智能体能力边界的载体感到兴奋。