从 Prompt 工程到 Skill 工程一文讲透 Agent Skill 的原理与实践参考来源阿里云开发者「Harness 工程之道Skill 原理与最佳实践」大模型每轮对话都是失忆的必须从零构建上下文。传统 Prompt 工程将所有领域知识塞进提示词项目越复杂、Prompt 越臃肿关键信息被稀释、复用性极低。Agent Skill 以模块化、可复用的文件夹形式封装领域知识通过渐进性披露按需加载用最小上下文成本换取最大知识覆盖。本文从原理出发结合完整实操示例讲清 Skill 的结构、触发机制与工程化最佳实践。文章目录从 Prompt 工程到 Skill 工程一文讲透 Agent Skill 的原理与实践一、为什么需要 Skill—— 从全量灌输到按需激活Skill 与 System Prompt 的分工二、核心设计理念渐进性披露三、Skill 的结构规范3.1 SKILL.md唯一入口与触发器3.2 SKILL.md 正文路由器而非知识仓库四、触发机制description 是灵魂4.1 description 书写公式4.2 作用域与优先级五、实操从零构建一个订单查询 SkillStep 1初始化目录Step 2编写 SKILL.mdStep 3编写子模块Step 4打包验证Step 5版本管理六、性能对比有 Skill vs 无 Skill七、工程化最佳实践7.1 工具隔离与权限最小化7.2 脚本化确定性计算 —— 突破 LLM 能力边界7.3 参数传递快照机制7.4 测试维度7.5 适用边界八、总结一、为什么需要 Skill—— 从全量灌输到按需激活大模型会话的核心矛盾在于每轮对话都是独立的模型没有持久记忆。CLAUDE.md 等方案将团队技术选型、编码规范固化为 Agent 可读的配置文档每次会话自动加载让 Agent 直接进入高效协作模式。但随着项目规模增长这种全量灌输的模式暴露出三个核心痛点上下文膨胀项目越复杂Prompt 越长。上下文窗口被无关信息占满模型的注意力被稀释——真正关键的信息反而被淹没在大量背景文本中。耦合严重领域知识与具体项目深度绑定。同样是订单查询逻辑在电商项目写一遍换到 ERP 项目又得从头再来复用性几乎为零。维护成本高单文件扁平的 Prompt 随着规则增多增删改查都需要修改一整块文本稍有不慎就引入冲突。Agent Skill 的方案是将领域知识和工作流封装为可移植、可版本控制的文件夹Agent 在需要时才加载——按需投放知识而非全量灌输。Skill 是给 AI Agent 的「入职指南」——新员工不需要第一天背下整本手册遇到具体任务时查阅对应章节即可。Skill 与 System Prompt 的分工维度System PromptSkill定位项目级全局规则、编码规范特定领域能力封装加载策略会话启动时全量加载渐进式按需加载生效范围当前项目可跨项目、跨会话上下文成本恒定占用仅在命中时加载未命中零成本结构化单文件扁平组织多文件模块化支持脚本和资源简单记法System Prompt 是这个项目的规矩Skill 是一种可复用的能力。二、核心设计理念渐进性披露Skill 最核心的设计哲学是渐进性披露Progressive Disclosure——只在需要时加载需要的知识。这与传统全量加载 System Prompt的思路形成鲜明对比。阶段触发时机加载内容上下文成本Discovery发现会话启动时每个 Skill 的namedescription~50 tokens / SkillActivation激活语义匹配命中完整SKILL.md路由表 全局规则~500 tokensExecution执行按路由分发当前步骤所需的子模块文件按需精准加载经济学优势假设有 20 个 Skill每个完整加载需 3000 tokens。全量加载需 60,000 tokens而渐进性披露在 Discovery 阶段仅需 1,000 tokens20 × 50。大部分请求中真正被激活的 Skill 仅 1-2 个——上下文成本降低一个数量级。更关键的是更小的上下文意味着更少的噪音模型的注意力更集中决策精准度反而更高。三、Skill 的结构规范一个 Skill 就是一个包含SKILL.md的文件夹my-skill/ # 必需skill 名称小写字母数字连字符 ├── SKILL.md # 必需入口文件全大写文件名 ├── scripts/ # 可选可执行脚本 ├── references/ # 可选参考文档 ├── assets/ # 可选模板、资源文件 └── ... # 任意额外文件这种格式已被 Claude Code、Cursor、GitHub Copilot、Gemini CLI 等 40 Agent 产品采纳形成了事实上的开放标准详见 AgentSkills.io。3.1 SKILL.md唯一入口与触发器SKILL.md分为两部分YAML frontmatter元信息和正文指令路由表 规则。---name:order-query-skilldescription:为用户提供订单查询与操作能力支持按订单号查询、 按用户ID查询历史订单、订单状态追踪等。 触发词查订单、订单状态、历史订单、物流查询。argument-hint:[订单号] [查询类型]disable-model-invocation:falseuser-invocable:trueallowed-tools:[Read,Grep,Glob,Bash(sql:read)]model:qwen-plusversion:1.0.0---核心 frontmatter 字段说明字段必填作用name是Skill 唯一标识最长 64 字符小写字母数字连字符description是触发机制核心写清做什么 何时触发最长 1024 字符allowed-tools否工具白名单精确控制可调用工具范围disable-model-invocation否设为true时禁止模型自动调用仅允许用户手动触发user-invocable否设为false时用户不能直接调用仅模型可自动触发version否语义化版本号方便团队协作和迭代追踪3.2 SKILL.md 正文路由器而非知识仓库正文应控制在500 行以内约 2000-3000 tokens核心职责是路由分发## 意图路由表 | 用户意图 | 路由模块 | 加载文件 | |----------|----------|----------| | 查订单 | query | modules/query/query.md | | 查物流 | logistics | modules/logistics/logistics.md | | 退款操作 | refund | modules/refund/refund.md | ## 全局安全红线 1. 禁止直接操作数据库写操作 2. 禁止编造订单数据 3. 退款操作需二次确认拆分时机当单个文件超过 300 行或某个 Step 的规则超过 100 行就是拆分信号。越频繁用到的知识离入口越近越偶尔查阅的知识越往深处放。四、触发机制description 是灵魂Skill 支持两种触发方式互补使用自动触发Agent 将用户意图与各 Skill 的description做语义匹配命中后自动加载。用户无感如同老员工听到需求就翻出了对应的 SOP。手动触发用户通过斜杠命令如/order-query显式调用给高级用户精确控制权。4.1 description 书写公式公式功能定义 触发场景 核心能力。写好 description 需要遵循以下原则同时回答 WHAT 和 WHEN不能只说处理订单要明确写出这个 Skill 做什么、在什么场景下该被调用。枚举具体触发词Agent 做语义匹配时关键词越具体命中率越高。显式列出用户可能说的所有表达——不只是术语还包括口语化说法。“查订单”、“订单在哪”、“看看买了什么”、“物流到哪了”——这些都要写进去。使用第三人称description 会被注入系统提示词应写成客观描述。“提供订单查询能力”而非我可以帮你查订单。划定排除边界明确写出不适用场景降低误触发概率。对比示例❌ 不好的写法✅ 好的写法“帮助用户处理订单”“提供订单查询、物流追踪与退款操作。当用户提到查订单、物流状态、申请退款、退货处理时触发。不适用商品上下架、价格修改等运营操作。”4.2 作用域与优先级当多个 Skill 的 description 同时匹配用户输入时优先级规则为全局配置 用户配置 项目配置 Plugin 内置这一层级设计确保了企业级安全策略始终优先于个人偏好。五、实操从零构建一个订单查询 Skill以下以阿里云百炼平台 通义千问模型为例演示完整构建流程。Step 1初始化目录在 AI 对话中直接告诉 Agent“帮我用 skill-creator 生成一个名为 order-query 的 Skill”AI 自动运行初始化脚本生成标准目录order-query/ ├── SKILL.md ├── scripts/ └── references/Step 2编写 SKILL.md---name:order-querydescription:提供订单查询、物流追踪与退款操作能力。 当用户提到查订单、订单状态、物流、快递、 退款、退货、买了什么、历史订单时触发。 不适用商品上下架、价格修改等运营操作。argument-hint:[订单号或查询意图]version:1.0.0allowed-tools:[Read,sql:read]---正文路由表部分# 意图路由表 | 场景示例 | 路由模块 | 加载文件 | |----------|----------|----------| | 查订单、订单状态、我的订单 | query | modules/query/query.md | | 物流、快递到哪了、发货了吗 | logistics | modules/logistics/logistics.md | | 退款、退货、申请退款 | refund | modules/refund/refund.md | # 全局规则 1. 所有查询默认查询当前登录用户 2. 涉及金额的操作必须二次确认 3. 禁止直接执行 DELETE / UPDATE 等写操作 4. 订单数据以系统实际数据为准禁止推测Step 3编写子模块以modules/query/query.md为例# 订单查询模块 ## 执行流程 1. 确认查询条件订单号 / 用户ID / 时间范围 2. 调用 order_query_api(query_params) 查询 3. 格式化结果返回给用户 ## 查询模板 ### 按订单号查询 SELECT * FROM orders WHERE order_id {order_id}; ### 按用户ID查询 SELECT * FROM orders WHERE user_id {user_id} ORDER BY created_at DESC LIMIT 20; ### 按时间范围查询 SELECT * FROM orders WHERE user_id {user_id} AND created_at BETWEEN {start_date} AND {end_date} ORDER BY created_at DESC;Step 4打包验证skill-creator validate order-query验证项包括frontmatter 完整性、name/description 是否存在、目录结构合法性。Step 5版本管理cdorder-querygitinitgitadd.gitcommit-mfeat: init order-query skill整个流程总结AI 对话描述意图 → 初始化目录 → 编写 SKILL.md 子模块 → 打包验证 → Git 提交从头到尾不需要手动执行任何命令——你只负责描述意图AI 负责执行。这也是 Agent Skill 的设计初衷让 AI 成为真正的协作伙伴。六、性能对比有 Skill vs 无 Skill为直观感受 Skill 对上下文效率的影响以查询最近 5 笔订单的物流状态为测试任务对比两种配置方式指标无 Skill全量 Prompt有 Skill渐进加载系统 Prompt 大小~8000 tokens~1500 tokens首次响应 Token 消耗估算~9000~2000任务完成率10 次70%7/1095%响应延迟估算3.2s1.1s误触发率—~3%测试说明无 Skill 组使用完整 System Prompt 包含 8 个领域的全部规则订单、库存、支付、用户、营销、物流、售后、报表有 Skill 组仅触发 order-query Skill。Token 消耗和延迟数据为基于典型场景的参考估计值实际值取决于模型和平台。有 Skill 的方案在首次响应 token 消耗上仅为无 Skill 方案的约 22%任务完成率反而从 70% 提升到 95%——更小的上下文意味着更少的噪音模型聚焦准确度更高。七、工程化最佳实践7.1 工具隔离与权限最小化当 Skill 涉及多个模块时必须实施模块级工具隔离——每个模块只能调用其白名单中的接口。# SKILL.md 全局级allowed-tools:[Read,sql:read]# modules/refund/refund.md 中显式声明allowed-tools:[Read,sql:read,sql:update]# 退款模块需更新订单状态设计原则白名单制每个模块的 tools.md 明确列出可用接口白名单外一律禁止危险接口显式禁用万能工具如直接 HTTP 调用全局禁止工具隔离不同模块使用不同接口集合防止误调用7.2 脚本化确定性计算 —— 突破 LLM 能力边界凡是 LLM 有概率出错、但脚本能 100% 确定性完成的操作都应该封装成脚本场景纯指令的局限脚本的优势配置读写LLM 可能输出格式错误的 JSON脚本保证格式原子写入环境检测LLM 无法可靠检测系统状态脚本直接查询结构化返回日志采集LLM 不应直接处理网络请求脚本封装 HTTP 调用异常自处理复杂计算LLM 算术不可靠脚本精确计算脚本设计四原则自愈性内部处理所有异常始终正常退出绝不阻断 Skill 主流程结构化输出统一输出 JSON方便 Agent 解析和流转幂等性多次执行结果一致预检脚本只追加缺失项安全边界只操作指定文件不触碰其他系统资源7.3 参数传递快照机制跨阶段的参数传递建议采用快照Snapshot机制{currentOrderId:ORD20260706-001,queryType:logistics,snapshotVersion:2,lastUsed:2026-07-06}每个阶段将产出写入快照下一阶段从快照读取。阶段门卡检查参数完整性确保参数不丢失、可追溯、可校验。7.4 测试维度Skill 的测试不能只跑 Happy Path测试类型方法重点验证触发测试准备 10 个自然语言变体触发 Skill是否全部正确激活不相关输入是否误触发功能走查用自然语言驱动完整流程路由分发准确性、红线规则遵守、异常场景熔断性能对比同一任务分别用无 Skill和有 Skill各跑 5 次Token 用量和完成质量差异高效迭代的关键建立日志采集机制记录每次 Skill 执行的触发匹配、路由分发和执行结果便于持续优化触发精准度和执行质量。7.5 适用边界Skill 并非万能解药以下场景需要权衡极小规模项目3-5 条规则直接用 System Prompt 即可Skill 的目录开销反而多余跨 Agent 互操作Skill 解决的是教 Agent 怎么做若需要让 Agent 调用外部服务应结合 MCPModel Context Protocol实时数据依赖强的场景Skill 适合封装工作流知识不适合替代实时数据管道八、总结Agent Skill 的核心价值不在于多了一种配置方式而在于它重新定义了 AI Agent 获取知识的方式——从 “被动灌输” 到 “按需激活”。渐进性披露让每个 Skill 在未被触发时几乎零成本在被激活后精准高效地提供专业指导。回顾本文核心要点渐进性披露是 Skill 的灵魂Discovery → Activation → Execution 三阶段按需加载。SKILL.md 路由器控制在 500 行以内业务细节下沉到子模块。description 决定触发命中率枚举触发词、明确排除边界、使用第三人称。工程化实践工具隔离、脚本化确定性计算、快照参数传递、系统化测试。对于正在构建 AI Agent 系统的团队建议从最小的 Skill 开始——选一个高频场景按本文流程跑通感受渐进性披露带来的上下文效率提升再逐步扩展 Skill 体系。本文基于阿里云开发者「Harness 工程之道Skill 原理与最佳实践」的个人理解与实践总结。参考资源Agent Skills 官方规范Claude Code 官方文档阿里云百炼平台感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
一文讲透 Agent Skill 的原理与实践
发布时间：2026/7/6 23:31:26
从 Prompt 工程到 Skill 工程一文讲透 Agent Skill 的原理与实践参考来源阿里云开发者「Harness 工程之道Skill 原理与最佳实践」大模型每轮对话都是失忆的必须从零构建上下文。传统 Prompt 工程将所有领域知识塞进提示词项目越复杂、Prompt 越臃肿关键信息被稀释、复用性极低。Agent Skill 以模块化、可复用的文件夹形式封装领域知识通过渐进性披露按需加载用最小上下文成本换取最大知识覆盖。本文从原理出发结合完整实操示例讲清 Skill 的结构、触发机制与工程化最佳实践。文章目录从 Prompt 工程到 Skill 工程一文讲透 Agent Skill 的原理与实践一、为什么需要 Skill—— 从全量灌输到按需激活Skill 与 System Prompt 的分工二、核心设计理念渐进性披露三、Skill 的结构规范3.1 SKILL.md唯一入口与触发器3.2 SKILL.md 正文路由器而非知识仓库四、触发机制description 是灵魂4.1 description 书写公式4.2 作用域与优先级五、实操从零构建一个订单查询 SkillStep 1初始化目录Step 2编写 SKILL.mdStep 3编写子模块Step 4打包验证Step 5版本管理六、性能对比有 Skill vs 无 Skill七、工程化最佳实践7.1 工具隔离与权限最小化7.2 脚本化确定性计算 —— 突破 LLM 能力边界7.3 参数传递快照机制7.4 测试维度7.5 适用边界八、总结一、为什么需要 Skill—— 从全量灌输到按需激活大模型会话的核心矛盾在于每轮对话都是独立的模型没有持久记忆。CLAUDE.md 等方案将团队技术选型、编码规范固化为 Agent 可读的配置文档每次会话自动加载让 Agent 直接进入高效协作模式。但随着项目规模增长这种全量灌输的模式暴露出三个核心痛点上下文膨胀项目越复杂Prompt 越长。上下文窗口被无关信息占满模型的注意力被稀释——真正关键的信息反而被淹没在大量背景文本中。耦合严重领域知识与具体项目深度绑定。同样是订单查询逻辑在电商项目写一遍换到 ERP 项目又得从头再来复用性几乎为零。维护成本高单文件扁平的 Prompt 随着规则增多增删改查都需要修改一整块文本稍有不慎就引入冲突。Agent Skill 的方案是将领域知识和工作流封装为可移植、可版本控制的文件夹Agent 在需要时才加载——按需投放知识而非全量灌输。Skill 是给 AI Agent 的「入职指南」——新员工不需要第一天背下整本手册遇到具体任务时查阅对应章节即可。Skill 与 System Prompt 的分工维度System PromptSkill定位项目级全局规则、编码规范特定领域能力封装加载策略会话启动时全量加载渐进式按需加载生效范围当前项目可跨项目、跨会话上下文成本恒定占用仅在命中时加载未命中零成本结构化单文件扁平组织多文件模块化支持脚本和资源简单记法System Prompt 是这个项目的规矩Skill 是一种可复用的能力。二、核心设计理念渐进性披露Skill 最核心的设计哲学是渐进性披露Progressive Disclosure——只在需要时加载需要的知识。这与传统全量加载 System Prompt的思路形成鲜明对比。阶段触发时机加载内容上下文成本Discovery发现会话启动时每个 Skill 的namedescription~50 tokens / SkillActivation激活语义匹配命中完整SKILL.md路由表 全局规则~500 tokensExecution执行按路由分发当前步骤所需的子模块文件按需精准加载经济学优势假设有 20 个 Skill每个完整加载需 3000 tokens。全量加载需 60,000 tokens而渐进性披露在 Discovery 阶段仅需 1,000 tokens20 × 50。大部分请求中真正被激活的 Skill 仅 1-2 个——上下文成本降低一个数量级。更关键的是更小的上下文意味着更少的噪音模型的注意力更集中决策精准度反而更高。三、Skill 的结构规范一个 Skill 就是一个包含SKILL.md的文件夹my-skill/ # 必需skill 名称小写字母数字连字符 ├── SKILL.md # 必需入口文件全大写文件名 ├── scripts/ # 可选可执行脚本 ├── references/ # 可选参考文档 ├── assets/ # 可选模板、资源文件 └── ... # 任意额外文件这种格式已被 Claude Code、Cursor、GitHub Copilot、Gemini CLI 等 40 Agent 产品采纳形成了事实上的开放标准详见 AgentSkills.io。3.1 SKILL.md唯一入口与触发器SKILL.md分为两部分YAML frontmatter元信息和正文指令路由表 规则。---name:order-query-skilldescription:为用户提供订单查询与操作能力支持按订单号查询、 按用户ID查询历史订单、订单状态追踪等。 触发词查订单、订单状态、历史订单、物流查询。argument-hint:[订单号] [查询类型]disable-model-invocation:falseuser-invocable:trueallowed-tools:[Read,Grep,Glob,Bash(sql:read)]model:qwen-plusversion:1.0.0---核心 frontmatter 字段说明字段必填作用name是Skill 唯一标识最长 64 字符小写字母数字连字符description是触发机制核心写清做什么 何时触发最长 1024 字符allowed-tools否工具白名单精确控制可调用工具范围disable-model-invocation否设为true时禁止模型自动调用仅允许用户手动触发user-invocable否设为false时用户不能直接调用仅模型可自动触发version否语义化版本号方便团队协作和迭代追踪3.2 SKILL.md 正文路由器而非知识仓库正文应控制在500 行以内约 2000-3000 tokens核心职责是路由分发## 意图路由表 | 用户意图 | 路由模块 | 加载文件 | |----------|----------|----------| | 查订单 | query | modules/query/query.md | | 查物流 | logistics | modules/logistics/logistics.md | | 退款操作 | refund | modules/refund/refund.md | ## 全局安全红线 1. 禁止直接操作数据库写操作 2. 禁止编造订单数据 3. 退款操作需二次确认拆分时机当单个文件超过 300 行或某个 Step 的规则超过 100 行就是拆分信号。越频繁用到的知识离入口越近越偶尔查阅的知识越往深处放。四、触发机制description 是灵魂Skill 支持两种触发方式互补使用自动触发Agent 将用户意图与各 Skill 的description做语义匹配命中后自动加载。用户无感如同老员工听到需求就翻出了对应的 SOP。手动触发用户通过斜杠命令如/order-query显式调用给高级用户精确控制权。4.1 description 书写公式公式功能定义 触发场景 核心能力。写好 description 需要遵循以下原则同时回答 WHAT 和 WHEN不能只说处理订单要明确写出这个 Skill 做什么、在什么场景下该被调用。枚举具体触发词Agent 做语义匹配时关键词越具体命中率越高。显式列出用户可能说的所有表达——不只是术语还包括口语化说法。“查订单”、“订单在哪”、“看看买了什么”、“物流到哪了”——这些都要写进去。使用第三人称description 会被注入系统提示词应写成客观描述。“提供订单查询能力”而非我可以帮你查订单。划定排除边界明确写出不适用场景降低误触发概率。对比示例❌ 不好的写法✅ 好的写法“帮助用户处理订单”“提供订单查询、物流追踪与退款操作。当用户提到查订单、物流状态、申请退款、退货处理时触发。不适用商品上下架、价格修改等运营操作。”4.2 作用域与优先级当多个 Skill 的 description 同时匹配用户输入时优先级规则为全局配置 用户配置 项目配置 Plugin 内置这一层级设计确保了企业级安全策略始终优先于个人偏好。五、实操从零构建一个订单查询 Skill以下以阿里云百炼平台 通义千问模型为例演示完整构建流程。Step 1初始化目录在 AI 对话中直接告诉 Agent“帮我用 skill-creator 生成一个名为 order-query 的 Skill”AI 自动运行初始化脚本生成标准目录order-query/ ├── SKILL.md ├── scripts/ └── references/Step 2编写 SKILL.md---name:order-querydescription:提供订单查询、物流追踪与退款操作能力。 当用户提到查订单、订单状态、物流、快递、 退款、退货、买了什么、历史订单时触发。 不适用商品上下架、价格修改等运营操作。argument-hint:[订单号或查询意图]version:1.0.0allowed-tools:[Read,sql:read]---正文路由表部分# 意图路由表 | 场景示例 | 路由模块 | 加载文件 | |----------|----------|----------| | 查订单、订单状态、我的订单 | query | modules/query/query.md | | 物流、快递到哪了、发货了吗 | logistics | modules/logistics/logistics.md | | 退款、退货、申请退款 | refund | modules/refund/refund.md | # 全局规则 1. 所有查询默认查询当前登录用户 2. 涉及金额的操作必须二次确认 3. 禁止直接执行 DELETE / UPDATE 等写操作 4. 订单数据以系统实际数据为准禁止推测Step 3编写子模块以modules/query/query.md为例# 订单查询模块 ## 执行流程 1. 确认查询条件订单号 / 用户ID / 时间范围 2. 调用 order_query_api(query_params) 查询 3. 格式化结果返回给用户 ## 查询模板 ### 按订单号查询 SELECT * FROM orders WHERE order_id {order_id}; ### 按用户ID查询 SELECT * FROM orders WHERE user_id {user_id} ORDER BY created_at DESC LIMIT 20; ### 按时间范围查询 SELECT * FROM orders WHERE user_id {user_id} AND created_at BETWEEN {start_date} AND {end_date} ORDER BY created_at DESC;Step 4打包验证skill-creator validate order-query验证项包括frontmatter 完整性、name/description 是否存在、目录结构合法性。Step 5版本管理cdorder-querygitinitgitadd.gitcommit-mfeat: init order-query skill整个流程总结AI 对话描述意图 → 初始化目录 → 编写 SKILL.md 子模块 → 打包验证 → Git 提交从头到尾不需要手动执行任何命令——你只负责描述意图AI 负责执行。这也是 Agent Skill 的设计初衷让 AI 成为真正的协作伙伴。六、性能对比有 Skill vs 无 Skill为直观感受 Skill 对上下文效率的影响以查询最近 5 笔订单的物流状态为测试任务对比两种配置方式指标无 Skill全量 Prompt有 Skill渐进加载系统 Prompt 大小~8000 tokens~1500 tokens首次响应 Token 消耗估算~9000~2000任务完成率10 次70%7/1095%响应延迟估算3.2s1.1s误触发率—~3%测试说明无 Skill 组使用完整 System Prompt 包含 8 个领域的全部规则订单、库存、支付、用户、营销、物流、售后、报表有 Skill 组仅触发 order-query Skill。Token 消耗和延迟数据为基于典型场景的参考估计值实际值取决于模型和平台。有 Skill 的方案在首次响应 token 消耗上仅为无 Skill 方案的约 22%任务完成率反而从 70% 提升到 95%——更小的上下文意味着更少的噪音模型聚焦准确度更高。七、工程化最佳实践7.1 工具隔离与权限最小化当 Skill 涉及多个模块时必须实施模块级工具隔离——每个模块只能调用其白名单中的接口。# SKILL.md 全局级allowed-tools:[Read,sql:read]# modules/refund/refund.md 中显式声明allowed-tools:[Read,sql:read,sql:update]# 退款模块需更新订单状态设计原则白名单制每个模块的 tools.md 明确列出可用接口白名单外一律禁止危险接口显式禁用万能工具如直接 HTTP 调用全局禁止工具隔离不同模块使用不同接口集合防止误调用7.2 脚本化确定性计算 —— 突破 LLM 能力边界凡是 LLM 有概率出错、但脚本能 100% 确定性完成的操作都应该封装成脚本场景纯指令的局限脚本的优势配置读写LLM 可能输出格式错误的 JSON脚本保证格式原子写入环境检测LLM 无法可靠检测系统状态脚本直接查询结构化返回日志采集LLM 不应直接处理网络请求脚本封装 HTTP 调用异常自处理复杂计算LLM 算术不可靠脚本精确计算脚本设计四原则自愈性内部处理所有异常始终正常退出绝不阻断 Skill 主流程结构化输出统一输出 JSON方便 Agent 解析和流转幂等性多次执行结果一致预检脚本只追加缺失项安全边界只操作指定文件不触碰其他系统资源7.3 参数传递快照机制跨阶段的参数传递建议采用快照Snapshot机制{currentOrderId:ORD20260706-001,queryType:logistics,snapshotVersion:2,lastUsed:2026-07-06}每个阶段将产出写入快照下一阶段从快照读取。阶段门卡检查参数完整性确保参数不丢失、可追溯、可校验。7.4 测试维度Skill 的测试不能只跑 Happy Path测试类型方法重点验证触发测试准备 10 个自然语言变体触发 Skill是否全部正确激活不相关输入是否误触发功能走查用自然语言驱动完整流程路由分发准确性、红线规则遵守、异常场景熔断性能对比同一任务分别用无 Skill和有 Skill各跑 5 次Token 用量和完成质量差异高效迭代的关键建立日志采集机制记录每次 Skill 执行的触发匹配、路由分发和执行结果便于持续优化触发精准度和执行质量。7.5 适用边界Skill 并非万能解药以下场景需要权衡极小规模项目3-5 条规则直接用 System Prompt 即可Skill 的目录开销反而多余跨 Agent 互操作Skill 解决的是教 Agent 怎么做若需要让 Agent 调用外部服务应结合 MCPModel Context Protocol实时数据依赖强的场景Skill 适合封装工作流知识不适合替代实时数据管道八、总结Agent Skill 的核心价值不在于多了一种配置方式而在于它重新定义了 AI Agent 获取知识的方式——从 “被动灌输” 到 “按需激活”。渐进性披露让每个 Skill 在未被触发时几乎零成本在被激活后精准高效地提供专业指导。回顾本文核心要点渐进性披露是 Skill 的灵魂Discovery → Activation → Execution 三阶段按需加载。SKILL.md 路由器控制在 500 行以内业务细节下沉到子模块。description 决定触发命中率枚举触发词、明确排除边界、使用第三人称。工程化实践工具隔离、脚本化确定性计算、快照参数传递、系统化测试。对于正在构建 AI Agent 系统的团队建议从最小的 Skill 开始——选一个高频场景按本文流程跑通感受渐进性披露带来的上下文效率提升再逐步扩展 Skill 体系。本文基于阿里云开发者「Harness 工程之道Skill 原理与最佳实践」的个人理解与实践总结。参考资源Agent Skills 官方规范Claude Code 官方文档阿里云百炼平台感谢阅读记得点赞、关注、收藏欢迎各位评论区交流
 获取与实战)
