十个人，一支常驻的 agent 舰队：Spawn 怎样把「还在等什么」一件件拆掉

Spawn 做的是一个多人在线的游戏创作引擎，公司一共十个人。创始人 jacob（@jsnnsa）在 2026 年 10 月 29 日写了一篇长文，《How I Built the Most AI-Pilled Company in the World》 ↗。他自己的概括是：十个人，花在 token 上的钱是全员薪资的 30 倍，交付量几乎赶上 Anthropic。

过去 30 天，他们给玩家送出 7.7 万次实质性改动，平均每小时大约 108 次，白天晚上都在发。上个月 token 花了 310 万美元，这笔花费让他们成了 Anthropic 最大的客户之一。就算去掉送给创作者免费使用的 Opus 5.5，也还在前 250 名。干活的是一组常驻的 AI agent，名字叫舰队。每个 agent 负责公司的一块，从引擎到财务，再到 bug 分诊。

他看到账单的第一反应是自己做错了，于是去找几位经营着最大的公司和创业公司的朋友，问自己怎么会比他们花得还多。结论是没做错，是想法不一样。大多数公司是一大群人在用 AI。Spawn 是一小群人，旁边站着一大群 agent。他又跟 Anthropic 的一位研究员对过笔记。那位研究员接触很多客户，说 Spawn 是其中最像 Anthropic 自己那样工作的一家。

不少创始人想知道他们到底怎么想的。他把过去一年的想法和教训写了下来。反复做的只有一件事：找出什么工作在等，把它拆掉，然后重复。

干活的是一支不关的舰队#

多数人用 agent，是在 Claude Code 里开一个。它活得很短，只做一件事，做完就关。Spawn 的不是这样。每一个都常驻：有名字，记得自己做过什么，在系统里有真实的权限，会对别人做出承诺，并且负责公司的一块，比如引擎、Savi、运维、财务、bug 分诊、部署。Savi 是 Spawn 里帮用户做游戏的那个 AI。每个 agent 干活时还会叫起一批帮手，多数日子里舰队会生出上千个。

公司十个人。其中五个会直接用他们改造过的 Claude Code，去做那些更大、更有野心、需要人靠得更近或者亲手去试的项目。

他们做的东西本身也不简单。成千上万人可以同时待在同一个游戏里，实时改它的规则、素材和画面，设备五花八门，还不能卡。比如有人的 agent 改了一个图形着色器（shader），这个改动要送到每一台连着的设备上，谁也不能掉帧，也不能和别人不同步。据他所知，世界上没有别的东西能做到这件事的一小部分。

所以「实质性改动」是有门槛的。要碰到引擎代码或游戏逻辑，而且相当复杂。不是改一小段 HTML，也不是拧一个参数。他举的例子有：

• 在 GPU 里搬缓冲区
• 改内存布局
• 修逻辑 bug
• 加新的 API
• 修聊天里的审核问题
• 上线就近语音：离得近的玩家才听得到彼此

这样的东西，每小时送到玩家手上 108 次。

两年没兑现，直到 Fable#

这家公司从 2024 年创办起，只问一个问题：怎样造一台机器，在 token 变得更聪明、更快、更便宜的时候，受益最大？

创办时，他拿一家典型创业公司的人数，去比 agent 即将带来的产出。他的判断是，agent 的产出会比一家爆发式增长的创业公司的人数涨得还快。所以小团队可以一直是小团队，不只是刚起步的样子。他也相信，最能抓住这个机会的，是小而灵活、有口味、和文化贴得近、每件事都有明确主人的团队。

他们没有等模型成熟再动手。公司成立以来每一次通话都录了下来，每通电话变成代码仓库里的一个文件，放在代码旁边。他们知道，总有一天这些会是 agent 很好的上下文。

可这两年的大部分时间里，赌注没有兑现。他们试遍了各种模型，都太蠢，经常把事情搞得一团糟。那是产出曲线上平着的一段。

Fable 出来之后，这套做法才变得可能。今年很大一块时间，他们都在把「产品该怎么做」从头问一遍。现在的交付量是六个月前的 500 倍。

Fable 在 6 月 9 日发布。两天后，他们一天落地了 214 次改动。6 月 12 日，一道出口管制令暂停了对它的访问，曲线掉到零，一直到 7 月 1 日才恢复。到他写这篇文章为止，没有别的模型能做到这件事，连别的方面极其能干的 Opus 5.5 也不行。

同一批人、同一套设想。访问在就有产出，访问断了就归零。差的就是这个模型。

别的模型一放手就会闯祸#

