AgSpec 用会话与工作区语料加自适应草稿长度，把编码智能体的生成吞吐提升到自回归解码的 4.37 倍

AgSpec 把检索式推测解码的语料按文本来源拆成会话、工作区与全局三类，并让工作区文件以智能体实际输出的形式（如统一 diff 中带空格或减号前缀的行）被索引，从而让智能体反复复现的代码、日志与先前尝试变得可检索。 既有检索式方法只索引当前调用、预建数据存储或跨请求汇总的输出，语料覆盖不全，且按智能体读取时的形式存储文本，与智能体生成时的 token 序列不一致。 论文以 trace 驱动的模拟在 SWE-bench Verified 上比较不同语料配置的期望接受长度：把每次调用的语料换成会话语料带来最大增益，工作区语料单独增加一部分，叠加后达到仅用全局语料时的数倍；输出形式索引在第一轮把 coder 的接受长度提升最多，第二轮起因补丁本身已进入会话语料而增益下降。

AgSpec 用离线画像得到的每智能体草稿上限约束草稿长度，并用验证反馈在线调整长度缩放，使草稿长度跟随不同智能体、不同轮次间接受长度的差异与漂移。 既有方法的草稿长度要么是服务前固定的静态上限，要么只按匹配长度或出现次数缩放，从不依据验证结果修正，也不区分角色与轮次。 在 SWE-bench Verified 上用 Devstral 与 SAM-Decoding 引擎的对照显示：batch size 1 时长草稿比短草稿快 14%，batch size 16 时反而慢 30%；AgSpec 在两个 batch size 下都最快，分别高出 25% 与 16%，每步拒绝的 token 数最多为 6，而长草稿方案拒绝 11–26 个；仅启用在线缩放即把吞吐提升 66%，拒绝草稿占比从 78% 降到 50%。

AgSpec 作为不改动检索引擎的框架，可叠加在 SAM-Decoding 与 SuffixDecoding 两种引擎之上，并同时提升两者的吞吐与接受长度。 论文把 AgSpec 定位为与检索引擎正交的策略层，只补齐语料与草稿长度策略，而不替换匹配机制。 叠加 SuffixDecoding 时吞吐平均提升 16.5%、接受长度提升 18.5%；叠加 SAM-Decoding 时吞吐提升 64.6%、接受长度接近翻倍；虽然 SAM-Decoding 在全部十二个设置中都落后于 SuffixDecoding，AgSpec-SAM 在其中九个设置中反超。

AgSpec 的收益不限于仓库级多智能体场景，在无仓库的 LiveCodeBench 与单智能体的 Terminal-Bench 上同样有效。 论文用这两个基准分别检验缺少仓库工作区、缺少显式角色分工时的泛化性，此时 AgSpec 退化为共享上限与单一缩放表。 LiveCodeBench 上较快的 AgSpec 变体达到自回归解码 4.87–7.94 倍吞吐，超过最快的既有推测方法 35–145%；Terminal-Bench 上吞吐比最快的既有推测方法高 9.3–27.2%，接受长度比对应检索引擎基线高 16.7–34.3%。

AgSpec 面向编码智能体流水线，尤其是仓库级、多智能体、多轮会话的场景；它假定检索引擎能查询多个语料并接受每步草稿长度，因此适用于 SAM-Decoding、SuffixDecoding 这类引擎。收益最大的情形是会话内反复复现代码与工具输出、工作区文件被智能体以补丁形式写回；在无仓库的 LiveCodeBench 与单智能体的 Terminal-Bench 上，它退化为共享上限与单一缩放表，仍能带来提升。全局语料按模型与基准各建一份并在服务前固定，会话与工作区语料在会话结束后释放，因此该方法适合按会话隔离语料的部署方式。

论文报告的是生成吞吐与接受长度，未涉及任务成功率或输出质量的变化，因此加速是否影响解题结果仍是开放问题。全局语料按模型与基准分别构建，跨模型或跨仓库的语料复用效果尚不清楚；工作区语料跨会话增长未带来明显收益，作者把多会话共用同一仓库的情形留作未来工作。草稿长度控制中的缩放更新在理想化假设下对应分位数损失，实际中因会话有限、分布漂移而不收敛，只在目标附近波动。此外，本次读取的是论文全文，但部分表格与图的具体数值在文本中以区间或占位形式呈现，若需精确对比各基线的逐项数字，仍需查阅原文图表。