AI智能体技能管理：300个Skill精准调用技巧

以某开发项目为例，方案中一次性集成了51个Agent与35项技能，这还不包括此前陆续推出的工具，比如让AI具备真实浏览器能力的那种。技能数量激增后，一个核心矛盾浮现：Agent如何精准匹配当前任务与可用技能？

北京大学的研究团队聚焦于一个关键命题：如何让技能描述“写对”，从而提升系统选技能的准确性。他们提出的方案是将人类阅读的SKILL.md文档转化为机器可查询的三层JSON结构图。实验结果证实，技能检索准确率提升12%，安全风险评估效率提升24%。

据一位用户反馈，其Agent环境已安装300多个技能，这种情况颇具代表性。一方面，上下文窗口不断膨胀；另一方面，过长的上下文反而导致大模型难以决策，无法确定调用哪个技能以完成当前任务。

SKILL.md的混合表示瓶颈

以论文附录B中的Writing Refiner（写作润色器）为例。

其SKILL.md描述大致如下：“根据用户提供的草稿文本与写作上下文，加载风格指南，解析写作意图，选取适用的编辑规则，对文本进行润色，最终返回修订后的文本及所应用编辑原则的列表。”

这段描述实际上混杂了四类性质截然不同的信息：

• 技能功能：润色文本。
• 调用方式：输入草稿文本与写作上下文，输出修订文本及应用原则列表。
• 执行流程：验证输入 → 解析上下文 → 加载指南 → 选择规则 → 应用修订。
• 安全边界：需要文件系统读取权限，依赖文本处理能力。

当Agent系统需要调用此Skill时，必须同时回答三个问题：

第一，该Skill与当前任务是否匹配？这涉及“意图签名”与“输入/输出契约”。
第二，该Skill的执行流程是什么？需明确分几个阶段、阶段间如何跳转。
第三，该Skill是否安全？它访问了哪些资源？是否会删除数据？是否包含网络调用？

这三个问题的答案实际上都已存在于SKILL.md中，但问题是它们全部混杂在一起。每当系统需要做出判断，都必须从头到尾解析全文。论文将这种现象称为“表示瓶颈”——语义上不同的属性被压缩到了单一的文本表面。

问题根源：检索效率与安全盲区

论文从两个方向详细拆解了纯文本表示为何不够用。

为何技能检索如此困难

从技能池中筛选出合适的技能，本质上是将用户请求与一个或多个可执行能力进行匹配。

表面上看，这类似于查询与文档检索，但关键区别在于：每个候选并非普通文本，而是一个可执行的能力。

神经检索领域的研究早已指出，表示质量是匹配的核心。进一步针对工具与技能的检索工作发现，能力匹配所依赖的信号分散在接口字段、指令文本、示例、实现细节与结构依赖中。通用的检索器很难稳定地迁移到工具或技能的选择场景。

若检索器仅依赖一小段元数据描述，可能遗漏关键线索；若通读数千字的SKILL.md全文，有用的调用信号又被噪声淹没。关于工具文档压缩与增强的研究也表明，冗长的工具描述通常需要预处理和重组才能实现有效检索。

然而，这些工作均忽略了一个前提假设：候选表示必须已经以合适的形态存在。每个技能在检索前应如何表示，才能让匹配过程利用显式的接口、结构与操作线索，而非仅依赖原始文档文本？这一问题始终未得到系统性的回答。

为何安全风险难以从文本描述中检出

工具使用Agent的安全风险通常出现在自然语言指令与外部能力的边界处。

间接提示注入研究显示，检索或工具返回的文本可能模糊数据与指令的边界。而Agent安全基准将这一担忧延伸到更复杂的多步设置中，涉及工具调用、内存读写、不可信的外部观察以及有害的用户目标。在这些场景下，攻击者无需直接修改代码，只需在Skill的文本描述中嵌入一段看似无害的指令，便可绕过审查。

提示流完整性、强制访问控制、最小权限执行等安全机制，将安全限定为权限边界与资源访问问题。即：谁可以访问什么资源，在什么条件下可以访问，访问之后可能产生什么后果。

