GitSwarm：用共享 Git 仓库实现去中心化累积推理

困难的长时程问题很少能一次解决。部分解决方案、实验甚至失败的想法往往在后来被证明有用，但大多数消耗推理计算的方式在尝试结束时就把它们丢弃了。我们把另一种方式称为复利式推理：组织推理时的计算，使中间工作得以保留，并能被后续计算检查、扩展、组合或质疑。

GitSwarm 将这一想法付诸实践。一组相同的智能体在一个共享的、可分支的 Git 仓库上异步工作。没有人分配任务：每个智能体阅读已有的内容，自行决定什么最有帮助，并将其工作发布为一个提交，记录它基于哪些更早的提交。

为什么是复利式推理？

大多数在推理时为模型提供更多计算的方式都把尝试视为一次性的。你可以采样许多答案并保留最好的一个，或者让一个智能体在单个上下文中推理更长时间。无论哪种方式，当一次尝试结束时，它所得出的几乎所有东西也随之结束。

然而，在长时程问题上，中间工作的价值在产生时往往并不明确。一个失败的实验可能指向更好的方向。一个部分证明可能包含某人在十次尝试后需要的引理。两个半可用的程序结合起来可能比任何一个单独更有价值。如果这些工作消失了，后来的尝试就必须重新发现它。如果它被保留下来，后来的尝试就可以在其基础上继续。

GitSwarm 如何工作

GitSwarm 有三个部分：一个作为群体记忆的共享 Git 仓库，一组各自选择下一步行动的相同工作者，以及一个轻量级执行框架，负责调度工作者、隔离它们并验证它们发布的内容。没有规划者，没有分配的角色，也没有享有特权的最终裁判。

仓库即记忆

每个任务从一个包含任务规范的仓库开始。工作者发布的每一项工作都成为一个原子性的、不可变的提交：一份草稿解决方案、一个测试、一个实验及其结果、一次修复，或一个负面发现。分支让相互竞争的方法并行发展，因此群体永远不必过早地确定一个方向。

每个提交记录两种历史。它的 Git 父提交是工作者开始时的状态。它的 informed_by= 字段列出了工作者所依赖的其他提交，包括其他分支上的提交。我们把第二种链接称为语义继承：它让工作者在一个分支上构建的同时，从另一个分支借用发现，而无需合并。从任何提交沿这两种链接向后追溯，就得到它的祖先：它所基于的所有更早的工作。

相同的工作者，没有管理者

每个 worker 都运行相同的模型，使用相同的指令。没有人被指定为求解者、验证者或整合者。每个 worker 查看仓库，并决定当前什么能带来最大价值。专业化，当它出现时，源于仓库的状态：早期的 worker 撰写初稿，因为还没有任何东西存在，而后来的 worker 则进行修复、测试、组合和比较。我们将在下文回到这一点。

异步执行

该 harness 最多同时运行 C 个 worker（在我们的基准测试运行中为五个），并在有槽位空出时启动替补，直到用完 B 个 worker 回合的预算。Worker 从不互相等待，因此一个提交对其发布后启动的每个 worker 都是可见的。

查看实时 swarm

尚未提交的工作在 Git 中不可见，因此 worker 获得两个对实时运行的只读视图。每个 worker 在生成时收到 dashboard 的快照，并可以随时通过运行 gs_dashboard 获取最新的快照。它显示剩余预算、有多少 worker 正在运行，以及提名计数，后者被明确标记为不是正确性的证据；在研究运行中，它显示共享 GPU 使用情况和最佳验证分数。要查看其他 worker 当前正在做什么，worker 运行 gs_inflight：它列出正在运行的 worker，而 gs_inflight inspect 显示一个 worker 的公开日志，包括它宣布将要做的事情、进度更新和未提交的更改。每个 worker 自己写入此日志，以便其他人可以避免重复其工作。这两个视图都不分配工作。

