SkillWeaver 架构拆解：Agent 面对千工具时的 Token 优化实操

一把工具钥匙打开千把锁

写 Agent 的人都有个体感：工具少的时候，把所有 function definition 塞进 system prompt 就完事了。但当你接入 MCP 生态，工具数量从十几个膨胀到上千个的时候，光工具描述就能吃掉好几万 token——还没算用户的实际请求。阿里最近发表的 SkillWeaver 论文，就是冲着这个问题来的。

TLDR AI 在 7 月 3 日的报道中提到，SkillWeaver 框架的核心卖点很直接：不再把所有工具一次性加载进上下文，而是按需检索、按需组合。效果是 token 消耗降低 99% 以上。

这篇文就拆开 SkillWeaver 的三步管线，看看它到底做了什么，以及独立开发者能从中偷到什么招。

三步架构：分解 → 检索 → 组合

第一步：分解（Decompose）

用户说"帮我把刚才那张表导成 PDF 发到 Slack"，这是一个组合查询——涉及文件操作、格式转换、消息发送三类工具。如果把 2209 个 MCP skill 的描述全塞进上下文，光这一步就要烧掉巨量 token。

SkillWeaver 的做法是先用一个 LLM 把组合查询拆成原子子任务：

• 任务 A：读取表格文件
• 任务 B：将表格转为 PDF
• 任务 C：发送文件到 Slack 频道

每个子任务只对应一个功能类别，后续只需要去对应类别的 skill 池里找工具。

第二步：检索（Retrieve via FAISS Bi-Encoder）

拆完之后，SkillWeaver 用 FAISS 做向量检索。每个功能类别下预先建好 skill 描述的 embedding 索引，子任务描述作为 query 去检索最相关的 skill。

关键点：这里用的是 bi-encoder 而非 cross-encoder。Bi-encoder 的优势是 skill 端的 embedding 可以离线预计算好，线上只需要算一次 query embedding 再做 ANN 检索，延迟在毫秒级。Cross-encoder 精度更高但每对都要跑一次模型，上千工具的场景下根本扛不住。

第三步：组合（DAG Planner）

检索到具体 skill 之后，SkillWeaver 用一个 DAG（有向无环图）规划器来安排执行顺序。上面的例子中，B 依赖 A 的输出，C 依赖 B 的输出，构成一条线性链。但真实场景可能更复杂——比如"把这份 PDF 翻译成英文，同时提取里面的表格数据"，两条分支可以并行。

DAG 规划器负责：

1. 确定子任务之间的依赖关系
2. 安排可并行任务的执行顺序
3. 把上游 skill 的输出传给下游 skill 作为输入

SAD：反馈循环把召回率拉了 32.7 个百分点

论文里最漂亮的一组数据来自 SAD（Skill-Aware Decomposition） 机制。

初步实现中，分解阶段用的 LLM 可能拆错——比如把"从 Notion 导出数据库到 Airtable"拆成了"导出"和"导入"两个子任务，但"导入"这个描述太模糊，检索时匹配不到 Airtable 相关的 skill。

SAD 的做法是加一轮反馈校验：子任务描述检索完毕后，检查检索结果的 category 是否和子任务的意图匹配。如果不匹配，把检索结果作为负例反馈给分解 LLM，让它重新拆。

这个反馈循环的效果：

Category Recall 翻了接近一倍，意味着三分之二的查询能正确找到目标功能类别。而 token 消耗从每查询约 8.5 万降到约 600——这就是 99%+ 降幅的来源。

CompSkillBench：拿什么衡量组合能力

论文同时发布了 CompSkillBench 基准测试集，包含：

• 300 条组合查询：每条都需要调用多个 skill 协作完成
• 2209 个真实 MCP skill：从实际 MCP 生态中抓取，不是合成的
• 24 个功能类别：文件操作、数据库、通信、搜索、代码执行等

这个 benchmark 的价值在于它测的是组合能力而非单工具调用。现有 Agent benchmark 多数只测单步工具调用，但真实场景中用户的一句话往往需要多工具协作。CompSkillBench 填了这个空白。

VenureBeat 的报道指出，SkillWeaver 在 CompSkillBench 上的表现显著优于全量加载基线，同时 token 消耗只有后者的不到 1%。

