别急着卖Skill：AI能力市场真正交易的是什么？

本文来自微信公众号： AIGC从0到1 ，作者：王零壹，头图来自：AI生成

以后能不能靠卖Skill赚钱？

一份SKILL.md，几段提示词，再配上脚本、案例和工具接口，把自己会做的事封装起来，挂到某个市场。别人安装，Agent调用，开发者收钱。经验终于可以像软件一样被复制和出售。

这件事也已经开始发生了。

但如果把它理解为“AI时代再来一个App Store”，很容易把最重要的东西看错。会写Skill的人很多，可以上传文件的目录也已经有了。眼下真正稀缺的，是一套让人愿意把工作交出去的机制。

文件可以复制，工作责任复制不了。

这也是为什么，今天已经能看到Skills的开源分发、安装工具和企业级市场，却很难找到一个真正跑通的“普通人买一份Skill，开发者靠它稳定发财”的大众零售市场。前者已经热起来了，后者还在搭地基。

要讨论这门生意，先得把“Skill”这个词从一团雾里拎出来。

一、一个Skill，到底是什么？

今天大家口中的Skill，至少混着三种不同的东西。

第一种，是工作说明书。

它告诉Agent在什么情况下该做什么，先看哪些材料，遵循什么步骤，最后按什么格式交付。一个Skill通常包含SKILL.md，也可以附带脚本、参考资料和其他资源，让Agent在需要时加载。

这一层很重要，但也最容易被误判价值。一份写得好的说明书能显著减少跑偏，能把一个团队里经验丰富的人做事的顺序保存下来。不过，只要它没有独有数据、工具权限、持续维护或效果验证，别人拿到以后通常也能很快模仿。

第二种，是操作能力。

一个Skill如果能调CRM、读数据仓库、生成报价单、改广告计划、把工单写回系统，它就不再只是“教Agent怎么说话”。它给了Agent一双能碰到真实世界的手。

这里常常和MCP、API Connector、自动化工作流混在一起。它们彼此相关，但不该混为一谈。MCP更像让Agent接上外部系统的通道；Skill更像告诉它进了这个系统以后，什么任务值得做、按什么次序做、什么情况要停下来找人。一个能做事的Agent，通常两者都需要。

第三种，才是客户愿意长期买单的东西：一段可以被托付的工作。

比如“把销售线索按规则分级”远不止一个提示词。它要接到CRM，理解这家公司什么算有效线索，知道哪些字段不能碰，遇到边界案例要转给谁，还要能回看为什么给了这个判断。客户购买的，是一段能稳定运转、出了问题有人能解释和修复的流程。

这三个层次的价格差，会非常大。

一份通用写作Skill很可能是免费的，或者只是一种获客材料；一个对接客户系统、持续更新规则、能对结果负责的行业能力包，则可能对应订阅、实施费和长期服务合同。把它们都叫“卖Skill”，会让人误以为变现靠的是把文件写得多漂亮。

其实，决定收入的往往是最后一层：你让谁放心把哪段工作交给它。

二、全球市场已经出现了三种形态

先说一个可能有点扫兴的事实：现在的全球Skills生态，并不存在一个已经公认成功、像iOS App Store那样以零售抽成为主的统一市场。

它正在长成三种不同的形态。

第一种是开源包和开发者分发。

Anthropic在2025年把Agent Skills推成开放标准，随后GitHub Copilot、Codex等产品也开始支持以SKILL.md为核心的技能包。Vercel在2026年初推出了skills CLI和skills.sh，把安装、更新、搜索和跨Agent适配做得越来越像一个包管理器。

这一层的主角是Git仓库、命令行、安装次数、维护者和贡献者。它看上去很像开源软件生态，而不是商品零售。开发者先用免费分发来取得安装量、口碑和生态位置，再把咨询、托管服务、云产品或团队版卖出去。

NVIDIA、Microsoft、Vercel这些公司发布官方Skills，也很能说明问题。它们把“怎样正确使用我的产品”封装成Agent能听懂的工作说明和工具路径。Skill在这里承担的是产品分发和客户成功的角色：Agent更容易用对你的SDK、云服务或API，用户也就更可能持续使用你的核心产品。

第二种是企业组件市场。

Salesforce的AgentExchange是一个更接近真实商业闭环的例子。它的商品是合作伙伴提供的actions、topics、prompt templates和agent templates。客户能在Agentforce的构建环境里发现、试用、采购和部署，合作伙伴则通过企业销售流程、私有报价、统一计费和交付来完成交易。

这套模式真正卖的是“进入企业工作流的资格”。

