如何安全使用 OpenAI Skills

可复用的智能体工作流可以从一个提示词开始，但重复工作很快会暴露在不同对话之间复制指令的局限。重要步骤会被遗漏，输出格式会漂移，流程背后的推理也会变得难以审查。OpenAI skill 通过将操作说明和支持材料放入可版本控制、可检查的结构化文件夹来解决这一问题。

这种便利不应被误认为安全边界。一个 skill 可以影响智能体选择哪些工具、读取哪些文件、运行哪些脚本，以及联系哪些外部服务。因此，安全采用需要两类审查：将工作流作为可读知识来评估，并将其可能执行的操作作为软件供应链输入来评估。

本指南说明这一格式、它在 OpenAI 插件中的位置、可移植性的真实限制，以及用于判断某个 skill 应用于个人试验还是获批准生产环境的实用流程。

了解你正在安装的单元

开放的 Agent Skills 规范 将 skill 定义为以 SKILL.md 文件为中心的目录。该文件使用 YAML 元数据记录 skill 名称和描述等字段，后面是 Markdown 说明。可选目录可存放工作流所需的脚本、参考资料、资产、模板、模式或其他资源。

这种结构有意保持朴素。名称和描述帮助兼容的智能体发现 skill 何时可能适用。工作流激活时可以加载完整说明，而更大的支持资源在需要前保持可用。这种渐进式加载使许多专门流程可以访问，而无需将每条说明放入每一次对话。

因此，skill 不只是保存下来的提示词。它可以定义输入、有序步骤、所需证据、输出约束、失败条件和验收检查。审查 skill 可能要求检测框架、执行测试、安全检查和固定报告。发布 skill 可能要求完整元数据、经验证来源、图像来源信息和发布前验证。

该格式也将通用模型能力与本地流程分开。领域专家可以用可读说明表达判断，工程师则可在精确行为重要时添加确定性脚本。两部分都能在版本控制中审查。OpenAI Academy 的 skills 指南 将这种复用描述为不必从头解释同一重复流程的方法。

将发现元数据视为可执行路由

SKILL.md 中的描述不是装饰性文案。它经常帮助智能体判断 skill 是否匹配当前任务。过于宽泛的描述可将无关工作路由进该流程；含糊的描述可在需要 skill 时阻止激活。两种失败都会在人看到详细说明前改变智能体的行为。

应像审查步骤一样仔细审查名称和描述。它们应说明 skill 的作用、触发它的情形以及有意义的排除项。如果一个工作流编辑电子表格却不应控制实时 Excel 会话，该边界应写入发现语言。如果它只能在明确批准后发布内容，该条件必须毫不含糊。

然后检查指令层级。skill 不会仅因被激活就获得权限。用户意图、平台政策、沙箱限制、项目规则和批准要求仍然适用。要求智能体忽略这些控制的说明，是拒绝该包的理由，而不是绕过它们的捷径。

将 skill 与其插件容器分开

OpenAI 原始的 skills 目录 已弃用，并引导开发者转向当前的插件示例和指南。这是分发方式的变化，并不表明底层 skill 格式已经消失。核心指令单元仍可为 SKILL.md 文件夹，而可安装产品成为插件。

根据 OpenAI 的插件打包指南，插件根目录必须有 .codex-plugin/plugin.json 清单。该包可将 skills 与 MCP 服务器定义、应用、命令、钩子、智能体元数据和资产一同包含。说明和捆绑资源足够时，仍可使用仅含 skill 的插件。

这一区别在设定范围时很有用。skill 描述可重复的流程。插件可提供分发和运行该流程所需的更广泛能力，包括外部工具、认证要求、界面元素和包元数据。插件是安装边界；skill 仍是其中一个组件。

对于新的 OpenAI 相关分发，应遵循当前插件路径，而不要围绕已弃用目录建立安装流程。在实际可行处，将工作流本身保留在符合标准的 skill 中。这样可将持久说明与宿主专属集成分开，并让日后审查或迁移更容易。

精确理解可移植性

纯 Markdown、较小的必需模式和可选资源文件夹，使 skills 更容易在兼容智能体之间移动。该规范提供共同布局，而可读文件很适合熟悉的版本控制和代码审查做法。这是指令层面有意义的可移植性。

这并不保证同一文件夹在所有地方表现相同。宿主可能以不同方式解释可选元数据。工具名称、操作系统、依赖项、文件系统路径、连接器、上下文限制和批准流程都可能不同。调用本地命令的工作流不会自动在纯浏览器环境中运行。需要私有数据的工作流在没有可用连接器和适当授权时会失败。

分层评估可移植性：

1. 核心流程： 另一兼容宿主能否理解目标、顺序、输入和输出契约？
2. 捆绑资源： 文件引用是否相对、已记录，并随 skill 提供？
3. 运行时假设： 命令、包、操作系统要求和失败信息是否明确？
4. 已连接操作： 哪些工具、认证方式和界面专属于一个宿主或插件？
5. 行为结果： 工作流是否会在每个预定环境中一致地激活并完成代表性任务？

