DeltaTTG：教AI agent"看懂"自己离成功还有多远

你有没有玩过那种闯关游戏，打到第五关才告诉你"游戏结束，失败"？你完全不知道是第一关的某个操作就埋下了祸根，还是第四关才翻车。你只能把整个流程重新来一遍,靠猜测和运气去调整。

这其实就是现在训练AI agent时遇到的真实困境。

一个AI agent要完成"帮我查一篇论文""帮我订机票""帮我修复这个代码bug"这样的任务,往往需要经过十几步甚至几十步的思考、调用工具、观察结果、再决策。但训练它的时候,系统给的反馈只有一个：任务最后成功了,还是失败了。

这就是论文里说的"稀疏且延迟的奖励"问题。

稀疏奖励:整个任务做完才给一次反馈，中间每一步做得好不好完全不知道。延迟奖励:这个反馈要等到任务彻底结束才出现，没法在过程中及时纠正。

想象你在教小孩骑自行车,但你不能在旁边随时提醒"这里该刹车了""方向盘再往左一点",只能等他骑完全程摔了跟头或者安全到达之后,才告诉他"这次不行"或者"这次可以"。他要怎么知道是第三秒的手部动作出了问题,还是第十秒的重心偏移导致的?如果你一直这样教,他摔的次数会远远超过正常水平，因为他永远在瞎试。这正是当前多轮强化学习训练agent时面临的真实处境。

那怎么办?一些研究者想到,既然没法知道"绝对对错",那能不能让同一个任务采样很多条路径,然后互相比较?这就是所谓的"组内比较"方法,比如论文里提到的GiGPO和HGPO。

这类方法的思路是，让AI在同一个状态下尝试不同动作,然后看哪些动作带来了更好的结果,从而给每一步打分。听起来挺合理,但这里有个致命的前提:你得先能准确判断"这两条路径走到的是不是同一个状态"。

现实世界里的agent任务,往往是开放式的交互,状态几乎不可能完全重合。你让它去搜索论文、操作网页、调用API,每一步产生的上下文都略有不同。如果靠相似度去凑一个"差不多的组",反而会把本质上不可比的状态硬凑在一起,引入噪声。打个比方，这就像你想比较两个厨师谁炒菜更好，结果找来的"对照组"一个用的是新鲜辣椒一个用的是不辣的青椒，火候、调料全不一样，硬要靠这个比较谁的手艺更强，比出来的结论根本不可信。如果继续用这种方式打分，agent学到的可能不是"动作好不好"，而是"凑巧分到了什么组"。

另一条路是直接给每一步打分,但这需要请人工标注员、训练额外的裁判模型,或者针对每个任务手写一套评分规则。成本高,还不通用,换个任务就要重新设计一套。

那有没有第三条路?一个不需要精确状态匹配、也不需要人工标注的进度信号？

这篇论文的作者们,就是奔着这个问题去的。

把"进度"换个角度想:还剩多少活要做

论文提出的核心思路,说出来其实挺朴素。

既然很难直接判断"这一步好不好",那能不能换个角度,去估计"做完这一步之后,还要花多大力气才能完成任务"?

他们管这个指标叫Token-to-Go,简称TTG。

Token-to-Go（TTG）：指从当前这一步状态出发,直到任务成功完成,AI还需要生成多少个token（可以粗略理解为AI还要"说"多少话、做多少步思考和操作）。它是从真实记录下来的交互轨迹里直接数出来的，不需要额外标注。

这个指标为什么好用?因为它是可观测的。一条成功完成的任务轨迹,你完全可以倒着数回去,精确知道每一步之后还剩多少token要生成。不需要外部裁判,不需要人工打分,只要有历史记录就行。

论文里打了一个很形象的比方:在"创建活动票价档"的任务里,agent每创建完一个票价档位,距离任务完成就近了一截,剩余要做的事情自然就变少了。如果某一步做了无用功,甚至做错了什么,后面可能需要更多步骤去补救,剩余工作量反而会增加。

这里有一个很关键的洞察:同一个状态下,不同的agent、不同的模型家族、不同的交互方式,它们走完任务所消耗的token数肯定不完全一样。有的模型废话多,有的模型简洁高效。但作者的核心假设是,如果把来自各种不同模型、不同能力水平的大量轨迹汇总起来看,一个有益的动作，平均下来会比一个有害的动作留下更少的剩余工作量,而彻底失败的续写则会被赋予一个很大的"剩余工作量代价"。

