我如何打造出全球最彻底拥抱 AI 的公司

转载并翻译自 jacob (@jsnnsa) 的原文，版权归原作者所有。

Spawn 只有十个人。我们花在 AI token 上的钱是员工薪资总额的 30 倍，交付量几乎与 Anthropic 相当。 过去 30 天，Spawn 交付了 77,000 项实质性改动。也就是说，我们这支十人团队昼夜不停，平均每小时交付约 108 项。

这些工作由我们称为“智能体舰队”的团队完成。它由一批长期运行的 AI 智能体组成，各自负责公司的一部分，从引擎、财务到 bug 分诊。上个月，我们在 token 上花了 310 万美元，是 Anthropic 最大的客户之一。即使不算我们免费提供给创作者使用的 Opus 5.5，我们仍能排进它的前 250 大客户。

我一开始以为我们哪里做错了。于是，我找了几位经营大型公司和创业公司的朋友聊，想弄明白我们的花费怎么会比他们还高。结果我们并没有做错什么，只是对 AI 的思路截然不同。大多数公司让庞大的人类团队使用 AI；我们则让一个小型人类团队与一支庞大的智能体团队并肩工作。为了弄清具体差别，我还和 Anthropic 的一位研究员交流了经验。他们接触过许多客户，那位研究员说，Spawn 的运作方式最像 Anthropic 自己。

许多其他创始人想了解我们的思路，所以我把过去一年的想法和经验整理下来，写在这里与你分享。

直到 Anthropic 发布 Fable，这套方法才行得通

Fable 发布以来，今年我们花了大量时间重新从第一性原理出发，摸索如何打造产品。现在，我们的交付量是六个月前的 500 倍。

为了让你感受到这个规模：过去 30 天，我们向玩家交付了 7.7 万项实质性改动，平均每小时约 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）自然就成了审查的地方。

智能体并不是这样分工的。每个智能体都能深入理解整个系统，因此能从头到尾负责自己的任务。所以今年早些时候，我们取消了 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。用户在产品中遇到问题，或者 Savi 自己遇到问题时，她就会报上来。报告直接交给一个智能体，由它判断这是真正需要修复的 bug、我们决定不修的问题，还是有意如此设计、但仍需作出判断的情况。通常，问题会变成一项改动，在一小时内交付给那位用户，并在同一个聊天窗口中告知对方。它可能是引擎 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% 的改进，却很不擅长停下来想：“你知道吗？这 10 万行代码其实可以变成 1 万行。为此我得重组很多东西，但做完之后效果会好上 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 原有的问题大多不见了；我们预计这种情况会继续。只要结构正确，每一代新模型都会让整家公司显著变强，而后来者很难追上。

如果这听起来与你的团队运作方式相去甚远，确实如此。现在就是开始的最好时机。回头见！