对独立开发者意味着什么

你可能在想：我又没有 2209 个工具，这套架构跟我有什么关系？

关系在于：MCP 生态正在爆发式增长。MCP 官方文档显示，目前已有数百个 MCP server 覆盖文件系统、数据库、API 集成、浏览器自动化等场景。即便你今天只接了 20 个 MCP server，每个 server 平均暴露 10 个工具，也是 200 个工具——已经到了全量加载会很吃力的阶段。

SkillWeaver 给出的实操启示有三层：

启示一：按需加载，不要全量塞

最简单的版本你今天就能实现：给每个工具打上 category 标签，用户请求来了先用 LLM 做意图分类，只把相关 category 的工具定义加载进上下文。这不需要 FAISS，不需要 embedding，一个 if-else 路由就能起步。

启示二：用 embedding 做语义检索

工具多了之后，硬编码的 category 路由不够用——用户说"帮我存一下"，你得知道这到底是"存到数据库"还是"存到文件"。这时候给每个工具描述算好 embedding 存起来，请求来了算一次 query embedding 做相似度检索。FAISS 是开源的，SGLang 的 Agent 辅助开发博客也展示了类似思路在生产环境中的应用。

启示三：反馈循环是便宜的精度提升

SAD 机制的精髓不是什么高深算法，就是"检索完了检查一下对不对，不对就重来"。这个模式你在任何 Agent 项目里都能复用：检索结果拿回来后让 LLM 判断是否匹配意图，不匹配就把负例塞回去重新检索或重新分解。一轮反馈就能把召回率拉几个档次。

自己动手：一个最小可行方案

如果你想在自己的 Agent 项目里实现类似的按需加载，这里是最低成本路径：

1. 给工具建索引：遍历所有可用工具，把 name + description 拼成文本，用 embedding 模型（OpenAI text-embedding-3-small 或本地 bge-small）算向量，存成 JSON 或 SQLite
2. 请求来了先检索：用户输入作为 query，算 embedding，cosine 相似度取 top-5 工具
3. 只把 top-5 的定义塞进上下文：system prompt 里只放这 5 个工具的 function definition
4. 加一轮校验：让 LLM 看看这 5 个工具能不能完成用户请求，不能就扩大到 top-10 或换关键词重新检索

这四步加起来不超过 200 行代码，但 token 消耗能降一到两个数量级。

🎯 行动清单

1. 盘点你的工具数量：如果超过 30 个，全量加载的 token 成本已经不可忽视
2. 给工具打 category 标签：手工或用 LLM 自动打，建立第一级路由
3. 搭一个 embedding 检索层：FAISS 或直接用 numpy 算 cosine，入门级方案就够
4. 加一轮检索校验：参考 SAD 机制，检索完让 LLM 判断是否匹配，不匹配就反馈重试
5. 监控 token 消耗：对比优化前后的 system prompt token 数，量化收益
6. 关注 CompSkillBench：用这个 benchmark 测你自己的 Agent 组合工具能力

开放问题

SkillWeaver 的局限也很明显：

• 分解阶段仍需 LLM 调用：虽然比全量加载便宜，但多一轮 LLM 调用就多一轮延迟和成本
• DAG 规划器对复杂依赖可能出错：论文中没展示超过 5 步的组合查询表现
• MCP 生态动态性：新 skill 不断出现，embedding 索引需要定期更新

这些恰恰是独立开发者可以发力的地方——更轻量的分解策略、更鲁棒的执行规划、自动化的索引更新，每个点都能做成一个开源项目。

相关链接：

• 论文全文：arXiv 2606.18051
• VentureBeat 报道：New Alibaba AI Framework Skips Loading Every Tool
• TLDR AI 7月3日刊：tldr.tech/ai/2026-07-03
• MCP 官方文档：modelcontextprotocol.io
• SGLang Agent 辅助开发博客：lmsys.org/blog/2026-07-02-agent-assisted-sglang-development

延伸阅读

• mragent-memory-framework：Agent 记忆框架拆解
• prompt-injection-2026-landscape：Prompt 注入攻防全景
• llm-coding-agent-guide：Simon Willison 的 LLM 编码 Agent 实战

觉得有用？转发给也在搞 Agent 的朋友。想聊实现细节？评论区见。