当大模型开始学会装技能包

前言

论文原文Agent Skills for Large Language Models: Architecture, Acquisition, Security, and the Path Forward。

当大模型开始学会装技能包

大模型正在从“什么都懂一点”走向“需要什么就装什么”。这不是提示词技巧的小改良，而是智能体架构的一次明显转向：把原本塞进模型权重、长提示词或固定工具链里的能力，拆成可以按需加载、组合、治理和审计的技能包。理解这一点，基本就能看清下一代智能体系统为什么会长成现在这个样子，也能看清它接下来最大的机会和最大的问题分别是什么。

过去几年，扩展大模型能力主要靠三条路。第一条是提示词，把要求写得更细；第二条是工具调用，让模型能访问外部函数和 API；第三条才是正在成形的技能体系。它的关键变化在于，智能体不再只在“会不会调用某个工具”这个层面扩展能力，而是在“遇到这类任务时，应该按什么流程理解、决策、执行、回退”这个层面获得成套的程序性知识。

这意味着，技能不是一个函数，也不是一段固定提示词。它更像一个可携带的工作方法包：里面可以有说明文档、执行脚本、参考资料、模板文件，甚至还可以附带权限边界。模型不是一直把这些内容全部带在上下文里，而是在相关任务出现时再逐级加载。也正因为如此，技能体系同时解决了两个长期矛盾：一方面让通用模型具备更强的专业执行能力，另一方面又避免把所有知识永久塞进模型上下文或模型参数里。

技能的价值不在于多一个文件，而在于把程序性知识变成可加载的模块

理解技能体系，先要把它和提示词、工具区分开来。

提示词的问题是短期有效、难以复用，也很难治理。它当然能影响模型行为，但这种影响是临时的、脆弱的，换个任务、换个模型版本、换个上下文长度，效果就可能明显波动。工具调用则解决了执行问题，但工具本身通常是原子的。它只定义输入和输出，不负责教模型如何完成一整类任务。

真正复杂的任务，往往需要的不只是“调用哪个工具”，而是“先做什么，再做什么，哪些情况该分支处理，失败后怎么补救”。例如处理 PDF，不只是暴露一个“填写表单”的函数，而是需要明确什么时候先提取文本、什么时候需要 OCR、什么时候应该检查格式、什么时候应当写回文件，以及要规避哪些边缘情况。技能体系把这些流程知识显式打包，于是模型获得的不是单个动作，而是一整套做事方法。

从这个角度看，技能工程可以理解为提示词工程和工具工程之间再往前走一步。它把“如何完成任务”的知识从零散经验，变成了可以存储、共享、组合和审计的资产。对组织来说，这一点尤其重要。许多原本依赖个人经验的流程，终于可以以标准化形式沉淀下来，而不是随着人员流动一起消失。

技能体系真正的架构创新，是分层加载而不是一次性塞满上下文

技能之所以能扩展，不靠上下文窗口无限变大，而靠“渐进披露”的加载方式。

一个技能通常以目录形式存在，核心文件是 SKILL.md。智能体启动时，只预加载非常短的元信息，例如技能名称和描述。这样做的好处是，一个系统可以挂载很大的技能库，但不会在一开始就把上下文挤爆。只有当用户请求与某个技能匹配时，系统才进一步加载这项技能的完整说明。再往下，如果说明里确实需要脚本、参考文档或模板资源，系统才继续按需读取更深层的内容。

这套机制之所以重要，是因为它把“能力规模”和“上下文成本”拆开了。以前，一个智能体若想覆盖更多任务，常常意味着更长的系统提示、更复杂的工具描述，以及更高的推理成本。技能体系把这些成本延后到真正需要时才支付。于是，一个拥有大量专业能力的智能体，不必在每次对话一开始就背着全部说明书工作。

这种设计也改变了技能与函数调用的关系。函数调用的本质是执行，工具返回一个结果；技能的本质是准备，它先改变模型对任务的理解方式、允许使用的资源，以及后续可采取的行动路径。也就是说，技能不直接生成结果，而是先把智能体放进一个更适合完成当前任务的状态里。

技能和 MCP 不是替代关系，而是智能体栈里的上下两层

只看技能还不够，因为技能解决的是“应该怎么做”，但很多任务还需要“怎么连上外部世界”。

这就是技能和 MCP 的分工。MCP 提供的是一种标准化连接层，用来把智能体和外部数据源、工具、服务端点连起来。技能负责告诉智能体应该采用什么流程、如何解释结果、失败时怎么回退；MCP 负责把这些外部能力可靠地暴露出来。前者偏程序性知识，后者偏连接能力。

这两个层次放在一起，才构成一个完整的智能体执行栈。技能定义方法，MCP 提供通道。一个技能完全可以要求智能体调用某个 MCP 服务、解释服务返回的数据，并在连接失败时改走备用路径。这样一来，系统不再是“模型直接碰工具”，而是“模型通过技能组织方法，再通过 MCP 接入世界”。

如果说过去的工具调用把大模型变成了会按按钮的系统，那么技能加 MCP 的组合，开始让它更像一个知道流程、知道边界、也知道如何调用基础设施的执行者。

