本文内容
git-ai 评测：并行智能体合并与验证
git-ai 的仓库名称为 feder-cr/git-ai，项目自称 gitai，是面向并行编码智能体的版本控制后端。它将仓库操作移到服务器，并批量处理同时提交到同一分支的变更。评估是否采用它，最有价值的问题是：团队能否缩短等待集成的时间，同时保留能够证明最终发布版本已经验证的证据？
生成补丁、将补丁合入分支，以及证明最终产品能够正常运行，是三件不同的事。gitai 为合入环节和部分结果验证提供了机制。工程流程仍需将这些环节衔接起来。
资料核查日期：，对应提交 6b0ab81e6e37。本次核查的 README 将 gitai 标为 0.3.0 版本。本文基于文档与源代码分析，不代表 Wavect 的实际部署，也不是我们独立运行的性能基准测试。下文的评估用例是我们提出的建议。
feder-cr/git-ai 是什么？它与 Scion 有什么关系？
所核查提交中的项目 README 将其描述为受 Anthropic 公开版本控制设计启发、采用 MIT 许可证的独立实现。项目起步于 GitLab 的 Gitaly 服务器，命令与配置名称中仍使用 graft，底层也仍然保留普通 Git 仓库。
Anthropic 的 Scion 工程文章 介绍的是为其自身特殊的仓库规模与智能体负载构建的基础设施。gitai 是另一个独立项目。Scion 报告的基础设施资源节省不能直接套用到 gitai，安装 gitai 也不等于安装 Anthropic 的内部系统。
| 名称 | 主要用途 | 对应的决策问题 |
|---|---|---|
| feder-cr/git-ai，即 gitai | 在服务器上执行仓库操作并合入并发变更；CLI 名为 graft | 智能体完成的变更应如何进入一个频繁更新的分支？ |
| git-ai-project/git-ai | 追踪 AI 生成代码的来源，详见其独立项目仓库 | 哪些代码来自 AI 工具？ |
| Graft 仓库上下文工具 | 为智能体提供仓库映射，详见我们的 Graft 仓库映射评测 | 智能体如何找到相关代码？ |
按照安装说明操作之前，先确认仓库所有者。名称相近不意味着命令或集成方式可以通用。
并发合入解决的是哪一种瓶颈？
合入（landing）是将提交的变更集成到目标分支，并不等于部署。当许多智能体同时完成任务时，它们可能都基于同一个分支最新提交准备变更，但另一个智能体抢先推进了分支。这种情况下，反复重建集成结果并重试，本身就会形成额外负载。
合入实现指南 解释了其批处理方式：单个服务器进程中的处理通道按仓库分支归集请求，依次基于不断推进的分支末端集成，再通过比较并交换（compare-and-swap）更新引用，一次发布已接受的变更。只有引用的原值仍与预期一致，这次更新才能成功。
调度和内部队列仍然存在，区别在于如何协调彼此竞争的更新。批处理适用于满足条件的独立运行模式请求，文档明确排除了 GitLab 集成模式。一个批处理通道也只属于一个进程，因此增加服务器节点不会自动形成跨节点共享的单一通道。
| 观察到的问题 | 适合先排查的方向 |
|---|---|
| 智能体覆盖彼此的本地文件，或需要不兼容的依赖 | 工作区与运行环境隔离。可以先阅读我们的 worktree 与 Jujutsu 指南。 |
| 兼容的任务需要在同一个运行中的应用里获得反馈 | 本地变更组合与分支归属，详见 GitButler 共享工作区指南。 |
| 已完成的变更反复争抢同一个服务器分支的更新机会 | 测量合入重试次数、竞争程度和集成延迟。这才是与 gitai 直接相关的评估场景。 |
| 代码可以无冲突合并，却破坏了产品行为 | 改进行为测试、依赖检查和发布证据。更快地更新引用并不能证明结果正确。 |
gitai 如何验证 AI 生成的合并冲突解决方案？
模型生成的冲突解决方案首先只是提案，只有配置的验证在真正准备合入的目录树上通过后，才具备自动合入的条件。冲突解决协议 将服务器与可选的解决器命令或 HTTP 服务分开。冲突解决需要启用，并在请求中明确调用。解决器可以使用确定性规则，也可以调用模型。
对于模型输出，运维人员必须配置 verify.command 并启用验证。检查未通过时，调用方会收到冲突包，其中可能包含建议采用的文件内容。确定性规则的解决结果可以不经这项验证直接合入；开启验证后，这类结果也会接受检查。如果自定义命令内部调用了 LLM，就必须将其标识为基于模型的解决器。将其标为规则，会错误描述结果的来源。
关键实现细节在于候选结果的身份。合入代码 会比较已经验证的树对象 ID 与实际合并后的树对象 ID。如果并发更新改变了候选结果，先前的通过记录不能直接为另一棵目录树提供合入依据。
以一个假设的账单变更为例：智能体 A 重命名了总额计算函数，智能体 B 则为旧函数增加了税率参数。解决器可能生成看似合理的代码，却丢掉计税逻辑。有效的验证应包含对含税总额的断言，单纯编译可能发现不了这个错误。如果后续另一个变更又修改了舍入规则，最终组合出来的目录树就需要与该状态相符的验证证据。
仓库中的验证测试 覆盖了验证器失败、超时、候选结果变化，以及目录树未变化时复用结果等情况。这些是有价值的实现证据。我们检查了测试代码，但没有执行该项目的测试套件。配置的命令通过，只能证明该命令实际检查的内容。
无冲突合并会自动经过同一套测试关卡吗？
不会。解决器的验证并不是所有已接受变更都必须运行的通用测试套件。在本次核查的普通合入路径 中，快进和无冲突集成不会调用冲突解决验证器。其他已经配置的策略仍然适用。
文本冲突和行为冲突是两回事。一个智能体可能修改默认授权规则，另一个则在不同文件中添加新端点。Git 可以顺利组合这两项变更，但新端点的访问控制行为可能已经出错。
对于评估 gitai 的团队，这会改变验收问题。需要逐一确认哪些路径运行了必要检查：普通的无冲突变更、确定性规则解决的冲突、模型解决的冲突，以及人工提交的解决结果。一次 AI 冲突解决演示成功，不能证明所有路径都受到同样的检查。
graft-verify 在合入之后检查什么？
独立的 graft-verify 工具 监听分支更新，将某个分支末端提交检出为工作文件，再运行运维人员指定的测试命令。测试通过后，它会推进通过验证的引用（green reference），默认位置为 refs/graft/green/<branch>。自动二分定位和回退需要单独显式启用，默认关闭。
这会产生两个值得区分的位置：集成分支可以持续推进，而通过验证的引用标记的是已检查的提交。我们建议发布流程明确选定一个已验证版本，并将构建产物绑定到该版本。如果读取了通过验证的引用，却又构建最新的 main，就丢失了验证器刻意建立的这一区别。
| 阶段 | 记录内容 | 能够证明什么 |
|---|---|---|
| 智能体提案 | 基础版本、提交的变更和执行者 | 请求的变更内容及其起始假设 |
| 解决器验证 | 候选树对象 ID、命令和结果 | 配置的检查已在该冲突解决候选结果上通过 |
| 接受集成 | 返回的已合入版本及分支更新 | 变更已经被仓库接受 |
| 合并后验证 | 测试的分支末端提交、测试结果和通过验证的引用 | 所选检查已在该集成版本上通过 |
| 发布 | 选定版本、产物摘要和发布批准 | 交付流程使用的是从获批状态构建的产物 |
最后一行是我们建议采用的交付约定，不是 gitai 自带的自动部署功能。回滚也有类似边界：回退源代码无法撤销已经发生的付款、发送出去的邮件，或破坏性的数据库迁移。
CI 集成还有一个容易忽略的细节：graft-verify --once 在批次被跳过时，也可能像检查通过时一样返回零退出码。应读取它的 JSON 结果，包括 passed、skipped 和实际测试的 tip。仅凭进程成功退出，不足以作为发布证据。
gitai 比 GitHub 或普通 Git 更快吗？
已发布的合入基准测试不能得出这个结论。基准测试文档 比较的是同一台服务器开启和关闭批处理后的结果。其重点展示的负载是 50 个智能体各向同一分支提交 5 项变更，其中 20% 被刻意设计为冲突。
不使用解决器时，批处理负载中的 250 项变更有 200 项成功合入，剩余 50 项是预设冲突。确定性解决器可以处理演示中构造的冲突，但这不能衡量 LLM 是否能保留任意应用的正确行为。
在所核查的提交中，README 与基准测试文档给出的吞吐量和延迟区间也并不一致。因此，我们不会据此提炼一个用于标题的提速倍数。现有证据支持的结论更有限：在这项合成负载中，批处理可以减少相互竞争导致的重试。
进行自己的对比时，应测量从变更完成到获得已验证版本的时间，并记录失败、人工介入和运维成本。测试中需要包含实际测试套件和真实的文件重叠情况。每分钟接受更多提交，只有在验证和恢复能力跟得上时才有意义。
自托管团队需要检查哪些权限和代码暴露问题？
智能体安全模型 提供独立的智能体身份和引用策略。共享令牌仍是运维人员的凭据。在本次核查的实现中，合并后的 graft-verify 工具使用该运维凭据，智能体不能直接访问保留的 refs/graft/ 命名空间。应设计受控的发布集成方式，而不是把该工具的权限交给每个编码智能体。
仓库采用自托管，并不决定解决器会把代码发送到哪里。启用的外部解决器可以收到允许处理的冲突文件内容。需要明确哪些路径可以交给哪些提供商处理，也要考虑源代码中包含个人数据或凭据的情况。文档中的 glob 匹配规则很重要：*.env 不会递归覆盖嵌套目录中的 .env 文件。解决器也不会自动发现并脱敏所有秘密信息。
合入前验证器的实现 会针对仓库内容执行配置的命令。应将这些内容视为来自智能体和解决器的可执行输入。精简环境变量不等于沙箱：需要隔离运行器、移除不必要的凭据、限制网络访问，并约束资源消耗。测试输出本身也可能泄露数据，因此仅限制网络访问还不够。
采用 gitai 是否意味着更换现有代码托管平台？
首先明确哪个系统拥有分支的最终更新权，哪个系统负责评审、CI 和发布。仓库后端只是开发平台的一部分。我们的代码托管迁移分析 讨论更全面的平台选择；本文重点是如何接受并验证智能体提交的变更。
评审子系统文档 指出了一个重要边界：记录一项已经批准的评审，并不会使该批准自动成为合入前必须满足的检查。如果工作流程要求独立审批，就需要另外验证这项要求是否得到强制执行。
存储核心文档 区分了可选的影子模式与权威存储模式，并描述了单节点使用 SQLite、多节点使用 PostgreSQL 加共享对象存储的方案。本地 Git 仓库仍需要补齐所需数据并占用磁盘容量。因此，转移权威存储职责应安排单独的恢复演练。
部分概览文档落后于较新的实现细节。例如，当前存储文档已描述可选的 pack 垃圾回收，代码树中也包含多节点存储测试。这两点都不能证明你选用的云端后端、故障模式或生产负载已经得到验证。应固定一个提交版本，再验证实际采用的部署路径。
迁移生产分支之前，应如何评估 gitai？
使用可丢弃的测试仓库、具有代表性的智能体任务，以及明确的失败用例。在确认哪些变更会被接受、如何验证、如何恢复期间，保持部署链路断开。先以现有 Git 工作流程作为对照：应测量集成瓶颈，再决定它是否足以成为运维另一项服务的理由。
上游快速入门要求 Linux 或 macOS、Git、make、OpenSSL 命令行工具、Go 1.26、C 工具链、Meson 和 Ninja。以下命令固定到本文核查的源代码版本，然后运行项目示例。我们没有在撰写本文时执行这些命令：
git clone https://github.com/feder-cr/git-ai.git
cd git-ai
git checkout --detach 6b0ab81e6e3766824920ec18e17593fe8db714fd
make build
examples/graft/quickstart.sh快速入门中的服务器和示例智能体用于演示工作流程。它们不能证明生产权限模型已经合适，也不能提供具有代表性的吞吐量或经过验证的恢复方案。
| 需要演练的情况 | 需要收集的证据 |
|---|---|
| 多项无冲突变更同时提交到一个分支 | 哪些变更成功合入、重试次数、被拒绝的请求，以及包含失败尝试的延迟 |
| 模型解决结果未通过行为断言 | 候选结果仍保持为提案，分支没有自动接受该解决结果 |
| 验证期间目标分支发生变化 | 变化后的候选结果被重新检查，过期的成功记录不能授权其合入 |
| 确定性规则处理了一个冲突 | 明确理解关闭和开启验证时的区别，并确认行为符合预期策略 |
| 无冲突集成破坏了产品规则 | 所选合并后检查能够发现问题，失败版本不会进入发布路径 |
| 验证器跳过、超时或遇到不稳定测试 | 发布集成能区分这些结果与通过状态，并避免缺乏依据的回退 |
| 智能体请求访问禁止的分支或保留引用 | 权限请求被拒绝、执行者归属正确，并与运维权限保持隔离 |
| 服务器重启或丢失本地仓库缓存 | 预期引用和对象得到恢复，记录恢复耗时，并保留验证证据 |
比较经过验证的交付时间、评审人员介入次数、回归问题和总运维成本。如果测试权威存储模式，还应加入磁盘增长和恢复时间。试验开始前就确定可接受的界限，避免一次更快的演示悄悄改变成功标准。
Wavect 的 AI 落地支持服务 可以帮助团队定义这项评估及其发布标准。我们的 Hyperstate AI 案例 介绍的是另一项工程工作，不代表 gitai 部署经历。可以使用上线前软件 QA 检查清单 确定行为检查范围，或带上近期重试和集成失败的实例，与我们讨论并行智能体的集成瓶颈。
gitai 合并验证常见问题
feder-cr/git-ai 是追踪 AI 代码来源的工具吗？
不是。feder-cr/git-ai 是面向编码智能体的版本控制后端，CLI 名为 graft。git-ai-project/git-ai 是另一个用于追踪 AI 生成代码的独立项目。按照安装说明操作之前，应先确认仓库所有者。
gitai 是 Anthropic Scion 的官方开源版本吗？
不是。它是受公开 Scion 设计理念启发的独立项目。Anthropic 的内部实现和已报告的基础设施结果，不是 gitai 的发布内容或性能保证。
gitai 能自动解决 AI 生成代码的合并冲突吗？
它支持可选的解决器。模型生成的解决结果需要配置并启用验证，而且验证必须在真正准备合入的目录树上通过，否则结果仍是提案。确定性规则解决结果的默认行为有所不同。
verify.command 会测试每一次无冲突合并吗？
不会。在本文核查的提交中，冲突解决验证器不是无冲突集成的通用测试关卡。需要另外定义这类变更的检查，并在发布流程中使用与已验证版本绑定的证据。
graft-verify 会自动回退失败的提交吗？
只有显式启用自动回退后才会如此。默认情况下，它会报告检查失败，通过验证的引用保持原位。回退源代码也无法撤销数据库迁移等外部副作用。
graft-verify 返回零退出码，是否就证明版本通过验证？
不能。单次运行在批次被跳过时也可能成功退出。将结果视为发布证据之前，应检查结构化结果，并确认实际测试的版本。
小团队应该用 gitai 替换 Git worktree 吗？
它们解决不同层面的问题。Worktree 用于分离本地检出目录。只有在测得的服务器端合入竞争足以支持增加服务及验证集成成本时，才值得评估 gitai。仅仅存在几个并行任务，并不能证明有这种需要。