员工笔记AI技能满天飞，企业却要承担混乱

随着企业采用 AI agents，开发者们不断堆砌包含部署手册、代码审查清单、样式指南、事件流程和内部工作流的庞大 skill 库，这个问题变得更加复杂。

这些繁多的 skills 通常始于个人实验，随后才传播到代码库、本地机器、Slack 频道和插件中。更令人困惑的是，这些 skills 通常没有明确的负责人，也没有可靠的方法来知道你正在使用的 skill 是否为最新版本。

Speakeasy 于上周五发布了 Skills Management，这是一个旨在将 skills 视为集中注册的企业级制品的系统，具备不可变版本、作用域访问控制和使用情况的可观测性。

今年早些时候，我们开始看到开发者创建 prompt 集合，并为其配置 agents 使用方式。在很短的时间内，Agent Skill 规范被锻造出来——用 Markdown 编写并加入一些 YAML frontmatter。而一个 skill 仍然是向任何 agent 传递特定企业知识的最佳方式。

Agent skill 库急剧增长

Speakeasy 关于企业中的 skills 有一个简单的观点。随着组织采用 AI agents，他们正在迅速构建 skills 库——包括部署手册、代码审查清单、样式指南、事件流程、内部工作流以及其他公司特定知识。

问题是这些 skills 库的增长速度超过了公司能够管理的速度。Skills 最终分散在代码库、本地机器、Slack 频道和插件中，导致团队无法清晰了解存在哪些 skill、哪个版本是最新的，以及谁拥有某个给定的 skill。

Speakeasy 声称"一家中型金融科技客户最近发现公司内正在使用超过 500 个独特的 AI skills"。这是因为 AI 实验始终首先是一项个人行为。使用聊天机器人感觉很私密；即使 Claude Code 仍然像聊天机器人一样与你交流。所以与团队分享你的 prompt 可能不会立即发生。这导致大量重复工作——员工在不知道彼此在做什么的情况下创建了类似的 skills。

集中化 skill 管理

为了解决这个问题，Speakeasy 首先将 skill 视为一种新的企业制品，需要某种集中注册——这就是该公司所品牌化的 Skills Management。

Skills Management 以与 git 处理代码类似的方式管理 skills——不可变版本的注册表，以及对存在内容的共享视图。因此，如果你编辑一个现有的 skill，你会得到一个新版本。但 Speakeasy 还增加了可观测性，因此企业可以知道哪些 skills 使用最频繁，以及不同部门编写相似内容的频率。更重要的是，如果一个 skill 表现不佳（也就是说，使用它的 agent 在执行时注意到问题），LLM judge 可以对其进行分析并提出改进建议。

Skills Management 在创建 skill 文件时强制用户遵守上述 Agent Skills 规范，以便它可以使用 frontmatter 名称作为规范名称。尝试以不同名称输入相同内容将被忽略。

不可变版本和访问控制

作用域访问允许围绕角色形成——谁可以创建和维护 skills，谁可以消费它们。

Skills 被 Speakeasy 的控制平面监控，同时 agents 在使用它们，这种组合显然比仅仅将 skill 文件集中到 git 仓库中更好。

根据 Agent Skills 规范验证 skills 是一个非常好的主意。毕竟，Markdown 基本上就是带有一些符号的英文。但 frontmatter 中的一些可选条目（如"license"）可以使用企业模板来简化流程。

Sagar 告诉 The New Stack，他还没有看到客户提出这个需求。

"我们目前没有公司特定模板的第一方概念，"他说。"不过，公司可以创建一个用于验证 skills 的 skill，引入到我们的 LLM-as-judge 流程中。"

"我们追踪每个 skill 的元数据，以便管理员可以快速看到哪些 skills 得到了维护（最后更新时间）以及使用频率（以及在团队成员中的传播情况）。"

那么，对于一个人（或流程）来说，是否可以轻松阻止最新的错误变更扩散？

"是的，"Sagar 说。"我们追踪每个 skill 的元数据，以便管理员可以快速看到哪些 skills 得到了维护（最后更新时间）以及使用频率（以及在团队成员中的传播情况）。我们正在积极开发一些自动分类功能。"

"管理员"这个术语引出了大型企业的另一个问题。很多不同的角色可能需要走到一起来共同管理公司的 skills。你可能希望一位安全专家建议一个新版本的 skill，但更重要的是——让现有 skill 版本失效。然而，你不会希望他们能够编辑现有 skill 的内容。这能实现吗？

Sagar 解释说 skill 版本是不可变的："更新一个 skill 版本是不可能的。"

然而，"当你发布一个新的 skill 版本时，现有版本会被自动化'取消发布'。这解决了这个场景中的两个问题：安全专家会起草一个新版本的 skill，发布它会将旧版本从员工的机器上撤销，我们的可观测性堆栈会暴露任何差异——例如，滞后的插件版本或故意的本地副本。旧版本可以在适当的情况下回滚。"

"但是，出于安全原因，目前没有版本固定 skill 的概念。"

这个 Speakeasy 系统真正智能的地方在于，它理解一个 skill 如何从开发者的笔记本电脑开始，需要在企业中经过推广才能被完全采用，这暴露了更多关于角色的问题。

管理者需要大量 UI 来识别推广工作的进展速度——但他们对 skills 本身的其他方面没有任何兴趣。

"因为 skills 遵循 Agent skills 开放格式，所以在存储 skills 方面没有任何专有之处。"

企业 skill 可移植性

对于任何构建知识的系统，用户必须知道如何离开它。Sagar 说 Speakeasy 已经解决了这个问题："因为 skills 遵循 Agent skills 开放格式，所以在存储 skills 方面没有任何专有之处。用户可以自由导出他们的 skills 语料库并迁移到另一个平台。我们还提供了一条路径，允许用户将所有 MCP 服务器和 skills 克隆到 GitHub 仓库，这样他们就可以随时离开。"

企业正处于控制内部 AI agents 爆炸式增长的中间阶段，同时也在询问增加 token 成本是否真的值得。这种类型的管理和可观测性平台将在判断 Agent 时代的真正价值方面发挥越来越重要的作用。