主流云厂商发布五种智能体技能设计模式

一、什么是智能体技能设计模式

2026年5月，主流云厂商在其官方文档中集中发布了一批智能体技能（Agent Skill）的组织范式，涵盖工具包装器、生成器等类型，并统一采用“渐进式知识加载”思路。其核心主张是：把领域知识以文件形式封装为技能，智能体在识别到相关意图后再按需读取相应内容，避免在每一轮对话中重复注入全部知识，从而大幅降低 Token 消耗。

那么，智能体技能设计模式到底是什么？

智能体技能（Skill）是一种以文件为载体的能力封装单元。它把某项任务所需的领域知识、操作规范和可执行资源组织为统一目录，并由智能体在识别到任务意图时按需加载、应用。通常包含三类内容：描述技能“能做什么、何时启用”的入口文件，存放规范、约定与最佳实践的参考知识，以及决定输出形式或执行动作的模板与脚本。

技能设计模式是对这类能力包的抽象与组织范式，回答三个问题：

• 知识放在哪一层：直接写入智能体指令，还是以参考文件形式按需加载；
• 何时、由谁使用：由模型理解应用、由脚本确定性执行，还是由校验环节把关；
• 以何种形式生效：约束知识、规定输出、编排流程、扩充知识来源，还是保障输出质量。

理解设计模式，关键在于抓住两点：

• 它是知识治理方法：各模式在“灵活理解”与“确定执行”之间选取不同的平衡点，没有普遍最优，只有与任务特性相匹配；
• 它依赖渐进式加载：各模式先共享同一套“按需读取知识”的底座，再以不同方式组织知识，共同目标是用最少的上下文完成最可靠的工作。

示意性目录结构（仅为通用示例）

my-skill/
├── SKILL.md             # 技能入口：名称、描述、加载指令
├── references/          # 参考知识：规范、约定、风格指南
├── assets/              # 输出模板
└── scripts/             # 确定性脚本（需要时使用）

二、为什么需要技能与设计模式：渐进式知识加载

1. 全量注入的困境

传统做法是把领域知识、编码规范和示例全部写进系统提示词或知识文档，每一轮对话都随请求重复发送，带来四个问题：

• Token 成本高：上下文越长，单次调用的费用越高，且会挤占任务推理所需的空间；
• 注意力被稀释：无关规则与当前任务争夺模型的注意力，反而容易遗漏关键约束；
• 知识难以维护：所有知识堆叠在单份长文档中，局部修订影响全局，也难做版本追踪；
• 技能难以复用：规范、流程与模型指令耦合在一起，换一个任务就要重写一遍。

2. 渐进式知识加载的三层机制

渐进式知识加载（Progressive Knowledge Loading）的核心思想是“按需读取、逐层深入”，通常分为三层：

1. 发现层：智能体启动时只加载各技能的名称与简短描述，类似一份轻量级“技能目录”。每个技能仅占用很少的 Token，却能覆盖大量能力。
2. 匹配层：智能体依据用户意图，从目录中匹配最相关的技能并读取其入口指令，明确本任务应遵循的规则与可引用的资源。
3. 展开层：入口指令指引智能体按需打开参考文件，必要时调用附带脚本。与该任务无关的知识始终不进入上下文。

3. 动态发现与显式调用

渐进式加载主要有两种触发方式，二者可以并存：

• 动态发现：由模型根据任务语义自主选择，使用门槛低，但依赖描述质量；
• 显式调用：由开发者、宿主应用或上层编排流程指定启用哪些技能，触发更确定，适合流程固定的生产任务。

技能之间还能逐级调用。例如，一个“接口开发”技能可以在其知识中引用“编码规范”技能：智能体先激活前者，再按其指引加载后者。上下文始终从入口逐层展开，而不是一次性全量展开。

4. 分层带来的收益