一个Docusign相关能力之所以可以出现在这样的市场里，是因为它能被接入合同生成、签署、跟踪的流程，并且已有身份、权限、数据和商业条款可以承接。对于企业采购者来说，这种包装比“下载一个陌生Skill”有意义得多。

第三种是企业内部的能力库。

这或许会是规模最大、但最不显眼的一块市场。企业把客服处理、销售跟进、财务对账、研发排障里的固定做法，连同访问权限、知识资料和验收标准，一并封装为内部Skills。它们不一定会公开售卖，却会在组织内部被重复调用。

外部市场解决的是“谁能卖给更多人”；内部能力库先解决“谁能让自己的经验留下来”。后者往往更早产生价值，因为它避开了最困难的冷启动问题：你不需要先教育陌生用户，只需要找到一段已经有人每天都在做、且总是做得不够稳的工作。

三、技能市场不是卖场，它首先是一套委托系统

App Store的基本逻辑很简单：用户挑一个App，下载，自己打开使用。

Skills的逻辑更绕一些。用户往往不会说“我要买一个合同条款比对Skill”。他会说：“这份合同帮我看一下。”接下来，Agent才有可能判断是否需要调用一个相关能力。

这让Skills的交易链条变成了五步。

先是发现。人或Agent得知道世界上有这个能力，并且大致理解它的边界。

然后是信任。它来自谁，最近更新是什么时候，读哪些数据，能执行哪些动作，有没有通过与自己场景相近的测试。

再往后才是授权。一个Agent就算找到了最合适的Skill，也不能因为说明文件写得很有道理，就直接去读取财务数据、删记录或发邮件。权限、预算、人类确认和审计日志，得在调用之前摆好。

执行之后还有验收。任务是否完成、质量如何、有没有造成损失，不能只由Skill自己宣布。

最后才是结算和迭代。谁为模型调用、工具调用和数据访问付费，开发者凭什么持续维护，差评或事故如何影响它的后续分发，这些都需要变成规则。

这才是一套能运转起来的Skills市场机制。它把能力、权限、效果和责任连在了一起，远比“上传文件，等人购买”复杂。

从这个角度看，未来最关键的排序指标，恐怕也不会是下载量。

它更接近几件事：在什么任务上成功过，成本是多少，失败会发生在哪里，谁愿意为结果担责。

四、真正能赚钱的地方，不在那份文件本身

如果把Skill当作独立数字商品来卖，最先遇到的问题就是复制。

一份通用SOP、一段公开提示词、一个没有私有数据依赖的工作流，很难长期保持稀缺。它可以帮开发者完成第一次获客，却很难成为稳定护城河。用户买过一次，别人改个名字再放一份，价格很快就会被压下去。

目前更现实的收入，通常发生在四个位置。

第一个位置，是托管执行。

开发者不把全部能力交付成文件，而是提供一个持续运行的服务：模型怎么选、工具怎么调、数据怎样更新、失败怎样重试，用户看到的是结果。收费可以按席位、按调用量，也可以按处理的任务量。此时，Skill是服务内部的能力单元，钱收在长期可用性和持续维护上。

第二个位置，是行业实施。

很多业务流程并不存在“装上就能用”的版本。教育机构的招生、律所的合同审阅、跨境团队的选品，表面上任务名相同，实际的判断口径、数据位置、业务例外和人类接管点都不同。能把这些差异接进同一套能力框架的人，卖的是实施、配置和运营，而不是单次安装包。

第三个位置，是结果责任。

当效果能被清晰测量时，收费会逐渐从“调用了多少次”向“完成了多少有效工作”靠近。比如一段流程节省了多少人工复核、减少了多少无效线索、把多少工单在SLA内处理完。这里的难点不在定价页面，而在于双方先把结果的计算口径说清楚。

第四个位置，是产品入口。

对云厂商、SaaS和数据服务商而言，Skill甚至不必单独收费。把官方最佳实践装进Skill，能够减少客户上手成本，让Agent更频繁地调用自己的产品。Skill成了开发者关系、产品文档和销售漏斗的一部分。很多时候，最赚钱的Skill并不是被售卖的那个，它把收入导向了后面的API、云资源、席位和企业合同。

所以，今天问“卖Skill能不能赚钱”，更准确的回答是：能，但收费对象通常不是那份Skill文件。它可能是稳定运行的能力、接入客户系统的工作、被验证过的结果，或者某个产品更高频的使用。

五、为什么目录越热闹，反而越难做生意？

Skills市场眼下最有意思的矛盾是：供给增长得非常快，交易所需要的基础设施却远远没有跟上。