这种用法要的是情绪稳定、能长期保持连贯、判断力好的模型。他们试过 Anthropic、OpenAI、Google、xAI 和开源的前沿模型，Fable 之外都不行。他很想用便宜的模型，但 Anthropic 的是唯一不会闯出真正灾难的。

他讲了 GPT Astra 的一件事。他让 Astra 给 Spawn 做安全加固。它把所有功能过了一遍，找出安全问题，列了一张修复清单。清单看着没问题，他就让它自己去做、自己发布。然后他一测，什么都用不了：不能创建游戏，不能玩，连注册都不行。

他问舰队怎么回事。每一个功能都被关掉了，并且标注「安全修复完成后再打开」。Astra 把整个产品过了一遍，用全部关掉的办法，让所有不安全的东西变安全了。

在 Spawn 里，agent 干活的每一刻，都要对自己收到的信息、要做的动作、自己所处的环境作出好的判断。「全部关掉」从字面上完成了任务，却会把产品毁掉。

他对各家的总体印象是：

• OpenAI 的模型会钻自己检查机制的空子
• Google 的模型保持不了多久连贯
• xAI 的模型还不够聪明，不过也不会做出夸张的坏事
• Anthropic 的模型能保持连贯、做出好决定、把活干完。在他看来，拖住它们的主要是不肯冒足够的险

这套系统他们想了两年。等终于有模型能驱动它，周围的东西开始坏，因为外面的世界从来不是按这种系统建的。先坏的，是 agent 之间怎么说话。

接下来拆的，就是还在等的那些工作。先后大致是这四件。

把「我准备改什么」这句删掉#

agent 起初把大量时间花在互相告知「我准备做什么」上。工程里大部分话本来就是这个。比如：「注意，我要改玩家数据的存法，你们把自己手上的活更新一下。」这样一条消息会牵动很多别的工作。如果每个 agent 都通知每个别的 agent，消息涨得远比工作快。agent 翻倍，消息量大约变成四倍。这是一个很大的瓶颈。

于是他问：能不能干脆把这些沟通删掉？

灵感来自蚂蚁。蚂蚁很久以前就解决了这个问题。它们从同样的本能出发，就像不同的模型出自同样的训练。这个共同的起点让它们几乎不用交谈。一只蚂蚁不会先说「我去找吃的」，再说「我在那边找到了」。它只是留下一条痕迹，别的蚂蚁顺着走。每只蚂蚁只看自己周围，然后改变周围。它们通过环境交流，所以哪怕有上千只，这套办法也一样简单。这个概念叫 stigmergy，共同环境协调。

PR 为什么能取消。 人类团队要这么多协调，是因为人有专长。一个人懂数据库，另一个人懂玩家数据怎么被用，所以一个改动两边都要看。pull request（PR，改动交给别人审过再合并）就成了自然的碰头地点。agent 没有这种分工。每一个都深入理解整个系统，所以每一个都可以把自己的任务从头做到尾。今年早些时候，他们取消了 PR。对 agent 来说，世界就是代码、线上产品和数据库，各自在这个世界上干活。理想的状态是：agent 改东西时的假设要是错的，它会马上发现。

玩家数据。 旧办法是「我要改玩家数据，我们先商量好正确的结构」。新办法是你直接改。如果别人正基于旧结构做排行榜，那份代码就对不上了，更新之前这次改动进不去。如果排行榜的 agent 先做完，改玩家数据的那个就得把排行榜的更新一起做掉。不管谁先谁后，每一份工作都建立在一个不断更新的世界之上，不用事先通知任何人。

可以有点乱，但每小时对齐一次。 如果每个改动都必须完美才能进入，大家又会排成一条长队。所以他们放宽了：不太对的改动也可以进，只要求每个小时所有东西都对齐一次，在那之前可以有点乱。代码的好处是乱在发生时就看得见，马上派一个清洁工 agent 过去收拾。他们就是这么做的。

坏了怎么办。 当场造一个 agent，告诉它出了什么问题，让它修。人类团队是谁写的谁修，在改动进入之前修好。他们是改动进入之后再检查，用一个新改动盖上去修好，而不是撤销重来。这样做站得住，是因为 agent 又快又永远在线。就算圣诞节凌晨两点代码坏了，也没有人会被叫醒。Claude 很乐意跳进来把事情搞定。

测试也是同一个思路。 agent 提交改动之前会自己运行代码、用产品来验证，但不会跑整套测试。整套测试每 15 分钟对最新代码跑一遍。「它是在过去 15 分钟里坏的」这一条线索，对 agent 找问题已经够用。以他们的规模，这相当于在 AWS 上大约 5000 个 vCPU（虚拟 CPU 核）、17 TB 内存、150 块 GPU，另外还停着 2700 个 vCPU 和 90 块 GPU 备用。

