Agent Skill 技能系统：从能力封装到可进化资产的工程化全链路
2026-07-27 Agent Skill 技能系统：从”能力封装”到”可进化资产”的工程化全链路
📅 学习日期：2026-07-27 | 📚 来源：AI Agent 知识库 | 📝 综合文章数：5 篇
为什么选这个主题
前两篇笔记已覆盖了 Agent 架构演进（宏观坐标系）和记忆系统（成长性引擎），今天深入第三个核心组件——Skill 技能系统。在架构演进笔记中，Skill 是 Harness 能力层的关键组成、Loop 五原语之一；在记忆系统笔记中，“记忆与技能深度融合”被标记为演进趋势。Skill 是 Agent 从”能执行”到”能沉淀经验”再到”能自主进化”的中间枢纽——它把模型的一次性能力变成可复用、可组合、可治理的标准化资产。另外，你最近在用的 ima.copilot 的 skill 机制（比如刚创建的 daily-learning-note）本身就是 Agent Skill 的一个具体实例——今天从理论到实践全面拆解它。
核心要点
要点 1：Skill 不是 Prompt，是结构化行为设计——三重分立架构是核心骨架
多篇文章都强调同一个定义：Skill 不是一段 Prompt，而是围绕任务、工具、流程和输出边界的结构化行为设计。最小形态只需一个 SKILL.md 文件（YAML 元数据 + Markdown 指令），但背后有三重分立架构支撑：
| 分立层 | 角色 | 产出 | 核心问题 |
|---|---|---|---|
| 心智层（元） | 人或协调者 Agent | spec.md / YAML 元数据 | ”做什么” |
| 规范层（规） | SKILL.md 作为 SOP | SKILL.md 正文 | ”怎么做” |
| 底座层（源） | 执行资源与安全环境 | scripts/、templates/、Docker沙箱 | ”怎么安全地做” |
这个架构的设计哲学是声明式规范（Spec）作为唯一真理源——“外部规范架构接管内部概率输出”。人类锁定 Spec，AI 和 Skill 基于 Spec 实现，确保需求与实现精确对齐。代码被视为规范的”实现衍生品”，而非核心资产。
Skill 作为 Prompt 增强包的含义：它在基础 Prompt 之外，按需为 Agent 注入特定领域的知识、操作流程与输出约束。不是写死在系统提示词中，而是渐进式加载——仅在相关任务出现时才激活对应内容。目前已有 33+ 个 Agent 产品采纳此规范（Claude Code、Cursor 等）。
要点 2：三层懒加载是 Token 经济学的核心设计——上下文消耗降约 90%
所有文章都认同：大模型上下文窗口是稀缺资源，Skill 系统必须解决”海量能力库 vs 有限窗口”的矛盾。三层懒加载（渐进式披露）是公认的解决方案：
| 层级 | 加载时机 | 内容 | Token 消耗 |
|---|---|---|---|
| L1 元数据层 | 系统启动时 | name + description（每个~50-100 Token） | 20个Skill仅1000-2000 Token |
| L2 指令层 | 任务匹配时 | SKILL.md 正文（<5000 Token） | 按需加载，不常驻 |
| L3 资源层 | 执行引用时 | scripts/、references/、assets/ | 仅在执行步骤中按需引用 |
关键数据：相比单体式提示词（把所有能力写死在 system prompt），上下文使用量减少约 90%。Anthropic 的16个官方 Skill 中，参考文档渐进加载型（如 pptx、mcp-builder）通过三层信息模型（L0概览~30Token/L1 body~500-2000/L2文档~1000-5000）节省 Token 最高约 46%。
编排场景的三层懒加载扩展：多 Skill 编排时，L1 作为全局路由索引，L2 作为编排流程每步的 SOP，L3 作为步骤落地的工具箱。动态匹配 → 技能链组合 → 条件分支，全部在三层架构内完成。
要点 3：5 种执行模式与一个关键发现——Function Calling 不是必需的
源码拆解文章揭示了 Anthropic 16个官方 Skill 的 5 种执行模式，并得出一个颠覆直觉的结论：
| 模式 | 代表 Skill | 特点 | 适用场景 |
|---|---|---|---|
| 纯 Prompt 注入型 | frontend-design、brand-guidelines | 只有 SKILL.md，无脚本无依赖 | 教规范/风格 |
| 脚本执行型 | pdf、pptx、xlsx | SKILL.md当教程 + scripts/当工具箱 | 操作特定文件格式 |
| 库调用型 | slack-gif-creator | 自带 Python 库（core/），LLM现场写代码import | 灵活组合 API |
| 参考文档渐进加载型 | pptx、mcp-builder | SKILL.md做路由表，详细文档按需加载 | 知识量大需分文档 |
| 编排型 | skill-creator | 32KB超详细编排指南+子Agent+脚本 | 复杂多步骤工作流 |
颠覆性发现：所有16个 Skill 均未使用 Function Calling，全部通过 SKILL.md 文本 + skill_run 沙箱命令驱动。原因有三：
- LLM 本身就是最好的代码执行器——注册 function calling 限制灵活性，LLM 看示例后能自己写代码，完成技能作者未预想的操作
- skill_run 是万能兜底——任何语言/命令只要能在 shell 跑就能执行；Token 经济上看，1个 skill_run Schema约20 Token vs 8个独立 function calling 约1600-4000 Token，10轮对话差 1.6万-4万 Token
- Tools: 价值场景窄——只有调用不能靠代码/shell完成的操作（内部API、数据库等）才需要
结论公式：Skill 的执行力 = SKILL.md body 质量 × (Agent 基础工具 + skill_run 沙箱能力)。Function Calling 只是可省略的”可选配件”。
要点 4：五层纵深防御 + 七阶段闭环——Skill 不是”写完就跑”，而是全生命周期治理
Skill 的工程化不只是写好 SKILL.md，而是需要从诞生到退役的完整治理体系：
五层协同纵深防御：
| 层级 | 治理内容 |
|---|---|
| 规范/设计层 | 安全基线”宪法”（constitution.md），安全左移 |
| 元数据/契约层 | YAML声明最小权限集（allowed-tools）、风险等级 |
| 指令/执行层 | 流程嵌动态权限校验、风控链、强制人工审批断点（HITL） |
| 资源/运行时层 | Docker”每任务一容器”沙箱隔离、临时凭证注入 |
| 平台/治理层 | 企业级资产中心统一纳管、RBAC集成、集中审计 |
七阶段闭环管理：
- 规划与定义 → 2. 设计与开发 → 3. 测试与验证 → 4. 发布与上架 → 5. 发现与部署 → 6. 运行监控与治理 → 7. 迭代演进与下线
每个阶段之间有质量门禁：开发态→可发现态需通过所有测试+SBOM安全审查；可发现态→部署态必须”版本锁定”（禁 latest）；运行态→迭代态需数据评估+灰度预案。
“人在回路”断点机制：编排引擎内置 HITL 断点。执行到预设高风险环节（删生产数据、合规审查、资金交易、合并主干），自动将状态置为 AWAITING_APPROVAL，只有指定权限的人类审批后才继续。
要点 5：Google 的 5 种设计模式 + Anthropic 的评估体系——Skill 开发有成熟方法论
Google ADK 的 5 种可组合设计模式：
| 模式 | 核心思路 | 示例 |
|---|---|---|
| Tool Wrapper | 给 Agent 装”技能包”，需要时加载领域知识 | FastAPI规范 Skill |
| Generator | 模板+风格指南强制一致输出，主动提问补信息 | 报告生成 Skill |
| Reviewer | 分离”查什么”和”怎么查”，按清单打分解释WHY | 代码审查 Skill |
| Inversion | Agent 先采访用户弄清需求再动手 | 项目规划 Skill |
| Pipeline | 多步骤带质检关卡，不通过不向下 | 调研→起草→整合→交付 |
模式可组合：Pipeline+Reviewer（带质检的流水线）、Generator+Inversion（先问清楚再生成）。
Anthropic Skill-Creator 的评估体系——像做机器学习一样做 Prompt Engineering：
- 三个专业化子 Agent：Grader（评估断言通过与否+自我批评断言质量）、Comparator（双盲比较 A/B 输出）、Analyzer（揭盲分析胜负原因）
- 7种 JSON Schema 贯通数据流（evals→timing→metrics→grading→benchmark→comparison→analysis→history）
- TDD 循环（RED-GREEN-REFACTOR）：先不带 Skill 跑压力场景记录违规，再写最小 Skill，最后堵新借口保持合规
四类 Skill 的差异化测试策略：
- 纪律执行型 → 最严测试（最大压力下仍守规）
- 技术指导型 → 应用场景正确性
- 思维模式型 → 判断何时用何时不用的准确性
- 参考资料型 → 检索发现性与覆盖度
要点 6：Skill 正在从静态资产走向可进化生态——记忆融合、自学习、联邦网络
多篇文章都指向同一个趋势：Skill 不再是写完就锁定的静态资产，而是有内生进化机制的”活知识”。
自学习机制：失败驱动为核心触发。框架如 EXIF（探索者-执行者）、Memento-Skills（Read→Execute→Reflect→Write，性能提升116%）、Hermes（学习-固化-复用）。技能文档外化为”外部可训练状态”，能力与模型解耦——Skill 进化不需要重新训练模型。
记忆与技能深度融合：记忆演进为程序性记忆库，沉淀经验实现跨任务迁移与个性化自适应。这正是昨天记忆系统笔记中提到的趋势——今天从 Skill 视角看到了具体落地方式。
多 Agent 协作架构的量化成效：跨行业规模化落地后，错误率降低 65%、任务执行速度提升 40%、综合成本降低 25%。支撑路径包括”MCP协议+代码执行”范式（Token开销降超98%）、技能按需加载（基础上下文降约90%）、模型路由与语义缓存（降本30-50%）。
未来方向：
- SkillOS（技能操作系统）：自主管理技能生命周期
- 联邦技能网络：跨组织安全共享协同，降重复建设
- 自适应编排：编排器具元推理与动态规划，自主重组任务、动态生成临时技能
- 从”技能工程”到”经验蒸馏”：从数字足迹提取技能
分歧与讨论
- Function Calling 是否必需？ Anthropic 16个官方 Skill 全部不用 Function Calling，只用 SKILL.md + skill_run。但这可能是因为这些 Skill 都是可以靠代码/shell 完成的操作型任务。对于需要调用内部API、数据库等不能用代码完成的场景，Function Calling 仍然不可替代。结论：不是”Function Calling 没用”，而是”大多数 Skill 不需要它，只在特定场景才用”。
- 单一职责 vs 复合编排：单一职责原则要求每个 Skill 只做一件事，但编排型 Skill（如 skill-creator）本身就是多步骤工作流。这两者如何平衡？答案可能是：单个 Skill 保持单一职责，复杂流程通过多 Skill 组合编排实现——而不是让一个 Skill 包办一切。
- Spec 作为唯一真理源 vs 实际执行中的灵活性：声明式规范要求人类锁定 Spec 后 AI 基于其实现，但实际执行中 Agent 可能发现 Spec 没覆盖的边界情况。Hermes 的”LLM审判官”机制允许 Agent 自主生成和修改 Skill，这与 Spec-First 原则存在张力。可能的调和方式是：Spec 定义”做什么”，但允许 Agent 在边界情况下自主调整”怎么做”——只要最终结果符合验收标准。
- Skill 生命周期治理的成本：七阶段闭环+五层纵深防御听起来很完善，但对小团队和早期项目，这个治理体系可能过于沉重。四阶段渐进式实施路径建议：先做1-2个高频场景试点，再逐步建设治理体系——治理是规模化后才需要的，早期先把 Skill 跑起来更重要。
与已学内容的联系
07-23：Agent 架构演进
- Skill 属于 Harness 能力层 → Loop 的五原语之一 → Agent OS 的组件
- 架构演进中”验证比生成重要”的结论，在 Skill 的五层纵深防御和 HITL 断点机制中得到了具体落地
- “智能下沉到模型、确定性留给框架”的设计哲学，在 skill_run 沙箱执行中得到了体现——模型写代码，框架提供确定性执行环境
07-24：Agent 记忆系统
- 记忆系统笔记提到”记忆与技能深度融合”是演进趋势 → 今天从 Skill 视角看到了具体实现：技能文档外化为”外部可训练状态”，记忆演进为程序性记忆库
- 记忆系统的”写入门控”（决定什么值得存），在 Skill 的”写入过滤机制”中有对应设计——不是所有信息都值得写进记忆，也不是所有能力都值得封装成 Skill
- Skill 的三层懒加载和记忆系统的三层架构（工作/短期/长期）有结构上的相似性——都是解决”海量信息 vs 有限资源”矛盾的分级管理方案
实际使用场景：ima.copilot 的 daily-learning-note Skill
- 你正在用的这个 Skill 本身就是 Agent Skill 的一个实例
- SKILL.md 定义了5个阶段的 SOP（Phase 1-5）、关键约束、故障处理
- 触发方式完全依赖 description 字段的语义匹配（“今天的学习笔记”、“每日学习”等）
- 没有使用 Function Calling，完全靠 SKILL.md 指令驱动
💡 思考题
- 你正在用的
daily-learning-noteSkill 属于5种执行模式中的哪一种？如果要让它变得更强大（比如自动搜索+自动写笔记+自动推送），应该往哪种模式演进？需要加什么组件？ ——这道题帮你把今天的理论映射到正在用的实际产品上。 - Anthropic 的发现”Function Calling 不是必需的”在你的工作场景中是否成立？你有多少任务是可以靠代码/shell完成的，有多少必须调用内部API或第三方服务？这个比例决定了你的 Skill 系统是否需要 Function Calling 层。 ——这道题帮你判断自己应该采用哪种 Skill 执行模式。
🎯 行动项
- 拆解一个你正在使用的 Skill：读一下
/sandbox/workspace/skills/daily-learning-note/SKILL.md的完整内容，对照今天的5种执行模式、三层懒加载、质量门禁，标注它目前属于哪一层、缺什么、可以怎么进化。这个练习会让今天的理论变成具体的改进方案。 - 尝试写一个最小 Skill：选一个你日常重复做的任务（比如”每天早上整理待办事项”），写一个只有 SKILL.md 的纯 Prompt 注入型 Skill，跑起来验证效果。先跑通再迭代——这是 Skill 开发的正确顺序。
参考文章
- [技能生成与管理的技术架构、编排机制、权限治理及全生命周期流程解析]（note_8063fdd1b44b6b1cc34019dc46a067c0_74472693264845147307200439519008，提供了三重分立架构、三层懒加载扩展、五层纵深防御和七阶段闭环的完整框架）
- [Skill工程方法论：从规范驱动到资产封装的企业级AI落地指南]（note_8063fdd1b44b6b1cc34019dc46a067c0_74438053556704087307200439519008，提供了声明式规范、Spec-First原则和四阶段渐进式实施路径）
- [Agent Skill规范、构建与设计模式]（wechatarticle_8063fdd1b44b6b1cc34019dc46a067c0_49650c6b0de0f7e8de9cdb799fe010557307200439519008，提供了Google5种设计模式、Skill-Creator评估体系和TDD循环）
- [兄弟！你真的懂 Skill 吗？]（wechatarticle_8063fdd1b44b6b1cc34019dc46a067c0_5948286acfc6f1ab86db7272b9372c577307200439519008，提供了Anthropic16个官方Skill的源码拆解、5种执行模式、Function Calling非必需的发现）
- [Agent Skills的系统化应用、管理与进化方法论]（note_8063fdd1b44b6b1cc34019dc46a067c0_74663622344997097307200439519008，提供了三位一体方法论、量化成效、自学习机制和未来演进方向）
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！