Plugin entry
plugin-sdk/plugin-entry 像报名处，常见核心是 definePluginEntry。
Plugins 导读
Plugin SDK Subpaths 是 openclaw/plugin-sdk 的分抽屉目录
这页列出插件作者可使用的窄子路径，并帮助维护者区分公共导出、兼容导出和仓库内部私有测试入口。新代码应优先使用明确子路径，避免继续依赖 deprecated compatibility facades 或 local-only helpers。
先讲这一页到底在解决什么
Plugin SDK Subpaths 是 openclaw/plugin-sdk 的分抽屉目录
这页列出插件作者可使用的窄子路径，并帮助维护者区分公共导出、兼容导出和仓库内部私有测试入口。新代码应优先使用明确子路径，避免继续依赖 deprecated compatibility facades 或 local-only helpers。
第一站
为什么要分抽屉，而不是一个大入口
SDK 子路径像工具箱里的标签。每个标签只公开一小组相关工具，这样插件作者知道自己依赖了什么，维护者也能看清哪些 API 真的有人使用。
好处一
依赖更清楚：看到 import 路径，就知道这段代码在用入口、运行时、测试还是频道工具。
好处二
升级更安全：维护者可以逐个抽屉检查，不用担心一个大 barrel 里什么都被外部拿走。
好处三
边界更干净：公开 API、兼容 API、仓库内部测试 API 不会混在一起。
记忆法
像图书馆按书架找书：你要食谱，就去食谱架；不要把全馆书打包装回家。
第二站
常用公开抽屉先认这几类
官方表格列了很多 key exports。低龄友好地看，可以先按“写插件会遇到的阶段”来记。
Runtime helpers
运行时助手像工具台，帮插件在真正工作时拿到上下文、注册能力或处理结果。
Channel pieces
频道相关子路径像电话线、信箱和消息纸，适合写聊天通道插件。
Testing helpers
测试子路径像练习场，帮你确认插件合同没有写歪。
第三站
deprecated 不等于立刻坏掉，而是“别再给新房子用旧水管”
官方保留了一些兼容入口，是为了旧插件还能跑、测试套件还能过。但新代码继续依赖它们，会让未来迁移越来越难。
兼容和测试 helper
这些路径还在 package exports 里，主要照顾旧插件和 OpenClaw 自己的测试，不适合作为新插件的首选。
少人使用的 public subpath
有些入口公开过一段时间，但生产插件很少用。它们保留可导入，只是新代码应该找更聚焦的替代。
broad barrels
大桶式 re-export 能省 import，但边界太宽。新代码用窄入口，像只拿今天需要的积木。
维护者怎么查
scripts/lib/plugin-sdk-entrypoints.json 是生成出来的入口清单；package exports 是真正对外公开的子集。
第四站
reserved helper subpaths 像“员工专用抽屉”
有些子路径是 bundled plugin 自己的兼容表面，不是给所有插件作者用的普通 SDK。
plugin-sdk/codex-mcp-projection属于 Codex 相关 bundled plugin 的保留辅助面，不是通用插件 API。
plugin-sdk/codex-native-task-runtime同样是插件所有者自己的保留入口，跨 owner 乱用会被边界检查挡住。
为什么要挡
如果一个插件偷偷拿另一个插件的内部工具，那个工具一改名，外部插件就会像踩空台阶。
正确做法
需要通用能力时，推动它进入真正公开、稳定、文档化的 SDK 子路径。
第五站
写 import 前先问四个小问题
它公开吗
确认路径在 package exports 里，而不是只在源码里碰巧存在。
它活跃吗
优先选官方仍推荐的新入口，避开 deprecated rare 或 broad barrel。
它够窄吗
能从小抽屉拿，就不要从大桶入口拿。
它归谁
不要跨插件 owner 使用 reserved helper，除非文档明确说可以。
最后记住
SDK 子路径的核心不是“路径很多”，而是“边界清楚”
第一次写插件时，先看 SDK overview 和 SDK setup；真正落到 import 时，再回到这页挑最小、最稳、最公开的抽屉。