这就像问一百个不同经验水平的厨师,在炒菜的某个中间步骤之后,还要几步才能上桌。有人手快有人手慢，但如果某一步明显是失误（比如糊了锅），不管哪个厨师来救场，后续要补救的步骤平均来说都会变多。如果不去汇总大量不同风格的样本，只盯着一个厨师的个人习惯,你学到的只是这个人的风格,而不是"这道菜本身的进度规律"。这正是为什么作者要刻意收集Qwen3-4B、Qwen3.5-9B、Qwen3.5-27B、Llama-3.2-3B等多种不同模型生成的轨迹,混合起来训练同一个进度表,而不是只用某一个actor自己的数据。

这也解答了为什么不能简单训一个"价值模型"(Value Model)来做这件事。

价值模型（Value Model）：传统强化学习里用来预测"这个状态未来能拿多少总奖励"的模型，但它一旦绑定在某个actor的训练数据上，就容易和这个actor的具体行为风格纠缠在一起。

论文指出,传统价值模型有个麻烦事,叫"价值扁平化"（value flattening）：在稀疏奖励下，很多不同的状态最后对应的都是同一个终局分数（成功或失败），于是价值模型学出来的估计值就趋于一片平坦，分不清谁好谁差。TTG不一样，它的标签在每一条轨迹的每个前缀上都是不同的具体数字，提供的是更细粒度的局部监督信号。

训练一个"进度表":从记录里学,而不是从反馈里学

搞清楚用什么信号之后,接下来的问题是:怎么把这个信号变成一个可用的模型?

论文把这个模型叫做进度表（progress meter），训练过程分两步。

第一步是监督微调（SFT）。拿大量记录下来的轨迹,在每个动作发生前切一刀,得到一个"前缀"（也就是当前的交互历史）。给这个前缀打上两个标签:这条轨迹最终是不是成功了（一个二元判断），如果成功了，从这里到结束还剩多少token（也就是TTG）。让模型学着从前缀预测出这两个值,先把输出格式和基本映射关系学会。

第二步是用强化学习（这里用的是GRPO算法）去精调。给模型的预测结果打分,如果完成状态预测对了,还会额外奖励它对剩余token数预测得准不准。这一步能让进度表的估计更精确。

训练完之后,这个进度表会被冻结,不再更新参数,然后反复用在actor（也就是真正要被训练去完成任务的那个agent模型）的训练过程里。

这里有个设计挺有意思:一个领域只需要训练一个进度表,就可以同时服务于不同大小、不同家族的actor模型。论文里的ALFWorld（一个文字版居家任务模拟环境）、PaperSearchQA（科研论文检索问答）、BFCLv3（工具调用评测）三个任务领域各训练一个进度表,然后分别拿去指导Qwen3-4B和Llama-3.1-8B-Instruct这两种完全不同的actor。

这就好比一个经验丰富的老师傅,看过成百上千个学徒的炒菜过程,练出了一双"一眼就知道这道菜做到哪一步、还差多远"的眼光。这双眼光不需要为每个新学徒重新培养,新来的学徒不管是急性子还是慢性子,老师傅看一眼都能告诉你火候对不对。如果反过来,每收一个新学徒就要重新观察、重新总结规律,那成本就太高了，而且很难做到跨团队、跨风格的通用性。

用"进度变化"重新分配功劳:DeltaTTG的credit分配机制

有了这个进度表,接下来就是整篇论文最核心的部分:怎么用它去指导真正的agent训练。

先回顾一下GRPO（Group Relative Policy Optimization）的基本做法。

GRPO：一种强化学习算法，对同一个任务采样多条轨迹，根据每条轨迹最终拿到的奖励，在组内做归一化，得到每条轨迹的"优势值"（advantage），用来指导模型往哪个方向调整参数。

GRPO的问题在于,它算出来的这个优势值是整条轨迹共享的,也就是说,一条轨迹里的每一步,无论做得好不好,都被同等地加上或减去这个优势值。这就是开头说的"稀疏奖励"问题在算法层面的体现。

DeltaTTG要做的,就是把这个均摊的优势值,按照每一步实际的"进度贡献"重新分配。

具体怎么分?论文定义了一个很简洁的量,叫做Δt（这一步的进度变化量）。

Δt：等于这一步之前进度表估计的剩余工作量,减去这一步之后的剩余工作量。如果Δt是正的,说明这一步让任务离完成更近了,是"进步"；如果是负的,说明这一步让任务离完成更远了,是"退步"。

接下来是整个方法里我觉得最巧妙的一个设计,叫sign-aware credit allocation(符号感知的功劳分配)。

逻辑是这样的:如果这条轨迹整体是成功的（优势值为正）,那就重点奖励那些带来"进步"的步骤；如果这条轨迹整体是失败的（优势值为负）,那就重点惩罚那些带来"退步"的步骤。

