Files
homeagent-sdk/example/sanitizer
JianFeeeee 74e2c654ed feat(sdk): 22 个示例插件配齐 skill + 三态启动声明 + 打包期校验
## 用户的三条要求

1. 「所有插件都默认自启会占启动时间,还在 llms 上下文塞大量工具」
   ⇒ 纯工具型改为按需加载,靠 skill 让 agent 知道要先拉起。
2. 「会向 agent 注入输入的部分插件不能这样做」
   ⇒ 9 个必须常驻,其余 13 个按需。
3. 「sdk 是不是没有暴露插件声明自身行为的方案」
   ⇒ 对:auto_start 只在 internal/plugin/manifest.go 有,SDK 零命中。

## 定级依据(代码证据,不是猜描述)

注入 / 钩子 ⇒ 必须常驻(9 个):

	qq         HTTP 监听 NapCat 推送,消息到达要立刻注入
	rss        轮询订阅源,新文章主动推送
	calendar   30s ticker 检查提醒
	memo       5min ticker 检查待办到期
	a2a        TCP 监听外部 Agent 请求
	acp        TCP 监听 ACP 客户端
	browser    ticker + 长命令完成回调
	sanitizer  注册 stage 钩子(无工具,要每轮生效)
	luademo    注册 stage 钩子做示范

纯工具型 ⇒ 按需(13 个):
	weather ocr music bili ai_image files editdoc deepsearch
	plugindev recoverydiag vanblog vikunja commondev

★ commondev 值得单独说:它虽然有 6 处 Inject 调用,但**注入源是自己的
sidecar 完成回投**,而 sidecar 只在 commondev_agent_up 时才拉起
(Start() 里不启 sidecar,通道也在 agent_up 时才注册)。所以没有 agent
调用它时,它不需要做任何事 —— 可以按需。44 个工具 ≈726 tokens 省下来可观。

## 改动

 · 22 个插件各配一个 skill,写明:何时用、先 plugin_start、
   工具清单、**用 plugin_stop 而不是 plugin_disable**
 · 13 个 plg.json 加 `auto_start: false`
 · `sdk/autostart.go`:把三态语义与"按需插件必须有 skill"的理由写进公开 SDK
 · hmapdev 打包期校验:`auto_start=false` 但无 skill/ 目录 ⇒ 直接 exit 1
   (理由:缺 skill 的按需插件**等价于没装**,比没装更糟 —— 占着磁盘让人以为可用)
 · 修 Lua 打包路径:它**完全不走** rawfile/skill 收集,luademo 的 skill 永远打不进去
 · 修 build-examples.sh:原来 `[ ! -x ]` 判"二进制在不在",改了 hmapdev 源码后
   重新打包**仍用旧工具链**(实测:luademo 的 skill 一直是 0)
 · 补 mocksdk.ToolDef.Timeout(上一轮加 ToolDef.Timeout 时漏了镜像)

## 判据

 · TestHasSkillDirRequiresRealSkillMd(空目录/.gitkeep/无 SKILL.md 都不算)
 · TestBuildRejectsOnDemandWithoutSkill(打包期必须真拦住 + exit 1)
 · TestLuaPackagingCollectsSkillAndRawfiles(**验代码行**,不验注释 —— 第一版
   只查符号存在,把 createHmapWithRaw 换回 createHmap 判据照样通过)

## 踩过的坑

 · Lua 分支的结束边界原是 `// Resolve build config`,但那个注释在文件里
   **出现多次**(Go 路径里也有),用它截取会把 Go 分支一起包进来 ⇒
   变异测不出。改成截到 Lua 分支自己的 `return` + `}`。
2026-10-18 13:21:47 +08:00
..

sanitizer · 文本清洗

不注册任何工具,只挂三个阶段钩子,在 Agent 全链路上洗掉两类污染:

  1. 坏字节:坏 UTF-8、U+FFFD(替换符)、ANSI 转义序列
  2. 思维泄漏:LLM 输出里残留的工具调用标记

为什么需要它

坏字节会被 LLM 复读。一次工具返回乱码(比如源码里带 ANSI 颜色码、或二进制片段被当文本读出来), 这些字节会进上下文,之后模型每次生成都可能把它抄一遍 —— 越滚越脏。 在每个入口洗掉,比事后清理便宜得多。

思维泄漏则是另一种:模型有时把 <tool_call>...</tool_call> 这类内部标记直接写进正文, 用户就看到一堆不该出现的 XML。

挂载的三个阶段

阶段 处理对象 作用
on_input ctx.RawMessage 洗用户输入,脏字节不进后续链路
after_toolcall ctx.ToolResults 洗工具结果,坏字节不进 LLM 上下文
post_action ctx.LLMText 洗模型输出:先清思维泄漏,再清乱码

每次有改动都打一行日志(cleaned N bytes),便于确认它真的在工作而不是静默失败。

识别哪些泄漏形态

按正则匹配多种标记写法,覆盖不同模型家族的习惯:

  • <tool_call>…</tool_call>、<invoke>…</invoke>、<tool>…</tool>
  • <function>…</function>
  • 上述标记包在 xml / json 代码块里的形态
  • 中文括号变体:【tool_call】…【/tool_call】

实现要点

  • 依赖 ABI v2 的 stage 写回能力:插件对 StageContext 的修改会同步回内核。 在 v1 上改了不生效。
  • 读写 StageContext 时按约定加 ctx.Lock()。

构建

go build -buildmode=plugin -o sanitizer.so .

或经 hmapdev build 打包为 .hmap。