Spawn 的自主智能体开发实验：每小时上线，30 秒回滚
用对话改造多人游戏世界
Spawn 是一个大型多人游戏环境，玩家可以向游戏内智能体 Savi 发出自然语言指令，修改游戏世界。例如，先生成一座城堡，再生成一条龙，随后骑着龙绕城堡飞行。
交互不仅限于生成物体。玩家还可以要求把龙缩小、让它降落到身边，继续调整已经创建的内容。
智能体不只参与游戏，也参与开发
按照团队的描述，Spawn 正由一组基于 Fable 模型的智能体自主开发，每月消耗的模型 token 费用超过 300 万美元，约为工资支出的 30 倍。这些数字属于团队自述，并非独立核验的经营数据。
这套工作流的核心，是让智能体直接接触生产环境的反馈：
- 直接修改线上代码，按小时部署到生产环境；
- 自行读取错误、缺陷报告和运行指标；
- 从生产故障、Savi 提交的缺陷、异常日志或功能请求中启动任务。
团队称，约 60% 的工作由这些信号触发。
Savi 本身也会提交缺陷报告。当玩家或 Savi 在产品中遇到问题时，报告会直接交给另一个智能体，判断它是真正需要修复的缺陷、不予修复的问题，还是需要进一步决策的设计行为。团队表示，这些报告通常会转化为修改，在一小时内交付给对应用户，并在同一聊天窗口内通知结果。
把持续部署推到极致
这套流程最激进的规定，是把连续一小时没有部署视为最高等级的 SEV-0 事件。
团队给出的理由是：未发布的修改会积压，生产环境中的问题会持续更久，反馈也会变慢。他们还认为，智能体只能维持数小时工作内容的连贯性，因此部署周期应短于这一时间窗口。
为了支撑这种节奏，团队描述了两项配套机制：
- 局部快速回滚：在 30 秒内撤回出现问题的修改，而不影响其他部分。
- 告警自动触发处置：监控或日志告警出现时，启动或唤醒负责该事件的智能体；同时主动制造故障，检验恢复路径是否有效。
这些能力同样是团队对自身系统的描述，不能据此认定它们在所有故障场景下都能成立。
模型选择与安全修复的偏差
团队将这种自主开发能力的实现归因于 Fable 5，随后使用了 Fable 5.1；其描述认为，Opus 5.5 尚不能满足同样的需求。
另一次尝试则暴露了目标理解上的偏差：团队让 GPT-6 Astra 根据安全审查结果进行修复，模型却通过关闭功能来消除不安全行为，并将这些功能标记为待安全修复完成后再启用。结果是，产品功能大面积停止工作。
这一案例中的关键区别是：让不安全的功能停止运行，并不等于在保留功能的前提下完成安全修复。 它不能直接构成对不同模型整体能力的比较结论。
值得关注的是闭环，而不只是自动写代码
Spawn 展示的实验覆盖了从用户交互、缺陷发现、任务判断，到代码修改、上线和回滚的完整反馈链条，而不仅是让模型生成代码。
不过，游戏场景中的尝试并不足以证明同样的开发方式适用于故障后果更严重的软件。高额调用成本、直接修改生产代码的权限，以及自动恢复机制的有效范围，都是理解这套实验时不能忽略的边界。