Skip to main content

Agent 如何加载海量 Skill？

· 4 min read

海量 Skill 不能全量塞进 prompt，核心是渐进式披露（progressive disclosure）按需加载。

  1. 为什么淘汰全量：token 是模型的注意力预算，工具目录涨到 200 个左右，工具选择准确率从 95% 断崖跌到 41%。
  2. 三 层渐进式披露：L1 元数据索引 → L2 意图注入 schema → L3 触发 RAG 翻文档，token 开销砍掉 90% 以上。
  3. 冷启动延迟：前端轻量路由分流 + 高频工具常驻 KV cache，响应时间缩短 30% 以上。
  4. 状态断联：任务快照浓缩执行进度，切技能时注入，新技能原地复活。
  5. 反过度设计：二三十个技能别上三层，前置语义过滤 + 精简 prompt 更稳。

为什么全量加载在工业界"查无此人"？​

因为 token 不只是计费单位，它是模型的注意力预算。

很多人觉得现在上下文都几百万 token 了，不差那点地方，把所有工具描述一股脑塞进去就行。这恰恰是面试官挖的坑。

有个实验数据很扎心：当工具目录扩展到 200 个左右时，主流模型的工具选择准确率会从 95% 断崖式跌到 41%。原因在 Transformer 架构本身——注意力复杂度是 O(N²)，几十万 token 全灌进去，模型会陷入注意力稀释和指令自我调和的怪圈。干扰信息太多，模型自己逻辑打架，关键指令反而视而不见。

主动制造混乱，在生产环境就是灾难。

渐进式披露：把知识加载拆成三层​

核心思路是"剥洋葱"——用到哪层才加载哪层，而不是一次全展开。

L1 元数据索引层：模型启动时只加载技能的名字和一句简单描述，每个技能就几十 token。目的是建立一张全局技能地图——知道"有什么"，但先不管"怎么用"。

L2 意图理解层：只有当模型判定"我现在需要这个工具"，编排层才截获这个意图，把完整的 schema、参数格式、甚至几个经典 few-shot 案例动态注入进去。执行那一刻，注意力最集中。

L3 深水执行层：万一遇到复杂报错、或者要翻万字文档，这时才触发 RAG。相当于把庞大的资料库从 prompt 里彻底剥离，只在真正需要翻书时才打开那扇门。

这套下来，token 开销能削减 90% 以上，成本和性能都保住。

面试深挖的两个难题​

动态加载不是免费的午餐，面试官一定会追着两个副作用问。

冷启动延迟：切技能时卡不卡？​

不再全指望大模型选工具，而是在前端加一层轻量路由。

这个路由是跑在 CPU 上的轻量级模型，它不参与思考，只负责毫秒级分流——把意图分派给对应的工具簇。再配合硬件级的 prompt 缓存：高频工具的说明文档几乎常驻 KV cache，省掉重复计算。两者叠加，响应时间能缩短 30% 以上，用户几乎感知不到动态加载的过程。

状态断联：旧技能卸载了，任务进度丢了怎么办？​

引入任务快照机制，不保留繁琐的对话历史。

做法是把"当前任务执行到哪一步、产出了什么、中间结果是什么"浓缩成一份极简的状态快照。每次切换技能，只要把这份快照注入上下文，新技能就能立刻原地复活，逻辑一点不断。关键在于快照存的是任务状态，不是聊天记录，所以又小又稳。

别忘了：架构选型只有平衡点，没有标准答案​

三层架构不是银弹，技能规模决定要不要上。

选型判断
  • 二三十个技能：搞三层架构是过度设计。直接用前置语义过滤 + 精简 prompt，反而更稳定。
  • 上百个技能的企业大集群：渐进式加载配合 swarm 集群架构，才是唯一解法。

面试里能说清"为什么这么设计、设计背后权衡了什么"，比背出概念更能拉开差距。

References​

  1. 面试精讲：Agent 海量 Skill 加载核心思路 —— AI大模型原理, Bilibili