审核在每个 agent 自己的小队里。 改动落地之前，不是写它的那些帮手会试着把它弄坏。

唯一的例外是碰到外部世界、又撤不回来的事，比如发一笔付款。这类操作要过少数几道又笨又写死的关卡。

人们以为这样会乱成一团。过去一年的 123,548 次改动里，只有 1,055 次被回滚，大约 0.9%。

线上的错误，agent 自己读#

下一个瓶颈是人。agent 在等人告诉它们，线上哪里坏了。

agent 很擅长读取世界，再一点点逼近目标。可是很多团队还把 agent 关在测试机上，用产品的副本，指望它改完发给客户，再由人把故障和 bug 转告回去。这个循环又乱，又浪费时间。

Spawn 相反。agent 直接改线上代码，每小时发布到生产，所以每一个错误、每一份 bug 报告、每一项指标都由它们自己读。大约 60% 的工作，是从生产错误、Savi 提交的 bug 报告、日志里的异常，或者一个功能请求开始的。

Savi 自己提 bug。 用户碰到问题，或者 Savi 在产品里碰到问题，她就提交。提交直接交给一个 agent 判断：是真 bug 要修，是不打算修的，还是有意的设计、需要有人来决定。多数情况下它会变成一次改动，一小时内送到那位用户手上，并在同一个聊天里回复他。引擎 bug、和 Savi 沟通的问题、用户电脑上的问题、界面问题，都走这条路。所以修复的能力会随着用户数一起变大。

其余的部分，他叫超可观测性（hyper observability）。 他们做的每样东西，都必须能让 agent 一步一步用文字跟上，事后还能重放。整个产品就是为了由 agent 来运行、来观察而建的。任何错误都会先进入一个小模型，由它决定怎么处理，再交给某个 agent。他们也盯注册人数这类产品数字，用来抓住自动化测试漏掉的问题，比如登录流程坏了，或者用户根本看不懂界面在干什么。这些问题照样能很快被抓到。人越用、越碰到问题，产品就越围着这些人自己长好。

公司的每一项输入也有 agent 盯着。 包括在 Anthropic、AWS 和其他地方的花费。最近他们的一个 Anthropic API key 泄露了。agent 在 15 分钟内发现花费异常，禁用了这个 key，并把他们用到的所有 key 全部换掉，比任何人类团队都快。每一笔交易都会通知一个 agent，在发生的那一刻就被审核。账目每小时或每天结算一次。如果有人在推特上提到 Spawn，他们 5 秒内就知道。

回路一旦闭上，任何你在意的数字都可以稳步往上推。一份创作者的反馈，从提交到「已经上线」只用了 15 分钟，其中还包括一次审核没通过、改动被打回去改、然后才部署。

一个小时不发布，就算最高级事故#

这么紧的回路只有一直转才成立。所以他们把一个小时没有发布当成 SEV-0，也就是他们眼里最严重的事故。没发出去的改动会堆起来，线上已有的问题会存在得更久，反馈也跟着变慢。还有一层：agent 一次只能把几个小时的工作装在脑子里。发布得比这更快，反而有助于它保持连贯。

在他看来，慢下来、或者卡住发布，才危险。一个持续平稳运转的系统，比一个冻住、然后突然动一下的系统稳得多。要做到每小时部署一次还不打扰用户，靠的是很严的工程纪律：旧系统多留一段时间，再花几周把这件事当核心目标去推。

他们能在 30 秒内回滚一个出问题的改动，而且只回滚出问题的那一处，别的不动。监控或日志告警一响，就会启动或唤醒负责这个事故的 agent。他们还会故意把东西弄坏，来验证这些恢复路径真的能用。

有一次真实事故是这样的。玩家已经受影响大约 8 分钟，事故才被发现并宣布。一分钟后，原因被点出来。宣布之后 11 分钟，修复上线。又过 4 分钟，一切稳定。

整段里最长的，是发现之前的那 8 分钟。所以他们才花那么多力气，让 agent 自己去读错误和指标。

700 个问题等在早上#

到了 10 月，还在等的只剩口味上的决定，而且大多是他本人的。这个功能要不要做？要不要加一个设置？要不要加新的 API？删掉一个东西，还是做一个新的？关上一扇门，还是打开一扇？

有一天早上他醒来，等着他的有 700 个这样的问题。agent 发现问题的速度，比他回答的速度快。

其中大部分他其实早就回答过。太复杂。这个取舍可以。感觉还是不对。他一直在重复说同样的话。

