阿里新技术：免加载工具，Token成本直降99%

想象你走进一家有 2209 道菜的超级餐厅，服务员不给你菜单，而是把每道菜的食材、做法、口味描述全部念给你听——念完大概要 3 个小时。等你终于听完，你大概率已经忘了前面说了什么，随便指了一道，结果还不是你想吃的。

这就是今天 AI Agent 面临的困境。当企业接入了成百上千个工具，Agent 要做的不是"能不能用"，而是"该用哪个"。阿里巴巴研究院最新提出的SkillWeaver框架，用一种全新的思路解决了这个问题——不念菜单，按需上菜。在 2209 个真实 MCP 技能的基准测试中，Token 消耗从 884,000 降到约 1,160，降幅超过 99%，同时准确率大幅提升。

1 暴力塞入：当前 Agent 工具调用的死胡同

当前主流的 Agent 工具调用方式，本质上是"暴力塞入"——把所有工具的描述文档一股脑塞进 LLM 的上下文窗口，让模型自己选。就像把整本百科全书摊在桌上让你找一条信息，效率可想而知。

当企业级 Agent 接入 MCP 生态中成百上千的工具后，三个致命问题立刻暴露：

Token 爆炸— 2209 个技能描述全部塞入提示词，单次查询就要吃掉约 884,000 Token。按 GPT-4 的定价，一次工具选择的成本就高得离谱

选择混乱— 即使使用超大参数模型 Qwen-Max，在 2209 个工具面前，正确检索率仅 21.1%。模型被海量选项淹没，就像在 2209 道菜里盲选

上下文溢出— 绝大多数 LLM 的上下文窗口根本装不下这么多工具描述，直接导致截断或报错

"Exposing an entire library to an LLM to find the right tool is highly inefficient, quickly overwhelms context limits, and consumes hundreds of thousands of tokens." — VentureBeat

暴力塞入 vs 精准路由：Token 消耗对比

暴力塞入（LLM-Direct）

2209 个工具描述全部塞入

LLM 上下文窗口

~884,000 Token · 21.1%

又贵又慢又不准

VS

精准路由（SkillWeaver）

2209 工具→索引→Top-K

LLM 上下文窗口

~1,160 Token · 大幅领先

又省又快又准

更深层的问题是：现有工具路由框架大多将路由视为"单技能选择"问题——每次只选一个工具。但真实的企业查询天然是组合式的。"下载数据集、转换格式、生成可视化报告"这样的需求，一个工具根本搞不定，就像做一道菜不能只靠一把刀。

2 SkillWeaver 三阶段架构：分解、检索、组合

SkillWeaver 的核心思路可以用做菜来类比：先想好要做哪几道菜（分解），再去冰箱拿对应的食材（检索），最后按顺序下锅（组合）。三个阶段形成一条从模糊需求到可执行工作流的完整管线：

Decompose

任务分解

拆为原子子任务

Retrieve

技能检索

语义匹配 Top-K

Compose

计划组合

生成 DAG 执行图

↑ SAD 反馈环路贯穿始终 ↑

用户查询 → 子任务序列 → 候选技能集 → 可执行工作流

以"下载数据集、转换格式、生成可视化报告"为例，走一遍完整流程：

Step 1 — Decompose（想好做哪几道菜）拆解为三个子任务：① 下载数据集 ② 数据转换 ③ 生成报告

Step 2 — Retrieve（去冰箱拿食材）语义检索召回候选：

任务① → api-client、http-fetch

任务② → csv-parser、etl-pipeline

任务③ → chart-gen、report-builder

Step 3 — Compose（按顺序下锅）评估兼容性，最终选择 api-client → csv-parser → chart-gen，输出可执行的 DAG 工作流

什么是 DAG？

DAG（有向无环图）听起来吓人，其实就是一张"工序流程图"。想象做一桌菜：洗菜和煮饭可以同时进行（并行），但炒菜必须等洗菜完成（依赖）。DAG 就是把这种"谁先谁后、谁能并行"的关系画成一张图。SkillWeaver 在 Compose 阶段输出的就是这样一张图——Agent 拿到图后，能并行执行的步骤就并行，有依赖的就按顺序来，效率最大化。

DAG 示例：下载数据集 → 转换格式 → 生成报告

