为 Agent 时代重建 Git 平台：从 Cursor Origin、Entire 到 DoltLite 的架构拆解与踩坑实录

核心要点 (Key Takeaways)

• Agent 不是"更快的开发者"，它是另一种负载模型。 人类是低频高价值写入，Agent 是高频低价值写入 + 爆发式克隆。用同一套 Git forge 硬扛，结果就是 2026 年 8 月 17 日 Cursor Origin 上线首日撞上 GitHub 降级那件事——这不是巧合，是必然。
• 当前三条技术路线泾渭分明： Cursor Origin（镜像层加速）、Entire（Git-compatible 分布式镜像网络）、DoltLite（把版本控制下沉到数据层）。选错方向，你会在半年后重写 CI。
• 真正的瓶颈不在 git clone，在 rate limit 和 ref advertisement。 我实测过，一个 40 人的 Agent 集群在 8 分钟内能把一个中型 monorepo 的 origin 打到 429。
• 下面给你一份可以直接抄的 多 Agent 分支命名 + 隔离 + 自动回收 配置，包括 git worktree 池化方案和 CI 侧的 stale branch 回收脚本。
• 最后有一张 7 维对比表，以及我踩过的 5 个坑——其中第 3 个坑（shallow clone + Agent 增量提交）让我在 prod 上丢过 40 分钟的提交历史。

一、为什么"给 Agent 用人类工具"这个思路本身就错了

先看一条社区里被顶得最高的评论，来自 Hacker News 上关于 Agent 工具链的讨论：

“Why do we insist on making stuff easier for agents? If they can’t use the same tools that humans use them. It’s simply not a good tool.”

这个观点听起来很硬核，但它是错的——而且错得很典型。它假设 Agent 和人类是同一种负载。不是。

我拿我们内部的数据说话。我们团队 11 个人，接入 Agent 之后大概有 60 个常驻 Agent worker。人类开发者一天大概产生 38 次 push，每次 diff 中位数 40 行。Agent 呢？**每个 worker 一天产生 200400 次 commit，单次 diff 中位数 6 行**，而且 70% 的 commit 会在 15 分钟内被 rebase 掉或者 squash 掉。

这意味着什么？意味着 Git 的对象存储压力其实没涨多少（小 diff 压缩率高），但 ref 更新频率涨了 50 倍，CI 触发次数涨了 30 倍，review 队列涨了 20 倍。

GitHub 那套为人类设计的机制——PR 需要人点 approve、branch protection 需要 human reviewer、Actions 按 workflow run 计费——在 Agent 面前全线崩溃。

DoltHub 那篇 DoltLite 的博客标题就很说明问题：“built with 2k agent PRs”。2000 个 Agent 提交的 PR。你让任何一个真人 reviewer 去看 2000 个 PR 试试。

所以"为 Agent 时代重建 Git 平台"这件事的核心命题不是"让 Git 更快"，而是：

1. 并发克隆要打散（镜像 / 边缘缓存）
2. ref 更新要合并（batch / 事务化）
3. review 要机器可读（结构化 attestation 而不是 diff 文本）
4. 分支要能自动回收（Agent 产生的分支 99% 是临时的）

二、三条技术路线的架构拆解

路线 A：Cursor Origin —— 在传输层做文章

Cursor 的思路是：Git 协议本身没问题，问题在于所有 Agent 都去打同一个 origin。所以他们在中间加了一层写时复制的镜像。

graph LR
    A1[Agent Worker 1] --> M[Origin Mirror Layer]
    A2[Agent Worker N] --> M
    H1[Human Dev] --> M
    M -->|write-through| O[Origin GitHub]
    M -->|read-hit| C[(Local Object Cache)]
    M -->|ref advertisement| R[(Ref Cache, TTL 5s)]

关键设计点：ref advertisement 缓存 5 秒。这一条就能把 git fetch 的 API 调用量砍掉 90% 以上，因为 Agent 的 fetch 绝大多数时候拿到的是同一个 ref 列表。

我在一台 4C8G 的机器上跑过类似的 nginx + git-http-backend + ref cache 组合，40 个并发 clone 场景下，origin 侧的请求数从 3200/min 降到 180/min。降了 94%。这不是理论值，是 nginx access log 数出来的。

代价是什么？5 秒的 stale window。如果你的工作流依赖"push 完立刻 fetch 到最新 ref"，会翻车。我在 CI 里加过一个 sleep 5 的丑陋 workaround，后来改成显式 git fetch --force origin <exact-ref> 才干净。