$ gs_dashboard=== Git-Swarm dashboard ===Total worker budget:          200Remaining worker budget:      101Workers currently in flight:  5Nomination workers in flight: 0Total valid nominations made: 7Nominated commits and vote counts  (selection state; not correctness evidence):  7ce10344e6db: 2 nominations  1e5a9adb44da: 1 nomination  ...--- research tasks show instead ---GPUs: 6/8 allocated (75.0%; 2 available)Jobs: 2 running, 0 starting, 11 queuedWARNING: Resource usage below targetBest protected dev: val_loss=3.9004  commit 1d9edbb

$ gs_inflight inspect w0101=== In-flight worker detail ===peer w0101  head=9ac922c47c87  branch=agent/w0101/word-boundary-regex-escapes 06:06:07 announce  targets=9ac922c  Gap: regex candidates diverge on doubled  word-boundary escapes | Deliverable: 9ac922c-  based normalizer | Success: differential  checks | Abort: if this exact refinement is  already published06:08:39 update  Implemented a localized escape  normalizer; narrowing probes ...06:09:16 update  py_compile and compile.sh pass.working tree:  M ambr.py  (+36 lines)

一个回合的剖析

一个 worker 回合是一次从生成到退出的 agent 运行，在其自己隔离的 Git worktree 内进行。提示要求它在行动前理解现有工作，限定一个有限范围的贡献，并事先说明什么情况下它会放弃。

结束一个回合的三种方式

每个回合都以三种动作之一结束。验证仅检查提交是否遵循任务的发布规则（必需文件、允许路径），而不检查其是否正确。

贡献

发布一个经过验证的、原子的提交，包含新工作：部分解决方案、实验、测试、修复或对多个分支的综合。

使用一个预算单位

提名

通过发布单独的提名记录并附上书面理由，为现有提交投出 worker 的票，使其成为最终输出。提交本身不变。

使用一个预算单位

弃权

当没有有用的东西可添加，或等效工作已完成或正在进行时，不发布任何内容而退出。

已替换，不使用预算

去中心化读出

最终，集群必须决定哪个提交是它的答案。GitSwarm 没有把这件事交给一个特权裁判，而是也留给工作节点。提名存储在提交图之外，因此工作节点可以在其他人继续构建新提交的同时评估候选者，而不会改变任何人的祖先关系。当预算耗尽时，获得提名最多的候选者被提交，平局以确定性方式打破。对于有验证分数的研究任务，则改为选择得分最高的模型。

实验设置

我们在两种设置下测试 GitSwarm：具有明确定义、可检查答案的长时程问题，以及开放式研究，其中工作节点还必须决定哪些实验值得运行。

长时程问题求解

IMOProofBench-Advanced

30 道奥林匹克级证明题；我们统计完全正确的证明。

ProgramBench

根据文档和一个仅可执行的参考二进制文件重建程序，按隐藏测试评分。50 个任务的分层子集。

工作节点

Codex（GPT-5.5-high）、基础 GPT-5.5、Gemini 3.1 Pro。五个并发工作节点。预算为 100–500 个回合（程序）和 20–160 个回合（证明）。

基线

强制单智能体，使用相同模型，每次停止时提示其继续，在相近 token 用量下进行比较。

持续研究（AutoResearch）

任务

在固定规则和固定指标下改进三个模型：Residual Matrix Transformer 和 Looped Transformer（仅架构更改），以及 NanoChat（架构、优化器和训练代码）。

工作节点

12–20 个工作节点通过 SLURM 调度器共享固定 GPU 池，持续 24–72 小时：使用 GPT-5.6 Sol（RMT）或 GPT-5.5（Looped Transformer）的 Codex 工作节点，以及在 NanoChat 上使用 GPT-6 Astra 或 GPT-5.6 Sol 的工作节点。

选择

提名被关闭；选择最佳验证分数，并在可用时在留出集上检查。

基线

使用相同模型、GPU 和时间的单智能体，外加 NanoChat 上的进化搜索基线。

ProgramBench 和 IMOProofBench 上的结果