这个设计的巧妙之处在哪?它避免了一个很容易踩的坑:如果不区分轨迹整体是成功还是失败,直接按"进步越多奖励越多"去分配,那么一条失败轨迹里偶尔出现的某个"进步"步骤,也会被错误地大力奖励,这其实是在鼓励错误的方向。而sign-aware这个机制保证了,奖励的方向始终和整体结果的方向一致,只是用进度变化来决定"奖励该往哪一步集中火力",而不是改变奖励的性质本身。

打个比方,一场足球比赛最终输了,整体复盘肯定是找问题，但如果你发现中场某一次传球配合其实很精彩,只是后面没抓住机会,你会说这次传球"值得保留"，但你不会把这次传球当成"赢球的关键"来大力表扬，因为比赛结果是输的。反过来,如果比赛赢了,你会重点表扬那些真正带来突破的配合,而不是去纠结某个失误传球"虽然丢了球权但姿势很帅"。DeltaTTG做的就是这件事:让功劳和过错的分配,始终服从于整体结果的方向,而不是脱离结果去单独评判某个瞬间的表现。

论文还设了一个均匀混合系数ρ,把纯进度打分和平均打分按比例混合,目的是防止进度表偶尔估计出错时,把所有权重都压在一两步上导致训练不稳定。同时还设了一个权重上限M=5,限制单个动作能拿到的放大倍数,避免某些极端情况把训练搞崩。

这些细节听起来有点琐碎,但背后的意图很清楚:让这个重新分配机制稳一点,别因为进度表偶尔的失误就让整个训练跑偏。

效果到底怎么样

说了这么多设计,实际效果如何?

论文在ALFWorld（居家任务）、PaperSearchQA（论文检索问答）、BFCLv3（工具调用）三个基准上,用Qwen3-4B和Llama-3.1-8B-Instruct两种actor做了测试,对比了ReAct（纯提示词方法,不训练）、GRPO、DAPO、GiGPO、HGPO五种基线方法。

结果显示,DeltaTTG在两种actor上都拿到了最高的平均分。用Qwen3-4B时平均分是72.86,比第二好的方法（DAPO的70.41）高了2.45分；用Llama-3.1-8B-Instruct时平均分是66.49,比第二好的GiGPO（61.69）高了4.8分。

在BFCLv3的多轮工具调用任务上,提升尤其明显:Qwen3-4B上比最强基线高4.8分,Llama-3.1-8B-Instruct上在Non-Live和Live两个子类上分别高出7.6分和9.0分。

训练效率方面也有意思的发现。在ALFWorld上,DeltaTTG大约75步训练就能达到80%的成功率,而GiGPO需要大约125步才能达到同样水平,相当于少用了40%的优化步数。

成本方面,论文专门做了GPU时间对比。DAPO要用到GRPO的2.7倍的GPU时间（因为它用了动态采样策略,需要反复生成直到凑够合格的训练批次）,但DeltaTTG只需要跟GRPO差不多的训练成本,就能拿到同样甚至更好的成功率。进度表本身的训练只需要10.45个GPU小时,而且这个成本是一次性的,可以反复复用在不同的actor训练任务上,相当于被摊薄了。

论文还做了一系列消融实验,拿掉某个组件看效果会怎样变化。比如把TTG换成单纯的"最终得分"（也就是传统的价值模型思路）,ALFWorld的成功率明显下降；去掉sign-aware的符号感知机制,Unseen split上的成功率从87.81掉到76.87,掉了近11个百分点;完全不训练进度表（直接用没训练过的原始模型当裁判),效果也明显变差。这些实验基本证明了,论文里每个设计选择都确实在起作用,不是摆设。

这个进度表到底靠不靠谱

光看actor训练效果提升还不够,论文也专门去验证了这个进度表本身到底学得怎么样。

他们用了一个叫AgentProcessBench的基准,里面有专门标注过"这一步是好是坏"的人工标签,拿这些标签去检验进度表的判断能力。结果显示,排除中间状态（既不算好也不算坏）之后,随机猜的期望准确率是50%,直接拿模型去问（不经过TTG专门训练）的准确率是50.83%,而经过TTG监督训练之后,准确率提升到56.91%。

这个提升幅度看起来不算惊人，但要知道，这是在排除了随机猜测基线之后的净提升，而且是在完全没有针对该基准做专门优化的情况下得到的结果，说明TTG确实学到了一些能泛化的"进度判断"规律，不是单纯记住了训练数据。