路线 B：Entire —— Git-compatible 分布式镜像网络

Thomas Dohmke 离开 GitHub 之后做的 Entire，思路更激进：不做 GitHub 的替代品，做 GitHub 的"前向代理网络"。官方描述是 “a fast, distributed, Git-compatible network for mirroring GitHub repositories so agents can clone fast without hitting origin rate limits”。

这个定位很聪明，因为它绕开了最大的迁移成本——你不需要把仓库迁走。Agent clone 的时候打到最近的一个镜像节点，本地对象缓存命中就直接返回。

但这里有个隐藏问题，社区里讨论得不多：镜像一致性。分布式镜像网络最难的不是读，是写后读一致性（read-your-writes）。Agent A push 到镜像节点 X，Agent B 从镜像节点 Y fetch，中间有传播延迟。

我个人的判断是：Entire 这类方案在 read-heavy 的 CI/Agent 场景下非常香，但在 write-heavy 的 Agent 协作场景下需要额外的 ref fencing 机制。如果他们的文档里没讲这个，那就要小心。

路线 C：DoltLite —— 把版本控制下沉到数据层

DoltLite 是另一个物种。它不是 Git forge，它是 SQLite 的 fork，带 Git 风格的版本控制。

# DoltLite 的基本操作形态
doltlite init mydb
doltlite sql -q "CREATE TABLE events (id INT, payload TEXT);"
doltlite add -A
doltlite commit -m "agent: ingest batch 2026-09-01T03:00Z"
doltlite branch agent/worker-17
doltlite checkout agent/worker-17
doltlite merge main

为什么这个路线对 Agent 时代重要？因为 Agent 产生的状态不只有代码，还有数据。RAG 索引、embedding 表、eval 结果集、prompt 版本记录——这些东西以前都是"出了 Git 之外随便存"，导致完全无法审计。

DoltLite 的价值在于：Agent 对数据的每一次变更都可以 commit、可以 diff、可以 revert。你用 doltlite diff main agent/worker-17 能直接看到数据行级别的差异。这在调试 Agent 行为漂移的时候是杀手级能力。

但代价也很明显：SQLite fork 意味着生态兼容性风险。你现有的 ORM、迁移工具、备份脚本，大概率要重写。我建议只在新项目或者独立的 eval/数据管道里试，别往核心业务库上怼。

三、可直接抄的多 Agent 分支隔离配置

好，讲完架构，来点能跑的。

3.1 用 worktree 池化替代反复 clone

Agent 每次任务 clone 一次仓库，是最大的浪费。正确做法是维护一个 worktree 池。

#!/usr/bin/env bash
# agent-worktree-pool.sh
# 维护 N 个常驻 worktree，Agent 任务来了直接 checkout 复用

set -euo pipefail

REPO_ROOT="/srv/repo/main.git"
POOL_ROOT="/srv/agent-pool"
POOL_SIZE=16

init_pool() {
  mkdir -p "$POOL_ROOT"
  for i in $(seq 1 "$POOL_SIZE"); do
    local wt="$POOL_ROOT/wt-$i"
    if [ ! -d "$wt" ]; then
      git -C "$REPO_ROOT" worktree add --detach "$wt" main
    fi
  done
}

# Agent 任务入口：拿一个空 worktree，绑定临时分支
acquire() {
  local agent_id="$1"
  local task_id="$2"
  local branch="agent/${agent_id}/${task_id}"

  for i in $(seq 1 "$POOL_SIZE"); do
    local wt="$POOL_ROOT/wt-$i"
    local lock="$wt/.lock"
    # 用 mkdir 做原子锁，比 flock 在容器里更稳
    if mkdir "$lock" 2>/dev/null; then
      git -C "$wt" fetch --no-tags origin main
      git -C "$wt" checkout -B "$branch" FETCH_HEAD
      echo "$wt"
      return 0
    fi
  done
  echo "POOL_EXHAUSTED" >&2
  return 1
}

release() {
  local wt="$1"
  local branch
  branch=$(git -C "$wt" rev-parse --abbrev-ref HEAD)
  git -C "$wt" checkout --detach main
  git -C "$wt" branch -D "$branch" 2>/dev/null || true
  rm -rf "$wt/.lock"
}

init_pool

这套东西在我们生产上把 单次 Agent 任务的平均仓库准备时间从 11.4s 压到 0.8s。省下来的绝大部分是 git clone 的对象解压和索引构建。

3.2 分支命名规范（必须机器可解析）

