Aspen开源：为Agent搭建自托管Git服务

几百个 AI Agent 同时向一个仓库提交代码，Git 服务的瓶颈可能先出在写入排队和重复打包。Reason Machines 开源的 Aspen，把写入协调拆到分支级别，再复用已经存好的数据包，试图承接这种高频流量。

它自报每秒处理 567 次 push，但向 main 合入只有约每秒 4 次，而且仍处于 pre-alpha。读这篇的价值，是看懂它如何拆开两类负载，以及这些成绩离生产可用还有多远。

为什么不同分支的 push 要一起排队

原文描述的负载是：Agent 每隔几分钟 push 一次，CI 随后 fetch。按 Reason Machines 的说法，传统服务会把同一仓库的 push 放进同一个队列，还会为每次 fetch 重新生成 pack。客户端增加，即使新增代码很少，服务器也会重复做大量工作。

这里的 pack，可以理解成 Git 传输和保存对象时使用的压缩包。

OpenAI 为类似问题构建了内部系统 Pando，公开结果是 push 延迟中位数降低接近 5 倍，每天服务接近 1 PB 数据。Aspen 是对 Pando 设计的独立开放实现，并非 OpenAI 放出的代码。

它的关键改动是比较并交换（compare-and-swap）：每个分支的版本链保存在 PostgreSQL 的一行里。push 先上传 pack，再尝试更新分支指针。不同分支之间不必等待；两个 push 同时更新同一分支，只有一个成功，另一个收到 Git 常见的「fetch first」错误。

Aspen 放宽的是不同分支之间的写入协调，同一分支上的竞争仍然存在。

代价是，读取多个分支时，它们可能对应略有差异的时刻。对依赖跨分支一致视图的流程，这个前提需要单独评估。

fetch 为什么可以不再反复打包

Aspen 不把每次 push 解包成散装对象，而是检查 pack、补齐缺失的基础对象，再保留原包。fetch 时直接传输客户端缺少的已有 pack，避免重新压缩，也可以通过签名 URL 让 CDN 提供这些包。

但只存原包，会不会让落后很久的客户端下载成千上万个小包？

它用后台压实解决：每次合并 16 个 pack，像日志结构合并树一样分层整理。按原文描述，落后较多的客户端只需获取几十个包。对于 depth-1 的 CI fetch，则生成一次 tip pack，供多个任务复用。

另一个优化发生在 push 协商阶段：服务器只通告主干分支，避免分支数量达到 100 万时，客户端仍要面对庞大的分支列表。这里指的是缩小协商信息，并非仓库只能保存主干。

这些改动共同减少重复劳动。它们针对的是高频提交、反复拉取的服务端成本，不能直接推导出构建或测试也会变快。

每秒 567 次 push，究竟测到了什么

作者给出的测试使用一台 8 核服务端、S3 Standard，以及一个 4 核 PostgreSQL。目标是 git.git 的副本，约有 4,500 个文件、75,000 次提交。

测试持续 5 分钟，稳定达到每秒 567 次 push，没有报错；push 延迟中位数为 208 ms，p99 为 314 ms。Git 打印「ok」之前，每次写入都已到达 S3 和 PostgreSQL。另一个客户端看到更新的时间，按中位数计算，是确认后的 30 ms。

depth-1 fetch 压力测试中，传输字节数是原生 git upload-pack 的 1.029 倍。不过，这只是字节量比较，不能据此认定延迟、CPU 和费用也相近。

横向数字同样要看条件。Cursor Origin 公布的结果是：S3 Standard 上最高每秒 120 次 push，S3 Express One Zone 上超过 300 次。但它测的是复制集群和 Cursor 自己的 monorepo。Aspen 的 README 也把自身数字称为参考结果，而非性能承诺。

更关键的是，向 main 合入只有约每秒 4 次。原文没有展开这条路径为何慢。不能拿跨分支吞吐量，代替团队最终合入主干的能力。

我的判断

我认可它把独立分支的写入拆开，也认可为重复 CI 拉取复用 pack 的方向。大量 Agent 各自在分支工作时，这两处确实切中了原文描述的成本来源。

但「传统 Git 服务都会按仓库串行处理」是文章采用的问题模型，不能无条件套到所有托管平台。原文列出的实现就有明显区别：Cursor Origin 使用 S3 写前日志，GitHub Spokes 使用副本间三阶段提交，Pando 则同样按分支协调写入。Origin 还公布了读取线性扩展到 100 个副本的结果，关注点也不只有 push 峰值。

目前的数据足以说明方案值得验证，还不足以证明它适合接管生产仓库。

Aspen 仍是 pre-alpha，没有正式 release，没有 Web UI，也没有通过文中提到的 24 小时持久性门槛。短测中写入成功，不能代替长期故障恢复验证；这个门槛如何定义，原文没有说清。

公司还称，一个 Reason Agent 用 4 天、151 个已合并 PR，把项目从首次提交做到公开。这是开发过程的自述，不是可靠性证据，也没有提供人工投入的对照数据。

能拿来做什么

• 如果团队已有多个编程 Agent 并行工作，先区分等待发生在分支 push、CI fetch，还是 main 合入。只有前两项构成明显负担时，Aspen 的设计才更贴近问题。
• 可以从源码构建后用 aspen dev 做本地验证，它使用 SQLite 和本地目录；团队试验可用带 PostgreSQL、MinIO 的 Docker Compose。客户端仍用标准 Git，通过 HTTPS 或 SSH 连接。
• 想保留现有 GitHub 或 GitLab 流程，可以先评估 mirror mode。项目也提供 Helm，以及覆盖 AWS、Google Cloud、Azure、Hetzner 的 Terraform 配置，但部署选项齐全不等于运维能力已经成熟。
• 对前端或 Node 项目的 CI，可以重点测 depth-1 拉取的重复成本，同时记录主干合入速度和故障恢复表现。采用前还需考虑它是 Apache 2.0 许可、单个 Rust 二进制，但没有 Web UI。