通道插件
像给 OpenClaw 新开一扇门，让它能接 Discord、IRC 之类的新消息平台。
Plugins 导读
插件怎么写、发哪里、能接哪些能力
不用把插件塞进官方仓库，发布到 ClawHub 或 npm，用户一行命令就能装。先看“Quick start: tool plugin”里的最小示例，从 package.json 和入口文件抄起。最容易漏的是 manifest 里的 compat 版本号，写错会导致插件加载失败。
先讲这一页到底在解决什么
插件怎么写、发哪里、能接哪些能力
不用把插件塞进官方仓库，发布到 ClawHub 或 npm，用户一行命令就能装。先看“Quick start: tool plugin”里的最小示例，从 package.json 和入口文件抄起。最容易漏的是 manifest 里的 compat 版本号，写错会导致插件加载失败。
第一站
📦 先把 plugin 想成“一盒写清楚标签的新积木”
官方原文前两段最想告诉你的，其实不是 TypeScript 语法，而是插件最本质的样子：它是一份可以被安装、被识别、被启用的能力包。
🛠 它能加什么
可以是新聊天通道、新模型提供商、新工具，也可以是会在某些时刻自动出手的钩子。
📮 它不一定要塞进官方仓库
官方明确说了，你不用把插件塞回 OpenClaw 主仓库。你可以发到 ClawHub，也可以发到 npm。
🚚 用户怎么拿到它
别人用 openclaw plugins install <package-name>，OpenClaw 会先去 ClawHub 找，找不到再去 npm 找。
⭐ 先记一句
Plugin 不是往系统里硬插代码，而是做一盒能被 OpenClaw 正式认出来的新能力。
第二站
🧭 先别急着写代码，先决定你这盒积木是什么类型
官方在这一步把插件分成三类，是为了防止你一开始就走错入口。
提供商插件
像给它加一个新的“大脑供应商”，告诉它可以从哪里拿模型能力。
工具 / Hook 插件
像给它加新手新脚，或者在某些关键时刻加一个会自动出手的小帮手。
这页主讲哪种
官方这页的 quick start 主要是在教你做一个最简单的“工具插件”。
第三站
🏷 先做盒子外面的标签：package.json 和 openclaw.plugin.json
第一次看这两份 JSON，很容易觉得它们很像。其实一个更像“快递外箱”，另一个更像“产品说明卡”。
package.json像快递箱外面的通用寄件标签：包裹名字、版本号、模块类型，还有告诉 OpenClaw “入口文件在这里”。
openclaw.plugin.json像这盒插件自己的名片。它会写上 id、name、description，还会说配置长什么样。
\"openclaw\": { \"extensions\": [\"./index.ts\"] }这行不是装饰，它像在盒子外写清楚：“真正的接线口在 index.ts 这儿。”
🧠 为什么 manifest 必须有
官方说得很硬：哪怕你没有配置项，也得有 manifest。因为系统总得先认清“你是谁”，才能决定要不要把你装进去。
第四站
🧪 definePluginEntry 那段代码，其实是在说“你好，我来登记一个新工具”
示例代码看起来像技术文，其实翻成人话非常简单：先声明插件是谁，再在 register 里把新能力挂上去。
definePluginEntry({ ... })像插件到前台做自我介绍：“我叫这个名字，我是干这个的，现在开始登记我能提供的能力。”
register(api)像系统给你一张登记表。你可以往里面填：我要注册一个工具、一个通道、一个 provider，或者别的东西。
api.registerTool({ ... })像正式把一个新工具挂到墙上，让 OpenClaw 以后在需要时可以把它拿下来用。
parameters: Type.Object({ input: Type.String() })像告诉系统：“这个工具吃进来的东西应该长什么样。”不是随便乱喂，而是先说明输入格式。
第五站
🛠 execute 里面才是“工具真正上班的地方”
前面那些声明像写名片，execute 才像真的把工具叫起来干活。
async execute(_id, params) { ... }像前台已经把任务单递到了这个工具手里。接下来它要看参数、做动作、再把结果交回来。
return { content: [{ type: \"text\", text: ... }] }像工具做完事后把一张回执条交回系统，说：“这是我干完以后要交给你看的内容。”
📌 示例里为什么这么简单
因为官方只是想让你看懂框架，不是想第一次就把你扔进复杂业务里。所以它故意做了个“把输入又吐回去”的极简例子。
🎈 真正要记住的点
插件代码不是神秘黑箱。它就是在告诉 OpenClaw：我能接什么任务，接到以后怎么干，干完怎么回报。
第六站
📚 官方后面那张大表，其实是在说“这一盒插件不只会一种本领”
很多人看到 capability 表就头大。其实它只是把“api 还能登记什么”一股脑摆出来了。
🧠
api.registerProvider(...)像登记一个新的大脑来源，让 OpenClaw 知道可以找谁来推理。
💬
api.registerChannel(...)像新开一扇沟通大门。
🪝
api.registerHook(...)像在某些关键时刻安排一个小哨兵，事情发生时它会自动跳出来看一眼、拦一下、或者补一手。
🌈 为什么说一个插件能装很多能力
因为同一盒插件不一定只能放一种零件。它完全可以又注册工具、又挂钩子、再顺手加个 HTTP 路由。
第七站
🚦 Required tool 和 optional tool，像“默认发放”与“先放仓库等你点头”
官方专门强调这一点，是因为很多工具并不适合一装上就默认给模型乱用。
✅ 默认工具
直接注册就会跟着插件一起上线，像开盒就附送的积木。
🧰
{ optional: true }像把这块积木先放在仓库架子上，不默认发给代理。用户得自己点头，把它加入允许名单。
tools: { allow: [\"workflow_tool\"] }这段配置像仓库管理员在清单上画勾：“好，这个可选工具现在允许领用了。”
📌 官方为什么建议副作用工具设成 optional
因为会改东西、会碰外部系统、会依赖额外二进制的工具，不该像糖果一样随手乱发。
第八站
🪵 Import conventions 和 checklist，看起来碎，其实是在防“盒子长得像插件，装上去却会摇晃”
官方后面这些注意事项并不花哨，但很重要。它们是在帮你做一盒不容易散架的插件。
📍 用子路径导入
官方让你从 openclaw/plugin-sdk/<subpath> 导，而不是整坨从根路径导。像从工具箱里拿具体抽屉，不要整箱全拖出来。
🧪 测试和
pnpm check像装箱前先摇一摇，看会不会散。不是走流程，而是避免你发布出去后别人一装就裂开。
📢 beta testing
像新学期开始前先试穿校服。官方更新快时，你的插件最好提前去 beta 版里过一遍，不然正式版一来就可能当场掉链子。
🎈 一句话收住
做插件这页的主线其实很朴素：先做清楚标签，再登记能力，再决定哪些默认发、哪些先锁起来，最后把整盒东西测稳后再交给别人装。