企业官网建设流程全解析

最近被一个实际问题卡了好几周:Agent 的技能列表从几十个涨到上百个之后,系统的表现不是你想象中的"能力变强了",而是"越来越蠢了"。具体症状是:模型选错工具的频次变高、响应变慢、甚至连续几轮都在调用同一个无关 Skill 绕圈子。我们团队排查到最后,发现根子不在推理链路,而在于一直没认真对待 Skill 的加载机制——说白了,技能都堆在仓库里,但 Agent 压根不知道该把哪些搬进工作台。

这个问题的解法,就是我们最后落地的多 Skill 分层加载机制。这篇就把它拆开讲清楚:为什么要分层、每一层放什么、路由和检索怎么做、上线后用什么指标看效果,以及我们在实际项目中踩过的几个大坑。如果你也在维护几十上百个 Skill 的 Agent 应用,这篇文章应该能帮你避开不少弯路。

1. 先看问题:上百个 Skill 全量加载,模型为什么就"乱"了

1.1 Skill 到底是什么:运行时可见的"能力卡片"

在 Agent 体系里,Skill 本质上是一个"能力单元"的封装。它包含两个部分:一段可执行逻辑——比如一个 Python 函数、一个 API 封装、一段外部工具的调用代码;以及一段供大模型理解和使用该能力的元数据——技能名称、功能描述、参数说明、适用场景示例、触发条件等。

可以把它理解成一张"能力卡片"。卡片正面写的是给模型看的话术:"当你需要做 X 时,请调用我";卡片背面才是真正干活的代码。模型在每一轮对话中,通过阅读这些卡片来决定要不要调用、怎么调用。

在不少开源 Agent 框架和自研系统中,这套机制都有类似实现,只是叫法不同:有的叫 Tool、有的叫 Plugin、有的叫 Action,底层逻辑大同小异。真正决定这套体系好不好的,不是编写函数的能力,而是"卡片上的描述质量"和"卡片在正确时间出现在模型面前的方式"。

1.2 全量加载的三个失控点:Token 膨胀、注意力稀释、选项过载

假设你有 120 个 Skill,平均每张能力卡片的元数据长度为 220 token——这个数字非常保守,实际很多项目里一个功能完善的 Skill 描述能达到 350 token 甚至更多。全量加载时,光技能描述就要吃掉 2.6 万 token 左右的上下文窗口。

这在许多场景下会造成连锁反应:

一是 Token 膨胀直接挤压对话历史的空间。上下文一旦逼近窗口上限,系统只能截断早期对话,导致多轮任务的记忆断裂,Agent 会反复追问用户已经给过的信息。

二是注意力稀释。大模型的注意力机制对超长列表的感知能力并不像我们期望的那么理想。当模型面对将近 100 个相似格式的能力卡片时,它更倾向于选择"描述写得更长、更具体、位置更靠前"的 Skill,而不是"真正匹配当前意图"的 Skill。

三是选项过载引发系统性偏好。我在测试中发现,当候选工具数量超过 20 个时,模型误调用的概率会明显上升,数量越多上升得越陡。最典型的翻车场景是:用户问"帮我算一下这笔订单的税费",模型却调用了"物流轨迹查询"——因为这两个 Skill 的描述里都出现了"订单"这个词,在 100 个卡片里,模型根本没法细致分辨微妙差异。

所以全量加载不是"能用但浪费",而是会直接损害 Agent 的决策质量。分层的价值,就是通过控制"每一轮实际暴露给模型的 Skill 数量",把决策问题从"100 选 1"简化成"5 选 1"甚至"3 选 1"。

2. 分层加载的核心思路:让不同 Skill 待在正确的"层"

我们把 Skill 仓库的加载逻辑分成了三层:L1 常驻层、L2 按需加载层、L3 会话动态层。三者的划分标准不是技能的重要程度,而是"场景普适性"与"生命周期长度"。

2.1 L1 常驻层:系统级技能,永远在线

L1 放的是那些在任何对话场景下都可能用到的基础能力,原则上不超过 8 个。例如:通用的信息检索、兜底的无参数问答、用户身份与权限识别、会话状态管理等。

这类 Skill 的特征是高频、横向、无场景偏向。它们不是某个垂直业务的专用工具,而是所有任务都离不开的地基。

L1 的加载方式是简单粗暴的"全部塞进上下文",而且必须放在 prompt 中最靠前的位置。为什么靠前?因为模型对前面的内容注意力更强,基础能力应该获得最稳定的可见性。

这一层的总量要严格控制。我们内部定的规则是:L1 总长度不超过 1500 token。超出这个阈值就必须开始排查,是不是某个业务专用 Skill 被误放进了常驻层。

