开源项目的“工业时代”转型与速度神话

我是Vincent Koc，OpenClaw的核心维护者之一，与Peter搭档工作。尽管我们都有全职工作（Peter在OpenAI），但OpenClaw作为一个开源项目，正经历着令人惊叹的发展速度。我常提到一个网络迷因：“醒来时，又一项新的技术进步出现了”，这反映了我们以超越阅读代码差异（diff）的速度进行发布的惊人效率。这种速度并非单纯的运气或像“Ralph”那样盲目地最大化循环，而是背后有扎实的工程化工作在支撑。

回顾我的个人经历，我曾是一名技术前沿的探索者。2013年，我在伦敦威斯敏斯特学院附近生活，后来移居澳大利亚。那时我佩戴过早期的VR头显，那个盒子附带警告标签：“每次使用仅限5分钟”，因为当时缺乏防晕动症技术。但我却连续使用了3小时玩《Team Fortress 2》，结果虽然玩得开心，却呕吐了3小时。这正如处于技术边缘的事物往往是粗糙、糟糕甚至恐怖的，OpenClaw的高频提交（有时我每小时都被GitHub限流）也处于这种未探索的领域。

这种高频生产让我联想到英国的工业革命。当时，手工织布机被集中的棉纺厂取代，瓶颈从“织布工的手”转移到了机械化生产。如今，我们正经历类似的范式转移：工程师不再仅仅是手写代码的工匠，而是成为管理AI代理 swarm 的工厂经理。瓶颈不再是体力或基础编码能力，而是品味（Taste）——即对代码质量、架构和方向的判断力。正如我所说的，“我们正处在一个如何规模化构建的时刻，过去的工作方式已不再适用。”

自动化代理的规模化应用与真实案例

在ChatGPT时代，许多人否认大规模使用它，但现实是大家都在秘密使用。现在，自主代理（Autonomous Agents）也处于同样的阶段。一些组织已经公开承认了这一转变。例如，Anthropic利用AI构建了新的C编译器；Spotify声称他们不再手动编写代码；Steve Yegge自称“氛围维护者”（vibe maintainer），每天独立推送约50个PR。而在OpenClaw，我们在高峰期每天提交800个commit，核心维护者仅10-15人，且都有全职工作。这种规模是天文数字般的。

“如果你查看我的提交历史，你会发现当我睡觉时提交就停止了。如果你想了解我何时睡觉、何时醒来以及睡眠时长，只需查看我的提交记录即可。”

在3月15日左右，我个人的提交量接近每天3000个commit。这并非终点，而是未来的常态。这种速度意味着传统的PR审查流程可能不再适用，我们需要新的工程范式。有人提出“Bot Looping”（机器人循环）的概念，即不仅仅是消耗token，而是通过更智能的奖励机制和更有观点的方法来运行循环。这提醒我们，这种规模的 Velocity（速度）将成为 everywhere 的常态，我们需要适应这种新的生产模式。

英伟达合作与多会话并行工程实践

在达到3000次提交的那天之前，我与Peter在英伟达（Nvidia）会面，遇到了另一位英伟达的代表。他们正在构建“Nemo Claw”，并邀请我们协助。在那次协作中，我们展示了多会话并行工程的实际操作。由于长时间使用笔记本电脑工作效率低下，我要求提供外接屏幕，而Peter甚至获得了更大的屏幕。

在这种环境下，Peter在家中通过VPN连接到他的Mac Studio，运行着约15个代码会话；而我则运行着另外10到15个会话。这种并行处理能力使得我们能够同时处理多个复杂的代码重构和生成任务。这种“工厂化”的工作流不仅依赖于AI的能力，更依赖于人类工程师对多个代理会话的协调、监控和品味把控。我们将这种模式称为“Doc Factories”（文档/代码工厂），它代表了从个体贡献者向规模化代理管理的转变。这种转变要求我们重新思考代码审查、版本控制和协作流程，以适应这种前所未有的生产速度。