维度	全量注入	渐进式知识加载
Token 开销	每轮重复发送全部知识	仅加载相关技能及文件
上下文质量	无关规则多，注意力易分散	只呈现当前任务所需规则
知识维护	集中于单份长文档，改动影响面大	按文件、按技能独立维护
复用能力	与模型指令耦合，难以迁移	与模型解耦，可跨任务、跨平台复用
扩展性	新增领域即膨胀上下文	新增技能基本不增加基线开销

三、技能的组成要素与运行机制

无论采用哪种设计模式，一个规范的技能通常包含以下部分：

• 入口文件：以结构化元数据声明名称与描述，正文给出加载指令与使用规则。其中 description 字段相当于技能的“搜索索引”，应写清能力边界与典型触发场景。
• 参考知识：规范、约定、领域术语、常见错误及最佳实践，一般按主题拆分为多个文件，供按需读取。
• 模板资产：规定产物的章节结构、必备要素与格式约束。
• 可执行脚本：封装校验、转换、数据处理等确定性步骤，适合放不适合交给模型自由发挥的逻辑。
• 配置与清单：声明依赖、所需权限与版本信息，便于打包分发、更新和审计。

运行过程可概括为四步：

1. 加载目录：智能体只读取技能名称和描述；
2. 匹配与激活：识别用户意图，加载命中的技能入口；
3. 按需展开：读取必要的参考文件、模板，按需调用脚本；
4. 执行与校验：应用知识完成任务，在需要时借助脚本或校验规则检查结果。

# 伪代码：渐进式知识加载的执行流程
skill_index = load_skill_index()          # 第一步：仅加载技能名称与描述
matched = match_skills(user_intent, skill_index)   # 第二步：按意图匹配技能
for skill in matched:
    skill.load_entry()                    # 读取技能入口与加载指令
    for ref in skill.needed_references:   # 第三步：按指令读取必要的参考文件
        skill.load_reference(ref)
result = generate(user_task, skill.context)        # 第四步：在技能知识下执行任务
result = skill.verify(result)             # 必要时执行校验脚本

四、五种技能设计模式详解

Pattern 1：工具包装器（Tool Wrapper）——纯知识封装

核心理念：把领域专家的规范与约定沉淀为参考文件，智能体在加载这些规则后即具备该领域的专业视角。整个技能只包含知识，不包含脚本和模板，是最轻量的封装方式。

结构示例：

my-skill/
├── SKILL.md                # 触发关键词与加载指令
└── references/
    └── conventions.md      # 规范、约定与最佳实践

入口示例：

---
name: api-design-expert
description: 帮助编写符合接口设计规范的后端服务代码。当用户需要设计 HTTP 接口、
  编写路由与参数校验、注入依赖或编写控制器层代码时触发。
---
# 接口设计专家
## 激活规则
1. 读取参考文档：references/api-conventions.md
2. 按照文档中的约定，确保生成的接口代码在分层结构、错误处理、参数校验与
   返回格式上均符合规范

适用判断：

• 已有成熟文档化的规范，知识本身相对稳定；
• 任务以“理解并应用规则”为主，不需要复杂计算；
• 希望以最低成本快速形成一套可复用的专家能力。

关键点：description 是智能体的“搜索索引”，必须包含具体业务关键词。若只写“帮助编写代码”这类过于宽泛的描述，技能很容易无法被正确触发，或在多个技能之间发生误匹配。

局限：纯知识封装依赖模型对规则的理解与执行，难以保证百分之百的确定性。若某些规则必须严格执行（如安全校验），应配合脚本实现，或改用校验器模式。

Pattern 2：生成器（Generator）——模板定结构，指南定质量

核心理念：用模板资产规定“输出什么结构”，用风格指南控制“如何写”。模板强制产物的章节构成，风格指南约束语气、用词、格式与可读性，两者结合保证产物既完整又一致。

结构示例：

