阿里这个新框架有点东西：Agent调用工具的Token消耗，一刀砍掉99%

今天看到阿里研究团队发了一个叫SkillWeaver的AI框架，核心数据是：Agent调用工具时的Token消耗直降99%。我花了一上午把这个东西研究了一下，结论是：它解决的确实是Agent落地最核心的瓶颈。

问题在哪：Agent"话太多"

用过Agent产品的人应该都有感受：让Agent帮你做一件事，它光是"思考要用哪个工具"就要消耗大量Token。比如你让它订张机票，它得先把所有可用的工具描述都看一遍——查天气、搜酒店、订机票、叫车、翻译……可能有几百个工具。每个工具的描述、参数、示例全塞进上下文，Token哗哗地烧。

当Agent面对上千个工具的时候，这个问题就变成了不可逾越的瓶颈。不是模型不够聪明，是它被信息淹没了。

SkillWeaver怎么做的：先理解任务，再找工具

阿里的思路跟传统框架完全反着来。传统做法是"把所有工具摆出来让Agent挑"，SkillWeaver是先让模型理解你要干什么，把复杂任务拆成几个子任务，再动态路由到对应的技能模块。

整个过程分三步：第一步Decompose，把用户需求拆成细粒度子任务；第二步Route，动态匹配技能而不是加载全部工具；第三步Weave，把多个技能串成可执行的工作流。因为每个子任务只加载相关的那几个工具，Token消耗直接砍掉99%。

为什么这个重要

Agent领域的共识是：2026年模型能力已经不是瓶颈了，瓶颈在工程层面。Agent要真正在企业里用起来，得能同时处理几十个不同类型的任务、调用几百个不同的工具。如果每多一个工具Token成本就线性增长，这个商业模式根本跑不通。

SkillWeaver解决的问题本质上是"Agent的可扩展性"。它让Agent在面对工具数量爆炸时，成本不跟着爆炸。这一点对Agent从demo走向生产至关重要。

实际体验会是什么样

我没有直接测试SkillWeaver（阿里目前是论文阶段），但从技术路线来看，它的效果应该是：同样的任务，响应速度更快、Token成本更低、准确率更高——因为Agent不用从几百个工具的噪声里做选择，只聚焦在当前子任务需要的那几个。

唯一需要关注的是：任务拆解和动态路由本身也需要消耗Token，框架的实际效率取决于"拆解+路由"的开销是否真的小于"全量加载"的开销。不过阿里给出的数据是99%的降低，说明至少在他们的测试场景里，账是算得过来的。

总结

Agent的这个瓶颈，所有做大模型应用的公司都会遇到。阿里的方案不是唯一的解法，但它指出了正确的方向：Agent的架构设计，比模型本身更重要。与其等一个更聪明的模型，不如让现在的模型更高效地工作。