Skill 可谓当前 AI 领域最红的热点之一，打开任何一个 AI Agent 的 Skill 市场，你会看到什么？

读写文件、调用 API、执行 Shell 命令、连接数据库、发送邮件…… 这些 Skill 是封装了能力吗？

 01

通用 Skill ≈ 接线工程

这些 Skill 其实都在做一件事：把 Agent 的意图接到外部系统的端口上。

这不是能力，这是接线。

就像一栋大楼的电气工程——重要吗？当然重要。没有布线，灯不会亮，电梯不会动。但你不会说"这栋楼的核心竞争力是它的电线"。电线是基础设施，不是建筑的灵魂。

同理，那些通用的、跨组织可复用的 Skill——文件操作、HTTP 请求、数据格式转换——它们解决的是 Agent 与外界的连通性问题。

这是必要的接线工程（harness engineering），但它跟"让 Agent 真正胜任工作"之间，隔着一道巨大的鸿沟。

真正让一个 Agent 在你的组织里有用的，不是它能不能调 API，而是它知不知道什么时候该调哪个 API、传什么参数、拿到结果后怎么判断对不对。

这些东西，通用 Skill 里找不到。

02

Skill 的本质

一个资深工程师在提交代码前会做什么？

跑单元测试，检查代码覆盖率，确认没有引入已知的安全漏洞模式，然后按照团队约定的格式写 commit message，最后指定合适的 reviewer。

这一套动作，没有任何一步是"通用知识"——单元测试的覆盖率阈值是多少？安全漏洞的检查规则从哪来？commit message 的格式是什么？reviewer 的指定逻辑是什么？……所有这些，全部是这个团队、这个组织长期演化出来的习惯。

把这些习惯写成 Agent 可执行的 Skill，它就不再是一条"能力"，而是一段组织记忆的编码。

这个区分至关重要。通用 Skill 是工具层的抽象——"我能读文件"、"我能查数据库"。

而组织级 Skill 是习惯层的编码——"在我们公司，部署到生产环境之前，必须先跑这三项检查，检查不过不能部署，检查过了要通知这两个人"。

前者是能力，后者是习惯。能力是通用的，习惯是专属的。

一个组织运转得好不好，很大程度上不取决于它拥有多少能力，而取决于它的习惯是否高效、一致、可靠。

那些"不需要想就知道该怎么做"的事情——代码审查流程、合规检查清单、事故响应步骤、新人入职配置——构成了一个组织真正的运行骨架。

当 AI Agent 进入企业，它需要继承的不是通用能力——那些能力它天生就有，或者装个插件就有了。

它需要继承的是这个组织的习惯。而这些习惯，只能由这个组织自己来编码。

03

Skill 的两层生态

理解了这个区分，Skill 的生态就自然分成了两层。

第一层：基础设施层。 

这是通用 Skill 的领地。文件系统操作、网络请求、数据库连接、消息队列、日志采集……这些 Skill 跨组织通用，跟具体业务无关。

它们的价值在于标准化和稳定性，就像操作系统的系统调用——你不需要自己写，用社区维护的就好。

第二层：组织习惯层。 

这是每家公司必须自己建设的部分。代码审查规则、部署前检查流程、数据治理规范、合规审计步骤、客户分级策略、内部知识检索逻辑……这些 Skill 编码的是"我们公司做事的方式"。

它们无法从外部市场获取，因为外部市场不知道你的流程、你的标准、你的例外情况。

问题在于：今天绝大多数 Skill 生态的注意力都集中在第一层。

公共 Skill 市场上琳琅满目的都是基础设施层的东西。这很正常——基础设施层天然适合公共分发，因为它不涉及组织私有知识。

但这也造成了一种错觉：好像“装够了 Skill，Agent 就能干活了”。然而事实上却是：不能！

装满了基础设施层的 Skill，你得到的是一个"什么都能连上，但什么都不会做"的 Agent。它像一个刚入职的新员工，电脑配好了，权限开好了，工具齐全了——然后呢？他还是不知道这家公司怎么做事。

04

公共 Skills Marketplace 的繁荣与局限

截至近期，ClawHub 上的公开 MCP Server 已经超过 15,000 个。Claude Code 生态中可检索的社区 Skill 超过 87,000 个。数量上，公共 Skill 生态已经相当繁荣。

但仔细看这些 Skill 在做什么：绝大多数是连接器——连 GitHub、连 Slack、连 Notion、连各种 SaaS 工具。少数涉及特定领域，比如代码格式化、Markdown 转换、日志解析。几乎没有任何一个 Skill 能回答"在你们公司，这件事应该怎么做"。

这不是公共生态的问题，这是公共生态的边界。

