在上一篇文章中，我们探讨了 agent-skills 的技能定义格式 —— 每个 SKILL.md 如何通过 Frontmatter、Process、Verification 三段式结构为 AI 代理提供可执行的工作流框架。本文将视角向下游移动，讨论一个更复杂的工程问题：当技能定义本身已经标准化之后，如何让多个技能协同工作、形成可靠的任务执行链。
这不是一个简单的问题。单一技能可以优雅地描述 "如何做一件事"，但一个完整的生产级任务 —— 比如 "实现一个带有认证、数据库和前端的新功能"—— 需要的不是一条指令，而是一套有序执行的技能序列。这套序列必须解决三个核心问题：技能之间如何发现和调用、任务依赖关系如何解析、跨不同环境（Claude Code、Cursor、Gemini CLI）执行时如何保证一致性。
技能链式组合的核心：元技能驱动的发现机制
agent-skills 没有采用硬编码的技能调用顺序，而是通过一个元技能（meta-skill）using-agent-skills 来实现技能发现与动态组合。这个设计选择至关重要：它意味着技能链不是预定义的固定流程，而是根据任务上下文实时推导出的执行路径。
using-agent-skills 本质上是一个决策树。当任务到达时，它首先判断任务所处的开发阶段，然后根据阶段特性决定应该激活哪个技能。以一个完整的特性开发为例，典型的技能触发序列是这样的：
任务到达 → 判断是否为模糊想法 → 触发 idea-refine 进行结构化发散与收敛 → 想法明确后 → 触发 spec-driven-development 编写 PRD → 有规格文档后 → 触发 planning-and-task-breakdown 拆解任务 → 进入构建阶段 → 激活 context-engineering 加载正确上下文 → source-driven-development 从官方文档验证技术方案 → incremental-implementation 增量实现 → test-driven-development 每个切片验证 → 构建完成后 → code-review-and-quality 评审 → shipping-and-launch 部署上线。
这个序列不是写死的，而是由决策树的每个分支 "生长" 出来的。更值得注意的是，并非每个任务都需要完整走完整个生命周期。文章开篇就明确指出：简单 bug 修复可能只需要 debugging-and-error-recovery → test-driven-development → code-review-and-quality 三步就能完成。技能链的长度取决于任务的复杂度，而复杂度由元技能根据任务特征自行判断。
这种设计的工程价值在于：它把 "什么时候用什么技能" 这个决策从硬编码逻辑中抽离出来，变成一个可配置、可扩展的规则集。新增一个技能只需要在决策树中添加一个分支节点，而不需要修改任何调用方的代码。这为技能库的演进提供了极大的灵活性。
依赖解析：任务分解中的垂直切片策略
技能链的执行依赖于任务分解的正确性。没有合理的任务分解，再好的技能也无法可靠执行。planning-and-task-breakdown 技能提供了一套依赖解析的方法论，其中最核心的概念是垂直切片（vertical slicing）和依赖图（dependency graph）。
水平切片是新手最容易犯的错误：先完成所有数据库设计，再完成所有 API 实现，再完成所有前端界面。这种方式的问题是，在相当长的时间里系统处于 "什么都做了但什么都不可用" 的状态，任何返工都会导致大量浪费。垂直切片则要求每个增量都包含完整的端到端功能路径：一个增量完成用户注册的数据层加接口层加界面层，另一个增量完成用户登录的完整路径，以此类推。
依赖图的构建是垂直切片的前提。planning-and-task-breakdown 展示了一个清晰的依赖层次：数据库 schema 是所有其他层的底层依赖，schema 之上是 API models 和 types，再之上是 API endpoints，然后是前端 API client 和 UI components。这种层次决定了实现顺序必须从底层向上：先建地基，再建墙体，最后装修。任何违反这个顺序的做法都会导致大量的返工和耦合。
这套方法论直接影响了技能链的可组合性。当任务被正确分解为相互依赖的垂直切片后，每个切片就可以独立地触发相应的技能序列。切片 1 可能只需要 incremental-implementation + test-driven-development，切片 2 如果涉及 API 设计，还需要额外激活 api-and-interface-design。技能链的长度不再是固定的，而是由任务分解的结果动态决定的。
验证门控：每个技能退出条件的强制执行
技能链式组合中最大的风险不是某个技能执行失败，而是 "看起来成功了但实际没有达到标准"。using-agent-skills 中有一条核心原则："Seems right" 永远不够 —— 必须有证据。这个原则被嵌入到每个技能的验证门控中，形成了技能链可靠性的最后一道防线。
incremental-implementation 技能展示了验证门控的具体实现。每个增量完成时，必须执行完整的验证清单：所有现有测试通过（npm test）、构建成功（npm run build）、类型检查通过（npx tsc --noEmit）、lint 通过（npm run lint）、新功能按预期工作、变更已提交。任何一个环节失败，增量就不能算完成，就必须修复后重新验证。
这种强制验证的门控机制防止了技能链中的 "信任积累" 问题。在一个长的技能链中，如果每个技能只是 "差不多完成了" 就进入下一个，最终累积的偏差会导致系统性的失败。验证门控要求每个技能的退出条件必须清晰、可测量、不可跳过。
doubt-driven-development 技能进一步强化了验证的严格性。它要求对每个非平凡决策都进行一次 fresh-context 的对抗性审查。在这一步中，决策者将代码 diff、提案描述和约束条件提交给一个隔离上下文的审查者，审查者的职责是发现问题而不是验证正确性。审查发现被分类为：合同误读（需修正合同）、有效可操作（必须修改代码）、有效权衡（接受风险并文档化）、或者噪音（审查者误解）。只有当所有有效问题都被处理后，决策才能 "站立" 进入下一个技能。
这种多轮对抗性审查的机制在技能链中引入了实质性的质量门。虽然它增加了执行时间，但它的价值在于：在方向错误导致大量返工之前捕获问题。这是技能链式组合中最昂贵的检查，但也是最值得的检查。
跨环境执行一致性的工程设计
agent-skills 需要在至少六种不同的 AI 代理环境中运行：Claude Code、Cursor、Gemini CLI、Windsurf、OpenCode、GitHub Copilot。这些环境在指令格式、能力边界和调用方式上存在显著差异。技能链要在这六种环境中保持一致的执行效果，必须依赖一套清晰的环境适配策略。
环境适配的第一层是技能格式的统一。所有的技能都遵循同一个 SKILL.md 格式：Frontmatter 定义元数据（name、description、触发条件），Overview 说明技能用途，When to Use 明确激活条件，Process 提供步骤化的工作流，Rationalizations 提供常见借口和反驳，Red Flags 列出警示信号，Verification 定义退出标准。这个格式在任何环境下都是一致的，代理只需要按照格式读取并执行即可。
环境适配的第二层是命令别名系统。Claude Code 使用 .claude/commands/ 中的 slash commands（/spec、/plan、/build 等），Gemini CLI 使用 .gemini/commands/ 中的同名命令，Cursor 和 Windsurf 则将技能内容复制到 .cursor/rules/ 或对应的规则目录中。这些不同的安装路径都映射到同一个技能定义，保证了无论在哪种环境中执行，技能的实质内容都是一致的。
跨环境一致性的第三个工程要素是渐进式上下文加载。文章明确指出："The SKILL.md is the entry point. Supporting references load only when needed, keeping token usage minimal." 这不是优化建议，而是可靠性设计。在长技能链中，如果每个技能都加载全部上下文，上下文窗口会在中途耗尽，导致后续技能无法正常执行。渐进式加载确保在技能链的任何一个环节，上下文压力都保持在可控范围内。
工程化落地的关键参数与检查清单
基于上述机制分析，以下是在实际项目中应用 agent-skills 技能链式组合时的关键参数和检查项。
技能链启动前的环境参数。 在启动技能链之前，必须确认以下环境参数就位：技能库已正确安装到目标代理环境中、slash commands 已注册并可响应、references 目录可被技能访问、增量验证命令（npm test、npm run build 等）在目标项目环境中可用。这些参数中的任何一个缺失都会导致技能链无法完成执行。
任务分解的质量参数。 一个好的任务分解必须满足以下标准：每个任务都有明确的验收条件（可测试的具体描述）、每个任务都有验证步骤（不仅仅是 "完成" 而是 "通过了什么检查"）、任务依赖关系被明确标注并按依赖顺序排列、没有任何任务的规模超过 L（5-8 个文件），所有 L 级任务必须进一步拆分。这意味着对于大多数代理任务，实际执行的任务规模应该控制在 S（1-2 个文件）和 M（3-5 个文件）级别。
技能链执行中的门控参数。 在技能链的执行过程中，每个技能的退出必须满足：所有验证命令通过、变更已原子提交（一个变更一个 commit）、上下文窗口使用量保持在 70% 以下（为后续技能留出空间）、没有任何跨越任务边界的 "顺便修复"（scope discipline）。当验证失败时，必须停止并修复，不得跳过进入下一个技能。
跨环境部署的参数。 将技能链部署到新的代理环境时，必须验证：SKILL.md 格式在该环境中正确解析、Frontmatter 中的 name 和 description 被正确加载、Verification 步骤中的命令在目标环境中可用、渐进式上下文加载机制在长链中有效工作。首次部署后应在非关键路径任务上进行小规模验证。
技能链式组合的本质是将工程判断编码为可执行的流程。当这套流程被正确实现时，AI 代理不再只是生成代码的工具，而是遵循工程纪律的完整参与者。它知道什么时候该写规格文档、什么时候该写测试、什么时候该停下来进行对抗性审查、什么时候可以安全部署。这种纪律性是生产级可靠性的真正来源。
资料来源：addyosmani/agent-skills，包含 22 个技能定义及完整的生命周期工作流设计；using-agent-skills 元技能定义了技能发现与动态组合的决策树模型；planning-and-task-breakdown 提供了依赖解析与垂直切片的方法论；doubt-driven-development 实现了非平凡决策的对抗性审查机制。
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。