智能体技能通过文件形式，将可重复使用的工程任务封装起来，方便团队审查和复用；而工具、项目上下文和权限则由运行这些技能的宿主环境决定。

这周，你有多少次向智能体重复解释同一项任务？又有多少次向那位拥有丰富组织经验的同事请教如何解决某个具体问题？这些上下文信息不应该随着聊天结束而丢失，也不应该只存在于某一个人的脑海中。智能体技能可以帮助你记录可重复使用的指令，让你和智能体都能反复调用。你今晚为自己编写的技能，日后也可能成为团队工作流的一部分。

智能体技能是一个经过版本管理的目录，其核心是一个 SKILL.md 文件，用于描述何时以及如何执行一项可重复的任务。你可以在不同的智能体之间共享这些指令，但执行环境仍然需要提供相应的工具、凭据和权限。例如，技能可以描述如何查询数据库，但它本身并不会授予访问该数据库的权限。

在 GitHub Universe 2026 期间，我与 Procore 数据工程高级经理 Shishir Tewari 进行了现场分享，探讨了这一主题。我们的分享主题是 “一次构建，适用于任何智能体：智能体技能实用指南”。

明确一项任务及其适用场景

一项技能要发挥最佳效果，需要有明确的任务、输入和输出。例如，假设你正在构建一个智能体，用于检查 AI 生成的代码变更是否符合最初的需求。如果让同一个智能体评估自己的工作，它给出的解释就可能影响审查结果。借助 Proof Agent，我们使用一个独立的验证器来检查代码变更，并为其判断结果提供证据。技能的 frontmatter 会指定任务名称并描述其用途：

---
name: proof-agent
description: Adversarial verification of AI-generated work. Spawns an independent verifier to check for false claims, broken code, and security issues.
---

其核心遵循一条简单的原则：自我验证不等于验证。

Proof Agent 的 SKILL.md 中的 When to Verify 部分，说明了何时应该调用这项技能。其余指令则解释了验证器需要审查哪些内容，以及在输出审查结果时需要包含哪些证据。

协调多项技能，构建更大型的工作流

当一个数据管道能否正确运行所依赖的判断经验，分别掌握在四个人手中时，这四个人就成了项目推进的关键。管道的每一次变更，都取决于他们是否有时间参与，以及他们对数据的了解程度。Data Forge 展示了如何将这些判断经验中的一部分沉淀为多项协同工作的技能。

在这个 支持服务台管道示例 中，我们从一项指标需求开始：统计已创建和已解决的事件数量。在构建管道之前，forge-init 技能会先收集源数据表、命名规范等信息，然后将这些信息写入一个已解析的清单文件。其他技能则通过读取该清单，获取所需的项目上下文。

随后，forge-builder 技能会协调从问题提出到创建拉取请求的整个过程。在设计和构建管道时，它会使用 forge-dbx 查询数据平台，并使用 forge-lint 应用团队的规范。整个过程中，人员可以对拟定的决策进行审查。最终生成的拉取请求包含管道代码、架构变更和测试。

每项技能都有明确的职责，它们通过共享项目上下文协同工作，而不是各自独立地重新收集信息。当某个步骤发生变化时，你只需要修改对应的技能，而不必影响其他部分。

技能适用于边界明确、可重复执行，并且能够从可复用经验中受益的工作，例如检查清单、版本发布、迁移任务或指标管道。如果某个工作流需要稳定的接口、共享状态、审计跟踪、长时间运行的控制能力，或者需要在模型之外强制执行权限，那么使用应用程序会是更合适的选择。

将项目配置与技能分离

我们不希望将每个项目的名称、数据库或约定都硬编码到技能中。在 Data Forge 的支持服务台示例中，我们使用一个 manifest 来描述项目、指标存储和平台。这样，技能就能获取正确的项目详情，而不必将这些信息直接写入指令中：

project:
  name: "support-desk"
  store_name: "support_metric_store"

platform:
  engine: "duckdb"
  pipeline_framework: "spark_python"
  duckdb_dir: "warehouse"

当相关信息被收集并写入已解析的清单后，其他技能就不必再自行猜测项目配置。

