在开发项目所使用的技术方案中，一次性集成了51个Agent与35个技能，这还不包含此前陆续推出的各类实用功能（例如为AI配置真实浏览器环境）。技能数量激增后，一个关键问题随之浮现：Agent如何才能精准判断该调用哪个技能？

北京大学发表的这篇论文，核心聚焦于一个目标：教会AI如何“正确撰写”技能描述，从而使系统能更准确地匹配并选择技能。研究团队提出的解决方案是：将原本面向人类阅读的SKILL.md文档，转化为机器可高效检索的三层JSON结构化数据。实验结果表明，技能检索准确率提升了12%，安全风险评估效率提升了24%。

有用户反馈称自己安装了300多个技能，这种现象极具代表性。一方面，上下文窗口需要承载的内容越来越多；另一方面，上下文长度增加后，大模型反而容易陷入选择困境，难以确定该调用哪个技能来完成任务。

SKILL.md的困境

先来看一个来自论文附录B的示例：Writing Refiner（写作润色器）。

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

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

• 技能能做什么：润色文本。
• 如何调用：输入草稿文本、写作上下文，输出修订文本、应用的原则列表。
• 执行步骤：先验证输入、再解析上下文、再加载指南、再选择规则、最后应用修订。
• 安全边界：需要文件系统读取权限、依赖文本处理能力。

当一个Agent系统试图使用这个技能时，它必须同时回答三个问题：

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

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

问题的根源：检索与安全

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

技能检索为何困难

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

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

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

如果检索器只查看一小段元数据描述，可能会遗漏关键线索；如果让它通读数千字的SKILL.md全文，真正有用的调用信号又被噪音淹没。关于工具文档压缩与增强的研究也指出，冗长的工具描述通常需要预处理和重组，才能被有效检索。

然而，所有这些工作都忽略了一个前提假设：候选表示必须以合适的形态存在。每个技能在检索前究竟该如何表示，才能使匹配过程利用显式的接口、结构和操作线索，而不只是依赖原始文档文本？这个问题一直未被认真对待。

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

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

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

提示流完整性、强制访问控制、最小权限执行这些安全工作，将安全框定为了权限边界和资源访问问题，即：谁能访问什么、在什么条件下能访问、访问之后有什么后果。

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

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

SSL表示：三层解耦

SSL的核心思想很简单：将上述三类信息拆分到三个不同的层次中，每一层只负责一件事。

调度层 → 这个Skill能做什么、怎么调用
结构层 → 这个Skill的执行流程分几步
逻辑层 → 每一步具体做了什么操作、碰了什么资源

论文借鉴了认知语言学的三个经典理论来设计这三层，这三个类比是SSL的骨架，而不仅仅是贴上去的标签。

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

调度层类比的是“记忆组织包”。这个概念源于Schank 1980年的研究：人在记忆里组织重复经验时，并非按关键词存储，而是将经验打包成“目标+情境”的单元。例如“去餐厅吃饭”，不是存成一个“吃”的标签，而是一个包含入场、点单、结账的完整节奏。SSL的调度层正是发挥这个作用：将技能打包成“意图签名+输入输出契约+依赖项”的能力单元。这样，系统在不展开细节的情况下就能判断：这个技能能干什么？是否适合当前任务？

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

逻辑层类比的是“概念依赖”，由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)