你让 AI 助手安装软件、跑测试或查询数据库，它常会停下来等工具返回。模型此时没有继续计算，先前对话的 KV Cache——模型保存上下文中间计算结果的“草稿纸”——却可能一直占着 GPU 显存。赶走它，工具马上结束时又得重新计算或搬回来；留着它，正在工作的请求可能没地方可用。
论文《Ask the Tool, Don’t Guess》换了一个很直接的思路：不要在工具启动前猜它要跑多久，而要在运行中读取真实进度，再决定缓存留下、迁出，还是提前恢复。论文所有效果数字目前均来自作者自己的实验，尚无独立信源交叉验证。
猜时间，偏偏在最难猜时最重要
今天的服务系统会参考工具名称、历史耗时、调用前声明的预计时长，或引擎当前有多忙。问题在于，同一条命令的耗时不只由命令决定，还受机器负载、相邻任务和远端服务状态影响。
作者重放编码 Agent 的工具调用时发现，同一命令在空闲沙箱中可快一个数量级；加入繁忙的相邻任务后，多数调用又会慢数倍。生产负载下长任务的耗时排序，与空闲机器上的排序没有相关性。换句话说，预测器甚至未必能判断两个任务谁先结束。
这不是边角问题。在 mini-SWE-agent 的 SWE-bench 排行榜运行记录中，不到 3% 的工具调用占了近三分之二的工具总耗时，主要是安装、构建、测试和 Agent 生成的脚本。短调用怎么调度差别不大，真正占资源的恰好是最容易受环境影响的长调用。
工具其实知道自己跑到哪了
编译器可能正在处理第 40 个、共 66 个文件；测试程序会逐个打印完成标记；下载工具也知道何时进入最后阶段。只是这些信息常被关掉、截断或重定向了。作者发现，mini-SWE-agent 会预先关闭部分进度条；在他们自己的运行中，Agent 又把六分之五的工具时间藏在 tail、静默参数或文件重定向之后。
论文把可恢复的信息分成两档。强信号能给出剩余工作比例，例如“完成 40/66”；弱信号不能可靠估算百分比，但能准确提示“快结束了”。后者已经足以让系统开始把缓存搬回 GPU。
在三组统计中，强信号分别覆盖 38%、51% 和 48% 的工具时间；算上弱信号后，覆盖率升至 66%、59% 和 72%。剩余调用包括无需管理的短任务、自己声明期限的任务，以及难以解析的远端 API 或等待人工反馈等情况。
关键不是多显示一根进度条
作者设计了一个 harness——夹在 Agent、工具和服务系统之间的执行层。它给进度另开一条旁路，而 Agent 继续收到原来的输出和退出状态。
如果进度条被环境关闭，harness 会恢复它，再从 Agent 看到的结果中移除；如果输出被 tail 截断，它会在旁路保留完整副本。遇到只报当前计数、不报总数的构建任务，它先用 dry run（只演练、不真正执行）取得总量；若信息没有打印出来，还可观察工具在磁盘上逐个生成的目标文件。对 Agent 自己写的脚本，系统可加入进度报告，并通过比较输出、退出状态和任务成绩检查行为是否保持一致。
这些信息最终被统一成事件流：调用编号、已完成工作、总量、当前阶段和时间戳。若计数超过原先取得的总量，系统会撤回比例，退回到较弱的计数信号，避免把错误的“100%”当真。作者报告，这套包装层对现实调用的墙钟时间增加不到 1%；在其 100 个 SWE-bench Verified 任务样本中，也没有测出 Agent 得分的显著变化。
进度比历史更接近现场
系统主要在两个时刻需要判断：显存紧张时，该赶走谁的缓存；工具将结束时，何时把缓存取回。
在调用进行到一半时，实时进度对剩余时间的中位误差约为调用总时长的五分之一，最佳历史预测器约为三分之一。进行到 90% 时，实时进度的中位误差低于 10%，最佳历史预测器则为 80%。混用不同运行环境的历史后，预测器在接近结束时还会再差一个数量级；实时信号直接读取当前执行速度，环境变化只会造成数秒的适应延迟。
作者随后把这些提示接入 vLLM，并在 4 张 H100 SXM GPU 上重放 Agent 会话。与 LRU——优先处理最久未使用缓存的常见策略——相比，纯 GPU 显存配置下，工具返回后的 p90 TTFT 降低 20.7%；加入 DRAM 作为较慢的缓存层后，降低 20.8%。TTFT 是“首个词元等待时间”，p90 表示九成请求不超过的等待门槛。带 DRAM 时，该方法和知道准确返回时间的 oracle 都只产生了约 LRU 三分之一的重新加载量。
收益主要来自长调用。按论文报告，工具调用至少持续 2 秒时，平均 TTFT 改善约四分之一；至少 10 秒时约三分之一；至少 30 秒时约 40%。这也解释了为什么整体平均改善只有约一成：大多数调用很短，系统根本来不及驱逐缓存。
为什么值得关注
这项工作的价值不只是一种更准的耗时预测。它改变了问题的方向：系统不再试图从命令名称和旧记录推测未来，而是让正在执行工作的工具报告现场状态。对于需要频繁等待搜索、数据库、构建或测试的 Agent，这类信息可以成为服务系统的资源信号，而不必进入模型的对话内容。
论文还触及了可信度问题。工具输出可能由租户控制，脚本也可能谎报“已完成 90%”。作者提出信用账本：报告准确便积累信用，系统依据报告采取行动会消耗信用，事后发现错误则扣减；信用耗尽后退回无进度信号的普通策略。论文仅给出初步模拟：说谎让相关会话多占了 6% 内存，账本收回其中 5%。这还不足以证明机制已能应对真实攻击。
局限与未知
- “接近 oracle”缺少统一差距定义。论文也显示，一分钟以上的少量调用中，该方法的收益会回落；作者的分阶段回放表明，继续提升的重点是扩大信号覆盖，而不只是把已有进度算得更准。
- 20.7% 和 20.8% 来自作者在特定硬件、负载与回放设置下相对 LRU 的结果，不能直接外推到所有生产系统。
- 仅凭供稿无法确认论文是否经过同行评审或代码是否开放；不同 Agent 模型还会以不同方式压缩工具输出，使可恢复的长调用信号约在三分之一到一半之间。