ProgramBench。使用 Codex 工作节点时，GitSwarm 从 100 个工作节点回合时的 73.1% 提升到 500 个回合时的 79.4%。被强制的单个 Codex 智能体无论被推动多久，都停留在 63.1% 到 65.1% 之间。使用基础 GPT-5.5 工作节点时，GitSwarm 从 64.6% 提升到 71.2%。预算越大，增益越小，并且输入 token 增加，因为每个工作节点读取的仓库更大。

IMOProofBench-Advanced。使用 Gemini 3.1 Pro 工作节点时，随着预算从 20 个增长到 160 个工作节点，GitSwarm 从 23.3 个完全正确的证明提升到 29.0 个（在 80 处有局部下降）。最佳强制基线达到 26.5。使用 GPT-5.5 工作节点时，单次运行在预算为 40 和 80 时解决了全部 30 道题。使用 oracle 验证器的最佳 N 采样也达到了这一上限，因此解决全部 30 道题本身并不是 GitSwarm 独有的优势。

工作真的会复利吗？

更高的分数可能仅仅来自运行更多的智能体。为了检验后续工作是否真的建立在早期工作之上，我们查看了基准测试运行中的代码仓库内部：工作单元引用了什么、它们打开并运行了哪些文件，以及最终被选中的解决方案中包含什么。

99.9% / 96.2%的符合条件的片段引用了早期工作（ProgramBench / 证明）

94.7% / 44.4%的贡献后来被其他工作单元所沿用

82–93% / 21–33%的一次运行中的提交位于所选解决方案的祖先链中

约80% / 759 中的 583自愿产出的工件被主动复用 / 被后续工作单元打开的探测包

所选解决方案建立在早期工作之上

在两个基准测试中，所选解决方案都建立在早期工作单元所发布的工作之上，但它对一次运行的利用程度有所不同。在 ProgramBench 上，其祖先链覆盖了一次运行中 82–93% 的提交，其中只有约四分之一是通过 Git 父提交传入的；其余大部分是通过跨分支的语义继承传入的。在 IMOProofBench 上，所选证明触及图的 21–33%：好的证明往往出现得较早，后续工作单元大多是在检查和比较候选证明，而不是扩展它们。这种检查仍然利用了早期工作，并且决定了选择哪个证明，尽管它并不属于该证明的祖先链。

工作单元自主承担角色

我们在运行结束后为每个工作单元片段标注了其主要活动。在 ProgramBench 上，一小波工作单元创建了最初版本；此后，添加缺失功能、修复行为和组合候选方案一直持续到最后，而提名只在接近尾声时才出现。所选程序通常在一次运行进行到 93–98% 时才首次出现。证明类运行则提前得多：一旦存在好的候选证明，越来越多的工作单元会在它们之间进行检查和选择，而不是编写新的证明。大约每六个 ProgramBench 工作单元中就有一个在发现等价工作已经存在后选择弃权。

不同的问题，不同的工作流

同一协议会根据问题产生相当不同的协作模式。在 delta 运行中，不同的分支改进程序的不同部分，并在后期合并为一个强大的集成，获胜者就建立在其上。在 cheat 运行中，工作单元把前三分之一花在命令行和配置行为上，然后在一波渲染器实验之后转向输出渲染器，渲染器这条线最终成为获胜者。

AutoResearch：运行一个研究项目

基准测试有固定答案。研究没有：工作者必须选择实验、在共享 GPU 上运行它们、解读有噪声的结果，并决定下一步尝试什么。我们给 GitSwarm 三个研究任务，分别基于 Residual Matrix Transformer（Mak & Flanigan, 2025）、Looped Transformer Huginn（Geiping et al., 2025）和 NanoChat（Karpathy, 2025；我们从 autoresearch 设置开始）。在每一个任务中，工作者都从已发表的模型出发，并且必须在固定规则下改进它：Residual Matrix Transformer 和 Looped Transformer 只允许更改架构，而 NanoChat 允许同时更改架构、优化器和训练代码。他们把训练任务提交到一个共享 GPU 队列，就像一个研究小组那样。代码、结果和笔记都保存在仓库中。

