15. Plugins：OpenClaw 的扩展机制

这篇解决什么问题

OpenClaw 不把所有能力都塞进 core。

它有 extensions/、src/plugins/、src/plugin-sdk/，还在 package manifest 里支持声明 OpenClaw resources。

这说明 OpenClaw 的扩展机制是一等公民。

先看哪些目录

extensions/
src/plugins/
src/plugin-sdk/
src/plugin-state/
src/plugins/runtime/

package.json 的 files 里也能看到很多官方 extension，例如 discord、feishu、matrix、slack、whatsapp、qwen、deepseek、perplexity 等。

manifest 里能声明什么

官方 agent runtime architecture 文档给了资源包示例：

{
  "openclaw": {
    "extensions": ["extensions/index.ts"],
    "skills": ["skills/*.md"],
    "prompts": ["prompts/*.md"],
    "themes": ["themes/*.json"]
  }
}

也就是说，一个包不只可以提供代码扩展，还可以提供 skills、prompts、themes。

插件解决什么问题

插件适合：

新增 channel
新增 provider
新增工具能力
新增资源包
把某个外部系统接入 OpenClaw
把能力分发给其他用户

如果只是本地的一次性流程，写 Skill 可能更合适。

插件和 core 的边界

官方架构文档强调：插件使用 documented openclaw/plugin-sdk/* entrypoints，不应该 import src/** internals。

这点很重要。

src/** 是内部实现，可能变化。

plugin-sdk 才是插件稳定契约。

如果你要写插件

先问：

这个能力是否要复用/分发？
是否需要代码执行而不只是流程说明？
是否要接平台/API/provider？
是否需要保存插件状态？
是否应该通过 plugin-sdk 暴露？

如果答案是是，再走插件。

实践：插件边界核对

从 extensions/ 任选一个已有扩展，用 3—5 分钟查看它的 package manifest 和导入入口：确认它声明了哪些 OpenClaw resources，并检查代码是否通过 openclaw/plugin-sdk/* 使用稳定契约。只读检查，不改扩展。

完成标准

• 找到一个真实 extension；
• 能说出它提供 channel、provider、tool 或 resource 中的哪类能力；
• 找到其 manifest 或入口；
• 未把直接导入 src/** 当作推荐做法。

多走一步

将这个扩展与一个纯 Skill 对比，写下一条“为什么这里需要代码”的理由。

下一篇看什么

下一篇看 MCP。插件是 OpenClaw 自己的扩展体系，MCP 是外部工具协议。