Hermes Skill设计模式：AI能力复用工程资产权威指南
#26 Skill设计模式：把AI能力变成可复用的工程资产
你会写代码，但你能让AI也“学会”写代码吗？
Prompt教AI做事，本质上还是手工作坊那一套。你花了两小时精心构造了一个代码审查的Prompt，效果确实惊艳。然后呢？这个能力就锁死在了你的聊天记录里——换了项目、换了同事、哪怕只是关掉当前对话窗口重新打开，一切归零。你的AI能力，从来没有真正属于你的团队。它们散落在无数聊天记录的角落，像手写配方一样，人走了，配方也就丢了。
这不是个别现象，而是整个行业的通病。大多数团队的所谓“AI能力”，本质上就是几个资深工程师脑子里装着的Prompt集合。团队扩张时，新人只能从零摸索；项目交接时，经验随风消散；季度复盘时，没人说得清团队到底积累了多少可复用的AI能力。每一次有价值的AI协作经验，都在对话窗口关闭的那一刻，蒸发得干干净净。
Hermes给出的答案是Skill设计模式——七种将AI能力从“手工作坊”提升为“工业资产”的结构化模式。之前在模块四中，我们介绍了Skills系统的七个必定义要素和基础用法。今天，我们从“会用Skill”升级到“设计Skill”——就像从“会写代码”升级到“会用设计模式写代码”一样，这是一次认知层级的跨越。当你的团队掌握了这七种Skill设计模式，每一个AI能力就不再是消耗品，而是可以复用、组合、进化的工程资产。
Skill完整生命周期：从诞生到进化
一个Skill不是写完就结束了。它有自己的生命周期——从定义、到触发、到执行、到验证、到沉淀、最终到进化。理解这个生命周期，是掌握Skill设计模式的前提。
┌─────────────────────────────────────────────────────────────────────┐
│Skill Lifecycle: 从诞生到进化 │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Define │─→│ Trigger │─→│ Execute │─→│ Verify │ │
│ │ 结构定义 │ │ 条件匹配 │ │ 工具调度 │ │ 证据校验 │ │
│ └─────────┘ └─────────┘ └─────────┘ └────┬────┘ │
│ │ │
│ ┌─────────┐ │ │
│ │ Evolve │←─│ │
│ │ 自进化 │ │ │
│ └────┬────┘ │ │
│ │ │ │
│ ▼ │ │
│ ┌───────────┐│ │
│ │ 下一轮执行 ││ │
│ │ 更强的Skill││ │
│ └───────────┘│ │
└─────────────────────────────────────────────────────────────────────┘
Define（结构定义）——按照七种设计模式之一，将AI能力结构化定义。模板模式最简单，组合模式最强大。定义的质量，直接决定了Skill的可复用性和可进化性。
Trigger（条件匹配）——Context Engine分析当前Goal的语义和上下文，判断是否匹配某个Skill的触发条件。精准的Trigger定义是避免“该用没用”和“不该用乱用”的关键。
Execute（工具调度）——Skill的Steps被翻译为具体的Tool Dispatch调用。Execution Layer负责调度Worker、分配工具、管理执行顺序。
Verify（证据校验）——每一步执行的结果都经过Verification Protocol的校验。不是“看起来完成了”，而是有证据地完成。
Store（经验沉淀）——执行轨迹、成功模式、失败教训全部写入Memory System（LTM和EP）。这不是日志归档，而是为自进化准备燃料。
Evolve（自进化）——这是生命周期的终点，也是下一轮的起点。Trajectory Log中的模式被Skill Registry识别，提炼为Skill的改进版本。一个定义时只有3个Step的Skill，经过100次执行后可能进化为5个Step——因为系统学到了两个新的边界条件需要处理。Skill不是静态代码，而是活的工程资产。
七大Skill设计模式：从简单到强大的阶梯
软件工程有23种经典设计模式。Hermes的Skill系统提炼出七种高频模式，覆盖从最简单的单步操作到最复杂的多Skill编排。掌握这七种模式，就像掌握了搭建能力建筑的七种标准结构——任何AI能力都可以用它们的组合来表达。
模式一：模板模式（Template Pattern）
最简单也最常用的模式。固定执行步骤，参数化输入。就像一个模板函数——逻辑不变，数据可替换。
┌──────────────────────────────────────┐
│Template Pattern │
│ │
│ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │Step 1 │─→│Step 2 │─→│Step 3 │ │
│ └───┬───┘ └───┬───┘ └───┬───┘ │
│ │ │ │ │
│ ┌───▼───────────▼───────────▼───┐ │
│ │ 参数化输入 (inputs) │ │
│ │ files, context, standards │ │
│ └───────────────────────────────┘ │
└──────────────────────────────────────┘
适用场景：流程固定、输入可变的任务。代码审查、文档生成、测试编写。
skill: code_review_v2
pattern: template
trigger: "当需要审查代码变更时"
inputs:
- files: { type: "list", required: true }
- strictness: { type: "enum[standard,strict]", default: "standard" }
- focus_areas: { type: "list", default: ["security","performance","style"] }
steps:
- action: "读取变更文件的git diff"
tool: git_diff
- action: "运行静态分析工具"
tool: linter_runner
- action: "按维度逐一审查"
tool: llm_reasoning
context: "{focus_areas} 维度清单"
- action: "生成结构化审查报告"
tool: report_generator
模式二：策略模式（Strategy Pattern）
同一目标，多种策略可选。运行时根据上下文选择最优策略。
┌──────────────────────────────────────┐
│Strategy Pattern │
│ │
│ ┌──────────┐ │
│ │ 目标 Goal │ │
│ └─────┬────┘ │
│ │ │
│ ┌──────────┼──────────┐ │
│ ▼ ▼ ▼ │
│ ┌─────────┐┌─────────┐┌─────────┐ │
│ │策略 A ││策略 B ││策略 C │ │
│ │金丝雀 ││蓝绿部署 ││滚动更新 │ │
│ └─────────┘└─────────┘└─────────┘ │
│ │ │ │ │
│ └──────────┴──────────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ 策略选择器 │ │
│ │(基于上下文)│ │
│ └───────────┘ │
└──────────────────────────────────────┘
适用场景：同一任务有多种实现路径，需要根据环境、风险级别、资源约束动态选择。
skill: deployment
pattern: strategy
trigger: "当需要部署服务到目标环境时"
strategy_selector:
rules:
- condition: "environment == 'production' AND risk_level == 'high'"
strategy: "canary"
- condition: "environment == 'production' AND rollback_window == 'immediate'"
strategy: "blue_green"
- condition: "environment == 'staging' OR change_scope == 'small'"
strategy: "rolling"
fallback: "rolling"
strategies:
canary:
steps: ["部署到5%流量","监控15min","扩大到25%","监控15min","全量"]
blue_green:
steps: ["部署蓝环境","健康检查","切换流量","保留绿环境30min"]
rolling:
steps: ["批次1(25%)","批次2(50%)","批次3(75%)","批次4(100%)"]
模式三：管道模式（Pipeline Pattern）
串行处理，每步输出是下步输入。经典的数据处理流水线。
┌────────────────────────────────────────────────────────┐
│Pipeline Pattern │
│ │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌─────┐ │
│ │Extract│→│Clean │→│Trans-│→│Enrich│→│Load │ │
│ │ │ │ │ │form │ │ │ │ │ │
│ └──────┘ └──────┘ └──────┘ └──────┘ └─────┘ │
│ ↓output ↓output ↓output ↓output ↓ │
│ 成为下步input 成为下步input ...... 完成 │
└────────────────────────────────────────────────────────┘
适用场景：数据处理、ETL、多阶段代码生成（分析→设计→编码→测试）。
skill: data_pipeline
pattern: pipeline
trigger: "当需要处理和转化数据时"
inputs:
- source: { type: "data_source", required: true }
- target: { type: "data_sink", required: true }
pipeline:
- stage: "extract"
tool: "data_connector"
output: "raw_data"
- stage: "clean"
tool: "data_cleaner"
rules: ["remove_nulls", "deduplicate", "normalize_encoding"]
input_from: "raw_data"
output: "clean_data"
- stage: "transform"
tool: "llm_reasoning"
prompt: "按目标Schema转换数据格式"
input_from: "clean_data"
output: "transformed_data"
- stage: "enrich"
tool: "external_api"
input_from: "transformed_data"
output: "enriched_data"
- stage: "load"
tool: "data_writer"
input_from: "enriched_data"
output: "completion_report"
模式四：分支模式（Branching Pattern）
条件判断后走不同路径。不是所有任务都是直线——有些需要根据中间结果做决策。
┌──────────────────────────────────────────────────┐
│Branching Pattern │
│ │
│ ┌──────────┐ │
│ │ 输入判断 │ │
│ └─────┬────┘ │
│ │ │
│ ┌──────────┼──────────┐ │
│ ▼ ▼ ▼ │
│ ┌────────┐┌────────┐┌────────┐ │
│ │路径 A ││路径 B ││路径 C │ │
│ │error_ ││error_ ││error_ │ │
│ │type ││type ││type │ │
│ │=timeout││=auth ││=data │ │
│ └───┬────┘└───┬────┘└───┬────┘ │
│ └──────────┴──────────┘ │
│ ▼ │
│ ┌──────────┐ │
│ │ 结果合并 │ │
│ └──────────┘ │
└──────────────────────────────────────────────────┘
适用场景：错误处理（根据错误类型选择修复策略）、用户请求路由（根据意图分发）、条件发布（根据检查结果决定下一步）。
skill: error_handler
pattern: branching
trigger: "当执行过程中间出现错误时"
branches:
- condition: "error.type == 'TIMEOUT'"
path: "retry_with_backoff"
steps: ["等待1s", "重试", "失败则等待2s再试", "3次后升级"]
- condition: "error.type == 'AUTH_FAILURE'"
path: "refresh_credentials"
steps: ["刷新Token", "重试原操作", "仍失败则升级人工"]
- condition: "error.type == 'DATA_VALIDATION'"
path: "auto_fix_data"
steps: ["分析校验失败原因", "生成修复方案", "自动应用", "重新验证"]
- condition: "error.type == 'UNKNOWN'"
path: "escalate"
steps: ["记录完整错误上下文", "生成诊断报告", "升级到人工审批"]
模式五：并行模式（Parallel Pattern）
多个子任务同时执行，结果汇聚。大幅缩短执行时间。
┌──────────────────────────────────────────────┐
│Parallel Pattern │
│ │
│ ┌──────────┐ │
│ │ 任务分发 │ │
│ └─────┬────┘ │
│ ┌──────────┼──────────┐ │
│ ▼ ▼ ▼ │
│ ┌────────┐┌────────┐┌────────┐ │
│ │子任务A ││子任务B ││子任务C │← 同时执行 │
│ │file_1 ││file_2 ││file_3 │ │
│ └───┬────┘└───┬────┘└───┬────┘ │
│ └──────────┼──────────┘ │
│ ▼ │
│ ┌──────────┐ │
│ │ 结果汇聚 │ │
│ └──────────┘ │
└──────────────────────────────────────────────┘
适用场景：多文件审查、批量数据处理、多环境测试、多源信息聚合。
skill: multi_file_review
pattern: parallel
trigger: "当需要同时审查多个文件时"
parallel_tasks:
- task: "review_file"
inputs: { file: "${files[0]}", focus: "security" }
- task: "review_file"
inputs: { file: "${files[1]}", focus: "security" }
- task: "review_file"
inputs: { file: "${files[2]}", focus: "security" }
# ... 动态扩展，每个文件一个并行子任务
aggregation:
strategy: "merge_reports"
steps: ["收集所有审查结果", "去重重复问题", "按严重性排序", "生成汇总报告"]
模式六：递归模式（Recursive Pattern）
自我调用处理层级结构。文件系统遍历、嵌套数据解析、分治问题求解。
┌───────────────────────────────────────────────────┐
│Recursive Pattern │
│ │
│ ┌───────────┐ │
│ │ 处理节点N │ │
│ └─────┬─────┘ │
│ │ │
│ ┌────▼────┐ │
│ │有子节点？│ │
│ └──┬───┬──┘ │
│ YES│ │NO │
│ │ └──→ 返回处理结果 │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ 对每个子节点递归调用 │──→ 处理节点N/child_1 │
│ │ ├──→ 处理节点N/child_2 │
│ │ └──→ ... │
│ └──────────┬──────────┘ │
│ ▼ │
│ 合并所有子结果 │
└───────────────────────────────────────────────────┘
适用场景：目录结构遍历、嵌套JSON/XML解析、分治算法、多层依赖分析。
skill: directory_analyze
pattern: recursive
trigger: "当需要分析目录结构和代码组织时"
recursive_logic:
base_case: "当前节点是文件 → 分析单个文件"
recursive_step: "当前节点是目录 → 对每个子节点递归调用自身"
aggregation: "合并所有子节点的分析结果"
max_depth: 10
termination:
- condition: "depth >= max_depth"
action: "停止递归，返回当前层级摘要"
- condition: "node_count > 500"
action: "切换为采样模式，每层最多分析50个节点"
模式七：组合模式（Composition Pattern）
多个Skill组合成新Skill——这是最强大的模式。当原子Skill足够丰富时，组合模式让你像搭积木一样构建复杂的AI能力。
┌─────────────────────────────────────────────────────────┐
│ Composition Pattern │
│ │
│ Composite Skill: 发布流水线 │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────────┐ │
│ │ Skill A │ │ Skill B │ │ Skill C │ │
│ │ 代码审查 │→│ 安全扫描 │→│ 部署 │ │
│ └─────────┘ └─────────┘ │ ┌──────┐ │ │
│ │ │策略A │ │ │
│ │ │金丝雀│ │ │
│ │ └──────┘ │ │
│ └─────────────────┘ │
└─────────────────────────────────────────────────────────┘
适用场景：完整CI/CD流水线、端到端开发流程、复杂工作流编排。
skill: release_pipeline
pattern: composition
trigger: "当需要执行完整的发布流程时"
composed_skills:
- skill_ref: "code_review_v2" # 模板模式
inputs_mapping:
files: "${goal.changed_files}"
strictness: "strict"
- skill_ref: "security_scan" # 模板模式
inputs_mapping:
target: "${goal.project_root}"
- skill_ref: "multi_file_review" # 并行模式
inputs_mapping:
files: "${goal.changed_files}"
condition: "code_review_v2.passed == true"
- skill_ref: "deployment" # 策略模式
inputs_mapping:
environment: "${goal.target_env}"
condition: "all_previous.passed == true"
七种模式全景对比
| 模式 | 复杂度 | 适用场景 | 自进化潜力 | 关键价值 |
|---|---|---|---|---|
| 模板模式 | 低 | 流程固定、输入可变 | 中 — 步骤可扩展 | 最快上手，团队入门首选 |
| 策略模式 | 中 | 同一目标、多种路径 | 高 — 策略库可增长 | 运行时动态选择最优解 |
| 管道模式 | 中 | 串行多阶段处理 | 高 — 管道节点可插拔 | 数据流转清晰可控 |
| 分支模式 | 中 | 条件判断、路径选择 | 高 — 分支条件可学习 | 应对不确定性 |
| 并行模式 | 中高 | 多任务并发执行 | 中 — 并行策略可优化 | 执行效率倍增 |
| 递归模式 | 高 | 层级/嵌套结构处理 | 中 — 终止条件可进化 | 处理任意深度结构 |
| 组合模式 | 最高 | 多Skill编排成流水线 | 极高 — 组合方式指数级增长 | 能力的复利效应 |
七个必定义要素的工程深化：设计模式视角
之前我们介绍了Skill的七个必定义要素——Trigger、Inputs、Tools、Steps、Failure Handling、Logs、Verification。现在从设计模式的视角重新审视它们。不同的设计模式，会从根本上改变每个要素的定义方式。
Trigger：从关键词匹配到语义理解
模板模式的Trigger通常是简单的关键词或条件判断。但策略模式需要更智能的Trigger——它不仅要判断“该不该触发”，还要判断“该用哪个策略”。组合模式的Trigger最复杂，它需要理解Goal的完整语义，才能决定是否需要触发一整条流水线。
# 模板模式Trigger — 简单条件
trigger: "当需要审查代码变更时"
# 策略模式Trigger — 条件 + 策略选择
trigger:
condition: "当需要部署服务时"
strategy_resolver: "根据environment + risk_level动态选择策略"
# 组合模式Trigger — 语义匹配
trigger:
condition: "当Goal语义匹配'发布流程'或'上线部署'时"
composition_resolver: "根据Goal上下文选择Skill组合方案"
Inputs：从静态参数到动态流
管道模式中，Inputs是动态流动的——每一步的输出自动成为下一步的输入。并行模式需要将Inputs拆分到多个子任务。递归模式的Inputs在每次自我调用时都在变化（当前处理的节点不同）。
# 管道模式Inputs — 流式传递
pipeline:
- stage: "extract"
output: "raw_data" # 自动注入下一阶段
- stage: "clean"
input_from: "raw_data" # 引用上一阶段输出
output: "clean_data"
# 并行模式Inputs — 动态分片
parallel_inputs:
source: "${goal.changed_files}"
partition_strategy: "one_file_per_task"
Steps：从线性列表到动态DAG
模板模式的Steps是固定的线性列表。分支模式的Steps是条件树。组合模式的Steps是多个Skill的编排图。Steps的定义方式直接决定Skill的表达能力上限。
# 模板模式Steps — 线性
steps: ["步骤1", "步骤2", "步骤3"]
# 分支模式Steps — 条件树
steps:
- action: "判断错误类型"
branches:
- condition: "timeout" → ["重试逻辑"]
- condition: "auth" → ["刷新Token"]
# 组合模式Steps — DAG编排
steps:
- skill: "code_review" → 输出到 gate_1
- skill: "security_scan" → 输出到 gate_1
- gate_1: "全部通过?" → 输入到 deployment
- skill: "deployment" → 输入来自 gate_1
Failure Handling：从单点重试到模式化容灾
管道模式中，某一步失败可能需要从失败点重新开始（而非从头重跑）。并行模式中，一个子任务失败不应阻塞其他子任务。递归模式需要防止无限递归。每种模式有其独特的失败模式，容灾设计必须与之匹配。
Logs和Verification：从记录到进化燃料
无论哪种模式，Logs和Verification都是自进化的关键输入。管道模式记录每阶段的延迟，用于优化瓶颈。策略模式记录每次策略选择的结果，用于优化选择器。组合模式记录每条流水线的端到端指标，用于优化编排策略。Logs不只是审计日志，它是Skill自我进化的训练数据。
从Prompt到Skill的转化方法论
理论说完了。现在看一个完整的转化案例——从“每次花20分钟写代码审查prompt”到“一行指令调用Skill”的全过程。
第一步：识别高频操作
回溯过去一个月的AI交互记录，找出你反复在做的操作。代码审查、Bug分析、API设计、测试编写——这些高频操作就是Skill的候选。判断标准很简单：同一个操作你做了3次以上，它就应该被封装为Skill。
第二步：提取模式
分析这些高频操作的共性。以代码审查为例：
原始Prompt片段（每次都要重写）：
"请审查以下代码变更，注意：
1. SQL注入等安全漏洞
2. N+1查询等性能问题
3. 是否符合团队编码规范
4. 边界条件处理
5. 异常处理完整性
6. 与现有架构的兼容性
请按严重程度标注每个问题..."
提取模式：这是一个模板模式Skill——步骤固定（6个审查维度），输入可变（不同的代码文件）。
第三步：结构化定义
将提取的模式按照七个必定义要素结构化：
# 转化前：每次花20分钟手写Prompt
# 转化后：一行调用
/skill code_review_v2 --files src/api/auth.py,src/services/user.py
# 背后的完整定义
skill: code_review_v2
version: "2.4" # 经过24次迭代进化
pattern: template
evolution_log:
- v1.0: 初始6维度审查
- v1.3: 增加"依赖兼容性"维度（从第8次执行中学到）
- v2.0: 重构为模板模式（从第15次执行中发现模式）
- v2.4: 增加"LLM幻觉检测"维度（从第22次的误报中学到）
trigger: "当需要审查代码变更时"
inputs:
- files: { type: "list", required: true }
- strictness: { type: "enum[standard,strict]", default: "standard" }
- focus_areas: { type: "list", default: ["security","performance","style","edge_cases","error_handling","architecture_compatibility"] }
tools: [git_diff, linter_runner, test_runner, llm_reasoning, report_generator]
steps:
- "读取git diff，提取变更范围"
- "运行静态分析和测试套件"
- "逐维度深度审查（6+1个维度）"
- "标注严重级别，生成修复建议"
- "输出结构化审查报告"
failure_handling:
- linter失败: "跳过自动检查，切换为纯LLM审查"
- 文件过大: "自动分片审查，每片不超过500行"
- 超时: "返回已完成部分的审查结果，标记未完成区域"
logs:
- "审查文件数、发现的问题数及级别分布、审查耗时"
verification:
- "所有变更文件均已审查"
- "每个问题包含：位置、严重级别、修复建议"
- "报告格式符合团队标准"
stats: # 自进化统计数据
total_invocations: 247
success_rate: 96.3%
a vg_issues_per_review: 3.7
false_positive_rate: 4.1% # 持续下降中
last_evolved: "2026-05-28"
看到evolution_log了吗？这个Skill不是一次写完就固定的——它经历了24次迭代，每次迭代都来自真实执行中发现的新模式。v1.3的“依赖兼容性”维度是从第8次执行中发现的盲区：代码本身没问题，但新引入的依赖版本与现有系统冲突。v2.4的“LLM幻觉检测”维度是从第22次执行中学到的：审查报告引用了一个不存在的函数名，后来发现是LLM的幻觉。这些都是人类不可能在第一次定义时就预见到的——只有通过持续执行和自进化才能学到。
震撼时刻：Skill的网络效应
以下是一个真实团队在6个月内的Skill积累数据。看这张表的时候，请注意最后一列。
┌────────────────────────────────────────────────────────────────────┐
│团队Skill积累曲线：从0到47的6个月旅程 │
│ │
│月份 Skill数 本月新增 总调用次数 平均成功率 组合复用次数 │
│───── ──────── ──────── ──────────── ──────────── ──────────── │
│M1 3 3 47 78.2% 0 │
│M2 8 5 186 84.1% 7 │
│M3 16 8 523 89.7% 34 │
│M4 27 11 1247 92.3% 128 │
│M5 38 11 2891 94.8% 437 │
│M6 47 9 5634 96.1% 1203 │
│ │
│═════════════════════════════════════════════════════════════════ │
│核心洞察：组合复用次数的增长不是线性的，而是指数级的 │
│ │
│M1→M3: 16个Skill, 34次组合 → 每个Skill平均参与 2.1次组合 │
│M4→M6: 47个Skill, 1203次组合 → 每个Skill平均参与 12.8次组合 │
│ │
│第47个Skill的价值 ≈ 前46个Skill创造的所有组合机会 │
│公式：新增组合潜力 = C(46,1) + C(46,2) + ... ≈ 2^46 │
└────────────────────────────────────────────────────────────────────┘
Skill的价值不是线性的，而是网络效应式的——第47个Skill的价值远大于第1个，因为它可以与前46个Skill任意组合。
这就像城市的交通网络。第1条路的价值很低——它只连接两个点。但当路网扩展到47条路时，每新增一条路不仅连接两个新点，还让所有已有的点之间多了一种新的可达路径。47个Skill的团队，本质上已经拥有了一个覆盖C(47,2)=1081种双Skill组合、C(47,3)=16215种三Skill组合的能力网络。
更关键的是最后一列的数据——成功率从78.2%上升到96.1%。这不是因为团队在手动优化每个Skill，而是因为自进化机制在每次执行后自动提炼经验。每个Skill的成功率提升，会通过网络效应传导到所有包含它的组合Skill中——一个基础Skill的1%提升，可能让10条流水线的端到端成功率各提升0.5%。
Skill vs Plugin vs Macro：本质区别
这三个概念经常被混淆。但它们之间的差异不是程度上的，而是本质上的。
| 维度 | Macro（宏） | Plugin（插件） | Skill（技能） |
|---|---|---|---|
| 抽象层级 | 操作序列的录制回放 | 功能接口的标准化封装 | 能力的结构化表达 |
| 可组合性 | 低 — 顺序拼接 | 中 — 通过接口调用 | 高 — 七种设计模式自由组合 |
| 自进化能力 | 无 — 录完即固化 | 无 — 版本需手动升级 | 核心特征 — 每次执行都在积累进化数据 |
| 上下文感知 | 无 — 不看环境 | 弱 — 固定参数 | 强 — Context Engine动态注入 |
| 失败处理 | 无 — 出错即停 | 弱 — try-catch | 多层级 — 重试/降级/分支/升级人工 |
| 治理复杂度 | 低 — 几乎不需要 | 中 — 版本和依赖管理 | 高 — 但设计模式提供标准化治理框架 |
| 价值增长曲线 | 线性 — 加一个多一个 | 线性 — 装一个多一个 | 指数级 — 网络效应驱动复利增长 |
核心区别用一句话概括：Macro是“你做了什么”的回放，Plugin是“系统能做什么”的扩展，Skill是“Agent学会了什么”的能力资产。 只有Skill具备自进化能力——它越用越强，越组合越强大，越分享越有价值。
模块十启程：从底层到能力的跨越
模块九的五篇文章拆解了Hermes的五层架构全景——从Interface到Foundation，从Tool Dispatch到Trajectory Log，从Reasoning Parsing到Verification Protocol。那些是Hermes的骨架和肌肉。模块十，我们进入一个全新的维度——能力层。
七个Skill设计模式是能力层的设计语言。模板模式让简单的事标准化，策略模式让复杂的事可控化，管道模式让数据流转工程化，分支模式让不确定性可管理，并行模式让效率最大化，递归模式让层级结构可处理，组合模式让能力实现指数级增长。这七种模式不是选一个用——它们是组合使用的。一个成熟团队的Skill库中，七种模式都会出现，而且越高级的模式越依赖低级模式作为积木。
但设计模式说完了，Skill最可怕的特性还没有展开——它会自己进化。本文的evolution_log字段只是冰山一角。下一篇，我们将拆解自进化Skill的完整机制：Skill如何从执行轨迹中自动学习新步骤？如何从失败中自动提炼新的分支条件？如何从用户反馈中自动调整策略权重？
#27：自进化Skill，让AI能力自己长出来。