mirror of
https://gitcode.com/JianFeeeee/homeagent-sdk.git
synced 2026-10-31 14:27:30 +00:00
74e2c654ed
## 用户的三条要求 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` + `}`。
recoverydiag · 快速检查 / 崩溃取证
给 guard 与 failback 用的确定性诊断工具集。
设计基调（源码原话）：返回结论而非原文，确定性检出，不消耗 LLM token。 崩溃后最忌讳的是把几万行日志塞进模型上下文让它"看看"，那既慢又不可靠 —— 这里每个工具都在本地算出结论再返回。
工具
| 工具 | 说明 |
|---|---|
recoverydiag_diag_triage |
快速分诊：按退出码 / 信号 / 存活状态粗分类别（进程死亡 vs 配置类不可达 vs 正常） |
recoverydiag_diag_db |
config.db 完整性（PRAGMA integrity_check）+ LLM 源解析校验（core.llm.sources.* 必备字段），逐项 ok/fail |
recoverydiag_diag_log_scan |
在日志目录的时间窗内统计已知错误签名（panic / OOM / 网络不可达 / provider 失败 / sql / 致命）出现次数，给出主导结论 |
recoverydiag_diag_delta |
对比 baseline（上次 good 快照/目录）与现状，列出 created / modified / deleted 清单与摘要，判定"改了什么" |
recoverydiag_diag_loc |
综合前四项结论，按因果强度正交排序定位根因并给出推荐恢复动作 |
用法顺序
diag_triage → diag_db → diag_log_scan → diag_delta → diag_loc
（各自独立，可只跑需要的） （要传前四项的结论）
diag_loc 需要你把它余下的结论作为参数传进去（triage / db / log / delta 四个对象），
它不自己去调 —— 这样它只做归因，不重复执行。
配置项
| 键 | 默认 | 说明 |
|---|---|---|
db_check_cmd |
auto |
diag_db 用的 sqlite3 命令。留空=auto：可用时用 sqlite3，缺失则回退读内核 Settings |
recovery_kb_dir |
空 | diag_loc 结论 JSON 的落盘目录。缺省 <data_dir>/recovery_kb |
不注册通道与钩子
本插件只提供工具，不订阅输入、不挂阶段钩子 —— 它是被 guard 或 agent 主动调用的， 不做后台干预。
测试
go test -count=1 ./...
diag_test.go 覆盖各诊断项的判定逻辑。
构建
hmapdev build