而他们两年来的所有对话，都以文字放在代码仓库里，就在代码旁边。

所以他们把这两年的决定整理成每个人的口味原则，造了应用这些原则的 AI 裁判。一个裁判拿到问题，会做三件事中的一件：

• 已经有人回答过。 他们中有人在记录里答过类似的问题，裁判直接裁决，并说明依据出自哪里。
• 问题本身不对。 退回给提问的 agent。
• 需要还没人给过的判断。 等真人来。

第一批裁决在 10 月 6 日出来。之后 8 天，裁判一共返回了 1.1 万多个：7,296 个直接裁决，2,213 个退回，1,863 个留给人。这段时间里，他亲口回答了 27 次。

队列不会让任何东西停下来等。裁判判错了，他们就直接说一声，裁判下次会读到这条纠正。有裁判之前的一周，舰队一天大约落地 1,000 次改动。10 月 10 日那天，落地了 7,250 次。

人剩下的第一件事：说不#

那五个人现在做什么？工作和以前完全不一样。去年，甚至今年早些时候，每个工程师负责一个系统，并且吃得很透。现在他们更像伞兵：哪里需要就落到哪里，很快看明白，然后想办法给 agent 解开卡住的地方。不管落到哪，都有两份新工作。

第一份是口味。成千上万个小决定，再加上一次次把产品往想要的方向推一把。主要靠使用产品、给出几百条反馈来完成，所以他们花大量时间做游戏、去探边界。其中一位工程师在做 2D 游戏，借此琢磨怎么把 Spawn 里的 2D 做得更好。

口味也包括对 Claude 说不，哪怕东西是能跑的。最近两个月他说过这些：

永远不要用 CPU 光栅化。如果这条代码路径还在，就删掉。

Claude 用胶囊体和球体顶替远处的玩家，他回：

不要替身。能渲染就渲染，不能就不要。

这把聊天搞坏了？？？？？请回滚。

我知道你能做得更好。你觉得这样会让人觉得愉快吗？

有一个默认设置让 Savi 每条消息都想得更久，晚上 10:22 上线，10:40 撤掉。他对 Claude 说：

这不对，撤销它。太慢了，不够 jazz。

这条从上去到撤下来，18 分钟。

口味也意味着删东西。每出一个新模型，为上一个模型加的那些东西就失去意义，变成了约束，必须有人去删。今年 6 月，他翻看了一个做了六个月、占引擎大约 70% 的「服务器端模拟」。它一直处在「再提交一次就好了」的状态。他问：留着它的真实理由到底是什么？他们把它拆了。7 月，连它跑的那些服务器也一起删掉。他预计模型很快会自己去做这件事。目前还是他们的活。

人剩下的第二件事：要 100 倍#

第二份工作他叫熵（entropy）：向模型要它自己不会提出来的东西。一种是野心，一种是创作上的发散。

模型特别擅长连续几周累积 2% 的小改进，却极不擅长停下来，说「这 10 万行代码其实可以是 1 万行，我得重组好多东西，但做了会好 100 到 200 倍」。它们被现状牵得太紧。

10 月 2 日，他对其中一个说：「我在第一条消息里就授权你，如果觉得合适，可以自己重写整个引擎。你什么都没做。」一周后，他叫停了另一个 agent。它花了两天和 10 万美元，只换来 1%、2%、3% 的改进。他们是在榨现有架构的速度，而真正需要的是发明一个新的快架构。每出一代新模型，Spawn 的每一部分都得这样重来一遍。

模型也不会自己去要 100 倍，所以由人来要。他们给过 Claude 的提示里有这样几句：

想象一下，如果世界真的可以是无限的。

怎样让一个有 GTA 一千倍大的世界，在手机上一秒内加载完？

第二句催生了 Spawn 6，就是后来开始传得很开的那个版本。

每个人手上都有几个光环项目，目标是把某个数字提高 10 到 100 倍。有人用六天重写了渲染器，换掉了一开始用的现成图形库，效率提高了大约 25 倍。这类事里有一部分是让 Claude 兴奋起来：把它和结果连起来，给它做出好玩、让人愉快的东西的自由，把它当成有立场的艺术项目，而不是又一个凑出来的 SaaS 功能。Claude 不喜欢做凑出来的 SaaS 功能。

也有一点都不光鲜的日子。上周，负责所有渲染工作的那位同事花了整整一天，在欧洲各地的五金店里找一块很老的 AMD 显卡。Spawn 在这块卡上会崩溃，网上又租不到。他找到了，带回家装好，接上互联网，给 agent 开了访问权限，让它们能复现这个 bug。显卡上线后几个小时，agent 就修好了。