第一个问题是发现。

skills.sh已经开始用匿名安装遥测做排行榜，MCP也有了官方Registry。它们解决了“世界上有哪些东西”的问题，却还解决不了“眼前这个任务该用哪一个”的问题。

安装次数不等于任务质量。一个Skill的名字写得好、背后的发布者有名，或者它恰好进入一个热门教程，都可能带来安装。可它是否适合你的技术栈、行业规则和数据环境，安装量并不会告诉你。

这就是Skills市场比App市场更难的地方。用户下载一个记账软件，试错成本有限。让一个Agent带着陌生能力碰企业数据，试错成本可能是一封错发的邮件、一条错误报价，甚至一次越权访问。

第二个问题是安全。

Skill的说明文字本身就会进入Agent的上下文；它还可能附带脚本、依赖和外部网络连接。恶意Skill可能诱导Agent外传数据或执行非预期动作。开放生态里的平台同样承认，无法为每一份收录能力的质量和安全做担保。

这并不意味着开放分发没有价值。它意味着，Skill的安全审查不能只看一眼产品介绍。需要看权限声明、依赖、代码来源、网络行为、版本变更，也要看Agent在真正执行前能否被限制在合理的权限范围内。

第三个问题是“可移植”被说得太轻松了。

开放标准让一份SKILL.md有机会被多个Agent识别，这当然是进步。但文本层面的可移植，并不等于工作层面的可移植。不同Agent的工具能力、文件系统、权限模型、上下文长度、触发规则都不同。同一份Skill换了运行环境，可能只剩下说明文字仍然有效。

这也是为什么接下来会出现一批不那么显眼、但很重要的服务：兼容性测试、版本管理、运行监控、效果评测和权限治理。它们听起来不性感，却决定了一份Skill能否从GitHub的示例，变成企业敢装进生产环境的能力。

六、个人、小团队和企业，各自该站在哪里？

对个人开发者来说，最容易犯的错误，是从“我能写什么Skill”开始想。

更好的起点是：谁正在重复做一段麻烦、可判断、又愿意掏钱解决的工作？

去找一个具体的岗位动作，比如把一次访谈整理成可直接录入CRM的销售纪要，或者把投放数据变成一份能让运营负责人下决策的复盘。范围越窄，客户越容易判断你有没有用。

第一批产品也别只交付一个压缩包。把Skill、示例数据、安装方式、失败时的人工接管点和一段清晰的验证方法放在一起。先找到十个愿意把真实工作交给你测试的人。只要他们持续使用，你就会知道哪部分是通用流程，哪部分其实需要服务。

小团队的机会，在于做“行业能力组合”。

一个好团队不应该忙着搭一个什么都卖的市场，而应该围绕一条业务链沉下去。以教育招生为例，真正有价值的不是一个会聊天的咨询Skill，而是一套能把线索识别、资格判断、人工转接、跟进提醒、内容复盘串起来的系统。单个能力可以被替代，理解这一整条链路里哪些地方最容易损失客户，才是更难复制的资产。

商业上，这类团队很可能会同时做三件事：对外展示一部分轻量Skill来获客；把核心能力托管起来；为客户提供接入系统和持续优化。它看起来不像纯软件生意，也不像传统咨询，更像一间用Agent放大交付能力的行业服务公司。

企业的第一步则不该是“把Skill拿出去卖”。

更值得先做的是内部Registry。把一段真实有效的工作流程连同数据权限、责任人、验收指标和版本记录一起登记下来。选择一个低风险但高频的场景，让它在内部反复跑，先建立更新、回滚和审计的习惯。

当企业能清楚地回答“它为什么这么做”“它读了什么数据”“出错时谁接手”，再讨论市场化输出，事情会稳很多。那时它拿出去卖的，也不只是员工经验的文字版，而是一段已经在真实组织里跑出边界的能力。

七、Skills市场会更像什么？

它会有一点像npm：能力可以开源、安装、更新和组合。

它也会有一点像AppExchange：企业需要采购、集成、权限和责任。

它还会有一点像咨询业：真正有价值的经验，常常藏在业务例外、判断顺序和落地后的持续调整里。

所以，Skills市场的胜负手，大概不在于谁先开出一万个货架位。

谁能让Agent在正确的时候找到正确能力，谁能把权限和安全放在调用之前，谁能用真实结果证明一段流程值得反复交付，谁才可能获得这个市场最有价值的一部分。

卖Skill当然会成为一门生意。

只是到最后，卖出去的从来不是一份文件。是别人愿意交给你的那段工作。