← 返回博客

当基础设施巨头发布了一个'Skill'

支付宝刚发布了'支付集成 Skill'。当支付基础设施、AI 框架和代码编辑器都用同一个词指代互不兼容的东西时,这不是趋同——这是协议层即将诞生的前兆。

当基础设施巨头发布了一个'Skill'

支付宝——全球最大的支付平台之一——刚刚发布了它所称的”支付集成 Skill”。这是一个标准化组件,让 Vibe Coding 开发者通过自然语言集成支付能力:安装 Skill,描述需求,AI 完成支付流程的接入。通过魔搭社区的 Skills 中心分发,配套沙箱环境用于测试。

有趣的不是它做了什么。支付 API 封装已经存在多年。有趣的是它传递的信号:“Skill”这个词已经从 AI 原生工具领域跨越到了企业基础设施领域。而当一个概念获得普遍采用却没有普遍定义时,一个非常特定的模式就会浮现。


七个平台,七种定义,一个词

过去十二个月里,“Skill”——或它的语义等价物——被完全不同的生态系统采纳:

平台术语实际含义
Anthropic (Claude)Skill带 YAML frontmatter 的 markdown,教 Claude 领域工作流
Cursor IDESkillSKILL.md 文件,扩展 AI 编程助手的能力
支付宝 / 魔搭社区Skill (技能)封装的支付 API + prompt 模板
OpenAIGPT / Action自定义指令 + API 集成,打包为可分享的”应用”
Coze(字节跳动)插件 / Skill锁定在 Coze 平台的可视化工作流节点
Microsoft CopilotPlugin通过自然语言调用的 M365 集成
OpenClawSkill具有 Soul/记忆系统的模块化能力文件,面向自主 Agent

七个平台。七种定义。一个词。

唯一的共同属性是”AI 能使用的一个东西”。其余一切——封装格式、分发渠道、运行时要求、安全模型、生命周期——互不兼容。

这就是语言学所说的语义漂白:一个词因使用过于广泛而失去了特定含义。“Skill”如今涵盖了从”一个带指令的 markdown 文件”到”一个封装的 API 包装器”到”可视化工作流构建器中的一个节点”的所有东西。这个术语在同一时刻赢得了普遍采用,也失去了普遍定义。


语义陷阱

危险不在于这些定义不同。危险在于开发者没有意识到它们不同。

当一个支付宝开发者和一个 Cursor 开发者都听到”Skill”时,两人都会点头表示理解。但支付宝的 Skill 是一个锁定在魔搭社区的支付 API 包,需要沙箱凭证和中国支付基础设施。Cursor 的 Skill 是一个带有触发模式的 SKILL.md 文件,没有运行时依赖。

它们共享一个名字。除此之外什么都不共享。

这造成了一个可预测的失败模式:开发者在一个平台上积累了”Skill”的专业知识,假设它可以迁移。但它不能。封装格式不同。分发渠道不同。运行时不同。评估标准不同——如果有评估标准的话。

而且碎片化正在加速。每个月都有新的平台推出自己的”Skill”概念。词汇看起来越来越统一,实现却越来越分裂。


这一切曾经发生过

普遍词汇搭配碎片化实现,是计算机领域最古老的模式之一。

超文本(1989–1993)。 在 HTTP 出现之前,多个团队独立构建了超文本系统——Gopher、WAIS、HyperCard、Xanadu。都能将文档链接到文档。都互不兼容。直到一个协议(HTTP)和一种格式(HTML)将概念统一为可互操作的东西。

电子邮件(1971–1982)。 在 SMTP 出现之前,每个网络都有自己的邮件系统——UUCP、FidoNet、ARPANET 邮件。你能联系同一网络上的人。跨网络邮件需要网关和运气。SMTP 胜出不仅是因为技术优势,更是因为它定义了一个最小可行的互操作层。

数据库(1970–1986)。 在 SQL 标准化之前,每个厂商都有自己的查询语言——IMS 用 DL/I,IDMS 用 DML,dBASE 有自己的语法。SQL 没有替代这些实现。它定义了一个通用接口,使数据库变得可比较、可替换、可组合。

模式始终相同:

1. 多个团队独立解决同一个问题
2. 它们收敛到相似的词汇
3. 词汇制造了兼容性的幻觉
4. 不兼容性在规模化后成为摩擦
5. 一个协议层应运而生,提供真正的互操作性

“Skill”生态系统正处于第 3 步。第 4 步和第 5 步不可避免。


协议层需要什么

如果碎片化催生了对协议的需求,这个协议需要提供什么?

可移植的表示。 为一个平台编写的能力应当能在另一个平台上被评估——理想情况下还能执行。这需要一个通用的中间表示。Web 领域是 HTML。数据库领域是关系模型。对于 Agent 能力,候选者是带类型接口的编译 WASM:不依赖执行环境,需求前置声明。

适应度评估。 当七个平台各有 100 个”文本摘要”的实现时,必须有东西回答:哪个最好?不是靠 Star 数或更新时间,而是在标准化条件下的实测表现。这需要基准测试、度量指标和竞争——不是人工策展。

能力协商。 支付 Skill 需要网络访问和 API 凭证。文本分析 Skill 只需要字符串输入。在一个能力运行于新环境之前,需要一个形式化的检查来验证:这个环境是否提供了该能力所需的一切?这就是 WASM 组件模型所称的接口匹配——也是 Agent 生态系统尚不具备的。

生命周期管理。 能力被发布后就……一直存在。没有弃用机制,没有下架策略,没有办法知道依赖是否已在底层断裂。协议层会定义能力如何诞生、竞争、传播和退役。

集体安全。 当一个恶意能力在某个平台上被发现时,信息只停留在那个平台。Agent 能力没有跨平台的威胁情报。协议层会让威胁签名在平台间传播,保护整个生态系统而非单一孤岛。


碎片化是信号,不是问题

很容易把碎片化看作协调失败。但它不是。碎片化是协议诞生的前提条件

计算机历史上每一个变革性协议都诞生于完全相同的情境:多个团队解决同一个问题,收敛到相似的词汇,构建互不兼容的实现。不兼容性带来的摩擦正是催生统一层的需求。

“Skill”概念显然已经跨越了鸿沟。当支付基础设施都在发布”Skill”时,这个词汇已经赢了。但没有协议的词汇只是平行建设——很多建设者,没有桥梁。

下一个问题不是”如何构建更好的 Skill”,而是”不同平台的 Skill 如何竞争、组合、共同进化”。

这是一个协议层的问题。Rotifer Protocol 通过将每个能力视为一个 Gene 来回答这个问题:可移植(带类型接口的 WASM IR)、可评估(适应度函数 + Arena 竞争)、可组合(形式化能力协商)、可进化(水平逻辑迁移实现跨 Agent 传播)。

Skill 是氨基酸。Gene 是蛋白质。协议是将它们连接成一个活的生态系统的东西。

构建模块已经无处不在。七个平台证明了这一点。现在它们需要一种不只是一个词的共同语言。


Rotifer Protocol 是一个面向自主软件 Agent 的开源进化框架。协议规范、CLI 和 SDK 可在 npm 获取:@rotifer/playground