良好设计将持久流程保留在 skill 中，并将产品专属连接器、界面元数据、权限和安装行为置于外围包中。这不能让每项操作都可移植，但能防止偶然的集成细节遮蔽可复用知识。

按后果而非文件类型审查权限

可读 Markdown 比不透明二进制文件更易检查，但说明仍可能导致有后果的工具使用。相关问题不只是包是否包含代码。应问它能说服或指示智能体做什么。

将每项请求的能力映射到具体步骤。文件读取权限可能是文档分析所必需的，但广泛写入权限不是。网络访问可能有研究工作流的正当理由，而访问凭据或无关服务则没有。能够发送消息、发布内容、改变生产系统或删除数据的工具，应有明确确认边界。

脚本需要直接检查。检查每个可执行文件和支持文件，而不只检查 SKILL.md。识别命令、依赖项、环境变量、网络目的地、文件路径和任何改变外部状态的操作。优先采用完成预定任务的最小权限集，并在允许访问有价值系统前使用一次性数据或沙箱测试。

还要检查间接输入。参考资料、抓取页面和已连接数据可包含自身说明。安全工作流应将这些材料当作要分析的内容，而不是更高优先级的权威。包说明应表明不可信内容从何处进入，以及智能体必须如何处理它。

将 skills 作为供应链依赖项管理

公共仓库的受欢迎程度并非安全审查、生产可靠性或成功采用的证据。恶意或被入侵的 skill 可能试图获取机密、修改文件、联系意外服务，或通过脚本和参考资料扩大范围。良性工作流也可能在更新后变得有风险，或在 API、产品界面或合规规则变化时过时。

安装前记录来源：发布者、仓库、精确修订版或版本、许可证、审查日期和获批准文件。安装方式允许时，固定经审查的修订版。不要仅因更新较新就接受它；检查差异、重新运行评估用例，并重新评估任何权限变化。

生命周期信号也很重要。旧 OpenAI skills 仓库尽管其通知称已弃用，仍可访问。搜索结果和已保存链接可能比首选安装路径存续更久。不要因包可访问就假定它仍在维护；应检查仓库通知和当前文档。定义团队在其来源被入侵或行为改变时如何禁用、替换或回滚 skill。

对于组织使用，所有权必须明确。应有人负责更新、兼容性、测试用例和退役。将批准的包存放在受控位置，保留审计轨迹，并将试验与智能体可在生产工作中激活的集合分开。

批准前运行分阶段评估

有效目录只证明文件被正确排列。它并不表明激活可靠、说明安全或结果有用。使用具有代表性任务和明确通过条件的分阶段评估。

1. 确定目的和边界

写下重复任务、预定用户、可接受输入、预期输出，以及必须保持在范围外的操作。决定更好的说明是否已足够，还是工作流确实需要带工具和连接服务的插件。从解决问题的最小能力开始。

2. 审计每个包组件

阅读清单、SKILL.md、脚本、参考资料、资产和配置。验证链接和依赖项符合所述目的。搜索机密访问、破坏性命令、意外网络调用、绝对本地路径、隐藏下载和绕过批准或政策的说明。

3. 建立明确的权限映射

列出每个工具和数据源、它启用的操作、访问是只读还是会更改状态，以及何时需要人工确认。移除没有对应工作流步骤的能力。评估时使用受限凭据和沙箱资源。

4. 测试路由和正常行为

创建应触发 skill 的代表性任务，以及不应触发的相邻任务。检查描述是否正确路由工作。对于正向案例，验证所需步骤、证据、输出格式和验收检查，而不要只判断最终答案听起来是否合理。

5. 测试失败和拒绝行为

尝试缺失输入、不可用工具、无效文件、冲突说明和超出范围的请求。skill 应清楚停止、保留数据并请求必要决定，而不是即兴获得权限。确认不可信内容不能悄然重定义工作流。

6. 在声称可移植处测试可移植性

在每个预定宿主运行相同用例。记录核心说明哪些部分可以迁移，哪些集成需要调整。只有其内部 skill 符合标准时，不要将完整插件标为可移植。

7. 批准修订版并监控变化

固定已评估版本，记录结果和已知限制，指定负责人并设定审查间隔。在说明、脚本、权限、依赖项、工具或宿主行为变化后重新评估。保留回滚路径和明确退役流程。

使用最小的可信层

skills 很有价值，因为它们使重复的操作知识可见、可复用且可审查。当工作流需要安装元数据、工具、认证、界面或组织控制时，插件增加实用交付层。两层默认都不安全，两者也都不能消除对宿主强制权限的需求。

持久的方法是保持核心流程可读，隔离产品专属集成，只授予每一步所需访问权限，并测试行为而非仅测试语法。当来源、权限、评估用例、所有权和回滚一并记录时，skill 就成为受治理的工作流，而非未经检查的指令包。