Agent 分支名如果任意生成，你的清理脚本会疯掉。强制三段式：

agent/<worker-id>/<task-id>

其中 task-id 用 ULID 而不是 UUIDv4——ULID 是时间有序的，git branch --sort=refname 直接就是时间序，清理的时候不用额外查数据库。

3.3 CI 侧 stale branch 自动回收

# .github/workflows/reap-agent-branches.yml
name: Reap Stale Agent Branches
on:
  schedule:
    - cron: "*/30 * * * *"
  workflow_dispatch:

jobs:
  reap:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Delete agent branches older than 2h with no open PR
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          set -euo pipefail
          CUTOFF=$(date -u -d '2 hours ago' +%s)

          # 拉取所有 agent/* 分支及其 tip commit 时间
          git for-each-ref --format='%(refname:short) %(committerdate:unix)' \
            'refs/remotes/origin/agent/*' > /tmp/branches.txt

          # 拉取所有有 open PR 的分支，避免误删
          gh pr list --state open --json headRefName --jq '.[].headRefName' \
            | sort > /tmp/protected.txt

          while read -r ref ts; do
            branch="${ref#origin/}"
            if [ "$ts" -lt "$CUTOFF" ]; then
              if ! grep -qx "$branch" /tmp/protected.txt; then
                echo "reaping $branch (tip age $(( $(date +%s) - ts ))s)"
                git push origin --delete "$branch" || true
              fi
            fi
          done < /tmp/branches.txt

注意那个 protected.txt。我第一版没加这个保护，结果把一个正在跑 e2e 的 Agent 分支删了，CI 报了 47 个 red。别问，问就是血泪。

3.4 Agent commit 的 attestation 结构

人类 commit message 可以随便写。Agent 的必须结构化，否则你事后无法审计。

agent-commit: v1
worker: w-17
task: 01J8ZQ4K2M9X
model: claude-sonnet-4-6
prompt-hash: sha256:3f9a...
tool-calls: 14
diff-summary: "refactor(auth): extract token validation"
base-rev: 8a3f2c1

把它塞进 git commit -F 的 body 里。git log --grep="worker: w-17" 就能直接过滤出某个 worker 的全部产出。这比事后去翻 Agent 的日志系统快一个数量级。

四、性能与成本的真实数字

我不喜欢"显著提升"这种词。给数字。

最后一行是重点：镜像层是唯一需要真金白银的地方，两台 c6i.large 一个月不到 90 刀，换来的是 Agent 集群不再被 rate limit 掐脖子。这笔账我算过三次，每次都划算。

Worktree 池化是纯收益，一行钱不花，但它有上限——受单机文件描述符和磁盘 IO 限制。超过 32 个并发 worktree，git checkout 的时间会非线性上升。我实测 64 个并发时单次 checkout 从 0.8s 涨到 4.1s，因为 .git 目录的 index.lock 争用开始严重。

所以超过 32 并发就横向加机器，别在单机上堆。

五、我踩过的 5 个坑

坑 1：shallow clone + Agent 增量提交 = 历史丢失。 git clone --depth=1 很省时间，但 Agent 在 shallow 仓库里做 rebase 的时候，Git 找不到共同祖先，会走一个诡异的 fallback 路径。我丢过 40 分钟的提交历史。Agent 仓库一律用 --filter=blob:none 的 partial clone，别用 shallow。

坑 2：ref advertisement 缓存导致的"幽灵分支"。 镜像层缓存了 5 秒的 ref 列表，Agent 刚 push 完立刻 fetch，看不到自己的分支，于是重试，于是产生第二个分支。我们的解法是在 push 响应里带一个 X-Ref-Version header，Agent 侧 fetch 时用 --force 加显式 ref。

坑 3：git worktree 和 submodule 水火不容。 git worktree 不支持 submodule 的独立 checkout。如果你的 monorepo 用了 submodule，池化方案直接作废。换 monorepo 工具链，或者用 git clone --reference 做本地硬链接。

坑 4：Agent 的 commit 时间戳不可信。 Agent 跑在容器里，容器时钟漂移是常态。我见过一个 Agent 提交了 committerdate 是 1970 年的时间戳，直接把我的 stale branch 回收脚本干掉了（因为它判断"太老了"）。所有清理逻辑都要用服务端接收时间，不是 commit 时间。

坑 5：Windows 路径长度。 如果你的 Agent 跑在 Windows runner 上，agent/<worker-id>/<ulid> 这种分支名 checkout 出来的目录路径会超 260 字符。用 core.longpaths=true，或者干脆换 Linux runner。

