论文标题：A Survey of Agent Skills: Toward Procedural Infrastructure for LLM Agents
论文链接：https://www.preprints.org/manuscript/202605.1276
过去一年，AI Agent 的讨论越来越热。
但你有没有发现一个变化： 大家已经不再满足于“让模型回答问题”，而是在追问一个更硬核的问题——如何让 Agent 稳定地完成复杂任务？
写代码、查网页、跑终端、调 API、操作 GUI、协作多智能体、长期记住经验……这些任务的共同特点是：不是一步问答，而是一连串动作。
也正是在这个背景下，一个关键词开始频繁出现：
Skill，智能体技能。
港科大（广州）与 IDEA Research 等机构最新综述 A Survey of Agent Skills: Toward Procedural Infrastructure for LLM Agents，系统梳理了 Agent Skill 的概念、表示、生命周期、运行时集成、治理风险与应用版图。文章给出的核心判断非常值得关注：
Skill 不是简单的 Prompt，也不是普通 Tool，而是 LLM Agent 迈向“可复用行动能力”的关键基础设施。
这篇文章，我们就用一文讲清楚：Agent Skill 到底是什么？为什么重要？它会如何改变下一代智能体系统？
01 从 Prompt 到 Skill：Agent 真正缺的不是“更会说”，而是“更会做”
早期的大模型应用，主要依赖 Prompt Engineering。
后来，大家发现只靠提示词不够，于是有了 Context Engineering：把记忆、检索、工具说明、用户偏好、任务背景都塞进上下文里。
再后来，Agent 开始进入真实环境：文件系统、浏览器、终端、数据库、API、代码仓库、多人协作流程……
这时问题变了。
不是“怎么问模型”，而是：
如何让模型在复杂环境里稳定行动？
综述中提到，Agent 工程正在经历一条清晰路径：
Prompt Engineering → Context Engineering → Harness Engineering
所谓 Harness，可以理解为包裹在模型外部的执行外壳：它负责连接文件、工具、终端、浏览器、记忆、权限和人类反馈。
而 Skill，正是在这个外壳里逐渐浮现出来的新抽象。
为什么需要 Skill？
因为 Agent 不能每次都从零开始推理。
一个人学会调试代码后，不会每次都重新发明调试流程；一个工程师熟悉某个项目后，也不会每次都重新探索目录结构。人类会把经验压缩成套路、方法、流程和检查清单。
Agent 也一样。
Skill 的本质，就是把反复成功的经验，压缩成未来可复用的行动程序。
02 一句话定义 Agent Skill
综述给出了一个非常清晰的定义：
Agent Skill 是一种可复用的程序性知识单元，它将重复经验、人类专家知识，或二者结合，压缩成可执行、可迁移、可验证的行为模式。
换句话说，Skill 解决的是“知道怎么做”的问题。
它通常需要回答四件事：
- 什么时候用？ 适用条件是什么？面对什么任务、输入、环境状态时应该触发？
- 怎么做？ 具体步骤是什么？是自然语言流程、代码片段、决策图，还是文件夹式 Skill 包？
- 用什么资源？ 需要哪些工具、脚本、文件、API、记忆或外部资料？
- 怎么判断做成了？ 有什么完成条件、质量检查、错误信号或验证标准？
综述中将 Skill 形式化为：
s = <C, P, R, E>
其中：
-
C：适用条件 Condition -
P：程序核心 Procedure -
R：资源接口 Resource -
E：评估标准 Evaluation
这个定义很关键，因为它把 Skill 从“提示词片段”升级成了一个完整的行动单元。
一个好的 Skill，不只是告诉 Agent 要做什么，还告诉它什么时候做、怎么做、依赖什么、如何验收。
03 Skill 位于 Memory 和 Rule 之间：它是“知道”到“做到”的桥梁
很多人会问：Skill 和 Memory 有什么区别？和 Rule 又有什么区别？
可以这样理解：
- Memory：记住过去发生了什么
- Rule：抽象出一般原则
- Skill：把经验变成可执行流程
比如，一个 Agent 做过一次网页购物任务。
Memory 会保存：“我上次在某网站搜索了 laptop，筛选了价格，加入购物车。”
Rule 可能会总结：“购物前要确认商品是否符合需求。”
Skill 则会写成：“当任务要求购买商品时，先解析约束条件，再搜索关键词，筛选候选商品，逐项检查颜色、尺寸、价格、库存，最后加入购物车并确认订单状态。”
这就是区别。
Memory 记录事实，Rule 提炼原则，Skill 组织行动。
综述中特别强调，Skill 的价值不只是节省存储空间，更在于：
减少重复规划、稳定长任务执行、提高行为可解释性。
对长程任务而言，这一点非常重要。因为 Agent 最大的问题往往不是“不知道答案”，而是在多步执行中：
- 走偏；
- 忘记目标；
- 重复探索；
- 错误调用工具；
- 没有检查结果；
- 无法复用过去经验。
Skill 的作用，就是把过去摸索出来的路径沉淀下来，下次直接复用。
04 Agent Skill 可以长什么样？
综述将 Agent Skill 的表示方式分成几类。每一种都对应不同的使用场景。
1. 自然语言 Skill：最轻量，也最灵活
最简单的 Skill，就是一段自然语言经验总结。
例如：
在网页搜索任务中，如果第一次查询没有得到结果，不要重复同一个搜索词；应该拆分问题、替换关键词，或先查询实体背景信息。
这种形式很像经验卡片、SOP、任务提示或启发式规则。
优点是：
易写、易读、易迁移。
缺点也明显：
执行依赖模型理解，不保证流程稳定。
适合用于搜索、问答、网页浏览、客服、轻量办公等场景。
2. 代码片段 Skill：把经验变成可运行程序
有些 Skill 可以直接写成函数。
比如在 Minecraft 智能体 Voyager 中，Agent 可以把“砍树”“制作石镐”“与僵尸战斗”等行为封装成可复用代码。
这类 Skill 通常包含：
- 自然语言描述；
- 可执行程序；
- 参数说明；
- 调用条件。
优点是：
可执行、可组合、结果更稳定。
缺点是：
需要运行环境，也需要测试代码正确性。
在软件工程、数据处理、终端任务、机器人控制中，代码 Skill 非常重要。
3. 决策图 Skill：把流程写成可检查的工作流
有些任务不是线性步骤，而是包含分支、判断和循环。
比如售后处理、表单审核、网页任务、客服 SOP。
这时可以用决策图表示 Skill：
- 节点表示动作；
- 边表示条件；
- 分支表示不同情况；
- 路径表示执行流程。
这种方式的优势在于：
可检查、可编辑、可控性强。
它比自然语言更结构化，又比代码更容易让非程序员理解。
4. 文件系统式 Skill：Claude Skills 代表的新范式
综述中重点讨论了 Anthropic Claude Skills 的文件夹式设计。
一个 Skill 可以是一个目录：
PDF-SKILL/
├── SKILL.md
├── FORMS.md
├── REFERENCE.md
└── scripts/
├── extract_tables.py
├── fill_forms.py
└── validate_pdf.py
其中 SKILL.md 是核心文件，里面包含：
- Skill 名称；
- 描述；
- 触发条件；
- 使用说明；
- 示例；
- 资源链接；
- 可调用脚本。
这个设计有一个非常重要的思想：
渐进式披露。
也就是说，Agent 一开始只看到 Skill 的名称和描述。只有当任务匹配时，才加载完整 SKILL.md；只有真正需要时，才继续读取脚本、参考文档或模板。
这解决了一个关键矛盾：
Skill 越详细越有用，但上下文窗口越容易爆。
文件夹式 Skill 让知识可以放在外部，按需加载，而不是一次性塞进 Prompt。
05 Skill 的生命周期：不是写完就完，而是要持续进化
综述提出，Skill 不应被看作静态提示词，而是一种会经历完整生命周期的操作性知识。
它包括五个阶段：
获取 → 存储 → 使用 → 维护 → 内化
获取：从经验中提炼 Skill
Agent 可以从三类来源获取 Skill：
第一类是成功轨迹。 比如一次任务做对了，就从中提炼可复用流程。
第二类是失败对比。 成功经验重要，失败经验同样重要。因为失败能告诉 Agent：哪些条件不满足、哪些步骤容易错、什么时候需要回退。
第三类是主动探索。 Agent 可以主动尝试新任务、阅读文档、分析代码库，从外部资源中挖掘新的 Skill。
这里最难的是把握抽象粒度。
Skill 太具体，就变成一次任务记录；Skill 太抽象，又无法执行。
好的 Skill 应该像工程师写的操作手册：既不是流水账，也不是空话。
存储：Skill 库不能只是一个大文件夹
当 Skill 数量变多后，问题会立刻出现：
- 怎么找到正确 Skill？
- 哪些 Skill 是高层规划，哪些是低层操作？
- Skill 之间有没有依赖关系？
- 哪些 Skill 可以组合？
- 哪些已经过期？
综述总结了几种 Skill 存储方式：
- 扁平存储：简单，但很快混乱；
- 层级存储：按粒度组织，如规划 Skill、功能 Skill、原子 Skill；
- 树状存储：按能力领域导航；
- 图结构存储：表达依赖、组合、替代、相似关系。
未来大规模 Skill 系统很可能不是一个“技能列表”，而是一个 Skill Graph。
使用：不是检索一个 Skill，而是装配一组可执行能力
很多人会把 Skill Retrieval 理解成语义搜索：用户任务来了，找最相似的 Skill。
但综述指出，这还远远不够。
真正的 Skill 使用，需要同时考虑：
- 当前任务意图；
- 环境状态；
- 执行历史；
- 上下文预算；
- Skill 之间的依赖；
- 工具可用性；
- 风险等级。
比如一个“生成月度财务报告”的 Skill，可能还依赖：
- 读取 Excel 的 Skill；
- 清洗数据的 Skill；
- 调用图表工具的 Skill；
- 检查数值一致性的 Skill；
- 输出 PDF 的 Skill。
所以，Skill 使用不是简单“命中一个文档”，而是：
在有限上下文中，组装一组最小但完整的执行能力。
维护：Skill 会变旧，也会互相冲突
Skill 写出来后，不代表永远正确。
工具 API 会变，网站页面会变，项目规范会变，安全策略会变。
因此 Skill 需要维护：
- 失败后修复；
- 成功后强化；
- 冗余 Skill 合并；
- 低价值 Skill 下线；
- 过期 Skill 标记；
- 版本回滚；
- 测试验证。
这很像软件工程中的包管理和版本治理。
Skill 越像基础设施，就越需要工程化维护。
内化：成熟 Skill 最终可能进入模型本身
外部 Skill 有好处：模块化、可编辑、可审计。
但也有成本：检索噪声、上下文占用、调用延迟。
因此，综述提出一个有意思的方向：当某些 Skill 足够稳定、通用、频繁使用时，可以通过训练或蒸馏，把它们“内化”进模型行为中。
也就是说：
Skill 库既是执行工具，也是训练脚手架。
短期靠外部 Skill 提升能力，长期把成熟经验压缩进模型参数。
06 Runtime Integration：Skill 真正发挥作用的地方
Skill 不是摆在仓库里的说明书。它必须进入运行时，才能变成行动。
综述把运行时集成分成几类。
终端 Agent：Skill 是命令行世界里的安全绳
终端非常强大，也非常危险。
Agent 可以在终端里：
- 查看文件；
- 安装依赖；
- 跑测试；
- 修改代码；
- 调用脚本；
- 访问服务；
- 生成报告。
但终端动作空间极其开放，Agent 很容易乱试命令。
Skill 在这里的作用是：
把反复出现的命令模式、诊断流程、验证步骤、人工确认点封装起来。
比如一个“修复 Python 项目测试失败”的 Skill，可以规定：
- 先运行测试并保存日志；
- 定位失败文件；
- 阅读相关函数；
- 做最小修改；
- 重新跑目标测试；
- 再跑全量测试；
- 总结变更。
这比让 Agent 每次自由发挥可靠得多。
Tool Agent：Skill 是高层意图和底层 API 的适配器
Tool 很重要，但 Tool 本身只告诉模型“能调用什么”。
它通常不会告诉模型：
- 什么时候调用；
- 多个工具如何排序；
- 中间结果如何判断；
- 失败如何恢复；
- 什么时候停止。
Skill 正好填补这个空白。
Tool 是原子动作，Skill 是可复用流程。
比如电商场景中，Tool 可能包括：
- 搜索商品；
- 查看商品详情；
- 加入购物车；
- 结算；
- 查询订单状态。
而购买商品的 Skill 会组织这些 Tool：
解析需求 → 搜索商品 → 筛选候选 → 检查属性 → 加入购物车 → 确认订单
这就是为什么综述强调：
Skill 既不是 Prompt，也不是 Tool，而是连接推理与执行的中间层。
多智能体系统：Skill 是协作协议
在多 Agent 系统里，不同 Agent 可能扮演产品经理、工程师、测试员、审查员等角色。
但如果没有 Skill，协作很容易变成开放式聊天：
- 谁负责什么？
- 输出格式是什么？
- 什么时候交接？
- 失败如何反馈？
- 谁来验证？
Skill 可以把这些协作模式写成流程：
角色职责、输入输出、交接标准、验证方式、异常处理。
从这个角度看，Skill 不只是单个 Agent 的能力，也可以是多智能体系统的“组织记忆”。
Agent Harness：未来的运行时会内置 Skill 层
真正成熟的 Agent Harness，不能只是把模型接上工具。
它应该内置 Skill-aware Runtime：
- 能根据任务检索 Skill；
- 能按需加载 Skill 内容；
- 能绑定工具、文件、终端和工作区状态；
- 能监控 Skill 是否按预期执行；
- 能记录成功和失败；
- 能把新经验反哺 Skill 库；
- 能在高风险动作前请求人类确认。
一句话：
未来的 Agent Harness，不只是执行壳，而是 Skill 的运行、治理和进化平台。
07 Governance：Skill 也会成为新的安全攻击面
Skill 越强大，风险也越大。
因为 Skill 往往可以接触：
- 本地文件；
- API Key；
- 终端命令；
- 浏览器状态；
- 用户数据；
- 外部服务；
- 第三方依赖。
这意味着，Skill 生态很可能继承软件供应链的风险，并引入 Agent 特有的新风险。
综述重点讨论了几类威胁：
1. Skill 注入攻击
恶意指令可以藏在 Skill 文件、注释、说明文档甚至辅助资源里。
一旦 Agent 加载 Skill，就可能被诱导执行危险操作。
这比普通 Prompt Injection 更麻烦，因为它不是一次性输入，而是持久化在可复用组件中。
2. 恶意 Skill 和后门 Skill
某些 Skill 可能表面上是生产力工具，实际包含：
- 凭证窃取；
- 数据外传；
- 远程命令执行；
- 隐藏依赖；
- 触发式后门。
当 Skill 市场发展起来后，这类风险会类似 npm、PyPI 的供应链问题。
3. Skill 克隆与漏洞传播
如果一个有漏洞的 Skill 被大量复制、改名、分发，漏洞也会随之扩散。
这会让治理变得很难：你修复了原版，不代表所有衍生版本都安全。
4. 权限过大与隐式信任
用户通常不会逐行审计 Skill。
他们可能只看名称、描述、下载量、分类标签。
这会形成“隐式信任”。
而 Agent 一旦加载 Skill，就可能在用户不完全知情的情况下执行复杂操作。
所以综述提出，未来 Skill 系统必须具备：
- 来源验证；
- 权限分级；
- 沙箱隔离；
- 运行时监控；
- 人类审批；
- 安全扫描；
- 版本审计；
- 回滚机制；
- 合约式约束。
Skill 不是普通文本，而是可执行行为的载体。
这句话，可能会成为未来 Agent 安全治理的基本共识。
08 Skill 的应用版图：从机器人到代码智能体
综述最后梳理了 Agent Skill 的主要应用场景。
1. 机器人：Skill 是语言和物理动作之间的契约
在机器人场景中，Skill 可以连接高层语言指令和低层控制器。
比如“拿起杯子”不是一句话那么简单，它涉及：
- 识别杯子；
- 判断可达性；
- 规划抓取点；
- 控制机械臂；
- 检查是否成功。
Skill 可以把这些流程封装成可调用能力。
2. 开放世界游戏：Skill 是长期探索的积累
Minecraft 等开放世界环境，是研究 Agent Skill 的经典场景。
因为这里有长程目标、稀疏奖励、资源依赖、组合任务。
一个 Agent 学会“砍树”“挖石头”“制作工具”后，这些 Skill 可以继续组合成更复杂目标。
开放世界游戏展示了 Skill 的一个核心价值：让 Agent 的能力可以持续积累。
3. Web Agent：Skill 是网页自动化的稳定流程
网页任务有很多重复结构：
- 搜索；
- 筛选；
- 点击；
- 填表；
- 对比；
- 提交；
- 验证；
- 异常恢复。
Skill 可以把低层点击轨迹抽象成可复用流程，让 Agent 不必每次从头摸索网页。
4. GUI / Mobile / OS Agent：Skill 是数字设备操作层
在手机和桌面系统里，Agent 面对的是像素、窗口、按钮、菜单、弹窗、权限和应用状态。
Skill 可以把常见操作编译成参数化模板：
- 打开某 App；
- 搜索联系人；
- 发送消息；
- 导出文件；
- 修改设置；
- 跨 App 完成任务。
这类 Skill 的难点是环境会变：App 更新、按钮位置变化、权限弹窗出现、屏幕尺寸不同。
因此 GUI Skill 不仅要能执行，还要能检测失败并修复。
5. 软件工程 Agent：Skill 是工程实践的抽象
在代码智能体中，Skill 尤其重要。
真实软件开发不是“写一个函数”这么简单，而是：
- 理解 issue；
- 定位文件；
- 阅读上下文；
- 修改代码；
- 补测试；
- 跑测试；
- 修复失败；
- 提交补丁；
- 解释变更。
这些都是可复用的工程 Skill。
比如：
- 代码定位 Skill；
- 单元测试生成 Skill；
- 回归测试 Skill；
- 性能优化 Skill；
- 依赖升级 Skill；
- Bug 修复 Skill；
- Code Review Skill。
综述也指出，并不是 Skill 越多越好。错误的 Skill 可能占用上下文、误导模型，甚至降低任务成功率。
因此软件工程场景需要的不是“堆 Skill”，而是：
可评估、可裁剪、可组合、可验证的 Skill 体系。
09 未来挑战：Skill 会成为 Agent 的“包管理系统”吗？
综述最后提出了几个非常关键的开放问题。
第一，如何评估 Skill 的真实价值？
不能只看任务成功率。
还要看：
- 是否被正确触发；
- 是否真的改善执行；
- 是否减少成本；
- 是否能迁移；
- 是否鲁棒；
- 是否和其他 Skill 冲突；
- 是否带来安全风险。
Skill 需要作为一等对象被评估，而不是藏在 Agent Pipeline 里的黑盒组件。
第二，如何处理 Skill 与上下文窗口的矛盾？
Skill 太短，不够用。 Skill 太长，占上下文。 Skill 太多，检索噪声大。 Skill 太少，覆盖不足。
未来系统需要更聪明的 Skill Disclosure：
在正确时刻，以正确粒度，加载正确内容。
第三，如何解决 Skill 冲突？
不同 Skill 可能给出相反建议。
一个强调安全检查，一个强调速度；一个适用于 React 项目，一个适用于 Vue 项目；一个来自企业内部规范，一个来自开源社区。
这就需要 Skill Arbitration，也就是 Skill 仲裁层。
它不仅判断“相关不相关”，还要判断：
能不能同时用？谁优先？是否符合当前项目和用户意图？
第四，如何避免 Skill 漂移？
Skill 会在使用中不断修改。
但改着改着，可能越来越偏离原本目标。
这类似软件中的技术债：
- 局部补丁越来越多；
- 适用边界越来越模糊；
- 行为越来越不可预测；
- 老版本难以追踪。
因此 Skill 也需要像软件一样管理：
版本、测试、回滚、审查、发布、弃用。
第五，Skill 会不会成为下一代 Agent 基础设施？
这是综述最重要的观点之一。
未来 Skill 可能不再是某个 Agent 的小插件，而会像软件包一样，拥有完整生态：
- Skill Registry；
- Skill Package Manager；
- 依赖管理；
- 权限模型；
- 安全扫描；
- 版本控制；
- 评价体系；
- 运行时隔离；
- 企业私有 Skill 库。
也就是说：
Agent Skill 很可能成为 AI Agent 时代的“npm / PyPI”。
但这一次，包里装的不只是代码，还有 Agent 的行为模式。
10 总结：Skill 是 Agent 从“聪明”走向“可靠”的关键一步
这篇综述最大的价值，是把 Agent Skill 从零散概念整理成了一个完整框架：
- 本体层：Skill 是什么；
- 表示层：Skill 如何编码和打包；
- 生命周期层：Skill 如何获取、存储、使用、维护和内化；
- 运行时层：Skill 如何接入终端、工具、多 Agent 和 Harness；
- 治理层：Skill 如何安全可信地分发和执行；
- 应用层：Skill 如何服务机器人、游戏、网页、GUI、OS 和软件工程。
如果说 Tool 让模型“能做事”，Memory 让模型“记得事”，那么 Skill 让模型开始“会做事”。
更准确地说：
Skill 是 Agent 把经验变成能力的接口。
它不是一个提示词技巧，也不是一个简单插件，而是未来智能体系统中可复用、可组合、可审计、可进化的程序性基础设施。
下一阶段的 Agent 竞争，可能不只是谁的模型更强，也是谁拥有更好的 Skill 生态：
谁能更快沉淀经验，谁就能更快提升 Agent； 谁能更好治理 Skill，谁就能更安全地部署 Agent； 谁能构建可复用 Skill 基础设施，谁就可能拥有下一代智能体平台的入口。
Agent Skill 的时代，才刚刚开始。