“我们不再只是简单地‘最大化提交’，而是需要一种更有观点的方法。我们需要思考奖励机制，如何让循环更智能，而不仅仅是消耗token。”

这种实践表明，未来的软件工程将是人类工程师与AI代理 swarm 的协同工作。人类负责定义目标、设定品味标准和解决关键架构问题，而AI代理则负责执行大量的编码、测试和重构任务。这种分工不仅提高了效率，还释放了人类的创造力，使其专注于更高价值的问题解决。随着工具链的完善，这种模式将从OpenClaw扩展到更广泛的软件开发领域，成为行业标准。

代码库重构：从混乱到插件架构的激进转型

OpenClaw 团队目前维持着 60 到 70 个 子代理（sub-agents）的运行规模，在前端则划分了大约 15 个泳道（swim lanes）以并行处理任务。这一架构的诞生源于一次意外的代码变动：一位维护者将文件夹结构进行了调整，导致所有涉及 MS Teams 和 Slack 的对话记录在代码库中的位置发生了迁移。这次变动成为了所谓的“大重构”（Great Refactor）的催化剂。团队意识到，如果无限制地合并所有贡献者提出的功能请求，代码库将变成难以维护的“火堆”（fire dump）。因此，他们决定将代码库拆解，引入 插件架构（plugin architecture），使各个模块（如 OpenAI 或 Anthropic 的提供商代码）能够独立存在和管理。

这次重构的代价是巨大的。在凌晨 2 点，团队决定彻底重构整个代码库，最终产生了 2,700 次 提交，修改了接近 100 万行 代码，触及了 82% 的核心代码库。尽管过程惊险，甚至让负责人怀疑自己是否“飞得太高”（vibe too hard），但团队成功地将代码库重新整合。关键的救命稻草是那些 AI 生成的单元测试，虽然这些测试存在过拟合问题，但它们作为基准，确保了在代码被彻底拆解后，核心功能仍能通过测试绿灯。

代理工厂：泳道管理与计算瓶颈

Vincent Koc 将这种多代理协作模式称为他的“工厂”（Factory）。他通过 泳道（swim lanes）来管理不同的代码会话，通常分为 5 到 20 个泳道，每个泳道负责特定的任务领域，如 CI、新功能开发或 Bug 修复。例如，当代码库相对稳定时，他会让泳道 1 和 2 专注于重构测试，只需确保测试通过并推送即可，无需过多干预。而泳道 3 和 4 可能涉及 Docker 或消息通道的具体问题，需要他与代理进行更深入的对话和调查。泳道 5 则可能处理 P0 或 P1 级别的高优先级问题，甚至利用 GitHub 数据或在 Discord 频道中运行的代理来监控发布后的动态。

随着代理数量的增加，Token 成本不再是主要瓶颈，真正的挑战转变为 原始计算资源（raw compute）和 人类认知负荷（brain space）。Vincent 表示：“Tokens are no longer the problem... What really ends up becoming the problem is just raw compute and my brain space in order to sort of keep an eye on all of these sessions.” 为了应对这一挑战，他依赖自动化测试框架（Harness），并避免使用复杂的“计划模式”或“规范模式”，而是通过与代理的直接对话来解决问题。然而，这种高强度的工作流也带来了工具层面的痛苦，例如他每天机器上可能同时存在 70 到 80 个 活跃的 Git work trees，导致系统资源耗尽。

直觉式管理：像管理员工一样管理 AI

在管理这些代理时，Vincent 发展出了一种类似管理人类员工的直觉。他并不依赖复杂的自动化流程，而是通过观察代理的“解释方式”来判断其工作状态。他引用《黑客帝国》中 Neo 的比喻，形容这种状态为能够感知“穿红裙子的女人”或“遛狗的人”，即通过细微的线索感知代理的思维过程。如果代理的解释显得啰嗦、混乱或缺乏逻辑，他会将其视为“胡扯”（bullshitting），并果断终止该会话，将代码段移交给其他维护者。