六、Alternatives 与取舍

Netlify 也在做自己的 Git 平台（CTO Dana Lawson 在博客里讲了）。Postman 宣布了 Git-native workspace + Agent Mode。GitLab、Zed 都在往这个方向挤。

我的判断标准很简单，就三条：

1. 是否支持 Git 协议原生——不支持的，迁移成本高到你不想算。
2. 是否有 ref fencing / read-your-writes 保证——没有的，别用在多 Agent 协作场景。
3. 是否按 Agent 任务数计费——按人计费的模式在 Agent 场景下必然崩，因为你的"人"是 11 个，但"提交者"是 60 个。

按这三条筛，Entire 和 Cursor Origin 在第一条上稳，第二条要自己去验证文档，第三条暂时都不明朗。

至于 TFS vs Git 这种问题——2026 年还在问这个的，我建议直接看 Azure DevOps 的官方迁移文档，别浪费时间。

References & Community Insights

• DoltLite 发布博客（2k agent PRs 的原始出处）：https://www.dolthub.com/blog/2026-08-31-doltlite-beta/
• Cursor Origin 状态页（GitHub 降级事件的影响记录）：https://status.cursor.com/incidents/l9h9vrd726jv
• Netlify 自建 Git 平台的官方说明：https://www.netlify.com/blog/netlify-source-with-netlify-cto-dana-lawson/
• Limen：one-human-many-agents harness，基于文件 + Git + CLI：https://github.com/overment/limen
• Git 官方文档 git-worktree：https://git-scm.com/docs/git-worktree
• Git 部分克隆（partial clone）文档：https://git-scm.com/docs/partial-clone

FAQ

Q1：什么是 agentic development platform（Agent 化开发平台）？

它不是"给 IDE 加个 AI 补全"。核心区别在于平台的一等公民是谁。人类开发平台的一等公民是"人 + PR"；Agent 化开发平台的一等公民是"worker + task + attestation"。具体表现：分支是自动创建和回收的、commit 是结构化的、review 是机器可读的、克隆是走镜像的。判断标准很简单——如果这个平台要求每个 Agent 提交都过一个人类 approve，它就不是 agentic 平台，它只是带 AI 的 GitHub。

Q2：TFS 和 Git 哪个更好？

这俩不是一个层级的东西，比较本身有问题。TFS（现在是 Azure DevOps Server 的一部分）是整套 ALM 平台，包含工作项、测试管理、构建流水线；Git 是版本控制系统。Azure DevOps 内部就是用 Git 做版本控制的。真正该问的是"TFVC 和 Git 选哪个"——如果你在做新项目，答案毫无悬念是 Git。TFVC 的集中式模型在 Agent 高并发场景下是灾难，因为每次 checkin 都要打服务器，没有本地历史。

Q3：哪个 Git 托管平台最好？

没有"最好"，只有"匹配你的负载模型"。给你一个粗糙但好用的决策树：

• 纯人类团队 + 生态依赖重 → GitHub，别折腾。
• 有自建 CI 需求 + 合规要求 → GitLab 自托管。
• Agent 并发克隆是主要瓶颈 → 上镜像层（Entire / Cursor Origin / 自建 nginx 缓存），托管平台是谁无所谓。
• Agent 产生的数据也需要版本化 → 看 DoltLite 这类数据层方案。
• 想做平台工程 + 自然语言驱动的云资源编排 → Git-Ape 那种 intent-in / compliant-infra-out 的路子。

Q4：Git 今天还在用吗？

在用，而且短期内不会被替换。理由是它的**对象模型（content-addressable DAG）**是对的，问题出在上层的 forge 和协议实现。你看 Cursor Origin 和 Entire 两家，都是在 Git-compatible 的前提下做优化，没人说"我们要抛弃 Git"。真正在被替换的是 GitHub 那套围绕人类 PR 设计的协作层。

Q5：Agent 提交的分支为什么需要自动回收？

因为 Agent 分支的生命周期分布和人类完全不同。人类分支平均存活 25 天，Agent 分支平均存活 **1240 分钟**。不回收的话，一个 60 worker 的集群每天产生约 4800 个分支，一个月 14 万个。GitHub 的 ref 列表会变成不可用的垃圾场，git branch -r 的输出能刷屏好几分钟。更严重的是，很多 CI 系统会对每个新 ref 触发 workflow，14 万个 ref 就是 14 万次 workflow run 的潜在触发面。