Meta 超级智能实验室与 Mila、蒙特利尔大学等机构的研究者，前几天公开了一篇 GitSwarm 研究预印本。他们让一批 AI Agent 共享一个 Git 仓库，把代码、实验记录、局部解法和失败尝试都留下来，供后来的 Agent 检查、修改和接着做。
每个 Agent 自己决定下一步：补功能、做实验、验证某条思路，或者把几条分支的成果组合起来。系统不安排一位“总指挥”给它们分工，协作主要发生在这份不断更新的工作记录里。作者把这种组织方式称为 compounding inference：让不同回合的推理成果逐渐积累。
在论文选取的 50 个 ProgramBench 程序重建任务上，使用 GPT-5.5 Codex 的 GitSwarm 得到 79.4% 的平均得分，持续被要求“继续工作”的单个 Codex Agent 最佳报告结果为 65.1%。研究还覆盖了数学证明，以及三项需要实际跑 GPU 实验的神经网络架构改进任务。
Git 仓库里留下的不只是代码
增加推理算力，常见的办法是让模型多试几次，再从答案里挑一个；也可以延长单次推理，或者让多个 Agent 一起做。同一回合里，模型能保留已经走过的步骤，但换到另一条尝试，之前发现的反例、尚未完成的证明或实验结果，未必还在眼前。
GitSwarm 把这些中间成果做成了后续工作可以读取的文件。
一个 Agent 完成贡献时，除了代码、测试或实验产物，还要留下两份记录：MY_THOUGHTS.md 说明它想解决什么、用了哪些前人成果、做了什么；EVALUATION.md 写清实际检查、当前缺口和值得继续做的事。后来者打开仓库，就能看到某个方案为何成立、在哪个条件下失败，以及下一步可以从哪里接上。
分支允许几种思路同时存在。一个方向暂时走不通，其代码和记录也仍留在历史里，不会被最后选中的版本盖掉。
GitSwarm 的协作示意：后续 Agent 可以复用不同分支中的贡献，图中不是实际实验轨迹
这里多了一条普通 Git 历史没有直接表达的信息：这次工作还用到了哪些其他分支的发现。
Git 的父提交记录的是“我从哪个版本开始修改”。GitSwarm 要求 Agent 另外填写 informed_by=，列出对本次贡献有帮助的早先提交，其中必须包含父提交。
这样，一个 Agent 可以从某个代码版本出发，同时参考另一分支的反例、第三条分支的实验结果，再把相关想法实现到自己的版本里。那些分支不必先做 Git merge，引用关系也能保留下来。
这些关系由 Agent 声明，研究者还会检查执行轨迹，看它们是否真的打开、运行或改写了前面的产物。
一个新 Agent 怎样接过工作
新回合启动后，Agent 先看仓库已有成果，再看其他 Agent 正在做什么。已提交的工作可以用 Git 和配套检索工具查看；尚未提交的工作则通过活动记录暴露当前目标和进展。它可以检查同伴的记录，但不能修改同伴的工作区。
随后，它选一项有价值的贡献，确定交付物和检查条件，从合适的提交创建自己的分支，在独立 worktree 里执行。写代码、运行测试、做实验之后，连同推理和评估笔记提交一个原子 commit，标上所依赖的早先提交，这一回合就结束了。
框架负责并发、隔离和提交格式检查。例如，ProgramBench 中的每个候选都必须保留能生成可执行程序的 compile.sh。符合提交要求的代码仍可能行为不正确，后续 Agent 可以继续找问题和修补。
有的 Agent 会比较现有候选，推荐自己认为最好的版本。推荐记录与代码贡献分开保存，解题预算耗尽后，系统按提名数量选出提交，平票按确定规则处理。做架构研究时则使用验证分数选模型。
如果发现自己准备做的事已经有人完成或正在做，Agent 也可以放弃这一回合。这个决定会释放位置，但已经花掉的推理 token 仍然计入实际消耗。
因此，论文图里的 100、200、500，是累计计费的 worker episodes，也就是工作回合预算。程序重建和数学解题实验最多同时运行 5 个 Agent，空出位置后再启动后续回合。
一次失败，约两天后又派上了用场
论文里的 RMT 实验很能说明这些记录有什么价值。
RMT 是一种保留矩阵形式残差状态的 Transformer。Agent 要在维持这一特征、参数量低于 350M 的条件下改进架构。研究者用 12 个 GPT-5.6-sol Codex worker，在 H200 资源上连续研究 72 小时。
其中一条尝试想利用前一个 token 的记忆，效果不好，结果被记了下来。约 49.5 小时后，另一个 worker 回看这条记录，把想法扩展到多个前序 token，做出了后来进入最终模型的 temporal mixer。
RMT 的研究依赖图：绿色表示最终方案路径，紫色虚线表示复用了被否定的结果
最终架构的六项改动中，四项来自其他分支。两个资源配置下的模型，留出集 loss 分别为 2.890 和 2.894，参考模型为 3.147，三者最终训练都使用 1.3B tokens。
Looped Transformer 的经历又有些不同。
Agent 很早就提出：把循环输入的线性适配层换成带门控的前馈网络。最初在 128 个样本的快速评测中，这个方案被淘汰。后来有 worker 用 512 个样本重新评测，再到完整开发集上确认，方案其实有改善。
事后比较发现，128 样本评测把 12 对模型中的 5 对排错了，512 样本时只排错 1 对。记录里留下的评测条件，帮助后来的 Agent 重新判断早先的“失败”。
Looped Transformer 的研究过程：早先被拒绝的适配层方案经过重新评测后进入最佳模型
这项实验的最佳模型把开发集 loss 从 3.265 降到 3.187；参数量匹配的对照为 3.212，仍保留约三分之二的改善。最后的代码路径不长，但它声明依赖了 89 个提交，很多贡献提供的是实验依据。
在另一项 NanoChat 研究中，70.1% 被标为负向结果的研究提交，后来被其他已接受贡献引用。这个数字来自该项研究的记录分析：失败产物可能被复用，失败时的条件也可能帮助后续取舍。
多轮协作，究竟比单个 Agent 多做了什么
ProgramBench 给 Agent 一份文档和一个只能执行的参考程序，要求它重新实现一个独立代码库，再用隐藏测试比较输出行为。论文用了全库 200 个任务中的固定 50 题，平均得分是隐藏测试的匹配比例，不是“完整解决了多少题”的成功率。
单 Agent 对照并非回答一次就停止。研究者在 Codex 每次自然结束后继续提示它工作，并评估不同停止点；GitSwarm 则把额外回合交给能读取共享成果的新 worker。两边使用同样的 GPT-5.5 high 模型设置。
随着预算从 100 个回合增加到 500 个，GitSwarm 的平均得分从 73.1% 升到 79.4%。单 Codex 对照在所绘制的各个检查点上保持在 63.1%—65.1% 之间。
ProgramBench 的输入与输出 token 曲线，B100 和 B500 表示累计工作回合预算
蓝线继续上升，但增益逐渐变小。共享仓库越来越大，新 worker 要检查更多已有成果，输入 token 的消耗也随之增长。作者分别画了输入、输出 token 曲线，便于看清成绩与计算消耗的关系；每题累计输入达到上亿 token，这套实验也并不是低成本运行。
贡献是否真的被接着使用，同样有统计。在这批 ProgramBench 运行中，94.7% 的已发布贡献后来被当作父提交或 informed_by= 来源引用；执行轨迹里，79.9%—82.5% 可供复用的自愿产物包被主动使用。
论文也得到过 30 道 IMOProofBench-Advanced 数学证明题全部做对的结果。但这个结果来自单次运行，带理想验证器的独立采样基线同样能达到满分，而且用更少 token。数学任务中，后续 worker 经常是在核对和比较已有证明；程序重建中，它们则持续补能力、修行为、组合不同分支，最终实现会接入更多早先工作。
推理成果可以积累，代价也会积累
GitSwarm 为长程 Agent 留下了一种具体的工作方式：一个回合结束后，代码、实验条件、负向结果和依赖关系都还在，新的回合可以选择接着改、重新测，或者换一条思路。
它的实验模型没有在协作过程中更新权重，增长的是外部工作记录。论文验证了大量复用行为，但要进一步区分持久记忆、分支和跨分支引用各自带来了多少成绩提升，还需要更直接的消融实验。随着任务变长，读取历史、重复探索和共享算力调度的开销也需要一起测量。
作者在结尾提出了一个后续方向：在这样的环境中训练 Agent，让奖励考虑一条贡献被后续工作使用的价值，而不仅看当前回合有没有得到最终答案。
参考链接
- GitSwarm: Decentralized Compounding Inference：https://arxiv.org/abs/2610.04862
