Files
homeagent-sdk/docs/guide/capability-boundary.md
JianFeeeee d685789988 docs: 文档与站点链接随托管地迁移到 GitHub
go module 路径已迁到 `github.com/JianFeeeee/homeagentsdk`(见上一提交),
文档里的示例 import、Releases 下载地址、模块路径引用同步更新。

涉及:README.md、README_EN.md、docs/guide/{getting-started,first-plugin,
capability-boundary}.md、mkdocs.yml。

## 有意保留的 gitcode 提及

**不是漏改**,删了反而让文档说谎:

- README.md:「二进制的实际分发地址目前是 gitcode」——两个仓的 release
  附件不同步,只有二进制暂时还得去 gitcode 取
- mkdocs.yml:gitcode 镜像链接(国内直连更快,海外看 GitHub)
- docs/guide/getting-started.md:注明「gitcode 仅作国内镜像」

判据:**能照做的指引**优先于「链接好看」。读者照 README 下载 hmapdev
时,走 gitcode 是真能拿到东西的那条路。
2026-10-09 07:25:35 +08:00

4.6 KiB
Raw Blame History

能力边界:哪些 API 外部插件能用

HomeAgent 有两类插件:

类型 说明 分发
外部插件 第三方开发,编译成 .hmap 后安装 独立分发,可闭源
内置插件 编译进内核,init() 自注册 随内核发行,需合入主仓

SDK 包是同一个 github.com/JianFeeeee/homeagentsdk/sdk,但两类插件拿到的 能力不同:外部插件跑在独立进程里,由内核通过桥接注入能力(IPC,不是共享内存里的直接调用)。

本页说明边界在哪、为什么,以及怎么在写代码前就知道某个 API 是否可用。

一句话规则

公开 SDK 包里声明的符号,不等于外部插件拿得到。

原因是:有些能力只有进程内的内置插件才可能拥有(比如直接读事件发布通道、 直接注入到内核 IO 层)。外部插件通过桥接运行时拿到的是一份受注入的能力集合。

外部插件不可用的 API

这些 API 在公开包里存在,但在外部插件路径上拿不到。文档里每条都带 仅内置 标记, 完整清单见 仅内置插件可用。

API 外部插件的实际情况 该用什么
sdk.PluginSDK.Events() 恒为 nil。桥接运行时不注入 event subscriber(SetEventSubscriber 全仓无调用点) 桥接运行时已按你的声明完成 events.subscribe;Lua 插件用 sdk.events.subscribe
sdk.PluginSDK.SetEventSubscriber 无人调用 同上
UnregisterOutputChannel 桥接只注入 registrar、不注入 unregistrar,调用是静默无效(返回 nil,不报错也不注销) RegisterOutputChannel 可用;注销需重载插件
SocialAPI 的写操作 公开接口只有 6 个只读方法 读用 s.GetPerson 等;写需内置插件
EventSubscriber.Publish 公开接口刻意只有 Subscribe,没有 Publish 只订阅
PriorityL4 声明会被内核夹到 L3 用 L1–L3
RegisterChannel / ListChannels / OutputChan / InjectInput / InjectInterrupt 只存在于内核内部 SDK RegisterInputChannel / RegisterOutputChannel / InjectText 等公开方法
PluginMgr() 的完整能力 公开 PluginMgrAPI 只有 3 个方法(ReloadOne / ListLoadedPlugins / IsPluginDisabled) 就这 3 个;ReloadPlugins/Disable/Remove 属内部接口

!!! warning "两处常见的文档错误(本站已更正)" 1. PluginMgr() 不是「仅内置可用」。桥接模板显式注入了它 (base.SetPluginMgrAPI(procPluginMgr{})),公开 PluginMgrAPI 也注明 「外部插件可调用」。真正的区别是方法数量:公开面 3 个,内部面 9 个。 容易混淆是因为两个包里有同名但不同的接口: sdk.PluginMgrAPI(3 方法)与 internal/sdk.PluginManager(9 方法)。 2. Events() 恒为 nil 这件事以前没写清。旧文档把 Events() 当作 可用的订阅入口,但桥接运行时不注入 subscriber。外部插件的事件订阅 实际由生成的运行时通过 events.subscribe 完成。

判定依据来自哪里

本站的「仅内置」标记不是猜的,逐条来自:

  1. tools/hmapdev/templates/proc_main.go.tmpl —— 外部插件运行时实际注入 哪些能力,看 buildPluginSDK() 里的 base.Set* 调用。
  2. internal/sdk —— 内置插件用的完整接口,与公开包对照。
  3. 内核 RPC 协议表(internal/plugin/proc/protocol.go)—— 外部插件能发哪些请求。

每条裁定的具体依据写在该 API 的告警框里,可以直接核对。

怎么快速确认

  • 用 API 搜索 搜 API 名或功能描述,带 仅内置 的就是外部不可用
  • 直接看 仅内置插件可用 汇总页
  • 拿不准时,读 example/ 下的示例插件 —— 它们全是外部插件, 能被它们编译通过的写法,外部就一定可用

为什么这样设计

不是为了限制,而是IPC 边界决定了能力边界:外部插件跑在独立进程里, 内核只能通过显式的注入点把能力交过去。凡是需要「持有内核内部数据结构」 的能力(事件发布通道、IO 通道、插件注册表全量操作),进程外都无法安全暴露。

这套边界同时带来好处:插件崩溃不会带崩内核(进程隔离), 以及插件可以闭源(SDK 是 MIT,见首页)。