技能不是只能手写，真正有潜力的方向是让智能体自己形成、复用和组合技能

技能体系最有意思的地方，不只是人可以写技能，而是技能本身正在变成一种可学习、可演化的中间层。

最直接的方式当然还是人工编写。这个门槛并不高，一个技能可以只是一个结构清晰的 Markdown 文件，也可以再附带脚本和模板。这样做的优势是可控、可读、可审计，尤其适合企业把内部流程固化成可复用的操作模块。

但真正拉开上限的，是技能可以通过经验积累出来。一个方向是强化学习配合技能库：智能体在连续任务中完成工作，同时把有效的方法沉淀成可复用技能，并在后续任务中反复调用。这样做不仅能提高任务成功率，还能明显减少交互步骤和 token 消耗。换句话说，技能不是额外负担，反而可能是降本增效的关键。

另一个方向是自主发现技能。面对从没见过的软件环境，智能体可以先探索、建立状态理解，再逐步生成更复杂的任务，通过不断试错总结出可迁移的操作模式。这一点对桌面软件、企业系统和图形界面任务尤其关键，因为这些环境变化快、界面异构性强，很难靠一次性人工覆盖。

还有一种更工程化的路线，是把技能做成结构化技能库。每个技能不仅有说明，还有参数类型、前置条件、可组合规则和失败恢复逻辑。这类表示方法的价值在于，它更适合长流程任务，因为系统可以更明确地判断“什么时候能用这个技能”“缺什么参数”“失败后该接哪一步”。

再往前一步，就是动态组合技能。很多复杂问题并不对应某一个现成技能，而是需要多个技能拼起来。数学推理、跨应用办公流程、混合 GUI 与代码执行任务，往往都属于这种情况。能否从技能库里选出合适组件，并在求解过程中临时拼成一个工作流，已经成为衡量智能体成熟度的重要指标。

但这里也出现了一个非常现实的上限：技能库不是越大越好。随着技能数量膨胀，路由和选择会变得越来越困难。一旦库太大，系统对该选哪个技能的判断精度可能会突然下降。这意味着技能生态的挑战不只是“如何生产更多技能”，还包括“如何在规模上来之后仍然准确地选对技能”。

技能最先跑起来的主战场，是电脑操作智能体

技能体系为什么最近升温这么快，一个重要原因是它刚好撞上了电脑操作智能体的需求。

要操作电脑，智能体必须在视觉感知、界面定位、规划决策、动作执行和状态记忆之间连续切换。它既要看懂屏幕，又要知道点哪里、什么时候输入、什么时候调用代码、什么时候读取本地文件。这样的任务天然不是一个函数调用能解决的，它更像一串需要程序性知识支撑的链式行为，因此特别适合用技能来组织。

在这种架构里，用户给出任务后，技能路由器先判断该激活哪些技能。被选中的技能把说明、脚本和工具权限注入当前上下文。随后，智能体核心开始工作：先感知屏幕或 DOM，再做界面定位，接着规划动作，最后通过点击、输入或代码执行去影响环境。与此同时，系统还要维护轨迹记忆、历史状态和技能缓存。MCP 层则负责把 GitHub、数据库、本地文件等外部资源接进来。

这也是为什么技能体系和 GUI 智能体的发展几乎同步。图形界面任务既长、又细、又容易出错，最需要明确的分步方法、失败恢复策略和权限边界。技能在这里不只是方便，而是几乎成了可用性的前提。

从基准表现看，这个方向进展很快。桌面、移动端和混合 GUI-代码任务的成功率都在明显提升，某些基准上甚至已经逼近或超过人工基线。但这并不意味着问题已经解决。更长程、更专业、步骤更多、环境变化更大的任务仍然暴露出明显短板，尤其是在复杂软件操作、长时间任务坚持和高精度界面定位上。

界面定位的突破，决定了技能能否在真实电脑环境里落地

电脑操作智能体里最难的一环之一，是 GUI grounding，也就是准确找到屏幕上该操作的元素。

这个问题如果做不好，再聪明的技能也很难落地。因为技能再会规划，最终也得落到“点对地方、输对位置、读对区域”。近来的突破主要来自更大规模的界面数据、更强的视觉定位模型，以及强化学习驱动的自我进化训练。结果是，小模型在某些界面定位任务上，已经能超越更大但训练方式较旧的模型。

这件事释放了一个明确信号：技能体系要真正进入生产环境，不能只靠语言层面的流程知识，还必须和稳定的视觉-动作接口绑在一起。技能决定做什么，界面定位决定能不能做成。两者缺一不可。

技能最大的短板不是功能不够，而是信任模型太粗糙

技能体系越有用，安全问题就越不能回避。

问题的根源在于，技能同时混合了自然语言指令和可执行代码，而智能体一旦加载技能，就会倾向于把这些内容视为可信上下文。也就是说，技能不是普通文档。它既能影响模型的理解，又可能进一步影响模型调用工具、访问文件、执行脚本的方式。这让它天然形成了一个新的攻击面。