api-client

下载数据集

csv-parser

格式转换

chart-gen

生成报告

Step 1（无依赖）→ Step 2（依赖 Step 1）→ Step 3（依赖 Step 2）

有依赖关系按顺序执行，无依赖的可并行——这就是 DAG

3 SAD：让 LLM 学会用"工具的语言"说话

SkillWeaver 最核心的创新不是三阶段管线本身，而是穿插其中的反馈环路——迭代式技能感知分解（Skill-Aware Decomposition, SAD）。

先看一个生活中的类比：你去外地出差，问路人"附近有超市吗？"对方一脸茫然——因为当地人管超市叫"合作社"。你用你的词，他用他的词，沟通就断了。SAD 解决的就是这个问题。

LLM 分解任务时，倾向于生成通用、模糊的步骤描述（"获取数据"），而技能库中的工具使用特定技术术语（"api-client"、"http-fetch"）。词汇不匹配，检索就失灵——就像你问"超市"，地图上标注的是"合作社"，永远搜不到。

SAD 反馈环路：生成 → 检索 → 回注 → 重写

① LLM 分解

"获取数据"

② 语义检索

找到 api-client 等

③ 回注工具描述

"库里有 api-client"

✓ 对齐完成

词汇与工具库匹配

④ LLM 重写

"用 api-client 获取"

↻ 再次检索

就像当地人告诉你"我们这儿叫合作社"，你下次就会用对名字

SAD 本质上是一种"对齐"机制——它让 LLM 的思维框架从"我该怎么做这件事"转向"这个工具库里有现成的什么能力可以组合"。就像你学会了当地人的叫法，下次问路就能精准命中。

SAD 效果对比：分解准确率提升

7B · 无 SAD

51.0%

7B · + SAD↑33%

67.7%

14B · 无 SAD⚠ 反直觉！更差

Qwen-Max · + SAD

92%

配置

分解准确率

SAD 加持后

Qwen2.5-7B（原始）

51.0%

67.7%

Qwen-Max（大模型）

92%

在需要 4-5 个技能协作的"困难"任务上，SAD 更是将准确率提升了 50%。反馈环路不是锦上添花，而是整个框架能不能用的关键开关。

4 反直觉：更大的模型可能更差

实验中发现了一个极具启发性的反直觉现象：在没有 SAD 引导的情况下，14B 参数模型的分解准确率竟然低于 7B 模型。

打个比方：让一个资深大厨和一个新手分别写采购清单。大厨知识丰富，把"做红烧肉"拆成了"选五花三层→切3cm方块→冷水下锅焯水→炒糖色→加八角桂皮→……"七八个步骤；新手只写了"买五花肉和调料"。结果超市里只有"猪肉-五花"和"调味料包"两个品类——大厨的细碎步骤在货架上根本找不到对应项，新手的粗粒度描述反而一搜就中。

⚠️ 过度分解陷阱

更大的模型倾向于将任务分解得过于细碎——把本该一步完成的操作拆成四五步微观子任务。这些微观步骤在技能库中根本找不到匹配的工具，导致检索阶段全面失败。能力越强，"想太多"的倾向越严重，结果反而越差。

而 SAD 的回注机制恰好解决了这个问题：检索到的真实工具描述像"锚"一样，把大模型的分解粒度拉回现实。大厨看到货架上只有"猪肉-五花"，就会把七八个步骤合并成"采购猪肉-五花"——基于"工具库实际上有什么"来规划，而不是天马行空地拆解。

"Aligning an agent with the vocabulary of specific tools is often more impactful than paying for a larger, more expensive LLM." — 论文核心结论

这对工程实践的启示是颠覆性的：与其花更多钱买更大的模型，不如花心思设计好工具对齐机制。一个 7B 小模型 + 好的路由策略，完全可以打败裸奔的 14B 甚至更大模型。

5 Token 消耗降 99.9%：一笔算得清的账

99.9% 的降幅听起来像魔法，但拆开算，逻辑非常清晰。关键在于理解两种方法在"谁干活"上的根本差异：

方法

Token 消耗

准确率

LLM-Direct（暴力塞入）

~884,000

21.1%

SkillWeaver（精准路由）

~1,160

大幅领先

Token 消耗对比：降幅 99.9%

