Depot 表示 GitHub 的拉取请求模型无法跟上编码代理的步伐

Why it matters

Depot's expansion shows where developer-tool founders expect AI coding pressure to move next: source control, CI, identity and policy.

Depot 联合创始人兼首席执行官 Kyle Galbraith 在一篇 7月29日的文章 中认为，GitHub 的分支、拉取请求、审查与合并工作流是为以人为节奏的开发而设计的，随着编码代理生成并行工作流，它正在成为瓶颈。

这一批评同时阐述了 Depot 的产品策略。Galbraith 希望将源代码控制、执行、工件、缓存、身份和策略转变为软件团队可围绕代理组装的基础设施原语。Depot 今年一直朝这一方向推进，掌控最初为 Depot 带来立足点的加速构建周边的层。

在 Depot 的 Series A 帖子 中，Galbraith 表示他与联合创始人兼 CTO Jacob Gillespie 在 Thorn 和 Era Software 担任 staff 工程师大约四年半。他们多次遇到容器构建和 CI 管道缓慢的问题，随后构建了一个内部概念验证，使他们自己的容器构建速度提升了五倍，Galbraith 如是说。那个实验变成了 Depot，Depot 于 2022 年 1 月注册成立，并加入了 Y Combinator 的 2023 年冬季班。

Galbraith 在俄勒冈州 Portland 周边长大，现在居住在法国 Montpellier。Gillespie 此前在 Webflow 和 Playlist 以及 Thorn 和 Era 工作，目前常驻伦敦。他们的地理分隔契合 Depot：一家分布式的开发者基础设施公司，专注于消除两位创始人在工程团队中所经历的等待时间。

对 GitHub 的批判及其背后的产品

Galbraith 的论点从熟悉的软件开发循环开始：在分支上写代码、打开拉取请求、等待检查、收集评论、修改代码并合并。早期的编码代理适配于该序列，因为它们的运行速度仍接近人类速度。他写道，更强的代理增加了同时通过同一系统流转的分支、检查和审查的数量。

这将约束置于代码生成的下游。源代码控制、CI、安全扫描、审查与部署都必须处理增加的输出，同时工程师仍需决定由代理撰写的代码归谁所有以及应如何信任这些代码。

Depot 在 3 月开始减少对该工作流的依赖，当时 Depot CI 进入公测。Depot 表示其早期产品可以加速容器构建或提供更快的 GitHub Actions runners，而 GitHub 仍然控制着编排、API 和周边控制平面。

Depot CI 为创始人提供了自己的编排和计算层。它接受 GitHub Actions 工作流，支持自定义 runner 映像，并允许开发者或代理通过 API 或命令行界面触发运行、检索日志和测试未提交的更改。兼容性是一种分发策略：团队可以将执行迁移到 Depot，而无需立即重写他们在 GitHub 上运行的工作流。

创始团队在 7 月 9 日向上推进了一层，推出了处于私测的源代码托管产品 Depot Code。Depot 表示其编写了一个无磁盘的 Git 服务器，将 packfile 和索引存储在 Amazon S3 中，将引用和元数据保存在事务性存储中，并运行可横向扩展的无状态工作进程。

Depot Code 可以托管独立仓库或镜像上游的 GitHub 仓库。在镜像配置中，Depot CI 可以从 Depot Code 克隆和抓取，同时提交继续回流到 GitHub。该设计为 Galbraith 提供了一条迁移路径：优先迁移对性能敏感的基础设施，并在客户准备好改变更多工作流之前保留 GitHub 的协作界面。

该方法也暴露了论点中的张力。Depot 认为 GitHub 的架构不适合代理规模的交付，但 GitHub 仍然是进入 Depot 目标客户群最简单的途径。GitHub Actions 的兼容性、仓库镜像和熟悉的 Git 命令降低了采用成本，同时也使 Depot 与其想要超越的平台保持绑定。

创始人正在超越更快的 runners

这一扩展具有防御逻辑。使现有平台的基础设施更快的产品，在该平台改善后可能失去其优势。

这正是 BuildJet 遭遇的情况，这是一家提供加速 GitHub Actions runners 的供应商。二月，BuildJet 宣布将于 3 月 31 日前关闭其 runner 服务。BuildJet 表示，GitHub 更快的硬件、更大的 runners 和原生 Arm 支持在很大程度上缩小了其服务试图解决的性能差距。

GitHub 也重建了 Actions 背后的核心服务。GitHub 表示其新架构在 2025 年末每天处理 7100 万个作业，而 2024 年初约为每天 2300 万个。GitHub 自 1 月 1 日起将托管 runner 的价格下调了最多 39%，并宣布自 3 月 1 日起对自托管 runner 收取每分钟 0.002 美元的平台费用，随后在客户反馈后推迟了该计费变更。GitHub 将重建的系统描述为面向智能代理工作负载的执行层，直接对抗 Galbraith 关于其架构无法适应的说法。

Depot 的回应是掌控足够多的交付栈，使其无法被简化为贴着 GitHub 标签的更快机器。容器构建引出了 runners、缓存和镜像仓库。这些产品引出了 Depot CI，而 Depot CI 则催生了将源代码托管拉近 Depot 执行层的理由。

投资者为这一演进提供了资金。Depot 在三月 完成了 1000 万美元的 A 轮融资，现有投资者 Felicis、Y Combinator 和 Pioneer Fund 参与投资。2024 年 8 月的 410 万美元种子轮 由 Felicis 牵头，Y Combinator、Aviso Ventures、Tokyo Black 和天使投资人参与。Depot 已披露至少 1410 万美元的外部融资。

Depot 表示其 在 2025 年加速了超过 1 亿 次构建，为客户节省了约 850 万构建小时。这些公司自报的数据表明其构建基础设施有显著使用量。但这些数据并不能证明客户已经准备好迁移源代码控制或替代拉取请求，因为那需要在安全、合规、所有权和审查实践方面做出远超购买更快计算的变动。

Galbraith 更大的赌注

Galbraith 提出一个以机器吞吐量为组织核心的交付系统。源代码控制提供不可变的历史。执行提供隔离的计算。工件和缓存在系统之间移动可重用的工作。身份确定更改是由人还是代理产生，策略决定该更改是否可以发布。

这种框架让 Depot 可以在任何胜出的协作模型下出售底层基础设施。团队可以保留拉取请求以供人为决策使用，同时让代理通过 Depot 的 API 创建仓库、运行测试并收集证据。另一个客户则可以在相同的原语上构建不同的审批流程。

难点将是信任。更快的代码生成提高了薄弱审查、不清晰的所有权和不可靠测试的成本。为机器量而建的交付系统需要在来源证明和策略方面有更强的控制，而不是绕过这些控制的更快路径。Galbraith 在他的文章中指出了这些需求，但 Depot 的最近发布集中在源代码控制和执行层面。

Depot 已经证明工程团队愿意为减少构建等待时间付费。Galbraith 现在押注，这些客户会重新考虑他们的代码存放位置、代码的验证方式以及哪些工作流环节仍需拉取请求。那将把 Depot 带入更大的市场，并使两位创始人直接与帮助分发其首批产品的平台展开竞争。