每个任务还展示了研究复合推进的不同方式。

我们没有编程设定的研究行为

阅读研究历史时发现了一些没有任何提示明确要求的行为。几个突出的例子，详情见论文附录 E：

Residual Matrix Transformer

一个失败，49.5 小时后被复活

让每个 token 看到前一个 token 的记忆状态失败了。两天后，另一个工作者引用该失败作为证据，说明更长的回看仍未探索，于是构建了一个覆盖多个更早 token 的混合器，它进入了提交的模型。

Looped Transformer

审计自己的标尺

在一次 128 样本检查几乎扼杀了获胜想法之后，一名工作者测量了小规模评估错误排序模型的频率：12 对中有 5 对。随后，群体采用了 128 → 512 → 4,873 样本的评估漏斗，共享的代理设置被 257 次提交复用。

全部三个任务

负面结果不会被丢弃

工作者会发布没有成功的实验，并如此标注，其他人会引用它们：Looped Transformer 运行中 74% 的负面架构结果和 NanoChat 中 70% 的负面架构结果被后续贡献引用，通常是为了排除某个方向或建立对照。

Residual Matrix Transformer

单个智能体缺乏的广度

群体探索了 19 个想法家族，并始终在尝试新的。单个 Codex 智能体在 26.5 小时后没有开启任何新的想法路线，而直接的 GPT 智能体将其 68% 的 GPU 时间花在单一家族上。

NanoChat · Looped Transformer

互相检查工作

一名工作者重新运行了完全相同的配置，把一次表面上的胜利变成了近乎平局；下一名工作者引用了这一点，并选择了不同的改动。在 Looped 运行中，四名工作者独立运行了参数匹配的对照，后来的一名工作者推翻了一个小样本胜利。

Residual Matrix Transformer

跨整个运行的复合推进

这个新集群以来自三个更早的独立运行（约220个研究小时）的最佳模型为种子，将它们组合起来，加入了其中一个运行的头部路由器和另一个运行的更深层堆叠，并将继承的最佳损失从2.909降至2.898。

要点

• 推理算力可以累积。借助持久、可分支的记忆以及显式的跨分支链接，独立的智能体回合累积成一份工作成果，供后续回合复用，而不是一堆一次性的尝试。
• 复利效应在不同问题上表现不同。程序重建将大部分运行过程折叠进最终程序。证明求解主要利用早期工作来验证和选择。研究则混合两者，并额外恢复了那些最初看似失败的思路。
• 协调可以保持去中心化。没有规划者或角色划分，工作者们自行分工、避免了一些重复，并自行选择答案。

局限性。我们的依赖关系和轨迹分析表明，工作者会阅读、复用并基于早期工作继续构建，但并未分离出每个被复用部分对性能的贡献有多大。ProgramBench 结果使用的是50个任务的子集；完美的证明得分来自单次运行；研究对比并非在每个维度上都匹配（例如 NanoChat 的起点和 GPU 分配不同）。持久协作也有成本：输入 token 随仓库增长而增长，冗余回合仍然消耗算力。

一个自然的下一步是在这类环境中训练智能体，奖励那些其价值只有通过其他智能体后续在其基础上构建才显现出来的贡献，从而使智能体学会推进一个共享的发现过程，而不仅仅是完成自己的回合。

引用

@article{shah2026gitswarm,
  title   = {GitSwarm: Decentralized Compounding Inference},
  author  = {Shah, Vedant and Samanta, Ankur and Dahal, Paras and Plekhanov, Mikhail
             and Wu, Carole-Jean and Yih, Scott and Munos, Remi and Fergus, Rob
             and Foerster, Jakob and Salakhutdinov, Ruslan and Arora, Sanjeev
             and Weston, Jason and Courville, Aaron and Goyal, Anirudh},
  journal = {arXiv preprint arXiv:2610.04862},
  year    = {2026}
}