13.4 开发自定义扩展

生成模型:Claude Opus 4.6 (anthropic/claude-opus-4-6) Token 消耗:输入 ~850k tokens,输出 ~80k tokens(本章合计)


前三节我们从架构、API 和实例三个层面理解了 OpenClaw 的扩展机制。本节进入实践环节——手把手指导如何开发一个自定义通道扩展,让读者具备独立开发新通道的能力。


13.4.1 扩展脚手架搭建

目录结构

一个最小可用的通道扩展需要以下文件:

my-channel/
├── package.json              # npm 包配置
├── openclaw.plugin.json      # 插件清单(必须)
├── index.ts                  # 入口文件
├── tsconfig.json             # TypeScript 配置(可选但推荐)
└── src/
    ├── channel.ts            # ChannelPlugin 定义
    ├── monitor.ts            # 消息监听逻辑
    ├── send.ts               # 消息发送逻辑
    └── runtime.ts            # 运行时引用缓存

package.json

关键配置:

字段
必填
说明

openclaw.extensions

声明入口文件路径数组,被插件发现机制读取

type: "module"

推荐

ESM 模块格式

dependencies

按需

第三方 SDK 依赖

openclaw.plugin.json

清单字段说明:

字段
用途

id

全局唯一标识符,用于 plugins.entries.mychat 配置

channels

声明此插件提供的通道 ID,用于 Gateway 自动加载

configSchema

JSON Schema,插件加载时验证 plugins.entries.mychat.config

runtime.ts — 运行时缓存

这个模式在 13.3 节中反复出现。由于 PluginRuntime 只在 register() 调用时注入,其他模块无法在导入时获得它,因此需要一个模块级缓存。

index.ts — 入口文件

注意:如果你的插件有自定义配置(不是 empty schema),可以将 emptyPluginConfigSchema() 替换为自定义的 Zod Schema 或手写的 safeParse 函数。emptyPluginConfigSchema() 的实现只接受空对象或 undefined


13.4.2 实现通道适配器接口

最小可用的 ChannelPlugin

ChannelPlugin 有近 20 个可选适配器槽位,但大多数是可选的。一个最小可用的通道只需要实现 idmetacapabilitiesconfig

能力声明的意义

capabilities 不仅仅是元数据,OpenClaw 的其他模块会根据它做决策:

逐步扩展适配器

随着功能完善,你可以逐步添加更多适配器:

第 1 阶段(最小可用)config + gateway

第 2 阶段(安全控制):添加 security + pairing

第 3 阶段(消息能力增强):添加 outbound + messaging + actions

第 4 阶段(运维功能):添加 status + directory + onboarding


13.4.3 注册到插件系统

安装方式

有三种方式将自定义扩展注册到 OpenClaw:

方式一:工作区级安装(推荐开发调试)

将扩展目录放到项目的 .openclaw/extensions/ 下:

OpenClaw 启动时会自动发现并加载。无需任何配置。

方式二:全局安装

放到用户级配置目录:

所有工作区都能使用此扩展。

方式三:配置路径安装

openclaw.config.yaml 中显式指定路径:

适合开发时指向源码目录,修改后不需要复制。

配置启用

openclaw.config.yaml 中添加扩展配置:

验证加载

启动 OpenClaw 后,可以通过 Gateway 日志确认插件是否加载成功:

如果加载失败,日志中会出现诊断信息:

也可以通过 Gateway RPC 查看已加载的插件列表:


13.4.4 测试与调试

单元测试

扩展可以独立进行单元测试。推荐使用 Vitest(OpenClaw 官方扩展的测试框架):

OpenClaw 官方扩展中的测试可以作为参考——例如 extensions/msteams/src/ 包含 attachments.test.tsinbound.test.tsmessenger.test.ts 等多个测试文件。

集成测试

对于需要验证消息收发完整链路的场景,可以通过 Mock 消息的方式进行集成测试:

调试技巧

1. 启用详细日志

在配置中开启 verbose 模式:

或在启动时设置环境变量:

2. 使用 Plugin Runtime 的日志器

3. 诊断事件(Diagnostic Events)

如果你需要监控扩展的运行状态,可以使用诊断事件系统:

4. 消息处理链路调试

对于入站消息处理,关键的调试检查点:

如果消息"消失"了,最常见的原因是:

  • 发送者不在 allowFrom 列表中

  • 消息格式不符合预期,规范化失败

  • Agent 路由未匹配到任何 Agent

  • 配置中 enabled: false

发布到 npm

完成开发后,可以将扩展发布为 npm 包:

其他用户安装:

然后在 openclaw.config.yaml 中添加 loadPaths 指向安装目录,或将其软链到 ~/.config/openclaw/extensions/


本节小结

  1. 最小可用扩展只需 5 个文件package.jsonopenclaw.plugin.jsonindex.tssrc/channel.tssrc/runtime.ts。其中 openclaw.plugin.json 清单和入口文件的 register() 函数是必须的。

  2. ChannelPlugin 的 20 个适配器槽位大多是可选的,推荐采用渐进式开发:先实现 config + gateway(最小可用),再逐步添加 securityoutboundstatus 等。

  3. 三种安装方式适合不同场景:工作区安装用于开发调试,全局安装用于个人使用,配置路径安装用于源码开发。

  4. 测试应分两层:单元测试验证 ChannelPlugin 的各个适配器实现,集成测试验证消息收发完整链路。

  5. 调试的核心是日志和诊断事件:通过 api.loggerruntime.logging.getChildLogger()emitDiagnosticEvent() 三个层次的日志,可以定位消息处理链路中的任何问题。

Last updated