你是不是也遇到过这种情况——Skill 越攒越多Agent 反而越来越不会用了。我讲的不是模型能力的问题而是真实开发中的一个尴尬局面项目里攒了一百多个 Skill也常被叫工具、插件、Function每次调用前要把所有工具的说明、参数、调用约束全部塞进上下文结果模型被海量信息淹没要么选错工具要么根本不知道该调哪个甚至为了“碰运气”硬编一个不存在的参数。更糟糕的是每次请求的 Token 消耗直线上升延迟也变得完全不可接受。这其实是多 Skill 场景下最典型的架构难题你有一堆能力但模型不知道什么时候该用哪一个。全量注入是简单粗暴的解决办法但一旦 Skill 数量过百这条路就走不通了。项目卡在这个阶段时我踩过不少坑最后摸出了“目录缓存层 标签路由层 语义召回层”的组合方案把上下文中的 Skill 说明从“上百份全量说明书”压缩到“每请求仅动态加载 3~5 个最相关技能”。这篇文章就把这套方案的拆解思路、实操细节和避坑记录完整写出来适合正在做 Agent 应用、或者被工具爆炸问题困扰的开发者参考。1. 先别急着加 Skill问题到底出在哪1.1 上百个 Skill 不是生产力是上下文的负担很多人一听到“Skill 多”就兴奋觉得模型能力变强了。但真实情况是残酷的大模型在回答时必须知道自己“有哪些工具可用”。这个“知道”的过程是有成本的。我给 Skill 的占用算过一笔账。假设每个 Skill 平均需要 130~200 个 Token 来描述“做什么、怎么调用、参数是什么、注意事项”100 个 Skill 就意味着 13000~20000 Token 的固定开销。这个数字是什么概念呢很多主流模型的上下文窗口虽然有数万 Token但其中真正留给回答和推理的空间往往只有几千到一万多 Token。你还没开始干活光工具说明已经吃掉半壁江山。如果把 Skill 细分成“描述前缀 参数 Schema 调用示例”成本还要进一步放大。有些工具我为了降低误用率会在描述里写详细的行为约束和边界条件一个 Skill 轻松超过 300 Token。100 个这样的 Skill 合计就是 30000 Token。注意这里是每一次请求都要重新付这笔钱无论这次请求只需要用到其中 1 个 Skill 还是 5 个 Skill。我实测过一个真实项目的 Token 消耗变化刚开始只有 12 个 Skill 时每请求约 3500 Token加到 70 个 Skill 之后涨到了 15000跨过 100 个 Skill 这条线直接冲破 30000。而且这还是“静态注入”的开销如果模型需要多轮思考去哪找工具每次思考都会重复检索一遍成本翻倍几乎是必然。这不仅仅是钱的问题延迟也会同步恶化。Token 多了Prefill 阶段变慢首字返回时间肉眼可见地延长。用户问一句话界面里要转好久的圈。在真实产品里这个体验是不可接受的。1.2 不是模型不行是“选择过载”害了 Agent很多人遇到 Skill 多之后模型表现变差第一反应是模型太笨了于是去换更贵的模型。但问题的本质是“选择过载”。人也好模型也好选项越多决策质量反而会下滑。心理学里有个经典概念叫“选择过载”用在大模型身上再贴切不过。当上下文里塞了几十个甚至上百个功能相似但描述细节有差异的 Skill 时模型的选择行为会变得特别不稳定。它可能只看前几个 Skill 的内容也可能因为某个 Skill 描述里恰好出现了和用户问题匹配的关键词而误选或者干脆不肯选直接回答“我无法完成这个操作”。一个更隐蔽的问题是相似类型的 Skill 之间存在“特征竞争”。比如你同时有“发送邮件”和“预约会议”两个工具两者都涉及“日历”“联系人”“备注”模型容易混淆。Skill 越多这种混淆的概率呈指数上升。换更贵的模型当然有改善但治标不治本——只要信息量还是这么大模型的注意力就一定会被稀释。所以核心矛盾从来不是“模型不够聪明”而是“信息架构不合理”。解决方案也不是压缩模型质量而是压缩、结构化“送给模型的工具信息”。这正是分层加载机制要解决的问题让模型每次只看到当前任务最需要的 3~5 个 Skill而不是全部。2. 分层加载的整体思路三层架构谁先谁后2.1 已有方案为什么不灵一说控制 Skill 信息量很多人第一时间想到的是“摘要压缩”。把 100 个 Skill 的描述全部压成一行短摘要每次传给模型。但这样做有致命问题摘要丢掉了参数细节、调用约束、返回值语义。模型知道有这个工具却不清楚怎么用、什么时候不该用。这就好比你看菜名知道“红烧肉”是吃的但不知道它具体口味、分量、忌口等于没看。还有人想用 RAG 对 Skill 做向量检索直接把用户问题和所有 Skill 的 Embedding 算相似度挑 Top-K 出来。理论上挺美好实际操作中效果很差。原因是向量检索擅长语义相似匹配但 Skill 选择这件事本质上是一个“需求意图到工具能力”的结构化映射问题。用户说“帮我安排下周一下午的会议”这句话和“会议室预订工具”在文本层面的相似度并不高跟“邮件发送工具”可能更接近。单纯靠向量路子跑偏是家常便饭。所以说想让 Agent 在多 Skill 场景下真正“知道怎么用”就得把“筛选”这件事结构化、分步骤。三层架构的核心思想是先用最便宜的方式做大步排除再做精细挑选。从大规模候选集里找最优解如果一上来就用重武器成本和失误率都控不住。2.2 目录缓存层、标签路由层、语义召回层三层各管一段我最终落地的方案把 Skill 筛选流程拆成三层每一层的目标、计算成本、输出完全不同。可以类比成查字典先翻目录再按拼音或偏旁缩小范围最后看具体解释。第一层是目录缓存层。它维护一份极轻量的 Skill 目录只包含 Skill ID、名称、路由键如所属模块、一句话摘要。这一层的作用是让系统能极快地知道“有哪些能力存在”为后续筛选提供一个便宜的导航底图。注意这一层不包含参数、调用规则等详细信息是一个刻意缩减信息量的层。它的数据可以缓存在内存或 Redis 里查询开销几乎可以忽略。第二层是标签路由层。每个 Skill 在注册时会打上多维度标签如领域标签销售/财务/HR、能力类型查询/生成/操作、输入类型文本/文件/JSON、风险级别只读/可写/需确认。这一层通过规则匹配和标签倒排索引把候选 Skill 从上百个快速缩减到二十个以内。它的判断依据是“用户请求里的关键词与技能标签的匹配”不依赖大模型的语义理解所以快而且可解释。第三层是语义召回层。经过标签路由过滤后候选集已经大幅缩小。此时才用 Embedding 做语义匹配对候选 Skill 进行精排选出 Top-K通常 3~5 个。这一层计算成本最高但因为候选集已经很小性能完全可控。精选出来的 Skill 才需要把完整描述、参数、调用规则注入给模型。这三层的顺序不是随便定的。如果先用向量检索等于把最重的计算放在第一步且容易误杀如果只用标签路由则缺乏语义级别的精细度无法处理用户表达模糊的情况。先窄化再精排兼顾了精度和效率。3. 分层加载机制的实操要点3.1 目录缓存层怎么建轻、稳、全目录缓存层的设计目标只有一个让系统以最低成本回答“我都有哪些能力”这个问题。我指的“最低成本”有两层含义存储成本和维护成本。目录层的每条记录只需要四类字段结构如下{ skill_id: send_email_v3, name: 发送邮件, route_key: communication.email, summary: 发送邮件给指定收件人支持附件与模板, version: 3 }这里有几个设计要点。第一summary 必须控制在一句话以内最好不超过 30 个 Token不能把详细参数写进来。第二route_key 必须有层次结构比如“通信.邮件”“数据.查询”“日程.会议”。层次化的路由键让标签路由层可以直接做前缀匹配。第三这个目录必须像 Level-1 Cache 一样热缓存任何一次请求的第一步查询都不能打数据库。我踩过的坑是一开始为了省事直接用 Hash Map 存储目录每次遍历扫描结果 Skill 一多目录查询本身反而成了瓶颈。后来改成按 skill_id 做索引 按 route_key 做前缀分组查询性能才稳定在亚毫秒级。这里的关键不是数据结构有多高级而是要想清楚你的查询模式是什么。还需要强调的一点是目录缓存要和 Skill 仓库保持版本一致。Skill 更新后目录必须同步刷新。这里建议引入简单的“递增版本号机制”——Skill 仓库每次变更版本号 1所有缓存节点检测到版本变化后触发目录刷新避免出现“目录说有这样的能力实际注册表里却已经删了”的脏数据问题。3.2 标签路由层怎么设计分类维度与命中算法标签路由层是整个分层机制的“主力过滤器”。它的工作方式相当直接把用户请求里的关键词和 Skill 标签做匹配拿到一组候选 Skill ID。要把它做好标签维度设计是核心功课。我的实践经验是不要只用一个维度打标签而是至少要覆盖四个维度标签维度示例值作用领域 Domainsales / finance / hr / admin快速圈定业务范围能力类型 Capabilityquery / generate / execute区分只读查询、内容生成、系统操作输入类型 InputTypetext / file / json / image判断技能能接收什么输入风险级别 RiskLevelread_only / write / confirm_required控制越权操作安全过滤其中风险级别这个维度容易被忽视但很有价值。比如用户请求写“删掉这个文件”如果请求对应的标签命中了一个风险级别为 confirm_required 的技能系统可以直接进入二次确认流程而不是傻乎乎地让模型直接执行。这属于安全性的前置过滤越早越好。标签的匹配算法我推荐用“加权命中得分”而不是简单布尔匹配。具体思路是每个 Skill 的标签列表对应一个加权权重用户请求的文本先做简单分词和同义词扩展再与标签做匹配最后按匹配到的标签权重求和排序。def route_by_tags(request_text, tag_index): candidates {} # 对请求文本做简单分词 同义词扩展 tokens tokenize(request_text) expand_synonyms(request_text) # 遍历命中标签累计权重 for token in tokens: for skill_id, tags in tag_index.items(): matched 0 for tag in tags: if tag in tokens: matched 1 if matched 0: candidates[skill_id] candidates.get(skill_id, 0) matched # 排序取前 N 个N 可以根据总 Skill 数动态调整 return sorted(candidates.items(), keylambda x: x[1], reverseTrue)[:ROUTE_TOP_N]这里的一个技巧是同义词扩展不能做得太重否则会把候选集重新撑大。我一般只做常见同义词的映射比如“发”和“发送”、“查”和“查询”、“约”和“预约”。过度扩展反而会把语义相近的无效技能引入候选集增加后面语义召回层的负担。另一个关键参数是 ROUTE_TOP_N 的取值也就是标签路由这一层输出多少候选。我试过 10、20、30 三档结论是100 个 Skill 的规模下20 个候选是最平衡的点。少于 10 个容易把真正合适的排挤出去多于 30 个则语义层的计算量明显上升但准确率提升有限。3.3 语义召回层怎么做向量检索与阈值选择进入语义召回层时候选集已经从上百个缩小到二三十个。这一层的任务是用向量相似度精排挑出最终要注入给大模型的 3~5 个 Skill。具体实操上每个 Skill 的“语义描述”需要单独构建。我的做法是把 Skill 的完整描述、参数 Schema 中的关键字段含义、典型调用示例拼接起来用 Embedding 模型编码成向量。注意这里不能用前面目录层的一句话摘要来做 Embedding信息量不够向量区分度太差。必须是信息丰富的“扩展描述”。查询向量的编码直接用用户的请求文本。相似度计算选择用余弦相似度即可然后按分数降序取 Top-K。核心参数有两个一个是 TopK 上限一个是相似度阈值。TopK 我给出的经验值是 5。为什么不是 3 或者 8因为 3 个有时候不够用比如某些任务需要“查询 生成 发送”三个步骤联动一个步骤可能需要两个候选3 个名额确实紧张8 个则会让注入上下文的信息量重新变大丧失分层加载的意义。5 是一个中间值实测下来准确率和 Token 消耗平衡得最好。相似度阈值的作用是“宁可少选不能乱选”。如果候选集中所有 Skill 的分数都低于阈值说明用户的请求可能不在已有能力范围内这时候宁可调用一个兜底逻辑比如告诉用户该请求不在当前工具能力范围内也不要硬选一个低相似度的工具让模型硬编参数。我用的阈值是 0.45这是在一个常见中文办公场景的数据集上调出来的不同业务域可能会有波动建议上线前跑一批历史请求统计一下相似度分布再定阈值。还有一个比较坑的细节就是去重和合并。有些 Skill 在功能上是同一族但版本不同比如“发送邮件 v2”和“发送邮件 v3”。语义召回层可能把老版本和新版本同时捞进来导致模型困惑该用哪个。我在这一步加了“族内去重”逻辑同一族 Skill 只要分数最高的那个进入最终队列其余直接过滤。4. 完整工作流程拆解一次请求在落地时走完的路线4.1 请求进来后每层做了什么前面说的都是架构组件你可能已经把它们串联起来了。这里我用一个真实的例子把完整流程走一遍。假设用户发来这样一条请求“帮我给上周新增的客户发送一封表达感谢的邮件内容委婉一些。”第一步系统拿到请求文本后先查目录缓存层。这一步不做任何理解只负责发现问题里有“发送”“邮件”“客户”这些关键词对应的路由键。目录层快速返回一个全部范围的 Skill 列表但这里只用了内存查询耗时极短。第二步请求进入标签路由层。分词并扩展同义词发送→发/发送邮件→email客户→客户/顾客。然后对所有 Skill 的标签做匹配。候选集合从 100 多个缩小到 18 个左右——匹配到的标签主要分布在“communication.email通信/邮件”、“customer.write客户/写入”、“execute执行操作”这几个维度下。那些和邮件、客户、执行无关的技能在这个阶段已经被排除掉了比如财务管理、数据报表查询等。第三步把 18 个候选 Skill 的扩展描述向量和用户请求向量做相似度计算。排序后发现“邮件发送 v3”得分 0.82“客户列表查询 v2”得分 0.61“客户新增 v4”得分 0.58“邮件模板生成 v1”得分 0.47。Top-K 设置为 5但这里只有 4 个技能得分高于 0.45 的阈值。最终挑选结果邮件发送 v3、客户列表查询 v2、客户新增 v4、邮件模板生成 v1。注意“客户列表查询”和“客户新增”看起来跟“发邮件”不完全直接相关但它们确实是完成这条请求必需的——系统需要先查到“上周新增客户”的收件人列表可能还要临时补录客户信息。如果只用朴素向量检索这类隐含依赖关系很难被挖掘但经过标签路由层把范围缩小后语义召回的胜率显著提高了。第四步把选出的 4 个 Skill 的完整描述、参数 Schema、调用约束注入模型上下文。模型只面对 4 个工具选择范围大大缩小决策稳定性和响应质量都回到可控水平。4.2 调度主流程的工程实现细节上面这个流程落到代码里我总结了一个可直接套用的实现骨架。核心是分层调度函数每一层接收上一层的输出做自己的处理再往下传。def choose_skills(user_request: str) - list[str]: # 第一层目录缓存层快速确认全量能力 catalog catalog_cache.get_all() # 第二层标签路由层粗粒度过滤 tagged_candidates route_by_tags(user_request, tag_index) # 第三层语义召回层精排 Top-K final_skills semantic_rank(user_request, tagged_candidates, top_k5, threshold0.45) # 族内去重同一族只保留最高分 deduped dedup_by_family(final_skills) return [s.skill_id for s in deduped]这段代码本身很简单但有几个隐藏细节值得注意。第一在第三层之前所有操作都不要调用大模型。目录查询和标签匹配都是纯内存运算只有语义召回涉及 Embedding 计算。这样设计的好处是当用户的请求明显不属于任何已有 Skill 能力时可以被标签路由层极快地拦截根本不需要算 Embedding也不必开一次大模型调用。这个“提前拦截”的收益在工业级场景里非常可观。第二每一层的输出都应该带上可追溯的信息比如候选名、匹配到的标签、相似度分数。建议把日志结构化为 JSON方便后续做链路分析和评估。我做这套系统时就靠这些日志发现了一大批“模型选了但其实是错选”的案例从而反过来优化标签设计。第三如果系统是多租户的每个租户的 Skill 列表可能不同。目录缓存层和标签索引在实现时要有租户隔离维度不能把不同租户的 Skill 混在一起否则会出现严重的权限与功能错配问题。我多次强调“把检索做到上下文注入之前”这个原则贯穿整个落地过程。模型省掉了大量无效信息的输入自然就更专注于当前任务本身。5. 踩坑实录与避坑指南5.1 分层加载与全量注入的对比实测光有架构没有数据说服力总是差点。我把自己维护的某个实际项目切换前后的数据整理出来做一个直观的对比。这个项目接了 100 个 Skill生产环境每天有约 2 万次调用。指标全量注入方案分层加载方案当前方案平均单请求额外上下文 Token250001800~2600平均首字返回时间3.1s1.2s工具选择准确率人工标注样本71%93%日均 Token 消耗约 1.2 亿约 2.5 千万因错选工具导致的失败请求6.8%1.2%表格里的数据是在同一模型、同一批 Skill 的前提下切换接入方式得到的。可以看到不仅是成本下降准确率和延迟也明显改善这验证了“减少信息量”在工具调度场景中往往比“增加信息量”更有效。不过我提醒一句这些数字是特定业务场景下的结果不一定能在你的项目里原样复现。分层加载的收益取决于 Skill 的异质程度——如果 100 个 Skill 本来就是八大类各十几条标签路由层受益会很明显如果 100 个 Skill 全都是文档处理类的只是工具名不同那标签路由层的作用会弱化语义召回的压力会变大。这类场景下建议给标签路由层增加更多“参数特征标签”如支持的文档格式、处理动作类型来强行制造维度差异。5.2 经验总结最常见的坑以及怎么避开我在实际落地过程中总结了几条高频踩坑点每一条都是一次真实教训的沉淀。第一标签体系不要一上来就做得很细。第一次设计时我给 Skill 打了三十多类标签结果标签路由层的匹配结果反而变差了——标签太分散每条标签下挂载的 Skill 太少同义词扩展命中率变差候选集没能有效缩小甚至偶发“冷门标签把无关技能拉进候选集”的问题。后来收敛到四大类维度每个维度只保留 3~5 个枚举值效果反而稳定。第二不要把标签路由层做成纯 Hard Match。真实用户请求的表达是灵活的如果用户说的是“删掉这条记录”而标签里只有“delete”而没有“删除”匹配就会失败。建议至少做一个简易同义词表并定期从日志里挖出未命中的请求反向补充同义词映射。第三Embedding 库的更新要谨慎。我出过一次生产事故语义召回层用的 Embedding 模型升级后所有 Skill 的向量需要重新生成但我没有同时更新缓存里的旧向量导致新旧向量混用相似度分数完全错乱Agent 疯狂挑选无关工具。从那以后我养成了“版本化向量库”的习惯每次模型升级都会绑定独立的向量版本号切换时彻底淘汰旧版本。第四要为“候选为空”和“候选分数过低”预留兜底逻辑。如果用户的请求匹配不到任何 Skill最优雅的兜底策略是明确回复“当前功能限制”而不是把不合适的 Skill 硬塞给模型。一开始我不舍得漏掉潜在可处理的请求后来发现“硬塞”的失败率非常高不仅任务完不成还给模型积累了错误模式。果断拒绝反而是一种更诚实的用户体验。写在最后的几个实操建议文章写到这核心机制已经拆得比较透了。最后分享几个我不会写在正式文档里的琐碎心得。第一如果你正被 Skill 数量问题困扰不要先急着重构可以先跑一周日志统计一下“实际会被调用的 Skill”有多少。我做过统计很多项目里 100 个 Skill高频被调用的其实只有 20~30 个。分层加载能影响的是整体架构质量但如果只想快速止血先把高频技能做一次手动“精选榜单”传给模型效果立刻能改观。这只是临时方案长期还是要靠结构化分层。第二三层架构的落地顺序建议是“先加标签路由层再考虑语义召回层”。标签路由简单可靠性能稳定语义召回依赖 Embedding 模型的质量和阈值调参坑更多。先把简单的一层跑稳了再叠加复杂层能大幅降低排查成本。第三日志和评估是分层加载方案的生命线。你永远需要知道“每一层掉了哪些候选”“模型最后选了谁”不然任何一层出了问题都难以及时发现。建议在第一层和第三层之间加一个 masked evaluation 的离线流程定期从请求日志里抽样本人工判断每一层是否有误杀。按这套机制改造后的系统在我自己的项目里跑了快半年最大的体会是Agent 其实不需要同时“知道”所有 Skill它只需要知道“当前这一步该用哪个”。把选择面缩小不只是性能优化更是模型稳定性的保障。如果你的 Agent 也在为 Skill 太多而困惑不妨先从分层这一步试起。