~884,000 Token

LLM-Direct 暴力塞入 · 准确率 21.1%

~1,160 Token降 99.9%

SkillWeaver

← 右边这根柱子只有左边的 1/762

逐步拆解：884,000 → 1,160 是怎么来的

暴力塞入的账：

2209 个技能 × 平均每个描述约 400 Token ≈884,000 Token

每次查询，不管你用几个工具，全量描述都要塞进上下文

LLM 要从 884,000 Token 的"大海"里"捞针"——又贵又慢又不准

SkillWeaver 的账：

Decompose 阶段：LLM 只看用户查询 + 少量提示 ≈ 几百 Token

Retrieve 阶段：LLM 不参与，纯向量计算，0 Token

SAD 回注：只传入 Top-K 候选的精简描述（约 5-10 个工具 × ~100 Token）

Compose 阶段：LLM 只看筛选后的候选组合 ≈ 几百 Token

合计 ≈1,160 Token

核心差异就一句话：暴力塞入让 LLM 读完整本百科全书再回答，SkillWeaver 先用向量检索翻到正确页码，再让 LLM 只读那一页。

这里需要解释一个关键概念——为什么"向量检索"不需要 LLM 参与？

Embedding 检索为什么不需要 LLM？

想象一个图书馆，每本书都被贴上了一张"标签卡"（向量），标签卡上用数字编码了这本书的主题。你要找"烹饪"相关的书，系统只需要把"烹饪"也编码成数字，然后计算哪张标签卡的数字最接近——这是纯数学运算，用 FAISS 索引毫秒级完成，完全不需要"理解"文本的 LLM 参与。LLM 只在"理解用户意图"和"做最终决策"时才出场，出场时只看筛选后的少量候选，Token 自然就少了。

✅ 成本与延迟双赢

Embedding + FAISS 建库仅需 15 秒（2209 个技能）；每次查询的检索延迟低于 15 毫秒。对企业级部署而言，同步工具索引只是一个可忽略的后台任务。

6 ReAct 范式的根本缺陷

实验中另一个值得深思的数据：传统 ReAct 风格的 Agent 在 CompSkillBench 上的分解准确率为0%——不是低，是彻底失败。

再用一个类比：ReAct 就像你在陌生城市开车，没有导航，每到一个路口才决定下一步往哪拐。你可能最终歪打正着到了目的地，但更可能越开越远。而 SkillWeaver 是出发前先用地图规划好完整路线——先上高速、再走国道、最后进市区——一步到位。

ReAct 的核心机制是"思考-行动-观察"循环，每次选一个工具执行，观察结果后再决定下一步。这种逐步推进的方式天然会将多步骤计划坍缩为孤立的单步操作——Agent 无法提前规划出连贯的工具序列，每一步都在"盲人摸象"。

ReAct vs SkillWeaver 的本质区别

ReAct 是反应式（Reactive）——走一步看一步，无法保证全局一致性。就像没有导航的驾驶。

SkillWeaver 是规划式（Planning）——先分解、再检索、后组合，一步到位生成完整的 DAG 执行图。就像出发前规划好路线。

ReAct vs SkillWeaver：执行路径对比

ReAct（反应式）

准确率：0% · 走一步看一步

选工具① → 观察 → 选工具② → 观察 → 选工具③

⚠️ 无法提前规划完整序列

SkillWeaver（规划式）

准确率：67.7%-92% · 先规划再执行

规划：Decompose→Retrieve→Compose

起点 → 工具① → 工具② → 工具③ → ✓ 精准到达

✅ 先规划完整路线，再高效执行

对于需要多工具协作的企业场景，ReAct 这种"摸着石头过河"的方式根本不适用。你需要的是一张完整的作战地图，而不是走到哪里算哪里。

7 可落地：用现成组件 30 分钟复现核心

虽然 SkillWeaver 的源代码尚未开源，但论文中使用的全部是现成组件，开发者完全可以自行复现。以下是核心组件清单和实现路径：

SkillWeaver 核心组件与替代方案

任务分解

Qwen2.5-7B / 任意 LLM + 论文提供的 Prompt 模板

语义检索

all-MiniLM-L6-v2 + FAISS（推荐升级 BGE-base-en-v1.5）

