|
|
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 |
|
|
|
968b01f26e
|
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 07:26:10 +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 |
|
|
|
98dcb2556c
|
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:44:05 +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 |
|
|
|
5c214cac23
|
fix(packaging): arm64 GUI 塞了 x86-64 electron——按目标架构取运行时并强制校验
## 现象
v1.0.0 与 v1.0.1 的 arm64 full/client 包里，homed 与 waiter 都是正确的
aarch64，但 GUI 目录下的 electron 是 x86-64。实测从 gitcode 下载的
homeagent-full_1.0.1_arm64.deb：
usr/bin/homed ELF 64-bit ARM aarch64 ✓
usr/bin/waiter ELF 64-bit ARM aarch64 ✓
usr/lib/homeagent-gui/electron ELF 64-bit x86-64 ✗
在 arm64 机器上装完，双击 GUI 得到 Exec format error。
## 根因
build_gui 无条件 `cp -r "$gui_dir/node_modules/electron/dist"/*`，而那里
永远是 **host 架构**（本机 x64）。目录名 homeagent-gui-linux-arm64 只是
命名，内容从未跟着目标架构变。
这与 v1.0.0 arm64 缺 homed 是同一类错误：**产物名声称的架构与实际内容
不符**，且都因为没做交叉验证而漏过整个发布流程——包名对、目录名对、
主二进制对，只有一个嵌套的运行时是错的，没有任何一环会喊出来。
## 修法：三层取 + 一道强制校验
1. 优先从 electron 缓存取目标架构的 zip
（~/.cache/electron/<hash>/electron-v<ver>-linux-<arch>.zip）。
版本号从已安装的 node_modules/electron/package.json 读，保证运行时
与 app 依赖一致。
2. 回退到 host node_modules/electron/dist 前**先比对架构**：只有目标
架构 == host 架构才允许；否则打印缺哪个 zip、该放哪里，然后跳过 GUI。
3. 最后用 `file -b` 校验 electron 二进制的实际架构必须匹配目标架构，
不符就删掉 GUI 目录并跳过。
第 3 步是关键。前两步是「尽量拿对的」，第 3 步是「绝不发错的」——
宁可不发 GUI，也不发装了跑不起来的包。`GUI built:` 日志行也加上架构
标注，日常构建就能看见。
## 验证
下载 arm64 electron 运行时（electron-v33.4.11-linux-arm64.zip，106MB，
unzip -t 无错，解出的 electron 确认为 ARM aarch64）放入缓存后重打包，
三个 arm64 deb 实测：
server homed=aarch64 waiter=aarch64
full homed=aarch64 waiter=aarch64 electron=aarch64
client waiter=aarch64 electron=aarch64
amd64 对照 electron=x86-64
arm64 tar.gz 从 120M 涨到 125M，也印证运行时换成了正确架构。
|
2026-09-04 20:12:35 +08:00 |
|
|
|
9b7b2675da
|
fix(packaging): arm64 GUI 塞了 x86-64 electron——按目标架构取运行时并强制校验
## 现象
v1.0.0 与 v1.0.1 的 arm64 full/client 包里，homed 与 waiter 都是正确的
aarch64，但 GUI 目录下的 electron 是 x86-64。实测从 gitcode 下载的
homeagent-full_1.0.1_arm64.deb：
usr/bin/homed ELF 64-bit ARM aarch64 ✓
usr/bin/waiter ELF 64-bit ARM aarch64 ✓
usr/lib/homeagent-gui/electron ELF 64-bit x86-64 ✗
在 arm64 机器上装完，双击 GUI 得到 Exec format error。
## 根因
build_gui 无条件 `cp -r "$gui_dir/node_modules/electron/dist"/*`，而那里
永远是 **host 架构**（本机 x64）。目录名 homeagent-gui-linux-arm64 只是
命名，内容从未跟着目标架构变。
这与 v1.0.0 arm64 缺 homed 是同一类错误：**产物名声称的架构与实际内容
不符**，且都因为没做交叉验证而漏过整个发布流程——包名对、目录名对、
主二进制对，只有一个嵌套的运行时是错的，没有任何一环会喊出来。
## 修法：三层取 + 一道强制校验
1. 优先从 electron 缓存取目标架构的 zip
（~/.cache/electron/<hash>/electron-v<ver>-linux-<arch>.zip）。
版本号从已安装的 node_modules/electron/package.json 读，保证运行时
与 app 依赖一致。
2. 回退到 host node_modules/electron/dist 前**先比对架构**：只有目标
架构 == host 架构才允许；否则打印缺哪个 zip、该放哪里，然后跳过 GUI。
3. 最后用 `file -b` 校验 electron 二进制的实际架构必须匹配目标架构，
不符就删掉 GUI 目录并跳过。
第 3 步是关键。前两步是「尽量拿对的」，第 3 步是「绝不发错的」——
宁可不发 GUI，也不发装了跑不起来的包。`GUI built:` 日志行也加上架构
标注，日常构建就能看见。
## 验证
下载 arm64 electron 运行时（electron-v33.4.11-linux-arm64.zip，106MB，
unzip -t 无错，解出的 electron 确认为 ARM aarch64）放入缓存后重打包，
三个 arm64 deb 实测：
server homed=aarch64 waiter=aarch64
full homed=aarch64 waiter=aarch64 electron=aarch64
client waiter=aarch64 electron=aarch64
amd64 对照 electron=x86-64
arm64 tar.gz 从 120M 涨到 125M，也印证运行时换成了正确架构。
|
2026-09-04 20:12:35 +08:00 |
|
|
|
e2d04a31a7
|
docs(git): 发布分支改为一个中版本一条，补三级发布通道规范
## 一个中版本一条发布分支
原规范写 release/vX.Y.Z（含 patch 位），实践中 1.0.0 与 1.0.1 各建了一条
分支，导致同一条 1.0.x 发布线被切成互不相连的碎片——追溯时无法用一条
分支看完整条线的演进。改为 release/vX.Y.x，patch 位用 x 占位，
承载该中版本全部 patch 直到下一条中版本分支切出。
## 三级发布通道（alpha / beta / 正式）
通道由 tag 区分而非分支：三者共用同一条 release/vX.Y.x。
alpha vX.Y.Z-alpha.N 功能齐了未充分验证 仅内部自测
beta vX.Y.Z-beta.N alpha 问题已修 小范围试用
正式 vX.Y.Z 通过验证可上现网 所有用户
这是 semver 标准预发布语义（1.1.0-alpha.1 < 1.1.0-beta.1 < 1.1.0），
版本比较逻辑天然认得，无需额外约定。允许跳级但要在发布说明写明理由；
alpha/beta 产物不上现网——预发布通道的存在就是为了不拿 24/7 服务冒险。
## 回流仍是 cherry-pick
明确不改 merge：merge 会把已发布的版本号带进 main，与「main 的
meta.Version 始终是下一个未发布版本」直接矛盾。
新补一条：修复落地当天要 pick 到所有活跃 feature 分支，否则它们合回
main 时可能带回旧代码（2026-09-04 的 stage 双重解锁修复即同时 pick 到
main 与 feature/memory-media）。
## 运维纪律沉淀
把今天走通的部署流程写进第四节，其中两条是踩过的坑：
- 备份配置库用 sqlite3 .backup 而非 cp（WAL 模式下 cp 可能拿到
不一致快照）
- install -m 0755 替换而非 cp（原子 rename，不写坏运行中的进程镜像）
健康检查列出六项，含「一次真实对话」与「fatal error 计数为 0」。
## 当前分支对齐
第三节更新为 2026-09-04 的实际状态，并记录 1.0.x 的 tag 历史表
（含 v1.0.2 未使用的原因、v1.0.3 直接跳正式 tag 的理由）。
按 patch 号命名的历史发布分支标注为应当删除的遗留形态。
|
2026-09-04 20:11:19 +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 |
|
|
|
e272c686d3
|
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:43:05 +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 |
|
|
|
6bf34e051b
|
fix(release): upload_assets.py 按 go.mod 定位仓库根，不再数 dirname
脚本从 scripts/ 移到 deploy/scripts/ 后目录深度 1→2，而两层 dirname
是写死的，于是资产目录解析成 deploy/dist/release，上传直接
FileNotFoundError（v1.0.1 首次上传即因此失败）。
这与 v0.7.2 的 2c5f9ff 把 package/ 移到 deploy/packaging/ 打断
build.sh 的 PROJECT_ROOT 是同一个坑：目录搬家没更新相对路径。改成
向上找 go.mod，以后脚本放哪都不会错。
顺带把两个静默失败改为显式报错：目录不存在、目录下无可识别产物
（原先前者抛裸 FileNotFoundError，后者会打出 ALL OK 却一个都没传）。
|
2026-09-04 10:34:51 +08:00 |
|
|
|
4f31f942a5
|
fix(build): arm64 交叉编译补 CXX——「刻意不设 CXX」的注释判断是错的
build.sh 的 linux/arm64 分支此前刻意不设 CXX，注释理由是「设了会让
Go 用 aarch64 的 g++ 去链接，而它对 host 产生的 .o 报 file format
not recognized」。
那个判断是错的。那个报错的真因是 cmd/{homed,waiter}/*.syso（x86-64
COFF Windows 资源对象）被 Go 无条件链进了目标，与 CXX 无关。四组对照：
syso 在 + 无 CXX → Relocations in generic ELF (EM: 183)
syso 在 + 有 CXX → 000000.o: file format not recognized
syso 隐藏 + 无 CXX → Relocations in generic ELF (EM: 183)
syso 隐藏 + 有 CXX → 成功，ELF aarch64
两个条件缺一不可。之前诊断时只单独试了其中一个，得出错误结论后写进
注释固化了下来，于是 arm64 的 homed 一直编不出（v1.0.0 发布时 arm64
deb 里只有 waiter/initconfig）。
本脚本的 hide_syso_for_target 已处理 syso 那半，这里补上 CXX 那半。
实测 v1.0.1：build.sh linux/arm64 直接产出 ELF aarch64，arm64 的
full/server deb 里 homed 与 waiter 均为 aarch64。
|
2026-09-04 10:24:55 +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 |
|
|
|
9b92a04230
|
docs: 文档与发布脚本同步到 v1.0.0 子进程架构
README/架构文档仍在描述 C ABI 动态库加载，与 v1.0.0 实际实现不符。
新用户按文档走会去做 -buildmode=c-shared，产物新内核根本不加载。
README.md / README_EN.md：
- 设计要点补子进程架构段（三面通信、崩溃自愈、真热重载）
- 代码结构 plugin/ 描述：.so 动态加载器 → 子进程加载器
- 项目状态补 v1.0.0 条目（6 类缺陷 + 实测数字），v0.9.0 标注 ABI 已退场
- 新增「下载」章节：三变体对照 + 各平台包格式 + macOS 限制
assets/docs/{zh,en}/ARCHITECTURE.md：
- 四种加载方式表：外部 .so/C ABI → 外部子进程/握手+stdio JSON-RPC
- 加载流程改写为 exec.Command → 继承 fd → 握手 → init → start
- 内置 vs 外部对照表 7 行更新
- 新增「子进程插件的三个通信面」小节，含每个面的选择理由
assets/docs/{zh,en}/OVERVIEW.md：插件系统段落改写
deploy/ 发布脚本三处回归（v0.7.2 的 2c5f9ff 把 package/ 移到
deploy/packaging/ 使目录深度 1→2，但没改相对路径，此后两个版本
的发布都没有二进制资产）：
- build.sh：.syso 按目标平台 hide/restore（trap 兜底），恢复
windows 目标的 CXX，arm64 刻意不带 CXX
- installer.nsi：5 处 ..\build → ..\..\build，PRODUCT_VERSION 可注入
（原先硬编码 0.8.0）
- homeagent.spec：server 变体补装 waiter（control-server 声明了 CLI 却没装）
deploy/scripts/upload_assets.py：release 资产上传（两步签名 URL → OBS
PUT）。放 deploy/scripts/ 而非 scripts/，因为后者在 .gitignore 里。
支持 GITCODE_REPO/ASSET_DIR 环境变量以复用于 SDK 仓。
v1.0.0
|
2026-09-03 19:26:17 +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 |
|
|
|
525aa1f943
|
Merge branch 'feature/plugin-proc-migration' into main
插件架构子进程化迁移（8-9 周）+ 崩溃自愈收尾。
## 消除的 6 类 C ABI 前提缺陷（对照 plan.md §11.0）
| 缺陷 | 原状 | 现状 |
|---|---|---|
| 热重载失效 | DF_1_NODELETE 让 dlclose 成 no-op | 换 plugin.bin 即生效 |
| 崩溃隔离缺失 | 插件 panic 带崩 homed | 子进程独立崩溃 + 自动重启 |
| stage lost update | 副本模型互相覆盖 35.8~36.8% | 共享内存段，0% |
| cgo 超时泄漏 | 现网泄漏 26 次线程 | 整套架构零 cgo，Kill 真取消 |
| output_send 假成功 | 永远返回 queued+nil | RPC 同步等真实结果 |
| 能力断层 | Windows 只见 3 字段无写回 | 18 字段全可见可写回 |
## 架构
- 控制面：stdio JSON-RPC（51 个 core.* method）
- 数据面：共享内存段（全部子进程共用一块，避免退化成副本模型）
- 通知面：事件环 + 三平台通知（Linux eventfd / macOS pipe / Windows Event）
- 权限梯度显式化为三道闸：procCore 命名字段 + manifest 能力声明 + RPC 边界拒绝
- C ABI 通道整体删除（-3198 行）
## 子进程生命周期管理
- 每子进程专职 waitLoop（cmd.Wait 唯一调用点），不依赖 stdout EOF
- proc.Supervisor 集中台账，Host.Close 先 StopAll 再拆段
- 崩溃自愈：摘注册面（工具+stage+IO通道）→ 移除注册表 → 退避重启
- Linux Pdeathsig 兜底 homed 被强杀场景
## 门禁
make test 零失败 / go vet 无告警 / SDK 公开接口 diff 为空（接口冻结不变量）
|
2026-09-03 13:46:51 +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 |
|
|
|
351e99dd70
|
docs(plan): 第 12 节 —— 子进程化迁移剩余工作与目标效果
迁移主体已完成上生产（内核 v1.0.0，17 插件全部子进程化），
但有若干项未做完或未达成。写进 plan.md 而非只留在对话里，
避免下次接手时靠猜。
八个小节按「阻塞程度」排：
**12.1 合并到 main + 发布分支** —— 卡在四个决策点，非技术阻塞：
merge 方式（--no-ff vs squash）、是否删 feature 分支、release 构建是否
再替换生产二进制、SDK 仓是否同步。附完整执行序列。
记了一个易错点：v1.0.0 tag 当前打在 feature 分支中间点 670efcd，
按规范应在 release 分支上，需删除重打。
**12.2 验收清单两项未达成** —— 这两项在迁移计划里已如实标 ⚠️：
- SetToolBlocks 仍未实现。C ABI 时代也是空实现故不算回归，
但 §3.8 明确承诺过「二进制写入 arena + Slice 描述符回传」，没兑现。
- 内存 88MB 远超「基线 +29MB」。根因是每插件静态链接整个 Go runtime，
15 个不同二进制无共同物理页（PSS/RSS 99.9% vs 基线 44%）。
基线用 2.68MB 最小插件复制 17 份，绝对数字本就不可比。
**12.3 事件环零真实负载检验** —— 机制完成、压测通过（2.29ms 与实验 4
一致），但 grep 确认无任何插件使用 Events().Subscribe。压测是我构造的
负载，生产上这条路径从未被真实插件走过。只写 ✅ 会掩盖这一点。
**12.4 三套 ABI 只收敛两套** —— C ABI 删了、Windows DLL 收敛了，
Lua 仍走独立解释器路径。§9.2 那句「三套收敛为单一 RPC」本轮兑现 2/3。
不阻塞是因为 Lua 不经 C ABI，不属于要消除的 6 类缺陷。
**12.5 Windows 无真机验证** —— 只做了交叉编译 + 单元测试。
已知语义差异（Event 是二元信号非计数器）推理上不影响正确性，
但没在真机确认过。§9.2 声称 Windows「从受害者变受益方」缺实证。
**12.6 stage 往返省两次 IPC** —— 132µs 里编解码只占 3.7µs，
其余是 3 次进程往返（invoke + 插件侧反向 lock/unlock）。合并后预期
降到 ~30µs。风险是锁持有时机改变，插件若在 handler 里再请求锁会死锁。
**12.7 遗留项** —— homed 主 heap 2.36GB（与插件无关）、鸿蒙端未提交改动。
**12.8 已达成目标留档** —— 6 类缺陷逐条对账，每条附证据
（测试名或生产日志），便于日后确认哪些是真解决了。
|
2026-09-03 08:50:48 +08:00 |
|
|
|
12259ed4ec
|
chore: 修 .gitignore 误伤源码目录（4 类，28 个已跟踪文件）
`git ls-files | xargs -n1 git check-ignore --no-index` 查出 49 个已跟踪
源码文件落在 ignore 规则下。它们现在能提交只是因为「已跟踪文件不受
.gitignore 影响」这条 git 规则在兜着——**新增文件会默默不入库**。
## 根因一：缺前导斜杠（28 个文件）
`knowledge/` / `memory/` / `scripts/` 不带前导斜杠，git 把它们当作
「任意层级的同名目录」：
memory/ → 吞掉 internal/memory/ 24 个文件
knowledge/ → 吞掉 internal/knowledge/ 3 个文件
assets/knowledge/
scripts/ → 吞掉 deploy/scripts/ 1 个文件
本意只是忽略根级运行时数据目录。旁边的 `/adapters/` 就写对了，
这三条是漏了斜杠。
修法：补 `/` 前缀。验证两侧行为：
根级 knowledge/y.md memory/z.db scripts/tmp.sh 仍被忽略 ✓
深层 internal/memory/new.go internal/knowledge/new.go
deploy/scripts/new.sh 可入库 ✓
## 根因二：internal/meta/ 整目录被忽略（1 个文件）
引入于 1f1233b（2026-07-12），同批还有 `.go/`、`.local/`、
`internal/plugins/openclaw/{manager,pysimulator}/`（后两个目录现已不存在）。
`internal/meta/meta.go` 是内核版本号与元数据的唯一数据源，本轮升 1.0.0 时
`git add` 报「paths are ignored」，就是这条。已跟踪所以改动能提交，
但新增 meta 文件会丢。直接删掉这条规则。
## 保留的 20 项不是缺陷
`third_party/homeagent-sdk/example/` 下 20 个已跟踪文件（plg.json +
plugin.go）仍在规则覆盖下，这是**有意的**：外部插件维护在独立 SDK 仓
（决策 sdk_repo_only），主仓只需要这 20 个源码文件参与构建，不要 SDK 仓的
main.go/go.mod/go.sum。删掉该规则会让 60+ 个文件涌进主仓——实测确认过。
已在两处 ignore 段落写明理由，避免后来人「修」错方向。
验证：修复后 check-ignore 扫描从 49 降到 20（全部是有意保留的 example/）；
go build ./... 通过。
|
2026-09-03 08:39:23 +08:00 |
|
|
|
2a03a83ce0
|
docs: Part 6.6 文档收尾 —— 迁移计划/接口矩阵/PLUGIN_DEV 全量更新
## plugin-migration-plan.md
Part 6 标记完成，并**记录实际执行与计划的偏离**而非假装一致：
原计划「逐插件迁移，随时回退」。用户决策改为彻底舍弃 .so、无回退通道，
本轮直接删 internal/plugin/cabi/。因此【V】的「.so ↔ .bin 混跑集群冒烟」
不再适用——新内核根本不认 .so。改为验证「新内核面对旧 .so 给可操作错误
且不崩溃」，已在真实二进制上确认。
最终验收清单加「结果」列，13 项逐项对账。**两项未完全达标，如实标注**：
- #9 SetToolBlocks：method 已定义并划入 CapCore，但内核侧仍返回未实现。
C ABI 时代它也是空实现（§1.4），故不是回归，但也没兑现 §3.8 的承诺。
- #13 内存：15 进程 RSS=88.0MB，远超「基线 +29MB」。根因是每插件静态链接
整个 Go runtime，15 个不同二进制无共同物理页（PSS/RSS 99.9% vs 基线 44%）。
实验 5 基线用的是 2.68MB 最小插件，绝对数字不可比；结构性指标
（均摊线程 5.5 vs 4.9）同量级。
新增两节实录：Part 6.5 生产切换（执行顺序为何不能反过来、hmap 正规通道
vs 手工拷贝的对照表、真实 QQ 消息的端到端证据链）与 Part 6.6 压测数据。
## plugin-interface-matrix.md
状态从「基线 v1」升为「完成 v2」。三个合同面逐一标注达成情况：
- 合同面 B：51 个整数 method id 已平移为 Method* 字符串常量。保留原表作
历史对照，但注明 case 25（CoreFreeString）无对应 method（内存管理是 C 层
特有问题），以及 io.setToolBlocks 已定义但内核侧未实现。
- 合同面 C：C1 标题从「今天」改为「迁移前」（迁移已完成，「今天」会误导）；
C2 补上「全部插件共享同一块 memfd」这个关键决定及其理由——第一版设计
是每插件一段，那会退化成副本模型复现 lost update。
- 第六节「新获得的能力」加「实际结果」列。事件订阅标注机制已完成但
零用户使用，故未经真实负载检验——这比只写 ✅ 诚实。
「刻意不给」清单同步为带 API 后缀的新命名（SelftestAPI 等），与
capability.go 的 withheldCapabilities 对齐，并说明为何加后缀：
不加时子串匹配会把 tool.register / io.setToolBlocks 误判为泄漏 ToolAPI。
## PLUGIN_DEV.md（中英双份）
C ABI 时代的描述全部改掉：
- 「动态 .so/.dll 插件」→「子进程插件」
- 「生成 C ABI bridge（z_bridge_gen.go + z_entry.c）」→ 子进程运行时三文件
- 「go build -buildmode=c-shared」→「go build（CGO_ENABLED=0）」
- 平台二进制表：三平台统一 plugin.bin（bundle 包内按 goos.goarch 区分）
- 「不能跨 C ABI 边界序列化」→「不能跨进程序列化」
- 「ABI v2 写回」→「Stage 写回」
新增 v1.0.0 破坏性变更提示框，五条要点：.so 不再加载、业务代码不需改、
entry 字段对 Go 插件已无意义、不再需要 cgo、Windows 从 3 字段升到全字段。
保留 .so 字样的只有变更说明本身（3 处），其余全部清理。
|
2026-09-03 08:12:30 +08:00 |
|
|
|
670efcd426
|
sdk: 同步 SDK 仓 meta 到 1.0.0（vendored 侧）
SDK 仓的 5ed8d65 在主仓这边的对应提交。主仓经 replace 引用
third_party/homeagent-sdk，其 sdk/ 与 meta/ 由主仓一并跟踪
（只有 example/ 与 tools/ 被 .gitignore 忽略）。
|
2026-09-02 23:02:26 +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 |
|
|
|
1d7f011e5d
|
plugin: 17 插件全量重编 + 端到端冒烟验证（Part 6.3）
## 17 个插件源码零改动，全部重编为 plugin.bin
16 个 × 3 平台（linux/darwin/windows），qq 1 平台（plg.json 自己声明
bundle:false）。luademo 走 Lua 解释器不适用。
git status example/ 无输出 —— 这是「业务代码零改动」的硬证据。
批 3 那些预估高风险的插件（qq 2686 行双向通道、browser 12 工具 +
InjectInterruptText、a2a/acp 的 InjectInputSync 同步注入）一次全过，
因为它们只碰公开 SDK 合同面，而合同面在 Part 2 已 51 个 method 全量平移。
唯一一次失败与迁移无关：rss 的 github.com/mmcdole/gofeed 不在本地模块
缓存且 proxy.golang.org 不通，换 GOPROXY=https://goproxy.cn 后通过。
## 真实 homed 加载验证
15 个外部插件全部经 proc 通道建链（protocol=1 sdk=0.9.2，各自独立 PID），
31 个插件 loaded（15 外部 + 16 内置）。
ai_image / files 未走 proc 通道：同名内置插件优先（工厂编译期注册），
外部插件被遮蔽。这是既有行为，与迁移无关。
事件环与共享段均正常创建，且共享段是**一块** 256KB 服务全部 15 个插件。
## 冒烟测试 4 项（internal/plugins/real_plugin_smoke_test.go）
用真实 example 产物而非 testdata 假插件；manifest 刻意写 "entry":"plugin.so"
验证工具链与内核都已不看 entry 值。未重编时 skip 而非 fail。
- ToolInvokeRoundTrip：工具真实调用往返（此前只验证到"注册"）。
weather_current 返回结构化参数校验错误——这恰是链路通的证据。
- StageRewriteTakesEffect：sanitizer 清洗 ANSI 序列，改写经共享段回到
内核 StageContext
- MultiPluginShareOneSegment：sanitizer + weather 并发，清洗结果不被覆盖
- CrashDoesNotKillKernel：SIGKILL 插件进程后 homed 存活、17 插件仍在
（对比 C ABI 下插件 panic 直接带崩 homed，§1.2 现网已发生）
## 开销实测与基线偏差
15 个插件进程 RSS=88.0MB PSS=87.9MB 线程=82，均摊 5.87MB / 5.5 线程。
RSS 88MB vs 实验 5 基线 29.1MB **不是回归，是基线不可比**：实验 5 用
2.68MB 最小插件，真实插件 3.1~14.8MB。可比的结构性指标：
- 均摊线程 5.5 vs 4.9 —— 同量级，无线程膨胀
- PSS/RSS 99.9% vs 44% —— **明显差于基线**
第二项是真实发现：基线里 PSS 远低于 RSS 说明 Go runtime 只读代码页在
进程间共享；实测几乎不共享，因为 15 个插件是 15 个不同的二进制，没有
共同物理页可映射。这是「每插件独立二进制」的固有代价，意味着实际内存
开销高于 §4.3 的乐观估计。压这一项的方向是共享 launcher 二进制。
## 工具脚本入 experiments/19-migration-verify
scripts/ 被 .gitignore 排除，故放到已跟踪的 experiments 目录下，
与 01~18 的可复跑实验并列。
measure-plugin-overhead.sh 第一版有统计口径 bug：RSS 读 status 的 VmRSS、
PSS 读 smaps_rollup 的 Pss，输出 PSS(87.9MB) > RSS(69.1MB) —— 物理上不可能。
两者对共享内存段计入方式不同（smaps 的 Rss 含 Pss_Shmem）。已统一从
smaps_rollup 读。另修 bc 不可用导致 MB 全显示 0.0（改用 awk）。
Ref: docs/zh/plugin-migration-plan.md Part 6.3、docs/zh/架构迁移评估.md §4.3
|
2026-09-02 20:20:25 +08:00 |
|
|
|
b20121f703
|
plugin: 删除 C ABI 通道（Part 6.2 完成，-3198 行）
外部插件统一走子进程 + stdio RPC，三套独立 ABI 实现收敛为单一 RPC 实现。
用户决策：彻底舍弃 .so 能力，不保留双通道回退。
## 删除清单
internal/plugin/cabi/ 1156 行（loader.go/loader.c/types.go/output_test.go）
internal/plugin/dynamic_dll_windows.go 272 行（§9.2 记录的能力退化实现）
internal/plugin/dynamic_loader_unix.go 79 行（唯一 cabi 引用点）
internal/plugin/dynamic_dll_test.go 32 行
internal/plugin/dynamic_dll_stub.go 11 行
internal/plugin/dynamic_loader_windows.go 11 行
internal/plugin/bridge_e2e_test.go （测的是 cabi 路径）
third_party/.../plugindev/templates.go 1296 行（取消跟踪，SDK 仓才是权威副本）
dynamic.go：entryCABI 通道删除，soEntry/dllEntry 常量删除。
registry.go：tryDynamic 探测顺序从 .so → .dll → .lua 变成 proc → lua。
## 旧 .so 给明确错误，不静默跳过
静默跳过会让「插件目录在但没加载」看起来像配置问题，而实际原因是需要
用新版 plugindev 重编。故保留 legacyCABIEntries 表专门用于识别残留：
plugin legacy: 检测到旧 C ABI 产物（plugin.so/.dll/.dylib）。
外部插件已改为子进程模式，请用新版 plugindev 重编产出 plugin.bin
（业务代码无需修改）
错误消息里「业务代码无需修改」这句是有测试守着的——迁移的核心承诺就是它。
## pluginmgr 安装逻辑跟进 bundle 命名
子进程模式下各平台产物统一叫 plugin.bin（进程边界即 ABI 边界），故 zip 内
按平台加后缀 plugin.bin.<goos>.<goarch>，解包时挑当前平台那一份重命名。
platformBinary 改为按 runtime.GOOS+GOARCH 生成条目名；platformBinaries 固定表
换成 isPlatformBinary 前缀判断（平台组合会增长：linux/arm64、darwin/arm64…，
按前缀判断无需维护清单）。
新增 chmod 0755：zip 保留了原权限位，但经某些工具链/传输后可能丢失，
内核加载时会因缺执行位报错。提前补上比事后让用户 chmod 更好。
## 测试
entry_dispatch_test.go 重写（12 项）：
- classifyEntry 对 .so/.dll/.dylib 现在返回 unknown
- LegacyManifestFallsBackToProbe：存量插件 manifest 仍写 "plugin.so"
（17 个插件没人去改），须靠目录探测找到 plugin.bin —— 这是
「外部插件零改动」的直接后果
- LegacyCABIGivesActionableError：错误消息须含 plugindev / plugin.bin / 业务代码
- PluginEntryHash_IgnoresLegacyCABI：.so 不参与 hash（内核已不认它）
upgrade_test.go 的 .hmap 构造改用 plugin.bin。
验证：go build ./... 通过；go test ./... 全仓无失败；
go test -race ./internal/plugin/... 全绿；三平台构建通过。
Ref: docs/zh/架构迁移评估.md §3.1/§9.2、docs/zh/plugin-migration-plan.md Part 6
|
2026-09-02 19:26:40 +08:00 |
|
|
|
d027c964e2
|
proc: Windows 共享内存 + 事件通知适配（Part 6.2 内核侧）
补齐内核侧的 Windows 创建端，与 6.1 的插件侧打开端配对。三平台
（linux/darwin/windows）现在都能构建 internal/plugin/proc。
## Windows 走命名内核对象（无 fd 继承语义）
os/exec 的 ExtraFiles 在 Windows 实现里不被支持，故：
- shmalloc_windows.go：CreateFileMappingW（INVALID_HANDLE_VALUE + 命名 →
系统页文件支撑的匿名段，不落盘）+ MapViewOfFile
- evtfd_windows.go：CreateEventW 命名 Event 对象 + SetEvent 通知
- shmpass_windows.go：把段名/对象名经环境变量注入子进程
（HOMEAGENT_SHM_STAGE / HOMEAGENT_SHM_EVTRING / HOMEAGENT_EVT_EVENT）
名字带 PID + 递增序号：多个 homed 实例并存时不能撞名。
Event 与 eventfd 的语义差异：Event 是二元信号，多次 SetEvent 只对应一次
唤醒，不累积。不影响正确性——消费者被唤醒后按 readSeq 追 writeSeq 批量
drain，丢的是"唤醒次数"不是"事件"；事件环本身就允许溢出丢弃并让消费者
知道丢了（dropped 计数），通知面从来不是可靠投递语义。
## 传递机制抽象为 shmpass_*.go
Plugin.Start 不再直接构造 ExtraFiles 列表，改为问 Host 要：
Env: p.host.procEnvForShm() // Windows 返回段名，Unix 返回 nil
ExtraFiles: p.host.procExtraFilesForShm() // Unix 返回 fd 列表，Windows 返回 nil
平台差异被收敛到这一对函数，Plugin/coreHandler/stage 全部平台无关。
## macOS pipe 生命周期修正
原实现只返回读端 fd，写端 *os.File 无人持有 → 可能被 GC 回收 →
读端收到 EOF 而非阻塞 → 消费循环变忙转。改为 pipePair 表同时持有两端，
evtfdClose 一并关闭。
## E2E 测试跟进模板拆分
模板从单文件拆成三个（主体 + unix/windows 挂载），测试需要一并落盘，
否则编译报 attachStageShm undefined。procRuntimeTemplates 表必须与
SDK 仓 proc_runtime.go 的 procRuntimeFiles 一致。
验证：三平台 go build ./internal/plugin/... 通过（gojieba 的 cgo 依赖
导致 internal/memory 在非 linux 失败，与本次无关）；
go test -race ./internal/plugin/... 全绿，含 2 项真实模板 E2E。
Ref: docs/zh/架构迁移评估.md §9.2、docs/zh/plugin-migration-plan.md Part 6
|
2026-09-02 19:07:14 +08:00 |
|
|
|
53a148cb54
|
docs: Part 5 标记核心已完成，进度快照更新事件环
Part 5 通知面内核侧 + 模板侧均已完成，端到端测试通过。
事件订阅从 C ABI 的空实现（case 23/24）变成真正可用。
测试数量更新：proc 38 项 + plugin 16 项（含 -race）。
下一步转 Part 6 逐插件迁移。
|
2026-09-02 17:07:43 +08:00 |
|
|
|
5bbfcc02fb
|
plugin: 事件环内核侧实现（§3.6 Part 5 核心）
事件环（EvtRing）是子进程首次获得事件订阅能力的基础设施。
此前 case 23/24 明确返回未实现，现在经事件环真正可用。
核心设计（§3.6，实验 4 已验证 post-and-forget 加速比 2218x）：
- 事件环放**独立共享段**（不与 StageContext 混放）：stage compact 会清 arena，
事件要独立于 stage 生命周期。Host 持有两块 memfd：fd 3 = StageContext，
fd 4 = 事件环段，fd 5 = eventfd。
- 无锁数据结构：内核 WritePush 追加写 slot，子进程 EvtConsumer 消费。
writeSeq 原子递增（Bus.Publish 并发调用），readSeq 每订阅者独立。
- eventfd 通知：Linux 用 unix.Eventfd（计数合并，1000 token 只唤醒几次），
macOS 用 os.Pipe（阻塞模式走 netpoller，只 park goroutine，实验 1 验证
200 等待者仅 +1 OS 线程）。两者行为一致：Read 阻塞直到有新事件。
- 溢出语义：落后超 cap 时跳到最新，丢弃计数记入 dropped（消费者知道丢了）。
不静默覆盖最旧（写端直接覆盖 slot，读端靠 seq 判断跳过）。
- 事件类型编码：pubsdk.EventType 字符串 ↔ uint32 位索引（编译时映射表），
typeMask 位掩码过滤（1<<idx）。
Host 改动：
- NewHost 同时创建事件环段和 eventfd（惰创建，一次分配）。
- Host 持有 evtSubscriber 接口（EvtRingSubscriber），由 Registry 注入
EventRing 实现——proc 包不依赖 internal/plugin（避免循环依赖）。
corehandler 改动：
- events.subscribe（原 case 23）：子进程传事件类型列表，coreHandler
通过 evtRing 接口调用 EvtRingSubscribe，注册到 Bus 上。
事件经 EventRing 写入环后由子进程 mmap 读取。
- events.unsubscribe（原 case 24）：当前由内核统一清理（子进程 Stop 时）。
Registry 改动：
- ensureProcHost 在创建 Host 后同时创建 EventRing（Bus → EvtRing → eventfd），
并通过 Host.SetEvtSubscriber 注入给 coreHandler。
测试 3 项：
- BasicWriteAndConsume：Host 创建 → EventRing 写入 → 消费者读到
- OverflowStillDelivers：写入超过 cap 后消费者仍能读到最新事件
- TypeMaskFiltering：typeMask 只订阅 tool_call，agent_output 被过滤
验证：go build ./... 通过；go test -race ./internal/plugin/... 全绿；
既有事件环测试 3/3 通过；proc 包测试未受影响。
Ref: docs/zh/架构迁移评估.md §3.6、docs/zh/plugin-migration-plan.md Part 5
|
2026-09-02 16:48:27 +08:00 |
|
|
|
4f14d0947f
|
docs: 更新迁移计划进度（Part 2/3/4 完成标记）
Part 2（子进程通道）、Part 3（plugindev .bin 构建）、Part 4（RunStage 接线）
标记为已完成，下一步转 Part 5 通知面。
记录两处与原计划的偏差及原因：
- Part 3 模板落地方式从 templates.go 的 raw string 换成真实 .go 源文件 +
//go:embed —— 900+ 行代码塞在字符串里写错只能等生成插件时才炸。
- Part 2 最初每插件一块共享段，等于副本模型换壳，已改为全部插件共享同一 memfd。
另记 lifecycle.autoRestart 缺口：公开 SDK 的 SetAutoRestart 是纯 setter
无 hook，隔着进程边界内核读不到，需模板在 Start 返回后显式上报。
|
2026-09-02 13:12:08 +08:00 |
|
|
|
11c1bbcebb
|
plugin: 子进程通道接通 registry（proc 通道端到端可运行）
Part 3 收尾。tryLoadProc 从桩位变成真实加载路径，plugin.bin 插件现在
经 registry 完整跑起来：spawn → 握手（共享段 fd 3）→ init/start →
反向注册 → 工具调用 → stage 共享内存读改写。
registry 侧：
- Registry 持有 procHost（惰性创建，**全部 .bin 插件共用一块段**）。
每插件一段会让「内核 ctx → 段 → 插件改 → 回读 ctx」在多插件下退化成
副本模型，lost update 原样复现（§8.4 实测 35.8~36.8%）。
- tryDynamic 分派到 Registry.loadProc；tryLoadProc 退为纯静态校验
（构造需要 Host，只有 Registry 有）。
- StopAll 在锁外释放共享段：插件还持有映射时拆段，它们下一次访问就是
SIGBUS；且持锁调用会与 onProcCrash 回调产生锁序风险。
- onProcCrash 把子进程退出转成 EventSystem 事件，不在回调里直接重载
（重载需 registry 锁，而回调可能来自持锁路径的 goroutine）。
proc_core.go —— 权限梯度的类型系统落点（§3.8）：
- procCore 用**命名字段**持有 *isdk.PluginSDK，不是嵌入。嵌入会提升全部
方法，外部插件就能经类型断言拿到 Supervisor/Tracker/Adapter/Indexer/
Status/Selftest。命名字段下只有显式写出的方法存在——权限梯度从
「C ABI 表达能力的意外产物」变成显式声明并强制的策略。
- 能力访问器把内部超集接口收窄到公开面（isdk.KnowledgeAPI 内嵌
pubsdk.KnowledgeAPI 再加 Stats/Remove，isdk.MemoryAPI 加 GraphData，
isdk.LLMAPI 加 Chat/ReloadFromConfig）；nil 保护避免类型化 nil 让
corehandler 的判空失效。
- procPluginAdapter 转接 Start(*isdk.PluginSDK) → Start(proc.CoreSDK)，
Close 对 closeDynamic 可见故重载能真 kill 子进程（对比 dlclose 对
Go c-shared 是 no-op，§1.1）。
共享段分配按平台拆分（原先 host.go 直接调 unix.MemfdCreate，darwin/windows
交叉编译失败）：Linux memfd；macOS 立即 unlink 的临时文件（无 memfd_create，
但语义一致：无残留、fd 可经 ExtraFiles 传递、子进程 mmap 同一 inode）；
其余平台明确报错而非静默降级成「无共享段」——那会让 stage 静默失去数据面。
测试 +13 项：
- e2e_template_test.go 用**真实 plugindev 模板**（而非 testdata 手写假插件）
编译插件跑全链路，验证「模板 ↔ 内核」协议/布局真的对齐，不只是内核自己
跟自己对齐。含 lifecycle.autoRestart 上报、工具调用、stage 读改写、
FinalText 回传（C ABI 下 after_toolcall 看不到此字段，§8.3 10→16）、
只读插件不覆盖改写插件。
- proc_load_test.go 验证 Host 唯一性/惰性、chmod +x 错误提示、
Close 可见性，以及 procCore 不暴露内核内部机制的断言。
验证：go build ./... 通过；go test -race ./internal/plugin/... 全绿；
全仓 go test 无新增失败；git diff third_party/homeagent-sdk/sdk/ 为空。
既有告警 cabi/loader.go:156 unsafe.Pointer 非本次引入。
Ref: docs/zh/架构迁移评估.md §3.3/§3.4/§3.8、docs/zh/plugin-migration-plan.md Part 3
|
2026-09-02 13:03:57 +08:00 |
|
|
|
82dcc86173
|
feat(proc): Plugin 加载器 + 51 method handler + RunStage 接共享段（Part 2 完成 / Part 4 闭环）
corehandler.go —— cabi/loader.go 51 个 case 体的整块平移（§3.2）:
- 参数从「s1/s2/s3 + i1/i2 五个固定槽」改为结构化 JSON，语义不变
- CoreSDK 接口刻意只含外部插件应得能力：无 Selftest/Supervisor/Tracker/
Status/Adapter/Config/Tool/Indexer/OutputChan/Publish
→ 权限梯度从「C ABI 表达能力的意外产物」变成「显式声明并强制的策略」（§3.8）
- 事件订阅(case 23/24)与 SetToolBlocks 明确返回未实现，不再像 C ABI 那样静默成功
（静默成功后收不到事件比报错更难排查）
- ToolDef.Cleaner / ChannelDef.Cleaner 是函数，跨进程置 nil（§3.5 回调型资源）
host.go —— 共享段所有权中心:
- ❗ 全部子进程插件共享**同一块 memfd**。若每插件一段，
「内核 ctx → 段 → 插件改 → 回读 ctx」在多插件下退化成副本模型，
最后回读者覆盖前者，§8.4 的 35.8~36.8% lost update 原样复现
- stageMu 串行化整次 stage 对段的独占（内核可能并发触发 RunStage）
- 首个进入者写入段，最后离开者回读 + Compact（此时无插件持锁，满足 §3.3 前提）
stage.go —— RunStage 接线（风险 3.4 落点）:
- 并发扇出保留（§0.2 第 1 条：并发扇出是原始设计，不是缺陷）
- 插件失败时 ForceReleaseLock，避免后续插件死锁（实验 9，无需 robust mutex）
plugin.go —— registry 可加载的插件实体:
- Start: spawn（fd 3 传共享段）→ 握手 → plugin.init → plugin.start
- Close: **真 kill + wait**，对比 cabi 的 Close 只做 dlclose 而后者是 no-op（§1.1）
- invokeOutput **同步等真实结果**，失败上报 error —— §9.4 根治
验证（34 项测试全绿，含 -race，全部用真实子进程）:
- 单插件 stage 读改写经共享段回到内核 StageContext
- sanitizer(改写) + weather(只读) 并发：清洗结果不被覆盖（现网场景）
- **5 个独立进程并发 append 同一 FinalText：5 个标记全部保留，零丢失零撕裂**
（实验 8 在真实 RPC + 真实 RunStage 下的复刻）
- 工具注册可调用 / 输出通道真实失败上报 / start 期间反向调用
- 未知 method 与未实现能力被拒绝 / stage 外加锁被拒绝
接口冻结: git diff third_party/homeagent-sdk/sdk/ 为空
|
2026-09-02 11:34:33 +08:00 |
|
|
|
d62430a71b
|
feat(proc): 子进程通道 —— RPC 协议 + 进程管理（Part 2 核心）
协议面（protocol.go，§3.2 method id 平移为 method 名）:
- NDJSON 帧，双向复用同一对 stdio；ID>0 需应答，ID==0 为通知(post-and-forget)
- 51 个 C ABI method id 全部平移为可读 method 名并标注原编号对照
编号本身扔掉——加能力不用改两边常量表，不再有 47 夹在 7 和 8 之间的痕迹
- case 25(CORE_FREE_STRING) 无对应 method：进程模型下各自 GC，概念消失
- case 23/24(事件订阅) 与 io.setToolBlocks 今日均为空实现「给不了」，
子进程下首次真正可给（§3.8 能力对齐）
- 新增 stage.lock/stage.unlock（C ABI 下不存在跨进程锁概念）
- StageInvokeParams 不含 StageContext 数据本身——数据在共享段，只带 stage 名 + seq
进程面（process.go，§2.3 保留现有生命周期机制）:
- Spawn: 启动 + 握手（协议版本不匹配显式拒绝，不半兼容运行）
- readLoop: NDJSON 分派应答/插件反向请求，1MB 单帧上限（大 payload 走 arena）
- CallContext: ctx 取消时立即返回**且清理 pending 条目**
对比 cgo：超时只让调用方返回，goroutine 永久卡在 C 调用里（现网泄漏 26 次）
- Notify: ID=0 不占 pending 表，满足约束 B（流式逐 token 发布不得等待消费者）
- markExited: EOF/退出 → 唤醒全部在途调用 → onExit 回调
这是「把 panic 捕获换成进程退出检测」的落点，plugin_health 逻辑完全复用
- Stop: plugin.stop → 宽限期 → 超时 Kill；Kill 后 OS 回收全部资源，零泄漏
- serveRequest 带 panic 隔离：内核 handler panic 不带崩 readLoop
验证（10 项，真实子进程而非 mock，含 -race）:
- 握手/工具调用/错误上报（插件失败调用方收到 error，非假成功）
- 插件反向调用内核（tool.register + settings.get 双向往返）
- **崩溃隔离**：插件 panic → 子进程 exit 2，内核存活、收到 onExit、在途调用不挂死
- 优雅停止 / **Kill 卡死插件**（ctx 超时返回 + pending 清零 + 资源回收）
- 通知不等应答（100 条 < 1s）/ 50 并发调用应答不串 / 协议版本不匹配拒绝
接口冻结: git diff third_party/homeagent-sdk/sdk/ 为空
|
2026-09-02 10:59:59 +08:00 |
|
|
|
bfa95ba320
|
docs(plan): Part 1 完成 + Part 4 核心完成标记，0.3/0.4 标记跳过
- Part 0.3/0.4 标记 ⏭️ 跳过并记录理由（子进程模型下问题整体消失，不给待删代码打补丁）
- Part 1 加载分派骨架 ✅ 完成（修改/审查/验证三步逐条勾选）
- Part 4 共享内存数据面 ✅ 核心完成（段/编解码/锁仲裁，RunStage 接线待 Part 2）
- 目录加进度快照
|
2026-09-02 10:43:40 +08:00 |
|
|
|
610e9d0bbb
|
feat(plugin): entry 双通道分派 + 共享内存 stage 数据面（Part 1 + Part 4 核心）
Part 1 加载分派骨架（迁移可逐插件推进、随时回退的前提）:
- dynamic.go: 新增 binEntry/skillEntry 常量 + entryKind 枚举 + classifyEntry/detectEntryKind
manifest entry 优先级最高（改回 plugin.so 即回退 cabi）；无 manifest 时按目录探测，.bin 优先
- registry.go: tryDynamic 按 entry 分派 proc/cabi 双通道；
entry 声明 .bin 但二进制缺失时报明确错误，不静默回退（否则'已迁移插件跑回旧通道'极难排查）
- registry.go: pluginEntryHash 候选顺序与 detectEntryKind 对齐（.bin 优先），
否则增量重载会用错文件算 hash
- dynamic_proc_{unix,windows}.go: tryLoadProc 桩位（权限/类型校验已实现，进程管理属 Part 2）
Part 4 共享内存数据面（迁移评估 §3.3/§3.4/§3.7，最关键一环）:
- proc/shm.go: 段布局（Header + ShmStageCtx 描述符数组 + append-only arena）
相对偏移设计——各进程 mmap 到不同虚拟地址仍能正确解引用
arena 用尽显式报错而非静默截断（§4.4 风险登记）；Compact() 回收 append-only 垃圾
- proc/shmcodec.go: StageContext 16 字段跨进程编解码
字段级描述符消除 lost update：只改 FinalText 的插件不触碰 ToolResults 描述符
WriteDirty 只写脏字段——只读插件零写入，不可能覆盖他人改写
Snapshot 存序列化字符串（切片共享底层数组的坑，C ABI 侧修 11.3 时已踩过）
Extra 4 键提升为具名字段；Response 用标志位表达 nil vs 空串
- proc/lock.go: 锁仲裁回归内核（§3.7 已裁定，零 cgo）
ForceRelease 实现实验 9 的崩溃自愈——排除 robust pthread_mutex 必要性
重复加锁显式拒绝（否则死锁 30s）；等待超时有补偿 goroutine 防锁泄漏
验证:
- proc 包 16 项测试全绿（含 -race）：全字段往返/只读零写回/原地改切片识别/
现网 sanitizer+weather 场景/5插件×40轮并发零丢失/arena 耗尽报错/压实不破坏字段/
锁互斥·串扰拒绝·崩溃自愈·临界区串行化
- entry 分派 9 项测试全绿；go build ./... exit 0；接口冻结 git diff sdk/ 为空
|
2026-09-02 10:41:18 +08:00 |
|
|
|
fe2fdc9692
|
docs: 固化当前分支对齐记录（update→feature/plugin-proc-migration）
|
2026-08-31 12:37:43 +08:00 |
|
|
|
69a138c1af
|
docs: Git 分支管理规范（main 长命 + feature/release/hotfix cherry-pick 流程)
- main 唯一长命、永远可部署；现网永远部署 release tag 构建
- feature/xxx 从 main 开出合回；release/vX.Y.Z 切出打 tag 构建
- hotfix 提交 release 分支 + 版本号分离提交，只 cherry-pick 修复回 main
- 明确'不需合并 release 回 main'（hotfix 已逐个 pick 回，避免冲突）
- 两仓（TrueAgent + homeagent-sdk）同用本规范
|
2026-08-31 12:36:44 +08:00 |
|
|
|
2e2602f437
|
docs(plan): Part 0.1/0.2 勾选 + 迁移计划进度标记
- plan.md 11.1 (3 checkbox)、11.3 (3 checkbox) 全部勾选
- plugin-migration-plan.md: 0.1/0.2 标记 ✅ 完成（含踩坑记录与待部署项）
|
2026-08-31 12:33:24 +08:00 |
|
|
|
9bb9cb3b1a
|
fix(cabi): applyStageResult 支持 diff 回传（plan 11.3 配套）
外部插件 bridge 模板改为只回传变更字段后（SDK 仓 5648519），内核侧配套：
- applyStageResult 的 tool_calls/tool_results 去掉 len(v)>0 拦截——改为键存在即应用，
使插件「清空全部工具调用」的显式回传 [] 能被表达（旧插件仅 len>0 才带键，不误清空）
- 逐字段应用，未回传的键保持原值（diff 语义：只改变更字段，不覆盖他人改写）
- output_test.go 新增 TestApplyStageResult_ClearedSlicesAreApplied / _OnlyPresentKeysApplied
验证: go build exit 0; go test ./internal/plugin/... ./internal/agent/... 全绿
|
2026-08-31 12:30:04 +08:00 |
|
|
|
b74ee15321
|
fix(cabi): output_send 等待真实发送结果，消除假成功（plan 11.1 / Part 0.1）
根因：CORE_REGISTER_OUTPUT_CH handler 无条件返回 {status:queued}+err=nil，
模型永远收到「已发送」，实际失败（如 meta 缺 user_id）只写日志，模型无法感知不会重试。
现网近 7 天成功 44 次、失败 2 次全部谎报成功。
改动：
- loader.go: 新增 awaitOutputResult（+可注入版 awaitOutputResultWith）+ outputSendTimeout=10s
goroutine 执行 cgo 发送 + 带超时 channel 等结果 → sent / error / unconfirmed 三态
handler 由 executeOutputSendTool 从 Go 侧调起，非 cgo 栈，不构成 cgo 嵌套
- output.go: executeOutputSendTool 识别 unconfirmed|queued，回报「发送结果未确认」而非「已发送」
- output_test.go: Success/Failure/Timeout 三用例
验证: go build exit 0; go test ./internal/plugin/... ./internal/agent/... 全绿
接口冻结: git diff third_party/homeagent-sdk/sdk/ 为空
|
2026-08-31 12:16:39 +08:00 |
|
|
|
8a1a7df406
|
docs(plugin-arch): 外部插件多进程化适配计划（修改→审查→验证三步微循环）
7 个 Part,每 Part 一个微循环:
- Part 0 脆弱基线先行(11.1/11.3/11.6,现网止血,不依赖迁移)
- Part 1 加载分派骨架(entry 双通道共存,可回退前提)
- Part 2 子进程通道原型(spawn/JSON-RPC/procPlugin,参考 sidecar.go)
- Part 3 plugindev 工具链改造(.bin 产物,SDK 仓)
- Part 4 共享内存数据面(StageContext 并发改写,最高风险)
- Part 5 通知面(EvtRing + eventfd,post-and-forget)
- Part 6 迁移收尾(17 插件 + 删 cabi + 权限显式化)
每 Part 含修改对象/审查要点/验证标准 + 13 项最终验收 + 风险回退表
|
2026-08-31 12:01:11 +08:00 |
|
|
|
fa99f6b4eb
|
docs(plugin-arch): 外部插件接口不变矩阵（多进程化整改基线 v1）
钉死「暴露给外部插件的接口不变」约束的合同面：
- 合同面A: 公开SDK类型/接口（sdk/plugin.go等，纯Go无cgo）
- 合同面B: bridge 51个method id ↔ SDK方法映射表（RPC平移清单）
- 合同面C: StageContext 跨ABI 10字段 → 共享内存16字段（能力扩展）
- 外部插件实测触达面 ⊆ 公开SDK合同面（接口不变成立的依据）
- 迁移后新获得能力/刻意不给项/检查点
|
2026-08-31 11:52:31 +08:00 |
|
|
|
304cad0648
|
docs(plugin-arch): 归档插件架构迁移评估 + plan 第11节整改计划
- docs/zh/架构迁移评估.md: C ABI→子进程+共享内存完整迁移论证(1621行)
- docs/zh/experiments/: 18项可复跑可行性实验(架构评估的所有数字来源)
- plan.md §11: 11.1~11.9 插件架构缺陷修复清单(唯一权威编号)
- main 保持干净,本批次为 update 特性分支的整改起点
|
2026-08-31 11:45:52 +08:00 |
|