论文还拿TTG和另外两种可能的监督目标做了对比:一个是直接预测最终得分（Future Score）,一个是预测剩余步数（Step-to-Go,只数步骤不数token）。结果TTG在验证集和测试集上都拿到了最高的综合准确率，这多少印证了之前的那个判断:用token数这种细粒度、连续变化的量来做监督，比用粗粒度的最终输出或者步骤计数，能提供更丰富的局部信息。

更有意思的是测试时的应用。论文尝试在推理阶段（也就是actor已经训练完,正式"上场"做任务的时候）,用这个进度表去帮它选动作。具体做法是,每一步让actor生成四个候选动作,分别在环境里试跑,进度表给每个候选打分,选那个让"剩余工作量"降得最多的动作往前走。

这个方法在Qwen3-1.7B、4B、8B、14B四种不同大小的actor上都测试了,结果显示,相比"随便挑一个候选"和"自然单次输出"两种对照组,进度表引导的选择在所有规模的actor上都带来了更高的成功率，而且平均完成任务用的步数也更少。比如在Qwen3-4B的Seen split上,自然rollout成功率是27.86%，用进度表引导之后提升到44.29%，提升了16.43个百分点，这个差距相当可观。

这说明进度表学到的东西,不只是能帮训练阶段分配功劳,甚至能在模型完全不改变参数的情况下,直接拿来当"参谋"用。

最后,论文还测了跨领域迁移。拿一个只在ALFWorld上训练出来的进度表,直接搬到PaperSearchQA这个完全不同的任务领域去指导训练,结果照样比GRPO表现更好。这说明进度表学到的"剩余工作量"这个概念,多少具备了一些跨领域的通用性,不完全是针对某个具体任务量身定制的。

写在后面

读完这篇论文,我印象最深的其实不是DeltaTTG本身的性能提升,而是它选择TTG这个指标的那个瞬间的思路转折。

大部分人想解决"稀疏奖励"问题,第一反应是去找更好的裁判、更细的打分规则,本质上还是在"评判"这件事上做加法。而这篇论文选择绕开评判,去测量一个更客观、更朴素的东西：还剩多少活要做。这个转变听起来简单，但它把一个主观判断题，变成了一个可以从历史数据里直接数出来的客观量，这是整篇论文最值得琐磨的一步。

还有一个细节值得单独说一下。论文审计发现,在成功的轨迹里,只有6.3%到10.5%的状态会被进度表误判为"失败"。这个数字其实挺微妙,它说明进度表不是完美的,但大部分时候是靠谱的,而且作者没有回避这个不完美,反而把它当成论证"失败代价常数C不敏感"的证据。这种对自己方法局限性坦率承认的态度,在很多论文里是缺失的。

这篇论文让我联想到的,是人类教育里一直存在的争议：到底该用"结果导向"还是"过程导向"去评价一个人的学习。结果导向简单粗暴但反馈太慢，过程导向细致但成本高昂、容易主观。TTG这个思路某种程度上提供了第三条路：找一个客观可测量、又能反映过程进展的代理指标。这个思路在教育、管理甚至个人习惯养成上，是不是也有类似的影子，值得想一想。

论文也留了一个没有彻底解决的问题,就是失败代价常数C的敏感性分析还不够充分。审计数据显示大多数情况下这个常数不影响判断，但作者自己也承认这还不足以证明鲁棒性。这个坑留在那里,后续的人大概会接着挖。

如果一个AI agent能准确判断自己"还差多远",那它离真正学会自我纠错、自我规划,还差多远?

Q&A

Q1：DeltaTTG是什么？

A：DeltaTTG是一种训练多轮AI agent的强化学习方法，核心是用一个叫Token-to-Go的指标训练出一个"进度表"模型，用它来估计每一步距离任务完成还剩多少工作量，再据此重新分配训练时的奖励信号，解决传统方法奖励稀疏延迟的问题。

Q2：Token-to-Go和传统的价值模型有什么区别？

A：传统价值模型容易出现"价值扁平化"问题，很多不同状态最终都对应同一个成功失败结果，导致估计趋于一片平坦。Token-to-Go直接从历史轨迹里数出剩余token数，标签在每个前缀上都是具体不同的数字，提供更细粒度的局部监督，而且可以汇总多个不同模型的轨迹训练出通用的进度表。

Q3：DeltaTTG相比GRPO等基线方法效果如何？

A：在ALFWorld、PaperSearchQA、BFCLv3三个基准上，DeltaTTG用Qwen3-4B平均分达到72.86，用Llama-3.1-8B-Instruct平均分达到66.49，均超过GRPO、DAPO、GiGPO、HGPO等基线，同时训练所需GPU时间接近GRPO，样本效率也更高。