已经暴露出来的风险大致有四类。第一类是提示注入，把恶意指令埋进长说明、脚本引用或参考文件里，让智能体在不知不觉中偏离原任务。第二类是数据外流，例如诱导读取敏感文件、窃取密钥或通过网络传出内容。第三类是权限提升，也就是利用技能放大本不应获得的工具能力。第四类是供应链风险，例如伪装品牌、污染依赖、把恶意内容伪装成社区技能分发。

更值得警惕的是，安全问题不是零星个案。社区技能中存在漏洞的比例并不低，而且带有可执行脚本的技能，风险显著高于纯说明型技能。这背后的逻辑不复杂：一旦技能从“告诉模型怎么做”扩展到“直接附带可运行代码”，攻击面就会立刻扩大。

因此，技能治理不能再停留在“要么信任，要么禁用”的二元逻辑上。真正合理的做法，是把信任做成分层、把权限做成渐进、把运行后的表现纳入持续监控。

一个更合理的治理框架至少应包含三层意思。

第一层是验证闸门。技能上线前不该只看描述，而应依次经过静态分析、语义一致性检查、沙箱行为验证，以及权限声明校验。前两步解决“它表面上写了什么”和“它实际上想干什么”之间是否一致，后两步解决“它运行后到底做了什么”和“它声明的能力是否和实际行为匹配”。

第二层是信任分级。不是所有技能都该拿到同样权限。未经审计的社区技能，最多只能被当成说明文本使用，不能直接获得工具权限；经过更充分验证的技能，才可以逐步获得只读工具、受限文件访问、声明范围内的执行能力，直到最高级别的完整权限。这样做的核心原则不是方便，而是最小权限。

第三层是生命周期演化。技能不是过审一次就永久可信。运行时仍然需要监控：是否出现异常工具调用，是否在试探权限边界，是否做出了与声明不符的行为。表现稳定的技能可以逐渐提升信任等级，异常技能则应降级、撤销甚至隔离。

这套思路有一个非常重要的优点：它正好与技能的分层加载机制天然对应。最浅层的元信息风险最低，完整说明风险更高，脚本和外部资源风险最高。治理不必粗暴地一刀切，而可以和攻击面大小精确对齐。

技能生态接下来最值得关注的，不是再多几个案例，而是解决七个真正卡脖子的难题

技能体系已经证明它有用，接下来决定它能否长期成立的，是几个更基础的问题。

首先是跨平台可移植性。技能看似是开放标准，但不同平台的执行环境、工具签名和模型行为并不一样。只要一个技能暗中依赖某家平台的特性，它就谈不上真正可移植。未来要么需要更统一的运行时，要么需要把技能编译到不同平台的适配层。

第二是大规模技能选择。技能数量少时，路由还比较容易；一旦进入企业级规模，如何从上百上千个技能中选出对的几个，将成为一个独立难题。这个问题本质上不是检索，而是理解任务、理解技能边界、理解多技能之间关系后的组合决策。

第三是技能编排。现实任务往往不是单技能完成的，而是多个技能之间共享状态、协调资源、处理冲突和接力恢复。现在已有一些初步方案，但离成熟的多技能编排框架还很远。

第四是基于能力的权限模型。技能不应因为“被加载了”就默认可以调用系统里所有工具。更合理的做法，是每个技能明确声明所需能力，再由系统或用户进行显式授权。

第五是技能验证与测试。软件包有单元测试和 CI/CD，技能目前还缺少同等级的标准化测试框架。如何证明一个技能确实完成了它声称的任务，而且没有做多余的事，这是一个同时涉及工程实践和 AI 安全的问题。

第六是持续学习而不破坏原有能力。模型能否不断习得新技能，同时不损伤已有表现，仍然是开放问题。动态加载技能会不会反过来干扰模型默认行为，也还没有被充分理解。

第七是评测方法。今天的大多数基准仍主要看任务是否完成，但这并不等于技能本身质量高。一个好技能还应该可复用、可组合、可维护，并且在环境变化后仍然稳健。未来更需要评估的是“技能生态的质量”，而不仅仅是“某次任务跑没跑通”。

技能体系真正改变的，是组织如何把经验变成可执行资产

站在更大的视角看，技能体系最重要的意义，也许不只是技术栈更先进，而是它让“经验”第一次变得像软件资产一样可以管理。

过去很多组织里的关键流程，靠的是资深员工脑中的隐性知识。文档写不全，流程说不清，工具虽然有，但新人还是做不好。技能体系把这些原本难以传递的程序性知识显式化、模块化，于是组织经验可以像代码一样沉淀、像包一样分发、像系统能力一样被调用。

这会带来很强的网络效应。每多一个高质量技能，平台整体就更有价值；每多一个被验证、被治理、被复用的技能，组织对智能体的信任就会提高一层。但同样，安全治理如果跟不上，技能生态也会很快重复软件包管理、插件市场和应用商店曾经历过的老问题。

所以，技能体系接下来的关键，不是证明它能做更多事，而是证明它能在开放、可复用和安全可控之间建立稳定平衡。只有这三者同时成立，技能才不会只是智能体领域的一阵热潮，而会变成下一代智能系统真正的基础设施。