Plugins 导读

新增 Capability 要先设计公共合同，再接具体插件和供应商

这页是 OpenClaw 核心贡献者指南。它提醒你不要把某个厂商直接写进 channel 或 tool，而是先定义共享 capability：输入、输出、错误、注册表和运行时边界都说清楚，再让 provider、harness、工具和通道按同一张合同工作。

先讲这一页到底在解决什么

原文共 10 节，先看 Start Here 路径：/plugins/adding-capabilities 查看官方原文

第一站

不要先把某个厂商直接塞进系统

如果一个新能力以后可能有很多供应商、很多工具、很多通道一起用，就不能只为第一个厂商开一条小路。

错误起点

直接把某个 vendor 写死到 channel 或 tool 里，像给全校只修一扇只认某个同学的门。

正确起点

先定义 capability，让所有供应商都按同一张任务单交作业。

plugin

像“这间教室归谁管”。它是所有权和加载边界。

capability

像“大家交作业用同一张表”。它是核心共享合同。

第二站

先把输入、输出、错误和权限边界说清楚。

共享类型和注册表要在核心位置，别散落在某个插件里。

供应商插件按同一能力合同提供实现。

通道、工具、命令只依赖能力，不直接绑死某个供应商。

第三站

types.ts

放公开形状：能力吃什么、吐什么、错误怎么描述。

registry.ts

放登记处：谁提供了这个能力，运行时怎么找到它。

runtime

放给执行阶段用的助手，避免每个调用方重复造轮子。

检查重点

新能力要有清楚所有权、测试、文档和迁移说明，不能只靠“能跑”就合并。

第四站

官方用图像生成举例，是因为它很像未来许多新能力：有不同供应商，有不同参数，还可能被工具、聊天通道和 UI 一起使用。

能力层

定义“生成图片”这件事的共同语言。

提供商层

不同厂商各自实现，但对外交同样格式的结果。

使用层

工具和通道只说“我要生成图片”，不用知道背后找的是谁。

一句话收住

先设计公路，再让车上路。不要为了第一辆车，把路修成只能它开。