my-skill/
├── SKILL.md
├── assets/
│   └── report-template.md   # 输出结构模板：必须包含哪些章节
└── references/
    └── style-guide.md       # 语气与格式风格指南

入口示例：

---
name: release-review-report
description: 根据变更记录与测试结果生成版本评审报告。当用户需要撰写发布评审、
  版本总结、上线风险评估或变更说明时触发。
---
# 版本评审报告生成
## 激活规则
1. 读取输出模板：assets/release-review-template.md，严格按模板章节组织内容；
2. 读取风格指南：references/release-review-style.md，统一语气、术语与格式；
3. 模板中标注“必填”的章节不得省略，数据缺失时应明确标注“未提供”，不得臆造。

适用判断：

• 产物有固定的章节结构或交付格式，如评审报告、周报月报、需求文档、测试报告、审计底稿；
• 需要多人、多次产出保持一致的风格；
• 模板本身需要版本管理，便于随业务变化而演进。

关键点：模板解决“完整性”，指南解决“一致性”，两者职责要分开维护。同时应在指令中明确缺失数据的处理方式，防止模型为补全模板而编造内容。

局限：模板越复杂，消耗的上下文也越多。应只保留必要章节，并尽量让模板与指南同批评审、同步更新。

Pattern 3：流程编排器（Workflow Orchestrator）——把 SOP 变成可执行流程

核心理念：把标准作业程序拆解为带顺序、分支和完成条件的步骤序列。智能体按步骤推进，在关键节点读取对应的参考知识，必要时调用脚本完成确定性操作。

结构示例：

my-skill/
├── SKILL.md
├── references/
│   ├── step-1-prepare.md
│   ├── step-2-implement.md
│   ├── step-3-test.md
│   └── step-4-review.md
└── scripts/
    └── check_result.py     # 确定性校验脚本

入口示例：

---
name: defect-fix-workflow
description: 按标准流程定位并修复软件缺陷，覆盖问题复现、根因分析、代码修改、
  测试验证与修复说明五个阶段。当用户报告线上缺陷或需要规范化修复流程时触发。
---
# 缺陷修复标准流程
## 执行步骤
1. 问题复现：阅读 references/step-1-reproduce.md，明确复现步骤与预期行为；
2. 根因分析：阅读 references/step-2-analyze.md，定位根本原因；
3. 代码修改：阅读 references/step-3-fix.md，遵循最小改动原则；
4. 测试验证：阅读 references/step-4-test.md，运行 scripts/check_result.py 校验；
5. 输出修复说明，记录变更点、影响范围与回归建议。
## 执行规则
- 每完成一个阶段，先确认其完成条件满足，再进入下一阶段；
- 任何阶段受阻时，不得跳过，应明确说明阻塞原因。

适用判断：任务步骤固定、存在明确先后依赖、关键节点需要人工确认或质量门禁的场景，如缺陷修复、数据迁移、版本发布、安全评估与合规审查。

关键点：流程编排器让智能体“按步骤办事”，而非“凭感觉办事”。完成条件越明确，流程越稳定；步骤应控制在合理粒度内，过细会增加加载成本，也会削弱模型的推理空间。

局限：灵活性相对较弱，流程外的探索性任务不适合套用。与基于提示词的流程模板相比，技能形式的知识可按阶段分别加载，同一套流程也更容易在不同任务间复用。

Pattern 4：知识路由器（Knowledge Router）——连接外部知识源

核心理念：技能本身不存储全部知识，而是充当“路由表”，声明可用知识源的类型、访问方式与适用条件。智能体先判断“该去哪里查”，再按需读取具体内容，适合知识体量大、更新频繁的领域。

结构示例：

my-skill/
├── SKILL.md
└── references/
    ├── knowledge-sources.md   # 知识源清单、访问方式与适用条件
    └── query-guide.md         # 查询与引用规则

关键点：要区分“检索什么”与“如何检索”。