SAD 环路

Prompt Engineering + 检索反馈（论文已给模板）

编排框架

LangChain / LlamaIndex / 原生 Python 均可

重排序

Cross-Encoder 或 LLM-based Reranker（可选增强）

下面给出每个 Step 的核心代码片段，用 Python + LangChain + FAISS 实现，总共不到 100 行：

Step 1：构建技能库向量索引

# 1. 加载技能库，每个技能包含 name + description

from sentence_transformers import SentenceTransformer

import faiss, numpy as np

skills = [{ "name" : "api-client" , "desc" : "通过HTTP API获取远程数据" }, ...]

# 2. 用 Embedding 模型编码所有技能描述

encoder = SentenceTransformer( "all-MiniLM-L6-v2" )

embeddings = encoder.encode([s[ "desc" ] for s in skills])

# 3. 构建 FAISS 索引（2209个技能约15秒）

index = faiss.IndexFlatIP(embeddings.shape[ 1 ])

index.add(embeddings.astype(np.float32))

Step 2：任务分解（Decompose）

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model= "qwen2.5-7b" )

DECOMPOSE_PROMPT = """你是任务分解专家。将用户查询拆解为

有序的原子子任务，每个对应一个可执行工具。

用户查询：{query}

输出JSON：{{"subtasks": ["子任务1", ...]}}"""

def decompose (query):

resp = llm.invoke(DECOMPOSE_PROMPT.format(query=query))

return json .loads(resp.content)[ "subtasks" ]

# → ["获取远程数据集", "数据格式转换", "生成可视化图表"]

Step 3：SAD 反馈环路（核心创新）

def retrieve_topk (subtask, k= 5 ):

# 将子任务编码为向量，在FAISS中检索Top-K

query_vec = encoder.encode([subtask])

scores, indices = index.search(query_vec, k)

return [skills[i] for i in indices[ 0 ]]

def sad_feedback_loop (subtasks, max_iter= 3 ):

for iteration in range (max_iter):

aligned = True

for i, task in enumerate (subtasks):

# ① 检索候选工具

candidates = retrieve_topk(task)

# ② 回注工具描述，让LLM重写子任务

rewritten = llm.invoke(SAD_PROMPT.format(...))

# ③ 如果有变化，标记未对齐，继续迭代

if rewritten != task: subtasks[i] = rewritten; aligned = False

if aligned: break # 全部对齐，退出

return subtasks

↑ SAD 核心：检索 → 回注 → 重写 → 再检索，直到子任务与工具库词汇对齐

Step 4：组合 DAG 执行计划（Compose）

def compose_dag (subtasks):

# 对每个对齐后的子任务检索最终工具

task_tools =

for i, task in enumerate (subtasks):

top1 = retrieve_topk(task, k= 1 )[ 0 ]

task_tools.append( f"Step{i+1}: {task} → {top1['name']}" )

# LLM评估兼容性，生成DAG

dag = llm.invoke(COMPOSE_PROMPT.format(task_tools=...))

return json .loads(dag.content)

# 最终输出：可执行的DAG工作流

dag = compose_dag(subtasks)

# → {"nodes": [{"tool": "api-client"}, {"tool": "csv-parser"}, {"tool": "chart-gen"}],

# "edges": [{"from": "step1", "to": "step2"}, ...]}

值得注意的是，论文发现 Bi-Encoder 将正确工具召回 Top-10 的概率约 70%，但排在第 1 位的概率仅约 37%。这意味着生产环境中大概率需要加一层 Cross-Encoder 或 LLM Reranker，对 Top-K 候选重排序，才能达到实用的精准度。

Bi-Encoder vs Cross-Encoder：为什么需要重排序？

Bi-Encoder 就像"看封面选书"——把查询和工具分别编码成向量，比较向量的距离。速度快，但只看"表面相似度"。Cross-Encoder 就像"翻开书读两页再判断"——把查询和工具放在一起深度比对。速度慢，但精准得多。SkillWeaver 的策略是先用 Bi-Encoder 快速筛出 Top-10（速度优先），再用 Cross-Encoder 精排（精度优先），两步组合兼顾效率和准确率。

8 尚未解决的关键问题：错误恢复

