Git 集成 · 一个 agent 为什么用了三套 git · Grok Build 源码解读

git 在编码 agent 里无处不在。grok 同时用了三套：git CLI（给模型看的状态）、gix（纯 Rust 的脏文件扫描）、git2（图谱的文件收集）。这一章看它们各自的活，重点讲一个精彩的坑：在 panic=abort + 紧 RLIMIT_NPROC 下，gix 并行扫描怎么把整个进程搞崩、又怎么救回来。

Git 集成 · 一个 agent 为什么用了三套 git

编码 agent 里 git 无处不在：看状态、算 diff、提交、切分支、开 worktree。有意思的是，grok 同时用了三套 git 实现，各干各的活。

三套 git，三种用途

用途	用什么	在哪
给模型看的状态(prompt 格式)	git CLI	`file_system/git_status.rs`
脏/暂存文件扫描	gix(纯 Rust)	hunk-tracker、worktree
代码库图谱的文件收集	git2(libgit2)	图谱构建器

为什么不统一成一套？因为各有所长：CLI 输出的格式模型最熟；gix 纯 Rust、无 FFI、适合高频扫描；git2 成熟、拿 tracked 文件列表快。**「按场景选实现，而非教条统一」**本身就是一种工程成熟度。

一个精彩的坑：gix 并行扫描会崩掉整个进程

xai-gix-status 这个小 crate 存在的理由，是一个非常真实、非常隐蔽的坑，值得单独讲。

gix 的并行状态扫描(in_parallel)内部是 spawn_scoped(...).expect("valid name")。问题来了：

grok 用 panic = "abort" 编译(panic 直接 abort 进程，不 unwind);
若系统 RLIMIT_NPROC(进程/线程数上限)很紧(容器里常见)，线程 spawn 会失败；
失败的 spawn_scoped 里那个 .expect() 就 panic → 在 panic=abort 下直接 abort 整个进程。

也就是说：在受限容器里跑一次 git status，可能让整个 agent 进程猝死。而且这不是能 catch 的 JoinError，是 SIGABRT。

xai-gix-status 的解法是给并行扫描的线程数上限做预算：compute_gix_status_thread_limit() 综合 CPU 核数(封顶 HARD_CAP=8)、RLIMIT_NPROC 软上限、当前已用线程数(/proc/self/status)，留出 OUTER_RESERVE=8 给非 gix 线程，算出一个保证 spawn 不会失败的线程数。所有 gix 状态调用都用 with_budgeted_thread_limit(...) 包一层。

一个致命细节：gix 里 thread_limit = Some(0) 表示无限制，不是「零线程」。所以这个 crate 里有 debug_assert!(!Some(0)) 守卫，永远不会传 0。这种「0 == 无限」的 API 反直觉设定，正是并发 bug 的温床——读源码时要格外警惕。

它的测试也很讲究：在子进程里调低 RLIMIT_NPROC(父进程绝不碰 rlimit，否则并行 cargo test 会互相干扰)，证明「无预算的扫描确实 abort、有预算的活下来」。

Git 集成 · 一个 agent 为什么用了三套 git