这种管理方式的核心在于 对代理推理过程的实时监控。Vincent 指出：“It sounds off because of how it's explaining itself to me. It's waffling. It's not making sense.” 当发现代理出现这种情况时，他不会试图修补，而是直接“核毁”（nuke）该会话。这种策略虽然看似激进，但在处理大规模代码重构和复杂问题时，有效地防止了错误代码的累积。尽管他羡慕其他人通过克隆多个仓库来隔离会话的做法，但他坚持当前的对话式工作流，认为这是在不引入过多复杂性的前提下，保持对代码质量控制的唯一可行路径。

构建基于Skills的Agent开发环境

在Agent开发领域，直觉的建立依赖于大量的Token消耗经验。Vincent Koc指出，通过过去一年中高强度的Token使用，他能够更直观地判断工程工作的方向。为了系统化这一过程，他构建了一个名为“Agent开发环境”的工作流，核心在于对“Skills”（技能）的管理。这些Skills类似于传统的.dotfiles配置文件，但他将其命名为.skills，并全部开源在GitHub上，包括用于编写技术文档等协作技能。他不仅使用开源工具如Geppetto，还深度整合了“Go Codex”技能，通过审查Codex会话日志来持续优化技能表现。

“I've been able to get to because of the sheer volume of token maxing I've had to go through in the previous year.”

这一流程强调技能的迭代与部署。工程师可以将优化后的技能部署到Open Core或个人环境中，并利用vercel.skills.sh等机制进行检索和测试。这种结构化的管理方式使得Skills不再是孤立的脚本，而是可维护、可复用的工程资产。通过这种机制，开发者能够将个人经验转化为标准化的工程流程，从而在复杂的Agent协作中保持高效和一致性。

应对海量PR的语义化治理策略

在维护大型开源项目时，处理成千上万个Pull Requests (PR) 是巨大的工程挑战。Koc提到，项目曾面临6,000甚至60,000个PR的积压，新加入的维护者往往试图通过聚类分析来解决这一问题。他采用了一种基于语义图谱和向量嵌入（Vector Embedding）的技术方案，对GitHub上的所有数据进行深度分析。例如，单个PR可能包含73,106个边缘连接（edges），这种细粒度的语义关联有助于理解PR之间的潜在联系。

然而，单纯的技术手段会导致信息噪音。当每个人都提交自己的解决方案时，问题列表变得混乱不堪。因此，Koc强调需要建立一套去重和优先级判断机制。虽然不称为传统路线图，但团队通过观察社区压力来识别关键问题：如果某个Issue引起大量关注，说明其重要性足以被其他贡献者共同认可。这种基于社区信号的决策机制，帮助团队在噪音中筛选出真正需要解决的核心问题，避免了在次要问题上浪费资源。

从模型能力转向流程与软技能

随着Agent规模的扩大，管理重点从模型性能转向了工程流程与人员软技能。Koc通过构建一个模拟Slack环境的评估系统（Evals），结合合成模型和真实模型，验证了各提供商和通道的有效性。面对“如何管理10多个Agent”的提问，他反问“如何管理10多名员工”，指出管理Agent与管理人类团队在逻辑上具有相似性，都需要清晰的沟通、信任建立和结果验证。

“It's no longer about the model or the agent. It's about the process.”

Koc认为，在大规模Agent协作中，软技能至关重要。工程师需要掌握如何向Agent提问、如何识别Agent是否“胡扯”（hallucination），以及如何高效运行这个“数字工厂”。2025年的核心是Token的最大化利用，而2026年的核心则是Token效率与Agent在环（Agent in the loop）的精准控制。这意味着未来的竞争壁垒不在于拥有多少模型，而在于如何构建高效、可靠且可维护的Agent协作流程，将技术能力转化为稳定的工程产出。