我如何打造了世界上最具 AI 浓度的公司。别被这个标题党劝退，Jacob Sansbury 的这篇文章描述了他们在如何构建Spawn，这是一次引人入胜的探索，展现了基于前沿模型的智能体工程所能达到的最前沿边界。
Spawn 是一个大型多人在线游戏环境，玩家可以用提示词（发给游戏内智能体 Savi）来修改游戏世界。
我在手机上启动它玩了几分钟，就能用提示词凭空造出一座城堡，然后造出一条龙，再骑着龙绕着那座城堡飞行。
按照 Jacob 的说法，Spawn 现在正由一群由 Fable 驱动的智能体自主开发，每月消耗的 token 成本超过 300 万美元每月（“我们在 AI token 上的花费是人力成本的 30 倍”）。
我们的智能体直接修改线上代码，并每小时发布到生产环境，因此它们会自己阅读每一个错误、缺陷报告和指标。我们大约 60% 的工作都始于一个生产环境错误、一条 Savi 缺陷报告（Savi 是你在 Spawn 中用来构建游戏的 AI）、日志中的某个异常，或者一个功能请求。
Savi 会自己提交缺陷。当用户遇到一个缺陷，或者 Savi 在产品中遇到一个缺陷时，她就会提交它。它会直接交给一个智能体，由该智能体判断这是需要修复的真实缺陷、我们不会修复的问题，还是需要做决策的有意设计。通常它会变成一项变更，在一小时内交付给该用户，并在同一个聊天中附上一条消息。
这就是持续部署拉满到 11 级：
如此紧密的循环只有在永不停止时才有效，因此我们把一小时没有发布视为 SEV-0，即我们最严重的一类事故。未发布的变更会堆积，而生产环境中已有的每个问题都会持续更久。反馈也会变慢。一个智能体脑子里只能同时记住几个小时的工作量，所以比这更快地发布实际上有助于它保持连贯。[...]
我们可以在 30 秒内回滚一个有问题的变更，且精确回滚到出问题的地方，不影响其他任何地方。当监控或日志告警触发时，它会启动或唤醒一个负责该事故的智能体，我们还会故意制造故障来测试这些恢复路径是否有效。
读这篇文章时我至少挑了十几次眉。我很难想象这种开发方式能用在出错代价更高的软件上，但对于一款游戏来说，这似乎运行得惊人地好。
Jacob 说，Fable 5（以及后来的 5.1）是让这种程度的自主性成为可能的模型。Opus 5.5 对他们来说不太够用，而当他们尝试用 GPT-6 Astra 来应用安全审查中的修复时，一切都停止工作了：
每个功能都被禁用了，并被标记为在安全修复完成后重新开启。Astra 遍历了我们的整个产品，通过把不安全的东西关掉来让它们变得安全。
这类极端实验正是我对游戏开发感到兴奋的原因把它作为探索当今编程智能体能力边界的基底。