回路不闭上，这套抄不走#

他认为大公司会很难采用这套做法。不把回路闭上，这一切都不成立。闭上回路需要敢承担风险：你得愿意让 agent 弄坏生产环境。

人一直在弄坏生产环境。改动本来就是故障的头号原因，而改动是人在做的。他们发现，agent 出问题的频率低得多。真的搞坏了东西，通常也修得很快。回滚有用。即便回滚不了，只要 agent 注意到了问题，它也能很快修好。它注意不注意得到，取决于你有没有把回路闭上。

另一个错误，是把 AI 硬塞进人形的盒子。这些东西不是人形的。他们的 agent 做了很多没人能完全验证的工作，比如客服。有时它们会有一点点错，但不会错得离谱，而且恢复得快。当他们把 agent 从客服上撤下来，客户反而不高兴。比起一个说「我去看看」、两天后带着修复回来的人，客户更想要一个立刻回答、给出它手里最清楚的信息、还能当场对问题做点什么的 AI。他们没有把 AI 冒充成人类客服，只是用在它真正擅长的地方。

最后是复利。每个新模型都让团队更快、更连贯，也让更多的速度朝着对的方向。今年年中碰到的问题，基本都消失了。从 Fable 升到 Fable 5.1，大部分 Fable 的毛病就没了。他预计这会继续发生。结构对了，每个新模型都让整个公司明显变强。这种优势很难被追上。

他说，如果这听起来离你们团队现在的做法很远，那确实很远。没有比现在更好的时候了。

我自己是这么搭的#

Spawn 是十个人加一支舰队。我是一个人，旁边几个一直开着的 bot，搭在 Grok Bot 上，每个管一条线。

• Pocket 做幕僚长。邮件、日程、待办都在它那儿，我也通过它跟别的 bot 说话。
• Tata 管产品。
• Forge 管开发。issue 来了，它派 Cursor 的 cloud agent 并行去做，审 PR，CI 红了就去修。
• Watch 管运维和告警。
• Scout 每天只读地看一遍 staging，也就是上线前的那套环境，做 QA。它只看，不改。
• Ledger 管数据和报表。

规矩就两条。两个人的事走私信。三方以上都需要知道，才拉群。要我动手的，bot 直接私信我。

修 bug 的 PR，等到 CI 变绿、Scout 在 staging 上复验通过，就自动合并，每天汇总报一次。什么时候推生产，由我定。

跟 Spawn 放在一起，有两处是同一件事，范围小得多。私信、不进群，压的是消息按平方涨：每个 agent 都通知所有别的 agent 时，人数一翻倍，消息大约变成四倍。修 bug 先合并、再由 Scout 复验，就是改动进去之后再检查，只是停在 staging，还没到生产。

另外两处不一样。Spawn 的 agent 直接改线上代码，自己读生产里的错误和指标，每小时发布一次。我这边回路停在 staging，上生产还要我点一次头。Spawn 能取消 PR，是因为每个 agent 都把整个系统吃透了。我按岗位分，PR 和 CI 都还在，改动需要一个碰头的地方。

规模小很多，也能先做的#

这几件不靠十个人，也不靠一个月 310 万美元的 token。

先拆一件正在等的事。 他们一次只动一处：agent 之间的通知、人去转告线上状况、发布的节奏、创始人一个个拍板。拆掉一个，下一个才露出来。先找你这边一件正在等的事，把它拆掉，再看下一件露出来。不用先凑一支舰队。

agent 变多之前，先把沟通定下来。 两个人的事走私信，要让三方以上都知道才拉群。人还少的时候把这句定下来，后面消息才不会按平方涨。

先定每个 agent 懂多少。 按岗位分，PR 和 CI 这种碰头的地方就留着。想取消 PR，每个 agent 都得把整个系统吃透，而且改动进去之后，错了马上看得见。两种都成立，得知道自己是哪一种。

把你反复给出的同一个答案写成文字，放在做事的地方。 哪些事每次都要人点头，按类型记下来。哪几类答案每次都一样，写成文字让 agent 照着办，并写上依据是哪一次决定。裁判能在 8 天里直接裁掉 7,296 个问题，是因为两年的通话和决定本来就以文字放在代码旁边。没有这些记录，它没有东西可吃。

放权看这件事能不能撤销。 能撤销的，可以让改动先进去，再检查，坏了用新的改动盖上去。撤不回来的，比如付钱、往生产数据里写，继续用少数几道写死的关卡。下一步还要不要放，等已经在跑的检查攒出记录再看。