|
|
e44164f5bd
|
feat(memory): Graph 原生一等记忆块节点与结构边(§13.12)
媒体/文本在 L3 不再是正文标记反解出的代理实体，而是带原生
modality/digest/MIME/size/vector/fingerprint 的 memory_blocks 节点；
contains/depicts/derived_from 等语义边落在 memory_block_edges，
端点必须是真实图节点（block/entity/sentence），不复用 owner 字符串。
本步只建立存储与查询能力，不接入 media_refs，也不改变 L0/L2 路径。
|
2026-09-11 10:08:59 +08:00 |
|
|
|
96c1d7baae
|
fix(memory): 千问文本塔补齐 tokenizer post_processor 与真实 ONNX 回归
验证 Go 端到端路径时发现：HuggingFace 的 tokenizer.json 带 TemplateProcessing
post_processor，规则是 `$A <|endoftext|>`——即每段输入末尾都会追加一个
`<|endoftext|>`(151643)。它正是图内 last-token 池化的锚点：
- 漏掉它：ONNX 仍能运行（不会报错），但池化取到的是模板末尾的 assistant
起始符，而非 post token，整条嵌入向量与上游不一致；
- 截断语义：HuggingFace 在 truncation=true 时先把正文截到 maxLen-1，
再保留末尾 post token（实测 600×"记忆"→ [511 正文][151643]）。
改动：
1. Tokenizer 新增 encodeModelInput(text, maxLen)：Encode 后追加 post token，
并在超长时先截到 maxLen-1；缺 <|endoftext|> 直接报错（防静默错误）。
2. Embedder.VectorizeDense 改用 encodeModelInput。
3. 测试：
- TestEncodeModelInputPostProcessor：短文本+post token；长文本按 512 截断
且尾 token 为 post token（用 600×"记忆"确保真的触发截断分支）。
- embedder_onnx_test.go（onnxruntime 标签）：用 Python onnxruntime 1.28
生成的冻结参考向量验证完整 Go 路径（模板渲染→BPE→ONNX→L2 normalize），
逐维 diff ≤ 2e-5；同时断言模型输入恰好 23 token 且末尾是 post token。
产物不在时跳过（与 tokenizer_test 相同约定）。
- 修正先前测试误用 400×"记忆"：BPE 把"记忆"合并为单 token，400 次只有
400 token 不触发截断；改用 600 次后确实走到 maxLen-1 分支。
其余（ORT 库路径、指纹纳入 .onnx.data）一并随本提交带上。
验证：go test ./internal/memory/qwen 与 -tags onnxruntime 全绿；
FP32 图与 PyTorch 在短/长/等长批次/真实 padding 批次上余弦均 ≥0.99999994。
|
2026-09-11 03:09:01 +08:00 |
|
|
|
8e88ae789f
|
feat(memory): 千问文本塔 ONNX 嵌入器（onnxruntime 标签，含 stub）
与 internal/memory/clip 同模式：`//go:build onnxruntime` 编真实实现，无标签时
走 stub，默认构建不链接 onnxruntime、行为不变。
加载契约（目录由 core.memory.multimodal_space.model_dir 指定）：
TextTower.onnx + 外部权重分片、tokenizer.json、embed_config.json。
图内已含 last-token 池化，输出即 [batch, dim]；L2 归一化在 Go 侧做。
两个刻意的设计选择：
1. **EmbedImageDense 明确报错，不返回零向量**
导出的是文本塔，视觉塔未导出。返回零向量会让「写入了但检索不到」，
把跨模态检索失效变成静默故障；明确报错则调用方（mediaref.go）log 后
跳过写向量，文本路径不受影响。
2. **Fingerprint 只哈希图文件 + 配置 + 外部权重的文件名与大小**
该目录有 6.5GB 权重分片，启动时全读一遍要几十秒、会阻塞 homeagent 启动。
换模型必然改变文件集合或大小，足以识别切换；代价是理论上存在
「大小相同但内容不同」的漏判，对本地单机部署可接受。已写入注释。
模板渲染（renderInstructionInput）放在无构建标签的 tokenizer.go，因此可被
测试覆盖：参考数据里有该模板串的用例，逐 token 对齐验证——模板差一个字符，
池化取到的「最后一个有效 token」位置就变，向量就不同，且不会报错。
验证：6 个测试全绿；go build ./...（stub）与 go build -tags onnxruntime
（真实实现）均通过。
|
2026-09-11 00:16:45 +08:00 |
|
|
|
e985151da9
|
feat(memory): 千问字节级 BPE 分词器 + 与上游逐条对齐的回归测试
为「千问嵌入模型导出 ONNX 并内嵌」的 Go 侧准备。CLIP 那套 tokenizer 不能复用：
CLIP 是「小写化 + 空白规整 + 词表 BPE」，千问是 **GPT-2 式字节级 BPE**
（先按字节映射到安全 unicode，再对映射结果做合并），中文与空白输入的切分
完全不同。
实现中撞到两个与上游对齐的坑，都由测试暴露：
1. **`\s+(?!\S)` 的语义依赖正则回溯**，不是「等价于 `\s+`」。
`\s+` 先贪婪吃完整段空白，发现后面是非空白导致 `(?!\S)` 失败，于是回退
一个字符，**正好留下末尾一个空白**给前面以 ` ?` / `[^…]?` 开头的分支合并。
这直接决定切分点：`" leading"` 会切成 `" "` + `" leading"`，
而不是 `" "` + `"leading"`。RE2 不支持 lookaround，近似改写必然对不上，
所以改成按分支顺序**显式实现**（含 `\s*[\r\n]+` 的回溯语义）。
实测：近似改写时 26 条里错 3 条，全部是空白串用例。
2. **Go 的 `\s` 只有 ASCII，且 regexp 不支持二进制属性 `\p{White_Space}`**
（只支持 script/category，直接写会报 invalid character class range）。
而上游 Rust regex 的 `\s` 正是 White_Space。改用 `unicode.IsSpace` 作为
唯一判据，避免全角空格/NBSP/行分隔符的切分点漂移。
另外特殊 token（`<|im_start|>` 等 24 个 AddedToken）必须**整体优先匹配**并
按长度降序，否则会被 BPE 拆成子 token，模型收到的输入就变了——且不会报任何错。
验证：`testdata/qwen_tokenizer_reference.json` 由 HuggingFace 真实 tokenizer
生成（26 条用例，覆盖中/英/中英混排/数字/各类空白形态/标点/emoji/特殊 token/
长文本/空串/单字符边界），Go 实现逐条精确对齐。字节↔unicode 映射另测双射性
（有碰撞会让不同字节编成同一 token，静默产生错误输入）。
|
2026-09-11 00:11:58 +08:00 |
|
|
|
b393b7072c
|
fix(ctx): prune 的查询向量改用插件 Cleaner 清洗后的有效内容(§13.8)
ContextPolicy=prune 上线时直接把**原始**工具结果传给 RelevanceContext.Prune，
而 Prune 的入参是**相关性查询向量**——它决定保留/归档哪些上下文事件。于是
ANSI 转义、base64、JSON 包装等噪声全被编进查询向量，打分失真，裁掉本该
保留的事件。
而 ToolDef.Cleaner 的契约本就写着「仅在向量化/jieba/蒸馏时调用」，裁剪正是
在向量化——所以这是**回归契约**，不是新增能力。此前只在构建事件向量
（context.go 的 toolOutputClean）时用了 Cleaner，裁剪查询这一处漏了。
回退规则（Cleaner 是计算层优化，不能因它失效而丢内容）：
- 未注册 Cleaner → 原文
- RPC 失败 → 原文（proc 侧 cleanerProxy 已有此保证）
- 返回空串 → 原文（空串会让查询向量退化成零向量，所有事件相关性相同，
等于随机裁剪）
验证：TestToolOutputForQueryAppliesCleaner（Cleaner 被调用恰好一次且用其
结果；无 Cleaner / nil stageHost 回退原文）、
TestToolOutputForQueryEmptyCleanFallsBack。
顺带把 §13.13 第 5 条（反向大结果）按核实结论结掉为「不做」：核实发现根本
不存在 llm.chat（llm.* 只映射切换 LLM 源），唯一可能返回大结果的 doc.query
没有任何外部插件使用且已被 CapDocMemory 能力门限制。留成永久 TODO 只会误导。
|
2026-09-10 23:59:12 +08:00 |
|
|
|
50ba4a64cb
|
feat(shm): 文档/知识正文入共享内存 + 协议版本 bump 到 2(§13.13)
## 数据面补齐
- doc.insert / doc.insertWithMedia：新增 doc_ref / attachments_ref，
模板序列化后 putValueInArena
- knowledge.add：新增 content_ref（内容是 JSON 字符串，读出后再解一层）
- 抽出通用 resolveJSONRef（resolveBlocks 也改用它），三处共用一套
“共享优先、内联回退”逻辑
## 协议版本 bump：让错配显式失败，而不是静默坏
这是本轮更重要的部分。§13.6/§13.13 改了内核→插件 payload 的承载方式，
两种错配都不会报错、只会静默失效：
- v1 插件只读内联 args（tool/cleaner/output）→ 遇到 v2 内核拿到空参数
- v2 插件发 blocks_ref → v1 内核反序列化时静默忽略（旧内核
io.setToolBlocks 还是桩实现）
现场表现为“输出变空 / 图注入没反应”，极难定位。所以把 ProtocolVersion
与模板 procProtocolVersion 一起 bump 到 2：双方都是等值校验，v1 插件遇上
v2 内核会在建链时明确报“协议版本不匹配…请用配套 plugindev 重编”。
测试里把“错误必须带出重编指令”也断言上了——生产上碰到它的现场就是
“只更新了内核没重编插件”，光报“不匹配”定位不到行动。
testdata 8 个插件的 protocol 同步更新（badprotoplugin 仍用 999 验证拒绝）。
工具链已重建并安装（协议 2，内嵌 blocks_ref/doc_ref/content_ref），
回滚副本 plugindev.bak-20260910-232544。
验证：-race 全绿。新增 KnowledgeAddViaArena(12000B 正文)、
KnowledgeAddInline、DocInsertViaArena、SetToolBlocks 三例 +
真实模板 e2e + 协议不匹配断言强化。
§13.13 第 5 条（反向大结果）范围更大——需把内核→插件的应答路径整体改成
“大结果写段 + 返回 ref”，涉及 callCore 的返回处理与 doc.query/llm.chat 等
所有读大结果的 method。已在 plan.md 标注未做，不冒充完成。
|
2026-09-10 23:26:16 +08:00 |
|
|
|
15d912ef34
|
feat(shm): 媒体块入共享内存 + 实现 setToolBlocks 桩(§13.13)
两个问题叠在一起，先发现的是第二个：
1. **io.setToolBlocks 在内核侧是桩实现**——直接返回“多模态注入待共享段
二进制通道落地”。也就是**子进程插件调 SetToolBlocks 必然失败**（模板
只 log 一行），只有内置插件（multimodal）能用。之前还有测试把这个错误
当作预期行为断言着。
2. 媒体块（injectMedia 系列 + setToolBlocks）把 blocks 内联在 RPC JSON 里，
而本地生成的图/音频是 base64 data URL，一张图可达数 MB。
顺带修掉一条与设计相悖的旧注释：injectMediaParams 写着“data URL 已是
base64 文本、再套一层二进制不会更小，所以走 JSON”。那只算了体积，漏了
两件更重要的事——内联时整份 base64 要在 RPC 报文里再编码/再拷贝一遍；
以及内容本体不在共享段里，插件回调就无法就地改写，只能各持一份拷贝。
共享内存的意义是后者。
实现：
- injectMediaParams 加 BlocksRef；新增 resolveBlocks（共享优先、内联回退）
- 真正实现 MethodIOSetToolBlocks（空块明确报错，不静默成功）
- CoreSDK 接口加 SetToolBlocks，procCore 转调 internal/sdk
- 模板：SetToolBlocks / injectMedia 三兄弟经 putValueInArena 传 blocks_ref；
同步调用用 mediaArgsOwned 拿释放函数，**不能在应答返回前释放槽**，
否则内核读到已释放内存
验证（-race 全绿）：
- TestCoreHandler_SetToolBlocksViaArena / Inline / EmptyRejected
- TestE2E_RealTemplateSetToolBlocksViaArena：真实 SDK 模板编译的插件，
9000 字节 base64 图经 blocks_ref 完整送达
工具链已同步：/usr/local/bin/plugindev 重建为新协议（内嵌 blocks_ref），
回滚副本 plugindev.bak-20260910-224255。注意内核与全部插件必须同批替换
——只换一边会静默坏（新内核+旧插件=输出 payload 变空；新插件+旧内核=
媒体注入静默失效），已记入长期记忆。
|
2026-09-10 22:45:19 +08:00 |
|
|
|
e2672c56d6
|
feat(shm): 输出通道 payload 走共享内存调用帧(§13.6)
§13.3 给 ToolInvokeParams 加了调用帧，但 OutputInvokeParams 没跟上——
payload 仍内联在 RPC JSON 里。核实后确认这个 lane 只做了半边：注入侧
（injectParams.TextRef + resolveText）可用，输出侧从内核到插件仍是内联。
改法照搬工具调用的 funccall 帧模型：
- OutputInvokeParams 加 Frame/ArgsLen（Args 仅留给直连 RPC 的测试）
- invokeOutput 序列化参数 → Alloc 帧 → 写帧 → 只传偏移描述符 → defer Free
- 帧尾不预留结果区：output 应答很小（"ok"/status map），走 RPC 应答字段即可。
但 OutputInvokeResult 支持插件把大结果写回帧（ResultRef），并识别
sharedRefFlagExpand 单独归还扩容块——与 invokeTool 一致。
- 模板 output.invoke 用 frameInput 从帧读参数，无帧才回退内联 Args
为什么要做：output payload 在真机上可能含图片/文件描述等大字段，内联会
撑爆 stdin/stdout 管道。
验证：
- TestPlugin_OutputPayloadViaArena：9000 字节 payload 经帧完整送达（插件回报
实收长度，不是只看返回值）+ 调用后 arena 归零
- TestE2E_RealTemplateOutputPayloadViaFrame：同上，但用真实 SDK 模板编译的
插件——生产插件走的就是模板，模板不读帧则此改动等于没做
- TestPlugin_OutputChannelReportsRealFailure 仍绿：同步等真实结果、失败必须
上报（§9.4）的语义未被破坏
- go test -race ./internal/plugin/... 全绿
plan.md §13.5 也如实标注：注入 side 内核→插件方向仍未接线（procCore.InjectText
直接传字符串，从不 Alloc/Put 构造 TextRef），不是仅打勾的项。
|
2026-09-10 21:28:56 +08:00 |
|
|
|
b71a88a471
|
chore(shm): 补齐 §13 验证项，删除统一区域遗留死代码
三件事，都是 plan.md §13 里未打勾的项：
1. §13.3「Bench: ToolInvoke 延迟对比」补测（bench_test.go）
改造后原有的 BenchmarkToolInvoke 仍走 legacy 内联 Args，已不代表生产
路径。拆成 inline / frame 两个子基准并各测两个尺寸（-count=3 取中位）：
payload inline（RPC 报文） frame（共享内存帧） 差
16 B 26.4 µs/op 48.0 µs/op +21.6 µs
32 KiB 695.6 µs/op 391.7 µs/op −303.9 µs
取舍随尺寸翻转：小 payload 多付 ~22µs 帧固定开销，大 payload 省掉整份
JSON 编解码与管道拷贝、快 44%。因为线上工具结果动辄几十 KB 且 22µs
相对 LLM 往返 2-8 秒可忽略，所以统一走帧而不按大小分叉（§13.3 第 4 条）
是对的。
2. 删除 §13.1 遗留死代码（evtring.go）
allocEvtRing 自统一共享区域之后从未被调用——旧版它单独建 memfd + eventfd，
现在只有一个 memfd，事件环只是区内的一个 segment（NewEvtRing 操作区内
切片）。留着会让人误以为事件环还有独立段。
3. 修正误导性注释（plugin.go）
仍写着旧 3-fd 布局「3=StageContext, 4=事件环, 5=通知」，与实现
（procExtraFilesForShm 只返回 memfd+evtfd）和 shmpass_unix.go 的权威
注释互相矛盾。
plan.md：§13.1/13.3/13.4/13.8 的验证项按实测打勾，并注明证据（提交号 /
测试名 / 实测数字），不留无依据的勾。
|
2026-09-10 21:18:16 +08:00 |
|
|
|
e218d0f100
|
fix(agent): 工具循环占位不再驱动重复发送，输出回执/子任务结果幂等
生产现象：单轮内 output_send__qq 被调用 34 次、持续 514 秒，直到 QQ 插件
自己的循环保险拒绝发送才停下（problem.md）。根因是多环节叠加，核心侧修四处：
1. 工具轮补位文案（process.go）
通用占位「请根据以上工具结果继续。」对纯输出通道调用是错的：异步通道
（qq/wechat）的回复只能经 output_send__* 交付，所以模型「已完成回复」的
表达形式就是一个工具调用，紧随其后的「请继续」会被读成「还要再做一步」，
而能做的「一步」恰好还是再发一条消息。
改为按上一批工具的性质选文案：全部是 output_send__* 时补
「若你的回复已完成，直接返回纯文本即可结束本轮，无需再调用任何工具。」
同时每轮先移除旧占位再补一条，避免占位在 prompt 前缀里线性累积。
（该占位是 zen 网关「最后一条必须是 user」的传输层附加物，HEAD 版本是
无条件内联追加、从不移除。）
2. 输出成功回执（output.go）
「已通过 [qq] 通道发送: map[status:sent]」这类富回执会被读成「这步成功，
继续下一步」。成功改为只回极简标记。
3. proc 桥标量透传（internal/plugin/proc/plugin.go）
插件返回 "ok" 时不再伪造 {status:sent} 覆盖插件真实返回值，否则只改
output.go 不生效。
4. 子任务结果幂等（spawn.go）
child_result 原先读到即删，而完成通知长期留在持久上下文里
（formatMergedTimeline 每轮重新注入），第二次查询必然得到
「不存在或已过期」这个永久失败信号，模型据此认为任务未完成而反复重试。
改为保留结果 + delivered 标记，重复查询返回明确提示；结果按上限有界淘汰。
顺带：agent.go 去掉文档层显式向量器注入（TF-IDF 已内置为 fallback），
cmd/homed/main.go 同步 document.NewStore 的 tokenizer 参数。
测试：internal/agent/core/tooloop_test.go（5 例）、spawn_test.go（3 例）。
|
2026-09-10 20:36:39 +08:00 |
|
|
|
b096e8ba2c
|
refactor(shm): 变长块分配器 + 工具调用 funccall 调用帧(§13.2/§13.3)
按架构约束推进两步：
1) 分配器收回内核后，定长槽失去了唯一存在理由
（定长槽只是为了绕开"跨进程无法安全变长分配"），
于是 arena 换成**变长块分配器**：first-fit + 邻块合并，
块头 16B（size/state/owner/prevSize）。内核可以按需标定每块大小，
payload 不再受固定槽容量限制（旧上限 16KB）。
- Alloc/Put/Read/Free/ReclaimOwner 全在内核进程内，一把 sync.Mutex
- Free 走块链校验 offset 是已分配块的数据起点 + owner 匹配，
伪造引用不能改动分配器状态
- Read 允许块内偏移（调用帧的结果区就在帧块中间），但不许跨块边界
- arena 4MB，底层 memfd 惰性分配：未触碰的页不占物理内存
2) 工具调用 payload **始终**走共享内存，取消按大小切内联的分支。
按 funccall 模型，内核（caller）标定调用帧交给插件（callee）：
[0, ArgsLen) 参数 JSON
[ArgsLen, Frame.Length) 结果区（内核预留的预算）
结果超出预算时插件才 `arena.alloc` 扩容块，引用上打
sharedRefFlagExpand 让内核单独归还。Cleaner 复用同一帧模型。
ToolInvokeParams.Args / ToolInvokeResult.Result 仅剩给直连 RPC 的
测试（process/bench 不建 Host）；生产路径永远走帧。
测试：
- TestArena_*（分配/归属/回收/并发唯一/耗尽/超限/伪造 offset/
相邻合并/对齐/布局校验）
- TestPlugin_ToolInvokeArgsResultViaArena：大**小** payload 都经帧往返，
结果一致且 arena 归零（"小 payload 同样走调用帧"是本轮行为变更）
- TestPlugin_ArenaAllocFreeAcrossProcess、TestE2E_* 保持通过
- 顺手修 process_test.go 一处预存 doc-comment 分段
|
2026-09-10 18:54:36 +08:00 |
|
|
|
f6f92a8a6e
|
fix(plugins): 修复两处预存缺陷（agentcli 临界区 / localuse 脚本转义）
agentcli cleanupLoop：
持锁期间为每个过期终端 go func 调 term.Close()（内部会 Kill 进程并等
<-t.done），临界区被拉长且与 TerminalSession 退出路径交错。改为持锁
只做筛选与摘除，锁外再逐个关闭。
localuse 脚本转义（两处真实 bug）：
1. AppleScript 注入：handleScreensue 只把 `"` 转义为 `\"`，未转义 `\`。
内容结尾的反斜杠会吃掉闭合引号，使后续内容逃逸出字符串字面量。
改为 escapeAppleScriptString：**先转义反斜杠再转义双引号**（顺序
不可颠倒，否则刚插入的反斜杠会被二次转义）。
2. PowerShell 路径被错误加倍反斜杠：handleScreensee 把 Windows 临时
路径的 `\` 写成 `\\`。但 PowerShell 单引号串里反斜杠是普通字符
（转义符是反引号），加倍会让截图保存到错误路径。
新增 psSingleQuote 统一处理，并把 4 处零散的 `ReplaceAll(x,"'","''")`
收敛到该 helper。
|
2026-09-10 17:56:57 +08:00 |
|
|
|
c03de9878d
|
fix(proc): EvtConsumer 生命周期——消除 host.Close 后的 SIGSEGV
预存缺陷（非本次重构引入，但会稳定复现崩溃）：
Stop() 只 close 了 stop channel，而 Run() 阻塞在 evtfd.Read 里，
根本没有机会检查 stop。调用方在 Stop 后释放 ringData（host.Close
会 munmap 整个区域），Run 一旦从 Read 恢复就会读已解除映射的内存：
**SIGSEGV，recover 捕不到**。实测 TestEventRing_OverflowStillDelivers
约 50% 概率触发。
两次尝试与结论：
1. os.File.SetReadDeadline 无效——eventfd/pipe 经 os.NewFile 包装后
**不会**注册进 Go netpoller（os.NewFile 对非 open 得到的 fd 一律按
非 pollable 处理），Read 是阻塞 syscall，SetReadDeadline 返回错误。
2. 改为 poll(2) 显式加超时（evtpoll_unix.go），消费循环每 100ms 回到
stop 检查。
新增 API 契约：
- Stop() 非阻塞，仅请求退出
- Wait() 阻塞至 Run 退出；**返回后才能释放 ringData**
- drainEvents 每条事件后检查 stop，避免慢 handler 拖延退出
其他：
- evtring_test.go 三个用例改为 defer Wait() → defer Stop()（LIFO 保证
Wait 先于 host.Close 完成）
- 溢出用例的 handler 改为非阻塞投递：写入了 8292 条事件而 channel 只
消费 1 条，阻塞投递会让 drainEvents 卡在 handler 里，Stop 无法退出
|
2026-09-10 17:56:54 +08:00 |
|
|
|
ca584bda3f
|
refactor(shm): 内核独占共享槽池，插件经 RPC 申请/归还(§13.2/§13.3)
推翻前两版跨进程分配器设计，根因是"共享内存里放了只被单一进程
更新的可变游标"：
- v1 在 SuperBlock 放 arenaUsed 游标，内核 CAS bump。但插件模板里
arenaUsed 是**进程本地变量**，两进程各自 bump 必写同一段内存；
arenaReset 还会重置共享游标覆盖对方数据。
- v2 把位图 CAS 下沉到插件模板，正确但把分配器实现泄漏进插件运行时，
且插件必须与内核保持位图布局同步。
新设计（用户明确的架构约束）：内核全权管理共享内存，插件通过
syscall 风格 RPC 申请/归还，内核返回偏移与大小。分配器只存在于内核
进程内，一把 sync.Mutex 即可。共享内存是内部实现，不对插件开发者
暴露——SDK 公开 API 仍是普通字符串/Map。
主要改动：
- arena.go: 定长槽 + 位图，Alloc/Put/Read/Free/ReclaimOwner，内核独占；
槽头记录 owner，Free 校验归属；payload 超槽容量退回内联 RPC
- protocol.go: 新增 arena.alloc / arena.free（CapCore）
- capability.go: 登记两个新 method（checkAllMethodsClassified 要求）
- corehandler.go: 实现 arena.alloc/free；Cleaner 改为内核预分配
请求槽 + 响应槽（插件完全不分配）
- plugin.go: Start 领 ownerID；handleExit 调 ReclaimOwner 回收残留槽
- unified.go: 移除坏的 bump 分配器；arena 基址 8 字节对齐
- 删除 toollane.go: ring 状态机是死代码（从未接线），且把 RPC 已有的
请求 ID 关联/错误传递/ctx 取消重新实现了一遍。控制面保留 RPC，
只把 payload 搬进共享槽。
- 测试: TestArena_*（归属/回收/并发唯一/耗尽/超限/非法引用/布局）+
TestPlugin_ArenaAllocFreeAcrossProcess（真进程申请→写入→随业务
RPC 回传→归还→内核读回一致且池归零）
|
2026-09-10 17:56:50 +08:00 |
|
|
|
cf3c99233b
|
fix(shm): 审核修复——arena 并发安全 + ToolCall ring 抢占 + arenaRead 校验
§13.2: arenaAlloc 改 CAS bump（修复并发覆盖）；arenaRead 增加 generation + arena 边界校验
§13.3: Reserve 从 Store+Load 改 CAS-free→Reserved 状态机抢占帧（修复并发分配重复）；
增加 RESERVED 中间态；SetReading/SetReady 改 CAS 返回 bool；ReleaseFrame 清零跳过 state
§13.5/13.6: 注入方法接入 resolveText（从 arena 读 SharedRef）；cleanerProxy 加 arenaMu 串行化+每次重置
§13.8: ContextPolicy prune topK 改为 maxContextSize-1（不再硬编码 20）
tool.register 校验 context_policy 只允许 none/prune
|
2026-09-10 17:03:32 +08:00 |
|
|
|
2bc813be13
|
feat(shm): InputChannel/OutputChannel lane 基础设施(§13.5/§13.6)
- injectParams 加 TextRef SharedRef（兼容旧 Text 字段）
- resolveText 辅助函数：优先 SharedRef，否则内联 Text
- 核心注入方法待迁移至 resolveText
|
2026-09-10 16:14:17 +08:00 |
|
|
|
9cfdfc9de8
|
feat(shm): arena + ContextPolicy(§13.2/§13.8)
- unified.go: arena 分配器 (alloc/write/read/reset)
- NewHost: 分配空间含 arena
- SDK ToolDef 加 ContextPolicy string
- StageAfterToolcall 后检查 prune 策略触发 RelevanceContext.Prune
|
2026-09-10 15:49:47 +08:00 |
|
|
|
772a494223
|
feat(ctx): ContextPolicy tool 上下文策略(§13.8)
- SDK ToolDef 加 ContextPolicy string（默认 none / 可设 prune）
- StageAfterToolcall 后检查工具 ContextPolicy=prune → RelevanceContext.Prune
- 所有现有测试通过
|
2026-09-10 15:41:23 +08:00 |
|
|
|
5608abdf5a
|
feat(shm): Cleaner 迁移到 SharedRef(§13.4)
- CleanerInvokeParams/Result 的 Text 改为 TextRef SharedRef
- cleanerProxy: 写 text 到 arena，传 SharedRef，读结果 SharedRef
- 插件侧 cleaner.invoke: 从 SharedRef 读 input，清洗后写回 arena 返回 TextRef
- NewHost(): 分配空间含 arena（256KB）
|
2026-09-10 15:30:00 +08:00 |
|
|
|
cf098a1d4f
|
feat(shm): arena allocator for unified region (§13.2)
- SuperBlock 新增 arenaOff/arenaCap/arenaUsed 字段
- arenaAlloc: append-only bump 分配，offset 0 保留给空语义
- arenaWrite: 写入并返回 SharedRef（含 generation）
- arenaRead: 按 SharedRef 切片读取
- arenaReset: 压实后重置游标
|
2026-09-10 14:33:44 +08:00 |
|
|
|
a8e3633174
|
feat(shm): ToolCall ring buffer(§13.3) — 栈帧模型 ring，push/pop 帧状态机
- ToolCallRing: 定长帧 ring buffer (64 frames × 112B)，状态机 FREE→CALLING→READING→READY→FREE
- Reserve: 环形扫描找 FREE 帧，全忙返回 ErrToolCallRingFull 背压
- SharedRef: pack/unpack 辅助函数
- unified.go: arena 分配器（arenaAlloc/arenaWrite/arenaRead）
- 5 个单测覆盖 init/reserve/背压/find/reuse
|
2026-09-10 12:33:58 +08:00 |
|
|
|
ad016e4410
|
feat(shm): 统一共享内存区域(§13.1) — 单 memfd 容纳 SuperBlock+StageContext+EvtRing
- unified.go: SuperBlock 布局 + SharedRef 类型
- NewHost(): 两段 memfd 合并为单一 memfd，fd 3 = 统一区域，fd 4 = eventfd
- 子进程侧: testdata 插件从 SuperBlock 解析 ctxOff/evtOff
- streaming 测试: EvtConsumer 协程在 host.Close 前 Stop+Wait 防 SIGSEGV
|
2026-09-10 11:42:22 +08:00 |
|
|
|
7a328679da
|
feat(proc): Cleaner 跨进程修复(tool/input/output) + 共享内存安全模式 + plan §13
- Cleaner 协议统一为 cleaner.invoke(scope,name,text)，覆盖工具/输入/输出三类
- 新增 ShmSecurityMode (safe/debug/full)，Linux 审计探针，Windows crypto nonce
- plan.md 追加 §13 步骤分组
|
2026-09-10 10:21:50 +08:00 |
|
|
|
580d5f5501
|
feat(doc): dense vector index for unified text+media retrieval
文档层引入稠密向量索引，与媒体检索共享同一多模态空间：
- Doc 加 DenseVec 字段（json:-，运行时计算）
- Consume/QueryScored 优先使用 denseSearchScored（brute-force cosine），
未配置时退化到 TF-IDF 倒排检索
- buildDenseIndex 在 Agent 启动时为全部文档一次性计算稠密向量
- L0 RelevanceContext 支持 denseSpace（Prune 使用稠密余弦），
退化到 fastText 稀疏余弦
vector 包新增 DenseCosine（[]float64 brute-force cosine）。
验证：492 篇文档 brute-force ~300ms，全部测试通过。
|
2026-09-09 18:56:44 +08:00 |
|
|
|
6c2039f5c9
|
feat(vector): pluggable multimodal vector space
核心暴露 MultimodalEmbedder 接口，两条路径共享同一套 L0/L2/L3
向量缓存、media.Store 坐标、QueryMemoryMediaScored 检索：
- onnx：内嵌 ONNX 模型（CLIP 等），通过 build tag 编译
- http：外部向量 API 服务（Jina v5 / OpenAI / 自建）
跨模态融合权重改为 CrossModalFusionConfig 可配置结构体，
移除所有模型特定硬编码（CLIP/Jina），版本切换只需改配置。
模型切换自动迁移：
- StaleVecDigestsAll 支持全模态（image+audio+video）
- 启动时并发重算（ONNX 4 workers / API 8 workers）
- 修复 SQL 运算符优先级导致 kind 过滤失效的 bug
实测对比（492 篇生产文档 + 3 张真实图片）：
- TF-IDF：MRR 0.457（精确匹配快，语义差）
- fastText：MRR 0.530（语义中等，延迟 8ms）
- Jina v5-omni：MRR 0.900（全面领先，延迟 40ms）
- 中文文本→图片：Jina MRR 0.833 vs CLIP 0.611
See docs/embedding-comparison.md for full benchmark.
|
2026-09-09 17:38:34 +08:00 |
|
|
|
6f8056d236
|
refactor(clip): CLIP 收敛为稠密 MultimodalEmbedder，不污染稀疏 Vectorizer/TF-IDF 语义
文本相似度检索是层次化系统：TF-IDF 高频削弱加权（idf<0.1 丢弃）+
倒排剪枝（只召回共享特征者）+ cosine。CLIP 512 维稠密向量若以
map[string]float64 稀疏形式实现 vector.Vectorizer 并塞进 vector.Store，
会让 512 维全部成为倒排 key → 候选集≈全库、剪枝失效，且绕过 TF-IDF
高频削弱，与既有文本检索语义错配。
收敛：
- vector.MultimodalEmbedder 改为独立稠密接口（VectorizeDense/
EmbedImageDense/Fingerprint/Dim/Loaded/Close），不再继承稀疏 Vectorizer
- clip.Embedder 删除稀疏垫片 Vectorize/EmbedImage/denseToVector，
只产出稠密向量；文档/知识/上下文层继续用 TF-IDF/fastText 稀疏路径
- 分层明确：文本→文本走 TF-IDF/fastText；文本↔图像、图像↔图像走
CLIP 稠密 QueryMedia（媒体层独立稠密余弦，原样保留）
|
2026-09-09 10:26:10 +08:00 |
|
|
|
98365f3a55
|
feat(clip): 多模态向量器（CLIP ONNX）——文本/图像 512 维共享空间 + 媒体向量写入与重算
- internal/memory/clip：CLIP ONNX 向量器（onnxruntime 构建标签控制，默认构建不链接 ONNX）
- clip.New(modelDir) 加载 text.onnx/vision.onnx（输出 text_embed/image_embed [batch,512]）
- 实现 vector.Vectorizer + vector.MultimodalEmbedder（Vectorize/EmbedImage + Dense 变体）
- 词级 BPE tokenizer：merges 合并后词末片段带 </w> 查 vocab，与官方 encode 逐 id 对齐
- EmbedImage：解码→resize 224→NCHW→normalize→vision session
- Fingerprint（text+vision 文件 sha256）供模型切换检测
- stub 版（无 onnxruntime 标签）保持默认构建行为不变
- vector/store.go：新增 MultimodalEmbedder 接口
- media.Store：新增 StaleVecDigests(currentModel)——查 vec_model 不匹配/缺失的图片
- agent core：AgentConfig.ClipEmbedder + Agent.clipEmb 接线；
describePendingMedia 描述成功后 EmbedImageDense→SetVec；
新增 reembedStaleMedia 启动补算历史无向量图片
- config：core.memory.media.clip_model_dir（未配置退化为现有 fastText/TF-IDF 行为）
- cmd/homed：读 clip_model_dir 加载 CLIP，失败仅记日志不阻塞启动
测试：TestSmokeLoadAndEncode（文本语义 cat>dog 0.914>physics 0.740）、
TestCrossModalAlignment（red-image vs red-text 0.063>blue -0.009，与 Python 一致）、
TestTokEnd（与官方 encode 逐 id 对齐）、TestStaleVecDigests，含 -race 全绿
|
2026-09-09 10:23:31 +08:00 |
|
|
|
8c9d96e065
|
feat(media): media.Store 加向量存储与跨模态检索
media.Item 新增 Vec []float64 和 VecModel 字段，视觉嵌入向量以 JSON
TEXT 存库（为什么不存 BLOB：Go 的 json.Marshal 对 []float64 是自然的，
而 SQLite BLOB 是 []byte 多一层序列化；单条最多 23KB，TEXT 够用）。
initSchema 加 ALTER TABLE 迁移 vec/vec_model 两列（幂等）。scanItem
扩展读回。新增 SetVec 和 QueryMedia 方法。
QueryMedia 对所有已嵌入媒体做余弦相似度检索，维度不一致的项自动跳过
——这是跨模态检索的核心：查询可以是图片也可以是文本，被查的媒体库
里每个 item 也有视觉向量，两者在同一空间比对，谁的相似度更高就召回谁。
配套 5 个单测覆盖：基本相似度排序、无向量项被跳过、维度不匹配过滤、
空查询安全、向量持久化正确性。
|
2026-09-07 22:31:39 +08:00 |
|
|
|
e9856c8f65
|
feat(media): media.Item 加视觉嵌入字段，Store 加 QueryMedia 跨模态检索
路线 3（完整跨模态检索）的媒体层基础：
- Item 新增 Vec []float64（视觉嵌入向量，JSON 序列化存库）和 VecModel
（模型标识，用于模型切换后触发重算）
- initSchema 加 ALTER TABLE 迁移 vec/vec_model 两列（幂等，列已存在可忽略）
- scanItem 扩展读回 vec/vec_model
- SetVec(digest, vec, model) 写入向量
- QueryMedia(queryVec, model, topK)：对所有已嵌入媒体做余弦相似度检索，
维度不一致的项自动跳过（防不同模型空间的向量被混算）
混合检索的设计意图：查询可以是图片也可以是文本（经向量化后调用 QueryMedia），
被查的媒体库里每个 item 也有视觉向量。两者在同一空间比对，谁相似度更高召回谁。
不再区分「图片查询」还是「文本查询」——向量空间的相似度自动决定。
|
2026-09-07 17:11:10 +08:00 |
|
|
|
0af38a29c6
|
feat(vector): Vectorizer 接口加 EmbedImage，支持多模态嵌入扩展
Vectorizer 新增可选的 EmbedImage(img []byte, mime string) (Vector, error)：
支持视觉嵌入的实现者（如 CLIP/MobileCLIP）覆写此方法；不支持的
（StaticEmbedder、TFIDFVectorizer）返回 ErrNotSupported 调用方按文本降级。
这是路线 3（完整跨模态检索）的接口基础：后续在 media.Store 里，
Describe 时同时算视觉向量并存库，QueryMedia 做跨模态混合检索。
|
2026-09-07 17:00:29 +08:00 |
|
|
|
e4be9667ec
|
chore(meta): main 的版本路牌推到 1.2.0
按 docs/git-branching.md §2.1，main 的 meta.Version 始终是**下一个未发布中版本**。
1.1.x 线正在发布中（release/v1.1.x 承载 v1.1.0 / v1.1.1），所以 main 指向 1.2.0。
它标记「main 正在积攒 1.2 的东西」，不表示 1.2.0 已经存在——1.2.0 没有任何 tag。
已发布的版本号一律看对应的 release/vX.Y.x 分支与 tag。
两仓同步：SDK 仓 main 也是 1.2.0（SDK 版本跟随核心中版本，见 §七.1），
而 release/v1.1.x 上 SDK 定版 1.1.0。
**此 commit 不 cherry-pick 到发布分支**（§五：版本号 bump 不跨分支搬）。
|
2026-09-06 09:54:55 +08:00 |
|
|
|
687e5655bc
|
feat(sdk): 多模态贯通插件边界——公开接口、内核桥接与统一输入主干
记忆系统在 1.1.0 支持了二进制多媒体节点，但那条链路只对**内核自己**开放：
用户在 qq 发图能落进 CAS、能被记忆引用，而插件调 Commit / DocMemory().Insert
交进来的媒体一律无处安放。原因是三层都断着，且**每一层都不报错**。
## 一、公开 SDK：补上媒体的表达能力（全部新增，无签名变更）
- `Triple` += `SentenceText`、`MediaDigests`
- `Doc` += `MediaDigests`、`Attachments`；新增 `MediaAttachment`
- `TextEvent` += `Attachments`
- `DocMemoryAPI` += `InsertWithMedia`
- `IOInjector` += `InjectInputMedia` / `InjectInputMediaSync` / `InjectInterruptMedia`
- `PluginSDK` 补上一直缺失的 `SetToolBlocks` 包装（接口里有、便捷方法里没有）
`MediaAttachment` 一个类型服务两个方向：给 `Data`+`MIME` 是新内容（CAS 按字节
去重），只给 `Digest` 是引用已有内容。读路径**只回元数据不回字节**——一次检索
可能命中几十份媒体，全塞回去会把跨进程消息撑爆。
媒体注入不能搭 `SetToolBlocks` 的车：那个方法只在工具处理函数内部可用，且媒体
要等下一条 tool message 才到模型手上。插件主动发起一轮带媒体的对话、以及中断
注入，需要自己的签名，且媒体在**本轮**就送到模型。
## 二、内核桥接层：原先在静默裁字段
`internal/sdk/memory_impl.go` 此前只搬自己认识的几个字段，其余丢弃且返回 nil：
- 图记忆丢 `Confidence`/`SubjectType`/`ObjectType`/`SentenceText`，又走 `Commit`
而非 `CommitWithMedia`（不回 sentenceIDs）→ 媒体绑定链 `SentenceText → sentences
→ sentence_id → media_refs` 一步都走不通，插件即便按格式写好标记也永远挂不上；
- 知识库 `Query` 只回 ID/Title/Content，`Insert` 只写这三个；`Remove` 不解引用，
于是那些媒体永久处于「被引用」状态，GC 收不掉、磁盘只增不减
（内核的归档路径 `releaseDocMedia` 做了这一步，插件路径漏了同一步）。
规则改为：**内部结构有的字段一律透传**。标记格式处理作为包级私有辅助留在桥接
层自己手里，但必须与内核 `mediaSummaryForEvent` 字节兼容——两边要能互读对方
写下的标记。
标记插入必须在 `ds.Insert` **之前**（向量索引取 `Summary + " " + Content`，
之后补的标记检索不到），引用绑定必须在**之后**（owner_id 是 Insert 生成的 ID）。
## 三、跨进程链路：不接线就是全体外部插件编译失败
`go test` 直接把这一层拍出来了——`procIO does not implement sdk.IOInjector`。
公开接口加方法后，生成模板不跟上，**每个外部插件都编不过**，是硬失败不是软降级。
六处接线：`protocol.go` 四个 method 常量、`capability.go` 能力归属、
`corehandler.go` 四个分派分支、`proc_core.go` 委托、`proc_main.go.tmpl` 模板侧
实现、以及三个测试替身。
## 四、统一输入主干：把模态从「函数选择」降级为「字段」
`processTextInput` / `processMediaInput` 合并为 `processInput`。这个分叉是历史
产物而非设计：`processTextInput` 本来就处理媒体（`bindEventMedia` +
`mediaSummaryForEvent`，与媒体路径尾部完全相同），`process()` 只看
`stageCtx.Extra["media_blocks"]`、根本不认识 `evt.Type`。模态是输入的**属性**，
不是输入的**种类**。
媒体路径由此获得它一直缺的六项：去重、`no_memory`、通道 `Cleaner`、中断语义、
`_consolidation_` 路由、正确的 `EventRawInput`。
最后一项是个真 bug：媒体路径发布 `"content": evt.Payload`（一个 map），而
`webui/handler.go` 断言 `.(string)` → 断言失败、`content == ""`、提前返回。
**用户发的图从来没出现在 WebUI 聊天记录里。**
`media_blocks` 同时接受 `[]agentAPI.ContentBlock` 与 `[]pubsdk.ContentBlock`：
字段一致但 Go 不自动转换，只认一种的后果是另一种被静默丢弃。
## 五、模型可调用的三个工具
`memory_commit` 的 `sentence_text` **从未暴露给模型**，而它是绑定链上的必经环节；
连同 `media_digests` 一起补进 JSON schema 与工具文档。`doc_commit` 加
`media_digests`。`doc_query` 把关联媒体单独一行附在结果末尾（正文按 2000 字截断，
标记通常就在尾部）。
标记由**内核**生成而非插件/模型拼装：要求调用方知道格式，等于让一个拼写错误
静默切断引用绑定，而全链路无人报错。
## 六、WebUI 上传走真实媒体链路
图片/音频读回字节拼 data URL 注入 `media_blocks`（8MB 上限，超限退回按路径处理）。
此前只注入一句「文件已保存到 <路径>」，指望模型自己调 `files_read`——但那返回
文本，图片字节对模型永远不可见。附件类型识别扩展到 audio 并在缺 Content-Type
时按扩展名兜底（判错不只是卡片样式问题，图片被当普通文件就进不了视觉链路）。
## 测试
- `internal/sdk/memory_impl_test.go`（12 例，此前该包**没有任何测试文件**）
- `internal/agent/core/inputunify_test.go`（统一主干 + 双静态类型 + 三工具媒体）
- `third_party/homeagent-sdk/sdk/stress_test.go`（13 例并发压测）
压测抓到两处**真**竞态（不是理论风险）：`PluginSDK` 的 API 字段与 `autoRestart`
无锁，而写方（内核注入 API、插件 `SetAutoRestart`）与读方（插件后台 goroutine
注入、内核 registry 读 `AutoRestart`）天然跨 goroutine。加 `apiMu` 修掉；约定
只在持锁期间取字段值，取完即释放再调用——持锁调用会把 `InjectInputSync` 这类
阻塞到 agent 回复（可达数分钟）的方法与 `SetIOInjector` 串起来，让插件重载卡死。
测试还抓出两个自身缺陷：`bindDocMedia` 把同一份媒体数两次（`AddRef` 幂等所以表
是对的，但日志说「绑定 2 个」而实际 1 条——误导后续排查），以及用单字符实体名
时 `validEntityName` 静默跳过、`Commit` 返回 nil 却什么都没写。
存量插件不需要改一行也不需要重编：新增方法由插件调用、内核实现，不调就不受影响。
17 个 example 插件源码零改动通过类型检查。
|
2026-09-06 09:51:31 +08:00 |
|
|
|
a7b54fef7f
|
test(memory): 修正数据丢失回归用例的构造——它被媒体三元组修复本身弄失效了
两个修复之间产生了耦合：TestArchiveColdDocs_KeepsDocWhenGraphWriteEmpty
的前提是「三元组全被 validEntityName 拒绝」，而同批引入的
mediaTriplesFromText 会为正文里的 [image/png <digest>] 标记产出合规的
「图片 <digest>」三元组，于是 ec=4 rc=2、绑定成功、释放引用变成正确行为，
用例的前提消失。
（注意当时 GC 断言并未触发——内容没丢，只是"引用被释放"这条断言不再
适用于该构造。）
改法：正文不再含媒体标记，媒体引用直接 AddRef 挂上。这模拟的是更危险的
组合——文档持有媒体引用，但正文里的媒体标记已在清洗中丢失，于是有引用
要释放却没有句子能承载它。那正是这个守卫要防的情形。
反向验证重做后仍成立：回退守卫 → FAIL（引用被释放 + GC 删掉了本该保留的
内容）；恢复修复 → ok。
教训：只跑针对性测试不足以发现修复之间的耦合。提交前我跑的是
internal/agent/core 与 internal/memory，当时通过是因为缺陷二尚未修完；
两个修复都落地后的第一次全仓回归才暴露它。
|
2026-09-05 12:08:33 +08:00 |
|
|
|
387b28ce09
|
fix(memory): 媒体归档三缺陷——数据丢失、L3 入库不可靠、L3 检索未接线
自动触发链实测（medialive）连续暴露的三个缺陷，全部是「手工调 API 的
单测无法发现」的类型。附带该实测本身。
## 缺陷一：三元组全被拒时仍释放引用并删文档（数据丢失）
archiveColdDocs 只检查 len(triples) > 0 就释放媒体引用、删除文档。
但 Commit 会静默跳过实体名不合法的三元组（validEntityName 要求
2–50 字符），于是「无错但一条也没写进去」真实发生：
[agent] doc→graph: doc_xxx → 0 entities, 0 relations
[media] 文档 doc_xxx 入图库，释放 1 个媒体引用（描述已留在图库）
被记忆引用的内容被 GC 删除了（清 1 条/318 字节）
图库里没有任何句子承载引用，文档也被删，blob 被 GC 回收 → 图片与描述
彻底消失。我在上一层写的注释「Commit 之后引用已挂到 graph_sentence」
是错的：ec=0 rc=0 时它什么也没挂。
修法（用户选定 B+A）：
B. ec==0 && rc==0 时保留文档、跳过归档——归档的实质是「信息从 L2
搬到 L3」，搬不过去就不该删源，下轮再试。
A. bindSentenceMedia 返回实际绑定数，commitTriplesWithMedia 透出为
mediaBound；释放前四路判断（查引用出错→保守不释放／本无引用→无需
释放／mediaBound==0→保留并记录原因／否则释放）。宁可留一条悬空
引用（内容还在，可由后续一致性检查清理）也不能丢内容。
反向验证：旧行为下新测试确实 FAIL，报「引用被释放了」+「GC 删掉了本该
保留的内容」；恢复修复后 PASS。
## 缺陷二：媒体入 L3 依赖 NLP 提取器运气（可靠性）
媒体能否进图库，取决于提取器碰巧从描述文本里提出合规三元组。实测 LLM
的 477 字图片描述只产出「水平 -分割-> 成」，obj 仅 1 字被拒 → 整条媒体
记忆进不了图库。表现为「阶段 5 时好时坏」，取决于描述文本。
但媒体自身的 digest / mime / 描述都是确定的，不该受提取器支配。
新增 parseMediaMarkers + mediaTriplesFromText：从文档正文的媒体标记
直接产出确定三元组，先于 NLP 提取。同一份真实文档由 0 entities 0
relations 变为 ec=4 rc=2 且拿到句子 id。
三个设计点：
- 实体名用「图片 <短digest>」而非描述：描述会被重新生成（换视觉模型、
补描述），若名字取自描述，同一张图会在图谱上留下多个节点。digest
不变则名字不变，长度也天然合规。
- SentenceText 用原始标记段，保证 bindSentenceMedia 的正则必然能反解
到 digest——绑定从概率事件变成确定行为。
- 描述为空时仍产出「类型」三元组：描述是后台异步补的，媒体节点不该
因为还没描述就不存在于图谱。
- summarizeForEntity 按 rune 截断而非字节：按字节切会破坏 UTF-8，
图库里会留下乱码实体名。同时清 Markdown 强调符。
这是过渡方案，用户已定：下个 feature 换多模态嵌入后不再依赖
「描述文本 → 提取三元组 → 图谱节点」这条链路。
## 缺陷三：L3 媒体检索没有任何调用方（接线缺失）
第四层实现的 RecallMediaForSentence / mediaContextForSentences 从未被
调用——媒体能存进 L3、能反查，但 agent 拿不出来。实测第二轮 agent 显式
调了 doc_query，回答「没有找到那张图片的任何记录」。
接两个入口：
- buildMemoryContext（自动注入，每次 LLM 调用都走）
- memory_recall 工具结果末尾（显式查询）
关系行只有实体名和关系类型，看不出「这条记忆当时还带了一张图」，
媒体挂在句子上，必须经 关系→句子→media_refs 反查。
一处折返：最初直接用 injected.Relations 取 sentence_id，测试失败。
Indexer.BuildContext 刻意把 Relations 置 nil（自动注入只给实体索引以省
token，细节留给 memory_recall）。改为用命中的实体名再查一次关系，
深度固定 1——媒体是「这条记忆当时带的图」，顺关系网扩散只会带出无关
媒体并挤占 token。
## medialive 自动触发链实测
internal/agent/core/medialive_test.go，medialive build tag，默认
go test 不收录。源/模型/密钥全部由调用方经环境变量显式指定，缺任何一项
Skip 并列出缺哪个——刻意不提供 fallback，猜一个 base_url 可能打到调用者
机器上不相干的服务，而失败会被误报成「媒体记忆有问题」。
MEDIALIVE_BASE_URL=... MEDIALIVE_API_KEY=... \
MEDIALIVE_MODEL=... MEDIALIVE_ADAPTER=... \
go test -tags medialive ./internal/agent/core/ -run TestMediaLive -v
只注入一个 image 事件，之后七个阶段全由生产代码自己触发：CAS 落盘 →
引用绑定 → 描述生成 → L0→L2 转移 → L2→L3 绑定 → GC 保护 → 第二轮召回。
另有阴性对照：不给记忆时不该「记得」，否则阳性用例的通过可能只是模型
猜常见配色。上游不可用时 Skip 而非假 PASS。
真实 claude-opus-5 实测通过：第二轮不给图，agent 答出
「上：紫罗兰色 #8800DD / 中：蓝色 #0055EE / 下：纯红 #EE0000」。
## 测试
graphmedia_test.go 新增 8 例：数据丢失回归（反向验证过）、mediaBound
计数、媒体标记解析、实体名生成、描述截断、确定性三元组必然可入库、
关系→句子映射、L3 检索接线（自动注入与显式查询两路）。
全仓 go build / go vet / go test 通过，internal/agent/core 与
internal/memory 全绿，SDK 冻结 diff = 0。
|
2026-09-05 12:03:30 +08:00 |
|
|
|
775d9e8a2e
|
fix(memory): core.New 漏接 rc.SetMediaStore，L0→L2 引用转移在生产从未生效
RelevanceContext.transferMediaRefs 依赖 c.mediaStore，而该字段只有
SetMediaStore() 能设置。搜遍全仓非测试代码，调用点为零——core.New() 里
没有，cmd/homed/main.go 里也没有。
上一层（f855893）把 AgentConfig.MediaStore 接到了 Agent.mediaStore，
漏了 rc 这一路。
后果是静默的：Prune 归档时 c.mediaStore 为 nil，transferMediaRefs 直接
return，而携带引用的 ContextEvent 已被归档删除 → 引用永久悬空在
context owner 上、计数永不归零 → 对应 blob 永远不会被 GC 回收。
## 为什么测试没抓到
mediaref_test.go 里我手工调了 rc.SetMediaStore(ms) 才测转移逻辑。
**测试验证了函数正确，没验证它被接上了。** 与 findPluginPID 那次同一
个教训：测了一件不会自然发生的事。
## 顺带全字段审计
写脚本比对 AgentConfig 的 32 个字段与 New() 函数体的引用情况，
确认无第二处漏接。
|
2026-09-05 12:02:34 +08:00 |
|
|
|
6190a5a587
|
fix(plugins): 修复隔离全量测试暴露的两处数据竞争
-go test ./... -race 全仓复验暴露的 7 处 race、5 个失败测试，全部定位。
两处独立缺陷，互不相关。
## 缺陷一（remotedevice，8 处 race）：连接写无串行化
WARNING: DATA RACE
Read at 0x... by goroutine 28:
bufio.(*Writer).Available() / writeFrameHeader / PushData
Previous write at 0x... by goroutine 27:
bufio.(*Writer).Flush() / writeFrame / handleWS
同一连接的 bufio.Writer 被两条并发路径写：
- handleWS 主循环：读到设备帧后回写 hello_ack/bind_ack/pong
- PushJSON/PushData：agent→设备的下发路径，可来自任意 goroutine
bufio.Writer 不是线程安全的。不加锁就在 WriteByte/Flush 上撞——这
不是理论风险，TestWSPushDataAudio 的异步 PushData 与 handleWS 的
hello_ack 回写并发时被 -race 稳定抓到。
修法：wconn 增加 wmu（sync.Mutex），PushJSON/PushData 拿锁后整条
下发（start + N 个 chunk + end）持锁——设备侧按协议串行聚合，中途
被插帧会破坏协议顺序。handleWS 的 hello_ack/bind_ack/pong 也改走
同一把锁（wsWriteLocked 封装，避免调用方绕过）。设备已离线时不回写。
关键点：不能只锁 Push* 不锁 handleWS——那只是把竞争挪了个位置。
## 缺陷二（agentcli，1 处 race）：共享读缓冲被并发读写
WARNING: DATA RACE
Write at 0x... by goroutine 26:
os.File.Read / (*linuxPty).Read / reader
Previous read at 0x... by goroutine 25:
runtime.slicecopy / readLoop
readLoop 创建 buf := make([]byte, ReadBufSize) 传给 reader goroutine
（t.session.Read(buf) 持续覆写），自己又在读到结果后
copy(data, buf[:r.n])——同一缓冲被读写并发。Go 的 pty 读走 OS 层
fd，专门在 reader 写下一段时读，跑 -race 稳定复现。
修法：readResult 携带 data field，reader 每次读完后把数据复制进自己
分配的切片再随结果传递，读取与拷贝之间不再共享任何可变状态。原 buf
保留（仍由 reader 独享用于 OS 读），readLoop 不再从其中 copy。
## 验证
- 两个插件包 -race -count=2 全过
- 全仓 go build / go vet / go test 通过
- 全仓 go test ./... -race：32 包全过，0 DATA RACE，0 FAIL
- SDK 冻结 diff = 0
其中 remotedevice 的 TestScreenseeEndToEnd / TestComputeruseEndToEnd
/ TestClipboardEndToEnd 原本因 race 挂，修后恢复全绿。
|
2026-09-05 05:53:17 +08:00 |
|
|
|
28fc833a6f
|
feat(memory): L3 图库媒体反查 + 修 L2→L3 引用泄漏
媒体记忆四层收尾。方案 A：只做引用，不建媒体实体节点。
## 为何不把媒体建成图库实体
图库里的实体与关系全部来自**描述文本**的 NLP 提取——描述经
mediaSummaryForEvent 进 L0 事件的 Input，随归档进 L2 文档的 Content，
蒸馏时提取器自然从描述文字里抽出实体和关系。检索能力已经具备。
若再把媒体本身建成节点，节点名只能从描述里取，而描述会被重新生成
（换个视觉模型、补一次描述，名字就变了），于是同一张图会在图谱上留下
多个语义模糊的节点。代价换不来能力。
所以这一层只做一件事：**反查**。图库句子写着「[image a1b2c3d4e5f6]
一张紫蓝红三色带图」，要能从这条句子取回那份字节。
## CommitWithMedia：新增方法而非改签名
Commit 有 10 个非测试调用点 + 21 个测试调用点。为一个多数调用方都不需要
的返回值改全部签名不划算。新增 CommitWithMedia 返回
map[句子文本]sentences.id，Commit 内部转调同一份落库逻辑。
## digest 靠正则从文本反解
三元组由 NLP 提取器从纯文本产出（nlp.ToMemoryTriple 只填 Subject/
Relation/Object/Confidence/SentenceText），提取链路上没有任何位置能塞进
结构化的 digest。要贯通就得改 internal/nlp 的整条数据流。而媒体标记本身
是我们自己按固定格式写进文本的，反解是最省的可靠做法。
配套加 media.ResolvePrefix：文本里是 12 位短 digest（完整 64 位会把一行
撑爆且无助人眼辨认），media_refs 主键要完整 digest。
**前缀歧义视为错误而非"取第一个"**：挂错引用会让 GC 删掉仍被引用的内容。
完整但不存在的 digest 也报错，否则调用方会挂一条孤儿引用。
## 顺带修掉 L2→L3 的引用泄漏
这是上一层（f855893）留下的缺口：我当时只处理了 L0→L2 的引用转移，
漏了 L2→L3 这一跳。archiveColdDocs 调 docStore.Remove(doc.ID) 时不注销
媒体引用——文档一旦消失就再没有任何东西能告诉我们它引用过哪些 digest，
media_refs 里那条记录永久悬空、引用计数永不归零，对应 blob 永远不会被
GC 回收。
新增 releaseDocMedia。L2→L3 这一跳是**释放**而非转移，因为图库存的是从
描述文本抽出的实体与关系，不再持有字节；媒体此时已完成使命。
顺序有讲究：必须在 commitTriplesWithMedia 之后释放。那一步已把引用挂到
graph_sentence owner 上，先销后挂会让引用计数瞬时归零，此时若后台 GC
正在跑就会把内容当孤儿清掉。
## 顺带修 Pending 的排除逻辑遗漏（承上一提交）
## 测试
graphmedia_test.go 11 例。核心是 TestBindSentenceMedia_RoundTrip：
写入 → 提交 → 从句子 id 反查 digest → 取回字节逐字节比对 → 跑 GC(0)
确认被引用的内容不被清。
其余覆盖：正则不误命中普通方括号（[注意]/[TODO] 不能当 digest，否则会拿
假前缀去 ResolvePrefix）、无法补全的 digest 不挂引用、媒体关闭时全链路
静默 no-op、releaseDocMedia 释放后 GC 真能回收、200 个样本的前缀补全
要么唯一命中要么明确报歧义。
TestCommit_StillWorksAfterRefactor 记录一个既有行为：重复提交时
entitiesCreated 不归零，因为 SQLite 的 ON CONFLICT DO UPDATE 也算一行
affected。用 main 分支的 graph.go 单独跑过基线确认与本次重构无关，
该字段只用于日志，故记录现状不改行为。
全仓 go build / go vet / go test 通过，internal/agent/core 与
internal/memory 全部 -race -count=2 通过，SDK 冻结 diff = 0。
|
2026-09-04 22:52:30 +08:00 |
|
|
|
74a24f93d7
|
feat(memory): 媒体 GC 与描述生成两条后台循环
补齐媒体记忆的最后两块：容量上限真正生效，描述文本成为持久语义记忆。
## mediaGCLoop：让容量上限不再形同虚设
CAS 的 GC 只在被显式调用时执行，Put 路径不触发它。此前配置项
core.memory.media.max_mb 注册了却没有任何调用方——一次 see_video 抽 10 帧，
帧本身在工具结果被 Prune 后就没人引用了，若无人清理会一直堆在磁盘上。
现在按 gc_interval（默认 6h）周期调 GC(gc_min_age)。两个不变量：
- 有引用的内容永不删除，即使超容量（宁可超限也不断引用）
- gc_min_age（默认 1h）保护刚 Put 还没来得及 AddRef 的项——它们
refcount 也是 0
## mediaDescribeLoop：描述才是能活过 GC 的那部分
blob 会被容量 GC 淘汰，而描述留在 media 表里，并经 mediaSummaryForEvent
写进 L0 事件、随归档进 L2 文档、经蒸馏进 L3 图库。于是「那张紫蓝红三色
带图」在原始字节早已被清掉之后仍然可被检索到。
复用既有的视觉回退链（resolveModalFallback + chatModalFallbackBatch），
不新造一套模型调用。
三个刻意的决定：
- **走后台而非入库时同步**：视觉模型一次调用生产实测 9.6s。放在对话
路径上会让每张图都给回复加十几秒，而描述的价值是几个月后还能检索到，
不是这一轮——这一轮模型本来就直接看着图。
- **逐条而非批量**：批量拿回来是一整段文字，无法可靠切分回各自的
digest（模型未必按序号输出，也可能把两张图合并成一句）。宁可多几次
往返也要保证「描述 ↔ digest」的对应关系确定。
- **默认关闭**（describe_on_ingest=false）：它消耗视觉模型配额。开启后
每 30s 最多处理 4 条，不跟对话抢额度。
失败处理分三类：
- 网络抖动/配额 → 不标记，下轮重试
- 空回复 → 视作失败（上游剥离媒体时通常回空，与 modalfallback 同理）
- 不可描述（kind=other、blob 已丢失）→ 标记 described_by=unsupported/
content-missing，退出队列
## 顺带修掉 Pending 的一个真缺陷
测试写出来才发现：Pending 原先只看 `description = ''`，于是被标记为
described_by=unsupported 但 description 仍空的项**每轮都会被重新取出来
重试**，永久占着 LIMIT 的名额，真正需要描述的新项永远轮不到。
改为同时要求 described_by 也为空。
这是「先写断言再看它是否成立」抓到的——原本我以为标记一下就够了。
## 测试
medialoop_test.go 7 例：两条循环在禁用时立即返回（nil store / 零间隔 /
describe 关闭三种形态，不留空转 goroutine）、GC 清孤儿保留有引用项、
minAge 保护新项、无可用源时不误标记、不可描述大类被标记后退出队列。
media_test.go 补 1 例专测 Pending 的排除逻辑。
全仓 go build / go vet / go test 通过，SDK 冻结 diff = 0。
|
2026-09-04 22:00:03 +08:00 |
|
|
|
2879e76883
|
fix(test): 崩溃隔离测试误杀同机生产插件，且断言无效
## 现象
生产 homed 的 editdoc 子进程从 9-03 起被 SIGKILL 9 次，间隔完全不规律
（126~485 分钟），全部发生在无工具调用的空闲期。查过 OOM（dmesg/
journalctl -k/cgroup oom_kill 全为 0）、systemd 内存限制（MemoryMax=
infinity）、cron/timer、内核自身的 StopAll 路径、agent 执行过的 cmd_run
命令，以及 Pdeathsig 绑创建线程的可能——全部排除。
## 真因：测试杀了生产的进程
用 ftrace 的 signal_generate tracepoint 挂监视器后抓到发送者 cmdline：
/tmp/go-build.../plugins.test -test.run=TestRealPlugin_CrashDoesNotKillKernel
findPluginPID 用**全系统** `pgrep -f plugin.bin`，然后只比"exe 路径含
editdoc"。生产实例的 /home/newqqagent/plugins/editdoc/plugin.bin 也满足
这个条件，谁先被 pgrep 列出来就杀谁。9 次 kill 全部落在有人跑 go test
的时段——18:18:30 那次正是一轮 `go test ./... -race` 的窗口。
之前几轮排查一直在生产实例内部找原因，方向从一开始就错了：杀手在仓库里。
## 更严重的是这个测试本身无效
旧断言是"SIGKILL 之后内核仍存活"。可内核本来就活着——即使信号发错了
对象（杀了生产实例的插件），测试内核的插件压根没死，断言照样通过。
**它在测一件没发生的事**，同时把生产环境打坏了，而绿色的测试结果掩盖了
这一切。这也是它能连续 9 次造成生产故障却从没被注意到的原因。
## 修法
findPluginPID 增加 root 硬约束：/proc/<pid>/exe 必须以测试自己的 plgDir
为前缀，且是目标插件，两道条件同时成立才算命中。root 为空直接 t.Fatal
——这不是可选过滤器，是防误杀的前提。
- 用 exe 而非 cmdline：cmdline 可被进程自行改写，exe 符链由内核维护。
- root 先过 EvalSymlinks：/tmp 在部分发行版上是符链，不归一化会让前缀
比较永远不命中，退化成静默 Skip（那样测试就白跑了）。
断言改成两步：先轮询确认目标进程真的退出（3s 上限），再验内核未被连带。
两步都成立才能证明隔离生效。
## 验证
修复后跑 TestRealPlugin_CrashDoesNotKillKernel：
- 杀的是 pid=3448366，exe 在 /tmp/hc_integration_3823918128/plugins 下 ✓
- 生产 editdoc pid 测试前后均为 3362892，存活时长连续 ✓
- 四个 TestRealPlugin_* 全部 PASS
|
2026-09-04 21:45:17 +08:00 |
|
|
|
f855893d1c
|
feat(memory): 媒体接入 L0/L2——digest 挂到对话事件，归档时引用随之转移
在 a822674 的 CAS 层之上把媒体真正接进记忆链路。此前 CAS 只是个孤立的
存储包，没有任何写入方。
## 媒体进入对话有两条路，两条都只把文字留给记忆
1. 用户直接发图 → processMediaInput → mediaToBlocks
ContextEvent.Input 只存 alt 文本（"[从 qq 收到了 image]"），
base64 随 message 数组发给模型后就丢了。
2. 插件注入 → SetToolBlocks → process.go 的 mediaMsg
ToolResultItem.Output 只存那句 "[已将图片注入后续对话] /tmp/x.png"。
于是下一轮起，模型能看到的只剩一句路径或一句 alt。那个文件被删、被覆盖，
或者本来就是 /tmp 下的临时产物，连线索都断了。
现在两条路在同一处收口（captureBlockMedia）：从 ContentBlock 的 data URL
取出字节存进 CAS，digest 挂到当轮 ContextEvent。
## 改动
internal/agent/core/mediaref.go（新）
- captureBlockMedia：ContentBlock → CAS。只处理 data URL——http(s) URL
拿不到字节就无法内容寻址，而「下载它再存」会把一次对话变成一次网络
请求（超时、鉴权、SSRF 全来了），不在本层解决。
- stage/drainMediaDigests：媒体在 process() 期间被捕获，而承载它的
ContextEvent 要等 process() 返回后才 Append——此刻还没有 owner_id，
故先缓存。与既有 pendingMedia 同一手法，同受 a.mu 保护。
- bindEventMedia：双向落地。evt.Media 让事件记得引了什么（随
context.json 持久化），media_refs 让 CAS 知道谁在引用（GC 的判断依据）。
只写一边的话，要么 GC 误删仍被引用的内容，要么孤儿永远清不掉。
- mediaSummaryForEvent：把已有描述拼成一行写进 Input。这是方案 C 的
落点——**描述文本才是持久语义记忆，blob 只是缓存**。blob 可能被容量
GC 淘汰，但描述会一直留在 L0/L2/L3 的文本里，让「那张紫蓝红三色带图」
几个月后仍可被检索。
ContextEvent 新增 ID 与 Media 两个字段，都是 omitempty：
- ID 懒生成，只有真要挂媒体时才赋值。绝大多数对话没有媒体，全量生成
会让每条事件都多一个字段进 context.json。
- 存量 context.json 读回来两字段皆空，不影响任何既有行为（有测试）。
RelevanceContext.Prune 归档时转移引用（transferMediaRefs）：
**先挂到归档文档、再注销原事件引用**。顺序不能反——先销后挂会让引用
计数瞬时归零，若此刻后台 GC 正在跑就会把仍被记忆引用的内容当孤儿清掉。
为此把 Prune 内的局部类型 scored 提为包级 scoredEvent（局部类型无法
出现在方法签名上）。
media 包新增 OwnerContext/OwnerDocument/OwnerGraphSentence 常量：
owner_kind 进了主键，拼错一个字符就是一条永远对不上的孤立引用——
AddRef 不报错，DropOwner 也永远匹配不到。
## 配置
core.memory.media.enabled（默认 true）、.dir、.max_mb（2048）、
.gc_interval（6h）、.gc_min_age（1h）。
关闭后全链路静默跳过，对话行为与本特性上线前完全一致（有测试）。
mediaStore 为 nil 时同理——它是记忆增强，不是对话必需品，开不起来
只记一条 warning 不阻止启动。
## 测试（11 例）
入库与 MIME 归类、http URL 跳过、nil store 全链路 no-op、音视频混合、
stage/drain 清空语义、懒生成 ID、描述作为持久记忆、**归档转移期间内容
始终可读且 refcount 不归零**、无媒体存储时归档照常、context.json
向后兼容往返。
全仓 go build / go vet / go test 通过，SDK 冻结 diff = 0。
## 尚未接入
L3 图库的 graph_sentence owner（常量已备好，无写入方）、
描述生成的后台任务（Pending() 已就绪，尚无消费者）、
媒体 GC 的定时触发（配置项已注册，尚未接 ticker）。
|
2026-09-04 20:53:32 +08:00 |
|
|
|
aa3ff5a12f
|
fix(proc): stage 协调器双重解锁——内核本体 fatal 崩溃的真因
## 现象
2026-09-04 06:56:18 生产 homed 主进程直接死亡，退出码 2，
带走全部 27 个子进程插件。
fatal error: sync: unlock of unlocked mutex
proc.(*Host).endStage(...) host.go:189
proc.(*coreHandler).runStage.func1() stage.go:94
core.(*StageHost).RunStage.func1() stages.go:190
stage.go:94 与 stages.go:190 各有一层 recover，专为「插件出错不拖垮内核」
而设，却全部失效：**sync.Mutex 的双重解锁走 runtime fatal，不是 panic，
recover 结构上就拦不住**。这就是本次「插件崩溃被隔离」的设计没能生效、
内核本体整体死亡的原因。
## 根因
endStage 把 coord.leave()（递减 inflight、判定「我是最后离开者」）放在
coordMu 临界区**之外**，而摘除 h.coord 在临界区**之内**，留出窗口：
A.endStage: leave() → inflight 1→0, last=true，尚未摘除 h.coord
B.beginStage: 看到 h.coord != nil，以「后到者」身份 enter，inflight 0→1
（后到者按设计不取 stageMu）
A.endStage: h.coord = nil；stageMu.Unlock() ← 第 1 次
B.endStage: leave() → inflight 1→0, last=true → stageMu.Unlock() ← 第 2 次 💥
B 从未持有 stageMu，却因挂进一个正在收尾的协调器而被判成「最后离开者」，
对同一把锁解了两次。崩溃前一行日志是 config_list_keys 的结果——那一刻
正好有 stage 扇出，与竞态窗口重合。
## 修复
把「递减 inflight → 判定最后离开者 → 摘除 h.coord」收进同一个 coordMu
临界区，后到者再不可能挂进已收尾的协调器。为此把 leave() 拆成：
- depart()：纯计数，由 endStage 在 coordMu 内调用
- finish()：共享段回读 + arena 压实，在 coordMu 外、但仍在
stageMu.Unlock() 之前（先放锁会让下一轮 stage 在回读未完时改写共享段）
leave() 保留给单测。
同一函数的第二个隐患一并修掉：首进者的 enter()（含 WriteAll 写共享段）
原先在 coordMu 之外，后到者可能拿到 coord 就去读**写了一半**的段。
现在 enter() 在锁内完成。
beginStage 错误路径的 stageMu.Unlock() 必须保留并已加注释说明：
runStage 的 defer endStage(coord) 是在 beginStage 返回 err 的检查**之后**
才注册的，这条路径上没有任何人会替它解锁，漏掉就是整个 stage 通道永久卡死。
锁序 stageMu → coordMu；endStage 只解锁 stageMu 不获取，无环。
## 验证
反向验证：把 host.go stash 回旧版跑新测试 → fatal error: sync: unlock of
unlocked mutex；恢复修复 → 通过。测试抓的确实是这个缺陷。
5 个回归用例（host_stage_test.go）：
- 后到者不复用已收尾的协调器（直接构造那个时序，不靠调度巧合）
- 8 worker × 40 轮并发进出（旧实现下整个测试二进制 fatal 而非 FAIL）
- 同阶段多插件扇出共用一个协调器、仅最后离开者解锁
- 50 轮串行不泄漏（少解锁会在第二轮卡死）
- 四阶段序列 pre_action→chat→after_toolcall→post_action
internal/plugin/... 全量 -race -count=2 通过。
## 同类缺陷审计（本 commit 未改动其他文件，仅记录结论）
针对「recover 拦不住的 runtime fatal」这一整类做了全仓审计：
1. 跨函数持锁（本缺陷的形状，脚本枚举 Lock/Unlock 不配对的函数）
- proc/lock.go 的 Release/ForceRelease 同样「只 Unlock 不 Lock」，
但两者都在 ownerMu 下先检查 held/owner 再解锁，非持有者直接返回，
不存在双解锁路径。
- 其余 22 处 Lock/Unlock 计数不等的函数逐一复核：全部是多分支早退各自
解锁（waiter 的 goto nextMessage、sidecar.call 的五个错误分支、
lua adapterPool 的 cond.Wait 池模式等），配对正确。
2. 并发 map 读写（同样是 runtime fatal）
- 16 处「无锁访问 map」全部复核为安全：Locked 后缀约定（orderedLocked、
defsLockedRegisterSource）、调用方持锁（document 的 addSummary/
removeDoc/loadAll、registry 的 runStopHandlers/runOnRemoveHandlers）、
或启动期单线程（knowledge.scanAll、static_embedder 构造后只读）。
3. close of closed channel
- 全仓仅 sidecar.go 有同名变量的两处 close(ch)，但作用于不同集合成员，
且 Close() 前有 readerWg.Wait() 与 stopped 标志，reader 侧已 delete
出 pending，不会双关。
- 各插件 stopCh 的 close：healthcheck 用 select 守卫、clawhubadapter 用
stopOnce、evtring 用 running 标志、timer 交给 StopHandler 单次调用。
agentcli.Stop() 是裸 close(p.stopCh) 无幂等守卫，但 Registry 的六处
Stop 调用点都在同一把 r.mu 下先 delete(r.plugins)+摘 r.instances 再
Stop，不存在二次调用路径——记录为「依赖调用方约定」而非当前缺陷。
4. WaitGroup 误用：未发现 Add 出现在 goroutine 体内的形状。
5. 全仓 go test ./... -race：零 DATA RACE、零 FAIL。
|
2026-09-04 18:45:19 +08:00 |
|
|
|
4ef3371701
|
test(memory): 媒体存储的压力、冒烟与长稳测试
在 a822674 的 CAS 层之上补齐三类验证。
## 压力测试（stress_test.go，9 例）
核心不是吞吐数字，而是并发下的不变量。为此写了 checkRefIntegrity：
用 SQL 对比每个 digest 的 ref_count 与 media_refs 实际行数。这条对不上
就意味着 GC 的判断依据是错的——计数偏低会误删有引用的内容，虚高会让
孤儿永远清不掉。所有并发用例收尾都验它。
- 32 goroutine 并发 Put 同一内容 → digest 一致、磁盘只 1 份
- 400 个不同内容并发入库 → 无丢条目、逐条回读无内容串位
- 24 worker × 40 轮引用增删风暴（含故意重复 AddRef 验并发下的幂等）
- GC 与读写并发 1.5s → 实测 11508 次 Put / 604 轮 GC，受保护内容零失败
- Describe 与 Search/Pending 并发 → 无 database is locked
- 容量上限持续加压 → 上限 256KB 收尾 98KB，有引用项全存活
- 重度 churn 后重开 → 磁盘文件数 == 元数据条数，无双向孤儿
- 4MB 单文件往返（see_video 10 帧 × 2MB 是现实上限附近）
- data URL 往返 ×50（SetToolBlocks 给出的实际形态）
-race -count=3 干净。
## 冒烟测试（smoke_test.go，6 场景）
走真实数据路径：真 PNG（自建 IHDR/IDAT/IEND + zlib）、真 data URL、
真 sha256、真 GC、真重启，而不是随机字节。
- 同一张截图连问 5 轮 → 磁盘 1 份、5 个 context 引用
- see_video 6 帧内容各异 → 各存一份、共享一个 owner
- 描述落库后按关键词检索命中（方案 C 最关键的一环：blob 可被淘汰，
描述会长期留在记忆里）
- L0→L2 归档时引用从 context owner 转到 document owner，期间内容可读
- 别的工具留下的一次性图被 GC 清掉，被记忆引用的一个不少
- 全生命周期跨重启：描述、引用、内容、磁盘一致性全部完好
第一次跑挂在「6 帧只搜到 5 条」，看着像存储丢帧，实际是夹具的
palette[(variant+y*3/h)%5] 只有 5 色，variant=0 与 5 产出逐字节相同的
PNG，被 CAS 正确去重。已把 variant 写进像素保证帧间真不同，并把这段
经过记进注释——误报本身证明了去重在工作，也证明冒烟确实有能力发现
「帧数对不上」这类问题。
冒烟原先是 internal/memory/media/smoke/ 下带 //go:build smoke 的独立
main，得记着加 -tags smoke 才跑得到，那种早晚被忘掉。已搬成普通测试，
随 go test ./... 一起跑，冒烟的意义才真正成立。
## 长稳测试（soak_test.go，-short 下跳过）
60 秒五路混合负载。实测：put=281885 get=1644084 gc=9142
describe=53875 search=23268 refOps=187926，零失败。收尾 20 个受保护项
内容字节一致、ref_count 全为 1；8MB 上限下实际占用 139KB / 48 条，
说明 28 万次写入产生的孤儿被持续清理，无无界增长。
描述者从 Pending() 取项再 Describe()，GC 随时可能在这两步之间清掉它。
这是正常竞态，故忽略 unknown digest 并注明原因；5 万多次调用没把它
升级成计数错位，印证了 Describe 对已删项返回错误而非静默建条目的选择。
全仓 go build / go vet / go test 通过，SDK 接口冻结 diff 为 0。
|
2026-09-04 11:29:18 +08:00 |
|
|
|
a82267484a
|
feat(memory): 内容寻址媒体存储（CAS）——图记忆支持二进制多媒体节点的底座
此前四层记忆全是纯文本载体，没有任何一层能存二进制：
L0 ContextEvent — Input/Response/ToolResults[].Output 全 string
L1 text.Event — 同上
L2 document.Doc — Summary/Content/Tags 全 string
L3 图库 — sentences.text TEXT UNIQUE，节点身份就是那串文本
于是 multimodal 插件注入的图只在本轮对话内可见（走 message 数组，不经
记忆），下一轮起只剩 ToolResultItem.Output 里那句
"[已将图片注入后续对话] /tmp/x.png"——一条路径字符串。那个文件被删或
被覆盖之后连线索都断了。
## 为何内容寻址而不是存路径
- 路径会失效。/tmp 下的探针图、下载缓存、别的进程的临时产物，记忆里
留个路径等于留个悬空指针。
- 同一内容常被反复注入（连问几轮同一张截图、see_video 相邻帧高度相似），
按 sha256 寻址天然去重。
- 内容即身份，与 L3 图库 sentences.text UNIQUE 思路一致：文本节点用文本
本身做身份，媒体节点用内容摘要做身份。
## 结构
元数据（SQLite media.db）与内容（磁盘 blobs/ 两级前缀分桶）分离，不把
blob 塞进库：单张图动辄几 MB，塞进去让每次 VACUUM/备份都拖着几百 MB 走，
WAL 也会迅速膨胀。
media(digest PK, kind, mime, size, width, height, origin_path, tool,
description, described_by, ref_count, first_seen, last_seen)
media_refs(digest, owner_kind, owner_id, created_at, PK 三列)
digest 既是主键也是文件名，所以没有 Path 字段——路径由 digest 推导，
不落库（落了就又是个会失效的引用）。origin_path 仅供人类溯源，注释里
明确标注不可用于读取。owner_kind 预留 context/document/graph_sentence。
## 几处刻意的决定
- Get 强制校验 digest：CAS 的全部保证建立在「文件名 == 内容摘要」上，
位翻转或外部误改必须被发现——把损坏的图喂给模型只会得到无从追溯的幻觉。
- 先写 .tmp 再 rename：中途崩溃不留半个 blob 被当成完整内容读走。
- AddRef 幂等：只有真插进 media_refs 才递增，否则计数虚高会让 GC 永远
不敢清。DropRef 用 MAX(0,...) 兜底防负数。
- Put 的空描述不冲掉已有描述（先到的可能来自更强的模型），但尺寸/工具名
这类前一次缺失的信息会被补写。Describe 是显式操作，允许覆盖。
- GC 两段 + minAge 保护：刚 Put 还没 AddRef 的项 refcount 也是 0，minAge
防「落地后还没挂上就被清掉」。有引用的项永不删除，即使超容量——宁可
超限也不断引用。
## 测试
21 例，覆盖去重 / MIME 归类 / 损坏检测 / 无残留临时文件 / AddRef 幂等 /
计数不为负 / DropOwner / GC 保留有引用项 / minAge 保护 / 容量淘汰 /
描述覆盖与补写策略 / Search 按描述与 kind 过滤 / Pending / data URL
往返 / Stats / 跨重启持久化。
本 commit 只加存储层，尚未接入 L0/L2/L3 与描述生成。
|
2026-09-04 11:03:36 +08:00 |
|
|
|
3907347cac
|
fix(multimodal): 媒体改挂独立 user message，落实「注入后续对话」的原意
插件三个工具的返回文案一直写着「已将图片注入后续对话」，b777322 的提交
说明也写着「模型在下一轮 LLM 请求里直接看到图」。但实现是把 block 挂在
tool message 的 content 数组上——role=tool 上的多模态 content 不被当作
可视内容。
同一张图、同一个模型、三轮实测：
图在 user message → 3/3 读到，prompt_tokens 7089
图在 tool message → 0/3（模型答「我没能读到这张图」），tokens 7967
tool 纯文本 + 后接 user → 3/3 读到，tokens 7570
tool message 那轮 token 反而更高，说明 base64 确实进了上游，只是模型看
不到它。这解释了为什么此前只有回退链（转文字进 tool message 的纯文本
content）能用，而「主模型直接看图」这条路从 b777322 起就没通过——当时
的验证只看了 prompt_tokens 涨了 8500，没有校验模型答案对不对。
改为：tool message 保持纯文本结果，媒体另起一条紧随其后的 user message
承载，并在首个 text 块标注 [以下是 <tool> 注入的媒体内容]，避免模型误
以为是用户新发的图。位置必须紧跟 toolMsg，中间插入其他消息会让
tool_call_id 配对断开。
验证（生产，答案预先封存、生成时不读）：
- AUTO 源 vision=true 直视路径：随机三色带 → 答「紫、蓝、黄」，与封存
答案一致，日志无 modal fallback（确实走的直视），耗时 9.6s
（回退链同一用例需 ~90s，省掉了绕视觉模型一圈）
- see_video 6 帧直视：23s（回退链合包版 131s，逐块版 363s），模型正确
描述测试图卡的彩条布局、彩虹带滚动与计数器递增
- 负向：AUTO 源改回 vision=false，回退链仍正常转写，模型如实标注来源
|
2026-09-04 07:49:30 +08:00 |
|
|
|
09071dc235
|
fix(multimodal): 修多模态假成功 + 落地视觉回退链 + see_video 帧数语义
## 起因
生产盲测：模型调 multimodal_see_picture 后声称看到了图，实际一个字
都没收到。工具却返回「[已将图片注入后续对话]」。
链路：core.llm.model=AUTO → llmsproxy 按优先级选 big-pickle(prio=100)
→ 转 opencode zen。llmsproxy 的 opencode.lua 明写着：
-- zen 上游 schema 只接受 text content part（无视觉/音频能力）
if part.type ~= nil and part.type ~= "text" then -- 丢弃
判据：256x256 纯红 PNG，带图与不带图的 prompt_tokens 都是 256。
图片贡献零 token，即根本没进上游。
内核序列化与注入链本身是对的（Message.MarshalJSON 正确产出 content
数组，SetToolBlocks → IOManager → ConsumeToolBlocks → toolMsg.Blocks
全通）。缺的是「主模型能否消费这些块」这一判断——内核此前完全没有
多模态能力的概念（grep supportsVision|multimodal 在 agent/ 零命中）。
这与 v1.0.0 修的 output_send 假成功同类：告诉调用方成功而实际未送达。
## 1. 能力声明
新增 core.llm.sources.<name>.vision / .audio（走既有 sourceFieldDefs，
WebUI 配置页自动出现），types.LLMSource 与 api.BaseConfig 同步加字段。
新增 agentAPI.ModalProvider 接口 + ProviderSupportsVision/Audio 判定：
未实现该接口的 provider 一律按不支持处理。保守侧是刻意的——宁可多走
一次文字回退，也不能把图默默扔给会剥掉它的上游。
为何是声明而非探测：探测需额外真实调用且结果不稳定（取决于 AUTO 当次
路由到哪）；而 200 响应 + 相同 token 数从响应侧无法区分「看到了但没
内容」和「被剥掉了」。
## 2. 回退链（modalfallback.go）
实现了 config/registry.go 里注册但从未被读取的 image/audio
fallback_provider + fallback_model（此前 0 处读取点）。
prepareToolBlocks 在 process.go 注入前判定：能直视就原样透传；不能就
调声明了该能力的源转写成文字，带 [由 X 转写，非当前模型直接感知] 标注。
几处刻意的设计：
- 逐模态判定，不一刀切。很多视觉模型能看图但听不到音频，全部降级会
白白把可直视的图变成二手描述
- 混合场景下转写文字作为 text 块并入 native，两部分同时到达模型
- 配置指向未声明能力的源时拒绝并继续找——照用只会重演静默剥离
- 未配 fallback_provider 但某源声明了 vision 时自动扫出来用；静默失败
比多找一个能用的源更糟
- 空回复算失败。上游剥掉媒体后模型往往回「我没看到图片」或空串，两种
都说明回退链也没真看到
- 多媒体块按模态合包为一次请求（见下）
## 3. 批量合包（生产实测驱动的返工）
首版逐块调用，生产 see_video 6 帧实测：4 帧里 3 帧超时，整轮 363 秒。
改为按模态合包一次请求后同一用例 131 秒、6/6 成功。
顺带把 modalFallbackTimeout 从 90s 提到 180s：生产经网关转
claude-opus-5 看一张 400x400 图要 ~81s，90s 贴着上限。
多张时 detail 默认 low 控体积，单张用 high 看细节；插件显式给了
detail 则尊重它。
## 4. see_video 帧数语义
fps=1/N 是频率（每 N 秒一帧）不是数量。20s 视频实测：
frames=4 → 5 帧、frames=10 → 2 帧、frames=1 → 20 帧，要得越多拿得越少；
长视频下 frames=4 会产出 时长/4 帧，靠 i>=9 的 break 兜着才没炸上下文，
而那个 break 用的是 ReadDir 索引，跳过条目后与实际帧数错位。
改为 ffprobe 取时长 → fps=N/时长 + -frames:v N 硬封顶。
0.4s/3s/20s/120s × frames=1/2/4/7/10 全部精确。
极短视频的坑：fps=1 在 0.4s 素材上产出 0 帧（不足一秒抽不出），所以
时长探测失败时不能退化成 fps=1，改为不传 -vf 只靠 -frames:v。
## 验证
- modalfallback_test.go 14 例：直视透传 / 回退转写 / 无源如实报告 /
未实现接口按不支持 / 混合模态拆分 / 空回复算失败 / 块数上限 /
多图合一次调用 / detail 策略 / 拒绝未声明能力的源 / 未配置时自动扫源
- go test ./... 全绿，go vet 无警告
- 生产盲测（答案预先封存、生成时不读）：随机三色带 → 模型答
「紫、蓝、红」，与封存答案完全一致
- 负向验证：拿掉回退源后模型如实回答「没看到图片内容」并引用工具返回
的配置提示，且主动纠正了上一轮的答案
- 生产 see_video 6 帧：单次转写，模型正确描述测试图卡的计数器递增与
彩虹带滚动
|
2026-09-04 06:25:51 +08:00 |
|
|
|
f91b27aedb
|
fix: WebUI 版本显示 + Windows 交叉编译 + 发布脚本三处回归
## WebUI 版本链路修复
问题：handler.go:949 报的是 sdk.SDKVersion，那条链最终指向
SDK 仓 meta.Version 的硬编码值，与 -ldflags 注入的内核版本
完全不相交。构建时间、commit hash 全部丢失。
dashboard.html 兜底值是 '0.1.0'——碰巧版本号相等时不显眼，
一旦不等就报错。
修复：
- KernelStatus 新增 BuildStatus 字段（Version/Commit/BuildTime/SDKCompatible/KernelName）
取自 internal/meta（-ldflags 注入点），与接口冻结无关（KernelStatus 只在 internal/sdk）
- /api/v1/status 改用 meta.Version，另加 sdk_version 字段暴露 SDK 版本
- dashboard.html 概览卡显示 HomeAgent vX.Y.Z + commit/日期/SDK 兼容版本，
去掉 || '0.1.0' 误导性兜底
## Windows 交叉编译修复
问题：internal/plugin/dynamic_proc_windows.go（Part 1 的桩，610e9d0）只定义了
tryLoadProc，但平台中立的 registry.go 还在调 loadProc / closeProcHost——这两个
函数只在 dynamic_proc_unix.go 里。Windows 下整个 homed 从 Part 1 起编译不过。
plan.md §12.5 声称「Windows 只做了交叉编译，无真机验证」——实际是连编译都没通过。
修复：dynamic_proc_unix.go / dynamic_proc_windows.go 合并为平台中立的
dynamic_proc.go（文件内无任何平台专属调用，proc 包内部通过
shmalloc_* / evtfd_* / shmpass_* / procattr_* 各自带构建标签处理差异）。
## 发布脚本三处回归修复
deploy/packaging/build.sh（从 package/build.sh 移到 deploy/packaging/ 后）：
1. PROJECT_ROOT 少一层目录（.. → ../..），产物落进 deploy/build/ 而非根目录
2. initconfig 从未被构建，但 installer.nsi 和 package-linux.sh 都引用它
3. GO 兜底路径指向 /home/jianf/go1.26.5（陈旧硬编码）改为 command -v go
4. electron-builder --config package.json 校验整个文件导致 devDependencies 被判为 unknown
property，去掉 --config 让它从 build 键读配置
deploy/packaging/package-linux.sh：
1. build_go() 补上 initconfig 构建步骤
2. GO 兜底路径同步修复
知识库 3 条重写 + 1 条新增：
- homeagent_identity：v0.9.0 C ABI → v1.0.0 子进程
- homeagent_architecture：全篇重写为子进程架构（三面通信、Supervisor 台账、
崩溃自愈、权限三道闸）
- homeagent_recent_updates：在 v0.9.0 前插入 v1.0.0 主线摘要
- changelog_v1.0.0（新建）：6 类缺陷消除、架构、实测、已知限制、迁移指引
|
2026-09-03 15:38:31 +08:00 |
|
|
|
02cc74ce11
|
fix(proc): 子进程崩溃自愈 + 集中台账 + 注册面摘除
根因：子进程插件被 kill 后，内核只发了一个无人订阅的事件，
工具/stage handler/IO 通道全留在注册表里指向死进程，
模型继续调用只吃 ErrProcessExited，没有任何路径把插件拉回来。
## 四层修复
### 1. 专职 waitLoop（进程收割）
- 每个子进程配一根 waitLoop goroutine，是 cmd.Wait() 的唯一调用点
- 不再依赖 stdout EOF 判定死亡（孙子进程继承 stdout 时 EOF 永不到来）
- 手工 os.Pipe 替代 cmd.StdinPipe/StdoutPipe，避免 waitLoop 与
os/exec 的内部关闭竞争
- host.go: Host.Supervisor()，Host.Close() 先 StopAll 再拆段
### 2. 集中台账 Supervisor
- proc/supervisor.go: 插件 Spawn 握手成功即 track，进程退出即 untrack
- StopAll: 并发发 plugin.stop 走优雅路径，到期仍在的一律 Kill
- 关停后才完成握手的进程被立即结束，不会活过内核
- 消除「孤儿进程持共享段映射 → SIGBUS」的隐患
### 3. 注册面摘除（detachPlugin）
- 新增 StageHost.UnregisterPluginStages：摘除指定插件的全部 stage handler
- 新增 Registry.pluginChannels 台账：记录每个插件注册的 IO 通道
- 三条路径统一走 detachPlugin：Disable / ReloadOne / RemovePlugin
- StopAndUnload 漏了 IO 通道也一并补上
### 4. 自动重启
- onProcCrash 从「只发事件」改为「摘注册面 → 从注册表移除 → 异步排重启」
- scheduleProcRestart: 窗口 5 分钟内最多 3 次，线性退避 1s/2s/3s
- 超限停手留日志；重启前复核是否已被 Disable 或被其他路径加载
- 崩溃计数窗口过期自动归零
### 5. 主动停止 vs 崩溃的区分
- proc.Plugin 新增 stopping 标志：Stop()/Close() 里 Set(true)
- handleExit 读 stopping 标志，主动停止不上报 onCrash
- 防止重载/禁用/卸载被误判为崩溃触发多余重启
### 6. Linux Pdeathsig 兜底
- procattr_linux.go: SysProcAttr.Pdeathsig = SIGKILL
- 兜 homed 自身被 SIGKILL/OOM 时子进程变孤儿的场景
- macOS/Windows 无等价物，空实现
### 7. pluginmgr 升级
- PluginManager 接口新增 PluginRuntime / ListPluginRuntimes
- plugin_list 输出运行态：loaded / alive / pid / crash_count / channel
- 新增 plugin_status: 全量运行期快照 + dead/unhealthy 汇总
- 新增 plugin_restart: 无条件重启单个插件（plgreload 不动未改二进制的插件）
### 测试
- process_test.go: 3 例（grandchild stdout 感知 / Supervisor track-untrack /
StopAll 无孤儿）
- crash_recovery_test.go: 8 例（detach 三项齐全 / 通道重注册 / 崩溃不阻塞 /
退避阈值 / 窗口过期 / 关停中跳过 / PluginRuntime 通道识别）
- stages_plugin_test.go: 4 例（stage 按插件摘除 / 空 stage 清理 / 空名 no-op /
工具+stage 双摘后可重新注册同名）
|
2026-09-03 12:37:58 +08:00 |
|
|
|
62bdfa2b54
|
meta: 内核版本升到 1.0.0；生产切换脚本改走 hmap 正规通道（Part 6.5）
## 版本号
1.0.0：外部插件从 C ABI 动态库迁到子进程 + 共享内存。首个不再加载
`.so`/`.dll` 的版本，与 0.9.x 不兼容（存量插件必须用新版 plugindev 重编）。
SDKCompatibleVersion 同步升 1.0.0。
同时删掉 ABIVersion / CABINum / 51 个 Core<Method> 整数 ID —— 随 Part 6.2
删 internal/plugin/cabi/ 就已无使用者（grep 确认只剩定义处）。留着会让人
以为 C 层协商还在生效，或以为加 method 要同步维护那张整数表。
⚠️ 注意 Makefile 的 `VERSION ?= $(shell git describe --tags --dirty)`：
实际注入值来自 git tag，meta.go 里的默认值只在不带 ldflags 时生效。
make build 当前注入 v0.9.1-56-g2572688-dirty。要让 1.0.0 真正生效需打
v1.0.0 tag 或显式传 VERSION=1.0.0。
## 生产切换脚本重写
第一版是手工拷 plugin.bin + 手改 plugin.json 的 entry —— 那等于**重新实现
了一遍 hmap 解包逻辑，且实现得更差**。漏掉的东西：
platforms 字段 hmap 内的 plugin.json 本来就写对了
平台二进制选择 我硬编码 _linux_amd64，正规路径用 platformBinary()
overwrite 语义 StopAndUnload 停旧实例但**保留配置表**
失败回滚 os.Rename 备份旧目录，解包失败自动恢复
校验 validatePackage 查 manifest + 各平台二进制齐全
配置保留那条尤其关键：生产 17 个插件都有配置（qq 账号、weather 默认城市、
browser profile 路径）。我的脚本恰好没碰配置表所以侥幸不丢，但那是运气
不是设计。
改为 POST 到 pluginmgr 的 HTTP 端点（127.0.0.1:9876/plugins），
传 {path, overwrite:true} 走 installFromPath → installFromData。
保留的一个设计：**先全部校验再动手**。任一插件缺 hmap 就整批中止——
新 homed 不认 .so，「一半装了一半没装」的中间态最难排查。
## 生产切换已执行
顺序（先换二进制再装包，而非反过来）：
1. systemctl stop homeagent
2. 换 /usr/local/bin/homed
3. 起服务 —— 15 个 .so 插件报可操作错误被跳过，homed 本体与 16 个内置正常
4. 逐个 POST 装 17 个 hmap（overwrite=true）
5. 待重启核对
第 3 步顺带在真实二进制上验证了 Part 6.2 的可操作错误：
[plugin] dynamic weather: 检测到旧 C ABI 产物（plugin.so/.dll/.dylib）。
外部插件已改为子进程模式，请用新版 plugindev 重编产出 plugin.bin
（业务代码无需修改）
不崩溃，只跳过。若反过来先装包，旧 homed 的 StopAndUnload 会停掉 qq
消息通道且无法重载 .bin，会卡在「插件全挂」的状态。
结果：17/17 成功，全部 config_kept=true；0 个残留 .so；17 个 plugin.bin
均有执行位；17 个 manifest 的 entry 均为 plugin.bin；无 .bak 残留。
bundle 包正确挑了当前平台（weather 目录只留 8.7MB 的 linux/amd64 那份）。
备份：/home/newqqagent-migration-backup-20260902-214812
（plugins 全目录 + homed.old + homeagent.service，162MB）
验证：go build ./... 通过；go test ./... 全仓无失败。
Ref: docs/zh/plugin-migration-plan.md Part 6.5
|
2026-09-02 22:40:47 +08:00 |
|
|
|
2572688c51
|
proc: 性能基准 + 流式压测（Part 6.6 验收项）
此前只做了功能冒烟与内存快照，延迟与压测都没测。这两项是计划里
明确列出的验收条件，补上。
## 基准结果（AMD Ryzen 7 7840HS）
| 项目 | 实测 | 基线 |
|---|---|---|
| 工具调用 RPC 往返 | 24.1 µs | 实验 11: 19.6 µs（同量级） |
| 锁仲裁（内核侧） | 0.76 µs | 见下注 |
| 事件环写入 | 95 ns | — |
| 事件环并发写入 | 83 ns | 无锁竞争恶化 |
| 完整 stage 往返 | 132 µs | 含 3 次进程间往返 |
| 共享段编解码 | 3.7 µs | 占 stage 的 2.8% |
**锁仲裁 0.76µs 不可与实验 3 的 19.40µs 对照**——测的不是同一个东西：
实验 3 测插件经 RPC 请求锁的完整跨进程往返，本基准只测内核侧
lockRegistry.acquire/release。真实成本仍在 20µs 量级。
基准原名 BenchmarkStageLockRoundTrip 有误导性，已改为
BenchmarkStageLockArbitration，并在注释里写明不可对照的理由——
否则日后有人拿 0.76µs 去比 19.4µs 会得出「优化了 25 倍」的错误结论。
**stage 往返 132µs 的成本构成**：共享段编解码只占 3.7µs，其余是
一次 stage 要走 3 次进程间往返（stage.invoke + 插件侧反向的
stage.lock / stage.unlock）。相对 LLM 往返 2-8 秒可忽略；要优化的方向是
把 lock/unlock 合入 stage.invoke 的请求/应答，省掉两次往返。
## 流式压测：§4.3 标记「风险高」的那一项通过
原文担忧：「Bus.Publish 路径禁用任何锁/阻塞——流式输出逐 token 发布，
任何等待都会卡顿」。事件环是 Part 5 新加在这条路径上的，必须验。
```
5000 次 Publish + 每条睡 20µs 的慢消费者
实测 2.29ms，均摊 457 ns/token
同步语义理论下限 100ms
订阅者 1 个：1.547ms（515 ns/次）
订阅者 8 个：1.518ms（506 ns/次） ← 无线性恶化
环溢出（无消费者写 30000 次，cap=8192）：均摊 35 ns/次 ← 仍 O(1)
```
2.29ms 与实验 4 的数字完全一致（那次也是 2.29ms / 0.46µs per token），
post-and-forget 在实现中成立。
第三项的意义：消费者完全停摆时写端覆盖最旧 slot，这条路径仍是 O(1)，
故「消费者卡住」不会连带拖慢内核主循环。
Ref: docs/zh/plugin-migration-plan.md Part 6.6、docs/zh/架构迁移评估.md §4.3
|
2026-09-02 21:42:18 +08:00 |
|
|
|
2ebdb9a5b7
|
plugin: 权限梯度显式化（Part 6.4）
迁移前，「外部插件拿不到 Selftest/Supervisor/Tracker」是 C ABI 表达能力的
**意外产物**——C 结构体不好传函数指针，这些能力自然到不了插件侧。那是运气
不是策略：任何人给 dispatch 加个 case 就能捅穿。
现在变成显式声明并强制，分三道闸：
1. **类型层**（proc_core.go，Part 6.2 已落地）：procCore 用命名字段持有
内核 SDK 而非嵌入，未在收窄面写出的方法编译期就不存在。
2. **能力集**（新增 capability.go）：54 个 plugin→kernel method 划入 11 个
capability 组，manifest 未声明的组被拒。
3. **RPC 边界**（corehandler.Handle 入口）：被拒时返回**明确错误**而非
静默忽略。
第 3 条针对一类真实故障：C ABI 时代 case 23/24（事件订阅）是空实现，
返回成功但永远收不到事件（§1.3 的「给不了」而非「不给」），插件作者无从得知。
错误消息含四要素：哪个插件、哪个调用、缺什么能力、在哪声明。
## 能力划分的两个判断
**粒度按能力域而非单 method**。逐 method 授权看似更精细，但插件作者要在
manifest 里列 60 个名字，且内核每加 method 所有 manifest 都得改。
**空声明 = 不受限，而非「只有 core」**。17 个存量插件的 plugin.json 都没有
capabilities 字段。若空声明当作最小权限，它们会全部失去 IO 注入、记忆读写
而**静默降级**——违反「外部插件零改动」的硬约束。收紧的路径是让插件显式
声明，而不是默默拒绝老插件。
## core 与受限能力的边界
core（无需声明，始终可用）：注册自身工具/阶段/通道/API、读写**自己的**配置、
共享段锁仲裁、握手、autoRestart 自述、setToolBlocks。没有这些插件无法工作。
受限（需声明）：io / memory / doc_memory / knowledge / text_memory / llm /
social / events / plugin_mgr / settings_cross。
settings 刻意拆成两级：读写自己的配置属 core（正常工作所需），读写**其他插件**
配置或**内核核心**配置属 settings_cross（能改别人/内核的行为）。
## withheldCapabilities：让「不给」可见
10 项刻意不提供的内核内部机制列在表里并附理由。它们没有对应 method 常量——
不是忘了加，是决定不加。列表存在本身就是「这是策略而非疏漏」的证据，
读代码的人能看到边界在哪，而不是从「protocol.go 里没有」这个负面事实去推断。
## 测试
proc 包 10 项：
- AllMethodsClassified：**最重要的一项**。漏登记的 method 会按 CapCore 放行，
等于绕过整套检查。新增 method 忘登记时当场报出。
- EmptyDeclarationIsUnrestricted / DeclaredSetRestrictsOthers / CoreAlwaysAllowed
- SettingsScopeSeparation：自身配置 vs 跨插件配置的归属
- DeniedErrorIsActionable：错误消息四要素
- HandleEnforcesAtRPCBoundary：被拒的调用不进 switch
- WithheldListIsDocumented：每项都有理由，且不被任何 method 暴露
- UnknownMethodFallsThrough：未知 method 报「未知」而非「权限被拒」，
否则作者会以为是漏声明能力
写这个测试时踩到自己的坑：第一版用子串匹配查 withheld 泄漏，"Tool" 匹配到
tool.register 和 io.setToolBlocks 误报——那两个是合法开放的（注册自己的工具）。
改成前缀 + unregister 关键字匹配，withheld 项也改名带 API 后缀以示区分。
internal/plugins 2 项接线验证：
- RestrictedPluginStillLoads：只声明 io 的 weather 仍能加载并注册工具
（它在 Start 里读 Settings，属 core）
- LegacyManifestUnrestricted：无 capabilities 字段的存量插件正常加载
真实 homed 实测：
[plugin] weather-capped 声明能力: [io]
[plugin] weather-capped: 经 proc 通道加载（子进程）
registering tool: weather-capped_current / _forecast / _set_location
验证：go build ./... 通过；go test ./... 全仓无失败；
go test -race ./internal/plugin/... 全绿；go vet 干净。
Ref: docs/zh/架构迁移评估.md §3.8、docs/zh/plugin-migration-plan.md Part 6.4
|
2026-09-02 21:27:13 +08:00 |
|