应当将收集到的项目详情与团队规范分开管理。初始化技能 forge-init 可以检查现有的架构和代码模式；而 forge-lint 技能则负责提供代码生成前需要遵循的规则。在代码仓库中发现的某种模式，并不意味着它就一定是需要保留的规则。因此，应确保收集到的信息可以被审查，并在涉及业务判断时允许人员进行确认或修改。要验证技能是否具有可移植性，可以思考一个问题：另一个团队能否使用自己的 manifest 来运行这些技能，而不需要重写它们？

在不同技能之间共享执行路径

forge-dbx 技能为其他 Data Forge 技能提供了一种访问数据平台的统一方式。它会读取 manifest，并选择 Databricks 或 DuckDB 适配器，这样每项技能就不必各自实现连接和查询逻辑。

manifest 可以为本地支持服务台演示项目选择 DuckDB，但它无法安装 DuckDB CLI，也无法授予数据库访问权限。这些仍然属于运行环境及其使用者的配置职责。manifest 负责选择引擎，宿主环境负责提供访问能力。

在工作流中设置检查和审批节点

Data Forge 的支持服务台工作流包含七个阶段，每个阶段都设置了一个人工检查节点。工作流概览 展示了这些技能如何协同工作。在进入下一阶段之前，工作流会检查上一阶段是否已经完成；在执行架构变更之前，则会请求审批。

Proof Agent 示例将同样的原则应用到了代码审查中。GitHub Actions 工作流会向验证器提供最初的需求和代码变更，但不会提供编码智能体自己的评估结果。验证器会返回 PASS、FAIL 或 PARTIAL，并且必须引用变更文件中的证据来支持自己的判断。GitHub Action 会对代码差异进行静态审查，但不会执行代码或运行测试。在演示工作流中，我们将 block-on-fail: false 设置为 false，使审查结果仅作为参考建议。默认情况下，FAIL 会导致检查失败；如果该检查被设置为必需检查，就会阻止代码合并。我们的目标是将测试结果和合并要求保留在代码仓库的 CI 检查与规则中。

为不同的智能体客户端打包，并验证其配置

要支持多个客户端，可能意味着需要维护多份相同的指令，并确保它们始终保持同步。在 Data Forge 示例中，我们将 skills/*/SKILL.md 作为源文件，并使用一个打包脚本生成适用于不同客户端的文件：

• .claude-plugin/plugin.json：用于 Claude Code。

• .cursor-plugin/plugin.json：用于 Cursor。

• .github/agents/*.agent.md：用于 GitHub Copilot。

该脚本还包含一种检查模式，可供 CI 使用：

node scripts/package.mjs --check

不同客户端在可用模型、工具、凭据和权限方面可能存在差异。安装技能后，需要检查客户端是否能够针对预期任务识别该技能、加载其引用内容、使用所需工具，以及按照技能要求返回相应的证据。

构建智能体技能的三项实践建议

1. 将业务上下文集中在一个文件中。 将项目特定的名称、架构和约定保存在 manifest 中，让每项技能读取该文件，而不是重复记录这些信息。这样，团队就有了一个统一且可见的配置更新位置。

2. 让相关技能通过统一方式使用平台。 让相关技能通过相同的路径执行查询、任务和架构变更，而不是让每项技能分别定义自己的命令和连接逻辑。这样既能让工作流的访问方式更容易理解，也能更方便地检查它在不同客户端中的运行行为。

3. 用指令引导工作，用检查验证结果。 技能可以告诉智能体应该遵循哪些规范，以及何时需要请求审批。在需要上下文信息或人工判断的决策环节加入人工审查，并通过测试和 CI 检查，在变更进入下一阶段之前发现问题。如果某项检查必须阻止代码合并或部署，则应在代码仓库的规则中配置相应要求。

不妨从那项让你厌倦了一遍遍解释的任务开始。记录它需要什么、执行到哪里应该停止，以及审查人员需要看到什么。然后尝试让另一个智能体执行这项任务，并根据实际效果不断改进。

将智能体技能添加到 GitHub Copilot >