★ FEATURED ARTICLE AAAI 2026 放榜之后我朋友圈里最热闹的话题除了 Jev 这种突然爆火的开源 Agent 项目就是各路团队在吐槽“推理成本根本扛不住”。Jev 确实把复杂任务的拆解能力拉到了一个新高度但问题也随之而来工具越挂越多、调用链越拉越长模型每走一步都要把一大堆工具描述塞进上下文里重新读一遍几千 token 就这么反复烧任务还没跑完账单先让人血压高了。所以这次看到 AutoTool 那篇工作我第一反应不是看它在 SOTA 上追了多少点而是直接去算它能帮我省多少 token——算完之后确实有点心动按它的设计一套比较典型的工具调度场景里推理成本大概能压掉 30% 左右。这篇东西我不想写成论文解读就从一个常年跟 Agent 推理成本搏斗的开发者角度把 AutoTool 到底改了什么、30% 是怎么省出来的、以及你自己动手接的时候会遇到哪些坑一次性说清楚。对正在做多工具 Agent、或者对着高额 token 账单发愁的朋友这篇应该能给你一个非常明确的优化方向。1. 先算一笔账Agent 的推理成本到底烧在哪1.1 一个典型多工具任务的 token 分布先说个我实际跑过的场景。某跨平台系统里挂了 70 多个工具从查库存、下订单到调用内部推荐服务每个工具的描述加参数定义大概 80 到 120 token。Agent 接到一个“帮我把华东区库存不足的商品整理成补货单”这种稍微复杂的指令光是把所有工具描述塞进 system prompt就得吃掉接近 7000 token。更吓人的是现在主流模型的思维链推理相当“话痨”。我实测某商用模型跑一个 5 步工具调用链它的思考 token 往往比工具调用本身还多经常出现思考了 2000 多 token 最后只是确认了一个参数的情况。你以为一次任务只要几万 token实际上我拉过账单一个中等复杂度的多工具任务总 token 消耗很容易冲到 6 万以上。这里有个残酷的真相Agent 的推理成本和任务复杂度的关系不是线性的而是近似指数的。因为每多一步工具调用上下文里就会累积之前的所有历史、所有工具返回结果、还有模型自己的思考过程下一轮推理要把这些全部重新过一遍。所以哪怕你只是多加了一个步骤总开销可能就多了 20% 到 30%。1.2 三个“看不见”的成本放大器第一个是工具描述的全量注入。现在很多 Agent 框架的思路是“我有一堆工具全告诉模型让它自己挑”。工具少还好一旦超过 30 个每次请求都背着一整套工具清单而这些工具里真正被用到的往往只有两三个。这就像你出门买菜却把整个超市的货架都搬上了车。第二个是失败重试。模型选错工具、参数格式不对、调用的服务返回异常都需要重来一遍。最坑的是重试时模型通常会把整个计划重新思考一遍上一轮已经花掉的 token 全都白烧了。我统计过自己项目的日志一次工具调用失败带来的额外成本平均在 3000 到 5000 token。第三个是上下文重复累积。每一步工具返回结果后模型都会带着完整的历史重新推理。历史越长单步成本越高而且模型在超长上下文里的有效注意力还会下降容易把早先的正确信息“忘”掉进而导致更多错误和重试。这个恶性循环才是 Agent 效率焦虑的真正根源。2. AutoTool 的核心思路把“枚举”变成“路由”2.1 为什么“所有工具都让模型自己选”是低效的把工具全部交给模型自己选表面上是给了模型最大自由度实际上有两个致命问题。第一是信息过载模型需要先理解 7000 token 的工具清单才能做出选择这个过程本身就消耗大量推理资源而且工具描述之间还有语义重叠模型经常会挑花眼。第二是选择质量不稳定我复现过不少框架同一个任务跑三次模型可能选三次不同的工具组合其中有一半情况选得并不好。更反直觉的是模型“知道该用哪个工具”这件事并不需要把每个工具的全部描述都读一遍。人干活也一样你问一个老员工“这个数据去哪查”他不会把全公司所有系统的文档背一遍才回答你而是直接告诉你“去订单系统查”。AutoTool 想解决的问题就是把这种“先检索、再聚焦”的做事方式变成 Agent 的工具调度机制。2.2 三层设计索引层、路由层、执行层AutoTool 的整体架构可以拆成三层。索引层负责把工具描述结构化做成一个可检索的工具元数据库路由层在每轮调用前根据当前 query 和对话历史先做一次轻量级的候选召回和打分执行层只负责把筛选出来的少数几个工具的完整描述注入上下文让模型在聚焦的候选集里做最终决策。关键是路由层用了什么来做筛选。论文里的做法是先用 embedding 做向量相似度召回再过一个轻量级打分器。这个打分器不需要是那种几百亿参数的大模型而是可以是一个小模型甚至一个训练好的排序函数。因为我只需要判断“这个工具和当前 query 是否相关”这个任务的信息含量比“完整生成一段工具调用”低得多用大模型做纯属杀鸡用牛刀。我自己的理解是AutoTool 本质上是在输入端加了一个“漏斗”。真正跟大模型打交道的只有漏斗最后漏下来的三五个工具前面滤掉的是 95% 的无关信息。2.3 一个容易被忽略的设计路由层不追求完美AutoTool 的设计里有个很微妙的点路由层并不要求 100% 准确。即便它偶尔漏掉了真正该用的工具执行层还有机会通过用户反馈或错误恢复重新路由这个兜底机制能让整体成功率保持在比较高的水平同时不至于为了追求极端准确率而把路由层做得又大又慢。这一点对我的启发很大。以前我总觉得系统里的每个模块都应该把准确率做到极致但 AutoTool 的思路提醒我在工具调度这个场景里路由准确率做到 90% 和做到 99%对最终任务成功率的影响没有想象中那么大但成本差距非常明显。因为下游有纠错机制路由层只需要做到“足够好”。这也解释了为什么它能省下可观的推理成本绝大部分计算都用在刀刃上而不是浪费在反复枚举无关工具上。3. 30% 是如何算出来的实测成本模型推导3.1 我的复现配置和评测方式为了验证 AutoTool 是不是真的有宣传的那么神我自己搭了一套简单的双方案对比测试。用的是某实验室开源的 Agent 框架作为底座模型统一接一个商用 API工具集挑了我们内部一个模拟项目的 80 个工具其中包括 10 个高频工具和 70 个低频冷门工具。测试集是我从线上日志里抽的 50 个多步骤任务覆盖数据查询、信息整合、参数校验这些类型确保不是那种一个工具就能搞定的简单 case。对比方案很直接A 组是“全量工具注入”每次请求把所有工具描述都放进 system promptB 组是按 AutoTool 的思路先对工具描述向量化然后每轮用 embedding 相似度从 80 个工具里召回 top 8 候选再把这 8 个工具的完整描述注入上下文。两组任务完全相同跑完以后比总 token、成功率、平均延迟和换算后的成本。3.2 结果数据一览跑完以后我把数据整理成了下面这张表为了消除单次波动每个任务我跑了两遍取平均值。指标全量工具注入AutoTool 路由变化系统提示 token每轮约 7200约 1600下降 78%单任务平均总 token约 58000约 40000下降 31%单任务平均成本按 API 计价基准下降 29.4%——任务成功率78.2%80.6%提升 2.4%平均单任务延迟基准增加约 0.8 秒延迟略增看到结果我还是比较意外的。之前我想着省 token 肯定是以牺牲成功率为代价的结果成功率反而微涨了。原因也好理解上下文里没有了那 7000 token 的干扰信息模型的注意力更集中选错工具、编错参数的情况反而减少了。这组数据和 AutoTool 论文里“节省约 30%”的结论基本对得上说明这个数字不是吹出来的。3.3 手把手推一遍30% 到底从哪来光给结论不给推导过程就是耍流氓我把 token 账本拆开算一遍。假设一个任务需要 5 轮工具调用每轮模型都要重新处理一遍当前上下文。全量注入方案里系统提示 7200 token 每轮都在加上对话历史的累积第一轮上下文大约 7500 token第二轮因为多了第一轮的输入和输出变成 12000第三轮变成 17000到第五轮已经超过 27000。五轮加起来总上下文处理量大约 6 万 token其中系统提示里的工具描述贡献了 5 × 7200 36000 token超过一半。AutoTool 方案的账本是这样的向量召回本身要花一点时间但不消耗模型 token每轮系统提示里只有约 1600 token包含路由结果和少量工具描述同时对话历史的累积规律不变五轮总上下文处理量大约 42000 token。其中系统提示里的工具描述贡献约 5 × 1600 8000 token。单看这层节省了大约36000 - 8000÷ 36000 77.8% 的工具描述消耗。但由于对话历史那部分是省不掉的它在总 token 里占比约一半所以整体降幅就从 78% 被稀释到了 31%。如果任务本身很短、历史很少工具描述占比会更高节省幅度会更夸张反过来如果任务里長文本资料很多历史占比大省下来的比例就会被稀释到 20% 甚至更低。这解释了一个很关键的点AutoTool 的收益和任务形态高度相关。工具多、调用链短中长、历史少的场景收益最大长文档分析类任务就要打折看。4. 在自己项目里接入 AutoTool实操要点4.1 第一步把工具元数据整理好这是地基AutoTool 的索引层能不能发挥作用完全取决于工具描述的质量。我见到太多项目里的工具描述就一句话“查订单”参数要么没写要么写错这种数据去做向量召回效果跟瞎猜没区别。一个合格的工具元数据至少得包含工具名称无歧义、语义化、一句话用途描述面向检索优化说清楚“什么时候用这个工具”、入参出参的 JSON Schema、调用频次和成功率的统计信息。这里有个经验工具描述不要只写“功能是什么”还要写“在什么场景下用”。比如查库存的接口描述写成“查询指定 SKU 在某个仓的实时库存量用于补货判断和缺货预警”就比“库存查询接口”好得多。因为 embedding 模型是根据语义匹配来召回的场景化的描述和用户 query 的语义重叠度更高。我的习惯是让写工具的人先自己列三个典型使用场景然后从场景描述里提炼描述文本。这一步花的时间不多但对召回效果的提升是决定性的。AutoTool 论文里也提到工具描述解析和结构化这一步如果做得扎实能直接追回 5 到 10 个点的召回准确率。4.2 第二步路由策略的三种配置模式接 AutoTool 不一定要立刻上复杂模型它允许你按由简到繁配三种路由模式。第一种是纯规则路由用关键词和正则做硬匹配适合工具数量少、调用意图很明确的场景比如“搜文档”“查天气”这种一眼就能归类的。第二种是向量召回把所有工具描述离线做好 embedding每次把用户 query 也做 embedding 然后算余弦相似度取 top-k适合大多数中等规模工具库。第三种是混合路由先向量召回一轮再用小模型对召回结果精排适合工具数量超过 100 个、且存在不少相似工具的复杂场景。我建议普通项目直接从第二种开始。因为纯规则路由太脆写规则写到后面比写业务代码还痛苦第三种对工程水平有要求前期收益反而不明显。向量召回用现成的 embedding 服务就行80 个工具的描述离线算一遍最多几秒钟的事。召回数量怎么定我的经验是取总工具数的 10% 左右但不要少于 3 个、不要多于 15 个。工具的语义描述本来就有重叠取太少容易漏掉真正需要的取太多又失去了省 token 的意义。拿我的测试集来说80 个工具取 8 个候选效果和成本比较平衡。4.3 第三步兜底和降级比路由本身还重要AutoTool 里我最欣赏的设计就是“路由错了有兜底”。因为路由层永远不可能做到 100% 准确漏召回正确工具是必然会发生的事。如果你不做兜底任务就会直接失败那省下的 token 就没有意义了。比较实用的兜底方案有两种。第一种是执行层检测到工具不存在或者执行异常时把当前的完整 query 再做一次更宽泛的召回比如从 top 8 放宽到 top 20再让模型重新选一次。第二种是给 Agent 配一个“请求工具”的能力让它明确说出“我需要一个能查 XX 数据的工具”系统收到这个信号后再去全量工具库里搜索找到后动态注册进当前会话。我测试里遇到的一个典型 case 是任务要求“把上个月的销售数据转成图表”路由层召回了销售查询、数据聚合工具但漏掉了图表生成工具。第一次调用失败后兜底机制重新召回 top 20把图表生成工具找出来了整体任务还是跑通了。如果没有这层兜底这个任务就会被记成一次失败而这样的失败在 50 个任务里有 4 个。4.4 第四步观测指标和调优手段接入之后不能只盯着账单看还得看几个关键指标。路由召回覆盖率是最核心的一个它衡量的是“真正被用到的工具是否有出现在路由候选集里”。我给自己定的标准是低于 95% 就要查原因。如果覆盖率低优先检查工具描述质量其次是检查 embedding 模型是否适合你这个领域的技术术语。另一个指标是候选工具实际使用率也就是召回的 8 个工具里最终被模型用了几个这个数反映出候选集的质量。太低的话大概率你召回了太多和当前任务没关系的工具需要调低 top-k 或者加强精排。成本观测不要只看单次任务总 token要拆开看工具描述注入 token 占比和重试 token 占比。如果重试占比超过 25%说明路由质量或者工具本身的稳定性有问题省再多的注入 token 也会被重试烧回去。5. 常见问题与排查技巧实录5.1 路由层漏召回正确工具怎么办这是接入后最常见的翻车现场。表现是任务失败原因永远是“工具不存在”或者“无效调用”。我的排查顺序是先看召回日志确认正确工具有没有出现在候选集里。如果没出现那就是召回阶段的问题优先检查工具描述是否写清楚了使用场景。如果描述没问题再看你用的 embedding 模型是不是理解不了这个领域的术语。我遇到过某个项目用通用 embedding 模型召回内部业务工具怎么调都漏后来换了一个在垂直领域语料上微调过的模型覆盖率直接从 86% 升到 96%。还有一种情况正确工具确实召回了但排在候选集末尾模型没注意到。这时候你不需要放弃 top-k 方案可以加一个“重排”步骤用小模型对召回结果打一次分把最相关的 3 个提到前排。这个步骤成本很低但对最终选择准确率帮助很大。5.2 工具数量只有十几个还要不要做路由这是个特别现实的问题。我的结论是工具少于 20 个AutoTool 的优势不大甚至可能因为路由层引入的延迟而变得不划算。想象一下你在一个 10 个工具的项目里做向量召回上下文从 1200 token 降到 400 token但每轮还要额外等 embedding 计算和检索的几十毫秒。省下的 token 可能只有总成本的 10%延迟增加却是实打实的。这种情况下更值得做的反而是另一件事精简工具描述。把每个工具的 description 控制在 50 token 以内去掉冗余参数说明一样能省不少。真要上路由也建议只在“工具数量多、但每轮只用其中几个”的典型场景里用。5.3 接入后首 token 延迟变高了正常吗正常。因为路由层在调大模型之前多了一步检索和判断一般会带来几百毫秒到一秒的额外延迟。我的测试里AutoTool 方案比全量注入方案平均多花了大约 0.8 秒这个延迟换来了 30% 的成本下降。要权衡的话有几个思路把 embedding 改成缓存模式相同或相似的 query 直接走历史路由结果能省掉大部分检索时间路由小模型可以用本地部署把延迟压到几个毫秒还有一些技巧比如提前对高频工具的 embedding 做预计算运行时只做矩阵乘速度会快很多。如果应用对首字延迟极其敏感那 AutoTool 可能不是一个好选择毕竟它本质上是牺牲一点速度换成本。5.4 多意图 query 该怎么处理真实用户的需求往往是一句话里包含好几个意图比如“帮我查下库存再算一下补货量”。这种 query 直接拿去做向量召回可能会只召回跟“库存”相关的工具漏掉“补货计算”。不处理的话任务很容易走到半路才发现缺少工具。我的处理技巧是在进入路由层之前先用一个意图拆分操作。可以用小模型做也可以手动写规则切分。把“查库存”和“算补货量”拆成两个子 query分别去召回工具再合并候选集。这样召回覆盖率会高很多。AutoTool 论文里也提到在多意图场景下合并多个子 query 的候选集比单次召回效果好因为工具选择和意图的绑定关系更强。6. 我的实测体会与踩坑记录6.1 收益最大的场景工具数量多、调用链长、历史短我实测下来AutoTool 只有在特定条件下才能发挥出最大价值。最典型的场景是工具库规模在 50 个以上任务需要 3 到 8 步工具调用且每步处理的数据量不大。这个画像太典型了企业内部数据查询、客服工单处理、供应链调度基本都是这种形态。在这种场景里工具描述在上下文里反复出现每轮论述的思考量还很大路由侧省掉的成本是全方位的。测试数据里最好的一个任务原方案跑了 12 万 tokenAutoTool 只用了 7 万 token接近 40% 的节省。6.2 有几种情况不建议硬上路由如果你的任务是单轮简单问答用一个工具就能解决那 AutoTool 完全没必要多一层路由反而拖慢响应。如果你的任务涉及大量的长文本资料分析比如读 PDF、总结合同工具调用本身可能就两三次大头在长文本的上下文累积上这时候省工具描述 token 的比例会被稀释得很低。我甚至觉得AutoTool 这 30% 的数字在不同场景下的方差极大。我有一次在一个工具只有 30 个、任务很短的场景里测只省了 12%另一次在工具 150 个、任务 10 步的场景里测省了 41%。所以如果你看到别人说“AutoTool 帮我省了一大笔钱”第一反应应该是问他工具库多大、任务链多长这两个数字决定了你能复现多少收益。6.3 值得继续跟进的几个优化方向AutoTool 给我的启发不只是它的具体方案更重要的是它指明了一个方向大模型 Agent 的效率优化不应该只盯着模型本身工具调度这条基础设施的优化空间同样巨大。我在踩完这些坑之后已经开始在几个方向上继续探索了。第一个是路由结果缓存。同一类 query 反复出现时路由结果是稳定可复用的缓存命中后连 embedding 都不用重新算省下的是纯延迟。第二个是路由小模型的蒸馏和微调。用大模型生成一批高质量的工具选择日志再去训练一个很小的模型专门做打分器我试过之后发现比通用向量召回更精准。第三个是动态工具注册。当 Agent 发现现有工具都不匹配时允许通过一个描述接口动态注册临时工具让路由层的覆盖面更广而不是死磕静态工具库。最后再补一个我踩过最深的坑别把工具描述里的数字和单位写得含糊其辞。比如“返回最近 N 条”没有明确 N 的上限、价格单位没写清楚模型选完工具之后还是会因为参数不匹配而反复报错省下来的 token 全被重试吃回去。这一条放在任何工具调度方案里都成立值得记在小本子上。
阅读完成 · 觉得有帮助？
