mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-11-05 16:57:32 +00:00
c9be04fdac
## 根因（4ab888c 的自检抓出来的）
4ab888c 在发送前加了配对自检，生产日志立刻指出真正来源：
★ dropped 1 unpaired tool message(s) before send (names: [qq_call_state])
顺着工具名查 context.json，脏帧是决定性的：
[42] tool_calls = [qq_call_state, output_send__qq]
tool_results = [output_send__qq] ← call_state 从未落盘
该帧自己的记录写了原因：qq_call_state 被 QQ 插件的来源权限策略拦下
（判定为"非所有者私聊"）。
## 缺陷位置
stepToolBegin 的顺序是「先记 call，再判能不能执行」：
f.appendToolCallRecord(tc) // ← 先落 ToolCalls
if a.runStage(sdk.StageBeforeToolcall, …) {
f.Msgs 补一条 role=tool // ← 模型能看到
f.ToolIdx++
return outcomeContinue // ← 但没写 ToolResults
}
同一函数里还有一处同构分支（插件崩溃态跳过执行），同样只补 f.Msgs。
task.go 顶部的注释写着「ToolCalls 与 ToolResults 通过 CallID 配对；
两者都由 appendToolCallRecord 同步追加」—— 这个不变量在**提前返回路径**
上被违反了。
## 为什么这会变成会话级故障
ContextEvent{ToolCalls: 2, ToolResults: 1}
⇒ 渲染出 assistant(tool_calls=[c1,c2]) 但只有 c1 的结果
⇒ 上游硬拒绝（HTTP 400）：
An assistant message with 'tool_calls' must be followed by tool messages
responding to each 'tool_call_id'. (insufficient tool messages…)
关键在于脏数据**持久化进 context.json**，之后每一轮都带着它，直到自检剔掉。
## 修法
新增 appendToolResultRecord（与 appendToolCallRecord 成对的公开入口），
在两处提前返回各补一行。
判定"被拒绝/被跳过"≠"没有结果"：拒绝原因本身就是结果，而且模型确实
从 f.Msgs 看到了它。落 context 的那份必须与发给模型的一致。
并发路径（stepToolBatch）没有这个问题 —— runOneTool 只返回结果，
join 后的顺序收尾段无条件写 ToolResults（含被拒绝项）。
## 判据（2 条，2 次变异全部实测变红）
TestDeniedToolStillRecordsResult
注册一个真的会拒绝的 before_toolcall 钩子，跑完整一轮，
断言落进 context 的每个 call 都有 result，且拒绝原因文本一致。
变异：删掉拒绝分支那行 ⇒ "★ call call_deny_1 (denied_tool) 没有对应的
ToolResults"（实测红）
TestUnhealthyPluginSkipStillRecordsResult
钉住第二条同构分支。
变异：删掉跳过分支那行 ⇒ "★ 被跳过的工具 call_unhealthy_1 没落
ToolResults —— 同型失配，上游 400"（实测红）
两条都走真实链路（真的调 runStage / 真的置崩溃态），不是只测
appendToolResultRecord 这个函数本身。
## 顺带发现一个独立缺陷（未修，不在本次范围）
写第二条判据时发现：插件崩溃熔断**实际从不生效**。
recordCrash 标记 Unhealthy=true，但从不设置 LastReload
⇒ isHealthy 的冷却判据 time.Since(r.LastReload) > reloadCooldown
在 LastReload 为零值时恒为真（Since 是巨大的正数）
⇒ 判定"冷却期早已过去" ⇒ 立刻自愈
实测：连续 3 次 recordCrash 后 needReload=true、Unhealthy=true，
紧接着 isHealthy 返回 true。
后果：task.go:1065/1135 的「插件崩溃态跳过执行」分支实际走不到。
这条应单独修并单独钉，本提交的判据用直达状态绕过它（注释已写明原因）。
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 62 包全过，0 FAIL
干净检出（worktree） build + TestDenied/TestUnhealthy 全绿