针对技能本身的安全研究进一步指出：可复用技能本身即构成一个独立的攻击面。它包含自然语言指令、可执行代码片段与隐式信任关系，并能通过分发和复用在不同的Agent之间传播。这些副作用若仅通过阅读纯文本，几乎不可能发现。你需要知道每个动作的类型、资源范围以及是否存在数据流向外部的线索——而这些信息都散落在长篇的自然语言描述中。

因此，安全分析面临真正的挑战：如何在技能被调用之前，使风险相关的证据变得可检查。这些证据包括动作类型、资源范围、依赖关系与数据流线索。例如，先前有研究发现，89.2%的攻击成功率正是源于这类结构性漏洞。

SSL表示：三层解耦与结构化重构

SSL的核心思想简洁明了：将上述三类信息拆分为三个独立的层，每层只负责一个职责。

调度层 → 技能的能力范围与调用方式
结构层 → 技能的执行阶段与阶段流转
逻辑层 → 每一步的原子动作与资源占用

论文借鉴了认知语言学的三个经典理论来设计这三层结构，这三个类比是SSL的骨干，而非单纯的标签。

理论基础：认知科学借来的框架

调度层类比“记忆组织包”（Memory Organization Packets）。该概念源于Schank（1980）的研究：人类记忆组织重复经验时，并非按关键词存储，而是将经验打包成“目标+情境”单元。例如“去餐厅吃饭”，并非存储一个“吃”标签，而是包含入场、点单、结账的完整节奏。SSL的调度层同样如此：将Skill打包为“意图签名+输入输出契约+依赖项”的能力单元。这样，系统无需展开细节即可判断：该Skill能做什么？是否适合当前任务？

结构层类比“脚本理论”（Script Theory），源自Schank与Abelson（1977）的经典工作。核心观察是：人类刻板活动并非线性的意识流，而是由一系列可预期的场景组成。以餐厅用餐为例，活动由“进门→就座→点餐→用餐→结账→离开”等场景构成，每个场景都有自身的进入与退出规则。SSL的结构层同理：将Skill拆解为PREPARE、ACQUIRE、REASON、ACT、VERIFY、RECOVER、FINALIZE等类型化场景，每个场景均标注输入输出、进入条件、退出规则及下一场景的跳转逻辑。

逻辑层类比“概念依赖”（Conceptual Dependency），由Schank于1972年提出。他认为语言意义的底层可分解为有限种类的原始动作结构：ATRANS（抽象转移）、PTRANS（物理转移）、MOVE（移动）、MBUILD（心智构建）等。SSL的逻辑层受此启发，定义了12种原子动作类型：READ、SELECT、COMPARE、VALIDATE、INFER、WRITE、UPDATE_STATE、CALL_TOOL、REQUEST、TRANSFER、NOTIFY、TERMINATE。每个原子动作从封闭清单中选择act_type，并将参数、效果与资源边界记录为类型化证据。关键原则：原子性是表示的属性，与运行时细节无关。逻辑步骤即源工件支持的最小操作单元，绝不无中生有地发明缺失的实现细节。

形式化定义

论文给出SSL的形式化表示：

G_d = (r_sch, G_str, G_log, R_cont, R_entry)

其中，r_sch代表调度层，捕获调用信号的技能级接口记录；G_str代表结构层，捕获执行阶段及其转换的场景级图；G_log代表逻辑层，捕获原子动作与资源使用证据的逻辑步骤图；R_cont记录跨层的包含关系；R_entry记录入口指针。

在实现层面，r_sch实现为单个技能级记录，其余两层实现为记录图：场景记录将G_str实例化为执行阶段上的有向图；逻辑步骤记录将G_log实例化为这些阶段内原子动作上的有向图。两个辅助关系指定组装方式：R_cont将场景分配给技能，将逻辑步骤分配给场景；R_entry标识遍历的起始位置。

三个设计目标

SSL遵循三个严格的设计目标：

紧凑性。仅保留技能管理与使用所需的证据，主动排除开放式或主观属性。不评估技能质量，不描述用户画像，不推断开发者意图，不推测隐藏行为。