2.2 L2 按需加载层:检索召回,每轮动态组装

L2 是分层机制的核心工作区。它包含除了 L1 和 L3 之外的所有业务 Skill,数量可能达到几十个甚至上百个。这些 Skill 都有明确的业务边界,比如"订单查询""库存扣减""优惠券核销""物流轨迹同步"。

L2 的加载方式是:在每一轮对话开始时,根据当前对话状态、用户最新消息、最近几轮意图,通过一套路由与检索机制,从技能仓库中动态选择 3 到 8 个候选 Skill,组装进系统提示或工具列表中。

这一层的核心挑战在于检索的准确性和路由的确定性。如果召回的候选里没有真正需要的 Skill,后续模型再聪明也只能矮子里拔将军;如果召回了一堆无关 Skill,则又回到了注意力稀释问题上。

我们在工程实践中采用的组合是:"场景分类 + 语义检索 + 关键词兜底"。后面第三章详细拆解。

2.3 L3 会话动态层:任务过程中临时产生和消亡

L3 对应的是在单次会话过程中临时产生、用完即弃的技能。典型场景有两类:

第一类是任务执行过程中的中间产物。比如 Agent 在执行数据分析任务时,现场生成了一段数据清洗脚本。你可以把这个脚本封装成一个临时 Skill,把它注册到当前会话的上下文里,后续几轮任务直接调用,而不用每次重新生成。

第二类是用户临时提出的一次性需求。例如用户在对话中说"接下来的对话里,凡是提到'那个系统'就是指订单管理系统,不要再问我是哪个系统"。这个临时约定,就可以作为一个 L3 Skill 注入当前会话。

L3 最大的特点是有明确的消亡时机:会话结束、任务完成或者超时未使用,都要立刻销毁,防止污染其他会话。这也是我们早期最容易踩坑的地方,后面会专门讲。

三层加起来,每一轮实际加载到上下文中的 Skill 数量被控制在了 10 个左右,元数据总长度控制在 3000 token 上下,约为全量加载的十分之一。决策空间小了,模型的准确率自然就提上来了。

3. 路由与检索设计:怎么让 Agent 知道"此刻该用哪个"

分层只是骨架,真正决定 Agent"知不知道用什么 Skill"的,是 L2 层的路由与检索机制。我们把这套机制拆成了两条路径:一条是"先分类后选择"的确定性路由,另一条是"边检索边兜底"的混合召回。

3.1 两级路由:先定场景,再选 Skill

一开始我们也尝试过直接用用户消息去检索 Skill,效果非常不稳定。原因很简单:用户的原话和 Skill 描述在字面上往往差距很大。用户说"我要把这批商品的价格改一下",Skill 描述里写的是"调用价格同步接口批量更新商品售价",纯靠字面匹配很难命中。

后来我们改成两级路由。第一级先让模型做一个"场景分类",判断当前请求属于哪个业务大类:订单、商品、库存、营销、金融、基础问答……这一步的任务相对简单,候选类别不超过 15 个,模型分类准确率能做到 97% 以上。

第二级再在对应的业务大类内部做 Skill 精排。这时候范围内的 Skill 数量通常只有 10 到 20 个,再配合语义检索和关键词加权,选出 3 到 5 个最可能的候选。

两级路由的好处是大大缩小了单次决策的候选空间,同时让第一级承担了"方向判断"的责任,第二级聚焦"细节匹配"。我们在一次对比实验里发现,单级检索的命中率在 70% 左右,改成两级结构后提升到了 92%——提升主要来自"大类判断"这一步过滤掉了大量跨领域的相似词干扰。

3.2 混合检索:Embedding 之外还要关键词兜底

在第二级精排时,单靠向量检索不够。一个很现实的场景是:用户输入"把订单 12345 的状态改成已发货",这个句子很短,语义向量和候选 Skill 描述之间相似度普遍偏低,排序会很散。

我们的做法是混合检索,三路并行:

第一路是向量召回,把用户消息和最近两个轮次的对话内容拼接后做 embedding,在 Skill 描述索引里找最接近的 top-10。

第二路是关键词召回,对用户消息做分词后,与 Skill 元数据里的关键词标签做精确匹配,命中即可加权,主要解决专有名词和业务编号的匹配问题。

第三路是规则召回,针对有明确格式依赖的 Skill 做强规则判断。比如用户消息里出现了"订单号 + 动词"结构,就直接把订单查询相关 Skill 拉进候选。

三路结果合并,做去重和加权重排,最终输出 top-5。这条路看起来比单纯调用一次 embedding 要麻烦,但实际跑下来,召回稳定性明显好得多。特别是关键词召回和规则召回,在业务术语非常固定的场景里,可靠性远超向量。

