他们做到了。太酷了，太棒了。欢迎大家，我是文森特。我是做什么的？我是 OpenClaw 的核心维护者之一，与彼得一起工作。正如大家之前所听到的，我也有全职工作，彼得也一样。他在 OpenAI 有全职工作。但你知道的，这是一个开源项目。令人惊叹的事情正在发生。我要谈谈我所谓的“文档工厂”，以及 OpenClaw 如何以比你阅读代码差异（diff）更快的速度发布。
这个梗真的很好笑。我想彼得是一两周前发的这个。我醒来，发现又有了一个新的技术进步。我醒来，这是一个玩笑，说我们在以疯狂的速度发布，而且速度简直 phenomenal（非凡）。有些人可能会想：“哦，这是运气，或者我们就像拉尔夫一样把速度调到最大。”但我认为这里其实有真正的工程工作，我要谈谈这一点。
正如我提到的，我是文森特，你们友好的“氏族成员”。这是我 2013 年使用 VR 眼镜的照片。尽管我的口音听起来有点像澳大利亚人，但我出生在伦敦东部，离这里不远。我实际上就在附近的威斯敏斯特上了大学。后来我决定住在澳大利亚，口音就变了。但我曾经热爱技术，热爱处于技术的前沿。
这是早期推出的几种 VR 眼镜之一。它装在一个大盒子里，上面有一个大警告标志，写着：“嘿，每次使用 5 分钟。”因为它没有内置防晕动症的功能。有趣的是，这个我并没有用 5 分钟，而是用了 3 个小时。我玩了《军团要塞 2》，玩得非常开心，但之后因为视力变成“蜜蜂视野”而吐了 3 个小时。
我想说的是，处于前沿的任何东西都会很粗糙、很糟糕，甚至很可怕。那是未开发的领域。在 OpenClaw 工作，并成为那个以令人难以置信的速度提交代码的团队的一员，以至于我每小时都被 GitHub 限制速率，这是一种有趣的体验。这种经历我以前也经历过。
我们经历了工业革命，当时工厂以极大的产量生产棉纺织品。在英国和欧洲，关于大规模生产和生产化的历史很多。我觉得我们现在又经历着这样的时刻。我们正处于这样一个时刻：如何大规模构建？以前我们使用的工作方式不再有效。
这有点奇怪，因为在我的全职工作中，我主要在评估（Evals）领域工作，那里一切都是结构化的，有遥测数据，必须完美无缺。我还有一个项目，我对“硬度”有着盲目的信仰。这是两个世界，但它们开始融合。我们以前有手工织布机和分散的作坊，到处都是集中的工厂。工匠就是工厂工人，但瓶颈是织布工的手。
我们现在正转向一个世界，工程师在编辑器中编写代码，而不是那样。工程师们在仓库间穿梭。工程师正在成为工厂经理，我要谈谈这一点。瓶颈变成了品味，你知道的，那个美好的词。意大利母亲的手，是的。那么，在这种情况下，这意味着什么？你在说绝对的废话，人们在绝对规模上构建东西吗？是的。
发生的事情与 ChatGPT 时代非常相似，当时每个人都在大规模否认他们在使用 ChatGPT。每个人都处于这种绝对的制造恐慌的世界中。但现实是每个人都在使用它。每个人都在秘密地使用，心想：“天哪，怎么回事？我需要跟它谈谈。”现在，自主代理在大规模应用时也发生了同样的事情。
一些组织已经公开使用了它。例如，Anthropic 最近关于构建新 C 编译器的工作。Spotify 说他们不再手工编写代码，据说是这样。史蒂夫·耶格（Steve Yegge），我非常喜欢他，他说他每天独自推送大约 50 个 PR。他称自己为“氛围维护者”。我对此有点共鸣。而在 OpenClaw，我们在高峰期每天推送 800 个提交。
realistically（现实地），大约有 10 到 15 名核心维护者，都有全职工作。就规模而言，这简直是天文数字。对我来说，那是 3 月 15 日。嗯，那是多久以前？大概两三周前？我当时达到了每天接近 3,000 个提交。如果你仔细看，我的提交在我睡觉时就会停止。所以，如果你想看我什么时候睡觉，什么时候醒来，以及我有多少睡眠时间，你只需查看我的提交历史。
是的，这是天文数字。但问题是，这将成为其他地方常态。这就像我在告诉你，你需要醒来，这种速度的规模将成为常态。试图审查 PR 并处理所有这些麻烦可能行不通。但在混合中存在着工程。有一种形式的工程将会发生。所以我们进行了“提交最大化”。你知道的？让我们直接去那里。尽可能多地提交。
这让我想起了拉尔夫循环，对吧？就像这个人，你想：“嘿，我只是给你分配一个任务。我会燃烧令牌 8 到 9 个小时。”然后你等待，你知道的？你等待。你希望发生点什么。也许会发生点什么。我不知道。但如果我们对这个过程有更观点鲜明的方法会怎样？如果我们称之为“机器人循环”呢？我不知道。另一位维护者给了我这个想法。也许我们会创造这个词。
我们真的只需要令牌吗？那种奖励机制是什么样的？我们如何变得更观点鲜明一些？是的，让我们运行循环，但让我们更聪明地进行。所以，就在你看到那些 3,000 个提交的时候，前一天，我和彼得在英伟达，左边那位先生是另一位英伟达的绅士。他们说：“嘿，我们正在构建 Nemo Claw。”我说：“什么？”怎么回事？“让我们帮你构建它。”
我在房间里。我想：“我不能连续几个小时在笔记本电脑上工作。你能给我拿个屏幕来吗？”他们给了我一个屏幕。彼得没有屏幕，所以左边那是他的笔记本电脑。他要求一个屏幕，所以他们给了他一个比我更大的屏幕，因为你知道的，为什么不呢？我们就开始工作了。他运行着大约 15 个代码会话，他在家里的 Mac Studio 通过 VPN 连接。我运行着另外 10 到 15 个。
我们团队总共运行着大约60到70个智能体，包括子智能体。而在前台，大概有15个并行的工作流。我们正全力推进。有趣的是，我们一边在开发Nemo Claw，一边有一位维护者决定“我要调整一些东西，移动几个文件夹”。结果他移动了整个频道。这意味着我们与MS Teams和Slack的所有对话都转移到了代码库的另一个位置。我们当时惊呼：“天哪，我们得改东西了。”顺便说一句，我还发现了一个放饮料的好地方。不过Nvidia的人不喜欢这样。
于是发生了所谓的“大重构”。基本上，我们意识到有很多人提交PR，而他们真正想要的是构建功能。问题是，我们不能给每个人他们想要的每一个功能，否则代码就会变得臃肿。正如Peter之前所说，挑战在于“我该拒绝谁？”而不是“我该同意谁”。在一个token很便宜的世界里，我可以对所有人说“是”并合并所有内容，但这会让代码库变成一团糟。因此，我们的愿景是精简代码库，将其拆解。
插件架构在某种程度上变得合理。想象一下，如果你是OpenAI、Mistral或Anthropic，如果你拥有那部分提供商代码，并且它与其他部分分离，会怎样？这次代码变更成为了我们的催化剂。那是凌晨2点，我们很累，心想：“为什么不重构整个代码库？”这听起来是个好主意。于是，经过2700次提交，近百万行代码变更，触及82%的核心代码库，插件正式推出。
前一天凌晨1点左右，我正准备睡觉，但测试没通过。我心想，我是不是像伊卡洛斯一样飞得太靠近太阳了？用我们喜欢的话说，我是不是“感觉太嗨”了？我通常觉得自己确实感觉太嗨了。但作为团队，我们设法将代码库重新整合。万幸的是，那些AI代码喜欢生成的糟糕单元测试实际上对我们的代码过拟合了。
当我们彻底移除一切时，这些过拟合的测试仍然存在。只要它们通过，我们就知道大致接近正确。那么，我们是如何做到的？以我为例，我称之为我的“工厂”。很多人问我：“这是什么魔法？你们是怎么做到的？”很简单，我有并行工作流。可以是5个、10个或20个。它们通常自动划分为不同部分。
比如，如果我在重构，而代码库相当稳定，我想重构一些测试，那可能是工作流1和2。我不需要太密切地监护它们，只需告诉它们：“慢慢来，确保测试通过，提交，推送。”而对于工作流3和4，我可能会关注特定功能或问题，比如Docker或我们的某个消息频道。这时我会与那些智能体对话，它们去调查、工作、回来。
工作流5可能在查看新的P0和P1级问题。它可能使用其他数据，比如GitHub。我们在Discord频道中有运行的智能体。发布时，我们会问：“过去2小时发生了什么我需要关注的事？”这会动态扩展。但有趣的是，token不再是问题。真正的问题只是原始计算能力和我的脑力，以便监控所有这些会话。
在Harness中，我们很信任。我没有极其复杂的流程。我生活中唯一复杂的是采用Git工作树，我甚至希望没这么做。原因是运行极重的测试套件时，它完全摧毁了我的机器，因为我触碰的每个PR都变成了一个新的Git工作树。我每天机器上可能有70或80个活跃的Git工作树，这简直是地狱。
因此，我不得不在我的Codex会话周围构建一些“魔法”。我的Codex知道Git工作树。如果我按退出键，它会崩溃，但会自动修复、自我恢复、获取稀疏数据。但 realistically，我应该像Peter和其他人那样，克隆仓库10次，并将10个不同的Codex会话指向每一个。但关键在于，我没有使用任何魔法。我不使用计划模式或规范模式。我与智能体对话，我们一起解决问题，找到让它工作的方法。
从Matrix的角度看，情况大致如此。人们问：“Vincent，你怎么知道它在某种程度上起作用？”这听起来有点疯狂。如果你看过Matrix中Neo过桥的场景，那人问：“你怎么知道？你怎么读文字？”那人说：“我干这行很久了，所以我能看到穿红裙的女人或遛狗的人。”你开始建立一种关系，能感觉到推理token。
这听起来很荒谬，但有时我看工作流时，会觉得“这听起来不对劲”。不是因为它在做什么，而是因为它向我解释的方式。它在啰嗦，没有意义，似乎不知道自己在做什么。这感觉很像我管理人的方式。如果有人为我工作并开始胡扯，我会说：“等等，怎么回事？”
在这种情况下，我可能会直接销毁会话，心想：“我不处理这段代码，留给另一个维护者。”或者我可能会……
回到那个状态四到五天后。那种体验非常像直觉，建立这种直觉，得益于我过去一年中为了最大化 Token 使用量而经历的巨大工作量。因此，这其中涉及工程工作。我称之为“代理开发环境”。基本上，流程是这样的：我有技能，我称之为“.skills”，类似于“.dotfiles”。我的“.skills”和“.dotfiles”都在 GitHub 上开源，大家可以去获取。其中一些技能是私有的，但也有一些技能，比如编写技术文档，这是我与其他开发者体验工程师和市场上的其他工程师共同创建的。
你可以使用技能工具包，比如 Geppetto，我也是其贡献者之一。或者你可以直接说“Go Codex”。在过去两周里我一直在使用这个技能。通过 Codex 会话，阅读日志，对技能进行改进。然后我会将该技能部署到我的开源核心中，或者带入我的个人环境，并使用类似 vercel.skills.sh 的机制来查看它。我在上面添加了一些其他测试和其他元素，但这有一套我作为工程师管理和维护技能的流程。
我们管理 PR（拉取请求）的方式也包含一定的工程工作。有一个流传的笑话，每个加入项目的维护者都试图解决：“天哪，我们有 6000 个 PR，我们要怎么解决？我要把它们聚类并搞清楚。”60k？多少？60k。没错。谢谢。这就是我尝试解决这个问题的方法。这是一种语义图化，对整个 GitHub 内容进行向量嵌入。这是一个 PR，它有 73,106 个边。
结果是每个人都会遇到同样的问题，所以他们决定发送他们版本的 PR 问题。这变成了彻底的噪音。因此，甚至有一套流程来决定我们如何消费我们将要处理的内容。我们可能不称之为路线图，但我们有一种去重和查看现有内容的方法。这可能是一个信号，让我说：“好吧，如果某个问题上有足够的压力，那它一定足够大，以至于所有这些‘clankers’（注：指代特定群体或误听，此处保留语境含义）都决定这是一个大问题。也许我应该去解决它。”
令人惊讶的是，还有评估（evals）。在所有这些重构工作之后，我们决定创建一个类似 Slack 的假环境，结合合成模型和真实模型，以便运行评估循环，检查每个提供商和通道是否正常工作。最近有人问我：“你如何管理 10 多个代理？”这让我思考。我反问他：“你如何管理 10 多名员工？”他无法回答我。我在航空公司和其他大型组织工作过，管理过大型 AI 团队。我有管理 30 到 40 多人的经验。所以，对我来说，这并不是什么新范式。
但我认为，对于大规模使用这些编码代理的工程师和人员来说，软技能才是关键。你如何询问你的代理“发生了什么？”你如何知道它们是否在胡说八道？你如何运营那个工厂？因此，不再关乎模型或代理，而是关乎流程。2025 年是关于最大化 Token 使用量，2026 年是关于不浪费它们。这是关于 Token 效率，关于代理在环（agent in the loop）。谢谢。