• 检索什么由模型判断，如识别问题类型、确定查询词与知识范围；
• 如何检索应交给确定性的检索服务完成，如关键词检索、语义检索或文档读取。

若让模型在入口文件中自行编写检索脚本，往往缺乏权限、难以执行，也不利于审计。

与 RAG 的关系：两者都解决“知识不进入模型参数”的问题，但侧重点不同。RAG 强调把检索到的内容拼装进上下文；知识路由器更进一步，先判断需要哪一类知识、从何处获取，再触发检索，相当于在检索之前增加一层“知识调度”。在渐进式加载体系下，它天然位于展开层，是连接技能体系与外部知识资产的桥梁。

适用判断：知识体量大且持续更新（如产品手册、内部规范、接口目录），或需要跨多个系统取数的场景。它无法缓解模型“知识截止日期”带来的时效性问题，真正最新的内容必须经由外部知识源获得。

Pattern 5：校验器（Guardrail / Evaluator）——给输出上一道质量门禁

核心理念：与直接生成答案不同，校验器技能聚焦于“检查与把关”。它把评审规则、判定标准和评分维度封装为技能，并尽量用脚本执行可机器判定的检查，用模型执行需要语义判断的评审。

结构示例：

my-skill/
├── SKILL.md
├── references/
│   └── review-checklist.md  # 评审清单、判定标准与评分维度
└── scripts/
    └── run_checks.py        # 格式、必填项、禁用词等机器可判定的检查

关键点：

• 分层检查：能被规则或脚本判定的（如格式、必填字段、敏感词）交给脚本，保证结果可复现；需要语义理解的（如逻辑是否自洽、结论是否有依据）再交给模型评审。
• 输出可执行：评审结果应结构化为“通过/不通过 + 问题清单 + 修改建议”，便于下游流程据此决定是否放行，而不是一段难以追踪的自然语言评语。

适用判断：安全合规审查、代码质量门禁、数据质量校验、内容合规检查，以及“先生成再校验”的双阶段流水线。

模式对比与组合

维度	工具包装器	生成器	流程编排器	知识路由器	校验器
解决的问题	缺乏领域规则	输出结构与风格不统一	多步骤流程执行不规范	知识量大且持续更新	输出质量与合规性
关键资产	参考知识	模板 + 风格指南	分阶段知识与脚本	知识源清单与查询规则	检查清单与校验脚本
确定性	低	中	中高	中	高
典型产物	符合规范的代码或建议	报告、文档、方案	按步骤推进的执行结果	引用外部知识的回答	评审结论与问题清单

这些模式并非互斥，实践中最常见的做法是组合使用。例如，用一个流程编排器技能串联整个交付过程，在编码阶段引用工具包装器，在文档阶段套用生成器，最后由校验器把关。这正是渐进式加载的价值所在：组合多个技能并不会让每个任务都承担全部知识的开销。

五、技能与相邻概念的区别

• Skill 与系统提示词：系统提示词面向“所有任务”，始终占用上下文；技能面向“特定任务”，按需加载。把通用行为准则留在提示词，把领域规则拆成技能，两者分工更清晰。
• Skill 与工具调用：工具调用让模型“做事”，技能让模型“懂怎么把事做对”。二者互补：工具提供原子动作，技能规定何时调用工具、遵循什么规范、以何种结构组织结果。
• Skill 与工作流引擎：工作流引擎以确定性流程保证执行可靠，适合步骤固定的任务；技能保留模型的判断空间，适合需要理解和决策的任务。生产系统常用“技能负责理解与生成、引擎负责调度与兜底”的组合方式。
• Skill 与模型微调：微调改变模型参数，成本高、周期长、难以解释；技能以外部文件承载知识，更新即时、可审计、可版本化。需要调整模型固有能力时使用微调，需要注入领域知识与规范时优先使用技能。
• Skill 与插件：插件通常通过接口扩展系统功能，侧重“增加能力”；技能侧重“封装知识并规定应用方式”，可以同时包含知识、模板与脚本，与模型解耦，可跨平台迁移。
• Skill 与 RAG：RAG 是检索增强手段，技能是知识与行为的封装单元。技能可以引用检索结果，检索系统也可以把高质量文档作为技能的参考知识来源。