3.3 推理式路由:让 LLM 先"想"再"查"的边界

还有一种做法是完全交给 LLM 推理决定,即把 Skill 清单用分类目录的形式组织好,让模型先输出它认为当前需要哪几个技能,再去拉取对应 Skill 的完整描述加载进上下文。

这种做法在一些项目中效果不错,因为它让模型在"有限的目录视图"上做决策,而不是面对上百个完整描述。我们也在部分场景用了类似思路,但发现有几个边界要特别注意:

第一是目录本身不能太长。如果目录里也要列出 100 个技能名字和一句话简介,那本质上又回到了全量加载的注意力稀释问题。

第二是模型容易在"不确定"时选错方向,特别是多轮对话中上下文信息不足时,模型的第一次推理路由可能完全跑偏。所以推理式路由必须搭配"兜底重试"机制——模型给出类别后,如果从该类别下找不到高质量的候选 Skill,要允许它重新分类,而不是硬着头皮从错误类别里挑一个。

我们在实际项目中的选择是:推理式路由作为第一级"场景分类"手段,混合检索作为第二级"技能精排"手段,两者结合而非对立。这也符合当前大多数大模型 API 使用习惯——先用轻量级调用完成意图判断,再在最终请求中注入精简后的完整 Skill 列表。

4. 工程落地:分层加载的元数据与生命周期设计

分层思路讲清楚了,接下来是落地。这一章是我们在工程实现里真正沉淀下来的细节。

4.1 Skill 元数据规范:从这里写,检索质量就有底

无论分层还是检索,都建立在 Skill 元数据质量之上。我们内部定了一份元数据规范,每个 Skill 必须包含以下字段:

name:全局唯一标识,语义化命名,比如"order_query_by_id"。

summary:一句话功能描述,严格控制在 30 字以内,必须包含"当用户需要……时使用"的句式。它的核心作用是让模型和检索器快速判断"要不要看这个技能"。

description:详细描述,说明功能边界、输入参数、输出格式、典型的触发场景和禁忌场景。这里要和 summary 完全区分开,summary 用于筛选,description 用于最终决策。

keywords:业务关键词列表,3 到 10 个,用于关键词召回。

category:业务大类标识,与两级路由的第一级对应。

examples:2 到 3 个典型的用户提问示例,用于辅助语义索引。

level:层级标识,标记 L1 / L2 / L3,控制加载逻辑。

我在整理过程中最大的体会是:summary 和 keywords 才真正决定检索质量,description 决定模型执行质量。很多团队在 description 上花大力气,却把 summary 写成"用于处理相关业务",这种等于没写。检索器在召回阶段根本不看 description,只看 summary 和 keywords——召回都召不回来,写再详细的 description 也是白搭。

4.2 加载、执行、卸载:全生命周期怎么管

我们把 Skill 的加载逻辑做了一个统一的生命周期管理模块,每个 Skill 实例都要经历四个阶段:

加载阶段。根据当前对话上下文,由路由模块决定把哪些 Skill 注入本次请求。L1 固定加载,L2 每轮动态计算,L3 根据会话内的注册状态加载。所有加载操作都要考虑优先级和互斥规则,例如同属于排他类目的技能,要从加载就禁止同时出现。

执行阶段。模型在收到候选 Skill 列表后,根据用户近期意图决定调用哪个,调用参数由模型生成,系统负责传给实际函数。这里要做参数校验,防止模型注入非法值。

监控阶段。记录每次 Skill 的加载、调用和返回结果,形成一条带时间戳的流水线。不要小看这一步,后面评估分层效果的数据全靠它。

卸载阶段。会话级变量结束时清理 L3 临时技能;L2 技能在下一轮重新计算后自然淘汰;L1 常驻技能在会话开始时加载、结束时释放。此外,当上下文剩余空间不足时,还要做基于调用时间戳的 LRU 淘汰,优先保留最近真实调用过的技能。

我们初期犯过的一个错误是"只加载不卸载":L3 的临时技能注册进去之后,后续轮次一直带着,直到 token 爆掉才发现。后来强制引入生命周期之后,这个问题才彻底根治。

4.3 上线后的评估指标:判断分层有没有效

分层加载上线后,我们用了四个指标来衡量效果:

加载命中率:模型最终真实调用的 Skill 是否在本次预加载的候选列表里。这个指标直接反映路由和检索的准确性,我们内部目标压在 90% 以上。

无效加载率:加载了但从未被调用的候选比例。不是越低越好——太低说明候选太少,模型没得选;但太高说明检索召回精度不足,把无关技能塞进了上下文。我们觉得 30% 到 50% 是一个健康范围。

决策错误率:模型调用了错误 Skill 的比例。这个指标比命中率更严格,它反映的是候选列表里是否混入了"看似相关实则错误"的干扰项。

