|
|
7e1169bcda
|
feat(kernel): 内置工具注册进 ToolAPI 面（方案 B，补真机实跑发现的架构缺口）
真机实跑实证（独立实例 /tmp/seqtest，未触碰生产）：
seq_run 报「工具 knowledge_list 不存在或未注册」，
而**同一轮模型直接调 knowledge_list 是成功的**。
根因：`memory_*` / `knowledge_*` / `doc_*` / `person_*` 这 20+ 个是
**内核内置**工具，在 core.executeToolCallInner 里按**前缀分派**，
由 buildToolDefs 直接生成 schema，**从不进 StageHost / IOManager**
⇒ ToolAPI（只有插件工具 + IO 设备工具）既查不到也调不了。
后果：序列只能编排插件/设备工具，无法编排记忆/知识/文档/人物
——恰恰是最常用的能力。
方案 B 的实现：
· internal/sdk: 新增 BuiltinProvider（Defs/Exec）与 SetBuiltinProvider。
用**晚绑定注入**而非让 toolImpl 依赖 core，理由：ToolAPI 是**全局单例**
却需要 per-agent 数据（驻留子是轻量内核，memory 为 nil；内置工具可见性
由 `if a.memory != nil` 等门控）。sdk 不能依赖 core（方向反了）。
· internal/sdk/tool_impl.go: ToolDefByName / ExecuteTool 补查内置工具。
⚠️ ExecuteTool 只在「io 确实没有该工具」时才转内置；io 的**执行失败**
必须如实上抛 —— 否则会把「设备离线」误报成「工具不存在」，让调用方
按 missing 策略跳过（与 P3 修过的父 io 吞错误同一族陷阱）。
内置工具**默认不声明 ParallelSafe**（含 SQLite 写与召回）。
· internal/agent/core/builtin_toolapi.go: Agent 侧 provider。
★ Defs **复用 buildToolDefs 的同一批生成逻辑**（筛出不在
StageHost/IOManager 中的那些），保证"模型看得到什么"与"插件看得到什么"
门控完全一致 —— 避免两套语义。
Exec 复用 executeToolCall 完整路径（授权闸 + 异常处理）。
· cmd/homed/bootstrap.go: agent 构造后注入。
★ 不会让模型看到重复工具（已核实）：模型侧走 buildToolDefs
（a.io / a.stageHost **直调**），ToolAPI 只经 PluginSDK.Tool() 暴露给插件
—— 两条不重叠的路径。
判据（builtin_toolapi_test.go，6 条）：
· 内置工具能从 ToolAPI 查到
· ★ 查到 ≠ 调得通：必须真的能执行
· 门控语义保持：未接 memory/knowledge 时不得声称有那些工具
· ★ 接了 knowledge 时必须可见（这正是要补的缺口）
· ToolAPI 上"不存在"必须是类型化 not-found（供 seq 的 missing 策略用）
· 内置工具默认不声明并发安全
真机复验（同一隔离实例，新二进制）：
序列 "smoke2" 执行完毕（1/1 组）— 工具 1 个
变量槽: summary = cangjie/central-repo/agreement/...
⇒ knowledge_list 成功执行并回填具名槽。上一次的「不存在或未注册」已消除。
已知局限（记入待定）：ToolAPI 单例而内置工具面是 per-agent，
多 agent 下看到的是"最近一个注入者"的面。本次不解决。
|
2026-09-27 13:40:22 +08:00 |
|
|
|
994f198bc5
|
fix(security): 设备授权闸下沉到 ToolAPI 路径（D4，堵住绕过）
问题：设备类工具的授权闸只存在于 core.executeToolCallInner
（toolcall.go:151-152），即**「agent 收到模型 tool_call」那条路径**。
而 ToolAPI.ExecuteTool 是**另一条**独立执行入口，不经那道闸
⇒ 凡是走 ToolAPI 的调用都能绕过 AllowedOutputs。
实测范围**不止序列**：cli 插件的 /terminal 直接经 ToolAPI 调 agentcli 的
终端工具（cli/plugin.go:1038 的注释自陈"SDK 的 ToolAPI 已允许跨插件调用
工具"）。任何插件拿 ToolAPI 都能指挥未授权的设备。
改动：
· internal/sdk/tool.go: ToolAPI 新增 CanUse(toolName, args) bool。
**纯新增方法**，零值实现返回 true ⇒ 未实现者（存量插件、测试替身）
行为不变。
· internal/sdk/tool_impl.go: 实现 CanUse。判据只有一条——设备类工具按
`device/<id>` 查授权；非设备工具不受影响（闸的作用域必须窄，否则会把
所有工具锁死）。
授权查询走**可注入**的晚绑定闭包：toolImpl 在 internal/sdk，而
IsOutputAllowed 是 core.*Agent 的方法，sdk 不能依赖 core。
· internal/plugin/registry.go: 新增 SetDeviceAuthQuery。
· cmd/homed/bootstrap.go: 在 newMainAgent 末尾注入。⚠️ 必须在 agent
构造**之后**——判据要用 agent 自己的 allowedOutputs，而 registry 早于
agent 构造，故 registry 存的是晚绑定闭包。
判据（toolapi_auth_test.go，7 条），核心是**两条路径必须一致**：
· 收窄授权时 ToolAPI 路径同样被拦
· 已授权设备放行（防闸过严杀掉正常能力）
· 非设备工具不受影响
· 枚举类工具不受影响（与内核 TestDeviceToolAuth_EnumerationNotGated 同语义）
· 未配置白名单 = 完整授权
· ★ TestCanUseAgreesWithInnerPath：4 组用例逐例比对内核路径与 ToolAPI
路径的结论 —— 判定不同本身就是漏洞
· ★ TestCanUseMatchesInnerFailOpenOnMissingDeviceID：把现状
（缺 device_id 时**放行**）钉住。⚠️ 这是 fail-open，是既有的可疑设计
（core 的 TestDeviceToolAuth_* 依赖它），本次不擅自改语义；判据写明
"若要改成 fail-closed，必须两处同时改"。
过程中三次自伤：
1. 一度在 core 写了个 toolAPIRef —— **只实现部分方法的替身**是过度设计，
且两份实现必然漂移。改为判据直接用 sdk.NewTool(stageHost, iom)，
与插件侧走**同一个**实现。
2. 判据里又写了 `var _ = agentIO.DeviceOutput` 这种压 unused import 的
占位 hack（第二次犯这个），并重造了 strings.Contains。都已去掉。
3. 注入点一开始找错了位置（以为 newStageAndRegistry 能拿到 agent，
实际 pluginReg 是 main() 的局部变量）。核实 newMainAgent 的签名后
确认它同时持有 agent 与 pluginReg，注入点落在那里。
变异验证：让 CanUse 恒返回 true（还原成原缺口）⇒ 两条判据 FAIL，
其中一条直指「内核路径=false 而 ToolAPI 路径=true —— 两条路径判定不一致」。
回归：go build ./... 通过；go test ./internal/... 全绿。
|
2026-09-27 13:15:22 +08:00 |
|
|
|
0327419c88
|
feat(prompt): 提示词声明「同轮默认并行」及其例外（阶段 2.5）
⚠️ 本阶段有硬性顺序约束：必须在并行执行（阶段 2d）落地**之后**。
反序（先说"并发"、内核仍串行）会让提示词**对模型说谎** —— 模型据
"并发执行"推断安全性，写出真正依赖顺序的调用。宁可晚改，不可错改。
改动（tooldefs.go，buildSystemPrompt）：
· 新增【工具执行顺序】段，讲清四件事：
1. 同一条回复里的多个工具调用**默认并行**（同时跑），不是依次执行
2. **不要依赖执行顺序** —— 参数依赖前一个结果就分两轮
3. **例外一：同通道 output_send__ 保序**（用户可见消息顺序敏感）
4. **例外二：不并发安全的工具整批退回串行**（写类工具 / 未声明者）
· 顺带说明并发安全由**工具自己声明**（ParallelSafe），不由模型判断
· 改掉 spawn_child 的落空表述：原文「应并行 spawn，不要自己串行逐个执行」
在并行化之前是**落空**的（模型照做，内核仍串行）。改为机制性表述，
并补一句「一次 spawn 只是启动动作，要拿结果仍需另一次 child_result」。
⚠️ 措辞刻意与 batchRunnable 的**真实**判据一致（全批 ParallelSafe 才并发
+ 同通道保序），而不是理想化表述 —— 提示词与实现不符，比不说更坏。
判据（prompt_parallel_test.go，5 条）：
· 四要点齐全（并行 / 顺序 / 保序 / 并发安全声明）
· ★ 必须同时讲**例外** —— 只讲并行就是"说谎"的那一种
· 同通道保序须显式说明（保序是内核兜底，模型不知情就会浪费它）
· spawn_child 不再含旧的落空措辞
· 回归防护：既有要点（输出规则 / output_list_channels / 工具能力 / 记忆清理）不丢
★ 判据里的一次自伤：先写了 spawnChildDescription(a) 这个**不存在**的
helper（"工具名反查描述"），编译失败后改为 toolDefDescription —— 内部
遍历 buildToolDefs 的**真实产物**。判据必须对着代码真实输出，不能另建一套
注册表。
变异验证：把两条例外改写成"以上适用于所有工具"⇒ 3 条判据 FAIL
（缺"保序"、缺"例外"、同通道未说明）。即"提示词说谎"这一失败模式
现已被判据覆盖。
回归：internal/agent/... internal/sdk/... internal/plugins/... 全绿（15 包）。
|
2026-09-27 11:55:33 +08:00 |
|
|
|
34c0df2705
|
feat(toolcall): 批次并发调度与同通道保序（阶段 2d，闭合 2c 判据缺口）
规则（三条全满足才并发）：
1. 批内 >1 个工具
2. **全部**工具声明 ParallelSafe —— 一个不声明就整批降级，不做部分并发
3. 不含需保序的同通道输出发送
SDK：
· ToolDef 加 ParallelSafe bool。⚠️ 零值 false 是刻意的：存量插件不改一行
就得到**保守**行为（整批串行），不会因升级被意外并发。声明它是责任
而非特权。纯新增字段，无签名变更。
· io.ToolDef 同步加该字段（设备/通道工具走 io 路径，只查 StageHost 会漏）。
core：
· 新增 StepToolBatch —— runTaskSteps 是单线程驱动状态机的，
「每步一个工具」的游标模型无法表达「一批同时跑」，故需独立 step。
· stepToolBatch：fan-out（每工具一 goroutine，各写自己的 toolCtxs[i]）
→ join → **按索引顺序**串行收尾（after_toolcall / 落消息 / 事件）。
收尾必须串行且按索引：f.Msgs 是共享切片，且按索引落才能让模型读到的
上下文顺序与它自己发出的顺序一致。
· runOneTool 抽出「before_toolcall + 执行」的单工具逻辑，串行/并发两条路共用。
· toolParallelSafe / batchRunnable 判据函数。
★ 修掉一个我自己引入的竞争：resolveTurnScenes 会把结果记进**共享**的
f.sceneDone / f.turnScene（memorypass.go:289）。最初在每个 goroutine 里
各调一次 —— 既是数据竞争，又会各自触发一次 EnterSceneWithHint，
重复计入场景强度（正是 sceneDone 注释警告过的问题）。改为在 fan-out
**之前**解析一次，goroutine 内只读。
判据（parallelsched_test.go，4 条）：
· 全批 ParallelSafe ⇒ 并发峰值 >= 2（用阻塞设备观察真实并发）
· 一个非 ParallelSafe ⇒ 整批串行，但**仍全部执行**
· 同 output_send__<通道> 连发 3 条 ⇒ 严格按声明顺序到达
· ★ 并发下每个工具的 ctx 只带自己的 ToolCalls、after 读到自己结果
★ 并关闭了 2c 的判据缺口：此前两条 2c 判据在**串行**下无法区分
per-tool 与单槽（变体验证后仍全绿）。新增的并发版判据在退回单槽时
触发 **6 处 DATA RACE 报告 + 串味断言失败**（dup:k_a 与 k_a 撞名）。
至此 2c 可记为已验证。
过程中三次自伤：
· resolveTurnScenes 竞争（上述）；
· 我的 harness 用 StageHost 注册 handler 遮蔽了设备工具，
slowDevice 根本没被调用（"实际 0"）——改为在 io.ToolDef 上声明；
· 批内并发峰值判据最初用 StageHost 声明 ParallelSafe，掩盖了
「设备工具也需要该字段」这一真实缺口。
回归：internal/agent/... internal/sdk/... internal/plugin/...
internal/plugins/... 全绿（17 包）；core 包 -race 全绿。
|
2026-09-27 11:27:24 +08:00 |
|
|
|
3d12e82f65
|
refactor(toolcall): StageContext 拆 per-tool，为并发执行消除共享槽（阶段 2c）
问题：f.StageCtx 是**单槽**，批内每个工具都覆写它（ToolCalls=[单元素]、
ToolResults 覆写、Results[0] 回读）。串行下看不出问题，但并发下
N 个 goroutine 同写一个 ctx = 数据竞争，且 after_toolcall 插件可能读到
**别的工具**的结果。
改动（task.go）：
· TaskFrame 增 toolCtxs []sdk.StageContext（每工具一份）
· buildToolContexts 在 stepLLM 设 PendingTools 时建池；
Extra **逐份浅拷贝**——共享同一 map 即竞争（stage handler 会写它）
· toolCtxFor(i) 取第 i 份，越界/未建时回落 f.StageCtx（测试替身安全）
· stepToolBegin（before_toolcall + 参数回填）、stepToolExec（写结果）、
stepToolAfter（读结果）三处全部切到 per-tool ctx
判据（toolbatch_test.go 追加两条）：
· 每个工具的 before_toolcall ctx 只带自己的 ToolCalls[0].Name，
且 Extra[output_channel] 逐份带过去（stage.go:18 依赖它）
· after_toolcall 读到的 Result 必须属于当前工具，不能是批内另一个的
★ 诚实记录：这两条判据在**串行**下**测不出与单槽的差别**——串行时
每工具跑完才进下一个，不存在交错。变体验证（toolCtxFor 退回单槽）后
判据仍全绿。故 2c 记为「实现已就位、判据未闭合」，真正判据必须与 2d
（并发执行）一起写，并以 -race 确认无竞争。已在执行计划中标注。
过程中两次自伤：
· 我的 harness 没设 Extra[output_channel]（那是 prepareInputTask 才写的，
task.go:380），判据一度报「产品缺陷」——核实后是我造的场景，已对齐生产；
· 阶段 1 的 TestStageCtxSuccessIsHonestEndToEnd 读 f.StageCtx.ToolResults，
拆分后失效——判据跟随新结构改为按批索引取 toolCtxs[i]，
断言的仍是内核产出的 Success 值本身。
顺带记录（非本次引入）：TestResidualKeep/Drop 偶发失败，根因是
offload_test.go 的 SpawnResident 起了子调度器 goroutine，而测试
enqueue 后无同步就读同一队列。干净基线 3/3 全绿属运气。已在计划中
记为待修，避免后续误判为并行化引入的回归。
|
2026-09-27 11:17:06 +08:00 |
|
|
|
28b42bcf0f
|
refactor(toolcall): 批内消息改为「一个 assistant 带全部 tool_calls」（阶段 2a）
问题：现状每个工具各自 append 一对（assistant[tool_calls=[tc]] + tool），
既不表达「这是一批」，也无法支撑并行：
· 产生 N 条 assistant 消息，同一段 assistant 文本语义上只该出现一次
· 并行下完成顺序不确定，若等结果回来再落消息，assistant 就必须等所有
结果齐了才能写——而 OpenAI 协议要求 assistant(tool_calls) 在结果**之前**
改动（task.go）：
· TaskFrame 增 assistantMsgIdx
· 新增 ensureBatchAssistant：惰性写入，全批只写**一条** assistant，
携带 f.PendingTools 全部 tool_calls；后续工具只补 tool 消息
· stepToolBegin 的 denied / unhealthy 分支与 stepToolAfter 统一改用它
· stepLLM 设 PendingTools 时清零 assistantMsgIdx
· msgContent 的 ContentOnce 归位移入 ensureBatchAssistant（仍是只挂第一条）
⚠️ 依赖：before_toolcall 阶段**不得**改写工具参数——已核实全仓无此用法
（grep ToolCalls[0].Arguments 赋值无结果）。若将来某插件要改写 args，
需改为「回填后重写该条 assistant」。该前提已写入代码注释。
判据（toolbatch_test.go 追加 TestBatchLayoutSingleAssistantCarriesAllToolCalls）：
· 带 tool_calls 的 assistant **恰好一条**且携带 2 个 tool_calls
· 其后紧跟 2 条 tool 消息且按声明顺序（c1、c2）
变异验证：让 ensureBatchAssistant 退化为「每工具一条」⇒ 判据 FAIL
「批内 assistant 应带 2 个 tool_calls，实际 1」。
stage 0.5 补的三条判据（配对完整性 / ContentOnce / denied 后继续）
在本改动后**仍然全绿**——它们正是为这种改动准备的保护网。
回归：internal/agent/... internal/sdk/... internal/plugins/... 全绿（18 包）。
|
2026-09-27 11:09:02 +08:00 |
|
|
|
25f5c53086
|
feat(io): 多模态块改 per-call 归档，为并行执行铺路（阶段 2b）
问题：ConsumeToolBlocks 此前是 **IOManager 级单队列**（取走即清空），
没有 call_id 维度。并行化后同批多个工具各自注入媒体时，后执行的
Consume 会**抢走**前一个的块 ⇒ 媒体挂到错误的 tool 消息上。而
task.go 里「媒体必须走 user message 且紧跟自己的 toolMsg」那条结论
是三轮实测才定下来的，并行会直接破坏它。多模态插件在 3 处调
SetToolBlocks（multimodal/plugin.go:136,246,320），是真实使用面。
改动：
· 字段 toolPendingBlocks: []interface{} → map[string][]interface{}
· 新增 SetToolBlocksFor / ConsumeToolBlocksFor / ClearToolBlocks（按 call_id）
· 保留 SetToolBlocks / ConsumeToolBlocks 作兼容入口（走 callID=""），
存量调用方与串行单工具场景不受影响；其注释写明并行下该路径不可靠
判据（toolblocks_test.go，4 条）：
· 两个 call 各自注入、**交叉顺序**并发取回，各归其主
· 取走即消费（二次取回为空）
· 未知 callID 返回空且**不影响他人**的块
· 32 路并发零串味
变异说明：本阶段是从「单槽」直接改为 per-call，旧实现在这四条判据下
（per-call API 不存在）无法编译通过，等价于判据先失败；per-call 版
再经 `go test -race` 验证无数据竞争。回归：internal/agent/io 全绿。
|
2026-09-27 11:06:41 +08:00 |
|
|
|
bce40b5099
|
feat(toolcall): 按 schema 预校验参数，在分派前拦下（阶段 1c）
问题：`required` 在仓内被声明 69 处，却**无任何消费方**（内核从不读）。
校验散落在每个工具内部手写成中文字符串（"path is required"），
要等工具真被调用才暴露——而模型看到这类与真因无关的报错只会原样重试
（实测 cmd_run 失败率 34%~48% 的成因）。
改动：
· core/argvalidate.go: validateToolArgs（纯函数）+ validateArgsAgainstSchema。
★ 校验器刻意**宽松**：只拦真正无法解析的形态，对模型实际会写的等价形态
一律放行。依据是工具内部 getter 的既有约定（utils.go 注释：
"实际调用里 bool/string/float 三种都出现过"；unitNumberRe 修的正是
`"20s"` 少引号那类）。**校验比工具更严就是在制造新失败**。
· required 判据是**键存在性** + 非空字符串；显式 null 视为已提供
（模型可能有意传 null，工具按零值处理，判成缺失即误伤）
· boolean 全放行（getBool 的 true/"1"/"0"/"yes"/0/1 全都合法）
· integer 接受 int/float64/"20"/"20s"；string 接受含 JSON 的长文本
· 无 schema / 无 required / 查不到 schema ⇒ 一律放行
· core/toolcall.go: 在 __arg_error 短路**之后**、分派**之前**接入。
· io/channel.go: 新增 IOManager.ToolDefOf——没有它就只校验到插件工具，
而 cmd_run / files_write 这类**设备/通道工具会完全绕过校验**。
判据（argvalidate_test.go，7 组）：
· 缺 required 被拦下并指名字段
· ★ 误伤防线：bool 传 "true"/"0"、integer 传 float64/"20"、
显式 null、字段顺序不同 —— 全部必须放行
· 类型确实不符报 type 错误
· 无约束场景一律放行（含 args 为 nil + schema 带 required ⇒ 应拦，
这条我最初**误放进放行组**，写完立刻发现改正）
· 错误文案含字段名/必填/改法（否则模型只会原样重试）
· 端到端：缺参时**设备真的没被调用** + 文案指名字段
· 端到端反向：参数齐备照常执行（校验不得阻塞正常路径）
变异验证（两轮）：
· 关闭分派前校验 ⇒ 端到端判据 FAIL「仍进入了工具」
· 把 boolean 校验改严格 ⇒ 宽松防线 FAIL 两个子用例（误伤 "true"/"0"）
过程中三次自伤：臆造 sdkToolError 别名；number 分支写了没有绑定的 x(v)；
把"显式 null"先当成缺失、过度修正后又漏掉"键不存在"的判定——
最终改为「键存在性 + 非空串」双条件，null 与缺失各归其位。
回归：internal/agent/... internal/sdk/... internal/plugin/...
internal/plugins/... 全绿（18 包）。
|
2026-09-27 10:56:02 +08:00 |
|
|
|
396d13e9af
|
feat(toolcall): 结果契约诚实化 —— Success 不再恒真 + 结构化失败可回填（阶段 1b/1d）
问题（实测，三条互相印证）：
· ToolResult.Success 硬编码 true（task.go 唯一赋值点）⇒ 该字段在结构上
不可能为 false，是**谎报字段**；
· 工具失败以 nil error + 错误**值**返回（files 的 errorResult、
pluginmgr 的 {"error":…}），上游无从判别；
· stepToolAfter 用 `Result.(string)` 断言，而插件返回的多是 map ⇒
断言几乎恒失败，after_toolcall 阶段对结构化结果的改写**静默失效**。
改动：
· third_party/homeagent-sdk: 新增 ToolError{Field,Reason,Detail,Hint}
与 Error()。纯新增、无签名变更，存量插件不必改动（零值语义：
内核的失败识别同时兼容既有三种约定，新类型是可选项而非迁移要求）。
· internal/sdk: 补 ToolError 别名。
· core/toolerror.go: isToolError / toolErrorText / renderToolResult。
⚠️ 判据必须同时兼容仓内**三种**既有失败约定，且**不得**把成功误判：
① {"error": msg} ② {"isError":true,content:…} ③ *ToolError
明确不判失败的：exit_code != 0（业务结果，带真实 stdout/stderr）、
stderr 非空（cmd 成功常带 warn）、字符串/数字/bool/数组/nil
（自由文本按成功处理：宁可少报失败，也不把正常结果报成失败）。
· core/toolcall.go: executeToolCallOutcome 返回 toolOutcome{Text,Raw}，
**Raw 必须在成功分支也带上**——否则结构化失败在 fmt.Sprintf("%v")
那一步被抹平，Success 又退回恒真。panic 与 60s 超时统一以 ToolError
表达（可执行 Hint，避免模型原样重试工具故障）。
· core/task.go: Success=!isToolError(Raw)；修恒失败的类型断言；
TaskFrame 增 CurRaw（未降级的原值）。
判据：
· toolerror_test.go 单元级：三种失败约定识别 / 成功形态不误判 /
非零退出不算工具失败 / ToolError 识别。
· TestStageCtxSuccessIsHonestEndToEnd 端到端读 f.StageCtx.ToolResults，
验证**内核产出的值本身**，而非辅助函数。
变异验证（两轮）：
· Success 退回硬编码 true ⇒ 端到端判据 3 个子用例 FAIL；
· 把字符串判据改成 strings.Contains(x,"error") ⇒ 「成功文本含 error 字样」
用例 FAIL。**第二轮暴露了判据缺口**（最初没有该用例），已补。
过程中三次自伤（均由判据/编译暴露）：用正则批量包装 return 时把
多行 fmt.Sprintf 截断；包装范围溢出到返回 string 的辅助函数；
测试里重复注册同名工具导致 IOManager 取到错误的 device。
遗留：全量 go test ./internal/... 在本机无法完整跑完——/tmp 是 9.8G
tmpfs 且已 98% 占用，link 阶段报 "no space left on device"；
/var/tmp 另有约 29G 陈旧 release worktree。与本次改动无关（未触碰
memory/* 等失败包），已在干净基线（7a566d5）对比确认。
|
2026-09-27 09:17:16 +08:00 |
|
|
|
4ba72977d2
|
test(toolcall): 补批内路径的三条缺失判据（阶段 0.5）
同一批多个 tool_call 的循环（StepToolBegin→Exec→After）此前只被
scheduler_critical_test.go:125 一条用例覆盖「按序执行」，缺的三条正是
阶段 2（并行执行层）要改的地方：
· tool_call_id 配对完整性 —— 阶段 2 改消息落法（一个 assistant 带全部
tool_calls + N 条 tool）时，配对断裂上游会直接报错
· ContentOnce 批内语义 —— 同一段 assistant 文本在批内重复 N 次，撑爆上下文
· denied 后继续批内 —— 改成 abort 会丢掉本可执行的后续调用
判据 toolbatch_test.go（4 条），全部确定性断言：阶段 0 已消除 map
迭代随机性，同批工具的落序与配对可稳定断言。
变异验证：令 stepToolBegin 跳过批内最后一个工具后，4 条判据同时 FAIL
（既有那条也 FAIL），报错直指 ToolsUsed=[tool_alpha]、
tool_call_id "c2" 被声明 0 次。
更正一处此前的不准确表述：我曾说「无任何测试直接驱动批内路径」——
不准确。scheduler_critical_test.go:125 已驱动「同批两工具按序执行」；
漏查是因为只 grep 了 PendingTools/ToolIdx 字段名，没查断言内容。
真正缺的是上表三条。
过程中三次自伤（均由「判据先写」暴露）：臆造不存在的 helper；
stageHost 置 nil 后又使用；给 newTaskFrame 传 nil 导致 stepPrepare 于
task.go:519 nil 解引用 panic（改用仓内既有 a.stageCtxFromInput）。
顺带记录：生产两处 newTaskFrame 调用都传真实 ctx，但 stepPrepare 对
f.StageCtx 无 nil 兜底——本次不修（无生产触发路径），记为潜在缺口。
回归：internal/agent/... 与 internal/plugins/... 全绿。
|
2026-09-27 08:59:30 +08:00 |
|
|
|
7a566d50b7
|
fix(toolcall): 工具「不存在」类型化 + 修父 io 兜底吞错误 + 修并行 tool_call 落序随机
主线：工具调用并行化改造（阶段 0 与 0.2）。
① flush 顺序随机（process.go）
flushToolCall 由 `for idx := range accs` 驱动，Go map 迭代顺序随机化
⇒ 同一批并行 tool_call 进入 resp.ToolCalls 的顺序每次运行都可能不同。
对 output_send__ 这类用户可见通道，分段消息到达顺序不可复现。
改为收集 index 后 sort.Ints 再 flush（两个调用点统一走 flushAll）。
判据 stream_flush_order_test.go（8 工具 × 200 轮），已变异验证可检测。
② 工具「不存在」类型化（io/channel.go、core/stages.go、core/toolcall.go）
工具是动态注册的，「不存在」是运行期常态而非异常。原先内核用
strings.Contains(err, "not found in any plugin") 判别——约定而非契约，
插件文案含该子串即被误判。改用哨兵 ErrToolNotFound + errors.Is
（沿用仓内 ErrInputChannelUnknown 的先例）。
⚠️ 顺带修一个静默 bug：IOManager 向父兜底时吞掉父的执行失败，
误报为「工具不存在」。后果是设备离线这类本该 retry 的失败被判为
「工具没了」⇒ 整组被跳过，与「插件真没加载」无法区分。改为只传递
「确实不存在」，其余如实上抛。
「不存在」的文案改为可执行指引（get_plugin_tools / output_list_channels），
而非含糊的「执行失败」——后者会让模型反复重试同一个不存在的名字。
判据：toolcall_error_test.go（类型化 vs 诱饵子串、%w 穿透、执行期文案）、
channel_error_test.go（父失败不吞、真的不存在仍可判别）。
两者均经变异验证。回归：internal/agent/... 与 internal/plugins/... 全绿（14 包）。
设计文档：docs/zh/toolcall-contract-and-sequence-design.md
执行计划：docs/zh/toolcall-parallel-execution-plan.md
|
2026-09-27 08:55:25 +08:00 |
|
|
|
2567a22be5
|
fix(memory): 场景键两路合并去重（现网日志实测 scenes=[chan:qq chan:qq]）
现网 21:49 的 QQ 轮次日志打出 `scenes=[chan:qq chan:qq]` —— 同一键
出现两次。查因：tooldefs.go:63 与 task.go:793 是同一段拼接写法，
scenes := a.sceneKeysFor(...) // 内部有 seen 去重
turn := a.resolveTurnScenes(...)
for _, k := range turn.Keys {
scenes = append(scenes, k) // ← 两路之间没有共同的 seen
}
而声明路与通道派生路都会产出 chan:qq（既是插件声明的、也是从
evt.Source 派生的），于是重复。
功能上无害（RecallByScene 内部会再去重），但有两个实际代价：日志里
的 scenes=[...] 误导排查——会让人以为场景集合本身有问题；以及每次
白走一遍前缀匹配。
修法：抽 mergeSceneKeys 共用函数（顺带消掉两处重复代码），两处调用点
都走它。判据 scenemerge_test.go 5 例：3 个合并场景（同名 / 归一化后
同名 / 多路重复）+ scene_policy=none 时两路皆空（防「声明路关了但
涌现路还开着」的半开状态）。
记忆 8 包 + agent/core 全绿，8 包齐全、无 FAIL/panic/race。
|
2026-09-26 21:55:12 +08:00 |
|
|
|
758ec11832
|
fix(memory): 图整备覆盖 scenes + 证据桶按桶清（R3/R5）
R3：图整理心跳只查 entities/relations，scenes 完全没有整备路径。
Recall(nil,nil,1,"") 的全量路径只 SELECT 这两张表
（graph.go:609/631），于是同一场面的双胞胎键从建库起无人发现：
auto:chan:qq+part:morning 累积到 strength=271 / 6 features / 0 refs，
孪生的 auto:chan:qq_part:morning 持有 210 refs 却 0 features
（聚类只读 scene_features，所以它永远不被看见）。
新增 GraphDB.DedupeScenes：归一化后同名的场景合成一个——强度相加、
特征取并集（权重取大）、引用全部重定向，存活者保留 id 最小行，
跨 origin 也合。接到 mergeLoop 尾部。
为什么不塞进 detectEntityMerge 的双重循环：
- 实体是全库两两 bigram + LLM 裁决（1 万实体实测 5000 万次配对、
~224GB 瞬时分配每轮，是独立问题）；
- 场景的判重口径是**归一化后是否同名**——同名即同一场面，键相同
本身就是证据，不需要 LLM 裁决。而「像不像」是 EnterScene 聚类的
职责，不是这里的事。
只做同键合并、不做相似度合并：把 chan:qq 与 chan:webui 合并是危险
的，去重不是「把像的一律合并」。
生产库副本实测（sqlite3 备份式复制到 /tmp，未碰生产）：
65 个场景 → 合并 8 组 → 57 个；
auto:chan:qq_part:morning 的 refs/rel/ent 一条没丢，strength 1 → 272。
R5：createSceneLocked 新场景成立时执行的是
`DELETE FROM situation_evidence`（全表清），而证据表是多通道共用的
计数桶。后果不是「多清一点」：qq 的场景一长出来，就把 mc/webui/cli
尚未攒够 minSceneEvidence=2 的证据抹掉，它们的计数被反复清零，
于是**永远**攒不到 2 次。判据实测：6 个通道各来 3 次，只长出 2 个场景。
改为 `DELETE ... WHERE label = ?`，只清本指纹那个桶。
判据：scene_dedupe_test.go 8 例（含「不同场面不得被合并」与幂等）、
scene_evidence_test.go 3 例。均先红后绿。修 R5 时差点栽：桶键是
sig.Label(2) 本身、不带 auto: 前缀（base 才是带前缀的场景键），
第一版删错对象会「一条没删却看起来通过」，用探针实测真实桶键后改正。
记忆 8 包 + agent/core 全绿，8 包齐全、无 FAIL/panic/race。
|
2026-09-26 20:16:11 +08:00 |
|
|
|
8887e06274
|
feat(sdk+memory): 补 ScenePolicy 声明项，让通道能退出场面识别
缺口（R6）：ChannelDef 的记忆声明已有三件套——NoMemory 管「进不进
记忆计算」、ContextPolicy 管「裁不裁上下文」、RecallPolicy 管「召不召回
记忆」，唯独没有「这条输入算不算一场戏的一部分」。现状是无条件参与：
situationFeaturesFor 里只要 evt.Source != "" 就产出一个 chan 特征，没有
可关的开关 ⇒ chan:system / chan:kernel / chan:timer 这类纯内部信噪通道
也在撑场面，每次触发都让不相干的场景长出来或变强，召回时又会把
「内核在跑定时器」当成「用户在这类场景下说过的话」取回。
穷举确认不是查漏：go.mod replace 指向 third_party/homeagent-sdk，
plugin.go 中 scene 出现 0 次，SDK 自身 git 历史 -S'Scene' -- sdk/ 为空。
SDK（纯追加，老插件行为逐字节不变）：
- 常量 ScenePolicyAuto / ScenePolicyNone + ValidScenePolicy，形状与
ContextPolicy / RecallPolicy 完全一致
- ChannelDef.ScenePolicy 与 InjectOptions.ScenePolicy，均带 omitempty
- 默认取 auto（参与）而非 none：场景只附加检索路、不改记忆本体，
默认关会让存量通道突然失去召回；「关」是少数意图。与 ContextPolicy
刻意相反（同为破坏性操作，那里是默认关）。
内核：
- applyInjectOpts 搬运 scene_policy（与另外三个标志位同面）
- sceneSuppressed 完全照 recallDeclared 的形状：注入点 payload >
通道定义 > 默认。none 时连时段(part)特征都不产，也不派生场景键
（只停指纹采集而留声明路，等于给这个口子开后门）
- situationFeaturesFor / sceneKeysFor 由包级函数改为 Agent 方法
（需要 a.io 查通道定义），23 个调用点同步
判据：scenepolicy_test.go 7 例，改前编译期红（undefined:
pubsdk.ScenePolicyAuto），改后全绿。其中两例专门护住「未声明时行为
逐字节不变」，是纯追加承诺的护栏。
记忆 8 包 + agent/core 全绿，8 包齐全、无 FAIL/panic/race。
存量通道标注待定：kernel/timer/offload-*/child/* 是纯 0-refs 信噪，
可直接标 none；但 mc:system(12 refs) 与 system(3 refs) 带真实记忆，
性质不明，不擅自标。
|
2026-09-26 20:09:17 +08:00 |
|
|
|
8bd8271f49
|
Revert "fix(agent): output_send 缺收件人时从输入事件自动补"
This reverts commit 6b74862.
## 为什么撤
方案本身是错的，三点：
1. **假设 meta 的收件人字段跨通道通用。** 只实现了 qq（user_id/group_id），
而 wechat、群聊各有各的字段名。逐通道补全会变成一张靠猜的映射表，
每加一个通道就得重猜一遍。
2. **假设「回复来源 = 收件人」。** 线上实测直接推翻（2026-09-26 19:05）：
一次请求从 webui 会话发起、却要发到 QQ（input source=webui，
output channel=qq）。收件人与来源根本不是一回事 —— 用户在
WebUI 里说"发个 QQ 给我"，收件人只能来自上下文或用户明说。
按 channel 名补，等于用错误的假设去覆盖真实场景。
3. **没解决问题，反而引入新风险。** 19:05:46 那次照样报同样的错
（"meta 中需要 group_id 或 user_id"），补全逻辑对跨通道场景无效。
而一旦补错，消息会发给错的人 —— 那比报错坏得多。
## 保留的部分
现象描述与排查结论留在这个 revert 的说明里，便于后续重新设计时
不再重复踩：各通道 meta 结构差异极大，要让插件自己声明收件人来源
（qq 插件知道自己的 user_id 从哪来），内核只转发不猜。
不采用"把格式写进工具描述"这类方案：那只缓解症状，
且各通道格式仍需逐个核实。
|
2026-09-26 19:11:51 +08:00 |
|
|
|
6b74862118
|
fix(agent): output_send 缺收件人时从输入事件自动补
## 现象（线上 2026-09-26 17:57）
用户从 QQ 私聊发来消息，agent 生成了回复也调了 output_send__qq，
但**没填 meta**：
17:57:45 qq_get_message → {user_id: 2198972886, message_type: private}
17:57:46 output_send__qq → 失败：meta 中需要 group_id 或 user_id 字段
17:58:14 output_send__qq_help → 查格式
17:58:14 output_send__qq → ok ← 靠重试成功，整轮耗时 74s
信息内核**本来就有**（输入事件里带着 user_id/group_id），却要模型从
qq_get_message 的返回里手抄进 meta。抄错就失败，失败才去查 _help。
而"回复"这件事的收件人是确定的（= 消息来源），本不该由模型负责。
运气差就不重试：同日 17:15 / 17:21 两次 `tools=[]` —— 模型压根没调
output_send，回复生成了但没发出去，日志连一行告警都没有。
## 改法
meta 缺收件人时，内核从**本轮输入事件**推导后补上。模型只需给内容。
## 边界（都刻意收窄：宁可不补，也不能补错）
- 显式传了 meta ⇒ 原样返回。主动 DM 别人等场景必须保持原行为。
- meta 里已有 group_id/user_id ⇒ 不覆盖。
- meta 是坏 JSON ⇒ 原样返回。让下游报"格式错"，而不是被静默替换成
一个模型没要求过的收件人 —— 那比报错更坏：消息会发给错的人。
- 非 qq 通道（如 webui）⇒ 不补。webui 走 ResponseCh，不过 output_send。
其余异步通道（wechat 等）不猜：猜错等于发错人。
- 输入事件里没有收件人信息 ⇒ 留空，让下游按原逻辑报"需要 user_id"。
宁可报错让模型重试，也不要编一个收件人。
- 群消息里 user_id 是**发送者**不是收件人 ⇒ group_id 非 "0" 时优先用
group_id，否则会把消息发回给群成员本人。
数字型 user_id 要按整数格式化：JSON 反序列化成 float64 时
fmt.Sprint 会得到 "2.198972886e+09"。
## 判据：7 条
私聊补 user_id / 群聊补 group_id 且不补 user_id / 显式 meta 不改写 /
已有收件人不覆盖 / 坏 JSON 不静默替换 / webui 不补 / 无信息留空（含 nil evt）。
★ 实现时我先自己写了个 payloadString，编译报错才发现包内已有更完整的
版本（memorypass.go:176，含 float64/int64/int/json.Number 分支），
直接复用 —— 不重复造轮子。
全量 42 包绿。
|
2026-09-26 18:29:23 +08:00 |
|
|
|
5dd98d7a05
|
feat(knowledge): 目录批量导入 + 派生数据批量收口
## 能力缺口
导入只能一条条 Add（knowledge_create）。agent 拿到一份 200 页的
文档目录要调 200 次工具，且每次都得自己决定分类与名字。
新增工具 `knowledge_import_dir(dir, category?, include_media?, dry_run?, max_items?)`。
语义是**复制**不是引用：源文件删改不影响已导入的副本。
- 文本经 Write 整份写入 <知识根>/<分类>/<名>/content.md
- 媒体按 sha256 进媒体库（内容寻址天然去重），条目只存 digest 引用
## 目录约定（自动适配，不要求改造资料）
1. 含 content.md 的目录 ⇒ 整体作为一个条目（与 scanDir 既有语义一致，
所以知识库自身目录能被原样再导入而不会被拆散）
2. 否则 .md/.txt 等文件各成一条，**目录路径即分类**
## 三个语义决策
- category 是**前缀叠加**（tech + 源结构），不替换：替换会丢掉源目录
自身最有价值的层级信息
- 同名冲突**跳过并计数**，绝不覆盖：Write 对同名本就是覆盖语义
（knowledge_create 靠它做更新），若直接调它，一次重导就会把手工
补充的内容悄悄抹掉，而日志只写"导入完成"
- dry_run **默认 true**：批量写，agent 第一次试某目录应先看清会写什么
## 安全边界（批量操作，缺一道就可能读到不该读的）
- 必须绝对路径：agent 的 cwd 不受控，相对路径会静默导到别处
- 符号链接不跟随：否则一个软链就把知识根之外的文件导进来
- 拒绝把知识库自身当源（自导会无限自我复制）
- category 复用 normalizeName（与 Write 同一道闸，两处分叉就成了绕过）
- MaxItems 默认 500：防 agent 误传 "/" 把盘灌满
## ★ 批量导入暴露的既有 O(N²)
Write 每条末尾都调 flushDenseLocked，而 saveDenseCacheLocked 是
**全量序列化整个 items map 再重写整个文件**。按 512 维 float64 估，
单条约 10KB，导入 500 条累计要写约 1.4GB。
仓库里索引侧早已有 indexDirty 的「标脏+延迟收口」（实测 writeIndexLocked
6.7ms/次、占单条 Add 绝大部分），**稠密缓存却还是逐条全量重写** ——
同一类开销只修了一半。
照 indexDirty 的模式补 batchDepth：批量期只标脏，endBatch 收口一次。
用 defer 保证提前 return 也会收口 —— 否则这批向量会留成"标脏未写"，
下次启动被当作缺失而全量重算。
## 判据：17 条 + 变异
安全边界做了 4 组变异验证（去符号链接拦截/去绝对路径要求/去自导检查/
content.md 目录不下钻）。
★ 判据第一版有两处自己骗自己，被变异抓出来：
1. 符号链接判据造的是**目录软链**，而 WalkDir 对目录软链本来就不下钻
⇒ 有无防护结果都一样，是假绿。改成**文件软链**后才真正判红。
2. 同名冲突判据里已有条目写成 "a/b"、源映射出的是 "b"（不同名），
判据自己就错了 —— 修判据而不是改实现。
媒体路径用假 MediaPutter：验的是「调了 Put 且 digest 挂到条目上」，
媒体库自身的落盘去重是 media 包的判据，不该在这里重测。
全量 41 包绿。
|
2026-09-26 16:19:10 +08:00 |
|
|
|
144564f5c2
|
feat(knowledge): 分类过滤与多模态打通到工具/插件边界
- internal/sdk：KnowledgeAPI 增加 SearchIn/AddWithMedia/AttachMedia/
ReindexDense/DenseStats；新增 MediaAPI（Put/Stat/Get）与 PluginSDK.Media()，
registry 装配。**公开 SDK 契约一字未动** —— third_party/homeagent-sdk/sdk/
的 diff 恒为 0（发布纪律的硬约束），走 internal/sdk 这条明确不受冻结约束
的内部扩展路径。
- proc：新增 knowledge.addWithMedia（正文与媒体清单都走共享内存，与
doc.insertWithMedia 同形）；knowledge.search 支持 category。
- corehandler 用**局部接口 + 类型断言**取扩展能力，而非直接引 internal/sdk：
后者已依赖 internal/plugin 的类型，直接引会成环（CoreSDK 注释已警示）。
断言失败明确报"能力不可用"，不静默退化成"媒体已写入"。
- agent 工具面：knowledge_search 增加 category；knowledge_create 增加
media_digests（复用 doc_commit 的 digest 前缀解析 + Stat 回读 MIME）。
顺带修 knowledge_search 的分类前缀重复（Name 已含分类，旧代码又拼一次，
实测输出 tech/go/tech/go/并发）。
- agent 启动接线多模态空间，顺序为先接线再 ReindexDense（否则首次启动
算出的向量因 MediaStore 未就绪而不落盘）。
|
2026-09-26 14:20:19 +08:00 |
|
|
|
84c7559b0e
|
chore(api): 删除批量定位改造后遗留的 6 个未使用函数
首版逐字段设计（findKey/firstElem/scanArray/decBuf 路径等）在批量定位
改造后已完全被取代，保留它们会让人误以为这些路径仍在生效。
删除：findKey / firstElem / scanArray / locateChunkBatchInto /
sseABIVersion / argStringC。
保留 C_size（rootSpan 在用）与 stringifyC（文本数组路径在用）。
go vet 与 go test 均不报未使用的包级函数，故用调用点计数核验
（每个符号的非定义调用数均为 0）。build + 全量 api 测试绿。
|
2026-09-26 10:44:18 +08:00 |
|
|
|
7a1322c97f
|
perf(api): SSE 导航层返工 —— 5+ 次边界压成 1 次（三项赢，仍默认关闭）
按 sse-codec-c.md §6.4 的架构改造方向返工。**部分成功**：从「五项全输」
变成「三项赢 / 一项持平 / 一项输」，且所有场景分配数都下降。
## 改造内容
| 项 | 前 | 后 |
|---|---|---|
| cgo 边界次数 | 5+（每字段一次 findKey） | 1（ha_sse_chunk_locate） |
| 键查找 | 每键各扫一遍对象（6 趟） | 单趟分派（遍历成员表一次即分发） |
| 解码 | 每字段一次往返 + 各自 decBuf | 同一趟内写进一块 sbuf（1 次分配） |
| 成员表遍历 | 6 趟 | 2 趟（顶层 + delta） |
顺带修掉两处自造的浪费（都是「先扫一遍拿个数、再扫第二遍拿首元素」）：
choices 数组的「数个数 + 取首元素」合一趟；choice0 内的 delta/finish_reason
合一趟。成员遍历实测 107ns/趟，省一趟就是省 107ns。
新增 ha_sse_chunk_locate：一次调用完成根校验 + 顶层分派 + choices[0] +
delta 分派 + content/reasoning/finish 解码，输出写调用方持有的 C 结构体
（C 结构体无 Go 指针 ⇒ 可安全传指针，消除 out-param 逃逸）。
choices_count>1 时直接回退（Go 侧 Unmarshal 会解析全部元素，本层只认 [0]，
其余元素可能类型不符而让 Go 整块作废 ⇒ 无法保证等价）。
## 实测（50000 次 × 3 轮取中位）
| 场景 | Entry | GoOnly | 判定 |
|---|---|---|---|
| content_zh | 1540ns / 5allocs | 1871ns / 13allocs | 快 18%，分配 -62% |
| content_ascii | 1250ns / 5allocs | 1304ns / 13allocs | 持平，分配 -62% |
| finish | 820ns / 6allocs | 921ns / 12allocs | 快 11% |
| usage | 2530ns / 9allocs | 2591ns / 12allocs | 持平偏快 |
| toolcall | 3450ns / 20allocs | 3000ns / 21allocs | 慢 15% |
## toolcall 仍输的根因（已定位，非猜测）
分解测量：C 侧纯 C 零边界 = 766ns；Go 侧 []openAIToolCall unmarshal =
1305ns/15allocs；对照 Go 整块 unmarshal ≈ 2980ns。
问题在第二行：tool_calls 元素是对象，Arguments interface{} 需要真实的
map[string]interface{}，必须走 encoding/json 的反射建树。
而为了定位已先做了一遍 C 扫描 ⇒ 同一份数据被解析了两次。
⇒ 不是 C 慢，是「扫两遍 vs 扫一遍」。
标量字段（content/reasoning/finish）C 能一次到位 ⇒ 那些场景赢；
需要建树的字段（tool_calls/usage）C 的定位是纯开销。
## 为什么仍默认关闭（理由充分，不是保守）
1. toolcall 是真实负载最常见的一类块（任何一次工具调用流），仍慢 15%
2. 18% 收益不足以抵消「与 encoding/json 语义并存的第二实现」的风险
3. 本刀原始动机在 toolcall 场景没有兑现：分配数 20 vs 21 几乎没降
⇒ 前提是先做「按字段类型决定是否 C 化」，让 toolcall 也不输，再重测。
## 正确性
6 万+ 差分用例（协议形态/真实负载/随机 JSON 3 万/随机字节 3 万）全过。
基准测量也修了：先前 C 基准脚本用 CLOCK_MONOTONIC 却只取 tv_nsec，
算出 -4201ns 的负值 —— 测量工具本身出错会直接毁掉结论。
## 验证
ASan+UBSan PASS；gcc+clang 零告警；arm64 交叉 0 告警；
libFuzzer 66 万次零崩溃；全量 go test 38 包 ok / 0 FAIL
|
2026-09-26 10:41:52 +08:00 |
|
|
|
7748ec450e
|
perf(api): SSE 分块 C 导航层 + 差分等价验收（实测更慢 ⇒ 默认关闭）
第三刀：把 ha_json_scan 接进 parseOpenAICompatibleStreamChunkFull。
**结论是否定的** —— 实测比原实现慢，故默认关闭并如实记录。这条提交的
价值在于「已钉死的正确性 + 已定位的根因 + 一条防静默回退的断言」。
## 设计：只做「结构导航」，序列化留在 Go
接线前实测出两条 wire 语义，它们让「整条解析全 C 化」不成立：
§5.1 重复键是**字段级合并**，不是替换：
{"choices":[{content:a}],"choices":[{reasoning:r}]} → 两个都保留。
机制：json.Unmarshal 的 object() 收尾做 v.SetIndex(i, subv.v)，
而 subv 拿到的是**已存在元素的指针** ⇒ 第二次是叠加。
§5.2 stringifyContent 的 default 分支 = json.Marshal(interface{})，
即**重新序列化**：{"b":1,"a":2}→{"a":2,"b":1}（键排序）、
1e2→100、<→\u003c、大 int 先舍入成 float64。
逐值一致 = 复刻 Ryu 最短浮点 + map 键排序 + HTML 转义 + int 舍入。
两条都只在**取值**阶段需要，故 C 只回答「值在哪里」（零分配零解码），
类型检查靠「用相同的 Go 类型 unmarshal 相同形状的子树」保证，不靠 C 复刻规则。
## 实测：新路径比原实现慢（20000 次迭代）
| 场景 | 新路径 | 原实现 |
|---|---|---|
| content_ascii | 2016ns / 20allocs | 1325ns / 13allocs |
| toolcall | 5854ns / 33allocs | 3270ns / 21allocs |
| usage | 3170ns / 24allocs | 2832ns / 12allocs |
分配数**也变多**（20 vs 13），与「消除 GC 抖动」的初衷相反。
根因（逐项测量，非猜测）：裸 cgo 调用 168ns；**每次带 out-param 的键查找
205ns + 2 allocs**（out-param 逃逸到堆）；一次解析需要 5+ 次查找
⇒ 边界与分配成本约 1µs，恰好吃掉全部收益。Go 侧只需**一次** Unmarshal。
一句话：**用很多次廉价调用换一次昂贵调用，在这个尺寸上不划算。**
## 天花板实验：方向对，但当前实现没到
假设拿到 span 完全免费，只测设计中必须由 Go 做的部分：
我的 Go 侧 505ns/7allocs vs 原实现 1239ns/13allocs
⇒ 边界归零后仍有 2.4× 时间、46% 分配的空间。故问题在**逐字段往返**
这个交互方式，不在 C 本身。正确改造：一次调用返回全部字段 span +
结果写调用方栈结构体 + 仅在确需重新编码时回退。
## 正确性：6 万+ 差分用例全过
同一批输入跑两条路径逐字段比对（Content/Reasoning/Done/Finish/ToolCalls/
Usage + bool），5 组：协议形态（含全部回退触发条件）、真实负载、随机 JSON
30000 例、随机字节 30000 例、优化有效性。
★ 差分测试当场抓出 4 个真实缺陷（其中一个正是「优化压根没生效」）：
1. ha_sse_arr_first 里「重新 init 到 sc.s+sc.i」使 base 变了 ⇒ start 恒 0
⇒ 返回的是**数组本身**而非首元素。症状是**快速路径永远不生效**——
而若只看「结果与 Go 一致」，这个 bug 会**完全隐形**（回退总是对的）。
⇒ 这就是必须单独断言「优化确实被走到」的原因。
2. chunkAssemble 的 bool 被丢弃 ⇒ 空对象被判 true（原实现 false）
3. 键匹配层级搞错：delta 是 **struct**（字段名 CI），不是 map。
我一度「推理」成 CS 并以为差分测试会通过——错的。
教教训：哪层是 struct、哪层是 map 要**回原实现读类型**，不能凭字段名推断。
4. cgo 边界：out-param 逃逸到堆
另修：C 代码从 cgo 前言移进 csrc/ ——前言里的 C **逃出全部 C 门禁**
（告警/sanitizer/交叉/模糊测试），而它恰是本刀最易出错处。
## 防静默回退
TestChunkFast_BenchGate 断言 chunkFastEnabled 必须为 false。
后来者看到「快速路径写得全 + 差分测试全过」，很自然会以为它已生效并打开它
—— 而实测更慢。断言把这个事实钉住，改动即判红。
## 实测汇总
- C 契约 119 项断言、黄金对照 5 组、差分 6 万+ 例：全过
- ASan+UBSan PASS；gcc+clang 零告警；arm64 交叉 0 告警（3 个源文件）
- 全量 go test -count=1 ./... 38 包 ok / 0 FAIL
- libFuzzer 4948 万次零崩溃（上一刀）
教训（与第一刀同源）：**「C 比 Go 快」不是前提，是待验证的假设。**
第一刀被 C.CString 的 82% 自找开销推翻一次，这一刀被逐字段往返推翻一次。
两次都是测量推翻直觉。
|
2026-09-26 10:32:20 +08:00 |
|
|
|
4d3962a845
|
feat(csrc): 第二刀 —— 零分配 JSON 扫描/取值层 ha_json_scan（含黄金对照）
C 化第二刀：为协议编解码层铺 JSON 底座。**本刀只交付库 + 验收，
未改 Go 生产路径**（接线是独立一步，库先验完再换产线）。
为什么是它：SSE 单块解析（parseOpenAICompatibleStreamChunkFull）是每个流式
chunk 都要跑的最热路径，实测 1937ns/13allocs（content 块）、3122ns/21allocs
（toolcall 块），而纯字节扫描理论下限 133ns/1alloc —— 差距 15~23×。
一次 1 万块的会话 = 1~2 万次堆分配，正是 GC 抖动的来源。
为什么不复用 SDK 的 remotedevice/ha_json.c（实测三缺陷，不可直接复用）：
① 无 \u 解码：\u4f60\u597d → ?0?d?d?0（非 ASCII 全靠转义时内容直接损坏）
② 只有 _get_int 无浮点：temperature:0.7 静默变 0
③ null 与「键缺失」不可区分
外加它是 DOM + malloc，与本层「不 malloc / 零拷贝 / 纯函数」正交。
设计：scan（结构，零分配零解码）+ extract（取值，按需解码）两段分离。
content 可能是很大的多模态数组，而 stringifyContent 只需要 text 字段拼起来；
若 scan 就解码并分配缓冲，等于把成本付给不需要它的调用方。
★ 被测试抓出 7 个真实缺陷（写 C 时同一逻辑我读三遍都认为正确）：
1 代理对合成成功后未跳过 unconditionally 的 U+FFFD 发射（😀 → 两个 FFFD）
2 过长编码检查用了只含首字节位的 cp（「你」→ 6 个 FFFD）
3 members_next 只报值起点不消费值 → 游标停在值前（模糊测试第一轮抓到）
4 扫描阶段不校验转义字符合法性（{"a":"\q"} C 判合法、json.Valid=false）
5 扫描阶段不校验 \u 后四位十六进制（同上）
6 get_int 接受前导零（007 / 00）
7 cgo 桥接把 C 结构体声明为 Go 局部变量 → 运行时 panic
（cgo argument has Go pointer to unpinned Go pointer）
其中 4 个是「静默分叉」——不崩、不报错，生产里表现为「内容少一个字符」
或「某些块被静默丢弃」，极难归因。这正是黄金对照不可省的理由。
★ 另纠正我自己两次错误的「真值」（比代码 bug 更危险，会变成错误规格）：
第一版真值表里 content:{} 的花括号少了一层，把「我写错 JSON」误读成
「Go 对 content 严格」。修正后实测发现一对方向相反的语义：
content 走 interface{} 宽松（{}→"{}"、true→"true"），
reasoning_content/usage/finish_reason 强类型严格（123 ⇒ 整块作废）。
照错误表写 C 会产出「比 Go 更严格」的实现，静默丢弃本该生效的块。
两个由缺陷倒逼的设计决定：
- members_next 返回**完整值 span** 并内部跳过 ⇒ 「返回 1」蕴含「成员良构」。
要求调用方自己推进游标的 API 是错的：忘一次就解析到上一个值且不报错。
- members_complete() 区分「正常扫到 }」与「输入畸形」，否则无法复刻 Go 严格性。
同时修两个基础设施目标对「多源文件/多测试」的适配：
- csrc-sanitize：每个契约测试各自链接（多个 main 合链会 multiple definition，
而报错被吞后会被误报成「本机无 sanitizer」——一个假的 SKIP）
- csrc-cross：多源文件改用 -fsyntax-only 逐文件（gcc 不支持多源单 -o）
实测（全部当场可复现）：
- C 契约测试 119 项断言全过；黄金对照 5 组全过（语法/成员/解码/整数/随机字节）
- libFuzzer 4948 万次运行零崩溃（121s）
- ASan+UBSan PASS（两个契约测试各跑）；gcc+clang 零告警；arm64 交叉编译 0 告警
- 全量 go test -count=1 ./... 0 FAIL；make build-linux-arm64 → ELF aarch64
- 纪律检查 SDK 公开接口 diff = 0 行（未触碰 SDK）
决策关闭（jianf 本轮裁决）：C 实现留主仓 csrc/（它本就是替换内核 Go 实现，
SDK 从未被触碰，跨端复用才需进 SDK 而它们不调用本层）；ha_json.c 不复用；
下一刀即协议编解码层。
|
2026-09-26 10:07:27 +08:00 |
|
|
|
8070844fe9
|
build(csrc): C 基础设施门禁（ABI 版本 / 告警 / sanitizer / 交叉编译 / 模糊测试）
C 化从「一把刀」推进到「可持续推进」，本轮先把基础设施建起来：
不建它，后续每个 C 切片都在裸奔（无告警门禁、无内存安全检查、
无交叉编译验证、无 ABI 漂移检测）。
新增门禁（make check-csrc / check-csrc-full，已接进 make test）：
- csrc-lint gcc+clang 双编译器 × -Wall -Wextra -Wpedantic -Wshadow
-Wconversion，零告警才算过（-Wconversion 是为 cgo 窄化
准备的：size_t→int 截断在默认档下是静默的）
- csrc-abi ABI 版本运行期自述 + 荒谬值检查
- csrc-headers 头文件自包含性（每个 .h 能单独编过）
- csrc-sanitize ASan+UBSan 跑 C 契约测试
- csrc-cross arm64 交叉编译（homed 的真实发布目标）
- csrc-fuzz libFuzzer：内存安全 + 6 条不变式（可 CI 门禁）
新增 ABI 契约（csrc/include/ha_abi.h）：
- ha_codec.h 声明「签名冻结」，但冻结只写在注释里；现改为
HA_CODEC_ABI_MAJOR/MINOR + 运行期自述 + Go 侧常量，
三方交叉断言，版本漂移在测试期判红而非线上表现为行为诡异。
- 门禁当场抓出我自己的两个真 bug：①_Static_assert 是 C11 而项目
是 -std=c99（-Wpedantic 报的）；②##msg 不能拼接字符串字面量，
导致两个断言共用一个 typedef 名（clang 报的）。
基础设施当场抓出的三个真实缺陷（都是「本机 gcc 能编过、别处会炸」类）：
- bench 用了 POSIX clock_gettime，而 CMake 刻意 C_EXTENSIONS OFF
（严格 c99）→ 头文件未声明；补 _POSIX_C_SOURCE（须在任何头之前）
- 头文件缺 include 时只在「恰好被别的头先包含」处静默编过
- Go 不允许在 _test.go 用 cgo ⇒ C 侧 const 桥接只能放非测试文件，
且 cgo 生成的 *_Cvar_* 不是 Go 常量（「两边一起错成一样」的盲区，
改用 C 函数返回 + 编译期 _Static_assert 补上）
实测（全部当场可复现）：
- 双编译器 × c99/c11 零告警；ASan+UBSan PASS
- libFuzzer 91s 跑 3329316 次、零崩溃（6 条不变式全过）
- 变异测试：改 C 侧宏 / 让 Go 常量与 C 函数「一起错成一样」，
均被对应断言抓住（证明门禁不是摆设）
- C 侧纯函数基准（首次把函数体成本与 cgo 边界成本分开测）：
ascii_1k 121.7ns/8.4GB/s；zh_1k 1434ns；truncate 两者均约 128-134ns
- 全量 go test -count=1 ./...：57 包 0 FAIL
- make build-linux-arm64 → ELF aarch64
- 纪律检查 FAIL=0；SDK 公开接口 diff = 0 行
未动：csrc/ 是内核 C ABI，不属 third_party/homeagent-sdk 公开接口。
|
2026-09-26 09:44:17 +08:00 |
|
|
|
7799ca4559
|
perf(c-core): 完全 C 化 + 消灭初版的 malloc/拷贝开销（C 从「更慢」变「明显更快」）
上一提交的基准结论是错的："C 比 Go 慢" 不成立 —— 那是我把自己的
malloc/拷贝开销误当成了 cgo 的固有成本。本提交先拆解成本、再逐项消灭。
## 成本拆解（同机、百万次 benchtime）
| 场景 | ns/op |
|---|---:|
| cgo 边界（零拷贝传指针 + 空函数体）| 31.9 ← cgo 真实固有成本 |
| + 一次 C.CString + C 侧 strlen | 105-111（多出 ~75ns）|
| 初版 ModelContextWindow（另加 lower_dup malloc + 16×strstr）| 175 |
即 82% 开销是自找的。而初版还违反了自己写在设计文档 §四 的原则第 1 条
「C 接口只吃 const char* + 长度」——它没传长度，让 C 侧 strlen 再扫一遍。
## 逐项修复
1. C.CString（malloc+整串拷贝）→ unsafe.StringData 传指针+长度，零拷贝
2. C 侧 strlen 再扫一遍 → 长度由调用方传入，不扫
3. truncate 的 malloc 输出缓冲 + GoStringN 拷回 → C 只返回**字节数**
（结果必然是输入前缀），Go 侧 s[:n] 完成切片，全程零分配
4. lower_dup 每次 malloc 模型名 → 栈缓冲折叠，超长走零分配回退
5. 逐字节 utf8_next 函数调用 → 字级（8 字节）ASCII 检测
6. truncate 扫完整串才判断 → 数满 keep 个 rune 立即返回（提前短路）
7. 纯 Go 侧 len([]rune(s))/[]rune(s)（1KB 分配 4KB）→
utf8.RuneCountInString / DecodeRuneInString 游走，零分配
## 结果
| 基准 | 初版 C | 优化后 C | 纯 Go | 提升 |
|---|---:|---:|---:|---:|
| ModelContextWindow | 175 | 76.5 | 46.8 | 2.3× |
| EstimateTokens / 1KB ASCII | 2318 | 80.8 | 326 | 28.7× |
| TruncateByTokens / 1KB ASCII | 2594 | 71.7 | 411 | 36× |
| TruncateByTokens / 1KB 中文 | 3923 | 70.1 | 3097 | 56× |
## 完全 C 化（jianf 裁定）
撤掉我一度加的「短串 <32B 走回 Go」按长度分派：那会同时存在两份语义
可能分叉的实现。C 是唯一实现。
代价如实记录：EstimateTokens("qq") 这类极短串上 C 约 47ns（几乎全是
31ns 边界成本）vs 纯 Go 约 3ns，慢约一个数量级；绝对值纳秒级
（0.000047ms），单次请求尺度可忽略。若某循环对极短串高频调用，
正确应对是**把该循环 C 化（批量传一次）**，而不是按长度分派回 Go。
## 顺带补的正确性缺口（初版是真错的）
初版 C 的 UTF-8 解码只按首字节推断长度、**不校验后续字节**，
因此对畸形序列会与 Go 分叉：例 "\xE4\x41\x41"，Go 判 3 rune，
初版判 1 rune ⇒ rune 计数偏差 ⇒ token 预算与截断点偏移。
这类偏差**只影响计数、不会崩**，不测发现不了。
现在 C 侧做与 utf8.DecodeRuneInString 等价的完整校验（含过长编码、
代理对、超 U+10FFFF、截断序列），语义边界逐条注释。
代价：中文密集输入比初版慢（1467 vs 840）—— 这是刻意的正确性代价，
且仍比纯 Go 快 2×。
新增测试：
- TestGolden_InvalidUTF8：3000 组**任意字节**（含畸形序列）对拍，
覆盖初版会分叉的输入类别
- TestGolden_TruncateAlwaysPrefix：截断结果必为原串前缀且不超长
- C 契约测试从 21 项扩到 40 项（含非 NUL 结尾、超长名、畸形 UTF-8）
## 包现在要求 cgo 才能编译
删除 codec_nocgo.go：CGO_ENABLED=0 下整包构建失败（错误直指缺失符号）。
不保留回退的理由：只验证过一条路，就不该存在第二条。
实测这不影响任何构建 —— go list -deps 证明只有 cmd/homed 依赖本包，
而 waiter/initconfig/memgc/mock-server 均不依赖（逐个验过），
且 homed 本就强制 cgo（sqlite3 + gojieba）。仓库无 CI。
Makefile 把「不许有第二条路」变成可执行断言：check-codec-cgo-only
（断言 cgo 下全绿 **且** CGO_ENABLED=0 下必须失败）。
## 验证
- C 契约测试 40/40（gcc -Wall -Wextra 零警告）
- 黄金对照 6 个测试全绿（含 2000 组随机 + 3000 组畸形字节对拍）
- 变异测试：改 C 侧返回值后 go test 立即 FAIL（确认真的走 C）
- make check-codec-cgo-only 两项断言通过
- go vet ./... 干净；全量 go test -count=1 ./... → 38 ok / 0 FAIL
## 已知既有 flaky（与本改动无关，单独记录）
internal/plugins 在全量并发下偶发一次 SIGSEGV，栈在
internal/plugin/proc/{unified.go:234,arena.go:197}（arena 的 getU32）。
该两文件最后修改于 09-10，本提交 0 处触及；随后连跑 5 次单包 +
2 次全量均通过。初步判断是 arena/shared-region 的既有竞态，需单独排查。
|
2026-09-25 15:40:20 +08:00 |
|
|
|
5ccdf24f18
|
test(c-core): 补跨语言开销基线 —— 数据反驳「C 比 Go 快」的直觉
codec.go 的注释写着「EstimateTokens 是否该留在 C 侧由 codec_bench_test.go
的实测数据决定，不要凭直觉断言」，但那个文件此前并不存在（悬空引用）。
plan.md 与设计文档也都在说「需先有真实延迟基线（当前没有）」。本提交把它补上。
## 数据（ns/op，benchmem）
| 基准 | C（经 cgo）| 纯 Go | 谁快 |
|---|---:|---:|---|
| ModelContextWindow（短 ASCII）| 175 | 38 | Go 快 4.6× |
| EstimateTokens / 空串 | 100 | 0.43 | Go 快 230× |
| EstimateTokens / 短 ASCII | 115 | 6.5 | Go 快 17× |
| EstimateTokens / 短中文 | 100 | 29 | Go 快 3.4× |
| EstimateTokens / 中 200 字 | 229 | 509 | C 快 2.2× |
| EstimateTokens / 1KB 中文 | 840 | 2870 | C 快 3.4× |
| EstimateTokens / 1KB ASCII | 2318 | 332 | Go 快 7× |
| TruncateByTokens / 短中文 | 233 | 54 | Go 快 4.3× |
| TruncateByTokens / 1KB 中文 | 3923 | 6918 | C 快 1.8× |
（已用 -count 复测确认稳定；ascii_1k 的异常已单独隔离复测 3 次）
## 三条结论
1. **cgo 固定开销约 95–100 ns/次**，小输入下完全压倒算法差异。
2. C 只在**长中文**（UTF-8 步进重）上领先；长 ASCII 反而 Go 快 7×
（Go 的 utf8.RuneCountInString 对 ASCII 有快路径，C 侧逐字节跑）。
3. ⇒ 判据应是「哪个在**真实输入分布**下真能变快」，不是「哪个看起来更底层」。
## 对后续 C 化的影响（已写进 plan.md §七 与设计文档 §7.1）
- EstimateTokens 的真高频点在 process.go:476 的逐事件循环与 resident.go:552。
字段分布不单一：Source 是短标签（Go 快 17× 那一档），
Input/Response 是对话文本（长中文 C 快、短文本与长 ASCII Go 快）。
⇒ 当前一刀切走 C 会让短串净亏；正确做法是按长度分派，
但须先用真实长度分布复测，不要凭推测动手。
- ModelContextWindow（provider.go:333）与 TruncateByTokens（tooldefs.go:38）
调用点单一、非热路径，开销在单次请求尺度上无关痛痒。
这不否定 C 化方向：协议编解码（JSON 解析、SSE 分片）处理长文本，
才是 C 的主场，也是比「把短函数搬过去」更合理的下一步。
|
2026-09-25 14:51:10 +08:00 |
|
|
|
7351c6ca2e
|
feat(c-core): 内核编解码层 C 化第一刀 —— L1 纯函数层落地并打通构建链
第一刀只做三个纯函数（窗口推断 / token 估算 / token 截断），
价值不在功能（Go 版没问题），而在打通「Go → cgo → C」全链路并
建立可复现的对照范式，后面每扩一个函数都复用它。
## 为什么是这三个
按「无状态 → 有状态」分层，L1 协议编解码最安全：纯 string in → struct out，
不碰网络、不碰 Lua、不碰 goroutine。三个函数更是同一组纯算术，最小可验证切片。
## 关键设计：包内符号链接，不链接静态库、不 include 包外源
三种做法都实测过，只有一种同时满足「可构建 + 可交叉编译 + 缓存可跟踪」：
1. ❌ 链接 `csrc/build/libha_codec.a`（原方案）
- .a 是构建产物、不入库（.gitignore 的 build/ 命中 csrc/build/），
而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空，
实测报 `cannot find .../libha_codec.a`
- 交叉编译 linux/arm64（homed 真实发布目标）时，宿主 x86-64 的 .a
被链进目标产物，实测报 `file in wrong format`
2. ❌ `#include "../../../csrc/src/ha_codec.c"`（包外相对包含）
★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测：包外源把返回值
7→8，`go test` 依然通过（缓存命中、静默沿用旧代码）；同样改动落在包内
文件时立即判红。对「逐步推进 C 化」这是致命的——改 C 源码不生效且无报错。
（包内 shim `#include` 包外源同样漏跟踪，已实测排除。）
3. ✅ 包内符号链接 `internal/agent/api/ha_codec.{c,h}` → `csrc/`
文件在包目录内 ⇒ 缓存按内容正确跟踪；只有一份权威源 ⇒ 无副本漂移，
也不需要「同步 C 源」的 make 目标。
## 不需要额外 build tag
ha_codec 是零依赖纯 C99 源码内联编译，不需要外部库或工具链前提；
而 homed 本就强制 cgo（sqlite3 + gojieba），故 C 路径自然生效。
只用 `cgo` / `!cgo` 一组约束（对比 onnxruntime：那个需运行期 .so，故必须显式 tag）。
## 顺带修掉的既有缺陷（非 C 化引入，但一直缺覆盖）
- Makefile 的 arm64 目标缺 CC/CXX：cgo 回退到宿主 g++，报
`gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'`
（deploy/packaging/build.sh:49 一直是对的，Makefile 漏了）
- Makefile 的 arm64 目标缺 .syso 隔离：cmd/{homed,waiter}/*.syso 是 Windows
COFF 资源对象，Go 会把同目录 .syso 无条件链进任何目标，交叉到非 Windows
平台报 `file format not recognized`（build.sh 有 hide_syso_for_target）
## 验证（每条可复现）
- `make build-linux-arm64` → ELF 64-bit LSB executable, ARM aarch64（82MB）
- `bash deploy/packaging/build.sh linux/arm64 homed` → ELF aarch64（79MB）
- 移走 csrc/build/ 后 homed（cgo）与 waiter（CGO=0）均能构建
- 变异 C 源（131072→777）后**同一缓存**下 go test 立即 FAIL（改前：仍报 ok）
- `make check-codec-paths` 两条路径 OK；`make csrc-test` C 契约测试 100%
- 黄金对照：手写用例 + 2000 次随机对拍，C 与纯 Go 逐值相等
- 全量 `go test -count=1 ./...` → 57 包：38 ok + 19 无测试 + 0 FAIL
新增 `make check-codec-paths` 防回归：只测一条路径时，另一条的破坏不会被发现。
## 文档
- `docs/zh/c-core/llm-orchestration-c.md` 同步为「已落地」，并更正因
「Windows 原生已放弃」而过时的 §2.3（回退路径的理由需重述）
- plan.md 的 P0-1 标记为已修复，附实测证据
|
2026-09-25 14:45:08 +08:00 |
|
|
|
8acd3ce1a8
|
fix(offload): 内核说明不能被再转投（自我循环）+ offload_owned 未接线
★ 线上实测两个缺陷：
1. **自我循环**：转投会在队列留一条 [系统] 说明（source=kernel），
而转投条件把这条说明也算进「积压够了」⇒ 每次转投都产生下一轮要转投的东西。
实测 5 秒内连续触发两次，分诊助手不断收到「N 条积压已转投」这类噪音。
修法：takeQueuedInputs 排除 isKernelNotice（source=kernel）。
2. **offload_owned 永远为 false**：我加了 ResidentInfo 字段、加了状态面映射，
却漏了在 rc.info() 里赋值 ⇒ 线上转投子明明存在，读出来是 null。
这类「加了字段但没接线」不会报错，只会让父的判断悄悄失效
（父据此决定回收策略，读到 false 就会把临时助手当成正式子）。
测试 +3：说明不转投 / 循环必须终止 / offload_owned 会被上报。
前两条已实测「禁用守卫会失败、恢复后通过」，是真回归测试。
|
2026-09-19 17:47:44 +08:00 |
|
|
|
943eef01cf
|
feat(resident): 分诊助手定位 + 残余任务由父显式决定
用户澄清（重要定性）：这不是「内核替父决定」，而是**及时反馈** ——
主 agent 忙时不该让用户干等十几分钟。子 agent 是**分诊助手**：
简单的直接处理并回复，需要主 agent 的立刻回「忙碌中，请稍候」、不勉强作答。
三处补齐：
1. 分诊助手的职责提示词（之前完全没给 ⇒ 子不知道自己为什么存在）：
两条路（直接办 / 报忙碌）、拿不准时报忙碌、必须 output_send 到原通道。
2. 驻留子继承父的 SystemPrompt（之前没传 ⇒ 子只用一句兜底文案，
拿不到「异步通道必须显式 output_send，否则回复被静默丢弃」这条铁律。
webui 这类同步通道能回是因为走 ResponseCh，掩盖了这个缺陷）。
3. 残余任务由父显式决定（用户要求）：reclaim/destroy 时子手头未处理的消息
不再由内核悄悄处置 —— 内核只负责列清楚，父用 residual=keep/drop 决定。
之前 pendingEvents 只收带 ResponseCh 的，异步（qq）残余任务完全不在内，
被销毁时静默消失、用户零反馈且日志无痕。
配套：
- scheduler.takeAllPendingEvents：取走全部未执行事件（不筛通道）
- ApplyResidual(keep|drop)：keep 转回父队列（保留 ResponseCh），
drop 逐条记日志 + 给同步调用方补终态（否则 cli/a2a 永久挂起）
- 状态面暴露 offload_owned，让父分清「我建的子」与「内核临时拉的助手」
- 工具 schema 加 residual 参数并说明 drop 的代价
这也是用户观察到的「机制很自然」的落点：分诊助手就在同一张登记表里，
父能 inspect/send/compress/reclaim/destroy，控制面 6 动作按 id 生效不区分来源。
测试 +7（残余 keep 转回且保留 ResponseCh / drop 通知同步调用方 /
空残余如实报告 / 分诊提示词 / 继承 SystemPrompt），
其中 drop 那条已实测「对着静默丢弃的旧实现会失败」。全套绿。
|
2026-09-19 17:43:16 +08:00 |
|
|
|
01909bb914
|
fix(offload): 转投必须保留 ResponseCh，否则同步调用方永久挂起
线上实测第二个 bug：转投生效、子也正常处理（日志各 ~3s），但 webui 的 HTTP
请求一直挂着不返回，最终 504。
根因：第一版用 InjectInputTo 转发，它会**重建** InputEvent ⇒ ResponseCh 被丢掉。
而 cli / a2a / webui 这类**同步**调用方正阻塞等这个 channel。
仓库反复警告过同一件事（Agent.Stop 的注释：「带 ResponseCh 的同步注入方
（cli / clawhubadapter 均无超时）会永久挂起」）。
修法：改走既有的跨 agent 投递原语 DeliverRouted —— 它推**原事件**，保留
ResponseCh/RequestID，只往 payload 里补转投标注。
回归测试 TestForwardKeepsResponseCh 断言**最强的那条性质**：真的等同步回执回来。
（不用「读子的 InputChan」来断言：SpawnResident 会启动子自己的调度循环，
它会与测试抢同一个 channel，那样写出来的测试是 flaky 的 —— 我第一版就是这样，
实测挂死过一次。）
已实测该测试对着错误实现会失败（10s 超时）、修后通过。
|
2026-09-19 17:16:24 +08:00 |
|
|
|
fe1d2672d8
|
fix(offload): 积压可能全堵在 io 输入 channel，不在就绪队列
线上实测发现上一版**永不触发**：主 agent 跑着 6×45s 的长任务、我连发 4 条消息，
scheduler 始终显示 queue=0、residents=0，转投一次都没发生。
根因：schedulerLoop 是**同步执行**任务的，所以「正忙」期间它根本回不到循环顶部
去调 pumpInbox —— 后到的输入全堆在 io.inputCh（容量 256）里，压根没进 sched.queue。
而 takeQueuedInputs 只看 s.queue ⇒ 恒取不到东西。
★ 仓库里早记过同一个坑：armStop 的注释写着「pending 是还没被 pumpInbox 搬进队列
的那一段……只数 s.queue 会得到 0（实测），配额随之失效」。我重犯了它。
修法：转投前先 drainInboxToQueue() 把 channel 里的输入搬进队列。
与 pumpInbox 的区别是**不要求 hasRoom** —— pumpInbox 满时会停下保留背压，
而转投场景恰恰是「队列空、输入堵在 channel」（调度器回不到 pumpInbox）。
队列上限仍由 enqueue 把关，放不下的给同步调用方 skipped 终态（不丢、不阻塞）。
回归测试 TestOffloadSeesInputsStuckInChannel 精确复现该现场状态：
已实测它对着修复前的逻辑**会失败**（期望 3 实际 0），修后通过 —— 是真回归测试。
|
2026-09-19 17:05:38 +08:00 |
|
|
|
69446a2649
|
feat(scheduler): 主 agent 忙时把积压任务自动转投给驻留子
问题（2026-09-19 线上实测）：主 agent 被长任务占住时（现场：12 分 8 秒、69 次
工具调用），后来到达的消息全部以 level insufficient 排进中断队列干等 —— 同级
中断不能抢占同级运行任务（canPreempt），只能等前一个跑完。而内核本有驻留子
（独立 agent + 独立调度器）可并行干活。
行为（用户 2026-09-19 明确要求）：
- 触发：运行任务持续 > offload_busy_after(5m) 且积压 >= offload_min_pending(3)
- 拉起/复用「转投专用」驻留子，把积压的纯排队输入转投过去
- 在原队列位置留下说明「[系统] N 条积压任务已转投给驻留子 agent X 处理…」
通道配置（按用户口径，与人工创建的子刻意不同）：
- 不配 inputch（内核的干活 agent，不接收插件用户输入）
- 持有全部输出通道（结果要能发回 qq/webui 等正确通道）
三个设计要点（都是实测撞出来的，写进代码注释与设计文档 §7.1）：
1. 检查必须在**独立 goroutine**：schedulerLoop 同步执行任务，放它里面在
「正忙」期间根本回不到循环顶部 ⇒ 永不触发（我第一版就写错了，测试才发现）。
2. 只转投 TaskQueued 纯排队输入：中断任务带级别语义、self 任务与父的记忆面绑定。
3. 转投失败/关闭时必须把任务**放回队列前端**：吞一条输入比多处理一条更糟。
这是设计 §7「决策在父的模型手里」的**刻意例外**（父正忙、物理上无法决策，
而积压任务本来就是空的），已在文档中显式记录，且默认关闭、由部署方显式打开。
测试 11 条：只取排队输入 / 不足量不取 / 放回不丢任务 / 说明自解释 / 默认关闭 /
空闲不触发 / 端到端转投 / 上限不增殖 / 独立 goroutine 确实会触发。
|
2026-09-19 16:59:47 +08:00 |
|
|
|
e273924511
|
fix(llm): 参数无法解析时给出真因，不再静默丢弃整条调用
★ 上次修复误判了成因。真实根因（本次运行日志 34/34 同形）：
{"command": "…完好的长命令…", "timeout": 20s}
command 一字节没错，只是 timeout 值少了引号 —— cmd_run 的 schema 把 timeout
声明成 string、示例写着 "10s, 1m, 30s"，模型照抄格式却忘了引号。
finish_reason=length 出现 0 次 ⇒ 上次那条"截断"分支从不生效。
旧行为把**整个参数**丢掉，模型只看到 "command is required"，看不出坏在 timeout，
只能原样重试。实测本次运行 cmd_run 失败率 35%（34 败 / 71 成），
12 分钟的任务里更是 48% 时间耗在这上面 —— 每次失败都付一次完整 LLM 往返。
三处改动：
1. repairToolArgsJSON：解析失败时先试窄修复 —— 只给"值位置上未加引号的带单位
数字"补引号，且修完必须真能解析成功才接受。不碰合法 JSON、不动正文里的 20s、
不会把真截断"修好"。
2. 修复仍失败时不再静默降级成空 map，改为带 __arg_error 交给模型，并按成因
分流文案：截断→拆小参数；JSON 写坏→提醒带单位的值要加引号。
3. 统一键名 __arg_error（原 __truncated_error 只覆盖截断，语义过窄）。
同一缺陷面不止 cmd：agentcli/healthcheck/timer 都有 string 类型却以
"5m, 1h" 作示例的参数，此修复一并覆盖。
回归测试：真实日志样本修复、保守性（不碰合法/正文/截断）、
端到端（修复后 timeout 仍能被 time.ParseDuration 接受）。
|
2026-09-19 16:49:16 +08:00 |
|
|
|
53e7106985
|
fix(llm): 参数解析失败不再丢弃完好字段（改错值格式，不是截断）
★ 上次修复误判了成因。真实根因（日志 11/11 同形）：
{"command": "…完好的长命令…", "timeout": 20s}
command 一字节没错，只是 timeout 值少了引号 —— 而 cmd_run 的 schema 把
timeout 声明成 string、示例写着 "10s, 1m, 30s"，模型照抄格式却忘了引号。
实测 finish_reason=length 出现 0 次，所以上次那条"截断"分支从不生效。
旧行为把**整个参数**丢掉：模型只看到 "command is required"，看不出是 timeout
写坏了，只能原样重试 —— 12 分钟的任务里 30 次失败 / 32 次成功（48% 浪费），
每次失败都付一次完整 LLM 往返。
改法：parseToolArgsJSON 失败时先试 repairToolArgsJSON，只做一件很窄的事 ——
给"值位置上未加引号的带单位数字"补引号，且修完必须真能解析成功才接受。
因此不会改坏合法 JSON、不会动字符串正文里的 20s、不会把真截断"修好"。
真实日志样本 + 保守性 + 反伪造三组回归测试已钉死。
|
2026-09-19 16:47:13 +08:00 |
|
|
|
6ddef5e49f
|
feat(llm): 声明真实上下文窗口 + 工作区间与窗口分离
问题：core.llm.model=AUTO，而 ModelContextWindow("auto") 匹配不到任何分支、
掉进 default 32768 —— 该源真实窗口是 1M（实测 990,034 token 的 prompt 通过），
内核却按小 30 倍的窗口算全部预算。
三处改动：
1. ModelContextWindow 补 deepseek-v4/v3 → 1M；推断不出时打日志（静默降级是
这次问题的成因，不能再默默退回一个小值）。
2. sourceFieldDefs 补 context_window 声明：它早已被 readInt 读进 LLMSource
并透传到 provider，但没进这张表 ⇒ WebUI 里看不见也改不了。
3. ComputeTokenBudget 新增 maxTargetTokens=600000：窗口 1M 不等于按 838K
（80%）干活。标称窗口≠有效窗口，600K 是该源最优工作区间，所以把
「窗口上限」（会不会被上游拒）与「工作区间」（预算分配）分开。
配套 core.llm.max_tokens 4096→32768（实测长输出样本达 18,272 token，
16384 仍会截断；上限是 cap 不是目标，短问答零成本）。
测试：tokenbudget_test.go 钉死封顶生效且小窗口不受影响；
context_window_test.go 钉死推断值与显式声明优先级。
|
2026-09-19 14:24:31 +08:00 |
|
|
|
95292aff8e
|
test(llm): 钉死截断必须短路工具分派
补一条端到端断言：截断的 tool call 绝不能拿着空 map 走到 files_write
（那会回 'path is required'，模型据此原样重试）。断言 executeToolCallInner
的短路 + 指引可执行。
|
2026-09-19 13:53:56 +08:00 |
|
|
|
2722d76095
|
fix(llm): max_tokens 截断不再静默降级成空参数
长参数工具调用（整段脚本/大 JSON）被 core.llm.max_tokens 从中间切断时，
上游回 finish_reason=length，而旧实现把这个信号整个丢掉：残缺 JSON 解析失败
后静默降级成空 map，工具只看到参数为空并报 'path is required'。模型因此完全
看不出真因，原样重试四遍、次次撞同一堵墙（2026-09-19 实测 4 次 files_write 失败）。
注：files_read 并未失败——是写挂之后模型反复重写把读卷进同一轮，看起来像两者都报错。
改法：
- finish_reason=length 时不再静默降级，改为塞入 __truncated_error 指引，
告诉模型「参数被截断 + 请拆成多次调用/追加写 + 勿原样重试」；
- executeToolCallInner 见到该标记即短路，不拿空参数去调工具；
- 非截断的残缺 JSON 保持旧行为（避免把「厂商不回 finish_reason」误判成截断）。
回归测试 2 条钉死这两面。
|
2026-09-19 13:49:21 +08:00 |
|
|
|
01113664b4
|
fix(obs): 抢占日志改在判决点打（修自伤）+ scheduler 事件接进 SSE
## 修我上一版的自伤
上一版把 preempt 日志打在 `executeNewTask`，但那时 `nextRef` 已经把
`s.running` 换成了抢占者自己，于是输出成了
preempt start: task#2 ... -> victim task#2 (cli)
victim 打印的是入侵者本人。判据必须落在 `registerInterrupt`——那一刻
running 还是真正的受害者。改为在抢占判决点打：
[agent] preempt: task#2 class=interrupt level=3 from cli (L3) preempts task#1 class=queued level=0 (qq)
## 补上「入队而非抢占」的日志
中断到了却没生效，此前完全不可解释。现在两种成因分开写：
[agent] interrupt queued: ... vs ... (qq) — running in critical section; queue=N
[agent] interrupt queued: ... vs ... (qq) — preempt cooldown; queue=N
[agent] interrupt queued: ... vs ... (qq) — level insufficient; queue=N
没有这条，`interrupt from X` 打过之后任务为什么没让位就只能猜。
## scheduler 事件接进 SSE
`EventScheduler` 此前既不在 `handler_chat.go` 的 subTypes、也没有任何订阅者
（全仓 grep 零命中）——内核里 suspend/resume 只 publishEvent，于是事件发出来
就掉地上，对内对外都不可见。加进 subTypes 后前端/客户端能看到抢占链。
## 验证
- preempt_logging_test.go 增一条：victim 与入侵者必须是不同来源（qq vs cli），
且排队输入对排队任务 `canPreempt` 必为假。
- 实测输出含 `cli (L3) preempts task#1 class=queued level=0 (qq)`。
- 全量 `go test ./internal/... ./cmd/...` 与 `go vet ./internal/...` 全绿。
|
2026-09-19 11:57:50 +08:00 |
|
|
|
b1ec278136
|
feat(obs): 抢占日志说出「受害者是谁」——suspend/resume 此前完全不落日志
排查「我的任务怎么被莫名打断了」时撞上的观测缺口。
## 缺口
`executeNewTask` 里挂起、`resumeTask` 里恢复，两处都**只发事件、不写日志**：
a.sched.suspend(t, f)
a.publishEvent(events.EventScheduler, map[string]any{"action": "suspend", ...})
于是生产日志里只有两行：`interrupt from X` 与 `LLM request cancelled by
preemption` —— **看不到受害者是谁、被谁挤下去、后来有没有恢复**。后果是实测过的：
按时间先后猜凶手，把时间上相邻的输入误认成抢占者。
## 改动
- `sourceOf(task, frame)`：取可辨识来源（`evt.Source` 优先，回退 OutputChannel，
自循环任务给 `self:<channel>`）。取 Source 而**不是** OutputChannel：
前者回答「谁送来的」（qq / homeagent-mail-bridge / timer / child/xxx），
后者只回答投递到哪个通道；多数场景同名，但因果链上要的是前者。
- `describeTask(task)`：`task#N class=queued|interrupt level=L`。
- `suspendDepth()`：日志专用，走锁而不是让日志点直接摸 `suspendStack`。
- 三个日志点：抢占开始（含 victim）、挂起（含来源与栈深）、恢复。
输出形状：
[agent] preempt start: task#2 class=interrupt level=4 from cli -> victim task#1 class=queued level=0 (qq)
[agent] suspend: task#1 class=queued level=0 (qq) yields to an interrupt; suspendStack=0
[agent] resume: task#1 class=queued level=0 (qq) resumes after the interrupt finished
## 验证
- 新增 preempt_logging_test.go：抢占后栈深 0→1、sourceOf 取到 qq、self/nil 不 panic。
- 实测日志（TestPreempt_HigherPreemptsAndResumes）三条齐全，能一眼看出
是 `cli` 的 L4 挤掉了 `qq` 的排队任务、随后 qq 恢复。
- `go test ./internal/... ./cmd/...` 全绿。
|
2026-09-19 11:31:04 +08:00 |
|
|
|
895948b24e
|
fix(stop): 配额须计入停在输入 channel 的待处理消息
实测：停止后排队消息仍逐条跑完。原因是 armStop 只数 sched.queue，
而用户按下停止时调度器正忙于当前任务，其余消息大多还没被 pumpInbox
搬进队列、仍停在 inputCh ⇒ queued=0、配额归零。
- IOManager.PendingInputs()：暴露 channel 中待处理条数。
- armStop(pending int)：queued = len(s.queue) + pending。
- 补 TestStop_ArmCountsPendingChannelInputs 锁死该口径。
|
2026-09-18 11:39:04 +08:00 |
|
|
|
698ff7ddd5
|
fix(stop): 修自伤——interceptLoop 里 takeStop() 被 || 短路提前消费
上一版把 stop 标记在 interceptLoop 里消费掉了一部分：
`if n := armStop(); n > 0 || takeStop() { ... }`，queued=0 时短路到
takeStop()，标记先被吃掉，stepLLM 永远看不到 → 取消后照样重跑一轮。
实测：日志正确打出 stop requested ... queued=0，但生成仍跑到自然结束（5000+ 字全文落库）。
改为只 arm 不 take（takeStop 只由 stepLLM 消费），并补一条**经真实
interceptLoop** 的用例：它必须 a.Start()（第一版测试只调 New()，
interceptLoop 根本没跑，假绿）。已验证该用例在注入此 bug 时失败、修复后通过。
|
2026-09-18 11:32:20 +08:00 |
|
|
|
ccc2ac2d4d
|
fix(stop): 停止按钮真正生效——停止 ≠ 空中断；鸿蒙 screensue 支持 HTML
两处鸿蒙端缺陷 + 一个跨端（WebUI/GUI/鸿蒙）的停止语义缺陷。
## 症状（实测取证）
1. **鸿蒙终止按钮按下没反应**。POST /chat/interrupt 带空 body，接口回 200
`{"status":"interrupted"}`，但 journalctl 零中断日志、生成继续跑到自然结束。
2. **鸿蒙 screensue 不解析 HTML**，把标签当普通字符串显示。
## 根因
停止按钮走的是「空内容中断」，而 interceptLoop 有一行
`if text == "" { continue }` —— 空内容被判为「无事发生」直接丢弃。
所以停止指令从未到达调度器；接口那个 200 是不诚实的。
另查明两条会放大症状的既有问题（停止后仍在跑）：
- `chatStreamWithFallback`：流式连接失败时无条件回退非流式 `Chat`。
上下文已取消时这等于**再发一次完整请求**（停止后模型继续生成）。
- `stepLLM`：`context.Canceled` 一律 `outcomeContinue` 重跑本步。
这是给「被更高中断抢占」用的（现场要交出去、稍后继续），
但用户按停止是「不要了」，重跑就是停止没生效。
## 修法（按用户明确的设计）
停止 = ①立即结束当前 LLM 推理（不重试、不恢复）；
②对**停止那一刻已排队**的 x 条消息，后续在 pre-action 阶段依次短路。
- scheduler：新增 `armStop`（登记快照配额并返回当时排队深度）/`takeStop`/
`consumeCancel`。配额取快照值（停止后新到的输入不受影响），
重复按停止取 max 不累加（两个客户端同时按不该翻倍）。
- `interceptLoop`：读 `stop` 标记。停止时 armStop + cancelCurrentLLM；
**纯停止不再进中断队列**（旧实现把它当空中断入队，所以停完还会活）。
带注释的停止（`/stop 换个话题`）仍走中断路径。
- `stepLLM`：取消 + `takeStop()` → 直接 `outcomeDone`（不再重跑）。
- `stepPrepare`：`consumeCancel()` 命中即在 pre-action 短路收尾。
- `chatStreamWithFallback`：以 **ctx.Err()** 为判据拒绝回退（不是「错误是不是
Canceled」——很多 provider 用 Canceled 表示「不支持流式」，那种必须继续回退，
否则会把探测误判成取消；这条区分是跑全量测试时才暴露的）。
- WebUI handler / CLI `/stop`：空消息时带 `stop:true`。
## 鸿蒙端
- `BridgeCaps.ets`：新增 `looksLikeHtml`（首字符 '<' + 字母开头标签名，
避免误判 "<3" 这类文本）、`screensueHtml`、`escapeHtmlText`。
- `ScreensuePage.ets`：HTML 走 **RichText**（只解析 HTML 子集、无脚本无网络），
纯文本仍走 Text。不用 Web 组件：agent 下发的是第三方内容，
Web 默认带 javaScriptAccess/fileAccess，等于让远端内容在客户端执行脚本。
注入主题前景色，避免 RichText 用系统默认色导致深色主题下黑字不可见。
- `ChatSession.ets`：`interruptChat` 改发 `{stop:true}`（含类型声明，
ArkTS 禁止无类型对象字面量），并在本地即时复位忙态 + 提示「已停止」。
## 验证
- 新增 `stop_semantics_test.go`：停止终结任务不重试（provider 调用次数恒为 1）、
配额是快照（x 条短路、随后新到的不受影响）、重复 arm 取 max。
- `go test ./internal/... ./cmd/...` 全绿。
- 鸿蒙 HAP 构建通过；unsigned 包已装进模拟器（signed 包受
READ_PASTEBOARD 授权限制装不上，与既有记录一致）。
|
2026-09-18 11:26:12 +08:00 |
|
|
|
e70d2171ee
|
refactor(terminal): 内核开终端/命令历史权威视图，WebUI 与 CLI 都改接内核
按「内核开，两个插件接」重构终端与命令历史的数据归属。
背景：此前 WebUI 与 CLI 各订 EventToolCall/EventTerminalOutput 攅一份状态，
同一件事两份推导，还各自踩过同一个坑——工具 result 是 Go 的 map 文本
（map[cols:80 ... id:term_2 ...]），断言成 map[string]interface{} 永远失败，
terminal_create 的 id 回填不生效，/terminals 因此恒空（WebUI 也一样）。
实测确认：WebUI 自己的 /api/v1/terminals 与 /api/v1/cmd/history 同样是空的。
内核开（权威唯一真相）：
- internal/agent/core/terminal_registry.go：TerminalRegistry 归并两类事件——
EventToolCall（terminal_create/close、cmd_run，id/command 从 args 或 Go map
文本回填）与 EventTerminalOutput（agentcli 生命周期 + 输出，含 64KB 缓冲上限、
100 条命令历史、50 个终端上限）。
- internal/sdk/terminal.go：新增 TerminalAPI（ListTerminals/CmdHistory）与
TerminalStatus/CmdExecStatus DTO。**不塞进 KernelStatus**：那是全量快照，
前端每 3 秒轮询 /kernel，背上每终端最多 64KB 输出会让轮询成本爆炸；
终端输出是按需拉取的明细，另开接口。
- Agent 订阅自己的事件总线（subscribeTerminalRegistry），且**只根 agent 建**
（驻留子共用同一总线，每个子都建会 N+1 份重复记账）。
- SDKConfig/Registry/bootstrap 接线：pluginReg.SetTerminalAPI(agent)。
生产者补全（agentcli）：终端无输出时 ticker 不发事件，内核就无从知道终端
存在。新增 emitTermState，在 handleCreate/handleClose/readLoop 退出（超时/
进程结束/读取错误/stopCh）显式上报 running 状态，并给输出事件补 command 字段。
handleClose 改为接收 *sdk.PluginSDK 以便上报。
两个插件接（消费方）：
- WebUI：删掉本地 termStates/cmdHistory/subscribeTerminalStream/handleToolEvent
及不再使用的 getStr；/terminals 与 /cmd/history 直接读 s.Terminal()。
- CLI：删掉上一轮刚加的 subscribeToolEvents 与 cliTermState/cliCmdExec；
/terminals 与 /cmd/history 直接读 s.Terminal()。两条路（local/remote）都通。
测试：新增 terminal_registry_test.go，锁死 Go map 文本解析（旧缺陷根因）、
生命周期、CLI 直调路径（无 EventToolCall 仅凭 output 事件建条目）、历史与
终端数量上限。全量 go test ./internal/... ./cmd/... 通过。
|
2026-09-17 18:56:15 +08:00 |
|
|
|
49695c38f3
|
feat(memory): 场景双通道——主动声明与被动涌现并存，且互不吞噬
按「声明式的也要支持，相当于主动被动两条路」落实。此前两者只是恰好并存，
没有边界，实测会互相吃掉（下面的坑就是）。
- Triple.Scenes []string（多值）：一轮写下的记忆**两条路都挂**。
只挂一条会丢东西——只挂声明则细粒度唤起丢失，只挂涌现则首次交互
（场景还没长出来）没有兜底。单值 Scene 保留兼容。
- TurnScene：Primary 用于写（优先涌现场景，首次退到声明场景兜底），
Keys 是两条路的并集，用于召回（声明+涌动的场景一起进 RecallByScene）。
- EnterSceneWithHint：主动路 EnsureScene（声明即建场景，不等第二次），
被动路 EnterScene（指纹聚类）。写侧由 executeToolCall 把本轮场景集合
传给 memory_commit，模型不需要知道"场景"这回事。
踩到并修掉的坑（两条路互相吞噬）：
最初让声明场景也吸收**整轮指纹**，于是 chan:qq 的相似度永远是 1.0，
把后续所有同类轮次全部吃掉 → 被动路再也长不出更细的场面，
实测 turn2.Emergent=true 但 Primary 仍是 chan:qq、没有 auto: 场景。
修法：给场景加 origin（declared/emergent）：
- 被动聚类只认 origin='emergent' 的场景（声明场景不进相似度空间）；
- 声明场景的特征**只从键自身解析**（chan:qq/peer:group_1 → {chan:qq, peer:group_1}），
白名单 kind（chan/peer/peer_group/tool/topic/part），不猜——
「老大2026-09-04_12:27_qq私聊图片」里的 12:27 也是 kind:value 形态，
放进特征空间就是往相似度里灌垃圾（有测试钉住）。
- 声明路的泛化靠**层级键前缀**（chan:qq 覆盖 chan:qq/peer:x），机制各归各。
- memgc -scene-stats 增加 [declared|emergent] 与 strength/features 两栏，
可直接观察两条路各自在长什么。
新增/改写用例：
- TestDeclaredAndEmergentBothLearn：首次交互兜底到声明场景 → 第 2 轮长出
细粒度涌现场景且**优先用于写入** → 声明场景不进相似度空间（防止压死被动路）
但仍走声明键取回 → 两条路都进召回集合 → 声明键特征解析与白名单。
- TestEffectiveScenes：多值+单值合并去重保序。
go build/vet 干净，go test -count=1 ./... 全绿。
|
2026-09-15 09:37:29 +08:00 |
|
|
|
d4f9a12db0
|
feat(memory): 场景从「声明」改为「涌现」——场面指纹自己长成场景
上一版场景是声明/派生的：调用方写 scene="chan:qq"，或由通道机械派生。
那不是涌现，是贴标签——标签谁定、怎么定全靠人。按「像人一样：干了什么事，
后续类似场面自动唤起对应记忆」的要求重做。
机制（全部取自运行时可观察量，无需模型配合、无需人工标注）：
- **场面指纹 Situation**：每轮采集 `chan:xx / peer:xx / peer_group:xx /
tool:xx / topic:xx / part:xx`。权重按种类：通道与对象最强（1.0），
工具次之（0.8），话题是软信号（0.4），时段最弱（0.2）。
- **归属判定用加权 Jaccard**（不是字符串相等）：共享特征权重和 / 并集权重和。
加权是必须的——`chan:qq` 与 `topic:排班` 的证据力差 2.5 倍，不加权会让
一次偶然的话题重合把两个不同场面并成一个。
- **涌现**：同类指纹重复到 minSceneEvidence=2 次才长出场景
（首次只登记 situation_evidence 足迹）。一次性的交互不是「场面」，
给它建场景会让库被一次性事件撑满、之后每次路过都召回一堆只发生过一次的事。
- **强化**：场景每次重现 strength+1、并入新特征。
- **唤起**：RecallBySituation 按**相似度**取回（阈值 0.35，比归属阈值 0.5 低
——想不起来是损失，多想起一条只是多几行上下文），与措辞无关。
- **遗忘**：DecaySceneRefs 按半衰期让久未重现的关联淡出，低于 floor 直接删；
已接进 archive 心跳（半衰期 30 天，比「这个月没做过这类事」更久）。
三个必须讲清的边界：
1. 一轮只解析一次场景（TaskFrame 缓存）——多解析一次就多记一次强度，
「工具调得多」会被误读成「这个场面更常出现」。
2. 声明与涌现**并存**：声明是「我知道这是哪个场面」（插件注入点最清楚），
涌现是「这轮看起来像哪个场面」。两者都进召回。
3. 记忆挂载全自动：memory_commit 没写 scene 时落到本轮涌现场景，
模型不需要知道场景这回事。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例（核心证据）：
- TestSceneEmergesFromRepetition：首次不建场景 → 第 2 次同类场面长出场景 →
同场面**不同话题**仍并入同一场景 → 换通道的场面自己长出独立场景（共 2 个）→
强度随重现增长、特征多条。全程没有任何人声明过场景键。
- TestSceneRecallsBySituationNotWording：场面里写下的规则，换措辞后仍被
自动唤起（含原句），无关场面不唤起。
- TestSceneRefDecay：一个半衰期权重减半、第二个半衰期低于 floor 被清掉，
仍在重现的场景不受影响。
- TestSituationFeaturesFor：指纹维度齐全、归一化、数值 group_id 转换、nil 安全。
|
2026-09-15 09:27:39 +08:00 |
|
|
|
b7e47a1b1f
|
feat(rel): 文档层接入场景（document 节点挂场景）
场景贯穿流水线的 doc 层补完：
- 新增 TagSceneDocument，linkBlocksToDocument 里建文档节点时一并挂场景；
- RecallByScene 返回该场景下的文档 id（可枚举「这个场面有哪些文档」）；
- 文档场景由**来源派生**（chan:<source>），不存冗余 Doc.Scene 字段——
存一份会随来源改名而说谎，是同一事实的第二份真相。
go build/vet 干净，go test -count=1 ./internal/memory/ ./internal/agent/core/ 全绿。
|
2026-09-15 09:16:22 +08:00 |
|
|
|
9d45cd0277
|
fix(rel): 场景贯穿流水线到块层 + 编辑不再丢置信度/场景 + 构建默认带 onnxruntime
三件事，前两件是上一轮热部署暴露/遗留的真缺陷。
1) 热部署差点静默降级（已修）
`make build` 之前**不带任何 tags**，而发行构建（deploy/packaging/build.sh）
默认 HOMED_TAGS=onnxruntime，package-linux.sh 还会直接拒收非 onnxruntime 二进制。
实测差异：33MB vs 84MB；启动日志里
「multimodal space active: provider=chineseclip dim=512」整行消失、
少加载一个插件（chinese-clip/qwen3vl provider 降级）、
静态词向量退回 fallback。即「随手 make build」与「发行构建」不是同一个东西，
而部署时无从察觉。
修：Makefile 的 build 默认 HOMED_TAGS ?= onnxruntime（与打包脚本一致），
构建后自动校验二进制里有没有 onnxruntime，缺了就打 WARN。
生产已按此重新构建部署（v1.4.0+hotfix.d98bf51，已核实 provider 行回归）。
2) memory_edit 每跑一次就静默降级一次（新）
memory_edit 是「按包含匹配 Purge + 写新三元组」，中间那一步把旧关系的
置信度、原句、**场景引用**全丢了：置信度被重置成默认 1.0，场景钉死的记忆
被打散成无场景。而关系复审心跳（reviewLoop）走的正是这条路——每轮复审都
在无声地削记忆质量。
修：编辑前用 FindRelations 精确取回旧关系，把置信度/原句/场景带到新三元组；
新增 ScenesOfRelation。Purge（hard/soft）与 PurgeNoise/PurgeOrphans 之后
统一清理悬空 scene_refs，SceneStats 不再说谎。
3) 场景贯穿流水线到块层（按「rel 应贯穿整条流水线」的设计）
此前场景只到 relation/entity：块（L0/L3 一等记忆块）没有场景，于是
「那场 QQ 对话里发过来的那张图」在场面重现时永远取不回来。
- MemoryBlock.Scene + memory_blocks.scene 列（幂等 ALTER 迁移）。
- scene_refs 增加 ref_text 承载字符串主键（块/文档 id 不是数值）。
**不能只 ALTER ADD COLUMN**：唯一约束要从 (scene_id,kind,ref_id) 变成
含 ref_text 的四元组，而 ALTER 改不了约束——旧约束会让「同场景第 2 个块」
直接冲突（只在多块场景暴露）。改为按列探测后整表重建并搬运旧数据。
- PutMemoryBlocks 同事务挂 scene_refs(kind='block')；无场景重写不覆盖已有场景
（否则一次无场景重写就静默抹掉挂载）。
- RecallByScene 返回块；FormatContext 增「场景素材」段（模态 + 文本/短 digest），
上限 3 条。
- 生产者接线：attachBlocksToSentence 让块继承承载它的三元组的场景；
linkBlocksToDocument 让文档的块继承文档来源场景（QQ 归档的图挂 chan:qq）。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：场景块（取回/同场景多块/无场景重写不抹场景/悬空引用清理）、
**旧表结构迁移**（降级成旧 scene_refs 后重开，旧数据保留且多块可写）、
场景素材注入、FindRelations+ScenesOfRelation 编辑搬运闭环。
生产：已重建（-tags onnxruntime）并原子替换 /usr/local/bin/homed + 重启，
35 插件全加载、panic/fatal=0、chineseclip 空间 active。
|
2026-09-15 09:03:36 +08:00 |
|
|
|
d98bf512e1
|
feat(memory): 场景式关联召回——给记忆节点赋场景引用，场面重现即取回
背景（实测）：带条件的记忆召不回来。生产库里明明有
「QQ回复禁用Markdown格式 --规定--> 纯文本不用Markdown」「老大 --偏好--> 同左」，
但输入「QQ回复格式」时命中 148 个实体、规则排第 32，注入只取前 5——规则根本没进去；
输入「在吗」这种零内容词的短消息，向量路反而灌进 17 个毫不相关的实体。
根因：词法/向量召回都建立在「字面或语义相似」上，而条件式记忆（在什么场合该怎么做）
约束的是**场面**不是话题。用户措辞不重合时它天然召不回；措辞太宽（"QQ"）时又被同形
命中淹没。另一处：自动注入只给实体名索引，而规则本体长在关系上（relation_type + object），
即使命中名字也拿不到「纯文本不用Markdown」这句正文。
改动：把「触发条件」升成一等索引维度。
- schema：新增 scenes(key) + scene_refs(scene_id, kind, ref_id, weight)，
kind ∈ relation|entity。刻意不建外键：节点可能先于引用被清理，
悬空引用由读取侧 JOIN 过滤，级联删除会把清理变成跨表事务。
- 场景键是分层字符串（`/` 分隔，由宽到窄）：chan:qq、chan:qq/peer:group_123、
tool:qq_get_message。NormalizeSceneKey 归一（小写、空白/标点→_、按 `/` 分层），
空白不算层级——否则「老大2026-09-04 12:27 QQ私聊图片」这种来源名会被拆成伪层级。
- 写入即挂场景：Triple 新增 Scene 字段，commit() 在同一事务里把「关系 + 两端实体」
挂到场景上（同事务是必须的：关系进库但引用丢了 = 这条记忆永远无声地召不回来）。
- 召回：RecallByScene 前缀匹配（chan:qq 取回 chan:qq 及所有更窄场景；用 `/` 兜底
防止 chan:qq 吞掉 chan:qq2），按 weight（=写入置信度）降序，返回**关系全文 + 原句**。
- 注入：BuildContextInScene 在词法/向量之外叠加场景路，FormatContext 把场景块排在
最前（规则对行为的约束强于话题相关的实体名），上限 8 条 + 原句截断 60 字；
场景实体不在【记忆索引】里重复占位。BuildContext(input) 保持原语义（无场景）。
- 当前场景推导：payload.scene 显式声明 > 通道（chan:qq）> 工具（tool:qq_get_message），
并列命中不取交集。qq 通道本身 RecallPolicy=none（到达的是中断元文本），
真正召回在 qq_get_message 工具上——现在那一步同时带上 chan:qq 与 tool:qq_get_message。
- 写入侧：memory_commit 新增 scene 参数（逐条 triples[].scene 优先，顶层 scene 作批次默认）；
docToTriples 按文档来源自动带 chan:<source>（QQ 归档的知识天然属于 QQ 场面）。
不做自动猜测：猜错的场景会把无关记忆钉死，之后每次进入该场面都被注入。
- 存量引导：memgc -tag-scene <键> -entity-glob <GLOB>。用 GLOB 而非 LIKE——
LIKE 对 ASCII 不区分大小写，`%QQ%` 会把对象带 /home/newqqagent 的路径类记忆
（生产数据目录、email-mcp、dify-ops 路径…实测 7 条）一起卷进 QQ 场景。
- 清理对齐：PurgeNoise/PurgeOrphans 之后顺带删悬空场景引用，并提供
PurgeStaleSceneRefs；memgc -scene-stats 看场景规模。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：场景键归一（含超长/分层/空白）、写入即挂场景（两端实体进、未标的实体不进）、
前缀语义（含 chan:qq2 反例）、weight 排序与 limit、GLOB 存量引导（dry-run 不写库）、
清理后无悬空引用、场景注入面（关系全文+原句+不在索引重复占位）、
agent 侧 sceneKeysFor 优先级（显式声明 > 通道 > 工具、数组形式、nil 安全）。
生产库实测（先 sqlite3 .backup 到 graph.db.bak-20260915-081043 再写）：
把 22 条 QQ 相关关系标进 chan:qq（GLOB *QQ* 19 条 + *qq_* 3 条）。同一批输入前后对比：
- 「在吗」：改前注入 17 个无关实体；改后场景块直接给出「QQ回复禁用Markdown格式
--规定--> 纯文本不用Markdown」等规则正文（零字面重合也能召回）。
- 「QQ回复格式」：改前规则排第 32 被截掉；改后排在场景块首位。
- 「帮我发个语音」：场景规则置顶，词法路的 qq通道语音输入 等仍在其后。
|
2026-09-15 08:13:52 +08:00 |
|
|
|
b37141f3f5
|
fix(memory): doc→graph 补回常用词闸门 + 存量噪音/孤立节点清理
问题：图记忆里堆着「结果(192) / 什么(59) / 哪个(99) / 待命(176) / 报告(174) /
context_archived(43)」这类节点，mention_count 冲到几百、度数只有 1~2——
占着热实体位、挤满召回预算，却不带任何结构。
根因：这层过滤原本存在，后来被换掉没补回。1cb3e87（NLP 三元组提取系统）
把 doc→graph 从「CutExact 滑窗词链」换成依存句法提取器时，CutExact
（去停用词 324 条 + validEntityName + 去重，注释至今还写着「用于 doc→graph
蒸馏」）失去了唯一生产调用点，只剩 cut_test.go 在调它。此后落库闸门只剩
validEntityName——它挡的是「不像名字的字符串」（2–50 字符、含字母），
完全不挡「像名字的常用词」。
改动：
- 新增 internal/memory/noise.go：IsNoiseEntity 收敛判定（停用词 /
context_archived / 模板摘要回声），FilterNoiseTriples 给自动填充路用，
PurgeNoise + PurgeOrphans + cmd/memgc 供存量清理（默认 dry-run）。
判定刻意保守：只拦三类客观噪音，开放类词（报告/对话/处理）不拦——
它们挡不挡是领域决策，见函数注释。
- docToTriples 接上闸门（用户点名的「文档常用词」路）。
对话蒸馏路 extractKeyTriples **不接**：CutExact 当年也只挂 doc→graph，
且 pipeline_test 明确断言「我 --读书--> 杭州」必须抽出（代词主语是该路
既定行为），是否拦属行为决策，已在代码注释里写明并留给使用者定夺。
- cut.go 补全封闭类常用词：咱俩/咱们（我们/你们/他们 早有）、任何/此/本/
其中/以及/那么/这样/那样/一样/还有/还要/只是/老是/全部/所有/有些/一些/
别的/其他/其余/各自/本身/方位词/部分/方面。
「不能/不会」试过又撤回：它们是 embedder tokenize 的实词路径，
加进停用词会让 static_embedder 的领域聚类用例翻转（今天天气句与股票句
的相似度大小关系反了），属真回归，不留。
- graph.go：CleanupOrphanedSentences 拆出 Locked 版供 PurgeNoise 复用。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：IsNoiseEntity 判定表、FilterNoiseTriples 顺序与边界、
PurgeNoise（统计/幂等/dry-run 不写库/不误删仍被媒体块边引用的句子）、
PurgeOrphans（识别/不误判有边实体/幂等）、docToTriples 噪音闸门与
模板锚点不被误杀。
存量清理（生产库 /home/newqqagent/memory/graph.db，先用 sqlite3 .backup 备份
到 graph.db.bak-20260915-073210）：
- 噪音实体 29 个 + 其关系 59 条
- 零关系孤立实体 25 个
- 结果：实体 778→724，关系 639→580；sentences 3 条与 block_edges 3 条原样保留
（媒体块引用不被误删），PRAGMA integrity_check=ok、无悬空关系/块边。
- 运行中的 homed 无需重启：下一个 archive 心跳会 Indexer.Sync 重建实体名向量索引。
|
2026-09-15 07:47:16 +08:00 |
|
|
|
94995eaa64
|
fix(memory): 修图记忆召回的两处能力缺失（关系重复 + 原句不回显）
针对 memory_recall / 自动注入这条图记忆召回链路的实测复核：
- Recall(depth>1) 跨层不去重：每层都用已累积的 entityIDs 查邻接，
上一层刚产出的关系会在下一层被反复查回并再次 append。实测
小明→小红 在 depth=2 出现两次，memory_recall 的 10 条关系预算被
同一句话刷屏、真正的新关系（小红→小刚）被截断。改为按 relation ID
跨层去重（实体本就已去重）。
- memory_recall 从不回显 sentence_text：工具 schema 明写「填了才能日后
从图谱回到原文」、Recall 也已 JOIN 出句子，但输出只给实体名与关系类型，
该字段形同虚设。抽出 formatRecallRelations，对非空原句截断 60 字附在
关系行后；超过 10 条仍截断并提示。
测试：TestRecallWithDepth 增补去重与精确条数断言；
新增 TestFormatRecallRelations_SurfacesSentence / _Truncates。
go build/vet 干净，go test -race ./internal/memory/ ./internal/agent/core/... 全绿。
|
2026-09-15 06:48:36 +08:00 |
|
|
|
6afe361804
|
fix(memory): 记忆层启动接线/并发/落盘一致性整备
按设计方案整顿记忆系统，收敛一批"单测照不出、只在长跑生产里暴露"的缺陷：
- 启动接线：initMemoryStack 残留 `defer distiller.Stop()`，规则蒸馏
10min 心跳启动即死。改为由调用点 cleanup 停机，并补 Stopped() 探针 +
TestInitMemoryStackKeepsDistillerRunning / TestStartKeepsLoopRunningUntilStop。
- L0 相关性上下文：SetDenseSpace 注入稠密空间时回填已有事件的稠密向量，
否则旧事件走稀疏余弦、新事件走稠密余弦，同一次 Prune 里两种尺度混排。
- 文档检索：QueryScored 访问计数从读锁内写移出（-race 竞争），更新后置脏，
优雅关停可落盘、FindColdDocs 冷度判据跨重启不再失真。
- 蒸馏管线：只 flush 未落盘记录（persisted 标记）、蒸馏成功后从 raw 文件
删除对应行、原子写文件，修重启重复蒸馏导致 mention_count 膨胀。
- 图库：全量 Recall 加实体上限（内部整备路径，防大图整表进内存）；
ClearSentenceID 补写锁；Commit/upsertEntity 计数语义注释澄清。
- 索引器：recalled 去重集加 FIFO 上限，防长跑进程自动注入越来越沉默。
- 文档/媒体注释修正；README 记忆层流程对齐跨模态召回。
验证：go build ./...、go vet、go test -race
./internal/memory/... ./internal/agent/core/... ./cmd/homed/... 全绿。
|
2026-09-15 06:32:36 +08:00 |
|
