2026 年 11 月 2 日，OpenAI 发文公开了支撑内部每天近 1 PB 流量的自研 Git 系统 Pando；仅仅 3 天后的 11 月 5 日，初创公司 Reason Machines 就开源了完整复刻该架构的 Git 服务器 Aspen（Apache 2.0 协议）。官方称，整个项目由 1 个自家研发的 Reason Agent 耗时 4 天、合并 151 个 PR 从零写完，并在单台 8 核服务器上跑出了每秒 567 次推送的成绩。
把时间戳对齐就会发现，这是一场卡着 OpenAI 技术博客上线的极限 96 小时 AI 复刻秀。Aspen 确实把头部 AI 公司秘而不宣的新一代 Git 架构变成了人人可用的单一 Rust 二进制文件，但翻开代码库的工程检查单就会看到另一面：这个处于 pre-alpha 阶段的系统连 24 小时持久性门禁都没跑通，官方甚至直接在文档里警告用户，切勿用它存储无法承受丢失的数据。
567 次推送/秒的跑分幻觉：放弃全局快照换来的单分支并发
传统 Git 服务器假设代码由人类低频提交，默认按整个代码仓库排队串行写入，并在每次拉取时动态重新打包。当几百个 AI Agent 每隔几分钟并发推送分支、触发海量 CI 拉取时，服务器 CPU 会迅速被打包计算和锁竞争耗尽。OpenAI 的 Pando 与这次开源的 Aspen 采用了同一种解法，即用 PostgreSQL（或 SQLite）存储分支历史，把每次推送改为单行记录的按分支 CAS（比较并交换），并将客户端传来的 pack 文件原封不动存入 S3 对象存储，拉取时直接复用静态文件。
在约 4500 个文件、75000 次提交的 git.git 测试库上，Aspen 用单台 8 核服务器、4 核 Postgres 和 S3 Standard 存储，跑出了持续 5 分钟每秒 567 次推送的成绩（中位延迟 208 ms，p99 延迟 314 ms）。报道将这一数字与 Cursor 商业方案 Origin（S3 Standard 下 120 次/秒，S3 Express 下超 300 次/秒）并列，很容易让人产生 Aspen 性能碾压 Cursor 近 5 倍的错觉。
| 方案名称 | 开源与商业状态 | 并发写入锁粒度 | 跨分支一致性保证 | 官方公布推送吞吐量 |
|---|---|---|---|---|
| Aspen | Apache 2.0 开源 | 按分支独立 CAS | 仅单分支因果一致 | 567 次/秒（特定 URL 自测） |
| OpenAI Pando | 内部系统未公开 | 按分支独立更新 | 放弃全局跨分支快照 | 中位延迟降近 80%，日传 1 PB |
| Cursor Origin | 商业平台闭源 | 按仓库共享 S3 WAL | 线性化推送与全局一致克隆 | 120 至 300+ 次/秒（巨型单仓） |
仔细拆解两者的底层设计，这两个数字根本不在同一个维度上。Cursor Origin 底层的 Continuity 存储引擎通过 S3 预写日志（WAL）和共享索引，保证了整个仓库所有分支的线性化写入和强一致性快照；而 Aspen 为了换取不同分支互不等待的极速并发，直接放弃了跨分支的全局时间点一致性。
此外，Aspen 的高分还带有严苛的前提条件。该项目 README 承认，567 次/秒的测试使用了 Aspen 特有的分支作用域 URL，排除了真实的 CI 拉取负载，且仓库里没有附上原始测试数据，连团队其他成员都尚未完成复现。
扒开 AI 造轮子的工程底裤：跑不通的 24 小时测试与主干拥堵
如果把 Aspen 当作检验 AI 编程 Agent 真实工程能力的样本，它的代码库暴露了一个残酷现实。AI 可以在 4 天内完美复现一套分布式存储的核心逻辑与部署脚手架（连 Docker Compose、Helm 和四大云厂商的 Terraform 模板都一应俱全），却跨不过硬核存储系统最枯燥的可靠性验证。
AI 4 天能跑通架构的阳关道，却填不平分布式存储的异常独木桥。
翻看 Aspen 代码库的质量门禁记录，有四处硬伤直接决定了它目前只能当玩具：
- 持久性测试不及格.官方设定的准入门槛是 24 小时混沌持久性测试，但目前仅在三个独立分段中累计跑完了 11.59 小时的无故障运行，且这些测试全部发生在一次底层存储修补之前；另一项关键的百万次操作差分测试同样处于未完成状态。
- 主干合入退化.尽管分支并发高达 567 次/秒，但当所有 Agent 完成开发、要把代码合并回
main主干分支时，所有请求依然要退化为单分支 CAS 排队，吞吐量瞬间暴跌至每秒约 4 次（且不含 CI 运行时间）。它只解决了 Agent 草稿阶段的并发，没解决最终合入的独木桥拥堵。 - 安全边界自相矛盾.项目的
SECURITY.md声称已实现认证授权、pack 大小限制与并发工作准入控制，但主 README 却依然将并发边界控制（concurrency bounding）列为尚未解决的开放缺陷，同时整个 GitHub 仓库的公开 Issue 列表为空，文档中引用的多个缺陷编号均处于不可见状态。
对于正在搭建多 Agent 编码平台的架构师和研发团队来说，Aspen 提供了一个低成本验证 Pando 架构的沙盒。它内置了镜像模式（Mirror mode），可以作为前置缓存挂载在现有 GitHub 或 GitLab 仓库前，团队不需要迁移主库就能用 aspen dev 在本地或测试环境跑通高并发分支实验。
- 风险.在 Reason Machines 补齐修补后的 24 小时混沌测试、完成百万次差分验证并由人类工程师复现跑分之前，任何团队都不应将核心代码资产脱离 GitHub/GitLab 主库单独交由 Aspen 托管。