插件包与频道目录元信息

OpenClaw 最新插件文档里有一个很值得注意的变化：插件不再只是“一个单文件扩展”，而是已经支持 package pack 和频道目录元信息。

这意味着一个目录不仅能装一个插件，还能成为一组扩展能力的分发单元。

什么是 package pack

官方允许在插件目录里的 package.json 写入：

{
  "name": "my-pack",
  "openclaw": {
    "extensions": ["./src/safety.ts", "./src/tools.ts"]
  }
}

这里的含义是：

• 一个目录
• 一个 package
• 多个 extensions 入口

每个入口都会被当成一个插件来加载。

多入口时插件 id 怎么算

最新官方规则很明确：

• 如果 pack 只暴露一个扩展，通常直接使用 package 名称或显式 id
• 如果 pack 暴露多个扩展，默认 id 会变成 name/<fileBase>

也就是说，像上面的例子里，最终更接近：

• my-pack/safety
• my-pack/tools

这对配置层非常关键，因为后续：

• plugins.entries.<id>
• plugins.allow
• plugins.deny

都是按这个最终 id 来匹配的。

为什么 pack 比零散单文件更适合团队维护

如果你只是本地写一个小插件，单文件当然足够。

但一旦进入团队协作或私有扩展，package pack 的价值会变得明显：

• 可以把多项能力放在同一个依赖环境里
• 可以共用一个 node_modules
• 更适合统一版本和发布
• 更容易把“渠道 + 工具 + 安全规则”做成一套能力包

这类结构特别适合企业内私有扩展、团队内部工具包和渠道接入组合。

最新文档补了什么安全边界

这一块最值得注意的是官方现在加了明确 guardrail：

• openclaw.extensions 中的每个入口，经过 symlink 解析后都必须仍然位于插件目录内
• 任何试图逃出 package 目录的入口都会被拒绝

这条规则很重要，因为它直接避免了“一个看似正常的 pack，实际把任意路径文件挂进来”的风险。

插件依赖安装现在也更克制

官方文档还强调了一个很实用的细节：

• openclaw plugins install 安装插件依赖时使用 npm install --ignore-scripts

这意味着插件依赖里的 lifecycle scripts 不会自动执行。

官方因此也给出了明确建议：

• 尽量保持插件依赖树为纯 JS / TS
• 避免依赖必须通过 postinstall 编译的包

如果你在团队里分发 pack，这条建议几乎应该当成规范，而不是提示。

openclaw.channel 和 openclaw.install 是做什么的

在频道型插件里，官方现在支持通过 package 元信息提供更友好的引导信息：

• openclaw.channel
• openclaw.install

它们不是业务逻辑本身，而是给目录页、引导页、安装提示和 onboarding 使用的元信息。

可以把它理解成“频道插件的产品说明层”。

这类元信息通常会描述：

• 这是哪种渠道插件
• 是否需要额外环境准备
• 安装时要不要补某个依赖
• UI 或目录页应该展示什么提示

对于中文站用户来说，这意味着未来“渠道目录”会越来越不只是一个包名列表，而会更像可引导的接入目录。

pack 什么时候比多个独立插件更合适

更适合做成 pack 的情况通常包括：

• 多个插件共享同一依赖树
• 你希望一次性分发一个能力套件
• 同一团队维护多条相关扩展
• 某个渠道接入同时需要多个配套入口

如果只是一个单点扩展、依赖很少、生命周期独立，那单插件仍然更简单。

中文站建议的使用理解

可以把最新插件生态先分成三层来看：

• 单插件：解决一个明确扩展点
• Package pack：打包一组相关扩展
• 频道目录元信息：让安装和引导更可读

这三层叠起来，OpenClaw 的插件系统就不再只是“装一个 npm 包”，而更接近真正的扩展分发体系。

下一步推荐

• 插件清单与配置校验
• OpenClaw 插件系统怎么用
• 用 Webhooks 接外部系统