类型化。采用受限词汇表，使输出在技能间具备可比性。例如，scene_type仅限PREPARE/ACQUIRE/REASON/ACT/VERIFY/RECOVER/FINALIZE七种；act_type仅限READ/SELECT/COMPARE等十二种。完全禁止自由文本。

接地性。字段严格总结源工件中存在的证据，不推断隐藏行为。若SKILL.md中未提及某个操作，对应字段保持为空，不得从上下文编造。

调度层：技能级接口与能力记录

调度层不将技能视为指令文档，而是将其作为调用级能力单元对待。在深入检查之前，它首先暴露支持的意图、输入/输出契约以及粗粒度的依赖与控制流属性。这为每个技能提供了一个稳定的能力记录，使其能在不展开完整场景或逻辑步骤结构的情况下，跨仓库进行比较。试想一个仓库中有500个Skill，你无需逐一展开内部结构，仅通过调度层即可完成初筛。

结构层：场景级执行阶段划分

结构层的节点是场景，边表示这些场景之间的阶段级转换。受脚本式事件结构启发，它将低级操作分组为连贯的阶段：PREPARE（准备）、ACQUIRE（获取）、REASON（推理）、ACT（行动）、VERIFY（验证）、RECOVER（恢复）。这使得技能的阶段组织在读者检查单个逻辑步骤之前即可展现。看到结构层，你便能快速理解：该Skill的执行分为几个阶段？每个阶段的进入条件与退出条件是什么？阶段之间如何跳转？是否存在分支或回退路径？

逻辑层：原子动作与资源使用证据

逻辑层的节点是逻辑步骤，边表示基于源代码的原子动作之间的微级转换。每个原子动作从封闭的原始清单中选择act_type，并将参数、效果与资源边界记录为类型化证据。例如，若某步骤标注act_type = CALL_TOOL、resource_scope = NETWORK，即可识别为外部调用；若标注resource_scope = CREDENTIALS，则立即知晓涉及凭证访问。由于原子性是表示的属性，逻辑步骤即为源工件支持的最小操作单元。该层回答：该技能在每一步具体做了什么？访问了哪些资源？会产生什么效果？

具体实现：规范化管道

如何将SKILL.md转换为SSL JSON对象？论文采用DeepSeek-V3.2作为规范化器，执行四个步骤：

第一，提取技能级调度记录。
第二，将文档分解为场景。
第三，将每个场景扩展为基于源代码的逻辑步骤。
第四，验证生成的图结构。

规范化器严格作为语义提取器运行，避免开放式摘要。其提示明确指定了模式、允许的词汇表与接地策略，每个填充字段必须由源工件支持。

验证环节检查六项硬约束：结构良好性、标识符一致性、允许的枚举值、包含链接无环、入口指针指向有效记录、转换目标引用现有记录或终止值。解析失败或验证失败的输出将被重试。

在6,500个候选技能上，经过两遍规范化后，6,184个生成了有效的SSL对象，成功率达95.1%。第一遍使用DeepSeek-V3.2的Thinking模式，温度设置为0.1；失败或格式错误的，使用Non-Thinking模式重试，温度同样为0.1。论文还进行了人工审计：对100个标注技能检查接地质量，83%的SSL输出被判定为可由对应源工件支持。

以下是论文附录B中Writing Refiner经过规范化后的完整SSL对象（JSON结构示例）。将此JSON与前面的自然语言描述对比，差异一目了然。

在自然语言描述中，你需要AI自行判断：“该技能是否涉及网络？是否有文件操作？”而在SSL中，直接查看resource_scope字段即可。同样，自然语言描述需要AI理解：“该技能执行分几个阶段？失败后如何处理？”而在SSL中，直接查询scenes数组与next_scene_rules便能得到答案。

效果验证

技能发现：检索准确率提升12%

论文构建了包含6,184个公开技能的检索候选池，测试集包含431个意图级请求，覆盖功能性、基于约束、组合式、面向安全与场景式五种类型。每个查询仅有一个正确答案，即其源技能。

十种检索输入在统一的嵌入与排序管道下比较。所有稠密向量由Qwen3-Embedding-0.6B生成，使用FAISS内积索引进行排序。

