为什么值得读
做 Agent 推理加速的人如果只看一个全局接受率指标，很容易在「看起来在变好」的曲线上做错优化。这篇的价值一半在指标拆解，一半在训练策略：草稿模型该在哪些中间轮次上监督。
问题：聚合指标把不同的决策混成了一个数
Agent 的一次任务由反复的模型调用组成，历史里混着推理、动作和工具返回。已有投机解码的评估通常报一个平均接受率，但这对「该在哪里补草稿监督」几乎没有指导意义——它把差异极大的决策类型平均掉了。
论文的做法是把轨迹评估和自适应草稿训练接起来：动态执行 + 固定前缀回放，并构建 TraceSpec-Traj 语料，含 10,000 条训练状态与 2,500 条测试状态，覆盖浏览（browsing）与软件工程（SWE）两类负载。
发现：上下文变长，总接受率升、局部接受率降
对五个投机解码基线做拆解后，作者报告了一个反直觉现象：聚合接受率会随上下文变长而上升，但在匹配的同类型「后段浏览动作」内部，接受率是下降的。
也就是说，长上下文把大量容易预测的 token 混进了分母，掩盖了真正难的位置在变难。工作负载类型和执行阶段会进一步把这些趋势分开——这正是按轨迹条件做监督的动机。
方法：在中间 assistant 轮次上训练，按状态分配预算
TraceSpec 在中间 assistant 轮次上训练草稿模型，并用「状态条件下对前缀感知接受率缺口的估计」在固定预测预算内做分配。
相对其基线 DSpark，在三个目标模型尺寸、两个温度设置下，回放吞吐提升 12.5%–22.6%。在 Qwen3-4B 上的消融显示，相比固定「整轮全监督」，自适应分配让平均接受长度提升 3.3%–10.0%；另有对比支撑了状态条件与连续 token 一致性两项设计的作用。
可直接复用的部分
即便不换草稿模型，论文的拆解口径也值得抄：按工作负载 × 阶段 × 动作类型分桶看接受率，而不是只看全局均值。这能立刻定位「哪一段在拖后腿」。
TraceSpec-Traj 提供了现成的训练/测试状态切分，适合用来评估自家草稿模型在 Agent 负载上的真实收益，而不是在单轮 chat 数据上刷接受率。
本站仅据 arXiv 摘要页（E1）整理，未复现、未读全文；吞吐提升相对的是 DSpark 基线，不是与所有投机解码方案的横向对比；语料只覆盖浏览与 SWE 两类负载，其他 Agent 场景（如代码执行、多模态工具）需自行验证；摘要页检索未发现代码仓库链接。
本文基于论文原文摘要与方法章节整理，观点由编辑撰写；如与原文有出入，以 arXiv 原文为准。 内容为信息整理与技术评论，不构成投资或决策建议。 发现错误请通过站内纠错页提交（记录可查），修订记录只增不删。