一句话：别让推理引擎猜它的工具能告诉它的事
9 月 16 日提交的论文「Ask the Tool, Don't Guess」（arXiv 2609.18849）盯上了一个所有人都知道存在、却很少有人正面处理的问题：agent 请求的大量墙钟时间耗在等工具上，而这段时间里，那份数十 GB 的 KV cache 一直占着 GPU 显存。留下、驱逐还是换回——推理服务系统每天都在做这个决定，而它做决定的依据，是猜。
论文作者来自系统方向的头部团队，他们给出的论断干脆利落：调用开始之前，任何估计都不可能预知这次工具要跑多久——用工具名、历史时长、声明值还是引擎占用率，都一样，这类估计甚至排不出调用的先后顺序。与此同时，一个讽刺的事实是：正在运行的工具自己知道答案，只是 agent 技术栈把它静音了。
提议：让工具报进度，让 harness 去听
解法在架构上相当克制：不发明新调度算法，不要求重写 agent，而是让工具在运行中主动上报进度——「还剩几分之几」或者「快结束了」。论文对四份公开 agent 语料做了普查，发现一旦信号被揭示，多数工具时间里都存在可读的进度信息，且强度分两档：剩余工作占比，或者精确的临近结束信号。
关键设计在于「不改 agent 看到的东西」：harness 层回收这些信号，用于服务系统的 cache 决策，agent 的输入与输出一个字都不变。实测下来，agent 在基准上的分数没有可测变化——优化发生在基础设施层，与智能体行为完全解耦。这种「加一句话就能上生产」的克制，是这篇论文从学术走向工程的最短路径。
效果：接近神谕的两成收益
把进度信号接进生产级推理引擎后，数字是这样的：在 KV cache 决策点上，上报的进度比已发表的最佳预测器准确数倍到一个数量级；而且环境变了它依然准——因为它量的是工具自己报的事实，不是从历史数据里拟合出的相关性。落到端到端指标，工具调用后的 p90 首字延迟（TTFT）对比 LRU 基线下降约两成（仅 HBM 与 HBM 加 DRAM 两种配置均如此），已接近理论神谕值。
两成听起来不算惊人，但要放在上下文里读：这是在 agent 负载最痛的位置上拿到的——工具等待期恰恰是 TTFT 尾延迟的主要来源，而尾延迟直接决定交互式 agent 的体验下限。加上改动只是给工具加几行上报提示，这笔投入产出在工程上几乎没有争议。
为什么这个方向此刻重要
把这篇论文放进近期的行业脉络里，能看到一条正在成形的线：基础设施正在为 agent 负载重新设计。推理云在并购执行沙箱厂商，计费体系在为智能体引入新的计量单位，而现在轮到了调度与缓存层——agent 请求的形态（长任务、多轮工具等待、上下文反复复活）与传统 chat 请求完全不同，为后者设计的 LRU 类策略在前者身上自然水土不服。
这篇论文的更普适启示在于信息流向：系统各层之间，最便宜的优化往往不是更聪明的预测，而是让掌握事实的一方直接说话。服务系统猜工具时长猜了几代，答案其实一直在被猜的对象手里。对做 agent 平台的团队，值得检查自己的技术栈里还有多少处「正在静音的事实」——工具的进度、沙箱的状态、数据源的新鲜度，每一处被揭示的信号，都可能换回一份延迟或成本的下降。
至于落地上手，论文给出的路径足够轻：harness 侧加回收逻辑，工具侧加上报提示，服务引擎通过少量改动消费信号。标准化的进度上报协议是否会出现、推理引擎厂商何时内建支持，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。但方向已经清楚：agent 时代的服务系统，应该学会向它的工具提问，而不是替工具编答案。