一句话看懂：Reason Machines 开源了 Apache 2.0 许可的 Git 服务器 Aspen，专门面向大量 AI Agent 并发推送仓库的场景，按分支而非按仓库扩展写入能力。
事件核心：发生了什么
2026 年 11 月，Reason Machines 发布了 Aspen，一个用 Rust 编写的单二进制 Git 服务器，分支历史存在 PostgreSQL 或 SQLite，pack 文件存入兼容 S3 的对象存储。它通过 HTTPS 和 SSH 提供标准 Git 服务，并独立实现了 OpenAI 此前为 Pando 描述的设计。
官方自报数据：在一台 8 核服务器、S3 Standard 和一个 4 核 Postgres 的测试环境下，对 git.git 副本持续 5 分钟每秒 567 次推送，中位延迟 208 毫秒，p99 为 314 毫秒。需要强调，这是项目自测、非第三方基准，且项目仍处于 pre-alpha，没有正式发布版本、没有 Web UI，24 小时持久性门槛也未达标。
为什么重要
传统 Git 服务器把同一个仓库的推送串行排队，每次 fetch 还要重新打包，服务器负载随客户端数量增长。当大量 Agent 每隔几分钟就推送一次、CI 再频繁拉取时，这条路径很快撞上瓶颈。Aspen 的取舍是按分支做 compare-and-swap，不同分支的推送互不阻塞，fetch 直接复用已存储的 pack，从而把写上限从“每仓库”提升到“每分支”。同赛道上，Cursor Origin 按仓库加 WAL 排序，OpenAI Pando 和 GitHub Spokes 均未公开，Aspen 目前是少数开源自托管选项，这本身对 Agent 基础设施生态有参考价值。
对用户/开发者/创作者的影响
对开发者而言，Aspen 提供了 Docker Compose、Helm、Terraform 以及 mirror 模式，可先代理 GitHub 或 GitLab 做小范围验证，迁移成本相对可控。但要注意其局限：落到 main 分支的推送约每秒 4 次，分支之间可能不是同一时刻的读视图，深度 CI fetch 也依赖后台 compaction。适合评估“多分支、多 Agent 并行写”的团队，不适合直接替代生产主干仓库。
值得关注的后续
一是项目能否走出 pre-alpha，补齐持久性和 Web UI；二是第三方基准能否复现 567 次/秒的写入数据；三是 Cursor Origin、GitHub Spokes 等方案是否开放或调整定价，形成可比较的竞争格局。
