Git分支接住中途改需求,30组全超原生长程Agent

GitHarness: Git Init Your Harness Working Memory for Perpetual User Requirements

Zhibang Yang, Xinke Jiang, Yuxuan Liu, Mingyu Zhang, Zhixin Zhang, Zhengxing Song, Yue Fang, Guohong Qiu, Ruiqing Li, Xu Chu, Junfeng Zhao, Yasha Wang

cs.MA, cs.SE

2026-09-29

GitHarness把需求与工作区收成版本史,按兼容基线局部更新。30组均超原生长程,代码token比原生少73.6%。

这篇在解决什么

长程 agent 做到一半,需求仍会变。用户看过草稿、检索或补丁之后,会补上遗漏的约束(requirement completion),加上一个新维度(requirement elicitation),或者改口、撤回(requirement shift)。要动的往往只是一小块:一个 bug、报告里的一节、画面上的雨伞颜色。

检索和意图重写能说清现在要什么,却不决定旧证据、代码和草稿哪些还能用,于是常常整段重跑。轨迹压缩和检查点恢复默认目标不变,过期要求连同产物留在上下文里。全留会污染后面的步骤,全重启会改掉已经做对的部分。需要一次明确决定,把需求变化、恢复点和保留范围接在一起。

方法

GitHarness 挂在 harness 外面。harness 是套在模型外的执行骨架,管记忆、工具和工作区。执行模型不动,各家工作记忆也不重写。每轮正常结束提交一版:当时的需求,加一份可恢复的工作区检查点。这些版本是一张有向图,旧检查点不可变,失败执行不落库。

系统不预测哪些文件会被动到。它从还兼容的旧状态接着做,改哪些地方由新需求决定。update hint 只是提示。

只训练 Git Agent,下游当黑盒,梯度只在它的输出 token 上,这就是 Harness RL。结局奖励看最终产物过不过任务 verifier。逐轮的 query-tracking 由 LLM judger 打分,看有没有漏写或编造、基线是否尽量复用、撤回内容是否清掉。同一题的一组采样用 GRPO 更新。GRPO 按同题采样做归一化优势。跟踪权重 λ 为 0.2。

结果

评测集 MTAgentBench 把 GSM8K、BIRD、BrowseComp-Plus、SWE-bench Verified、DeepResearch Bench 改成七轮对话。终态和原题语义等价,所以沿用原指标:准确率、SQL 执行准确率、答案准确率、修复率,以及 RACE。RACE 是 DeepResearch Bench 对照参考报告打的质量分。harness 为 TCRAG、StackPlanner、OpenHands,骨干为 Qwen3-32B 与 DeepSeek-V4-Flash。对照是原生长程 Native、每轮清空工作区的 Restart、意图折叠 U-Fold,以及用 Git 操作管理上下文的 GCC。

不训练的 GitHarness 在 30 组设置里全部高于 Native。其中 27 组严格超过最强对照,1 组打平,2 组落后。落后的是 StackPlanner 加 DeepSeek 的 SQL,78.0 对 U-Fold 的 81.0;还有 OpenHands 加 Qwen3-32B 的 SQL,73.0 对 GCC 的 77.0。打平的是 OpenHands 加 Qwen3-32B 的搜索,两边都是 10.0。

设置指标GitHarness最强对照
TCRAG + DeepSeek,搜索准确率56.0GCC 42.0
OpenHands + DeepSeek,搜索准确率57.0Restart 39.0
StackPlanner + DeepSeek,数学准确率94.0U-Fold 80.0
StackPlanner + DeepSeek,代码修复率74.0U-Fold 73.0
StackPlanner + Qwen3-32B,SQL执行准确率72.0Restart 66.0

DeepSeek 上搜索拉开得最多。TCRAG 比最强对照高 14.0,OpenHands 高 18.0;相对 Native 是 22.0 和 30.0。Qwen3-32B 的搜索、代码绝对分很低,大多在 1 到 15 和 3 到 19。

token 来自 StackPlanner 加 DeepSeek 的七轮全程,对照 Native。SQL 少 35.8%,149.68k 到 96.10k;搜索少 54.5%,1438.03k 到 653.87k;代码少 73.6%,4900.13k 到 1291.43k;研究少 36.7%,2095.92k 到 1327.77k。这三项同时是最高分和最低 token。数学 token 从 43.13k 升到 59.98k,短计算重做更便宜。代码单题 API 成本从 2.28 美元降到 0.63 美元。

基线若锁死在当前 HEAD,代码修复率从 74.0 掉到 44.0,token 从 129 万升到 451 万。去掉 INSPECT,修复率 42.0,token 422 万。关掉从空工作区重做,五个任务都下降,SQL 少 10.0,搜索少 11.0。

Harness RL 只训练 Qwen3-8B 的 Git Agent,下游执行器仍是 DeepSeek-V4-Flash。数学从 51.0 升到 81.0,SQL 从 55.0 升到 73.0。200 题验证集上,λ 为 0 时查询等价分 47.0、任务分 70.0;λ 为 1 时查询等价分 53.0,任务分掉到 65.0。

不含评测题的技能记忆在测试时检索,15 组里 13 组上升,StackPlanner 的 SQL 从 78.0 到 83.0。搜索、代码、研究没参与建记忆,研究 RACE 仍在三个 harness 上增加 2.07 到 4.27。两到四个任务交错、拉到 30 轮时,数学 84.0(U-Fold 78.0),研究 RACE 47.32(Native 34.53)。研究从 10 轮到 30 轮只少 2.21。

为什么重要

北京大学的这层版本管理,不要求重训 OpenHands、StackPlanner、TCRAG 的执行模型。8B 的 Git Agent 配上冻住的 DeepSeek,数学和 SQL 拉开 30 分、18 分。从哪一版接着干,可以和把题做完分开优化。代码 token 少大约七成,账单里有一块是在重做已经作废的工作。

GCC、GitOfThoughts 也有 commit 和 branch,但按当前推理或失败恢复来选历史,目标默认不变。这里用需求怎么变,决定保留、丢弃还是重算。分数上去,主要是少返工。执行器并没有突然更会做题。

局限与存疑

论文承认两处。反馈含糊或互相冲突时,解释需求和选基线都困难;恢复到兼容基线后,底层 agent 仍可能改动不该动的部分。无关文件被改的比例没有单列,任务分和 token 只是间接证据。

七轮对话是回顾式合成的。原题和原 verifier 先钉成终点,再往前编补全、加约束和改口,终点必须与原题语义等价,临时约束可以事后撤回。测的是需求晃动之后还能不能答出原题。换成没有标准答案的新目标,这套评测覆盖不到。对话不是真人的,每域测试 100 题。

跟踪奖励来自 LLM judger。λ 为 1 时跟踪分上升、任务分下降,两个目标会拉开,论文没有检查 judger 和 Git Agent 是否互相迁就。强化学习只用 GSM8K 和 BIRD 各 100 题,另外三域是域外。StackPlanner 加 DeepSeek 上,8B 的 RL 版五项都低于不训练的 DeepSeek Git Agent,数学是 81.0 对 94.0。30 组全部超过 Native 只对不训练的版本成立,RL 版本是 29 组。

术语

原文与代码

社区讨论

相关论文

全部论文解读