Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
Loading
本指南面向需要在整个组织中治理 Agent Skills 的企业管理员和架构师。它涵盖了如何大规模审查、评估、部署和管理 Skills。有关编写指南，请参阅最佳实践。有关架构详情，请参阅 Skills 概述。
在企业中部署 Skills 需要回答两个不同的问题：
在批准部署之前，根据以下风险指标评估每个 Skill：
| 风险指标 | 需要关注的内容 | 关注级别 |
|---|---|---|
| 代码执行 | Skill 目录中的脚本（*.py、*.sh、*.js） | 高：脚本以完整的环境访问权限运行 |
| 指令操纵 | 指示忽略安全规则、对用户隐藏操作或有条件地改变 Claude 行为的指令 | 高：可能绕过安全控制 |
| MCP 服务器引用 | 引用 MCP 工具的指令（ServerName:tool_name） | 高：将访问范围扩展到 Skill 本身之外 |
| 网络访问模式 | URL、API 端点、fetch、curl 或 requests 调用 | 高：潜在的数据外泄途径 |
| 硬编码凭据 | Skill 文件或脚本中的 API 密钥、令牌或密码 | 高：机密信息暴露在 Git 历史记录和上下文窗口中 |
| 文件系统访问范围 | Skill 目录之外的路径、宽泛的 glob 模式、路径遍历（../） | 中：可能访问非预期的数据 |
| 工具调用 | 指示 Claude 使用 bash、文件操作或其他工具的指令 | 中：审查执行了哪些操作 |
在部署来自第三方或内部贡献者的任何 Skill 之前，请完成以下步骤：
http、requests.get、urllib、curl、fetch）。切勿在未经完整审计的情况下部署来自不受信任来源的 Skills。恶意 Skill 可以指示 Claude 执行任意代码、访问敏感文件或向外部传输数据。对待 Skill 安装应与在生产系统上安装软件一样严格。
如果 Skills 触发不正确、与其他 Skills 冲突或提供不良指令，可能会降低代理性能。在任何生产部署之前都应要求进行评估。
在部署任何 Skill 之前，为以下维度建立审批关卡：
| 维度 | 衡量内容 | 失败示例 |
|---|---|---|
| 触发准确性 | Skill 是否在正确的查询时激活，并在无关查询时保持不激活？ | Skill 在每次提到电子表格时都触发，即使用户只是想讨论数据 |
| 隔离行为 | Skill 单独运行时是否正常工作？ | Skill 引用了其目录中不存在的文件 |
| 共存性 | 添加此 Skill 是否会降低其他 Skills 的性能？ | 新 Skill 的描述过于宽泛，抢占了现有 Skills 的触发 |
| 指令遵循 | Claude 是否准确遵循 Skill 的指令？ | Claude 跳过验证步骤或使用了错误的库 |
| 输出质量 | Skill 是否产生正确、有用的结果？ | 生成的报告存在格式错误或数据缺失 |
要求 Skill 作者提交评估套件，每个 Skill 包含 3–5 个代表性查询，涵盖 Skill 应该触发、不应该触发以及模糊边缘情况。要求在您组织使用的各个模型（Haiku、Sonnet、Opus）上进行测试，因为 Skill 的有效性因模型而异。
有关构建评估的详细指南，请参阅最佳实践中的评估与迭代。有关通用评估方法，请参阅开发测试用例。
评估结果可以指示何时采取行动：
规划
识别重复性高、容易出错或需要专业知识的工作流程。将这些映射到组织角色，并确定哪些适合作为 Skills 的候选。
创建与审查
测试
要求进行隔离评估（Skill 单独运行）以及与现有 Skills 一起的评估（共存测试）。在批准投入生产之前，验证触发准确性、输出质量以及在您的活跃 Skill 集中没有回归。
部署
通过 Skills API 上传以实现工作区范围的访问。有关上传和版本管理，请参阅通过 API 使用 Skills。在您的内部注册表中记录该 Skill 的用途、所有者和版本。
监控
跟踪使用模式并收集用户反馈。随着工作流程和模型的演变，定期重新运行评估以检测漂移或回归。目前无法通过 Skills API 获取使用分析。实施应用程序级日志记录以跟踪哪些 Skills 被包含在请求中。
迭代或弃用
在推广新版本之前，要求完整的评估套件通过。当工作流程发生变化或评估分数下降时更新 Skills。当评估持续失败或工作流程被淘汰时弃用 Skills。
作为一般准则，限制同时加载的 Skills 数量以保持可靠的召回准确性。每个 Skill 的元数据（名称和描述）都会在系统提示中争夺注意力。当激活的 Skills 过多时，Claude 可能无法选择正确的 Skill 或完全遗漏相关的 Skill。在添加 Skills 时使用您的评估套件来衡量召回准确性，并在性能下降时停止添加。
请注意，API 请求每次最多支持 8 个 Skills（请参阅通过 API 使用 Skills）。如果某个角色需要的 Skills 数量超过单个请求所支持的数量，请考虑将范围较窄的 Skills 合并为更宽泛的 Skills，或根据任务类型将请求路由到不同的 Skill 集。
鼓励团队从范围窄、针对特定工作流程的 Skills 开始，而不是宽泛的多用途 Skills。随着组织中模式的显现，将相关的 Skills 合并为基于角色的捆绑包。
使用评估来决定何时合并。只有当合并后的 Skill 的评估确认其性能与它所替代的各个 Skills 相当时，才将范围窄的 Skills 合并为更宽泛的 Skill。
示例演进过程：
formatting-sales-reports、querying-pipeline-data、updating-crm-recordssales-operations（当评估确认性能相当时）在整个组织中使用一致的命名约定。最佳实践中的命名约定部分提供了格式指南。
为每个 Skill 维护一个内部注册表，包含：
按组织角色对 Skills 进行分组，以保持每个用户的活跃 Skill 集聚焦：
每个基于角色的捆绑包应仅包含与该角色日常工作流程相关的 Skills。
将 Skill 目录存储在 Git 中，以实现历史跟踪、通过拉取请求进行代码审查以及回滚能力。每个 Skill 目录（包含 SKILL.md 和任何捆绑文件）自然地映射到一个由 Git 跟踪的文件夹。
Skills API 提供工作区范围的分发。通过 API 上传的 Skills 可供所有工作区成员使用。有关上传、版本控制和管理端点，请参阅通过 API 使用 Skills。
自定义 Skills 不会跨平台同步。上传到 API 的 Skills 在 claude.ai 或 Claude Code 中不可用，反之亦然。每个平台都需要单独的上传和管理。
将 Skill 源文件保存在 Git 中作为唯一的真实来源。如果您的组织在多个平台上部署 Skills，请实施您自己的同步流程以保持它们的一致性。有关完整详情，请参阅跨平台可用性。
Was this page helpful?