|
|
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 |
|
|
|
a01fe21ab1
|
feat(qq): 同一会话连续消息合并为一次中断 + 示例 SDK 指回仓库源码
需求（jianf）：同一个人连发的数条消息应打包成一次中断，别逐条唤醒 Agent。
- debounce 合并：同一会话 + 同一发送者（群聊按 群号+QQ、私聊按 QQ）在
batch_window_ms（默认 1500）内的连续消息合成一批，每来一条重置计时；
整批不超过 batch_max_ms（默认 30000），避免对方持续刷屏时一直不投。
- n>1 时中断说明「短时间连续发来 N 条」并列出 message_id，建议一次
get_history 拿全上下文；n==1 沿用原文，行为与合并前逐字一致。
- 可配置 batch_window_ms / batch_max_ms，0 = 关闭合并（逐条投递）。
- Stop 时 flush 未到点批次，别把对方消息吞掉。
- 新增 4 条测试（同发送者合并 / 不同发送者不合并 / 窗口 0 逐条 / 单条沿用原文）。
顺带：deepsearch / vikunja 的 go.mod 与 plg.json 此前指向本地安装的 SDK 1.2.0，
导致无法用当前 SDK 重编（缺 InjectOptions.Priority）。改回 ../../ 仓库源码，
与其余示例一致。
|
2026-09-14 16:09:45 +08:00 |
|
|
|
4482235312
|
fix(vikunja): body 里的 ID 必须是 JSON 数字（建任务/指派在 v2 下必定 422）
线上真调用暴露：vikunja_task_create 把 project_id 当字符串发出 →
422 validation failed: expected integer at body.project_id。同类的还有指派，
而且 v2 的 assignees **根本不接受 username 字段**（422 unexpected property），
两个分支都是坏的。单测没盖到，因为从未发过真实请求体。
实测（vikunja v2.6.0，2026-09-12）：
{"project_id":"1"} → 422 expected integer
{"user_id":"1"} → 422 expected integer
{"username":"jianf"} → 422 unexpected property
{"user_id":1} → 201 ✓
{"label_id":1} → 201 ✓（插件本来就 Atoi，无需改）
修法：
- taskBody：project_id 走 parseID（数字）
- 新增 resolveUserID：用户名 → 数字 id，查 GET /users?q=（v1 用 ?s=）；
**只认精确匹配**，不做「只有一条就用它」的模糊兜底 —— 指派是写别人任务的动作，猜错人更贵
- assigneeBody：v2 只发 {"user_id":N}，不再带 username
- task_assignees remove：路径也用解析后的数字 id
新增 5 项回归测试钉住请求体形状（数字 project_id / user_id、无 username 字段、
数字 ID 不查用户表、移除走数字路径、未知用户给可读错误）。
版本 1.0.0 → 1.0.1。线上复验：create(project_id=1, assignees=jianf) 不再报错、
add→list 显示 jianf、标签 add/remove 正常，测试数据已清理（任务/标签残留 0）。
|
2026-09-12 23:43:08 +08:00 |
|
|
|
4cf2df5be6
|
feat(vikunja): Vikunja 任务管理插件（28 工具）
token 走 password+Secret 配置项、每次调用前 ensure() 重读（换 token 无需重启）；
v1/v2 差异在插件内处理（建任务 PUT/POST、改任务整对象/PATCH、搜索 ?s=/?q=、
标签对象/{label_id}、TimeEntry 无 seconds 语义）；16 项单测 + 沙盒 homed 实测 28 工具全注册。
|
2026-09-12 23:16:33 +08:00 |
|