六、对 AI Skill 开发生态的影响

从单一技巧到体系化范式，技能化封装正在改变 AI 能力的开发与交付方式。

1. 知识资产化

企业多年沉淀的规范、流程与最佳实践，过去多以散落文档的形式存在，难以直接被智能体使用。技能化之后，这些知识变为有统一入口、有版本记录、可被智能体调用的数字资产，并可与日志服务、监控告警、对象存储等云上通用基础能力结合，纳入统一管理与审计。

2. 能力复用与组合

统一的结构约定降低了跨项目、跨团队复用的门槛。团队可以像引用依赖包一样引用技能，也可以通过组合多个技能快速搭建新场景，减少重复建设。

3. 分发与评测标准化

当技能具备统一的目录结构、入口描述与清单文件，围绕它的打包、版本管理、权限控制与自动化评测就能形成标准流程。例如，为每个技能配套一组“输入—预期触发—预期输出”的测试用例，在发布前验证触发准确率与输出质量，减少上线后的不确定性。

4. 开发角色的变化

开发者需要具备的不仅是提示词编写能力，还包括知识建模、规则抽象与评测设计能力：判断哪些知识适合写成技能，哪些逻辑应交给脚本，以及如何度量技能效果。

5. 治理与安全要求提升

技能会被反复复用、跨团队流转，一旦包含不当指令或低质量知识，影响面会被放大。因此，入口描述、参考知识与脚本的评审机制，技能来源的签名校验，以及最小权限原则，都应纳入日常治理。

七、落地注意事项

1. 写好触发描述：名称与描述应具体、可区分，覆盖典型用户表达和同义词，并定期根据实际触发日志优化，避免多个技能描述重叠造成误激活。
2. 控制技能数量与层级：技能过多会让匹配本身变得困难。建议按业务域分组、建立层级，或将相关性高的知识合并为一个技能，用参考文件拆分内容。
3. 把知识放在正确的一层：高频通用规则放在入口文件或系统提示词；低频、体积大的细节放在参考文件；需要严格执行的逻辑交给脚本。
4. 脚本遵循最小权限：脚本应只做明确、可验证的事，避免无约束的网络访问与文件操作，输入须校验，必要时在隔离环境中运行。
5. 做好版本与兼容管理：知识会随业务演进而变化，技能应纳入版本控制。入口描述调整或参考文件重构时，要为旧版本保留过渡期，避免智能体突然无法触发原有能力。
6. 建立可量化的评测：至少覆盖触发准确性、输出符合规范的比例与 Token 消耗三类指标，把评测结果作为技能迭代的依据。
7. 明确知识时效边界：对时效性强的信息，应说明知识来源与更新频率，关键结论要引导用户到权威渠道复核，避免把过期信息当作事实。

八、总结

回到定义本身：智能体技能设计模式，是把领域知识、输出规范和可执行逻辑封装为可发现、可按需加载的能力单元的方法体系。它依托渐进式知识加载，在“灵活理解”与“确定执行”之间提供了五种典型选择：

• 工具包装器用知识赋能；
• 生成器用模板统一输出；
• 流程编排器用步骤保障过程；
• 知识路由器用外部知识源扩充能力；
• 校验器用门禁保障质量。

选型时不必追求“最先进”的模式，而应回到三个问题：任务需要的是知识、结构、流程、外部数据，还是质量把关？知识多久更新一次？输出是否必须可复现？据此选择单一模式或组合方案，并配以清晰的触发描述、严格的最小权限与持续评测，才能让技能真正成为可复用、可治理的智能体能力资产。