一句话：长周期协作里需求会变，但大部分历史工作不该被推倒重来
9 月 29 日的一份预印本 GitHarness（编号 arXiv 2609.36789）提出了一个朴素却常被忽略的想法：把智能体的需求状态与工作态，组织成一套 Git 风格的、可分支的版本历史。它配一个可训练的 Git Agent 来解决「需求变了该怎么办」，并构建了一个叫 MTAgentBench 的基准来评测长周期、多轮的真实任务。这个工作的价值，不在于又造了一个记忆库，而在于把「记忆」从一段平铺的上下文，升级成了「可版本化的工作态」——这对工程化智能体是很实在的一步。
长周期协作里的需求漂移，是当下智能体的硬伤
论文先把问题讲清楚：智能体越来越多地和用户在长周期任务上协作，过程中不断积累证据、代码与草稿。用户看着这些结果，可能补一条缺失信息（需求补全），提出新需求（需求引出），或者改主意（需求偏移）。这些变动往往只影响一小部分已积累的工作，但现有的做法要么让 agent 带着作废信息继续往前走，要么把局部修订放大成一次全局重写。前者让错误沿着上下文一路传播，后者则把大量仍然有效的劳动白白丢掉。现有的方法大多只负责厘清当下意图，却没回答「过去的工作该怎么跟着变」。
Git 式分支版本历史：把需求态与工作态一起版本化
GitHarness 的核心，是把需求状态和与之对应的 harness 工作态，组织进一套可分支的版本历史。一个可训练的 Git Agent，负责解析需求变化、并挑选一个语义兼容的历史状态；随后一个统一的版本接口把那个状态恢复出来、创建新分支，让底层 harness 得以排除作废信息、继承兼容工作，把执行聚焦在真正受影响的局部。这个比喻很贴切：就像开发者不会因为需求变了就把整个仓库删掉重来，而是从某个 commit 切出新分支。把这套逻辑借给智能体的工作记忆，等于给了它一种「可回退、可局部修改」的结构，而不是一条只能追加、无法收拾的长上下文。
训练方式与 MTAgentBench：冻结下游，只练中间人
Git Agent 本身通过接口级的黑盒强化学习来训练，而下游的 harness 与任务执行模型保持冻结。这意味着它学的是「在接口层面怎么选态、怎么开分支」，而不用去动底层能力，工程上更友好。为了评测，作者还构建了 MTAgentBench，一个保留验证器的基准，覆盖数学推理、Text-to-SQL、智能体搜索、软件工程与研究综合等多轮、长周期任务。保留验证器很关键——它让「工作态恢复得对不对」可以被客观检验，而不是靠肉眼看一段生成文本顺不顺。
增量认知：可版本化的工作态，是工程化智能体的关键一步
把 GitHarness 放回智能体记忆这条线上看，它的增量不在「又多了一个记忆层」，而在它处理的是记忆最麻烦的那一半——变化。近几个月，STATE-Bench、Memora、AgentMemoryBench 等基准都在认真回答「智能体记不记得住、忘没忘掉、冲突怎么处理」；GitHarness 补上的是另一半：当用户的意图本身移动了，过去的工作该怎么跟着收拾。对做长时间任务的 agent 而言，这两件事缺一不可。一个只管「记」，一个管「变」，合起来才是能长期跑、又能改方向的工程化记忆。
边界：仍是早期方法论，泛化与真实成本待验证
也要把话说回来。GitHarness 目前仍属早期方法论与论文阶段：它在 MTAgentBench 这类保留验证器的合成任务上证明了自身，但跨不同 harness、跨真实生产环境的泛化能力，以及恢复分支与重新执行带来的额外开销，作者及行业暂未披露更多细节。对打算照搬的团队，更稳妥的态度是把它当作一种结构思路——给智能体的工作态加上「可回退、可局部修改」的版本语义——而不是当成可直接落地的成品框架。
结语
智能体要真正胜任长周期工作，光靠把更多历史塞进上下文是不够的。GitHarness 用一个很旧的、被工程师用熟了的思路提醒新领域：当需求偏移时，最贵的不是重做，而是把还有效的那部分也一起丢掉。给工作记忆装上版本，也许正是智能体从「一次性的好助手」走向「能长期合作、也接得住变化的同事」所缺的那块拼图。