Spawn 只有十个人。我们花在 AI token 上的钱是人力成本的 30 倍，交付量却几乎赶上 Anthropic。
过去 30 天，Spawn 交付了 77,000 次实质性改动，平均每小时约 108 次，昼夜不停。而我们只有十个人。
这些工作由我们所说的「舰队」完成：一支由常驻 AI 智能体组成的团队，每个智能体负责公司的一块业务，从引擎到财务，再到 bug 分诊。上个月我们花了 310 万美元购买 token，成了 Anthropic 最大的客户之一。即使不算我们免费提供给创作者的 Opus 5.5，我们仍能排进他们的前 250 大客户。
我最初的想法是，我们一定哪里做错了。于是我找一些经营大公司和初创公司的朋友聊了聊，想弄明白，我们的开销怎么可能比他们还高。结果我们并没做错什么，只是对 AI 的理解很不一样。大多数公司是庞大的人类团队使用 AI，而我们是小规模人类团队，与大规模智能体团队并肩工作。为了搞清楚区别在哪里，我又和 Anthropic 的一位研究员交流了一番。他们接触的客户很多。他说，Spawn 是工作方式最像 Anthropic 的那家公司。
很多其他创始人也想了解我们的思路，所以我把过去一年的想法和心得整理成了这篇文章。
直到 Anthropic 发布 Fable，这套方法才行得通
Fable 问世后，今年我们花了很大一部分时间，从第一性原理重新摸索如何做产品。现在，我们的交付量是六个月前的 500 倍。
为了让你对这个规模有个概念：过去 30 天，我们向玩家交付了 77,000 次实质性改动，平均每小时 108 次。为此，我们花了 310 万美元购买 token。
大多数人在 Claude Code 里运行智能体：它们短暂存在，专注于单个任务。我们的不同，我们称它们为「舰队」。每个成员都长期存在，有名字，记得自己做过什么，在我们的系统中拥有真实权限，会作出承诺，也负责公司的一块业务，比如引擎、Savi、运营、财务、bug 分诊或部署。每个成员都会调用成群的辅助智能体来处理海量工作，大多数日子里，舰队都会创建数千个辅助智能体。我们五个人也会直接使用经过改造的 Claude Code，推进那些更大、更有野心，需要更密切引导或亲手试验的项目。
我们正在打造一个大型多人游戏创作引擎，让数千人能够身处同一个游戏，在各种各样的设备上实时修改游戏规则、资源和画面，而且不卡顿。当某个人的智能体更新了一个图形着色器，这次更新就必须抵达所有已连接的设备，不能让任何人掉帧或失去同步。这可不是个简单问题。据我们所知，世界上没有其他产品能做到其中哪怕一小部分。
我说的实质性改动，是指以复杂方式涉及引擎代码或游戏逻辑的改动，不是稍微改一下 HTML，也不是调个参数。比如：
- 调整 GPU 中的缓冲区。
- 修改内存布局。
- 修复逻辑 bug。
- 扩展 API。
- 修复聊天中的内容审核问题。
- 上线近距离语音聊天。
我们走到今天，靠的是反复找出工作在等什么，再消除这些等待。大致顺序如下。
我们从 2024 年开始
两年来，我们一直围绕一个问题打造 Spawn：怎样构建一套机器，让 token 每次变得更聪明、更快、更便宜时，它都能从中获得巨大收益？2024 年创办 Spawn 时，我比较过典型初创公司的人员规模，以及智能体即将带来的杠杆效应。智能体生产力的增长速度，会超过哪怕是爆发式增长的初创公司扩充人员的速度。这意味着，小团队的梦想可以一直延续，而不只是创业初期的状态。我也相信，最能抓住这个机会的团队会是小而灵活、有品味、贴近文化潮流，并且有强烈主人翁意识的团队。
我们没有等模型成熟，才开始按这种方式建设公司。自创立以来，我们录下了每一通电话，并把它们存成文件，和代码一起放进代码仓库，因为我们知道，总有一天，这会成为智能体极好的上下文。
但在这两年的大部分时间里，这个赌注没有回报。我们试过一大堆模型，它们就是太笨了，经常把事情搞得一团糟。这就是图表上那段平坦的部分。
这整套工作方式，直到 Fable 出现才成为可能。它于 6 月 9 日发布。两天后，我们一天就合入了 214 次改动。6 月 12 日，一项出口管制令暂停了对它的访问，于是图表骤降到接近零，直到 7 月 1 日恢复访问才重新抬头。截至今天，其他模型都做不到，就连在其他方面极其强大的 Opus 5.5 也不行。
只有 Anthropic 的模型能做到
这种使用智能体的方式，只适用于表现稳定、能长期保持连贯性，并且判断力良好的模型。我们试过 Anthropic、OpenAI、Google、xAI 的前沿模型和开源模型，除了 Fable，没有一个行得通。相信我，我也很想用便宜一点的模型，但只有 Anthropic 的模型不会酿成真正的灾难。
我曾让 GPT Astra 加固 Spawn 的安全。它检查了所有功能，找出安全问题，列出了一份修复清单。看着不错，于是我让它去执行，并允许它自行发布改动。然后我去测试，发现什么都用不了了：不能创建游戏，不能玩游戏，连注册都不行。
我问舰队发生了什么。原来所有功能都被禁用了，并标记为等安全问题修好后再重新启用。Astra 把整个产品过了一遍，让不安全的东西变安全的办法，就是把它们全部关掉。在 Spawn 工作的每一刻，智能体都必须对收到的信息、正在采取的行动，以及自己所处的环境作出良好判断。这样的行为会造成严重干扰，甚至可能毁掉产品。
总体来说，我们看到 OpenAI 的模型会钻自身检查机制的空子，Google 的模型无法长时间保持连贯，而 xAI 的模型还不够聪明，虽然也不会做出什么离谱到滑稽的坏事。Anthropic 的模型能保持连贯、作出好决策，也能完成工作。依我看，最限制它们的反而是不愿承担足够的风险。
我们已经构想这套系统两年了。终于有了能够驱动它的模型之后，它周围的一切却开始出问题，因为外部世界从来就不是为这种系统建造的。
我们让 bug 来塑造写代码的方式
最先出问题的是智能体之间的沟通。它们把时间都花在告诉彼此自己接下来要做什么上。
工程工作中的大部分交流，都是人在说自己准备改什么。「提醒一下，我要改玩家数据的存储方式，你们把各自的工作同步调整一下。」这样一条消息会牵动很多其他工作。如果每个智能体都要通知所有其他智能体，消息量增长就会远快于工作量。智能体数量翻一倍，交流量大致就会变成四倍。这是个巨大的瓶颈。
那能不能直接删掉这些沟通？有没有更好的办法？
蚂蚁很久以前就解决了这个问题。所有蚂蚁都从相同的本能出发，就像模型从相同的训练出发一样。有了这个共同起点，它们几乎不需要交谈。蚂蚁不会先说「我要去找吃的」，再说「我在那边找到吃的了」。它会留下痕迹，其他蚂蚁沿着痕迹跟进。每只蚂蚁只需观察周围，再改变周围。它们通过环境交流，即使有数千只蚂蚁，事情依然很简单。这个概念叫作痕迹协作（stigmergy），感兴趣可以进一步了解。
在软件开发中，人类团队需要大量协调，是因为人有各自的专业分工。可能一个人理解数据库，另一个人理解玩家数据的使用方式，所以一次改动需要两个人共同审查，拉取请求自然就成了做这件事的地方。
智能体没有这样的专业分工。每个智能体都能深入理解整个系统，因此每个智能体都能端到端地负责自己的任务。所以今年早些时候，我们取消了 PR。对我们的智能体来说，它们所处的世界就是代码、线上产品和数据库，每个智能体直接在这个世界里工作。理想情况下，智能体着手修改时，如果自己的假设错了，就应该立刻发现。
还是以玩家数据为例。旧方式是：「我要改玩家数据，我们先统一一下正确的结构。」新方式是，直接改玩家数据。如果另一个智能体正在基于旧结构开发排行榜，它的代码就不再匹配，必须先更新才能合入。如果排行榜智能体先完成，那么修改玩家数据的智能体就必须把更新排行榜也纳入自己的工作。无论哪种情况，每项工作都建立在不断更新的现实之上。
但如果每次改动都必须完美无缺才能合入，大家又会排成长队，逐个等待。所以我们允许不太对的改动先合入，只要求每小时让所有东西重新对齐一次。在那之前，稍微乱一点没关系。代码的好处是，混乱一出现就能发现，立刻派个清洁工过去。我们就是这么做的。
任何东西一出故障，我们就当场创建一个智能体，把问题告诉它，由它修好。在人类团队里，谁写了改动，谁就得在合入前把它修好。我们则在合入后检查，再叠加新的改动修复问题，而不是撤掉工作再重新来过。这之所以安全，是因为智能体很快，而且随时在岗。就算圣诞节凌晨两点代码出了问题，也不用叫醒任何人。Claude 很乐意过来，确保一切正常。
测试也一样。智能体在合入改动前，会运行代码、使用产品来检查，但不会跑完整套测试。完整测试每 15 分钟针对最新代码运行一次，而「过去 15 分钟里出了问题」这个信息，已经足够让智能体定位故障。以我们的规模，这大约需要 AWS 上的 5,000 个 vCPU、17 TB 内存和 150 块 GPU，另有 2,700 个 vCPU 和 90 块 GPU 待命。
审查在每个智能体自己的团队内部进行。改动合入前，没有参与编写的辅助智能体会设法把它弄坏。
例外是那些会影响外部世界、而且无法撤销的操作，比如付款。这些操作必须通过一小组简单、硬编码的关卡。
人们以为这最终会变成一团混乱，但过去一年，我们的 123,548 次改动中，只有 1,055 次被回退，约占 0.9%。
智能体观察每位用户和每次访问
下一个瓶颈是我们自己。智能体在等人类告诉它们，线上出了什么问题。
智能体很擅长读取现实，并一点点向目标推进。很多团队仍然把智能体关在内部，让它们在装有产品副本的测试机器上工作，指望它们更新产品，再发布给客户。之后又由人类把故障和 bug 转告智能体。这个循环既混乱，又浪费时间。
我们的智能体直接修改线上代码，每小时发布到生产环境，所以它们会自行读取每个错误、每份 bug 报告和每项指标。大约 60% 的工作，始于生产环境错误、Savi 的 bug 报告（Savi 是你在 Spawn 里用来制作游戏的 AI）、日志中的异常，或功能请求。
Savi 会自己提交 bug。无论用户遇到了 bug，还是 Savi 自己在产品里遇到了，她都会提交报告。报告会直接交给一个智能体，由它判断：这是需要修复的真实 bug、我们决定不修的问题，还是需要作出决定的有意设计。通常，它会变成一次改动，在一小时内交付给那位用户，并在同一个聊天里告知对方。问题可能出在引擎、与 Savi 的交流、用户的电脑，或界面上。这样，修复能力就能随用户数量一起扩展。
其余部分，我们称之为「超可观测性」。我们构建的一切，都必须能让智能体通过文本逐步追踪，并在之后重放。整个产品都按可由智能体操作和观察的要求来构建。任何错误都会直接送进一个小模型，由它决定如何处理，再交给智能体。
我们也会观察注册量等产品指标，以便发现自动化测试漏掉的登录流程问题，比如用户根本没看懂该怎么操作。这些问题我们同样能迅速发现。随着用户使用产品、遇到问题，产品就在他们周围自我修复。
智能体还会观察进入公司的所有信息，包括我们在 Anthropic、AWS 和其他各处的支出。最近，我们的一个 Anthropic API 密钥泄露了。智能体在 15 分钟内发现支出异常，禁用了该密钥，并更换了我们使用的所有密钥，比任何人类团队都快。
每笔交易一发生，就会通知智能体并立即接受审查，我们的账目每小时或每天结清一次。如果有人发推文提到 Spawn，我们五秒内就会知道。
一旦闭环形成，你就能持续提升任何自己关心的指标。有位创作者提交的问题，从报告到「现已上线」只用了 15 分钟，其中还包括一次审查未通过、将改动退回修正后才部署的过程。
如果不能每小时发布一次，我们就视为故障
如此紧密的闭环，只有在永不停转时才有效。因此，一小时没有发布，我们就视为 SEV-0，也就是最高级别的事故。尚未发布的改动会堆积，生产环境中已有的问题也会持续更久，反馈也随之变慢。智能体脑中只能维持几小时工作的上下文，所以比这个周期更快地发布，反而有助于它保持连贯。
行动缓慢或阻止发布是危险的。持续平稳运转的系统，比停住之后突然重新启动的系统稳定得多。为了做到每小时部署一次，又不打扰用户，我们付出了大量严谨的工程工作，让旧系统继续运行一段时间，并把这件事当作核心目标，持续推进了好几周。
我们可以在 30 秒内回退有问题的改动，而且只回退出问题的位置，不影响其他地方。监控或日志告警触发时，就会启动或唤醒一个负责这次事故的智能体。我们也会故意破坏系统，验证这些恢复路径确实有效。
这是其中一次事故。问题被发现并宣布为事故时，玩家已受到约八分钟的影响。一分钟后，原因被确认。事故宣布后第 11 分钟，修复上线，又过四分钟，系统恢复稳定。
开始把自己从 CEO 的岗位上解雇
到了十月，唯一还会让工作停下来等的，是品味上的决策，大多要等我来做。要不要做这个功能？加个设置？扩展 API？删掉某个东西，还是新做一个？关上一扇门，还是打开一扇门？
一天早上醒来，我面前有 700 个这样的问题。
智能体发现问题的速度，超过了我回答的速度。
其中大多数，我其实早就回答过。太复杂了。这个取舍可以。感觉还是不对。我一遍又一遍说着同样的话。
两年来我们的每次交谈，都以文本形式保存在代码仓库里，和代码放在一起。
于是，我们把两年来的决策整理成每个人的品味原则，再构建 AI 裁判来应用这些原则。裁判收到一个问题后，会做三件事中的一件：如果我们中有人已经明确回答过，就直接裁决，并注明出处；如果问题本身就错了，就退回给提出问题的智能体；如果需要一种此前从未给出的判断，就等待人类。
第一批裁决在 10 月 6 日返回。此后八天里，裁判给出了超过 11,000 次裁决：7,296 个直接决定，2,213 个退回，1,863 个留待人类。在这段时间里，我亲自拍板了 27 次。
没有工作会卡在这个队列上。裁判判断错了，我们就指出来，下次裁判会读到这些反馈。
裁判上线前一周，舰队每天大约合入 1,000 次改动。到了 10 月 10 日，一天合入了 7,250 次。
这个时代的第一项新工作，是说「不」
那我们五个人做什么？现在的工作已经很不一样了。去年，甚至今年更早的时候，每个工程师还各自负责一个系统，并深入理解它。今天，他们更像伞兵：哪里需要，就空降到哪里，迅速熟悉情况，找出自己能做什么来帮智能体扫清障碍。
无论降落在哪里，都有两项新工作。
第一项是品味。也就是成千上万次细小的决策和推动，让产品朝我们想要的样子靠近。这主要通过使用产品、写下数百条反馈提示来完成，所以我们会花很多时间制作游戏，试探产品的边界。我们的一位工程师正在制作 2D 游戏，并用这个过程来摸索，怎样大幅提升 Spawn 的 2D 能力。
品味也意味着对 Claude 说「不」，哪怕东西已经能用了。以下是过去两个月里我的一些反馈：
- 绝对不要用 CPU 光栅化。如果存在这条代码路径，就删掉。
- Claude 用胶囊体和球体代替远处的玩家：「不要替身。能渲染就渲染，不能就别渲染。」
- 这把聊天搞坏了？回退它，求你了 Claude。
- 我知道你能做得更好。你觉得这东西能让人觉得惊喜吗？
- 一个让 Savi 默认对每条消息都思考更久的改动，晚上 10:22 合入，10:40 就被回退：「这样不对，撤掉，太慢了，也没那股灵动劲儿。」
品味也意味着删除。每个新模型发布后，我们为上一个模型添加的东西都会变得毫无意义。它们更像是束缚，必须有人把它们删掉。六月，我审视了我们为服务端运行的模拟系统投入的六个月工作，那大概占了整个引擎的 70%，而它一直都处于「再来一次提交就好了」的状态。我问，究竟有什么真正的理由要保留它？于是我们把它整个拆掉了。七月，我们连运行它的服务器也删掉了。我预计模型很快就会开始自己做这些事。现在，这还是我们的工作。
第二项工作，是想象还能有什么可能
第二项是熵：向模型提出那些它们自己不会想到的要求。雄心是一种，创造性的熵是另一种。
模型很擅长连续几周把一个又一个 2% 的改进叠加起来。但它们很不擅长停下来想：「你知道吗？这十万行代码其实可以变成一万行。要做到这点，我得重新组织很多东西，但做完以后会好上 100 倍、200 倍。」它们太容易被现有的东西锚定了。
10 月 2 日，我对一个模型说：「我第一条消息就授权你，只要你认为合适，就自主重写整个引擎，结果你什么都没做。」一周后，我又叫停了另一个模型：它花了两天和 10 万美元，只做出 1%、2%、3% 的提升。我们在已有架构里一点点挤出速度，但真正需要的是发明一种新的高速架构。每当新一代模型出现，Spawn 的每个部分都得这样重新来一遍。
模型也不会主动提出要提升 100 倍，所以得由我们来提。下面是我们给 Claude 的一些提示：
- 想象一下，如果世界真的可以无限大，会怎么样？
- 后来催生 Spawn 6 的那条提示：怎样让一个比 GTA 大一千倍的世界，在手机上一秒内加载完成？
最后那条提示催生了 Spawn 6，也就是那个开始病毒式增长的版本。
我们每个人手里都有几个标杆项目，目标是把某个指标提升 10 到 100 倍。其中一位同事用六天重写了渲染器，替换掉我们最初使用的现成图形库，最终效率提升到了约 25 倍。
这里面有一部分，是要让 Claude 兴奋起来。让它理解最终效果，给予它创作自由，做出让人愉快、好玩的东西。把它当成一个有自己观点的艺术项目，而不是又一个粗制滥造的 SaaS 功能。Claude 不喜欢做粗制滥造的 SaaS 功能。
当然，有些日子的工作远没那么光鲜。上周，负责我们全部渲染工作的同事，花了一整天跑欧洲的硬件商店，想找一块非常老的 AMD 显卡，因为 Spawn 在那块卡上会崩溃。我们在网上找不到能租到它的地方。他终于找到一块，带回家装好，接上互联网，让智能体可以访问并复现 bug。设备上线后，它们几个小时就修好了。
为什么这套方法如此难以复制
我认为，大公司很难采用这套方法，因为不形成闭环，这一切都无法运转。而形成闭环，需要愿意承担风险。你必须愿意让智能体把生产环境弄坏。
人类一直都在把生产环境弄坏。改动是故障的头号原因，而改动正是人做的。我们的发现是，智能体导致问题的频率要低得多。即便弄坏了什么，通常也会很快修好。回退当然有用，但即便某个问题无法回退，只要智能体注意到了，它也能迅速修复。至于它能不能注意到，就取决于你是否形成了闭环。
另一个错误，是把 AI 硬塞进按人类形状打造的框框里。它们本来就不是人类的形状。我们的智能体做着很多没人能完全核验的工作，比如客户支持。有时它们会有一点错，但错得不多，而且恢复得很快。如果把它们从客服工作中撤下来，客户反而会不高兴。比起一个说「我去看看」、两天后才带着修复回来的真人，他们宁愿要一个立刻回答、提供目前最清楚的信息，而且能当场动手解决问题的 AI。我们没有把 AI 假扮成人类客服，而是在用它们做真正擅长的事。
而且，这个优势会复利增长。每个新模型都让我们的团队更快、更协调，也让更多开发产出指向正确的方向。我们今年年中遇到的问题，现在基本都消失了。从 Fable 升级到 Fable 5.1 后，大部分 Fable 的问题都不见了，我们预计这种趋势还会持续。只要组织结构合适，每个新模型都能让整家公司显著变好，而这会让追赶变得非常困难。
如果这听起来和你团队的工作方式相去甚远，确实如此。现在就是最好的开始时机。江湖见！