你让 AI 智能体查资料。它先想去哪里找，再发出搜索指令，读完网页后修正判断，最后组织答案。为了让这一连串调用更快，系统可以安排一个“小模型”先猜，主模型再审核。但问题是：小模型可能很会猜搜索指令，却不擅长猜读完资料后的反思。把所有调用揉成一个平均分，很容易看错真正的加速机会。
TraceSpec 研究的正是这个问题。它不再只问“草稿模型平均猜中多少”，而是沿着智能体的执行轨迹，分别观察规划、行动、反思和回答等决策阶段，再把诊断结果用于训练草稿模型。论文把这套评估与训练框架称为 TraceSpec。
这里的推测解码（speculative decoding），可以理解为“速记员先写、主编批量审”：较快的草稿模型先提出一串 token——模型生成文字时使用的基本单位；主模型一次核验。连续猜对的部分直接保留，第一次不一致时再由主模型修正。因此，真正重要的不只是猜对多少个 token，还包括能连续接受多长，以及主模型核验和处理历史记录花了多少时间。
平均数为什么会骗人？
智能体会反复经历推理、调用工具、读取反馈和调整计划。每一步面对的文字规律都不同，之前积累的上下文也越来越长。如果后半程恰好出现更多“容易猜”的调用，总体接受长度就可能上升；这并不代表同一种决策在长上下文里变得更容易。
论文用一组结果展示了这种错觉。在在线浏览任务中，以 DSpark 配合 Qwen3-8B 为例，上下文不足 2,000 token 时，每轮平均接受 3.633 个 token；到 16,000—32,000 token 时升至 5.479 个。可生成吞吐却从每秒 82.73 token 降至 22.54 token。原因并不神秘：接受长度只衡量草稿与主模型对下一段输出的一致程度，吞吐还要计入处理越来越长的历史所需的工作。
更关键的是，当研究者只比较同一批任务中第 20 步以后的浏览行动，并对齐执行阶段与任务进度，趋势反了过来：DSpark 的每轮接受长度从 6.194 降到 5.322。DFlash 和 EAGLE-3 也呈现下降。换句话说，总体平均值在变好，匹配后的后期浏览行动反而更难猜。
这种反转不是所有工作负载都一样。固定历史进行回放时，DSpark 在 Web research 上的接受长度从短上下文的 5.242 降到长上下文的 3.442；在 software engineering 上却从 3.073 升到 4.321。不同阶段也有差异：Web research 中行动阶段高于规划阶段，software engineering 中反思阶段高于回答阶段。上下文长度显然不够解释一切，还要问模型此刻在做什么。
先把比较条件固定下来
TraceSpec 把两种观察方式放在一起。第一种是 dynamic execution，即让智能体真实推进任务，记录它实际遇到的模型调用和工具反馈。它接近真实运行，但不同模型可能走出不同路径。
第二种是 fixed-prefix replay——把一段已有历史当作固定存档点，让不同草稿模型从同一个开头重跑后续生成。这样可以把“走了哪条路线”的差异暂时拿掉，专门比较某个决策点上的解码表现。
为此，作者构建了 TraceSpec-Traj。它包含 10,000 个训练状态和 2,500 个测试状态，训练与测试分别来自互不重叠的源任务；两部分都在 Web research 与 software engineering 之间等分，并覆盖规划、行动、反思和回答四个阶段。每个状态保存当时可见的历史、下一段助手输出、实际前缀长度、此前的工具交互和轨迹位置。
论文随后在 BrowseComp-Plus 和 SWE-bench Verified 上各进行 100 个任务的动态评估，并在 2,500 个测试状态上做固定前缀回放。完整比较覆盖五种基线、三种 Qwen3 目标模型尺寸和两种采样温度，共 108 种配置。
训练资源该花在哪里？
诊断只是前半步。TraceSpec 还要回答：训练预算固定时，哪些决策值得让草稿模型多学几遍？
它先把目标模型生成轨迹中的每一次助手输出都作为训练候选，而不只训练最终回答。一次搜索指令、一次读完工具反馈后的反思，都可以提供监督信号。然后，系统估计每个状态中草稿模型与目标模型的“接受差距”，据此动态分配固定的 prediction budget——可用于训练的预测事件总量。
这套分配同时考虑两件事。其一是 state-conditioned，即结合工作负载、执行阶段、前缀长度和此前工具状态判断困难程度，而不是只看全局平均。其二是 prefix-aware：推测解码要求连续接受；如果草稿在一段开头就错了，后面即使猜对，也无法在这一轮直接保留。因此，TraceSpec 会更重视早期分歧对整段连续接受的影响。
一个容易忽略的细节是，长回答能提供的训练预测位置通常多于短工具指令。TraceSpec 因而按实际预测事件校准抽样次数，让分配的是训练预算，而不只是“见过多少段文字”。第一轮训练先按基础方案收集统计，此后再随当前草稿模型的表现更新优先级。
它带来了什么？
论文报告，TraceSpec 在固定前缀回放的全部 24 个阶段比较中领先。相对作为训练基础的 DSpark，它在三种目标模型尺寸、两种温度下把回放生成吞吐提高了 12.5%—22.6%；在采用同一原生 PyTorch 实现组的 18 项设置中，吞吐有 15 项领先。
Qwen3-4B 的消融实验进一步拆开了收益来源。在同等有效训练预算下，把中间助手回合纳入监督，相比只训练最终回答，接受长度提高 3.9%—10.2%；在此基础上，自适应分配相比固定的全回合监督又提高 3.3%—10.0%。去掉状态条件估计或连续前缀评分后，六项设置均不及完整方法。这些结果来自论文作者的单一信源，说明的是回放吞吐和接受长度，不能直接扩大成真实在线任务的普遍加速或质量提升。
为什么值得关注
TraceSpec 最有价值的地方，不是又给平均分加了几个百分点，而是改变了测量单位。智能体并非一次性写完答案的软件。它会在不同决策之间来回切换，而每种决策的解码难度、上下文成本和训练价值都可能不同。
这也重新界定了“加速智能体”的问题：草稿模型平均更准，并不保证系统更快；长上下文中的平均接受率上升，也不代表后期行动更容易预测。只有把执行轨迹拆到具体状态，才能看见训练预算应该投向哪里，以及那里的改善能否传到实际吞吐。
局限与未知
- 论文的主要效果数字都来自作者自己的实验。材料没有给出三种目标尺寸与两种温度下，12.5%—22.6% 区间端点分别对应哪些条件。
- 这里最明确的加速结果是固定历史上的 replay throughput，不是完整在线智能体的端到端吞吐、任务成功率或普遍延迟改善；在线运行还包含长历史处理和工具执行成本。
- “总体接受率上升、匹配后的后期浏览行动下降”依赖任务匹配、阶段划分和统计口径。现有材料不足以判断这一规律能否稳定推广到更多智能体工作负载。