正文 · AI 翻译
这周，你有多少次向智能体重复解释同一项任务？你又有多少次向深谙机构内部情况的同事请教如何解决某个具体问题？这些背景信息不该消失在聊天记录里，也不该只留在一个人的脑海中。智能体技能让你能够记录可重复使用的指令，供你和智能体反复使用。你今晚为自己编写的技能，以后可能成为团队工作流程的一部分。智能体技能是一个以 SKILL.md 文件为核心、受版本控制的目录，该文件说明何时以及如何执行一项可重复的任务。你可以在不同智能体之间共享这些指令，但运行环境仍需提供执行指令所需的工具、凭据和权限。例如，技能可以说明如何查询数据库，但不会因此授予数据库访问权限。我在 GitHub Universe 2026 期间与 Procore 数据工程高级经理 Shishir Tewari 现场讨论了这个话题。我们的会议题为“构建一次，适用于任何智能体：智能体技能实用指南”。明确一项任务及其适用时机 当技能有明确的任务、输入和输出时，效果最好。例如，假设你正在构建一个智能体，用来核对 AI 生成的改动是否符合原始请求。如果由同一个智能体评估自己的工作，它自己的解释可能会影响审查结果。使用 Proof Agent 时，我们会让一个独立的验证智能体检查改动，并为其发现提供证据。技能的前置元数据列出任务名称并说明其用途：--- name: proof-agent description: 对 AI 生成的工作进行对抗性验证。启动独立的验证智能体，检查不实说法、代码缺陷和安全问题。--- 核心是一条简单的规则：自我验证不算验证。Proof Agent 的 SKILL.md 中的“When to Verify”部分说明何时调用该技能。其余指令说明验证智能体要审查什么，以及其发现中应包含哪些证据。协调多个技能以完成更大的工作流程 如果决定数据流水线是否正确所需的判断分散在 4 个人的脑海中，那么这 4 个人就决定了工作推进的路径。流水线的每次改动都取决于他们是否有空，以及他们对数据的了解。Data Forge 展示了如何把其中一部分判断记录到相互协作的技能中。在服务台流水线示例中，我们从一个统计已创建和已解决事件数量的指标请求开始。在构建流水线之前，forge-init 技能会查明源表和命名约定等细节，然后将其写入已解析的清单。其他技能从该清单中读取所需的项目背景信息。随后，forge-builder 技能协调从议题到拉取请求的工作。设计和构建流水线时，它使用 forge-dbx 查询数据平台，并使用 forge-lint 应用团队标准。整个过程中，有人会审查拟定的决策；最终的拉取请求包含流水线代码、架构变更和测试。每项技能都有明确的职责，并且共享项目背景信息，无需各自重新查找。某个步骤发生变化时，你可以只修改一项技能，其余技能保持不变。技能适合范围明确、可重复且能从复用判断中受益的工作，例如检查清单、发布、迁移或指标流水线。如果工作流程需要稳定的接口、共享状态、审计记录、长期运行的控制机制，或在模型之外强制执行的权限，应用程序会更合适。将项目配置放在技能之外 我们不希望把每个项目的名称、数据库或约定都硬编码到技能中。在 Data Forge 服务台示例中，一份清单描述了项目、指标存储和平台，让技能能够使用正确的项目细节，而无须把这些细节写死在指令里：project: name: "support-desk" store_name: "support_metric_store" platform: engine: "duckdb" pipeline_framework: "spark_python" duckdb_dir: "warehouse" 查明的细节写入已解析的清单后，其他技能就不必各自对项目作出假设。应将查明的项目细节与团队标准分开。forge-init 初始化技能可以检查现有架构和代码模式；forge-lint 技能则提供生成代码前要遵循的规则。在代码仓库中发现某种模式，并不意味着它自动成为应当保留的规则，因此应让查明的细节可供审查，并让人们在需要业务判断时确认或修改。要检查可移植性，可以问：另一个团队能否使用自己的清单来使用这些技能，而无须重写技能？让技能共享执行路径 forge-dbx 技能为其他 Data Forge 技能提供访问数据平台的统一方式。它读取清单并选择 Databricks 或 DuckDB 适配器，因此每项技能都不必自行实现连接和查询逻辑。清单可以为本地服务台演示选择 DuckDB，但无法安装 DuckDB CLI 或授予数据库访问权限。这些仍是运行环境及其用户负责的配置工作。清单选择引擎；宿主环境提供访问权限。在工作流程中设置检查和审批节点 Data Forge 服务台工作流程分为 7 个阶段，每个阶段都有人工检查节点。工作流程概览展示了各项技能如何协同。在进入下一阶段之前，工作流程会检查上一阶段是否完成；在执行架构变更之前，会请求批准。Proof Agent 示例将同一原则用于代码审查。GitHub Actions 工作流程会向验证智能体提供原始请求和代码改动，但不提供编码智能体对自身工作的评估。验证智能体返回 PASS、FAIL 或 PARTIAL，并且必须引用已修改文件中的证据。GitHub Action 对差异内容进行静态审查；它不执行代码，也不运行测试。在演示工作流程中，我们将 block-on-fail: false 设为关闭阻断，使审查发现仅供参考。默认情况下，FAIL 会使检查失败；如果该检查是必需检查，就会阻止合并。目的是把测试结果和合并要求保留在代码仓库的 CI 检查与规则中。针对每种智能体客户端打包，然后验证其配置 支持多个客户端可能意味着需要同步多份相同的指令。在 Data Forge 示例中，我们以 skills/*/SKILL.md 为源文件，使用打包脚本生成针对各客户端的文件：供 Claude Code 使用的 .claude-plugin/plugin.json、供 Cursor 使用的 .cursor-plugin/plugin.json，以及供 GitHub Copilot 使用的 .github/agents/*.agent.md。该脚本还提供供 CI 使用的检查模式：node scripts/package.mjs --check。不同客户端可用的模型、工具、凭据和权限可能不同。安装技能后，应检查客户端能否在预期任务中识别它、加载其引用资料、使用所需工具，并返回技能要求的证据。构建智能体技能的 3 项实践 将业务背景信息放在一个文件中。把项目特定的名称、架构和约定保存在清单里，让每项技能读取清单，而不是重复记录这些事实。这样团队就有一个清晰可见的配置更新位置。为相关技能提供一致的平台使用方式。让相关技能通过相同的路径运行查询、作业和架构变更，而不是各自定义命令和连接逻辑。这样一来，工作流程如何获得访问权限更容易理解，其在各客户端中的行为也更容易检查。用指令指导工作，用检查验证结果。技能可以告诉智能体应遵循哪些标准，以及何时请求批准。对于需要背景信息或判断的决策，加入人工审查；并使用测试和 CI 检查，在改动进入下一步之前发现问题。如果某项检查必须阻止合并或部署，就在代码仓库的规则中配置这一要求。从那项你已经厌倦反复解释的任务开始。写下它需要什么、在哪里结束，以及审查者会看到什么。然后用另一个智能体试用，并根据实践中了解到的情况加以改进。向 GitHub Copilot 添加智能体技能 > 文章《构建一次，适用于任何智能体：智能体技能实用指南》最先发表于 The GitHub Blog。