实验结果清晰：最强非SSL基线（Desc + Source Outline）的MRR@50为0.649；而Desc + SSL-Rich达到0.729，提升12.3%。更关键的是，它甚至超越了完整SKILL.md全文的0.645，说明增益并非来自文本堆叠。

消融实验的发现颇具启发：SSL-Shallow（仅浅层规范化）已比原始描述提供显著增益，MRR@50从0.588跃升至0.716；SSL-Sched（增加调度视图）效果反而不如Shallow，可能是因为调度视图虽紧凑但缺少场景级组织信息；SSL-Rich（三层全开）效果最佳，MRR@50 = 0.729，因为它集成了场景级与接口级信号，这正是意图级技能搜索最需要的匹配线索。Recall@10的变化更为直观：Desc_only为0.761，Desc + SSL-Rich为0.905，用户在前十名中找到正确技能的比例提升了14个百分点。

风险评估：检出率提升24%

风险评估基准从6,184个技能中分层抽样252个，涵盖六个风险维度：数据泄露、破坏性行为、权限升级、隐蔽执行、资源滥用、凭证访问。黄金标签由三个大模型投票产生，存在分歧的维度进行二次审查并辅以抽样人工审计。

最佳方案为Full SKILL.md + SSL，宏F1从纯文本的0.409提升至0.509，提升比例高达24%。每个维度的结果均显示，组合视图在所有六个维度上均为最强。

提升最显著的是三个维度：凭证访问（0.695 → 0.780），因为SSL的逻辑层直接标记了哪些步骤访问CREDENTIALS资源范围，无需从自然语言中猜测；数据泄露（0.511 → 0.699），因为SSL暴露了NETWORK与LOCAL_FS资源访问，这些是数据泄露的核心静态信号；资源滥用（0.271 → 0.419），因为SSL的结构层展示了执行阶段与执行次数，可用于判断是否存在资源消耗循环。

一个重要发现是：Full SSL单独使用时宏F1为0.422，仅比纯文本的0.409略有提升；但Full SKILL.md + SSL直接跃升至0.509。召回率的增益尤为关键——组合视图恢复了纯文本输入经常遗漏的弱但具体的风险信号，同时精度保持甚至提升。这表明SSL不能替代源文档，而应作为源文档旁的“结构化证据层”使用。SSL负责暴露动作类型与资源范围，源文档则负责解释操作的必要性、调用条件及限制。

Agent系统如何落地

如果你或你的团队正在管理数百个Skill，可以从以下三个方向借鉴SSL的思路：

第一，为Skill添加一层结构化清单。无需构建完整的三层JSON图。最简单的起点：在每个Skill的元数据中引入intent_signature字段，使用一两个自然语言短句描述该Skill能够响应哪些请求。这已远强于全文向量检索。论文的消融实验中，仅添加SSL-Shallow即可将MRR@50从0.649提升至0.716。Shallow层仅包含调度层的基本字段：intent_signature、expected_inputs/outputs、dependencies、tags。这些字段可直接从任何技能文档中提取，无需复杂的场景分解与逻辑步骤展开。

第二，在安全审查中用结构化证据替代全文阅读。目前大多数Agent系统的安全审查仍依赖人工阅读SKILL.md全文。SSL的逻辑层提供了另一种路径：让审查者直接查看每个步骤的act_type与resource_scope。若一个Skill的所有逻辑步骤的resource_scope均为MEMORY，基本可判定为低风险。若出现NETWORK、CREDENTIALS、LOCAL_FS的组合，则需重点审查。act_type只有12种，resource_scope只有8种——这种设计将安全检查从“读一段话猜风险”转变为“查字段做判断”。

第三，将结构化表示与源文档配对使用，而非二选一。这是论文最重要的实践教训。SSL的最佳表现始终出现在“源文档 + SSL”的组合中，而非SSL单独使用。因为自然语言中包含结构化字段无法表达的内容：设计意图、边界条件、使用场景的限制说明。SSL提供索引与线索，源文档提供上下文与解释，两者相辅相成。

论文原文：https://arxiv.org/abs/2604.24026
代码仓库：https://github.com/COOLPKU/SSL
数据集：Hugging Face (SSL-SkillDiscovery / SSL-RiskAssessment)