bd26c2a402
## 真实故障（2026-10-13，生产日志实证）
从 `<data>/log/week_2026-W41.tar.gz` 解出的历史日志 + `memory/context.json`
拿到完整错误文本：
napcat send_private_msg: Post "http://192.168.2.106:25570/send_private_msg":
context deadline exceeded (Client.Timeout exceeded while awaiting headers)
对应日志时序（~30s 恰好撞上客户端超时）：
17:50:07 executing tool: output_send__qq
17:50:47 result: 通过 [qq] 通道发送失败: ... Post "...": ... ← 40s
21:47:15 → 21:47:47 ← 32s
08:17:39 → 08:18:09 ← 30s
**消息其实发出去了**，证据有二：
① agent 自己在上下文里总结（memory/context.json 原文）：
「其余几次 send 是 napcat 的 25570 接口超时重试，用户只收到一份，不会刷屏」
「napcat 这会儿接口有点不稳（好几次 context deadline exceeded），
不过关键的那一发是成功的」
② 同一内容重试后用户只收到一份 —— 那是 qq 循环保险拦住的，属侥幸而非正确行为。
根因：`httpClient.Timeout = 30s` 被**查询与发送共用**。而 QQ 发送要经
NapCat 的 `NodeIKernelMsgService/sendMsg`，慢时响应头 30s 回不来 ⇒
把已送达的消息报成失败 ⇒ 模型重试。
## 另一个独立缺陷：不校验 OneBot retcode
`napcat()` 原来只看 HTTP 通不通、JSON 能不能解，**从不看响应体里的
成败字段**。而 OneBot v11 的成败在 body 里：
成功 {"status":"ok","retcode":0,"data":{"message_id":...}}
失败 {"status":"failed","retcode":100,"message":"..."}
或 {"data":null,"message":"Timeout: NTEvent ...sendMsg","status":"failed"}
历史日志里实测到 NapCat 返回 `data:null` + `sendMsg Timeout`（真失败）
却被当作发送成功。两个方向都错，必须靠 retcode 判定。
## 改动
- 新增 `sendClient`（120s + Transport 显式配 `IdleConnTimeout`/`ResponseHeaderTimeout`）。
发送类端点（send_private_msg / send_group_msg / send_msg）走它；查询类
保持 30s（幂等，快速失败更利于排查）。
- `Transport.IdleConnTimeout=30s`：默认 Transport 的空闲连接无上限等待，
复用对端已单向关闭的 keep-alive 连接会得到"请求已写入/对端已处理，
本地读响应 EOF"——又一种「已发送却报失败」。
- `napcat()` 校验 OneBot `retcode`/`status`，失败转 error。
- 超时单独包 `errNapcatTimeout`，错误文案明写「**可能已送达并已发出，
不要盲目重发**」——只说"失败"会诱发模型重发 → 重复消息。
## 判据（4 条，两条经变异测试修正）
- `TestOneBotError_FailedResponses`：7 组 retcode/status 组合的判定
- `TestNapcatConvertsOneBotFailureToError`：**端到端**——napcat() 必须把
OneBot 失败转 error。★ 变异（删掉 napcat() 里的 oneBotError 调用）
实测发现：只测 oneBotError 的判据照样全绿（判据没穿过调用链）
⇒ 补这条才咬住。
- `TestNapcatSendUsesSendClient`：**真的验证路由**（用 Transport 重写 host
观测哪个 client 实际发了请求）。★ 变异（删掉路由分支）实测发现：
只断言两个 client 的 Timeout 字段值照样全绿 ⇒ 重写为观测实际请求。
- `TestNapcatTimeoutErrorIsActionable`：超时错误必须含「可能已送达」
与「不要盲目重发」
27 条判据全绿（含既有 23 条）。
qq · QQ 消息桥接
通过 NapCat 把 QQ 接成 HomeAgent 的一个 IO 通道： 让 agent 收发 QQ 消息、读群/好友信息、传文件。
⚠️ 这是安全敏感插件：它让外部 QQ 用户能触达 agent 的工具。 本文档的「权限模型」一节请务必读完。
通道与钩子
| 类型 | 名称 | 说明 |
|---|---|---|
| 出站 | qq |
CapText + CapFile + CapImage + CapAudio；发消息/文件给 QQ |
| 入站 | qq |
NoMemory: true + Cleaner + RecallPolicy: None |
四个阶段钩子（全部 StageScopeGlobal）：
| 钩子 | 作用 |
|---|---|
on_input |
把本轮 QQ 身份绑到帧上 |
before_toolcall |
权限门：逐个工具判断是否放行 |
post_action |
清掉被拒绝时模型已经吐出的废话 |
after_output |
收尾时清理插件全局身份 |
工具（20 个）
| 工具 | 说明 |
|---|---|
qq_get_message |
按 message_id 取消息正文、发送者、附件 |
qq_get_history |
取群/私聊最近历史消息 |
qq_list_chats |
会话列表（按最新消息排序，带未读数与摘要） |
qq_mark_read |
把某会话未读数清零 |
qq_send_file |
发文件/图片（私聊或群聊） |
qq_get_groups |
群列表，可按关键词搜 |
qq_get_friends |
好友列表，可按昵称/备注搜 |
qq_get_recent_contacts |
最近有消息的联系人与群 |
qq_resolve_name / qq_resolve_nickname |
名字 ↔ QQ 号互查 |
qq_get_group_member_info |
群成员信息 |
qq_group_manage |
群综合管理（见下） |
qq_friend_action |
好友操作 |
qq_get_group_files |
群文件列表 |
qq_download_file / qq_upload_group_file / qq_get_download_tasks |
文件传输与任务 |
qq_read_document |
读 QQ 传来的文档 |
qq_video_download |
下载视频 |
qq_send_like |
点赞 |
qq_group_manage 一个工具承载多种操作（command 参数）：
leave 退群、kick 踢人、ban/unban 禁言解禁、rename 改名、mute-all 全员禁言、
set-card 设名片、set-admin 设管理、set-title 设头衔、member-list、group-info、
msg-history、recall 撤回、pin-msg 精华、list-files、pending-requests、folder-create 等。
破坏性操作（leave/kick/ban/unban/rename/mute-all/set-card/set-admin/
set-title/recall/pin-msg/folder-create）必须显式传 confirm: true。
权限模型
这是本插件最重要的部分。
身份分级
| 身份 | 权限 |
|---|---|
| owner（Bot 所有者） | 私聊或群聊均完整放行 |
| 普通 QQ 用户 | 只放行白名单内的工具 |
身份必须「绑帧」，不能只存插件全局
源码注释记录了两个真实故障，这就是绑帧的原因：
- 中断抢占后身份丢失：中断会抢占当前轮、把现场压栈。中断轮收尾时
after_output会清空插件全局身份；随后外层被恢复（resumeTask复用同一帧、 不重跑on_input）。若身份只存全局，恢复后的外层就是"无身份"，before_toolcall在!auth.active处直接返回 —— 整个权限门失效。 - 运行中到达的消息改写身份：新消息会调
activateAuthContext改写全局身份， 把正在跑的那一轮换成另一方的身份（换高=越权，换低=误拒）。
帧上的 Extra 随帧一起压栈/恢复，正好是"这一轮的身份"。
合并取最小权限
多来源被内核合并到同一推理时，权限取交集而非并集：
p.auth.owner = p.auth.owner && next.owner
防的是"非所有者请求 + 随后所有者消息"意外把前一个请求提权。
硬私有工具
非所有者一律拒绝（不看白名单），按前缀拦截：
calendar_、email_、mail_、agentmail_、memory_、knowledge_、device_、
devicectl_、terminal_、shell_、command_、exec_、filesystem_、agentfs_、
config_、settings_、plugin_、plugins_，
外加 read_file、write_file、edit_file、delete_file、list_files、run_command、
homeagent_config、homeagent_restart、output_send__email、output_send__mail。
参数与会话一致性校验
光看工具名不够，还要检查参数指向的会话与当前身份一致，否则可以拿别人的
message_id 去读别处内容：
- 带
message_id的工具：该 ID 必须属于当前 QQ 会话（lookupMsgRef校验 peer 与群/私聊类型）。 get_group_member_info/get_group_files：group_id必须是当前群。
频率与重复控制
| 键 | 作用 |
|---|---|
max_qq_tool_calls |
单轮工具调用上限 |
max_qq_output_calls |
单轮输出调用上限 |
max_duplicate_qq_send |
重复发送上限，防刷屏 |
batch_window_ms / batch_max_ms |
消息合批窗口 |
被拒时只允许发一次权鉴说明，之后锁止本轮剩余工具调用
（clearDeniedResponse 再把模型已写出的内容清掉，避免输出里带一堆"我不能…"）。
配置项
连接
| 键 | 默认 | 说明 |
|---|---|---|
napcat_url |
— | NapCat 服务地址 |
listen |
— | 本插件 HTTP 监听地址 |
webhook_token |
— | webhook 校验令牌 |
身份与准入
| 键 | 默认 | 说明 |
|---|---|---|
owner |
空 | Bot 所有者 QQ 列表（逗号分隔），拥有完整权限 |
admin |
空 | 旧配置名，owner 为空时作为所有者列表（兼容用） |
dm_policy |
open |
私聊策略：open / allowlist / disabled |
allow_from |
空 | 私聊白名单（QQ 号，逗号分隔） |
group_policy |
open |
群聊策略：open / allowlist / disabled |
group_allow_from |
空 | 群白名单 |
private_tool_allowlist |
空 | 私聊下非所有者可用的工具 |
group_tool_allowlists |
空 | 按群配置的工具白名单 |
文件与转发
| 键 | 说明 |
|---|---|
files_dir |
本地文件目录 |
remote_dir |
供 NapCat 容器访问的目录（发文件前先复制到这里） |
agentfs_dir |
agent 文件系统目录 |
forward_rules |
JSON 数组，每项 {group_id,host,port,password,template}：匹配的群消息经 RCON 转发到 Minecraft；template 支持 {nickname} / {message} 占位 |
部署前提
需要自行部署 NapCat（本插件不含 QQ 协议实现，只是 NapCat 的客户端）。
发文件前会先把文件复制到 remote_dir，因为 NapCat 通常在容器里，看不到宿主任意路径。
测试
go test -count=1 -race ./...
含权限门与绑帧的回归测试。改动权限相关代码后务必跑 -race。
构建
hmapdev build