这项由北京大学计算语言学教育部重点实验室及计算机学院联合主导、中文系参与的研究，以预印本形式发表于2026年4月（arXiv编号：2604.24026v3），尚未正式刊载于具体期刊或会议，感兴趣的读者可以通过该编号检索原文。
当你雇了一个助手，给他一本厚厚的工作手册，里面写满了他该做什么、怎么做、用哪些工具、碰到什么情况该怎么处理。这本手册对你来说很好读——毕竟是用正常语言写的。但如果你需要从一千本这样的手册里快速找到"那个会帮你整理财务表格并自动更新数据的助手"，或者想在让助手动手之前先确认他会不会在不知情的情况下把你的私人文件发到外面去，那你就麻烦了。因为这一千本手册里，什么都搅在一起：什么时候该叫他、他会用哪些工具、他会碰哪些文件，全塞在一段段连续的文字里，没有明确分类，没有标准格式，看起来给人读的，机器要处理起来却非常吃力。
北京大学的研究团队正是针对这个问题展开研究。在当今越来越流行的AI智能体系统里，"技能"（Skill）是一个核心概念，它指的是一个打包好的能力单元，包含操作指令、执行流程、约束条件和工具调用方式，可以被智能体随时取用和组合。然而，这些技能目前普遍以"技能说明文档"（SKILL.md）的形式存在，本质上就是一份供人阅读的文字说明。机器想要用它，就必须每次都重新"理解"整篇文章，费时费力，而且容易出错。
研究团队提出了一套名为"调度-结构-逻辑表示"（Scheduling-Structural-Logical，简称SSL）的新型结构化表示方法，试图把这本说明书"翻译"成机器能直接读懂的三层结构图，同时不丢失原文的任何重要信息。这是目前已知的首个专门为智能体技能设计的结构化表示方案，团队通过两项具体任务——"技能发现"和"风险评估"——验证了它的实际效果，并在两项任务中均超越了只用原始文本的对比方案。
一、说明书乱成一锅粥，机器怎么找到该用哪个"助手"
回到开头那个雇助手的场景。现实中的AI智能体系统里，技能数量可能成千上万。每次需要完成一个任务，系统都得从这堆技能里找出最合适的那个，就像在一个巨大的人才市场里，根据岗位描述找到最匹配的候选人。
问题是，现有的技能说明文档（SKILL.md）就像一份格式不统一的简历。有的写得详细，有的只有三行字；有的先说擅长什么，有的先说限制条件；工具调用方式、执行步骤和适用情境统统混在一起，没有固定位置。机器在理解这类文档时，相当于每次都要重新"读完整份简历"才能判断这个人合不合适，效率极低。
更棘手的是，现有技能文档把至少三类性质截然不同的信息混在一起：第一类是"调用接口信息"，也就是什么情况下应该召唤这个技能、它需要什么输入、会产生什么输出；第二类是"执行结构信息"，也就是这个技能会经历哪些阶段、这些阶段如何衔接；第三类是"操作证据信息"，也就是技能在运行中会做哪些具体动作、会碰哪些资源（文件、网络、密钥等）。这三类信息对不同的使用场景各有侧重，但在原始文档里，它们全部挤在一段段连续的自然语言里，无法单独提取。
研究团队把这个现象形象地称为"表示瓶颈"：语义上本应分开的东西，因为都用自然语言写，所以被压扁成了同一个平面，没法区分。
二、从古老的语言学理论里，找到了拆开说明书的方法
北京大学的团队没有凭空发明一套拆解框架，而是从上世纪的认知语言学经典理论中寻找灵感。他们借鉴了心理语言学家罗杰·尚克（Roger Schank）和罗伯特·阿贝尔森（Robert Abelson）在上世纪七八十年代提出的三套理论体系，将其作为SSL框架的设计类比。
第一套理论叫"记忆组织包"（Memory Organization Packets），描述的是人类记忆如何围绕目标和情境来组织已有经验。SSL的"调度层"（Scheduling Layer）就以此为参照，把一个技能看作一个"可调用的能力单元"，专门记录它能服务于哪些用户意图、需要什么输入、会产生什么输出、有哪些依赖条件和控制流特征。这一层就像一张简洁的"技能名片"，让系统不需要读完整份说明书就能快速判断这个技能是否适合当前任务。
第二套理论叫"脚本理论"（Script Theory），描述的是人类如何把日常活动理解为一系列有顺序、有预期的"场景"，比如"去餐厅吃饭"这件事在人脑中会自动展开成"进门—入座—点菜—等待—用餐—结账—离开"的固定流程。SSL的"结构层"（Structural Layer）受此启发，把技能的执行过程拆解成若干"场景"（Scene），每个场景有明确的类型（如准备、获取、推理、执行、验证、恢复、结束）、目标、输入输出约定、进入和退出条件，以及指向下一个场景的跳转规则。这一层就像一张执行流程图，让审查者不必逐行阅读原文就能看懂这个技能会经历哪些阶段。
第三套理论叫"概念依存"（Conceptual Dependency），描述的是如何把自然语言中的动作分解为一套有限的原子操作，比如"转移"、"写入"、"通知"等，从而在不同表述方式之间建立共同的语义基础。SSL的"逻辑层"（Logical Layer）正是以此为参照，把每个场景内的操作进一步分解为原子逻辑步骤，每个步骤标注动作类型（从一个封闭词表中选取）、操作对象、所用工具、输入参数、输出绑定、前置条件、产生效果、资源范围和资源目标。这一层就像一份操作流水账，让安全审查者可以精确看到这个技能会读哪些文件、调哪些接口、写哪些数据。
这三层结构共同构成了SSL表示的核心骨架，对应原始文档里那三类"本应分开却混在一起"的信息。
三、把说明书变成结构图，具体是怎么做的
SSL框架在实际使用中，依赖一个基于大型语言模型（LLM）的"标准化工具"（Normalizer）来完成从原始SKILL.md文档到SSL结构图的转换。这个工具的工作方式类似一个严格的摘录员：它只允许从原文中提取信息，不能猜测、补充或发明原文中没有明说的内容。
标准化工具按照四个步骤依次工作。第一步是提取技能层级的调度记录，包括技能目标、意图签名、标签、顶层模式、预期输入输出、依赖项、控制流特征，以及入口场景标识符和所包含的场景列表。第二步是将原文分解为两到五个宏观场景，每个场景要对应源文件中的一个明确阶段或里程碑，并补充场景类型、数据契约（输入输出）、进出条件和跳转规则。第三步是将每个场景展开为若干原子逻辑步骤，每步要标注动作类型（从封闭词表中选取）、角色、工具、资源范围、资源目标、前提和效果。第四步是验证：检查全局唯一标识符、合法枚举值、合法跳转目标、合法包含关系和入口指针；不合格的输出会被重试，而不是静默接受。如果某个字段在原文中找不到支撑，标准化工具会留空或使用最粗粒度的分类，而不是凭空填入一个值。
SSL在技术实现上是一个类型化的JSON图，包含三个相互链接的表示层级。技能记录存储调度接口，场景图存储阶段级跳转，逻辑步骤图存储动作级跳转。跨层链接只有"包含关系"（哪些场景属于这个技能、哪些逻辑步骤属于这个场景）和"入口指针"（从哪里开始执行）两种，确保阶段结构和原子操作保持分离。
为了让各个技能的规范化结果可以相互比较，SSL使用了四类封闭词表：场景类型包含准备、获取、推理、执行、验证、恢复和完成七种；逻辑原语包含读取、选择、比较、验证、推断、写入、更新状态、调用工具、请求、传输、通知和终止十二种；资源范围包含内存、本地文件系统、代码库、进程、用户数据、凭证、网络和其他八种；终止目标包含成功结束、失败结束、成功返回上层和失败返回上层四种。这些封闭词表有意设计得较为粗糙，目的是防止出现五花八门的自定义标签，同时保留对执行行为、资源接触和风险相关操作进行比较的能力。
四、第一场考试：在六千多个技能里找到那个"对的人"
研究团队为SSL设计了一套"技能发现"评测方案，模拟的是这样一个场景：用户描述了一个任务需求，系统需要从一个包含6184个技能的候选池里找到最匹配的那个技能。
评测基准的构建分两步。团队首先收集并整理了6184个公开可用的技能作为候选池，然后从中随机抽取200个技能，为每个技能自动生成若干个任务描述型查询，最终得到403个查询。每个查询的"正确答案"就是生成它时所基于的那个源技能。查询集涵盖五种风格：功能型（直接描述想要完成什么）、约束型（附带特定限制条件）、组合型（同时要求多个功能）、安全导向型（关注潜在风险或权限要求）和场景式（描述一个具体使用场景）。五种类型大致均衡，各约80个。
评测使用了相同的检索流水线：用Qwen3-Embedding-0.6B模型将技能表示和查询分别编码为向量，然后通过FAISS内积索引进行排序，最后用平均倒数排名（MRR）作为主要指标，同时报告NDCG@5、NDCG@10和Recall@10。
参与比较的方案共分三组。第一组是不使用SSL的基线："仅描述"方案只嵌入技能的短文字描述，"完整SKILL.md"方案嵌入整个原始文档，二者的MRR分别为0.573和0.602。第二组是在短描述基础上叠加不同深度SSL字段的方案：浅层SSL（仅加技能名、标签、目标）达到MRR 0.698，调度视图（加意图签名、控制流特征、场景概要）达到0.680，而最丰富的SSL视图（加场景类型及目标、依赖项、顶层模式、预期输入输出）达到了0.707。第三组是在完整SKILL.md基础上叠加SSL的方案，MRR在0.643到0.652之间，反而不如仅描述加SSL组。
这个结果揭示了一个反直觉的规律：把完整的原始文档塞进嵌入模型，并不比用一段简短描述加上精心提炼的结构化字段效果更好。原因在于，原始文档里充满了对检索没有帮助的叙述性文字，这些文字稀释了真正有用的接口信号和场景信号，而简洁的结构化摘要反而让检索向量更加"纯粹"。浅层SSL已经能带来显著提升（从0.573跳到0.698），而最丰富的SSL视图再进一步（到0.707），说明场景层和接口层的信息都在发挥作用。Bootstrap置信区间显示，"仅描述"到"描述加最丰富SSL"的改进区间为[0.100, 0.168]，统计上非常可靠。
按查询类型细看，约束型查询的改善幅度最大，场景式查询的绝对值最高，而完整文档加SSL方案在场景式查询上表现最好。这表明不同查询类型对不同层级的技能信号有不同的依赖，SSL的多层结构能够照顾到这种多样性。
五、第二场考试：在技能被使用之前，先看清它藏着哪些风险
第二项评测模拟的是一个更严肃的场景：在把一个第三方技能部署到系统里之前，先对它进行风险审查。毕竟，一个写得很正经的技能说明书里，可能暗藏"会把用户文件发到外部服务器"、"会删除重要数据"或"会悄悄在后台持续运行"这类危险行为，而这些风险用肉眼从一段段文字里找出来，既耗时又容易遗漏。
风险评估基准从同一个6184技能语料库中抽取了500个技能，采用分层抽样以保证样本中包含足够多的"高风险信号"技能——那些有工具调用加网络或凭证资源访问的技能优先入选，有分支或循环的次之，其余的补充到低信号层。
评估维度共六个：数据渗漏（把本地或用户数据发送到外部）、破坏性行为（删除或不可逆地修改文件、数据库、云资源等）、权限提升（获取超出任务所需的授权范围）、隐蔽执行（以隐藏或难以审计的方式运行）、资源滥用（引发无限循环、大规模调用等超量消耗）和凭证访问（读取、传输或暴露密码、密钥、令牌等）。每个技能在每个维度上被打1到5分，1分代表没有可观察到的风险信号，5分代表有明确或严重的风险。
金标准标签由三个更强的模型（Gemini-3.1-pro-preview、Claude-Sonnet-4.5和GPT-5）共同标注，每个模型都同时看到完整的SKILL.md和完整的SSL表示，取三者的中位数作为最终金标准分。团队还对500个样本中的100个进行了人工抽查，验证标准一致性和标签与原文证据的对应关系。
在评测阶段，固定评判模型为DeepSeek-V3.2，只改变提供给它的输入表示，从而隔离"SSL带来的信息变化"对判断结果的影响。五种输入分别是：仅注册名称和描述（最弱）、完整SKILL.md（基线）、仅浅层SSL字段（名称、目标、标签）、完整SSL（不含原始文档）、以及SKILL.md加完整SSL（最强）。
主要评测阈值是"是否存在非平凡风险信号"（得分大于1算正向），关键结果如下：仅描述的宏观F1为0.669，完整SKILL.md为0.744，仅浅层SSL为0.704，完整SSL为0.775，SKILL.md加完整SSL达到了最佳的0.787。Bootstrap置信区间显示，从完整SKILL.md到SKILL.md加完整SSL的改进区间为[0.019, 0.069]，同样具有统计可靠性。
按维度细看，SSL的优势在数据渗漏、破坏性行为和凭证访问三个维度上最为明显，这三类风险都与明确的动作类型（写入、传输）和资源范围（网络、凭证）直接对应，SSL的结构化字段能很自然地"点名"这类证据。相反，权限提升和资源滥用两个维度上完整文档仍有优势，因为这两类风险的判断往往需要结合上下文语境——审查者需要读懂"这个操作在这个场景里是否超出了正常权限范围"，光靠字段不够用。
在更严格的阈值（得分大于等于3算中度以上风险）下，完整SKILL.md的F1为0.638，高于完整SSL的0.600，说明要判断风险的严重程度，原始文档提供的背景叙述仍然不可或缺。而在平均绝对误差（MAE，衡量预测分数与金标准分的平均差距）这个指标上，SKILL.md加SSL以0.307的结果拿到了最低值，进一步支持了"SSL作为补充证据而非替代品"的定位。
六、结构化信息的价值，以及它无法独立承载的东西
两项评测结合起来，揭示了一幅清晰的图景。SSL最擅长把那些"散落在原文里但性质明确"的信息显式化——调用接口、执行阶段、动作类型、资源边界。当一项任务的核心就是对这类信息进行匹配或识别时，SSL带来的增益非常显著。
但技能说明文档里还有另一类信息，是SSL目前无法承载的：设计理由、安全警示、失败处理建议、使用限制背后的语境、以及那些需要结合整体叙述才能判断"严重程度"的风险信号。这类信息依赖叙述性语言的连续性，不能简单地填进一个字段。正因如此，研究团队明确建议：SSL应当与原始文档搭档使用，而不是取而代之。结构化表示负责"把重要的东西摆在显眼的地方"，原始文档负责"提供解读这些东西所需的语境"。
团队还特别指出了一个反面案例。有一个叫server-actions的技能，它的功能是生成可以修改数据库的Next.js服务端动作代码。SSL在标注它的资源范围时，侧重于它直接操作的内容（本地代码库和内存），但没有充分反映它所生成的代码在运行时会接触数据库和Sentry监控系统。结果，加了SSL之后，评判模型反而把这个技能的风险评低了，给出了全是1分的预测，而完整文档的预测(2, 2, 2, 1, 1, 3)要准确得多。这个案例点出了SSL当前的一个根本性局限：它只能从静态文档中提取信息，无法推断"技能生成的代码在运行时会产生什么副作用"。
七、这套框架更大的意义，以及它还没有做到的事
从更宏观的视角看，SSL解决的是一个"共享清单层"的问题。随着智能体系统里的技能库越来越大，注册表、路由器、策略检查器和人工审查者每次都要从头解析同一份SKILL.md文件，这不仅低效，而且每次解析结果还可能不一致。SSL把那些关键事实变成持久的、紧邻原文的结构化记录，让注册表可以索引调用信号，让检查工具可以展示阶段结构，让策略审查者可以直接检查逻辑层面的动作和资源使用证据，同时保留随时访问原始文档的通道。
研究团队也坦诚地列出了当前阶段的几项局限。首先，SSL从静态文档中提取，无法确定动态行为，比如运行时下载的载荷、动态构建的命令，或条件性资源访问。其次，标准化工具依赖LLM，对于描述模糊或经过混淆的技能，可能会遗漏关键信息，或者把不确定的行为强行归入某个粗粒度类别。第三，当前评测只覆盖技能发现和风险评估，尚未直接测试SSL对智能体在执行阶段（规划、执行、监控、事后改进）的实际影响。第四，技能发现基准使用的是自动生成的查询，而非真实用户请求，这可能高估了SSL在"浅层字段匹配"上的表现。第五，风险标签来自多模型投票流水线，评判结果反映的是受控模型协议下的结构化风险识别，而非专家审计或真实世界危害率。
研究团队认为，SSL最自然的下一步是从"管理技能"迈向"辅助使用技能"。在执行阶段，智能体可以借助SSL来选择候选技能、追踪执行检查点、识别需要人工确认或资源敏感处理的步骤。在技能维护方面，SSL的预期输入、阶段边界、依赖关系和资源效果字段可以作为持续更新的参照。更长远地看，可以考虑把单个技能的SSL图链接成仓库级别的技能知识图谱，或者用运行时轨迹来丰富静态标准化的结果。
说到底，这项研究想解决的是一个非常具体但影响深远的问题：既然智能体系统越来越依赖可复用的技能，那技能本身的"说明书"就不能一直停留在"人类好读、机器难用"的状态。SSL是一次有实际效果的尝试，它不宣称自己是最终答案，也不假装能解决所有问题，但它确实在一个长期被忽视的环节——技能的表示本身——迈出了有据可查的一步。对于那些正在构建或研究智能体系统的人来说，这个方向的价值不在于某个具体的数字，而在于它指向了一种更清晰的系统架构思路：让结构和原文各司其职，而不是把所有东西都压进一段文字了事。有兴趣深入了解的读者，可以通过arXiv编号2604.24026查阅完整论文，相关数据集和代码也已在GitHub开放。
Q&A
Q1：SSL表示和普通的SKILL.md说明文档有什么实质区别？
A：SKILL.md是一份供人阅读的文字说明，把调用接口、执行步骤、工具使用等信息混在连续的自然语言里，机器每次处理都要重新"读懂"全文。SSL则把这些内容拆分为三层结构化记录：调度层记录"什么时候调用、输入输出是什么"，结构层记录"执行分几个阶段、怎么跳转"，逻辑层记录"每一步做什么操作、碰哪些资源"。两者不是替代关系，SSL是对原文的补充，不是取代，研究团队明确建议同时保留原始文档。
Q2：SSL风险评估能替代人工安全审查吗？
A：不能替代。SSL风险评估是在技能执行前，帮助评判模型或审查者更快识别"哪些字段暗示了潜在风险"，但它只能分析静态文档中的证据，无法判断技能运行时的动态行为，比如技能生成的代码在运行后会产生什么副作用。论文也指出，判断风险严重程度（而不只是有没有风险信号）时，原始文档提供的叙述语境仍然不可或缺，SSL更适合作为提示工具而非最终裁判。
Q3：SSL框架现在可以直接用在实际智能体系统里吗？
A：研究团队已经开放了SSL标准、标注语料库和评测数据集，标准化工具也基于现有大型语言模型实现。但团队明确表示，SSL目前是一个实用性的初步步骤，而非完整标准或端到端解决方案。当前主要验证了"技能发现"和"风险评估"两个场景，在规划、执行监控等智能体实际运行阶段的效果尚未系统评测，对于描述模糊或经过混淆的技能，标准化工具的提取质量也存在不确定性。
热门跟贴