再看企业内部。几乎每个有一定规模的工程团队，都会积累一些自动化脚本、CI/CD 配置、检查工具。

这些东西散落在各个代码仓库里，有的写在 Makefile 里，有的藏在 Jenkins pipeline 的某个 stage 中，有的是某个工程师本地的一个 Python 脚本，只有他自己知道。

这些就是组织习惯的"原始态"——它们存在，但没有被识别、没有被标准化、没有被封装成 Agent 可调用的 Skill。

换个角度想：

一个新入职的员工，如果能在第一天就拿到一份完整的"这家公司做事方式大全"，他的上手速度会快多少？

而今天的 AI Agent，连这份大全都拿不到。它拿到的是一堆通用工具，然后被期望"自己搞清楚公司怎么运转"。这显然不合理。

05

两个被低估的问题：安全与暗物质

公共 Skill 生态还有一个无法回避的问题：信任成本。

已有研究显示，公共 MCP Server 中存在约 20% 的恶意或高风险内容——包括提示注入、权限提升、数据外泄等安全隐患。

这不令人意外。任何开放生态在规模化之后都会面临信任危机，npm、PyPI、Docker Hub 都经历过。

但 Skill 的安全问题比代码包更棘手。一个恶意的代码包，你至少可以通过静态分析、沙箱测试来检测。

而一个恶意的 Skill，它操控的是 Agent 的行为逻辑——它可以在不触发任何传统安全告警的情况下，让 Agent "合理地"做出错误的决策。这种攻击面是全新的，防御手段远未成熟。

对企业来说，这意味着：你不能把组织的关键流程建立在未经审计的公共 Skill 之上。 

基础设施层的通用 Skill 可以从公共市场获取，但组织习惯层的 Skill 必须在受控环境内自建、自审、自管。

第二个被低估的问题，我把它叫做Skill 暗物质。

天文学中，宇宙的大部分质量由暗物质构成——看不见，但决定了星系的运行轨迹。

企业中的 Skill 也是如此：真正有价值的组织知识和流程，绝大部分没有被封装成显式的、可发现的、可调用的 Skill。它们散落在代码仓库的角落里、wiki 的某个页面上、某个工程师的脑子里。

这些暗物质级别的 Skill，不会出现在任何公共市场上，甚至不会出现在企业自己的内部搜索结果里。但它们才是一个组织高效运转的真正支撑。

把这些暗物质"照亮"——识别、提取、标准化、封装——这件事的价值，远远超过在公共市场上多装一百个连接器。

06

Skills Marketplace 不是可选项，是基础设施

把前面的逻辑串起来：

• 通用 Skill 解决的是连通性问题，是基础设施层的接线工程。

• 组织级 Skill 编码的是"我们怎么做事"，是习惯层的知识沉淀。

公共市场只能覆盖第一层，第二层必须自建。公共生态存在严重的信任成本，关键流程不能依赖未审计的外部 Skill。

企业内部最有价值的 Skill 大多以暗物质形态存在，亟待发现和封装。

一个明确的结论：每家认真对待 AI Agent 落地的公司，都需要建设自己的 Skills Marketplace。

这不是一个"有了更好"的加分项，而是 Agent 从"能连上"到"能干活"的必经之路。

一个企业级 Skills Marketplace 应该做什么？

• 第一，让组织习惯变得可发现——工程师和 Agent 都能快速找到"这件事应该怎么做"。

• 第二，让组织习惯变得可执行——不是文档里的一段描述，而是 Agent 可以直接调用的标准化接口。

• 第三，让组织习惯变得可演化——流程变了，Skill 跟着更新，版本可追溯，影响可评估。

• 第四，让信任可管理——每个 Skill 经过审计，权限受控，行为可追踪。

在我之前的文章中讨论过，AI Agent 面临的核心挑战之一是缺乏组织内部的知识体系支撑。Skills Marketplace 正是解决这个问题的一个关键抓手——它不只是一个工具仓库，而是一个组织知识的运行时。

今天大多数企业在 AI Agent 上的投入，集中在选模型、搭框架、写 Prompt。这些都重要，但它们解决的是"引擎"问题。

而 Skills Marketplace 解决的是"道路"问题——Agent 跑在上面的那套规则、流程和习惯。

引擎再好，没有路，也跑不起来。

Skill 不是你教给 Agent 的能力，是你交给它的习惯。习惯不是天生的，是一个组织用时间换来的。

把习惯变成 Skill，把 Skill 变成 Marketplace——这才是 AI Agent 在企业落地的真正基础设施。

欢迎关注微软 智汇AI 官方账号

一手资讯抢先了解

喜欢就点击一下 在看 吧~