成为AI原生公司：从共享技能开始
建立共享技能能力，是迈向AI原生企业最便捷的第一步——将个人技能转化为版本化、可发现的团队资产，配以评估与遥测循环，即构成持续增值的护城河。
TLDR；建立共享技能能力，是迈向AI原生企业最便捷的第一步。本文是一份关于如何正确实施的实用指南。
引言
技能是代理工作流中最强大的方面之一，已成为机构知识的标准打包格式。将技能视为你的代理能够实际执行的SOP。
本指南涵盖了你需要了解的所有内容，以构建一个能在公司内部不断增值的共享技能库。
本指南涵盖技能是什么、如何（安全地）使用它们、在团队或公司范围内实施共享技能能力的选项、如何治理技能，以及真正价值所在。
技能是什么以及为何共享它们很重要
代理技能是程序性知识的便携包——可以将它们视为指令、脚本、参考资料、护栏等，教会代理可靠地完成一项聚焦任务。
基本上，任何重复性任务——“让这段代码更优秀”、“结清月末账目”、“以我们的品牌语调起草这份文案”——技能都会以非常详细的程度概述该任务应如何执行。
最大的差距在于，技能通常是在个人层面创建的，并未被视为公司内的关键资产或工件。
这意味着创建技能所做的工作并未被所有应该使用它的人所利用，或者多人重复造轮子，创建了同一技能的多种版本。
共享将技能转变为有版本、可发现的公司资产，并将游戏从单人模式转变为多人模式。这就是你作为团队或公司获得杠杆作用的地方，这通常是在成为AI原生企业道路上你能做的最简单的提升。
Hiten Shah 的观点认为，每家公司的首个 AI 战略应是技能库；Atlan 的框架指出，“技能之于程序性知识，正如函数之于逻辑”；而 Microsoft 的工作趋势指数中的“自有智能”概念，都从不同角度汇聚于同一点——你的私有技能库是一种能持续增值的自有智能。
先提个醒：护城河并非实际文件本身。SKILL.md 简单至极。真正持久的资产是私有库，以及围绕它的评估与遥测循环。更多内容见第 6 节。
开放技能标准
Agent Skills 格式由 Anthropic 创建——于 2025 年 10 月 16 日在其工程博客上宣布，随后于 2025 年 12 月 18 日作为独立开放标准发布在 agentskills.io，并附带参考验证器（skills-ref），位于 github.com/agentskills/agentskills。
该格式：
- 一个以技能命名的文件夹
- 必需的 SKILL.md：YAML 前置元数据 + Markdown 指令。仅名称和描述为必填字段；名称必须与文件夹一致，仅限小写连字符；描述最多 1,024 字符
- 可选的 scripts/、references/、assets/
- 可选前置元数据：许可证、兼容性、元数据，以及实验性的 allowed-tools
让组织级技能库切实可行的机制在于：代理启动时仅加载名称与描述（约100个令牌/技能），仅在激活时才拉取完整的SKILL.md正文（建议不超过5000个令牌），并按需读取捆绑文件。这意味着你可以携带数百个技能而不烧毁上下文窗口——对于试图控制令牌成本的企业来说至关重要。
这一格式已被几乎所有主流代理框架和智能体平台采纳，因此你投入时间创建技能库后，被新事物取代的风险极低。
安全——构建前请先阅读此节
如果你未采取适当预防措施就从互联网下载技能，技能会构成非常现实的攻击面。由于技能本质上是代理遵循的指令，在其中隐藏恶意意图是真实威胁。
基于两项独立研究，不良技能的基础发生率较高：
- Snyk的ToxicSkills研究（2026年2月5日，n=3,984个来自ClawHub和skills.sh的技能）：37%存在至少一个任意严重程度的安全缺陷，其中76个被确认为恶意。
- Liu等人，“野外代理技能”（学术研究，n=31,132个技能）：26%包含至少一种危险模式，且捆绑可执行脚本的技能比仅含指令的技能易受攻击的可能性高出2倍以上。
两点重要意见应塑造你的架构：
- 提示注入存在于SKILL.md的散文文本本身。无需代码执行——恶意指令只需进入代理的上下文窗口即可。
- 技能在模型推理内部运作，对监视MCP工具调用的API级可观测性不可见。你现有的代理监控可能完全看不到技能行为。
好的，这听起来可能有点吓人，但实际影响相当明确：像对待开源软件包一样对待技能（扫描、审查、固定版本），对任何包含 scripts/ 文件夹的内容进行额外审查，未经适当审查绝不从公共市场自动导入，并且每次审批都要求作者与审查者分离。
如果我下载任何外部技能，我个人会使用 Nvidia 的 SkillSpector。
最佳做法——自己构建技能，避免下载任何第三方技能。
4. 实施选项
A. 私有 GitHub 仓库（最简单的起点）
一个包含技能文件夹的私有仓库是免费的、支持版本控制、适用于所有读取标准的代理，并且通过 PR 审查提供治理，无需额外开销。添加 CI 进行 YAML 检查和秘密扫描，整个流程很快就能完善起来。
分发通过所使用的工具约定进行（.claude/skills/ 路径、插件市场、各种 CLI 安装器）——规范本身对安装机制不作规定。
流程如下：个人起草技能并提交 PR -> PR 接受审查 -> PR 合并 -> 下次会话时所有人都能获取。任何人都可以直接获取内部 GitHub 链接，交给代理并说“安装这个”。
缺点：如果没有人负责维护，这种方式管理技能可能导致技能逐渐过时，变成“技能墓地”，所以最好从第一天起就为每个技能指定维护者，并为流程加上一些治理措施（详见下一节）。
B. 企业工具（如果你想要真正的工具化）
如果你希望选择一个更稳健、专门为帮助团队/组织管理技能而设计的选项，那么这些工具可能值得关注。主要优势在于对共享技能的扫描、签名、访问控制和审计功能。
现在这类工具很多，我无法断言哪些是最好的，但以下是当前可供你探索的选项：
- JFrog 代理技能注册表 - 采用两阶段“零信任消费模型”，包含恶意代码与提示注入扫描、证明证据及可选签名。
- TrueFoundry 技能注册表 - 一次编写，跨代理附加；按需加载；支持 UI 或 CLI；具备版本控制与访问控制。
- Agentman - 提供团队/共享层级，细粒度权限包括仅使用（在不读取技能内部实现的情况下调用技能——对保护专有流程细节确实有用）。
- SkillRepo - 托管库，具备技能分级、按仓库版本范围管理及合规追踪功能。
- Scalefocus skilly - 提供自托管选项，实现“每个代理技能的单一受控中心”。
- Agent Skill Harbor - 采用 MIT 许可的开源选项，原生集成 GitHub，无服务器目录，附带扫描器及推荐/不鼓励/禁止分类。
C. 真实企业实施案例（直接借鉴这些）
有时你只想复制其他优秀公司的做法。幸运的是，许多公司已在 X 或公司博客上发布了他们的设置，因此有大量可供借鉴的内容。
- Anthropic 内部 - 根据他们自己的关于如何使用技能的帖子：内部活跃使用数百个技能，采用两级分发机制（从 git 仓库升级到内部插件市场），涵盖九个内部技能类别，并通过 PreToolUse 钩子遥测来测量哪些技能被触发、哪些受欢迎、哪些触发不足。最后一点至关重要——这是唯一观察到的企业对技能循环进行度量的实例，也是值得复制的模式。
- Red Hat - agentic-collections 包含 7 个技能包，约 68+ 项技能，编码了 RHEL/OpenShift/Ansible 的运维知识。他们的 Lola 包管理器 将技能、命令、代理指令和 MCP 服务器打包成版本化模块。
- WorkOS - workos/skills 采用了相当复杂的路由器-技能模式（2 个路由器技能，覆盖 40+ 个参考文件，涉及 AuthKit/SSO/RBAC）。根据 ZenML 案例研究 的生产使用情况：一个 CLI 安装程序，能检测框架并配置 AuthKit，生成招聘报告，进行代码审查，以及 Slack 到 Linear 的自动化。他们验证的评估实践是基线对比——在有无技能的情况下使用相同提示词，并评分差异。听起来复杂，但只需将文章扔给你的 LLM，说“帮我制定一个类似的计划”。
- CloudQuery - 基于 Joe Karlsson 的博客 关于个人技能仓库意外成为非技术营销团队事实上的内部工具。他的经验：坚持 CLAUDE.md 优先的纪律，指定维护负责人，并且他明确表示没有进行过严格测量。这是一个令人耳目一新的诚实观点。
运营 - 评估、版本控制、生命周期
如果你还没听过这句话，那现在记住：一切都要靠评估。这正是区分一个真正能在内部积累智能的技能库，和一个最终沦为偶尔有人翻翻的陈旧目录的关键所在。
评估
Anthropic 官方的 技能编写最佳实践 推荐采用评估驱动的开发方式：先不带技能运行智能体以发现差距，构建至少 3 个测试场景，建立无技能的基线，编写最简指令，再对照基线进行迭代。每个严肃的团队都用评估来衡量自身，否则你只是在凭感觉做事。
两个小建议：技能的有效性因模型而异（要在不同模型和层级上测试，而不只是默认配置），并且尽量用不同的模型来设计和测试，否则你可能会发现“Claude A”设计的东西，“Claude B”测起来没问题，但换到 ChatGPT 上就不太好使。最好用 Claude 来设计、用 ChatGPT 来测试（或者任何你偏好的模型组合），这样才能发现那些细微差别。
版本控制与生命周期
我找到的两个对技能治理最有帮助的框架：
- Atlan 的 7 步生命周期： # 从业者 2026 治理指南
- AWS Well-Architected Agentic AI Lens（AGENTOPS03-BP01）：定义清晰的智能体生命周期，包含明确的 SME 所有权、测试和治理
直接读一读这些资料，或者至少把它们作为参考指南喂给你的智能体去遵循。
度量 - 坦诚面对现状
我尚未见到针对内部技能共享的严谨、有方法论支撑的采用率或时间节省指标。最接近真正方法的是WorkOS的有/无技能增量评分和Anthropic的钩子遥测。如果你在库中构建使用情况检测，你很可能拥有比行业目前发布的大多数数据更好的数据，因此这是进入领先地位的方式。
技能与MCP，以及护城河真正所在
按照Anthropic自身的框架：MCP将代理连接到数据和系统；技能教它如何处理这些数据和系统。访问提供上下文，技能提供判断力。
实际规则是，任何需要实时数据或认证操作的都是MCP服务器，任何编码程序或标准的都是技能，而成熟的技能通常会在过程中调用MCP工具。
关于护城河：技能文件是每个人都能看到的产物，因此很容易将库视为资产。真正复合的是库加上证明每个技能有效的评估套件、显示哪些技能实际触发的遥测，以及将使用反馈回修订的改进循环。
这个循环正是Anthropic用钩子对技能进行检测的原因，也是我在4B中提到的注册表供应商试图掌控控制平面的原因——护城河全在于数据。
入门路线图
- 采用开放的 SKILL.md 标准。别试图另辟蹊径搞些花哨的东西。
- 搭建一个私有 git 仓库。PR 审查就是你的第一天治理机制。这是最简单的起步方式。
- 从领域专家那里试点 5-10 个高价值技能——否则这些知识就会随他们流失。每个技能指定一名负责人。
- 从第一天起就编写评估：无技能基线、每个技能至少 3 个场景、每次变更后重新运行。这是最容易被跳过的一步，却也是最关键的一步。
- 扫描所有内容（如果使用任何外部技能，就用 Nvidia 的 SkillSpector），对捆绑脚本的技能要格外严格审查。作者绝不能兼任审查者。
- 在扩展之前先做好使用监控（接入遥测）。你看不到的东西就无法治理，而且你会比大多数使用技能的公司拥有更好的采用数据。
- 只有当规模或合规性要求时，再评估外部注册表工具；在那之前，坚持使用内部解决方案。
如果你在公司内部已经实施了共享技能，我很想听听你的经验。如果需要帮助，我的私信随时为你敞开。