平均决策时延:从发起对话请求到模型做出工具调用决策的耗时。分层加载本身引入了检索计算开销,但如果链路设计合理,整体时延应该明显低于全量加载,因为模型在更小的选项空间里更快完成决策。

我们上线后拿到的实测数据是:全量加载时平均决策时延约 3.8 秒,分层加载后降至 1.9 秒。加载命中率从 70% 提升到 92% 左右,无效加载率稳定在 35% 上下。这个结果基本符合预期。

5. 踩坑实录:多 Skill 加载最容易翻车的几个点

5.1 技能幽灵循环:召回了却一直不用,还占着上下文

我们在 A/B 测试阶段遇到过一个非常诡异的现象:某次对话在"查询订单详情"这个任务结束后,接下来连续三轮里,模型都在调用订单查询 Skill,但调用参数一次比一次离谱,甚至传入空订单号。

排查了半天,发现根因出在召回机制上。那一轮对话的开场白里包含"帮我看看最近订单的情况",订单查询 Skill 被顺利召回并加载。但后续用户转而问"帮我分析一下退款金额的趋势",按道理该加载数据分析类 Skill。然而由于对话状态窗口滑动的设计问题,订单查询 Skill 的候选权重一直没有被清理,每一次新的路由计算都会把它重新召回,让它像幽灵一样赖在上下文里。

这种问题的根源在于:L2 的候选列表虽然是动态的,但计算逻辑对"历史加载记录"过于依赖,导致错误技能被持续复用。后来我们给召回逻辑加了一条硬规则:除了当前轮到的新候选之外,历史轮次加载过但在最近两轮里没有被真实调用的 Skill,在重新召回时必须降低优先级,除非新意图明确指向它。

5.2 描述重叠导致路由歧义:两个 Skill 长得太像

还有一个高频问题:两个不同的 Skill,业务逻辑截然不同,但描述写出来高度相似。我们曾经有一个"库存占用调整"和"库存预占释放"两个技能,底层一个加占用数一个减占用数。由于描述里都写"用于库存管理场景,传入商品 SKU 和数量",模型经常在"需要释放库存"时调用了"占用调整",导致数据被错误更新。

解决办法是两层:一是描述层要强制区分。给每个 Skill 增加"适用场景 explicitly 举例",比如库存占用调整的例子是"用户下单后临时锁定库存",预占释放的例子是"订单取消后恢复可售库存"。二是路由层要引入语义互斥检测。当两个候选 Skill 的向量相似度过高、并且属于同一互斥组时,要强制二选一,不允许同时出现在候选列表里,避免模型看到两个高度相似的选项后猜错。

5.3 动态层 Skill 生命周期失控:跨会话污染

L3 动态技能的生命周期管理是另一个重灾区。我们的早期实现里,临时技能注册在一个全局作用域里,结果出现了 A 会话里注册的临时技能,在 B 会话里被模型错误调用。最典型的一次是:一个用户让 Agent"记住,以后 Excel 文件都保存在 /data/exports/",这个约定被封装成了一个临时 Skill,结果其他用户在同一服务里也触发了这个 Skill,导致路径拼接错乱。

这不是并发设计问题,而是生命周期边界没画清楚。修复方案很简单:每个 Skill 实例从创建之初就绑定会话 ID,注册、调用、卸载都限定在会话作用域内。对于需要跨会话长期保留的偏好设置,应该走独立的用户配置存储模块,而不是做成 Skill 塞进上下文。

这块在工程上有一个经验值得分享:给 L3 动态技能统一加一个"来源标记"字段,每当模型调用它时,系统记录调用来源,方便回溯,也方便做自动过期清理。我们目前设定的默认过期时间是会话结束即销毁,如果任务中途超过 10 轮未调用,也会触发一次清理扫描。

最后再讲一点个人体会

踩了这么多坑之后,我对分层加载的理解已经从最初的"省 token"变成了"降低 Agent 的决策熵"。尤其是当技能数量过百以后,真正决定 Agent 上限的不是它拥有多少技能,而是它在每一步决策时,能不能把一个正确的小选项集摆在模型面前。分层、路由、检索、生命周期,本质都是在围绕这一件事做工程化。

如果你们项目里 Skill 数量还在二三十个,也许全量加载还能撑得住,不必急着上这套机制;但一旦超过五十个,你一定会遇到和本文开头一样的"变蠢"现象。到那时候,不妨先从元数据规范和分层逻辑入手——先把技能归类排好,再把路由检索做起来,效果会非常明显。哪怕不搞特别复杂的工程架构,只是把"全量塞入"改成"分类别加载",也能显著改善模型的工具调用表现。