SkillWeaver 的贡献聚焦于路由和规划阶段，但真实的工具链执行远不止"选对工具"这么简单。继续用做菜的类比：你规划好了"切菜→炒菜→装盘"的完美流程，但炒到一半发现盐罐空了——整道菜直接卡住。

⚠️ 错误恢复缺失

当 DAG 执行到第 2 步时，如果 API 调用超时、返回格式异常或鉴权失败，整个链条直接断裂。SkillWeaver 目前没有提供 fallback、重试或降级机制。对于生产部署，开发者必须自行构建错误恢复层——这可能是整个系统中最复杂的部分。

SkillWeaver 解决的是"知道该做什么"，但"做的时候出错了怎么办"仍是一个开放问题。一个完整的企业级方案，至少还需要：

超时重试— 对每个节点设置超时阈值和重试策略（盐罐空了？去隔壁借）

降级方案— 当首选工具失败时，自动切换到备选工具（没有精盐？用粗盐顶上）

断点续传— DAG 部分节点失败后，已成功的节点不需要重跑（切好的菜不用重新切）

输出校验— 每一步的输出格式校验，防止畸形数据向下游传播（尝一口咸淡再上桌）

9 三层启发：从认知到架构到生态

LAYER 1 · 认知层

对齐 > 算力：别迷信大模型

论文最反直觉的发现是：14B 模型裸奔不如 7B + SAD。这打破了"堆参数"的迷信——在 Agent 场景下，让模型说"工具的语言"比让模型更聪明更有效。就像一个会说方言的外乡人，比一个只会普通话的学者更容易在当地办成事。

同时，ReAct 0% 的准确率告诉我们：反应式范式有结构性缺陷，复杂工具编排必须用规划式架构。"摸着石头过河"只适合简单场景，面对多步工作流，你需要"先想清楚再做"。

LAYER 2 · 架构层

分解粒度是瓶颈，反馈环路是解法

论文明确指出："The granularity of task decomposition is the biggest bottleneck to accurate tool retrieval"。与其在检索算法上死磕，不如先把任务拆对。SAD 的反馈环路本质上就是在解决分解粒度问题——规划的质量决定了一切下游的上限。

而 SAD 的"生成-检索-回注-重写"循环，与 RLHF 的"采样-评分-反馈-优化"、思维链的"推理-验证-修正"同属一个范式——让系统输出与外部信号对齐。这个范式不仅适用于工具路由，也适用于任何需要 LLM 输出与现实约束匹配的场景。

LAYER 3 · 生态层

MCP 索引层将从可选变成刚需

SkillWeaver 的 FAISS 索引本质上是在 MCP 工具生态上构建了一层"语义索引"。随着 MCP 工具数量持续膨胀，这类索引层将从"可选优化"变成"必需基础设施"——就像互联网从"有搜索引擎更好"进化到"没有搜索引擎不可想象"。

未来的 MCP 注册中心可能内置向量索引服务，Agent 接入即用，无需自行建库。谁先在 MCP 生态中建好索引层，谁就掌握了 Agent 工具调用的入口。

SkillWeaver 的核心贡献不在于某个算法突破，而在于重新定义了 Agent 工具调用的问题框架：从"选一个工具"升级为"组合一条工作流"，从"一次决策"升级为"迭代对齐"。99.9% 的 Token 降幅只是这个范式转换的自然结果。

当 Agent 系统从"能用"走向"好用"，从"单工具调用"走向"多工具编排"，组合式技能路由将成为不可回避的基础能力。而 SAD 反馈环路所代表的"对齐思维"——让模型学会用工具的语言说话——或许比具体的技术实现更值得我们铭记。

参考阅读

1. SkillWeaver: Compositional Skill Routing for LLM Agents (arXiv： https://arxiv.org/abs/2606.18051 )

2. VentureBeat: New Alibaba AI framework skips loading every tool ( https://venturebeat.com/orchestration/new-alibaba-ai-framework-skips-loading-every-tool-cutting-agent-token-use-99 )

3. all-MiniLM-L6-v2 Embedding Model (HuggingFace： https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2 )

4. BGE-base-en-v1.5 Embedding Model (HuggingFace： https://huggingface.co/BAAI/bge-base-en-v1.5 )

关注「代码的使命」，获取更多 AI 技术深度解读