|
|
17e7094967
|
fix(plugins): 修三处端口/监听缺陷 + 让测试用临时端口（消除既有 flaky）
排查内核 SIGSEGV 时用 A/B 对照（我的树 20 轮 vs 干净树 20 轮）确认了
两条**既有** flaky，与 C 化改动无关。本提交把它们修掉。
## 缺陷 ①（真 bug，不只是测试卫生）：pluginmgr 监听地址是包级可变全局
`var HTTPAddr = "127.0.0.1:9876"` 是包级可变全局，`Start()` 还把 settings 读到的值
**反写**回它，`startHTTPServer` 再读它。后果：
- 多实例互相污染：后启动的实例把地址写进全局，先启动那个读到的是**别人的**地址
（实测与生产 homed 抢 9876）
- 全局读写无同步，属数据竞态
修法：改为实例字段 `p.httpAddr`（默认走 `const defaultHTTPAddr`），
不再有可被任意代码改写的包级状态；并新增 `HTTPURL()` 访问器。
## 缺陷 ②：remotedevice 用 ListenAndServe，监听失败静默且 :0 无法回报端口
`p.server = &http.Server{Addr: p.addr}` + `ListenAndServe()` 在后台 goroutine 里报错，
端口被占时只打一行日志、`Start()` 仍返回 nil —— 插件表面「已加载」而网关根本没跑。
且 `:0` 下拿不到真实端口。
修法：改为 `net.Listen` + `Serve`（与 webui/pluginmgr 同形）：
- 监听失败**同步**返回，交给加载器
- 用**实际绑定**地址回写 p.addr，日志与诊断面显示真实端口
## 测试侧：全部改用 :0，不再抢固定端口
新增 `ConfigRegistry.SetPluginConfig(name, key, value)`：插件表原本只在
`RegisterDef`（插件 Start 时）创建，导致「想在插件加载前预置配置」无从下手
（直接 Set 会因表不存在而失败，错误常被忽略）。新方法先建表再写，填补该时序缺口。
`setupIntegration` 在 `Load()` 前预置：
- pluginmgr.http_addr / remotedevice.listen_addr → `127.0.0.1:0`
- webui 走已有的 `SetListenOverride("127.0.0.1:0")`（它有独立旁路）
实测三个插件现在各自绑到 OS 分配的空闲端口（41895 / 35855 / 34021）。
## 缺陷 ③：deepsearch 测试把「上游限流」当成功能回归
`TestRealPlugin_DeepSearchInvoke` 的断言会在上游限流时失败，但插件此时返回的是
**正常结果**（err==nil，content 含 "未返回结果" 与无响应引擎列表）——那是外部条件。
实测失败信息：`brave(Suspended: too many requests), duckduckgo(CAPTCHA), google cse(...)`。
更糟的是它**不可控地随机红**：干净树连跑 20 轮复现 2 次，与代码改动无关。
这种判据会让真正的回归淹没在噪声里。
修法：区分「上游不可用（限流/CAPTCHA）⇒ t.Skip 并说明理由」与
「其他异常 ⇒ fail」。不用静默 return，避免环境退化时判据无声失效。
## 由此发现并修掉的真缺陷：监听地址被硬编码在三处
`127.0.0.1:9876` 曾硬编码在 pluginmgr / cli / webui 各一份。cli 与 webui 后来改为
运行时读 `pluginmgr.http_addr` 设置（本次核实），pluginmgr 自己却仍是全局 —— 三处
口径现在统一为「读设置 + 实例字段」。
## 验证
- 新增 `TestTwoInstances_ListenIndependently`（pluginmgr）：两个实例同时监听、
各自 HTTPURL 指向自己端口、两个地址都真的可连。
★ 经**忠实变异**验证有牙：复原「包级全局 + Start 反写 + 读全局」后该测试判红
（我第一版测试只断言字段不共享，变异证明它没牙，已重写为端到端判据）。
- `internal/plugins` 连跑 **30 轮：30/30 全过**（修复前干净树 18/20）。
- 全量连跑 3 轮：38 ok / 0 FAIL / 0 bind 冲突。
- go build ./... / go vet ./... 干净。
|
2026-09-25 17:57:15 +08:00 |
|
|
|
b4fb254bf5
|
fix(proc): 修 arena use-after-unmap 导致的内核 SIGSEGV（关停竞态）
## 症状
全量 go test 偶发 SIGSEGV，整个测试二进制被杀（recover 捕不到 runtime
致命错误）。崩溃栈（2026-09-25 实测捕获，完整）：
readLoop (process.go:334)
→ markExited → once.Do
→ onExit → Plugin.handleExit (plugin.go:209)
→ Host.ReclaimOwner (host.go:342)
→ arenaRegion.ReclaimOwner → blockBase → getU32
→ SIGSEGV 读已 munmap 的内存
## 根因（两个叠加缺陷，同一后果）
**① markExited 里 close(exited) 早于 onExit**
close(p.exited) // :394 —— 先关闭，唤醒所有等待者
p.sup.untrack(p.name)
p.onExit(...) // :399 —— 回调里要读共享内存
onExit（内核侧 Plugin.handleExit）会调 Host.ReclaimOwner 回收该插件残留的
共享槽，那是要读共享内存区域的。而 exited 一关闭，Stop()/Kill() 就返回
（process.go:566/587），StopAll 随即返回，调用方（Host.Close）立刻
freeShm 解除映射 —— 此刻 onExit 还没跑完，ReclaimOwner 就成了读已 munmap
的内存。
修法：把 onExit 提到 close(p.exited) **之前**，并明确 exited 的语义是
「**完全**收尾完毕」而非「进程已死」——任何等待者看到它关闭后，都可安全
释放共享内存、卸载资源。
**② StopAll 超时分支 `go p.Kill()` 发射后不管**
go p.Kill() // 不等待
本函数返回后调用方就 unmap，而 Kill 内部要等 markExited 跑完（含 onExit）。
改为等全部 Kill 完成（Kill 自带 killReapTimeout 上限，不会无限拖住关停）。
**③ 同类的第三处：事件环订阅在关停时从不退订**
EventRing.Subscribe 注册到 Bus 的 handler 会 ring.WritePush（写共享内存），
而 Host.Close 会 munmap 整块区域。此前：
- handleEvents 把 EvtRingSubscribe 的取消函数**直接丢弃**（corehandler_runtime.go:103）
- EventsUnsubscribe 是 no-op，注释还写着「子进程 Stop 时由内核统一清理」，
但 closeProcHost 根本没有退订
于是每个订阅过的插件都在 Bus 上永久留了一个写共享内存的 handler，
munmap 后任意一条事件经过 Publish 就会写已解除映射的内存 ⇒ 同类 SIGSEGV。
修法：EventRing 记为 unsubs、新增 EvtRingSubscribeTracked（订阅即登记），
Host.Close 在 freeShm **之前**调用 evtCloser.Close 统一退订。
## 回归测试（3 个，均经变异验证「修复前判红」）
1. `TestProcess_OnExitCompletesBeforeExitedCloses`（proc）
断言 Exited() 关闭时 onExit 必须已返回。变异（把 close(exited) 挪回
onExit 之前）→ FAIL。这是本次崩溃的直接判据。
2. `TestHost_CloseUnsubscribesEventRing`（proc）
断言 Host.Close 调用了 evtCloser.Close。变异（撤掉退订）→ FAIL。
3. `TestEventRing_CloseUnsubscribesFromBus`（plugin）
端到端：订阅 → Publish 有写入 → Close → Publish 不再写入。变异
（Close 不做事）→ FAIL。
顺带给 EvtRing 加了 Written() 访问器（诊断 + 上述测试的可观察量）。
## 验证
- 三个新测试全绿；-race 下 ./internal/plugin/... 全绿
- proc 包连跑 12 轮、internal/plugins 连跑 20 轮：SIGSEGV 0 次
- 全量 go test -count=1 ./... → 38 ok / 0 FAIL
- go build ./... / go vet ./... 干净
## 另有两个**既有** flaky（本次未动，与 C 化无关，单独记录）
排查过程中用「我的树 20 轮 vs 干净树 20 轮」对照确认了归属：
- 测试间固定端口冲突（pluginmgr 9876 / remotedevice 9890 / webui 8080）：
并行或残留实例时报 bind: address already in use。干净树同样复现。
- TestRealPlugin_DeepSearchInvoke 依赖外部 SearXNG（127.0.0.1:8888）：
上游限流时（brave "too many requests"、duckduckgo/quark CAPTCHA）断言失败。
干净树同样复现。属外部依赖，不是代码缺陷。
两者都不属本次「排查崩溃」的范围，已记入 plan.md 待办。
|
2026-09-25 17:25:43 +08:00 |
|
|
|
7799ca4559
|
perf(c-core): 完全 C 化 + 消灭初版的 malloc/拷贝开销（C 从「更慢」变「明显更快」）
上一提交的基准结论是错的："C 比 Go 慢" 不成立 —— 那是我把自己的
malloc/拷贝开销误当成了 cgo 的固有成本。本提交先拆解成本、再逐项消灭。
## 成本拆解（同机、百万次 benchtime）
| 场景 | ns/op |
|---|---:|
| cgo 边界（零拷贝传指针 + 空函数体）| 31.9 ← cgo 真实固有成本 |
| + 一次 C.CString + C 侧 strlen | 105-111（多出 ~75ns）|
| 初版 ModelContextWindow（另加 lower_dup malloc + 16×strstr）| 175 |
即 82% 开销是自找的。而初版还违反了自己写在设计文档 §四 的原则第 1 条
「C 接口只吃 const char* + 长度」——它没传长度，让 C 侧 strlen 再扫一遍。
## 逐项修复
1. C.CString（malloc+整串拷贝）→ unsafe.StringData 传指针+长度，零拷贝
2. C 侧 strlen 再扫一遍 → 长度由调用方传入，不扫
3. truncate 的 malloc 输出缓冲 + GoStringN 拷回 → C 只返回**字节数**
（结果必然是输入前缀），Go 侧 s[:n] 完成切片，全程零分配
4. lower_dup 每次 malloc 模型名 → 栈缓冲折叠，超长走零分配回退
5. 逐字节 utf8_next 函数调用 → 字级（8 字节）ASCII 检测
6. truncate 扫完整串才判断 → 数满 keep 个 rune 立即返回（提前短路）
7. 纯 Go 侧 len([]rune(s))/[]rune(s)（1KB 分配 4KB）→
utf8.RuneCountInString / DecodeRuneInString 游走，零分配
## 结果
| 基准 | 初版 C | 优化后 C | 纯 Go | 提升 |
|---|---:|---:|---:|---:|
| ModelContextWindow | 175 | 76.5 | 46.8 | 2.3× |
| EstimateTokens / 1KB ASCII | 2318 | 80.8 | 326 | 28.7× |
| TruncateByTokens / 1KB ASCII | 2594 | 71.7 | 411 | 36× |
| TruncateByTokens / 1KB 中文 | 3923 | 70.1 | 3097 | 56× |
## 完全 C 化（jianf 裁定）
撤掉我一度加的「短串 <32B 走回 Go」按长度分派：那会同时存在两份语义
可能分叉的实现。C 是唯一实现。
代价如实记录：EstimateTokens("qq") 这类极短串上 C 约 47ns（几乎全是
31ns 边界成本）vs 纯 Go 约 3ns，慢约一个数量级；绝对值纳秒级
（0.000047ms），单次请求尺度可忽略。若某循环对极短串高频调用，
正确应对是**把该循环 C 化（批量传一次）**，而不是按长度分派回 Go。
## 顺带补的正确性缺口（初版是真错的）
初版 C 的 UTF-8 解码只按首字节推断长度、**不校验后续字节**，
因此对畸形序列会与 Go 分叉：例 "\xE4\x41\x41"，Go 判 3 rune，
初版判 1 rune ⇒ rune 计数偏差 ⇒ token 预算与截断点偏移。
这类偏差**只影响计数、不会崩**，不测发现不了。
现在 C 侧做与 utf8.DecodeRuneInString 等价的完整校验（含过长编码、
代理对、超 U+10FFFF、截断序列），语义边界逐条注释。
代价：中文密集输入比初版慢（1467 vs 840）—— 这是刻意的正确性代价，
且仍比纯 Go 快 2×。
新增测试：
- TestGolden_InvalidUTF8：3000 组**任意字节**（含畸形序列）对拍，
覆盖初版会分叉的输入类别
- TestGolden_TruncateAlwaysPrefix：截断结果必为原串前缀且不超长
- C 契约测试从 21 项扩到 40 项（含非 NUL 结尾、超长名、畸形 UTF-8）
## 包现在要求 cgo 才能编译
删除 codec_nocgo.go：CGO_ENABLED=0 下整包构建失败（错误直指缺失符号）。
不保留回退的理由：只验证过一条路，就不该存在第二条。
实测这不影响任何构建 —— go list -deps 证明只有 cmd/homed 依赖本包，
而 waiter/initconfig/memgc/mock-server 均不依赖（逐个验过），
且 homed 本就强制 cgo（sqlite3 + gojieba）。仓库无 CI。
Makefile 把「不许有第二条路」变成可执行断言：check-codec-cgo-only
（断言 cgo 下全绿 **且** CGO_ENABLED=0 下必须失败）。
## 验证
- C 契约测试 40/40（gcc -Wall -Wextra 零警告）
- 黄金对照 6 个测试全绿（含 2000 组随机 + 3000 组畸形字节对拍）
- 变异测试：改 C 侧返回值后 go test 立即 FAIL（确认真的走 C）
- make check-codec-cgo-only 两项断言通过
- go vet ./... 干净；全量 go test -count=1 ./... → 38 ok / 0 FAIL
## 已知既有 flaky（与本改动无关，单独记录）
internal/plugins 在全量并发下偶发一次 SIGSEGV，栈在
internal/plugin/proc/{unified.go:234,arena.go:197}（arena 的 getU32）。
该两文件最后修改于 09-10，本提交 0 处触及；随后连跑 5 次单包 +
2 次全量均通过。初步判断是 arena/shared-region 的既有竞态，需单独排查。
|
2026-09-25 15:40:20 +08:00 |
|
|
|
5ccdf24f18
|
test(c-core): 补跨语言开销基线 —— 数据反驳「C 比 Go 快」的直觉
codec.go 的注释写着「EstimateTokens 是否该留在 C 侧由 codec_bench_test.go
的实测数据决定，不要凭直觉断言」，但那个文件此前并不存在（悬空引用）。
plan.md 与设计文档也都在说「需先有真实延迟基线（当前没有）」。本提交把它补上。
## 数据（ns/op，benchmem）
| 基准 | C（经 cgo）| 纯 Go | 谁快 |
|---|---:|---:|---|
| ModelContextWindow（短 ASCII）| 175 | 38 | Go 快 4.6× |
| EstimateTokens / 空串 | 100 | 0.43 | Go 快 230× |
| EstimateTokens / 短 ASCII | 115 | 6.5 | Go 快 17× |
| EstimateTokens / 短中文 | 100 | 29 | Go 快 3.4× |
| EstimateTokens / 中 200 字 | 229 | 509 | C 快 2.2× |
| EstimateTokens / 1KB 中文 | 840 | 2870 | C 快 3.4× |
| EstimateTokens / 1KB ASCII | 2318 | 332 | Go 快 7× |
| TruncateByTokens / 短中文 | 233 | 54 | Go 快 4.3× |
| TruncateByTokens / 1KB 中文 | 3923 | 6918 | C 快 1.8× |
（已用 -count 复测确认稳定；ascii_1k 的异常已单独隔离复测 3 次）
## 三条结论
1. **cgo 固定开销约 95–100 ns/次**，小输入下完全压倒算法差异。
2. C 只在**长中文**（UTF-8 步进重）上领先；长 ASCII 反而 Go 快 7×
（Go 的 utf8.RuneCountInString 对 ASCII 有快路径，C 侧逐字节跑）。
3. ⇒ 判据应是「哪个在**真实输入分布**下真能变快」，不是「哪个看起来更底层」。
## 对后续 C 化的影响（已写进 plan.md §七 与设计文档 §7.1）
- EstimateTokens 的真高频点在 process.go:476 的逐事件循环与 resident.go:552。
字段分布不单一：Source 是短标签（Go 快 17× 那一档），
Input/Response 是对话文本（长中文 C 快、短文本与长 ASCII Go 快）。
⇒ 当前一刀切走 C 会让短串净亏；正确做法是按长度分派，
但须先用真实长度分布复测，不要凭推测动手。
- ModelContextWindow（provider.go:333）与 TruncateByTokens（tooldefs.go:38）
调用点单一、非热路径，开销在单次请求尺度上无关痛痒。
这不否定 C 化方向：协议编解码（JSON 解析、SSE 分片）处理长文本，
才是 C 的主场，也是比「把短函数搬过去」更合理的下一步。
|
2026-09-25 14:51:10 +08:00 |
|
|
|
7351c6ca2e
|
feat(c-core): 内核编解码层 C 化第一刀 —— L1 纯函数层落地并打通构建链
第一刀只做三个纯函数（窗口推断 / token 估算 / token 截断），
价值不在功能（Go 版没问题），而在打通「Go → cgo → C」全链路并
建立可复现的对照范式，后面每扩一个函数都复用它。
## 为什么是这三个
按「无状态 → 有状态」分层，L1 协议编解码最安全：纯 string in → struct out，
不碰网络、不碰 Lua、不碰 goroutine。三个函数更是同一组纯算术，最小可验证切片。
## 关键设计：包内符号链接，不链接静态库、不 include 包外源
三种做法都实测过，只有一种同时满足「可构建 + 可交叉编译 + 缓存可跟踪」：
1. ❌ 链接 `csrc/build/libha_codec.a`（原方案）
- .a 是构建产物、不入库（.gitignore 的 build/ 命中 csrc/build/），
而发布脚本原先并不产出它 ⇒「不入库 + 不生成」两头空，
实测报 `cannot find .../libha_codec.a`
- 交叉编译 linux/arm64（homed 真实发布目标）时，宿主 x86-64 的 .a
被链进目标产物，实测报 `file in wrong format`
2. ❌ `#include "../../../csrc/src/ha_codec.c"`（包外相对包含）
★ Go 构建缓存**不跟踪包外被 #include 的 C 文件**。实测：包外源把返回值
7→8，`go test` 依然通过（缓存命中、静默沿用旧代码）；同样改动落在包内
文件时立即判红。对「逐步推进 C 化」这是致命的——改 C 源码不生效且无报错。
（包内 shim `#include` 包外源同样漏跟踪，已实测排除。）
3. ✅ 包内符号链接 `internal/agent/api/ha_codec.{c,h}` → `csrc/`
文件在包目录内 ⇒ 缓存按内容正确跟踪；只有一份权威源 ⇒ 无副本漂移，
也不需要「同步 C 源」的 make 目标。
## 不需要额外 build tag
ha_codec 是零依赖纯 C99 源码内联编译，不需要外部库或工具链前提；
而 homed 本就强制 cgo（sqlite3 + gojieba），故 C 路径自然生效。
只用 `cgo` / `!cgo` 一组约束（对比 onnxruntime：那个需运行期 .so，故必须显式 tag）。
## 顺带修掉的既有缺陷（非 C 化引入，但一直缺覆盖）
- Makefile 的 arm64 目标缺 CC/CXX：cgo 回退到宿主 g++，报
`gcc_arm64.S: no such instruction: 'stp x29,x30,[sp,'`
（deploy/packaging/build.sh:49 一直是对的，Makefile 漏了）
- Makefile 的 arm64 目标缺 .syso 隔离：cmd/{homed,waiter}/*.syso 是 Windows
COFF 资源对象，Go 会把同目录 .syso 无条件链进任何目标，交叉到非 Windows
平台报 `file format not recognized`（build.sh 有 hide_syso_for_target）
## 验证（每条可复现）
- `make build-linux-arm64` → ELF 64-bit LSB executable, ARM aarch64（82MB）
- `bash deploy/packaging/build.sh linux/arm64 homed` → ELF aarch64（79MB）
- 移走 csrc/build/ 后 homed（cgo）与 waiter（CGO=0）均能构建
- 变异 C 源（131072→777）后**同一缓存**下 go test 立即 FAIL（改前：仍报 ok）
- `make check-codec-paths` 两条路径 OK；`make csrc-test` C 契约测试 100%
- 黄金对照：手写用例 + 2000 次随机对拍，C 与纯 Go 逐值相等
- 全量 `go test -count=1 ./...` → 57 包：38 ok + 19 无测试 + 0 FAIL
新增 `make check-codec-paths` 防回归：只测一条路径时，另一条的破坏不会被发现。
## 文档
- `docs/zh/c-core/llm-orchestration-c.md` 同步为「已落地」，并更正因
「Windows 原生已放弃」而过时的 §2.3（回退路径的理由需重述）
- plan.md 的 P0-1 标记为已修复，附实测证据
|
2026-09-25 14:45:08 +08:00 |
|
|
|
d05161ac8d
|
fix(plugin): 退避注释里无实测支撑的「感知不到工具缺席」
`scheduleProcRestart` 的注释写：
线性退避：1 次→1s，2 次→2s，3 次→3s。崩溃循环时不至于打满 CPU，
又足够快到用户感知不到工具缺席。
前半句是事实（退避确实只为防崩溃循环打满 CPU），后半句是主观断言：
首次重启就要等 1s，这 1s 内该插件的工具是缺席的、调用会直接报错。
「用户感知不到」既无实测支撑，也会让读代码的人误以为是无感恢复。
这正是另一处文档（README「崩溃到恢复 <1s」）同源的问题 ——
实测退避为 1s/2s/3s，故 <1s 从未成立（`procRestartBackoff = time.Second`
由 02cc74c 引入，且该提交是 v1.0.0 的祖先）。
改为写明真实代价与插件侧的正确做法（在 OnStart 里自建重连与状态重建），
与 SDK 仓 README 刚补的说明保持一致。
|
2026-09-21 10:34:41 +08:00 |
|
|
|
3374e7dbd9
|
docs: 更正三处无实测支撑的性能断言
用户指出现有文档里的性能数字可疑。逐个实测后发现三类问题，都不加改原文地
标注更正（历史条目保留原文，仓内已有此惯例）。
## ① 「崩溃到恢复 <1s」——从未成立
写于 v1.0.0 发版说明。但**当时的退避代码就已是 1s**（查 v1.0.0 tag 的
`procRestartBackoff = time.Second`），首次重启就要等 1s。
实测（新增临时测试测量 scheduleProcRestart 延迟）：
第 1 次崩溃 → 1s 第 2 次 → 2.001s 第 3 次 → 3.002s
顺带纠正我自己刚在站点写错的阈值：并非「崩 3 次停下」。实测第 **4** 次
才停（`procMaxRestarts=3`，判定为 `n > 3`），前 3 次都会重启。
## ② 「RPC 往返 p50 24.1µs」——量级对、数字不符
实测 `BenchmarkToolInvoke`：inline/small **30.4µs**、frame/small 51.5µs、
inline/large 767µs、frame/large 398µs。原文与实测同为几十微秒量级，
但具体值对不上，且未注明测的是哪种 payload。
## ③ 「CLIP 实测常驻 1.15GB」——采样点不对（6 处）
实测加载 chineseclip 两塔，RSS 会**自己降下来**：
加载前 0.00 GB
两塔加载后 1.59 GB ← 峰值
GC + 静置 0.89 GB ← 稳态（内核回收未用页）
1.15GB 落在两者之间，既不代表峰值也不代表稳态。线上稳态实测 0.39~0.58GB
（更长时间静置后更低）。同源问题：qwen3vl 的「常驻 9.4GB」实为**峰值**，
其视觉塔本就是按需加载（源码注释：每张图约 1.6GB，故按需）。
6 处全部改为「稳态 X（峰值 Y）」双值，消除口径歧义：README 中英、
docs/zh/multimodal-space.md、config/registry.go（2 处 + 1 处注释）、
providers/chineseclip/tokenizer.go。
## 验证
- `go build`（含 `-tags onnxruntime` 与不带）与 `go vet` 均通过
- 全仓 `grep 1.15GB` 已清零
- 测量用的临时测试文件已删除，无残留
|
2026-09-20 19:56:49 +08:00 |
|
|
|
0c9a3900b8
|
fix(release): .hmap 纳入发布产物白名单 + 路径解析
## 白名单（真问题）
`upload_assets.py` 的 ARTIFACT_SUFFIXES 只有 .tar.gz/.zip/.deb/.rpm/.pkg/_win64.exe，
**没有 .hmap** —— 即使插件包已经构建好放在 dist/ 下，上传时也会被静默跳过。
这正是「release 里一个插件包都没有」的直接原因之一。
补 `.hmap` 与 `SHA256SUMS.plugins`（插件包的汇总校验和，与内核包的 SHA256SUMS 分开，
避免混用）。实测 is_artifact() 现能正确识别两者、仍跳过 README.md。
## 测试路径解析
`HMAP_BUNDLE_DIR=dist/plugins` 这种相对仓根的写法原先会失败：测试的 cwd 是包目录
（internal/plugins/pluginmgr），相对路径解析到包内，报 "no such file or directory"，
看起来像产物不存在。改为相对路径按仓根解析（向上找含 go.mod 的目录）。
实测三种调用都正确：相对路径、绝对路径、不设时 skip。
|
2026-09-20 09:07:33 +08:00 |
|
|
|
a35f2126a1
|
test(pluginmgr): 校验发布用插件包能被内核真实安装
配套 SDK 仓新增的 scripts/build_plugin_bundles.sh：**能构建出来 ≠ 内核装得上**，
这个测试用内核自己的 extractPackage 把产物真解一遍，验证三种包形态都落成规范入口。
覆盖的三种形态（都由真实产物验证过）：
- 多平台 bundle：`plugin.bin.<os>.<arch>` → 按当前平台挑出并**重命名为 plugin.bin**
- 单平台包（qq 的 plg.json 是 bundle:false）：只有 `plugin.bin`
- Lua 包（luademo）：入口是 `main.lua`，不编译 Go
不设 HMAP_BUNDLE_DIR 时 skip（不作为常规 CI 的必跑项，避免依赖 hmapdev 工具链）：
HMAP_BUNDLE_DIR=/path/to/plugins go test ./internal/plugins/pluginmgr/ \
-run TestBuildPluginBundlesInstallable -v
实测 21 个真实产物全部通过（含 Lua 与单平台两种非 bundle 形态）。
|
2026-09-20 09:02:42 +08:00 |
|
|
|
c0274b71d5
|
docs: 删除迁移期临时文档，现行内容搬进正式文档
用户指出迁移评估那批是**过程性临时文档**，迁移已完成就该退场。
## 删除（38 个文件）
- docs/zh/架构迁移评估.md（1621 行）—— 评估稿。开头的「❗现网正在发生的问题」
（output_send 永远成功 / cgo 超时泄漏 26 次 / stage 污染）**全部已修复**，
留着是误导性告警。其 §三「目标架构」已被 ARCHITECTURE.md 完整覆盖
（且后者更细，含子进程生命周期管理）。
- docs/zh/plugin-interface-matrix.md（428 行）—— 迁移基线矩阵。
- docs/zh/experiments/（36 文件）—— 18 项可行性实验，验证的是"该不该迁移"，
迁移早已完成；实测无任何构建/测试依赖它。
## 现行内容先搬走（不能随临时文档一起丢）
- plugin-interface-matrix §九「接口扩展规则」→ 搬进 docs/git-branching.md 新增 §八
（只增不减/签名不改、新增必须"插件调用内核实现"方向、hmapdev 模板必须同步接线
否则全体插件编译失败、"接口纯追加"≠"无需重编"、合回 main 的同步清单）。
- git-branching §六 原写「接口冻结是合回门禁」—— 冻结是**迁移期**约束，v1.1.x 起
已到期，改为标注失效并指向 §八。
## 引用清理
8 处引用全部改指现行文档：plan.md ×3、两篇设计文档各 ×1、
4 处源码注释（proc/shm.go、proc/process.go、dynamic_proc.go、entry_dispatch_test.go、
proc/bench_test.go）。仅 third_party（SDK 独立仓）保留 1 处，不动。
## 验证
- `go build ./...` 通过；`go test ./internal/plugin/...` 两个包全绿
- 本项目文档**断链 0**（另 2 处断链在 oh_modules 第三方依赖内）
|
2026-09-19 19:22:48 +08:00 |
|
|
|
7213edd181
|
docs: 全面按当前源码更新文档 + 删除已过时文档
## 删除（内容已落地/已被替换，保留只会误导）
- demo.md ................... failback 与 recoverydiag 均已实现，0 引用
- docs/defect-qq-output-send-loop.md .. 已修复（本身也标了「已修复」），0 引用
- docs/embedding-comparison.md ....... 一次性选型报告，仅被 agent 产物引用
- docs/zh/plan.md ............ 描述的旧 nav 布局已重写、死配置已清，全部完成
- docs/zh/plugin-migration-plan.md ... 迁移已上生产，纯过程稿（Part 0~6 全完成）
## 更新（按当前源码核对）
- assets/docs/{zh,en}/ARCHITECTURE.md（README 指向的用户文档，最重要）：
把只讲 cancel/intercept 的旧「中断机制」章节重写为「输入调度器与中断机制」——
补上两类别 + 四级中断（L1~L4，默认 L1、外部插件 L4 夹到 L3）+ 抢占/挂起/中断栈
+ 饥饿防护（PreemptCount 提升，封顶 L4）+ 抢占冷却（2s）+ 停止语义（cancelBudget）
+ 驻留子/分诊助手/残余任务；新增「上下文预算」章节（窗口 ≠ 工作面，600K 封顶，
预算是上限非填充目标）。中英章节数现已对齐（各 13 节）。
- assets/docs/{zh,en}/PLUGIN_DEV.md：插件示例表补 6 个缺失项
（acp/deepsearch/plugindev/recoverydiag/vanblog/vikunja）；qq 工具数 17 → 20（实测）。
- README.md / README_EN.md：补 v1.3.x 线（此前只到 v1.2.0，而 1.3.x 已发布 12 个 patch）——
驻留式子 agent、输出通道寻址、输入调度器、轻量内核 profile、积压及时反馈。
- plan.md：开头两个「⚠️ 紧急/正在持续污染」是过期告警（实测 残留 = 0），
改为「已解决」并加文档定位说明；§13 仍是活跃路线图故保留。
- docs/zh/plugin-interface-matrix.md + 两处源码注释：清理指向已删文档的断链。
全仓 md 断链检查：仅剩 1 处，位于 third_party 的 oh_modules（第三方依赖，非本项目）。
|
2026-09-19 19:14:55 +08:00 |
|
|
|
8acd3ce1a8
|
fix(offload): 内核说明不能被再转投（自我循环）+ offload_owned 未接线
★ 线上实测两个缺陷：
1. **自我循环**：转投会在队列留一条 [系统] 说明（source=kernel），
而转投条件把这条说明也算进「积压够了」⇒ 每次转投都产生下一轮要转投的东西。
实测 5 秒内连续触发两次，分诊助手不断收到「N 条积压已转投」这类噪音。
修法：takeQueuedInputs 排除 isKernelNotice（source=kernel）。
2. **offload_owned 永远为 false**：我加了 ResidentInfo 字段、加了状态面映射，
却漏了在 rc.info() 里赋值 ⇒ 线上转投子明明存在，读出来是 null。
这类「加了字段但没接线」不会报错，只会让父的判断悄悄失效
（父据此决定回收策略，读到 false 就会把临时助手当成正式子）。
测试 +3：说明不转投 / 循环必须终止 / offload_owned 会被上报。
前两条已实测「禁用守卫会失败、恢复后通过」，是真回归测试。
|
2026-09-19 17:47:44 +08:00 |
|
|
|
943eef01cf
|
feat(resident): 分诊助手定位 + 残余任务由父显式决定
用户澄清（重要定性）：这不是「内核替父决定」，而是**及时反馈** ——
主 agent 忙时不该让用户干等十几分钟。子 agent 是**分诊助手**：
简单的直接处理并回复，需要主 agent 的立刻回「忙碌中，请稍候」、不勉强作答。
三处补齐：
1. 分诊助手的职责提示词（之前完全没给 ⇒ 子不知道自己为什么存在）：
两条路（直接办 / 报忙碌）、拿不准时报忙碌、必须 output_send 到原通道。
2. 驻留子继承父的 SystemPrompt（之前没传 ⇒ 子只用一句兜底文案，
拿不到「异步通道必须显式 output_send，否则回复被静默丢弃」这条铁律。
webui 这类同步通道能回是因为走 ResponseCh，掩盖了这个缺陷）。
3. 残余任务由父显式决定（用户要求）：reclaim/destroy 时子手头未处理的消息
不再由内核悄悄处置 —— 内核只负责列清楚，父用 residual=keep/drop 决定。
之前 pendingEvents 只收带 ResponseCh 的，异步（qq）残余任务完全不在内，
被销毁时静默消失、用户零反馈且日志无痕。
配套：
- scheduler.takeAllPendingEvents：取走全部未执行事件（不筛通道）
- ApplyResidual(keep|drop)：keep 转回父队列（保留 ResponseCh），
drop 逐条记日志 + 给同步调用方补终态（否则 cli/a2a 永久挂起）
- 状态面暴露 offload_owned，让父分清「我建的子」与「内核临时拉的助手」
- 工具 schema 加 residual 参数并说明 drop 的代价
这也是用户观察到的「机制很自然」的落点：分诊助手就在同一张登记表里，
父能 inspect/send/compress/reclaim/destroy，控制面 6 动作按 id 生效不区分来源。
测试 +7（残余 keep 转回且保留 ResponseCh / drop 通知同步调用方 /
空残余如实报告 / 分诊提示词 / 继承 SystemPrompt），
其中 drop 那条已实测「对着静默丢弃的旧实现会失败」。全套绿。
|
2026-09-19 17:43:16 +08:00 |
|
|
|
01909bb914
|
fix(offload): 转投必须保留 ResponseCh，否则同步调用方永久挂起
线上实测第二个 bug：转投生效、子也正常处理（日志各 ~3s），但 webui 的 HTTP
请求一直挂着不返回，最终 504。
根因：第一版用 InjectInputTo 转发，它会**重建** InputEvent ⇒ ResponseCh 被丢掉。
而 cli / a2a / webui 这类**同步**调用方正阻塞等这个 channel。
仓库反复警告过同一件事（Agent.Stop 的注释：「带 ResponseCh 的同步注入方
（cli / clawhubadapter 均无超时）会永久挂起」）。
修法：改走既有的跨 agent 投递原语 DeliverRouted —— 它推**原事件**，保留
ResponseCh/RequestID，只往 payload 里补转投标注。
回归测试 TestForwardKeepsResponseCh 断言**最强的那条性质**：真的等同步回执回来。
（不用「读子的 InputChan」来断言：SpawnResident 会启动子自己的调度循环，
它会与测试抢同一个 channel，那样写出来的测试是 flaky 的 —— 我第一版就是这样，
实测挂死过一次。）
已实测该测试对着错误实现会失败（10s 超时）、修后通过。
|
2026-09-19 17:16:24 +08:00 |
|
|
|
fe1d2672d8
|
fix(offload): 积压可能全堵在 io 输入 channel，不在就绪队列
线上实测发现上一版**永不触发**：主 agent 跑着 6×45s 的长任务、我连发 4 条消息，
scheduler 始终显示 queue=0、residents=0，转投一次都没发生。
根因：schedulerLoop 是**同步执行**任务的，所以「正忙」期间它根本回不到循环顶部
去调 pumpInbox —— 后到的输入全堆在 io.inputCh（容量 256）里，压根没进 sched.queue。
而 takeQueuedInputs 只看 s.queue ⇒ 恒取不到东西。
★ 仓库里早记过同一个坑：armStop 的注释写着「pending 是还没被 pumpInbox 搬进队列
的那一段……只数 s.queue 会得到 0（实测），配额随之失效」。我重犯了它。
修法：转投前先 drainInboxToQueue() 把 channel 里的输入搬进队列。
与 pumpInbox 的区别是**不要求 hasRoom** —— pumpInbox 满时会停下保留背压，
而转投场景恰恰是「队列空、输入堵在 channel」（调度器回不到 pumpInbox）。
队列上限仍由 enqueue 把关，放不下的给同步调用方 skipped 终态（不丢、不阻塞）。
回归测试 TestOffloadSeesInputsStuckInChannel 精确复现该现场状态：
已实测它对着修复前的逻辑**会失败**（期望 3 实际 0），修后通过 —— 是真回归测试。
|
2026-09-19 17:05:38 +08:00 |
|
|
|
69446a2649
|
feat(scheduler): 主 agent 忙时把积压任务自动转投给驻留子
问题（2026-09-19 线上实测）：主 agent 被长任务占住时（现场：12 分 8 秒、69 次
工具调用），后来到达的消息全部以 level insufficient 排进中断队列干等 —— 同级
中断不能抢占同级运行任务（canPreempt），只能等前一个跑完。而内核本有驻留子
（独立 agent + 独立调度器）可并行干活。
行为（用户 2026-09-19 明确要求）：
- 触发：运行任务持续 > offload_busy_after(5m) 且积压 >= offload_min_pending(3)
- 拉起/复用「转投专用」驻留子，把积压的纯排队输入转投过去
- 在原队列位置留下说明「[系统] N 条积压任务已转投给驻留子 agent X 处理…」
通道配置（按用户口径，与人工创建的子刻意不同）：
- 不配 inputch（内核的干活 agent，不接收插件用户输入）
- 持有全部输出通道（结果要能发回 qq/webui 等正确通道）
三个设计要点（都是实测撞出来的，写进代码注释与设计文档 §7.1）：
1. 检查必须在**独立 goroutine**：schedulerLoop 同步执行任务，放它里面在
「正忙」期间根本回不到循环顶部 ⇒ 永不触发（我第一版就写错了，测试才发现）。
2. 只转投 TaskQueued 纯排队输入：中断任务带级别语义、self 任务与父的记忆面绑定。
3. 转投失败/关闭时必须把任务**放回队列前端**：吞一条输入比多处理一条更糟。
这是设计 §7「决策在父的模型手里」的**刻意例外**（父正忙、物理上无法决策，
而积压任务本来就是空的），已在文档中显式记录，且默认关闭、由部署方显式打开。
测试 11 条：只取排队输入 / 不足量不取 / 放回不丢任务 / 说明自解释 / 默认关闭 /
空闲不触发 / 端到端转投 / 上限不增殖 / 独立 goroutine 确实会触发。
|
2026-09-19 16:59:47 +08:00 |
|
|
|
e273924511
|
fix(llm): 参数无法解析时给出真因，不再静默丢弃整条调用
★ 上次修复误判了成因。真实根因（本次运行日志 34/34 同形）：
{"command": "…完好的长命令…", "timeout": 20s}
command 一字节没错，只是 timeout 值少了引号 —— cmd_run 的 schema 把 timeout
声明成 string、示例写着 "10s, 1m, 30s"，模型照抄格式却忘了引号。
finish_reason=length 出现 0 次 ⇒ 上次那条"截断"分支从不生效。
旧行为把**整个参数**丢掉，模型只看到 "command is required"，看不出坏在 timeout，
只能原样重试。实测本次运行 cmd_run 失败率 35%（34 败 / 71 成），
12 分钟的任务里更是 48% 时间耗在这上面 —— 每次失败都付一次完整 LLM 往返。
三处改动：
1. repairToolArgsJSON：解析失败时先试窄修复 —— 只给"值位置上未加引号的带单位
数字"补引号，且修完必须真能解析成功才接受。不碰合法 JSON、不动正文里的 20s、
不会把真截断"修好"。
2. 修复仍失败时不再静默降级成空 map，改为带 __arg_error 交给模型，并按成因
分流文案：截断→拆小参数；JSON 写坏→提醒带单位的值要加引号。
3. 统一键名 __arg_error（原 __truncated_error 只覆盖截断，语义过窄）。
同一缺陷面不止 cmd：agentcli/healthcheck/timer 都有 string 类型却以
"5m, 1h" 作示例的参数，此修复一并覆盖。
回归测试：真实日志样本修复、保守性（不碰合法/正文/截断）、
端到端（修复后 timeout 仍能被 time.ParseDuration 接受）。
|
2026-09-19 16:49:16 +08:00 |
|
|
|
53e7106985
|
fix(llm): 参数解析失败不再丢弃完好字段（改错值格式，不是截断）
★ 上次修复误判了成因。真实根因（日志 11/11 同形）：
{"command": "…完好的长命令…", "timeout": 20s}
command 一字节没错，只是 timeout 值少了引号 —— 而 cmd_run 的 schema 把
timeout 声明成 string、示例写着 "10s, 1m, 30s"，模型照抄格式却忘了引号。
实测 finish_reason=length 出现 0 次，所以上次那条"截断"分支从不生效。
旧行为把**整个参数**丢掉：模型只看到 "command is required"，看不出是 timeout
写坏了，只能原样重试 —— 12 分钟的任务里 30 次失败 / 32 次成功（48% 浪费），
每次失败都付一次完整 LLM 往返。
改法：parseToolArgsJSON 失败时先试 repairToolArgsJSON，只做一件很窄的事 ——
给"值位置上未加引号的带单位数字"补引号，且修完必须真能解析成功才接受。
因此不会改坏合法 JSON、不会动字符串正文里的 20s、不会把真截断"修好"。
真实日志样本 + 保守性 + 反伪造三组回归测试已钉死。
|
2026-09-19 16:47:13 +08:00 |
|
|
|
6ddef5e49f
|
feat(llm): 声明真实上下文窗口 + 工作区间与窗口分离
问题：core.llm.model=AUTO，而 ModelContextWindow("auto") 匹配不到任何分支、
掉进 default 32768 —— 该源真实窗口是 1M（实测 990,034 token 的 prompt 通过），
内核却按小 30 倍的窗口算全部预算。
三处改动：
1. ModelContextWindow 补 deepseek-v4/v3 → 1M；推断不出时打日志（静默降级是
这次问题的成因，不能再默默退回一个小值）。
2. sourceFieldDefs 补 context_window 声明：它早已被 readInt 读进 LLMSource
并透传到 provider，但没进这张表 ⇒ WebUI 里看不见也改不了。
3. ComputeTokenBudget 新增 maxTargetTokens=600000：窗口 1M 不等于按 838K
（80%）干活。标称窗口≠有效窗口，600K 是该源最优工作区间，所以把
「窗口上限」（会不会被上游拒）与「工作区间」（预算分配）分开。
配套 core.llm.max_tokens 4096→32768（实测长输出样本达 18,272 token，
16384 仍会截断；上限是 cap 不是目标，短问答零成本）。
测试：tokenbudget_test.go 钉死封顶生效且小窗口不受影响；
context_window_test.go 钉死推断值与显式声明优先级。
|
2026-09-19 14:24:31 +08:00 |
|
|
|
95292aff8e
|
test(llm): 钉死截断必须短路工具分派
补一条端到端断言：截断的 tool call 绝不能拿着空 map 走到 files_write
（那会回 'path is required'，模型据此原样重试）。断言 executeToolCallInner
的短路 + 指引可执行。
|
2026-09-19 13:53:56 +08:00 |
|
|
|
2722d76095
|
fix(llm): max_tokens 截断不再静默降级成空参数
长参数工具调用（整段脚本/大 JSON）被 core.llm.max_tokens 从中间切断时，
上游回 finish_reason=length，而旧实现把这个信号整个丢掉：残缺 JSON 解析失败
后静默降级成空 map，工具只看到参数为空并报 'path is required'。模型因此完全
看不出真因，原样重试四遍、次次撞同一堵墙（2026-09-19 实测 4 次 files_write 失败）。
注：files_read 并未失败——是写挂之后模型反复重写把读卷进同一轮，看起来像两者都报错。
改法：
- finish_reason=length 时不再静默降级，改为塞入 __truncated_error 指引，
告诉模型「参数被截断 + 请拆成多次调用/追加写 + 勿原样重试」；
- executeToolCallInner 见到该标记即短路，不拿空参数去调工具；
- 非截断的残缺 JSON 保持旧行为（避免把「厂商不回 finish_reason」误判成截断）。
回归测试 2 条钉死这两面。
|
2026-09-19 13:49:21 +08:00 |
|
|
|
01113664b4
|
fix(obs): 抢占日志改在判决点打（修自伤）+ scheduler 事件接进 SSE
## 修我上一版的自伤
上一版把 preempt 日志打在 `executeNewTask`，但那时 `nextRef` 已经把
`s.running` 换成了抢占者自己，于是输出成了
preempt start: task#2 ... -> victim task#2 (cli)
victim 打印的是入侵者本人。判据必须落在 `registerInterrupt`——那一刻
running 还是真正的受害者。改为在抢占判决点打：
[agent] preempt: task#2 class=interrupt level=3 from cli (L3) preempts task#1 class=queued level=0 (qq)
## 补上「入队而非抢占」的日志
中断到了却没生效，此前完全不可解释。现在两种成因分开写：
[agent] interrupt queued: ... vs ... (qq) — running in critical section; queue=N
[agent] interrupt queued: ... vs ... (qq) — preempt cooldown; queue=N
[agent] interrupt queued: ... vs ... (qq) — level insufficient; queue=N
没有这条，`interrupt from X` 打过之后任务为什么没让位就只能猜。
## scheduler 事件接进 SSE
`EventScheduler` 此前既不在 `handler_chat.go` 的 subTypes、也没有任何订阅者
（全仓 grep 零命中）——内核里 suspend/resume 只 publishEvent，于是事件发出来
就掉地上，对内对外都不可见。加进 subTypes 后前端/客户端能看到抢占链。
## 验证
- preempt_logging_test.go 增一条：victim 与入侵者必须是不同来源（qq vs cli），
且排队输入对排队任务 `canPreempt` 必为假。
- 实测输出含 `cli (L3) preempts task#1 class=queued level=0 (qq)`。
- 全量 `go test ./internal/... ./cmd/...` 与 `go vet ./internal/...` 全绿。
|
2026-09-19 11:57:50 +08:00 |
|
|
|
b1ec278136
|
feat(obs): 抢占日志说出「受害者是谁」——suspend/resume 此前完全不落日志
排查「我的任务怎么被莫名打断了」时撞上的观测缺口。
## 缺口
`executeNewTask` 里挂起、`resumeTask` 里恢复，两处都**只发事件、不写日志**：
a.sched.suspend(t, f)
a.publishEvent(events.EventScheduler, map[string]any{"action": "suspend", ...})
于是生产日志里只有两行：`interrupt from X` 与 `LLM request cancelled by
preemption` —— **看不到受害者是谁、被谁挤下去、后来有没有恢复**。后果是实测过的：
按时间先后猜凶手，把时间上相邻的输入误认成抢占者。
## 改动
- `sourceOf(task, frame)`：取可辨识来源（`evt.Source` 优先，回退 OutputChannel，
自循环任务给 `self:<channel>`）。取 Source 而**不是** OutputChannel：
前者回答「谁送来的」（qq / homeagent-mail-bridge / timer / child/xxx），
后者只回答投递到哪个通道；多数场景同名，但因果链上要的是前者。
- `describeTask(task)`：`task#N class=queued|interrupt level=L`。
- `suspendDepth()`：日志专用，走锁而不是让日志点直接摸 `suspendStack`。
- 三个日志点：抢占开始（含 victim）、挂起（含来源与栈深）、恢复。
输出形状：
[agent] preempt start: task#2 class=interrupt level=4 from cli -> victim task#1 class=queued level=0 (qq)
[agent] suspend: task#1 class=queued level=0 (qq) yields to an interrupt; suspendStack=0
[agent] resume: task#1 class=queued level=0 (qq) resumes after the interrupt finished
## 验证
- 新增 preempt_logging_test.go：抢占后栈深 0→1、sourceOf 取到 qq、self/nil 不 panic。
- 实测日志（TestPreempt_HigherPreemptsAndResumes）三条齐全，能一眼看出
是 `cli` 的 L4 挤掉了 `qq` 的排队任务、随后 qq 恢复。
- `go test ./internal/... ./cmd/...` 全绿。
|
2026-09-19 11:31:04 +08:00 |
|
|
|
895948b24e
|
fix(stop): 配额须计入停在输入 channel 的待处理消息
实测：停止后排队消息仍逐条跑完。原因是 armStop 只数 sched.queue，
而用户按下停止时调度器正忙于当前任务，其余消息大多还没被 pumpInbox
搬进队列、仍停在 inputCh ⇒ queued=0、配额归零。
- IOManager.PendingInputs()：暴露 channel 中待处理条数。
- armStop(pending int)：queued = len(s.queue) + pending。
- 补 TestStop_ArmCountsPendingChannelInputs 锁死该口径。
|
2026-09-18 11:39:04 +08:00 |
|
|
|
698ff7ddd5
|
fix(stop): 修自伤——interceptLoop 里 takeStop() 被 || 短路提前消费
上一版把 stop 标记在 interceptLoop 里消费掉了一部分：
`if n := armStop(); n > 0 || takeStop() { ... }`，queued=0 时短路到
takeStop()，标记先被吃掉，stepLLM 永远看不到 → 取消后照样重跑一轮。
实测：日志正确打出 stop requested ... queued=0，但生成仍跑到自然结束（5000+ 字全文落库）。
改为只 arm 不 take（takeStop 只由 stepLLM 消费），并补一条**经真实
interceptLoop** 的用例：它必须 a.Start()（第一版测试只调 New()，
interceptLoop 根本没跑，假绿）。已验证该用例在注入此 bug 时失败、修复后通过。
|
2026-09-18 11:32:20 +08:00 |
|
|
|
ccc2ac2d4d
|
fix(stop): 停止按钮真正生效——停止 ≠ 空中断；鸿蒙 screensue 支持 HTML
两处鸿蒙端缺陷 + 一个跨端（WebUI/GUI/鸿蒙）的停止语义缺陷。
## 症状（实测取证）
1. **鸿蒙终止按钮按下没反应**。POST /chat/interrupt 带空 body，接口回 200
`{"status":"interrupted"}`，但 journalctl 零中断日志、生成继续跑到自然结束。
2. **鸿蒙 screensue 不解析 HTML**，把标签当普通字符串显示。
## 根因
停止按钮走的是「空内容中断」，而 interceptLoop 有一行
`if text == "" { continue }` —— 空内容被判为「无事发生」直接丢弃。
所以停止指令从未到达调度器；接口那个 200 是不诚实的。
另查明两条会放大症状的既有问题（停止后仍在跑）：
- `chatStreamWithFallback`：流式连接失败时无条件回退非流式 `Chat`。
上下文已取消时这等于**再发一次完整请求**（停止后模型继续生成）。
- `stepLLM`：`context.Canceled` 一律 `outcomeContinue` 重跑本步。
这是给「被更高中断抢占」用的（现场要交出去、稍后继续），
但用户按停止是「不要了」，重跑就是停止没生效。
## 修法（按用户明确的设计）
停止 = ①立即结束当前 LLM 推理（不重试、不恢复）；
②对**停止那一刻已排队**的 x 条消息，后续在 pre-action 阶段依次短路。
- scheduler：新增 `armStop`（登记快照配额并返回当时排队深度）/`takeStop`/
`consumeCancel`。配额取快照值（停止后新到的输入不受影响），
重复按停止取 max 不累加（两个客户端同时按不该翻倍）。
- `interceptLoop`：读 `stop` 标记。停止时 armStop + cancelCurrentLLM；
**纯停止不再进中断队列**（旧实现把它当空中断入队，所以停完还会活）。
带注释的停止（`/stop 换个话题`）仍走中断路径。
- `stepLLM`：取消 + `takeStop()` → 直接 `outcomeDone`（不再重跑）。
- `stepPrepare`：`consumeCancel()` 命中即在 pre-action 短路收尾。
- `chatStreamWithFallback`：以 **ctx.Err()** 为判据拒绝回退（不是「错误是不是
Canceled」——很多 provider 用 Canceled 表示「不支持流式」，那种必须继续回退，
否则会把探测误判成取消；这条区分是跑全量测试时才暴露的）。
- WebUI handler / CLI `/stop`：空消息时带 `stop:true`。
## 鸿蒙端
- `BridgeCaps.ets`：新增 `looksLikeHtml`（首字符 '<' + 字母开头标签名，
避免误判 "<3" 这类文本）、`screensueHtml`、`escapeHtmlText`。
- `ScreensuePage.ets`：HTML 走 **RichText**（只解析 HTML 子集、无脚本无网络），
纯文本仍走 Text。不用 Web 组件：agent 下发的是第三方内容，
Web 默认带 javaScriptAccess/fileAccess，等于让远端内容在客户端执行脚本。
注入主题前景色，避免 RichText 用系统默认色导致深色主题下黑字不可见。
- `ChatSession.ets`：`interruptChat` 改发 `{stop:true}`（含类型声明，
ArkTS 禁止无类型对象字面量），并在本地即时复位忙态 + 提示「已停止」。
## 验证
- 新增 `stop_semantics_test.go`：停止终结任务不重试（provider 调用次数恒为 1）、
配额是快照（x 条短路、随后新到的不受影响）、重复 arm 取 max。
- `go test ./internal/... ./cmd/...` 全绿。
- 鸿蒙 HAP 构建通过；unsigned 包已装进模拟器（signed 包受
READ_PASTEBOARD 授权限制装不上，与既有记录一致）。
|
2026-09-18 11:26:12 +08:00 |
|
|
|
1f5af1dccf
|
feat(cli,ohos): 补齐两处能力缺口——CLI /memory context|tools、鸿蒙 camerasue 录像回传
核对「CLI 与 WebUI 插件能力对齐」时发现两个此前遗漏的缺口，一并补齐。
1) CLI /memory 缺 context 与 tools（internal/plugins/cli/plugin.go）
WebUI 有 GET /api/v1/memory/context 与 /api/v1/memory/tools，CLI 只有
query/graph/text。IndexerAPI 本就对内部插件开放（BuildContext/
FormatContext/GetToolDefinitions/BuildToolPrompt），不是 SDK 缺口。
补上后与 WebUI 同源：context 打印「实际会注入什么上下文」，
tools 打印工具定义 + 工具提示词。
waiter 同步接上两条远端路由与 help 文案。
2) 鸿蒙 camerasue 录像（BridgeCaps/BridgeRouter/DeviceBridge.ets）
此前 `camerasue <N秒>` 直接返回「暂不支持录像回传」。查 SDK 后发现
cameraPicker 本身就有 PickerMediaType.VIDEO 与 PickerProfile.videoDuration
—— 录像完全可行，只是回传通道没接。
现改为：VIDEO 模式取回 mp4，经 DeviceBridge.sendDataChunked 按
cmd_data_start/分块/cmd_data_end 回传（与 GUI/CLI 录像路径一致），
网关聚合后落盘成文件、agent 拿路径；照片仍走小体积 base64 内联。
上限 64MB、时长 1~300s，超限明确报错而不是把 WS/上下文撑爆。
依赖方向处理：BridgeCaps 需要「往本请求回传字节」，但 DeviceBridge 为取
CapResult 已 import BridgeCaps，反向 import 会成环。改为 BridgeRouter
注入 DataChunkSender 回调（它同时持有 deviceBridge 与 reqId），
BridgeCaps 不碰 socket。新增 CapResult.chunked 标记「结果已由能力分块
发完」，DeviceBridge 据此不再回 cmd_result，避免网关把已完成请求与后续
分块错配。
验证：hvigor assembleHap BUILD SUCCESSFUL（ArkTS 编译通过，改动文件零告警）；
make check-client-versions 一致；go vet 干净；全量 go test ./internal/... ./cmd/... 零失败。
|
2026-09-18 10:04:53 +08:00 |
|
|
|
9de3b365a6
|
fix(agentcli): 修 4 个真实缺陷——停机死锁、超时泄漏、僵尸堆积、孙进程逃逸
jianf 提示 agentcli 可能有问题，系统性审了一遍（含 -race 与线上实证），
确认并修复 4 个互相叠加的真实缺陷，每个都配了「去掉修复即失败」的回归测试。
1) 停机/热重载死锁（plugin_stop_test.go）
Stop() 先 p.wg.Wait() 再 Close 终端，而 readLoop 自己也记在 p.wg 上、
只监 t.stopCh 不监 p.stopCh。只要有一个终端开着，wg.Wait() 就永不返回。
后果：插件卸载/热重载（StopAndUnload/ReloadOne）与停机全挂死，且
registry 持锁时是整个内核一起挂。
修：先关活跃终端（move 出 map 后在锁外 Close），再 wg.Wait()；
readLoop 顶部加 p.stopCh 探测；Stop() 用 sync.Once 保证幂等。
2) 终端超时后资源全泄漏（plugin_lifecycle_test.go）
readLoop 的 IsExpired 分支只 delete(sessions) 后 return，既不 Kill 也不
Close。终端已被移出 sessions，cleanupLoop 也再看不到它，进程/PTY fd/
reader 协程无人回收。实测：timeout=1s 的 sleep 300 超时后进程仍在跑。
修：readLoop 加 defer releaseResources()，保证「只要退出就释放」。
3) 子进程从不回收 → <defunct> 僵尸堆积（pty_linux.go + plugin_lifecycle_test.go）
newCommandPty 只 Start 从不 Wait。线上实测 homed 名下已有一个
[sh] <defunct> 僵尸子进程。
修：linuxPty 加 Wait()（sync.Once 保证只 Wait 一次），
releaseResources 通过可选接口 Wait() error 调用（Windows ConPTY 不实现则跳过）。
4) Kill 只杀直接子进程，孙进程逃逸（pty_linux.go + plugin_lifecycle_test.go）
newCommandPty 用 Setsid，sh 是新进程组领头，真正的命令（sleep/vim）是
其孙进程且同组。只 Kill(sh) 会留下孤儿继续跑。实测：`sleep 300; echo done`
只杀 leader 后 sleep 仍在（被 init 收养）。
修：改为 syscall.Kill(-pid, SIGKILL) 杀整个进程组，失败再回落单进程 Kill。
测试设计要点：回归用例必须让「sh 保留为父进程 + 孙进程显式 trap "" HUP」，
否则单个 sleep 会被 sh exec 掉、关 PTY 的 SIGHUP 又会顺手带走孙进程，
两个缺陷都测不出来（这两种情况都实际踩过并修正了用例）。
全量 go test ./internal/... ./cmd/... 通过，agentcli 单包 -race 通过。
|
2026-09-17 20:24:03 +08:00 |
|
|
|
ec13eb391a
|
fix(agentcli): 终端退出前补推残留输出，短命令输出不再丢失
线上验证「内核开、两个插件接」时发现的真实缺陷：`echo`、`ls` 这类在首个
200ms ticker 之前就结束的短命令，readLoop 走到 `!terminalRunning(t)` 分支
直接 return，残留在 stream 里的输出从未 flush。
症状：输出只留在 session.buf 里——agent 用 terminal_read 能看到，但
terminal_output 事件永远发不出去，于是内核权威视图（以及 WebUI/CLI 的
/terminals）的 output 恒为空。实测 term_2（echo HELLO_KERNEL_REGISTRY）
在 /terminals 里 output="" 而 agent 同期 terminal_read 拿到了正文。
修法：
- 抽出 flushTermStream(s, t)，ticker 与所有退出路径共用同一条推送路径
（避免以后再出现「某条退出路径忘了 flush」）。
- readLoop 顶部加 defer：defer flushTermStream 后于 defer emitTermState
声明 → LIFO 下先 flush 再报停止，保证「最后一段输出」先于 running=false
到达订阅者。
测试：plugin_flush_test.go 新增 TestReadLoopFlushesOutputOnExit——走
EventBus 捕获事件，推入输出后立即让进程退出（远早于 ticker），断言输出
已补推且末态 running=false。已验证去掉修复即 FAIL、加回即 PASS。
注：handleRead(clear=true) 会主动 Reset stream（避免与读取结果重复），
属既有设计；本修复针对的是「未被读取就退出」的路径。
|
2026-09-17 20:00:47 +08:00 |
|
|
|
e70d2171ee
|
refactor(terminal): 内核开终端/命令历史权威视图，WebUI 与 CLI 都改接内核
按「内核开，两个插件接」重构终端与命令历史的数据归属。
背景：此前 WebUI 与 CLI 各订 EventToolCall/EventTerminalOutput 攅一份状态，
同一件事两份推导，还各自踩过同一个坑——工具 result 是 Go 的 map 文本
（map[cols:80 ... id:term_2 ...]），断言成 map[string]interface{} 永远失败，
terminal_create 的 id 回填不生效，/terminals 因此恒空（WebUI 也一样）。
实测确认：WebUI 自己的 /api/v1/terminals 与 /api/v1/cmd/history 同样是空的。
内核开（权威唯一真相）：
- internal/agent/core/terminal_registry.go：TerminalRegistry 归并两类事件——
EventToolCall（terminal_create/close、cmd_run，id/command 从 args 或 Go map
文本回填）与 EventTerminalOutput（agentcli 生命周期 + 输出，含 64KB 缓冲上限、
100 条命令历史、50 个终端上限）。
- internal/sdk/terminal.go：新增 TerminalAPI（ListTerminals/CmdHistory）与
TerminalStatus/CmdExecStatus DTO。**不塞进 KernelStatus**：那是全量快照，
前端每 3 秒轮询 /kernel，背上每终端最多 64KB 输出会让轮询成本爆炸；
终端输出是按需拉取的明细，另开接口。
- Agent 订阅自己的事件总线（subscribeTerminalRegistry），且**只根 agent 建**
（驻留子共用同一总线，每个子都建会 N+1 份重复记账）。
- SDKConfig/Registry/bootstrap 接线：pluginReg.SetTerminalAPI(agent)。
生产者补全（agentcli）：终端无输出时 ticker 不发事件，内核就无从知道终端
存在。新增 emitTermState，在 handleCreate/handleClose/readLoop 退出（超时/
进程结束/读取错误/stopCh）显式上报 running 状态，并给输出事件补 command 字段。
handleClose 改为接收 *sdk.PluginSDK 以便上报。
两个插件接（消费方）：
- WebUI：删掉本地 termStates/cmdHistory/subscribeTerminalStream/handleToolEvent
及不再使用的 getStr；/terminals 与 /cmd/history 直接读 s.Terminal()。
- CLI：删掉上一轮刚加的 subscribeToolEvents 与 cliTermState/cliCmdExec；
/terminals 与 /cmd/history 直接读 s.Terminal()。两条路（local/remote）都通。
测试：新增 terminal_registry_test.go，锁死 Go map 文本解析（旧缺陷根因）、
生命周期、CLI 直调路径（无 EventToolCall 仅凭 output 事件建条目）、历史与
终端数量上限。全量 go test ./internal/... ./cmd/... 通过。
|
2026-09-17 18:56:15 +08:00 |
|
|
|
3cce605722
|
feat(cli): /terminals、/cmd/history、/terminal 对齐 WebUI（事件面 + ToolAPI，无需新接口）
去看了一遍源码，纠正上轮判断：终端与命令历史也不是 WebUI 插件私有。
- 终端会话：agentcli 插件持有，发 EventTerminalOutput；WebUI 只是订阅该事件
自己攒视图。命令历史：WebUI 订阅 EventToolCall 的 cmd_run 攒的。
- 于是 CLI 插件订阅同样两个事件即可同口径：/terminals、/cmd/history。
- 开/写/读/关终端：SDK 的 ToolAPI.ExecuteTool 已允许跨插件调用工具，
CLI 直接调 agentcli 的 terminal_create/write/read/close，新增 /terminal 子命令。
waiter 侧同步：/terminals、/cmd/history 两条路（local/remote）都接；/terminal
仅在 local 可用（远端 WebUI 无对应 REST 端点，明确提示而不是当聊天发出去）。
|
2026-09-15 15:31:32 +08:00 |
|
|
|
0227fc2d4d
|
feat(cli): /persona 与 /agents 对齐 WebUI（复用已开放的 SDK 面）
- /persona：读写 core.agent.personal_prompt / core.internal.persona_initialized；
插件 SDK 的 Settings() 满足 internal/config.PersonaKV，与 WebUI 同一实现。
GET 等价返回 initialized/current_prompt/file_override；/persona set <mode> [内容] 写。
- /agents：改用 supervisor.ListAgents()（WebUI /agents 同源），此前只回一个
agent_id、驻留子信息全丢。
- waiter 侧 /persona 在 local/remote 两条路都接上，/help 补齐。
|
2026-09-15 15:25:20 +08:00 |
|
|
|
91c25fa536
|
feat(cli): /runtime 接上（runtime 本就经 KernelStatus 对内部插件开放）
纠正上一轮的判断：runtime 不是“SDK 未暴露”。s.Status().GetKernelStatus()
里的 Scheduler / Residents / Channels / InputChannels 就是 WebUI /runtime
的数据源，内部插件同样拿得到——CLI 只是漏接了这条命令。
- CLI 插件新增 /runtime，输出与 GET /api/v1/runtime 同口径。
- waiter 侧 /runtime 在 local（发 CLI 插件）与 remote（走 REST）两条路都接上，/help 补齐。
|
2026-09-15 14:29:29 +08:00 |
|
|
|
bcaa8f3f31
|
feat(cli): /plugin install 真正可用（直连 pluginmgr 回环端点，与 WebUI 同实现）
原来 CLI 的 /plugin install 只打印“请去 WebUI”。插件安装逻辑在 pluginmgr
插件里（回环 HTTP，默认 127.0.0.1:9876，无鉴权），WebUI 也是转发到它；
CLI 插件改为直连同一端点，能力对齐。
|
2026-09-15 12:17:34 +08:00 |
|
|
|
5333a33e20
|
feat(cli): CLI 插件能力对齐 WebUI（memory/knowledge/config/tracker/adapters/network）
原来 CLI 插件只覆盖 WebUI 的一小部分：/memory 只有 query、/knowledge 只有
list、没有 config/tracker/adapters/network，结构化输出还各拼一套文本格式。
按 WebUI 的 REST 面对齐：
- /memory query|graph|text [n] （对应 /memory、/memory/graph、/memory/text）
- /knowledge | delete <name> | stats（对应 GET/DELETE /knowledge）
- /config （对应 GET /config）
- /tracker | rollback （对应 GET /tracker、POST /tracker/rollback）
- /adapters | remove <name> （对应 GET/DELETE /adapters）
- /network （对应 GET /network）
- 统一 writeJSONContent：结构化数据一律缩进 JSON，与 WebUI 同口径。
waiter 侧同步：把上述命令在 local（发 CLI 插件）与 remote（走 REST）两条路
都接上，/help 补齐；两条路语义一致。
|
2026-09-15 12:14:25 +08:00 |
|
|
|
acc94723fd
|
fix(memory): 打通场景/索引/召回残余矛盾点，清理死代码与冗余索引
- DecaySceneRefs 真半衰期：新增 scene_refs.decayed_at 作计时起点，
每个引用至多每 halfLife 衰减一次。此前只按 created_at 判龄 + 每次
心跳对半砍，30 天阈值配 60 分钟心跳会在几小时内清空老关联（不是半
衰期是骤死）；时间基准改走 SQLite datetime('now')，不再与 Go 本地
时间混用。
- Indexer.syncIfStale 基线口径与 Sync 对齐（min(实体数, 全量召回上限)）：
实体数超过上限时原实现永远不相等，每 retrainInterval 全量重训一次。
- EnsureScene 去掉从不使用的 Situation 参数；修正 EnterSceneWithHint /
resolveTurnScenes / 测试里「声明场景会学整轮指纹」的过时注释（实际
刻意不学，否则会吃死被动路）。
- SituationFeature.Weight 补 peer_group → wFeatPeer：此前落到 default
话题级 0.4，群聊身份被降级成软信号。
- RecallBySituation 注释改为与实现一致（相似度只决定命中哪些场景，
不参与每条关系排序）。
- 移除只被测试使用的 EmergentScenes（SceneStats 已含 origin/strength/
features，完全覆盖）。
- 清理与 UNIQUE 隐含索引重复的 idx_entity_name / idx_sentences_text。
- 新增 TestSyncIfStaleBaseline / TestPeerGroupWeight，衰减测试补「同一
半衰期内不重复衰减」用例。
go build/vet 干净，internal/... 全绿。
|
2026-09-15 10:20:40 +08:00 |
|
|
|
49695c38f3
|
feat(memory): 场景双通道——主动声明与被动涌现并存，且互不吞噬
按「声明式的也要支持，相当于主动被动两条路」落实。此前两者只是恰好并存，
没有边界，实测会互相吃掉（下面的坑就是）。
- Triple.Scenes []string（多值）：一轮写下的记忆**两条路都挂**。
只挂一条会丢东西——只挂声明则细粒度唤起丢失，只挂涌现则首次交互
（场景还没长出来）没有兜底。单值 Scene 保留兼容。
- TurnScene：Primary 用于写（优先涌现场景，首次退到声明场景兜底），
Keys 是两条路的并集，用于召回（声明+涌动的场景一起进 RecallByScene）。
- EnterSceneWithHint：主动路 EnsureScene（声明即建场景，不等第二次），
被动路 EnterScene（指纹聚类）。写侧由 executeToolCall 把本轮场景集合
传给 memory_commit，模型不需要知道"场景"这回事。
踩到并修掉的坑（两条路互相吞噬）：
最初让声明场景也吸收**整轮指纹**，于是 chan:qq 的相似度永远是 1.0，
把后续所有同类轮次全部吃掉 → 被动路再也长不出更细的场面，
实测 turn2.Emergent=true 但 Primary 仍是 chan:qq、没有 auto: 场景。
修法：给场景加 origin（declared/emergent）：
- 被动聚类只认 origin='emergent' 的场景（声明场景不进相似度空间）；
- 声明场景的特征**只从键自身解析**（chan:qq/peer:group_1 → {chan:qq, peer:group_1}），
白名单 kind（chan/peer/peer_group/tool/topic/part），不猜——
「老大2026-09-04_12:27_qq私聊图片」里的 12:27 也是 kind:value 形态，
放进特征空间就是往相似度里灌垃圾（有测试钉住）。
- 声明路的泛化靠**层级键前缀**（chan:qq 覆盖 chan:qq/peer:x），机制各归各。
- memgc -scene-stats 增加 [declared|emergent] 与 strength/features 两栏，
可直接观察两条路各自在长什么。
新增/改写用例：
- TestDeclaredAndEmergentBothLearn：首次交互兜底到声明场景 → 第 2 轮长出
细粒度涌现场景且**优先用于写入** → 声明场景不进相似度空间（防止压死被动路）
但仍走声明键取回 → 两条路都进召回集合 → 声明键特征解析与白名单。
- TestEffectiveScenes：多值+单值合并去重保序。
go build/vet 干净，go test -count=1 ./... 全绿。
|
2026-09-15 09:37:29 +08:00 |
|
|
|
bb7e7979ae
|
fix(memory): SceneStats 的 strength/features 不再说谎
- 旧行经 ALTER 加列后 strength 为 NULL，直接 SELECT 会显示成 0（实际是 1 次）；
改为 COALESCE(strength,1)，并补上 features 计数（场景长出了几个特征）。
- 两栏一起看才能判断「场景是不是真在涌现」，而不是被一次性写出来的。
|
2026-09-15 09:29:46 +08:00 |
|
|
|
d4f9a12db0
|
feat(memory): 场景从「声明」改为「涌现」——场面指纹自己长成场景
上一版场景是声明/派生的：调用方写 scene="chan:qq"，或由通道机械派生。
那不是涌现，是贴标签——标签谁定、怎么定全靠人。按「像人一样：干了什么事，
后续类似场面自动唤起对应记忆」的要求重做。
机制（全部取自运行时可观察量，无需模型配合、无需人工标注）：
- **场面指纹 Situation**：每轮采集 `chan:xx / peer:xx / peer_group:xx /
tool:xx / topic:xx / part:xx`。权重按种类：通道与对象最强（1.0），
工具次之（0.8），话题是软信号（0.4），时段最弱（0.2）。
- **归属判定用加权 Jaccard**（不是字符串相等）：共享特征权重和 / 并集权重和。
加权是必须的——`chan:qq` 与 `topic:排班` 的证据力差 2.5 倍，不加权会让
一次偶然的话题重合把两个不同场面并成一个。
- **涌现**：同类指纹重复到 minSceneEvidence=2 次才长出场景
（首次只登记 situation_evidence 足迹）。一次性的交互不是「场面」，
给它建场景会让库被一次性事件撑满、之后每次路过都召回一堆只发生过一次的事。
- **强化**：场景每次重现 strength+1、并入新特征。
- **唤起**：RecallBySituation 按**相似度**取回（阈值 0.35，比归属阈值 0.5 低
——想不起来是损失，多想起一条只是多几行上下文），与措辞无关。
- **遗忘**：DecaySceneRefs 按半衰期让久未重现的关联淡出，低于 floor 直接删；
已接进 archive 心跳（半衰期 30 天，比「这个月没做过这类事」更久）。
三个必须讲清的边界：
1. 一轮只解析一次场景（TaskFrame 缓存）——多解析一次就多记一次强度，
「工具调得多」会被误读成「这个场面更常出现」。
2. 声明与涌现**并存**：声明是「我知道这是哪个场面」（插件注入点最清楚），
涌现是「这轮看起来像哪个场面」。两者都进召回。
3. 记忆挂载全自动：memory_commit 没写 scene 时落到本轮涌现场景，
模型不需要知道场景这回事。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例（核心证据）：
- TestSceneEmergesFromRepetition：首次不建场景 → 第 2 次同类场面长出场景 →
同场面**不同话题**仍并入同一场景 → 换通道的场面自己长出独立场景（共 2 个）→
强度随重现增长、特征多条。全程没有任何人声明过场景键。
- TestSceneRecallsBySituationNotWording：场面里写下的规则，换措辞后仍被
自动唤起（含原句），无关场面不唤起。
- TestSceneRefDecay：一个半衰期权重减半、第二个半衰期低于 floor 被清掉，
仍在重现的场景不受影响。
- TestSituationFeaturesFor：指纹维度齐全、归一化、数值 group_id 转换、nil 安全。
|
2026-09-15 09:27:39 +08:00 |
|
|
|
b7e47a1b1f
|
feat(rel): 文档层接入场景（document 节点挂场景）
场景贯穿流水线的 doc 层补完：
- 新增 TagSceneDocument，linkBlocksToDocument 里建文档节点时一并挂场景；
- RecallByScene 返回该场景下的文档 id（可枚举「这个场面有哪些文档」）；
- 文档场景由**来源派生**（chan:<source>），不存冗余 Doc.Scene 字段——
存一份会随来源改名而说谎，是同一事实的第二份真相。
go build/vet 干净，go test -count=1 ./internal/memory/ ./internal/agent/core/ 全绿。
|
2026-09-15 09:16:22 +08:00 |
|
|
|
9d45cd0277
|
fix(rel): 场景贯穿流水线到块层 + 编辑不再丢置信度/场景 + 构建默认带 onnxruntime
三件事，前两件是上一轮热部署暴露/遗留的真缺陷。
1) 热部署差点静默降级（已修）
`make build` 之前**不带任何 tags**，而发行构建（deploy/packaging/build.sh）
默认 HOMED_TAGS=onnxruntime，package-linux.sh 还会直接拒收非 onnxruntime 二进制。
实测差异：33MB vs 84MB；启动日志里
「multimodal space active: provider=chineseclip dim=512」整行消失、
少加载一个插件（chinese-clip/qwen3vl provider 降级）、
静态词向量退回 fallback。即「随手 make build」与「发行构建」不是同一个东西，
而部署时无从察觉。
修：Makefile 的 build 默认 HOMED_TAGS ?= onnxruntime（与打包脚本一致），
构建后自动校验二进制里有没有 onnxruntime，缺了就打 WARN。
生产已按此重新构建部署（v1.4.0+hotfix.d98bf51，已核实 provider 行回归）。
2) memory_edit 每跑一次就静默降级一次（新）
memory_edit 是「按包含匹配 Purge + 写新三元组」，中间那一步把旧关系的
置信度、原句、**场景引用**全丢了：置信度被重置成默认 1.0，场景钉死的记忆
被打散成无场景。而关系复审心跳（reviewLoop）走的正是这条路——每轮复审都
在无声地削记忆质量。
修：编辑前用 FindRelations 精确取回旧关系，把置信度/原句/场景带到新三元组；
新增 ScenesOfRelation。Purge（hard/soft）与 PurgeNoise/PurgeOrphans 之后
统一清理悬空 scene_refs，SceneStats 不再说谎。
3) 场景贯穿流水线到块层（按「rel 应贯穿整条流水线」的设计）
此前场景只到 relation/entity：块（L0/L3 一等记忆块）没有场景，于是
「那场 QQ 对话里发过来的那张图」在场面重现时永远取不回来。
- MemoryBlock.Scene + memory_blocks.scene 列（幂等 ALTER 迁移）。
- scene_refs 增加 ref_text 承载字符串主键（块/文档 id 不是数值）。
**不能只 ALTER ADD COLUMN**：唯一约束要从 (scene_id,kind,ref_id) 变成
含 ref_text 的四元组，而 ALTER 改不了约束——旧约束会让「同场景第 2 个块」
直接冲突（只在多块场景暴露）。改为按列探测后整表重建并搬运旧数据。
- PutMemoryBlocks 同事务挂 scene_refs(kind='block')；无场景重写不覆盖已有场景
（否则一次无场景重写就静默抹掉挂载）。
- RecallByScene 返回块；FormatContext 增「场景素材」段（模态 + 文本/短 digest），
上限 3 条。
- 生产者接线：attachBlocksToSentence 让块继承承载它的三元组的场景；
linkBlocksToDocument 让文档的块继承文档来源场景（QQ 归档的图挂 chan:qq）。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：场景块（取回/同场景多块/无场景重写不抹场景/悬空引用清理）、
**旧表结构迁移**（降级成旧 scene_refs 后重开，旧数据保留且多块可写）、
场景素材注入、FindRelations+ScenesOfRelation 编辑搬运闭环。
生产：已重建（-tags onnxruntime）并原子替换 /usr/local/bin/homed + 重启，
35 插件全加载、panic/fatal=0、chineseclip 空间 active。
|
2026-09-15 09:03:36 +08:00 |
|
|
|
d98bf512e1
|
feat(memory): 场景式关联召回——给记忆节点赋场景引用，场面重现即取回
背景（实测）：带条件的记忆召不回来。生产库里明明有
「QQ回复禁用Markdown格式 --规定--> 纯文本不用Markdown」「老大 --偏好--> 同左」，
但输入「QQ回复格式」时命中 148 个实体、规则排第 32，注入只取前 5——规则根本没进去；
输入「在吗」这种零内容词的短消息，向量路反而灌进 17 个毫不相关的实体。
根因：词法/向量召回都建立在「字面或语义相似」上，而条件式记忆（在什么场合该怎么做）
约束的是**场面**不是话题。用户措辞不重合时它天然召不回；措辞太宽（"QQ"）时又被同形
命中淹没。另一处：自动注入只给实体名索引，而规则本体长在关系上（relation_type + object），
即使命中名字也拿不到「纯文本不用Markdown」这句正文。
改动：把「触发条件」升成一等索引维度。
- schema：新增 scenes(key) + scene_refs(scene_id, kind, ref_id, weight)，
kind ∈ relation|entity。刻意不建外键：节点可能先于引用被清理，
悬空引用由读取侧 JOIN 过滤，级联删除会把清理变成跨表事务。
- 场景键是分层字符串（`/` 分隔，由宽到窄）：chan:qq、chan:qq/peer:group_123、
tool:qq_get_message。NormalizeSceneKey 归一（小写、空白/标点→_、按 `/` 分层），
空白不算层级——否则「老大2026-09-04 12:27 QQ私聊图片」这种来源名会被拆成伪层级。
- 写入即挂场景：Triple 新增 Scene 字段，commit() 在同一事务里把「关系 + 两端实体」
挂到场景上（同事务是必须的：关系进库但引用丢了 = 这条记忆永远无声地召不回来）。
- 召回：RecallByScene 前缀匹配（chan:qq 取回 chan:qq 及所有更窄场景；用 `/` 兜底
防止 chan:qq 吞掉 chan:qq2），按 weight（=写入置信度）降序，返回**关系全文 + 原句**。
- 注入：BuildContextInScene 在词法/向量之外叠加场景路，FormatContext 把场景块排在
最前（规则对行为的约束强于话题相关的实体名），上限 8 条 + 原句截断 60 字；
场景实体不在【记忆索引】里重复占位。BuildContext(input) 保持原语义（无场景）。
- 当前场景推导：payload.scene 显式声明 > 通道（chan:qq）> 工具（tool:qq_get_message），
并列命中不取交集。qq 通道本身 RecallPolicy=none（到达的是中断元文本），
真正召回在 qq_get_message 工具上——现在那一步同时带上 chan:qq 与 tool:qq_get_message。
- 写入侧：memory_commit 新增 scene 参数（逐条 triples[].scene 优先，顶层 scene 作批次默认）；
docToTriples 按文档来源自动带 chan:<source>（QQ 归档的知识天然属于 QQ 场面）。
不做自动猜测：猜错的场景会把无关记忆钉死，之后每次进入该场面都被注入。
- 存量引导：memgc -tag-scene <键> -entity-glob <GLOB>。用 GLOB 而非 LIKE——
LIKE 对 ASCII 不区分大小写，`%QQ%` 会把对象带 /home/newqqagent 的路径类记忆
（生产数据目录、email-mcp、dify-ops 路径…实测 7 条）一起卷进 QQ 场景。
- 清理对齐：PurgeNoise/PurgeOrphans 之后顺带删悬空场景引用，并提供
PurgeStaleSceneRefs；memgc -scene-stats 看场景规模。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：场景键归一（含超长/分层/空白）、写入即挂场景（两端实体进、未标的实体不进）、
前缀语义（含 chan:qq2 反例）、weight 排序与 limit、GLOB 存量引导（dry-run 不写库）、
清理后无悬空引用、场景注入面（关系全文+原句+不在索引重复占位）、
agent 侧 sceneKeysFor 优先级（显式声明 > 通道 > 工具、数组形式、nil 安全）。
生产库实测（先 sqlite3 .backup 到 graph.db.bak-20260915-081043 再写）：
把 22 条 QQ 相关关系标进 chan:qq（GLOB *QQ* 19 条 + *qq_* 3 条）。同一批输入前后对比：
- 「在吗」：改前注入 17 个无关实体；改后场景块直接给出「QQ回复禁用Markdown格式
--规定--> 纯文本不用Markdown」等规则正文（零字面重合也能召回）。
- 「QQ回复格式」：改前规则排第 32 被截掉；改后排在场景块首位。
- 「帮我发个语音」：场景规则置顶，词法路的 qq通道语音输入 等仍在其后。
|
2026-09-15 08:13:52 +08:00 |
|
|
|
b37141f3f5
|
fix(memory): doc→graph 补回常用词闸门 + 存量噪音/孤立节点清理
问题：图记忆里堆着「结果(192) / 什么(59) / 哪个(99) / 待命(176) / 报告(174) /
context_archived(43)」这类节点，mention_count 冲到几百、度数只有 1~2——
占着热实体位、挤满召回预算，却不带任何结构。
根因：这层过滤原本存在，后来被换掉没补回。1cb3e87（NLP 三元组提取系统）
把 doc→graph 从「CutExact 滑窗词链」换成依存句法提取器时，CutExact
（去停用词 324 条 + validEntityName + 去重，注释至今还写着「用于 doc→graph
蒸馏」）失去了唯一生产调用点，只剩 cut_test.go 在调它。此后落库闸门只剩
validEntityName——它挡的是「不像名字的字符串」（2–50 字符、含字母），
完全不挡「像名字的常用词」。
改动：
- 新增 internal/memory/noise.go：IsNoiseEntity 收敛判定（停用词 /
context_archived / 模板摘要回声），FilterNoiseTriples 给自动填充路用，
PurgeNoise + PurgeOrphans + cmd/memgc 供存量清理（默认 dry-run）。
判定刻意保守：只拦三类客观噪音，开放类词（报告/对话/处理）不拦——
它们挡不挡是领域决策，见函数注释。
- docToTriples 接上闸门（用户点名的「文档常用词」路）。
对话蒸馏路 extractKeyTriples **不接**：CutExact 当年也只挂 doc→graph，
且 pipeline_test 明确断言「我 --读书--> 杭州」必须抽出（代词主语是该路
既定行为），是否拦属行为决策，已在代码注释里写明并留给使用者定夺。
- cut.go 补全封闭类常用词：咱俩/咱们（我们/你们/他们 早有）、任何/此/本/
其中/以及/那么/这样/那样/一样/还有/还要/只是/老是/全部/所有/有些/一些/
别的/其他/其余/各自/本身/方位词/部分/方面。
「不能/不会」试过又撤回：它们是 embedder tokenize 的实词路径，
加进停用词会让 static_embedder 的领域聚类用例翻转（今天天气句与股票句
的相似度大小关系反了），属真回归，不留。
- graph.go：CleanupOrphanedSentences 拆出 Locked 版供 PurgeNoise 复用。
验证：go build/vet 干净，go test -count=1 ./... 全绿。
新增用例：IsNoiseEntity 判定表、FilterNoiseTriples 顺序与边界、
PurgeNoise（统计/幂等/dry-run 不写库/不误删仍被媒体块边引用的句子）、
PurgeOrphans（识别/不误判有边实体/幂等）、docToTriples 噪音闸门与
模板锚点不被误杀。
存量清理（生产库 /home/newqqagent/memory/graph.db，先用 sqlite3 .backup 备份
到 graph.db.bak-20260915-073210）：
- 噪音实体 29 个 + 其关系 59 条
- 零关系孤立实体 25 个
- 结果：实体 778→724，关系 639→580；sentences 3 条与 block_edges 3 条原样保留
（媒体块引用不被误删），PRAGMA integrity_check=ok、无悬空关系/块边。
- 运行中的 homed 无需重启：下一个 archive 心跳会 Indexer.Sync 重建实体名向量索引。
|
2026-09-15 07:47:16 +08:00 |
|
|
|
94995eaa64
|
fix(memory): 修图记忆召回的两处能力缺失（关系重复 + 原句不回显）
针对 memory_recall / 自动注入这条图记忆召回链路的实测复核：
- Recall(depth>1) 跨层不去重：每层都用已累积的 entityIDs 查邻接，
上一层刚产出的关系会在下一层被反复查回并再次 append。实测
小明→小红 在 depth=2 出现两次，memory_recall 的 10 条关系预算被
同一句话刷屏、真正的新关系（小红→小刚）被截断。改为按 relation ID
跨层去重（实体本就已去重）。
- memory_recall 从不回显 sentence_text：工具 schema 明写「填了才能日后
从图谱回到原文」、Recall 也已 JOIN 出句子，但输出只给实体名与关系类型，
该字段形同虚设。抽出 formatRecallRelations，对非空原句截断 60 字附在
关系行后；超过 10 条仍截断并提示。
测试：TestRecallWithDepth 增补去重与精确条数断言；
新增 TestFormatRecallRelations_SurfacesSentence / _Truncates。
go build/vet 干净，go test -race ./internal/memory/ ./internal/agent/core/... 全绿。
|
2026-09-15 06:48:36 +08:00 |
|
|
|
6afe361804
|
fix(memory): 记忆层启动接线/并发/落盘一致性整备
按设计方案整顿记忆系统，收敛一批"单测照不出、只在长跑生产里暴露"的缺陷：
- 启动接线：initMemoryStack 残留 `defer distiller.Stop()`，规则蒸馏
10min 心跳启动即死。改为由调用点 cleanup 停机，并补 Stopped() 探针 +
TestInitMemoryStackKeepsDistillerRunning / TestStartKeepsLoopRunningUntilStop。
- L0 相关性上下文：SetDenseSpace 注入稠密空间时回填已有事件的稠密向量，
否则旧事件走稀疏余弦、新事件走稠密余弦，同一次 Prune 里两种尺度混排。
- 文档检索：QueryScored 访问计数从读锁内写移出（-race 竞争），更新后置脏，
优雅关停可落盘、FindColdDocs 冷度判据跨重启不再失真。
- 蒸馏管线：只 flush 未落盘记录（persisted 标记）、蒸馏成功后从 raw 文件
删除对应行、原子写文件，修重启重复蒸馏导致 mention_count 膨胀。
- 图库：全量 Recall 加实体上限（内部整备路径，防大图整表进内存）；
ClearSentenceID 补写锁；Commit/upsertEntity 计数语义注释澄清。
- 索引器：recalled 去重集加 FIFO 上限，防长跑进程自动注入越来越沉默。
- 文档/媒体注释修正；README 记忆层流程对齐跨模态召回。
验证：go build ./...、go vet、go test -race
./internal/memory/... ./internal/agent/core/... ./cmd/homed/... 全绿。
|
2026-09-15 06:32:36 +08:00 |
|
|
|
3a780384d0
|
refactor(memory): 裁剪与召回收敛到唯一入口 memoryPass
把「踢出去（prune）」与「取进来（recall）」从两处各写一遍，收敛为
memoryPass(query, trigger, prune, recall) 单一入口，统一：
- 同一份清洗后的 query（避免噪声带偏相关性打分）；
- 同一次 token 预算与召回截断；
- 同一条带 trigger 的审计日志（谁、据什么触发了哪种操作）。
落地：
- 新增 memorypass.go：memoryPass + pruneByQuery（原 pruneOnInput 的执行体）；
- pruneOnInput 只解析声明，执行委托 memoryPass；
- stepToolAfter 的裁剪/召回改为一次 memoryPass 调用（去掉重复的 topK 逻辑）；
- 抽出 recallText，输入侧 buildTaskMemoryContext 与工具侧 recallTextFor 共用；
- 输入侧召回 query 改用 CleanInput（清洗文本），与裁剪侧同一语义；
- QQ qq_get_history 补齐声明 ContextPolicy=prune + RecallPolicy=auto
（内容类工具：真实聊天正文既当轮用完即裁，又据正文召回）。
测试：新增 memorypass_test.go，锁死 no-op / 两轴同时生效 / 正交不互相触发 /
输入侧用清洗 query。go build/vet 干净，internal/... 全绿，qq 插件模块测试通过。
|
2026-09-14 23:32:41 +08:00 |
|
|
|
b792a94b84
|
feat(memory): 新增可声明的召回轴 RecallPolicy（与 prune 正交）
问题：召回（把 L2/L3 相关记忆注入本轮）此前不可声明、也不受任何 SDK 字段
控制——它只在任务开始时对 f.Input 无条件跑一次。于是 qq_get_message 取回
真实正文后只触发 Prune（裁剪），从不触发召回；而中断通知的 meta 文本反而
会去召回（词不对题，命中一堆泛实体）。
改动：
- SDK 新增 RecallPolicy(none|auto) 轴，落在 InjectOptions / ChannelDef /
ToolDef 三个声明面，与 ContextPolicy 正交（裁剪 vs 召回）。默认值与
prune 刻意相反：输入/注入默认 auto（保持既有「每条输入都召回」），
工具默认 none（工具输出多为噪声，按需声明）。
- 内核：recallDeclared 按 注入点 > 通道 > 默认auto 解析；输入侧用它决定
是否注入记忆索引；工具侧 ContextPolicy/RecallPolicy 共用同一份清洗后
query，一次相关性过程分别 prune / recall；召回以 system 消息挂到消息
末尾（同任务内替换而非累加）。
- 管线：proc RPC（inject/register + 校验）、lua 键、io payload 全量透传。
- QQ 插件：中断与 qq 通道声明 RecallPolicy=none（meta 不是内容）；
qq_get_message 声明 RecallPolicy=auto（取回正文后据正文召回）。
测试：新增 recallpolicy_test.go（core）与 proc 校验用例；
go build ./... 通过，go test ./internal/... 全通过，SDK 模块与 qq 插件测试通过。
|
2026-09-14 23:14:38 +08:00 |
|
|
|
bc32fbbc98
|
feat(webui): 阶段管道的工具格改为滚动展示最新一条调用
「工具」是循环格：一轮里可能调几十次工具/输出通道。此前每一次都追加成
chip，这一格被撑成一长条，反而看不出「现在在调什么」。改为固定一行的
滚动视口——只留最新一条，右侧给出本轮累计次数；新调用到来时旧条向上
滚出、新条滑入（morph 就地改文本不会重放 CSS 动画，故摘类 + 强制 reflow
+ 重加类）。并给 chip 名称加 .rt-chip-t 承接省略号，窄框不再硬切半截。
配套 TestStagePipelineToolCellShowsLatestOnly 钉住该口径。
|
2026-09-14 20:07:29 +08:00 |
|
|
|
0faf9fb4e8
|
style(webui): 队列/管道列宽下限收到 100px，消掉「4 个 + 1 个」孤行
118px 时容器 540px（小窗口侧栏展开的宽度）只放得下 4 列，第 5 个框
落到第二行且后面四个位置全空 —— 正是「看着空」的那种观感。
收到 100px 后 540px 也能一行放下 5 个；配套给 .rt-qmeta 加 wrap，
窄框里「登记/抢占」两枚迷你条换行而不是撑破框。
五档实测（1400/1100/900/700/480）：1400/1100/900/700 都是 5 框一行
（200/140/100/120px），480 为 3+2；均无横向溢出，框内元素无越界。
|
2026-09-14 18:45:36 +08:00 |
|
|
|
f89e57a732
|
feat(webui): 阶段管道与中断队列统一为等大表框，字体加大加粗
问题：阶段管道是「小圆点 + 一条连接线 + 9px 小字」，中断队列是五行
「名字 | 进度条 | 元数据」的扁条 —— 两块都远小于旁边的 KPI 框，中断队列四级
全为 0 时四行几乎全是空白，既占高度又难看。
改法：两块统一成同一套视觉语言 —— **等大表框**（与 KPI 同一种骨架）。
阶段管道（.rt-pipe-row / .rt-pipe-cell）
- 5 个等大框，框内 = 图标 + 阶段名 + 本阶段本轮发生的事件 chip。
- 阶段名 9px/500 → 13.5px/700；图标 12px → 15px。
- 当前阶段整框点亮（accent 描边 + 淡底 + 内阴影），不再靠一个小圆点表意。
- 删掉圆点、连接线、滑块把手那套已死的 CSS（.rt-pipe-track/.rt-pipe-knob 等）。
中断队列（.rt-queues / .rt-qcell）
- 五行扁条 → 5 个等大框（L4/L3/L2/L1 + 排队），一行排开。
- 框头级别名 16px/800、深度数字 26px/800（原来深度只是行末一个小数字）。
- 级别色同时用在框头、点亮格槽、有积压时的整框描边 —— 一处配色贯穿。
- 排队队列无级别，用虚线框与四级中断区分（另一**类别**，不是另一优先级）。
- 保留可见格槽：0 时也有形状，不会变回一片空白。
列宽自适应：两块共用 repeat(auto-fit, minmax(118px, 1fr))，
118px 而不是 150px 是为了让 640–740px 容器（窄屏侧栏收起后的宽度）也能
5 个框排一行，不出现「4 个 + 1 个」的孤行。chip 补 min-width:0 以免撑破窄框。
顺带清掉一条无用的旧 .rt-chip 规则（与新规则重名且只被阶段事件用到）。
实测（现网 CDP，1400/1100/900/700/480 五档）：
- 1400/1100/700px：5 框一行（200px / 140px / 120px）；900/480px：换行且框仍等大
- 五档均无横向溢出
- 字号：阶段名 13.5px/700，级别 16px/800，深度 26px/800
- 注入一轮轨迹：输入=输入|行动=思考|工具=qq_get_message x3 qq*|输出=生成|结束=完成
- 注入 L3=3/排队=2：L3 描边 rgba(255,166,87,.55)、框头与点亮槽同为琥珀色；
排队绿框；空的 L4 保持默认描边（首次读到的默认色是 0.25s 过渡中途，非 bug）
- chip 未溢出所在框；总览/侧栏/顶栏渲染文本无 emoji
|
2026-09-14 18:38:08 +08:00 |
|
