企业级 Skills

本指南面向需要在组织范围内治理 Agent Skills 的企业管理员和架构师。内容涵盖如何大规模审核、评估、部署和管理 Skills。有关编写指南，请参阅最佳实践。有关架构详情，请参阅 Skills 概述。



安全审查与审核

在企业中部署 Skills 需要回答两个不同的问题：

1. Skills 总体上是否安全？ 请参阅概述中的安全注意事项部分，了解平台级安全详情。
2. 如何审核特定的 Skill？ 请使用下方的风险评估和审查清单。



风险等级评估

在批准部署之前，请根据以下风险指标评估每个 Skill：



审查清单

在部署来自第三方或内部贡献者的任何 Skill 之前，请完成以下步骤：

1. 阅读所有 Skill 目录内容。 审查 SKILL.md、所有引用的 markdown 文件以及任何捆绑的脚本或资源。
2. 验证脚本行为与声明的用途相符。 在沙盒环境中运行脚本，并确认输出与 Skill 的描述一致。
3. 检查是否存在对抗性指令。 查找指示 Claude 忽略安全规则、对用户隐藏操作、通过响应泄露数据或根据特定输入改变行为的指令。
4. 检查是否存在外部 URL 获取或网络调用。 在脚本和指令中搜索网络访问模式（http、requests.get、urllib、curl、fetch）。
5. 验证没有硬编码凭据。 检查 Skill 文件中是否存在 API 密钥、令牌或密码。凭据应使用环境变量或安全凭据存储，绝不应出现在 Skill 内容中。
6. 识别 Skill 指示 Claude 调用的工具和命令。 列出所有 bash 命令、文件操作和工具引用。当 Skill 同时使用文件读取和网络工具时，请考虑其组合风险。
7. 确认重定向目标。 如果 Skill 引用了外部 URL，请验证它们指向预期的域名。
8. 验证不存在数据泄露模式。 查找读取敏感数据然后将其写入、发送或编码以进行外部传输的指令，包括通过 Claude 的对话响应进行传输。



部署前评估 Skills

如果 Skills 触发不正确、与其他 Skills 冲突或提供了不良指令，可能会降低智能体的性能。在任何生产部署之前都应要求进行评估。



评估内容

在部署任何 Skill 之前，请针对以下维度建立审批关卡：



评估要求

要求 Skill 作者为每个 Skill 提交包含 3-5 个代表性查询的评估套件，涵盖 Skill 应触发的情况、不应触发的情况以及模糊的边缘情况。要求在您的组织使用的各个模型（Haiku、Sonnet、Opus）上进行测试，因为 Skill 的有效性因模型而异。

有关构建评估的详细指南，请参阅最佳实践中的评估与迭代。有关通用评估方法，请参阅开发测试用例。



使用评估进行生命周期决策

评估结果可以指示何时采取行动：

• 触发准确性下降： 更新 Skill 的描述或指令
• 共存冲突： 合并重叠的 Skills 或缩小描述范围
• 输出质量持续偏低： 重写指令或添加验证步骤
• 多次更新后仍持续失败： 弃用该 Skill



Skill 生命周期管理



大规模组织 Skills



召回限制

作为一般准则，请限制同时加载的 Skills 数量，以保持可靠的召回准确性。每个 Skill 的元数据（名称和描述）都会在系统提示中争夺注意力。如果激活的 Skills 过多，Claude 可能无法选择正确的 Skill 或完全遗漏相关的 Skills。在添加 Skills 时，使用您的评估套件来衡量召回准确性，并在性能下降时停止添加。

请注意，API 请求每次最多支持 8 个 Skills（请参阅通过 API 使用 Skills）。如果某个角色需要的 Skills 数量超过单个请求所支持的数量，请考虑将范围较窄的 Skills 合并为范围更广的 Skills，或根据任务类型将请求路由到不同的 Skill 集合。



从具体开始，后续再整合

鼓励团队从范围较窄、针对特定工作流程的 Skills 开始，而不是从宽泛的多用途 Skills 开始。随着组织内模式的显现，将相关的 Skills 整合为基于角色的组合包。

演进示例：

• 起始：formatting-sales-reports、querying-pipeline-data、updating-crm-records
• 整合：sales-operations（当评估确认性能相当时）



命名与编目

在整个组织中使用一致的命名约定。最佳实践中的命名约定部分提供了格式指南。

为每个 Skill 维护一个内部注册表，包含以下信息：

• 用途：该 Skill 支持的工作流程
• 负责人：负责维护的团队或个人
• 版本：当前部署的版本
• 依赖项：所需的 MCP 服务器、软件包或外部服务
• 评估状态：最近的评估日期和结果



基于角色的组合包

按组织角色对 Skills 进行分组，使每个用户的活跃 Skill 集合保持聚焦：

• 销售团队：CRM 操作、销售管道报告、提案生成
• 工程团队：代码审查、部署工作流程、事件响应
• 财务团队：报告生成、数据验证、审计准备

每个基于角色的组合包应仅包含与该角色日常工作流程相关的 Skills。



分发与版本控制



源代码控制

将 Skill 目录存储在 Git 中，以实现历史记录跟踪、通过拉取请求进行代码审查以及回滚能力。每个 Skill 目录（包含 SKILL.md 和任何捆绑文件）都可以自然地映射到一个由 Git 跟踪的文件夹。



基于 API 的分发

Skills API 提供工作区范围的分发。通过 API 上传的 Skills 可供所有工作区成员使用。有关上传、版本控制和管理端点，请参阅通过 API 使用 Skills。



版本控制策略

• 生产环境：将 Skills 固定到特定版本。在推广新版本之前运行完整的评估套件。将每次更新视为需要完整安全审查的新部署。
• 开发和测试环境：使用最新版本，以便在推广到生产环境之前验证更改。
• 回滚计划：保留上一个版本作为后备。如果新版本在生产环境中未通过评估，请立即恢复到最后一个已知良好的版本。
• 完整性验证：计算已审查 Skills 的校验和，并在部署时进行验证。在您的 Skill 代码仓库中使用签名提交以确保来源可信。



跨平台注意事项

将 Skill 源文件保存在 Git 中作为唯一可信来源。如果您的组织跨多个平台部署 Skills，请实施您自己的同步流程以保持它们的一致性。有关完整详情，请参阅跨平台可用性。



后续步骤