AI 认知观点 VIEWPOINT重要度 62

自主AI智能体如何开发多人游戏世界

Simon Willison · 2026-10-29 · 原题《Building a multiplayer game world with autonomous Fable-class models》 · 原文约 3 分钟 · 阅读原文 ↗

Spawn 用 Fable 模型驱动的智能体群自主开发游戏，每月花费超300万美元代币，实现每小时部署，但作者对高风险软件能否适用存疑。

论证要点

Spawn 是多人游戏环境，玩家用提示词让游戏内智能体 Savi 修改世界；作者实测可造城堡、龙并骑龙飞行。
据 Jacob 称，Spawn 由 Fable 驱动的智能体群自主开发，每月代币成本超300万美元，是工资的30倍。
智能体直接改线上代码并每小时部署，约60%工作源于生产错误、Savi 报的 bug、日志异常或功能请求。
Savi 自己提交 bug，由智能体判断是否修复、不修或需设计决策，通常一小时内交付变更并通知用户。
他们把一小时未部署视为最高级别事故（SEV-0），因为未部署变更会堆积、问题持续更久，且智能体只能记住几小时工作。
故障可30秒内精准回滚，监控告警会唤醒负责智能体，并故意破坏以测试恢复路径。

对实践的启示

对做 AI 应用的人：这种极端自主开发在游戏等低风险领域已跑通，但需极短反馈循环、快速回滚和故意故障测试；高风险场景能否复制仍存疑。

作者承认的反方与局限

作者坦言难以想象这种开发方式适用于出错代价更高的软件，但对游戏似乎效果出奇地好。

原文摘引

we spend 30x payroll on AI tokens

we treat an hour without a ship as a SEV-0, our most severe kind of incident

Astra had gone through our whole product and made the insecure things secure by turning them off.

▸ 展开原文全文（19 段，抓取自 Simon Willison）

29th October 2026 - Link Blog

How I Built the Most AI-Pilled Company in the World. Don't be put off by the clickbait headline, this piece by Jacob Sansbury describing how they are building Spawn is a fascinating exploration of the bleeding edge of what's possible with agentic engineering against frontier models.

Spawn is a massively multiplayer gaming environment where players can use prompts (to the in-game agent, Savi) to modify the game world.

I fired it up on my phone for a few minutes and was able to prompt a castle into existence, then a dragon, then ride the dragon to fly around that castle.

By Jacob's telling, Spawn is now being developed autonomously by a swarm of Fable-powered agents costing over $3 million in tokens per month ("we spend 30x payroll on AI tokens").

Our agents change the live code directly and ship to production hourly, so they read every error, bug report and metric themselves. About 60% of our work starts from a production error, a Savi bug report (Savi is the AI you build games with in Spawn), something odd in our logs, or a feature request.

Savi files bugs herself. When a user hits one, or Savi hits one in the product, she files it. It goes straight to an agent that decides whether it's a real bug to fix, something we won't fix, or intentional design that needs a decision. Usually it becomes a change, delivered to that user within an hour, with a message in the same chat.

This is continuous deployment turned up to 11:

A loop this tight only works if it never stops, so we treat an hour without a ship as a SEV-0, our most severe kind of incident. Unshipped changes pile up, and every problem already in production lasts longer. The feedback slows down too. An agent can only keep a few hours of work in its head, so shipping faster than that actually helps it stay coherent. [...]

We can roll back a broken change in 30 seconds, exactly where it's broken and nowhere else. When a monitor or a log alert fires, it starts or wakes an agent that owns the incident, and we break things on purpose to test that those recovery paths work.

My eyebrows raised at least a dozen times reading this. I have trouble imagining this style of development working on software with higher stakes for when something goes wrong, but for a game this appears to be working surprisingly well.

Jacob says that Fable 5 (and then 5.1) was the model that made this level of autonomy possible. Opus 5.5 doesn't quite hack it for them, and when they tried GPT-6 Astra to apply fixes from a security review everything stopped working:

Every feature had been disabled and marked to be turned on again once the security fixes were done. Astra had gone through our whole product and made the insecure things secure by turning them off.

These kinds of extreme experiments are why I'm excited about game development as a substrate for exploring the edges of what today's coding agents can do.