arXiv 2610.13889（被 CIKM 2026 收录）提出 RATED：Reliability-Aware Tool Retrieval via Execution Dynamics，作者是 Weiliang Chen 与 Song Liao。论文要处理的缺口很具体——工具检索这件事，目前几乎所有人都当成静态搜索在做。
典型流程是这样的：用户提一个请求，系统把请求编码，在工具描述库里找语义最近的若干个，交给规划器或模型去选。问题在于，工具描述是静态的，工具的可用性不是。当排在最前面的那个 API 恰好宕了、超时了、鉴权挂了、撞上速率限制了，检索器依然会一丝不苟地把它排在最前一位。智能体于是显得很蠢——而问题根本不在模型。
两段结构：召回靠语义，排序靠执行反馈
RATED 的做法拆成两段。其一是常规的语义匹配：一个冻结的双编码器加对比微调，把 query 和工具描述映射到同一空间，做候选召回。第二段是它的增量——一个轻量的上下文老虎机模块，用实时执行反馈对候选工具重排。哪个工具刚刚超时了、哪个正在报参数校验错误、哪个被限流了，这些信号直接改写后续的排序。
这个设计里有两个判断值得单独拎出来。
其一，它不重训模型。多数应对工具失效的思路是：改提示词、加重试、加验证器、再挂一个更大的模型。RATED 的全部适应能力都压在排序层上，换句话说，它改的是「选谁」，不是「怎么想」。这让它的成本结构和一次前向推理几乎一样。
其二，延迟增量小于 1 毫秒（相对纯编码推理）。这个数字可能比 52.2% 那个 MRR 提升更关键——因为它意味着这套东西可以放在生产栈的检索环节里，而不用引入新的模型调用或让规划慢一圈。
论文给出的数字是：真实查询上相对 ToolLLM API 检索器的 MRR 相对提升 52.2%；在 30% API 失败率的严重故障场景下，故障工具选中率从 86.2% 降到 2.9%。后者这组对比读起来有点反直觉——传统检索器在工具大面积出问题时，超高比例地推荐坏掉的工具。
配套发布的基准叫 EcoAgent，5,172 个真实工具、超过 21 万组 query-tool 对，同时覆盖离线检索与动态可靠性两个维度。这个规模的意义在于，它让「静态匹配好」和「动态故障下不崩」这两件以前只能分开测的事，能在同一个基准上同时看。代码与数据集已开源。
论文没展开、但决定能不能上线的一段
论文框架里有一处被默认值掩盖的假设：只要「调用失败」是个可观测信号，老虎机就能学到正确的经验。可现实中，失败至少有六种不同的含义。
端点确实宕了、持续超时、限流——这些是真故障，应当降权，而且是短时间窗内的降权。但参数 schema 写错、用户权限不足、模型幻觉出一个参数、供应商悄悄改了行为，这些是伪故障。如果把这两类混在一起喂给排序层，会发生一件很具体的事：动态重排把系统自己的 bug 藏起来了。工具越是被错误调用、越是被降权，于是越少被用到，于是那个 bug 越不容易被发现。
还有一层论文默认掉了：故障该按什么粒度记。支付 API 在某个区域失败，不等于它在所有区域都该降权；某个搜索 API 对一类查询返回空结果，也不等于它整体超时。按全局记、按租户记、按任务类型记、按时段记，会得到完全不同的排序结果。
一篇同期评述把落地顺序说得更实在：先从工具日志做起，把成功、超时、校验失败、鉴权失败、用户可见的任务成功分成五类分别记，然后再决定要不要引入老虎机，还要加护栏防止一段坏窗口永久污染一个本来好用的集成。这套建议的潜台词是——算法是容易的那一半，「什么算失败」这个定义才是难的那一半。
它补的是智能体栈里缺的那一层
把视角拉远一点看，工具检索这个环节在多数智能体栈里其实是残缺的。常见的栈里有：工具目录、一些嵌入、规划器、日志，也许还有重试。真正缺的是关于工具健康度的运行时记忆——不是关于用户的长期记忆，也不是关于文档的向量记忆，而是关于智能体自己所处的执行环境的运营记忆。
这也解释了为什么论文把 EcoAgent 做成「静态匹配 + 动态可靠性」双维度基准，而不是只做检索质量评测：智能体可靠性失效的位置常常在模型层之下，而这一层此前没有被系统性地测过，也没有被系统性地设计过。
需要留意的是，52.2%、2.9%、1ms 这些数字都来自论文自身的实验设置，包括故障注入的方式与基线的选择。基准本身也会简化现实——真实系统里一次调用失败可能同时是宕机加权限变更的叠加。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。