|
|
d17c18665c
|
fix(remotedevice): 设备通道名改用 - 分隔并派生合规名（v1.3.0 部署后 agent 完全不应答的根因）
## 事故
v1.3.0 部署到生产后，**整个 agent 不应答**：任何对话都返回
`all 3 providers failed, last error: api error 403: model "claude-opus-5" is not allowed for this key`。
回滚到 1.2.2 立即恢复（部署前 403=0/成功对话=10，部署后 403=5/成功对话=0）。
## 根因（网关日志给出的原文）
```
tier 3 gozen/deepseek-v4.1-flash: api error 400: [invalid_request_error]
Invalid 'tools[299].function.name': string does not match pattern '^[a-zA...
```
设备的每设备输出通道名叫 `device/<id>`，内核按 `output_send__<通道名>` 生成工具 ⇒
`output_send__device/<id>` 里的 `/` 违反上游函数名规范 `^[a-zA-Z0-9_-]{1,64}$`。
上游不是"拒掉这一个工具"，而是**整条请求 400** ⇒ 网关 auto tier 全链条失败
（400/429/503 混在一起）⇒ 内核只能报"所有 provider 都失败"。
两台真实设备（waiter-fnnas / waiter-mainnas）一上线就登记了这种通道，于是必然触发。
## 修法（改插件，不改内核）
初版我在内核里加了"通道名净化 + 反向解析"层。用户否掉了这个方向，理由对：
**通道名是插件自己的声明，不合契约就该改插件**，不该让内核替插件擦屁股。
内核侧改动已全部回退（HEAD 干净）。
插件侧两处：
1. 分隔符 `device/<id>` → `device-<id>`（源码与来源标签统一，不留两套名字）。
2. 设备 id 是**外部输入**（设备自己声明），可能含空格/非 ASCII/超长 ⇒
`deviceChannelName()` 把它派生为**合规且唯一**的通道名：
保留 `[A-Za-z0-9_-]`、其它折成 `-`、主体截断到 32 字符（预算 64 = 13+7+32+7+…）、
发生截断或撞名时追加 id 的 6 位短哈希。同一 id 恒定同名；真名仍用于路由与日志。
核心契约写进了插件注释与 SDK 文档（见 SDK 仓同批提交）：名字若来自外部输入，
**在插件侧派生合规名**，内核不会替你净化。
## 验证
- 新增 `TestDeviceChannelNameIsLLMFunctionNameSafe`：恶意 id（空格/符号/非 ASCII/超长/
会折成同名的两个 id）都必须派生出**合法且互不重复**的通道名与工具名。
反向验证：把分隔符改回 `/` 即 FAIL。
- 生产两台设备派生结果：`device-waiter-fnnas`、`device-waiter-mainnas`
⇒工具名 `output_send__device-waiter-fnnas`（37 字符，合规）。
- 全量 `go test ./...` = 37 包 ok / 0 FAIL；`-race`（remotedevice + core）无 DATA RACE。
|
2026-09-13 13:07:24 +08:00 |
|
|
|
201a02839e
|
chore(meta): SDKCompatibleVersion 升到 1.3.0（内核已实现 SDK 1.3.0 的全部新增面）
SDK 1.3.0 相对 1.2.1 的公开面新增（`git diff v1.2.1..main -- sdk/` 逐条核对）：
- `InjectOptions.Priority` + `PriorityL1/PriorityL2/PriorityL3/PriorityL4`
- `UnregisterOutputChannel` + `OutputChannelUnregistrar` + `SetOutputChannelUnregistrar`
内核侧两样都已实现，故按既有先例（d1959cb 随"实现 SDK 1.2.0 新增方法"同步声明）在此声明：
- Priority：`applyInjectOpts` 落 payload → 调度器 `interruptLevel` 按四级中断阶梯调度，
L4 归内核自身与内核级插件；
- UnregisterOutputChannel：插件登记表的 `regOutputUnreg` + io 设备表注销
（远程设备 `device/<id>` 掉线即注销，不留死通道）。
不调新面的存量插件照旧可用（新增方法由插件调用、内核实现），无需重编。
|
2026-09-13 12:46:31 +08:00 |
|
|
|
f0be8cbaa5
|
feat(remotedevice): 设备能力 outputch 化 —— 每设备一个 device/<id> 通道 + 设备指令类工具补授权闸
用户指出 remotedevice 的能力应当 outputch 化。查证后发现比"应当"更严重：
设备方向**根本没有出站实现**。
## 查到的三个缺口
1. `devicectlDevice` 一直声明 `OutputCapabilities() = CapStructured`（对外宣称可作输出目标），
但 `Execute` 的 switch 里**没有 "output" 分支** ⇒ `output_send__devicectl` 必然拿到
`unknown device tool output`，回模型"通过 [devicectl] 通道发送失败"。
2. 全插件没有 `RegisterOutputChannel`，也没有任何 EmitOutput/output_send 路径：
设备方向只有「工具（请求-响应）」与「设备→agent 注入」，**agent → 设备是断的**
（唯一的下行通道是个 HTTP 端点 `/api/v1/device/push`，不在 agent 的工具/通道模型里）。
3. 寻址是聚合的：所有设备共用一个名字 `devicectl`，没有 `device/<id>`；且设备 caps 只在
插件内部软检查（`SupportsTool`），**绕过**了内核的 `AllowedOutputs` 授权闸 ——
驻留子只要拿到 `device_ctl_cmdrun` 就能指挥**任意**设备。
## 按方向切分（不是一刀切）
**出站/消息类 → 每设备一个输出通道 `device/<id>`**（与入站同名）：
- 上线注册、掉线注销（caps 由设备声明的 caps 映射：文本恒有；有屏→图/文件；
speaker→音频；可跑命令(cmd/cmdrun/cmdresult)或未声明已知能力→全能力，与
`deviceSupportsTool` 的旧设备兼容规则一致）。断连不注销会留下死通道骗模型。
- 于是自动获得：内核按 caps 在**发送前**拦（送图给纯文本音箱直接拒）；
`output_list_channels` 能列出设备；`AllowedOutputs` 可按设备收窄给驻留子。
- 上下线钩子用 `Registry.SetPresenceHandler`（**同步回调**）而不是既有的 `ChangeChan`
（那是 select+default，缓冲满会丢事件；丢一次就留下死通道或漏注册）。
- `devicectl` 保留为聚合通道，并把它"声明了却不实现"的 output 补实：按
`meta.device_id`（或 meta 就是设备 id / args.device_id）路由；缺省时返回**可执行**的
报错（列出在线设备），而不是含糊失败。
**RPC 类保留为工具**（`devicedetect`/`screensee`/`computeruse`/`clipboard*`/
`device_ctl_status|cmdrun|cmdresult`）：它们的返回值（图像/命令输出/状态）必须进模型
上下文，做成通道会丢掉这个语义。
**并给设备指令类工具补上同一道授权闸**（core/toolcall.go）：`device_id` 指向的设备
必须是本 agent 被授权的 `device/<id>`。根 agent 默认完整授权 ⇒ 无行为变化；
驻留子收窄后，"拿到工具就能指挥任意设备"的缺口被堵上（新增 3 条 core 测试钉住）。
**设备端参考实现**（`internal/devicebridge/client/bridge.go` + waiter）：新增 `op=push`
分发与 `OnPush` 回调（文本/结构化；二进制走既有 `cmd_speech_*` → `DataHandler`），
waiter 把它打到终端。
## 设计口径（用户当场纠偏，已写进代码注释与 harness README）
**主动转发只有 webui 与 cli 两个交互界面**（webui 订阅 EventAgentOutput 渲染气泡、
cli 用同步回程写回终端）。其它通道一律要求 agent **显式** `output_send__<通道>`。
我第一版给 remotedevice 加了 `EventAgentOutput` 订阅来自动回投设备——那是凭空造了
第三个转发者，违背"输出是 agent 的主动调用"，已撤回（该测试一并删除）。
## 验收
- 单测：caps 映射词表；设备上线→注册通道（含同名 inputch）/掉线→注销；push 真落到
WS 设备；聚合通道 `devicectl` 的寻址（无 device_id 报可执行错误、按 meta 投递、
指定不存在设备报错）；core 授权闸 3 例。
- 全量 `go test ./...` = 37 包 ok / 0 FAIL；`-race`（agent/plugins/plugin/devicebridge/sdk）干净。
- **真二进制端到端**（私有 netns + mock LLM + 真 WS 设备客户端 scripts/kernel-stress/devclient.py）：
设备上线 → 通道表出现 `device/pydev-1`（caps=[text file image audio structured]，由
`caps:["cmd"]` 映射）→ agent 经 `output_send__device/pydev-1` 主动发送 → 设备收到
`{"op":"push","payload":"内核推给你的消息","type":"text"}` → 设备掉线 → 通道从表中消失。
|
2026-09-13 12:23:28 +08:00 |
|
|
|
6e6035141a
|
fix(resident/plugin): 二进制级压测暴露的三个真问题（DataDir 漏接线 / inputch 未登记 / create 不开工）+ 通道双向登记贯穿全部内建插件
在真实内核二进制（私有 netns + mock LLM + CLI unix socket）上做压力测试时，
下面三个问题**只有跑真二进制才暴露** —— 单元测试里都显式传了参数、没走插件加载，
所以全绿也照样漏。
## ① 根 agent 的 DataDir 没接线 ⇒ 驻留子永远建不出来
现象：模型调用 `resident_agents` 成功，但结果是
`创建驻留子需要 data_dir 或显式 temp_path`。
根因：`cmd/homed/main.go` 构造 AgentConfig 时没有 `DataDir`，
而驻留子的 temp 图库需要 `<data>/residents/<id>/graph.db` 这个锚点。
（单测里 `AgentConfig{DataDir: dir}` 显式给了，所以测不出来。）
修：main.go 接线 `DataDir: cfg.Daemon.DataDir`；并在工具层加**兜底 + 告警** ——
data_dir 为空时从主图库路径反推（`<data>/memory/graph.db` ⇒ `<data>`），
失败才报错。静默失败会让线上表现成"工具能调但永远建不出来"。
## ② 插件通道没登记为 inputch ⇒ "划入 inputch"必然失败
现象：`划入 inputch cli: inputch 未注册`。
根因：`cli` 插件只调 `RegisterOutputChannel("cli", ...)`，却用同一个名字
`InjectTextSync("cli", ...)` 注入输入 —— 内核 inputch 登记表里根本没有它。
（实测审计：内建 6 个插件里只有 0 个登记过入站通道；SDK 示例里只有 qq/weather 是对的。）
修两处：
- **全部内建插件显式登记入站通道**：`cli`/`agentcli`/`timer`/`webui`(+`http`, NoMemory)/
`clawhubadapter`（每个 OC 通道声明处）/`remotedevice`（`device/<id>` 懒登记，幂等）。
- `registry.go` 把隐式兜底改成**留痕的兼容网**：只有当该名字还没登记为 inputch 时
才兜底登记，并打日志说明"建议显式 RegisterInputChannel"。
实测：改完内建插件后，启动日志里兜底告警 **0 次**。
## ③ create 之后子不开工 ⇒ rounds 恒为 0
现象：`[agent] r1 started, waiting for IO interrupts` 之后什么都没有，登记表里 rounds=0。
根因：`TaskPrompt` 只进了子的**系统提示词**，从没作为输入投给子。
修：create 即开工 —— 把任务提示词作为**第一条排队输入**投给子（排队而非中断：
创建是"安排工作"，不是"打断它正在做的事"）。
## 测试
- `TestResident_InputchTableAutoAndProactive` / `TestLightKernel_TraditionalContextNoTrimming`
随行为更新：create 会多跑一轮（任务提示词那轮也会写处理表），
断言改为"以创建时的表长为基线 + 等待新的一轮"。
- 全量 `go test ./...` = 37 包 ok / 0 FAIL；`-race`（agent/plugin/plugins）干净。
## 真实二进制压力测试结果（修复后）
私有 netns 里跑 mock LLM + 内核，用 CLI socket 驱动多并发连接：
- 密集：16 连接×12 输入 + 4 线程×20 次 L4 中断 → **274 任务 executed=274 / rejected=0 / errors=0**，
峰值排队 15、峰值待处理中断 76；
- 稀疏（中断每 3s 一次，压在排队任务的流式段上）→ **suspended=27 / resumed=27 / preempted=27**；
- 驻留子全链路：父建子（inputchs=["cli"]）→ 子开工 → 子 `notify_parent` → 父侧收到
`interrupt from r1/child/r1`（L3，且父被抢占 suspended/resumed=1）；
- 优雅退出：SIGTERM 后驻留子 temp 目录被清除、无残留进程。
|
2026-09-13 11:38:03 +08:00 |
|
|
|
aba1770701
|
fix(lightkernel): 传统上下文落到实处 —— 子不做策略性裁剪（并修掉裁剪估算的字节/rune 单位混用）
用户指出实现不自洽："子 agent 是传统上下文，没有裁剪"。查证属实：子仍走
`formatMergedTimeline` 的预算裁剪、也可能走 `pruneOnInput`（既裁剪又向 doc 记忆归档）。
即"动态上下文"（父专属能力）漏进了轻量内核。
## 三处闸门（按 isLightKernel() 判）
1. **拼装预算**：新增 `contextTokenBudget(b)` —— 父用动态上下文的 `ContextTokens`，
子用**整个窗口** `MaxContext`。两个调用点都改（`stepPrepare`、`rebaseFramePrefix`；
漏掉后者时 prepare 之后的重建仍会裁，实测就是这么被抓出来的）。
2. **pruneOnInput**：轻量内核前置返回 —— 不做按相关度裁剪、不向 doc 记忆归档。
3. doc 记忆 / 整理流水线：早已由 `a.memory == nil` 关闭（N2c）。
## "不裁"的准确含义
不做**策略性**裁剪（不按相关度挑、不归档），只受"模型能收多少"这个硬上限约束；
且在撞到硬上限之前，contextfull（90% 窗口）已按 L4 上报父 agent ⇒
**丢事件的决定权在父**（压缩/回收/销毁），不在内核。文档 §16.0.0 记录三处闸门表。
## 顺带修掉的既有 bug（单位混用）
`formatMergedTimeline` 逐事件估算原来是 `len(e.Source)+len(e.Input)+40` 再 ×2 ——
`len()` 是**字节**，而 `EstimateTokens` 是 rune×2 ⇒ 中文事件被高估 3 倍：
实测 2384 字的中文事件被估成 14398 token > 8192，于是窗口还有余量也提前 break、
把更早的事件整段丢掉。改为统一走 `EstimateTokens`（对父同样生效：中文长会话不再被过早裁剪）。
## 测试
- 新增 `TestLightKernel_TraditionalContextNoTrimming`：用**记录模型实收消息**的 provider
断言"更早的事件仍在"（为什么不看 TaskFrame：`prepareInputTask` 只做前半段，
消息在 `runTaskSteps`/`stepPrepare` 才拼出来 —— 我第一版断言就打在了空帧上）；
填充量取"超过动态份额、但仍在窗口内"，从而能区分父/子两种行为。
- 新增 `TestFullKernel_StillUsesDynamicContext` 作对照（父仍用动态份额）。
全量 go test ./... 37 包 ok / 0 FAIL；-race 干净。
|
2026-09-13 10:36:04 +08:00 |
|
|
|
cba33d2a6f
|
test(resident): 压力规模可用环境变量放大（RESIDENT_STRESS_N / RESIDENT_STRESS_ROUNDS）
默认仍是 8 子 × 12 轮（CI 友好）；要跑加重压力就放大：
RESIDENT_STRESS_N=64 RESIDENT_STRESS_ROUNDS=40 go test -race -count=2 ./internal/agent/core/ -run TestResident_E2EAndStress
实测已跑：
- 24 子 × 25 轮（-race）：通过
- 64 子 × 40 轮（-race -count=2，即 5120 轮次）：通过
|
2026-09-13 10:25:49 +08:00 |
|
|
|
2ebbdadcd6
|
feat(resident): N3–N7 驻留式子 agent 全量落地（生命周期/双向投递/处理表/contextfull/e2e+压力）
设计：docs/zh/resident-subagent-design.md §6/§7/§8/§9/§10。
## N3 生命周期（resident.go）
- `SpawnResident`：主库**受限句柄** + 自己的 temp 实例（`LightMemory`）⇒ 子的轻量内核；
划入 inputch（登记归属）、授权输出通道、注入任务提示词；为父登记 `child/<id>` 入站 inputch；
建独立 `IOManager`（共享通道登记表）；启动子。
- `DestroyResident`：停子内核、归还划入的 inputch（回到未分配）、丢弃 temp 目录、出登记表。
- `Stop()` → `StopResidents()`：**父退出必须销毁全部子、不留孤儿**（设计 §10 硬约束）。
- `Residents()` 登记表快照；`ResidentTable(id)` 父 pull 子的处理表（不打断）。
## N4 跨 agent 投递
- 子→父：`notify_parent` → 投进父的 `child/<id>` inputch，优先级 **L3**。
- 父→子：`SendToResident` → 投进子的 inputch，优先级 **L4**；
`isKernelLevelSource` 泛化为"该 agent 的上级"（`AgentConfig.KernelSource`）⇒
只有父能在子的阶梯上产生 L4（子内部一律 ≤L3）。
- 子的 contextfull → 父侧 `raiseKernelInterrupt`（内核级事件，带子标识，父侧 L4）。
## N5 inputch 处理表
- 子持有；`inputch_note` 主动写**优先**，轮末 `autoRecordInputch` 兜底 ⇒ 每轮必有记录。
- 压缩时清表（表记的是被压掉那段窗口的逐轮处理）。
## N6 contextfull（判据修正）
❗初版判据是"拼好的 `f.Msgs` 估算 > 90% 窗口"，**结构上永不成立**：
`buildMessages` 拿到的 `budget.ContextTokens` 由 `targetUsage = 0.8 × 窗口` 推出，
时间线**在拼进消息之前就被预算裁过**，`f.Msgs` 封顶在 ~80% 窗口。
（初版测试用一个比系统提示词还小的窗口才勉强越线 —— 那等于什么都没测。）
现判据 = **未裁剪的积累上下文**（`a.context.Recent(0)`）超过窗口 90%：
它超过就说明下一轮必须丢事件，这正是"上下文满"。
三处置：`CompressResident`（保留语义：`TrimKeepRecent` 保留最近 N 条 + 清表）/
`ReclaimResident`（取消语义：`ExportTriples` 读 temp → 父选出要保留的 → `Commit` 进 main → 取消该子）/
`DestroyResident`（立刻销毁并移除）。
## 工具面
`resident_agents`（父，单工具多动作：list/create/send/inspect/compress/reclaim/destroy）、
`notify_parent` + `inputch_note`（子）。声明条件式：父才有前者，子才有后两者。
## 验收
`resident_test.go` 五项：生命周期与不留孤儿、双向投递（含"子的主动消息不得以 L4 出现"）、
处理表（自动写 vs 主动写优先）、contextfull + 三处置、
**压力 8 子 × 12 轮（父→子 L4 与普通输入各半）+ 双向汇报 + 父退出清理**。
全仓 go test ./... 37 包 ok / 0 FAIL；`-race`（agent/memory/plugin）干净；
压力 `-race -count=3` 通过。
|
2026-09-13 10:20:06 +08:00 |
|
|
|
48cfa8fb6c
|
feat(lightkernel): N2c —— 轻量内核 profile（窄接口 GraphMemory + nil 即禁用整理面）
按用户指出的关键点（a.memory 多数使用点属"主 agent 整理记忆"与"记忆整理流水线"，
子不该有那些路径）实现，方案见设计 §16.0。
## 窄接口：只有 Recall + Commit
新增 `GraphMemory` 接口（memoryface.go）—— 按调用方实测分类后，真正"根与子都要"的只有这两个：
- `Recall`：上下文检索 / memory_recall
- `Commit`：自动写入路径的图部分 / memory_commit
新增 `Agent.graph`（共同面）与 `Agent.graphMem()` 访问器：
- `graph` 显式为 nil 时**回落**到 `memory` ⇒ 既有"只用 Agent 字面量设 memory"的测试无需改动
（原本会出现"必须同时设两个字段"的脚坑，实测踩到后去掉了）
- 轻量内核：`graph = *memory.LightMemory`，`memory = nil`
## nil 即禁用：整理面自动消失，不需要受限包装
子的 `a.memory == nil` ⇒ 既有的 22 处 `if a.memory != nil` 关卡自动禁掉全部整理面：
- 记忆整理流水线（distill.go 的 archive/review/merge 循环）
- 记忆块 + 媒体桥（graphmedia.go / medialoop.go）
- 记忆整理工具（memory_merge / memory_delete_entity / memory_block_merge /
memory_purge / memory_edit / memory_introspect）—— 它们本就在 `if a.memory != nil` 块内
唯一拆开的一处是自动写入 `commitTriplesWithMedia`：
图部分走 `graphMem().Commit`（父落 main、子落 temp），块/媒体部分仍由 `a.memory != nil` 守卫。
`executeMemoryTool` 的读路径改走 `graphMem().Recall`；整理类 case 加 `requireFull()` 闸门，
被直调时明确报"本 agent 是轻量内核：记忆整理不可用"，不静默降级。
## 验收（3 项新测试）
- `TestLightProfile_MemoryFaceWiring`：整理面为 nil、写入只落 temp（主库无子痕迹）、
读是并集（主库实体 + temp 实体都看得到）
- `TestLightProfile_OrganizeToolsAbsentAndRefused`：整理类工具**不进工具表**；
即便被直调也明确报"轻量内核不支持"
- `TestFullProfile_KeepsOrganizeFace`：对照，根 agent 仍保留整理面与整理工具
全仓 go test ./... 37 包 ok / 0 FAIL；-race（agent/memory）干净；gofmt 干净。
|
2026-09-13 10:02:02 +08:00 |
|
|
|
93aa942e1e
|
test(plugins): deepsearch E2E 不再带走共享搜索后端（附回归判据）
背景：E2E 临时目录里拉起的插件实例在 teardown 时执行了 `docker compose stop -t 2`，
把线上正在用的 SearXNG 关掉，表现为「搜索后端起不来」。
- integration_test.go：把 ConfigRegistry 暴露给测试环境（其余不变）
- deepsearch_e2e_test.go：
- forbidStoppingSharedBackend：测试实例一律 stop_searxng_on_exit=false
（配置表按内核约定先 RegisterDef 再 Set）
- 新增 TestRealPlugin_DeepSearchKeepsSharedBackendOnStop：停掉插件实例后，
6 秒内 healthz 必须始终 200 —— 判据落在网络层，直接钉住「跑测试不能断线上搜索」
验证：三条 E2E 全过，且跑完 healthz 仍 200、容器 StartedAt 未变（未重启）。
|
2026-09-13 09:55:33 +08:00 |
|
|
|
f0562915db
|
feat(memory): N2a 第二块砖 + N2d 数据面 —— 轻量图记忆装配（temp 可写/主库只读/并集）与回收合入
按用户确认的形态：**独立存储实例**（不给共享记忆层加 space 列）。
## LightMemory：子的图记忆装配（设计 §5.6）
temp 实例（独立存储，读写） ← 子的一切图记忆写入落这里，与子同生共死
主库受限句柄（只读） ← 子只能读（query_only 结构性拒绝写入）
子的查询 = 两实例各查一次 + **应用层合并**（并集）
- 写入**只落 temp**（`Commit` 不接受 main 方向）
- 并集合并规则：实体按**名字**去重（同名保留 mention_count 较大者）、
关系按 (源名, 关系, 目标名) 去重；结果排序确定（便于断言与展示稳定）
- 单侧查询失败不影响另一侧（只有两侧都失败才报错）
- `AllowWrite=false`（用户给的备选简化）：**没有 temp 实例**，子对图记忆完全只读，
写入被拒；读主库照常
## ExportTriples + 回收合入（设计 §9，N2d 数据面）
- `GraphDB.ExportTriples(limit)`：导出**活跃**三元组，把实体名一并带出
⇒ 合入侧直接复用 `Commit`（按实体名 upsert + 关系唯一约束）
- 回收主流程：子写 temp → 父导出 → **父选哪几条** → 写进 main。
未选中的**不进**主库；重复收割**幂等**（不产生重复实体）
## 验收（7 项新测试）
`light_memory_test.go`（5）：
- 写只落 temp、查询是并集、主库无子的痕迹
- **两个子的 temp 互不可见**（只有 main 共享）
- 写禁用时完全只读（无 temp 实例、写入被拒、读照常）
- 并集去重（同名实体只出现一次）
- 合并确定性（去重 + 排序 + mention_count 取大）
`reclaim_test.go`（2）：
- 导出只含活跃关系且带实体名、limit 生效
- 回收主流程（选中的进主库、未选中的不进、重复收割幂等）
全仓 go test ./... 37 包 ok / 0 FAIL。
|
2026-09-13 09:38:54 +08:00 |
|
|
|
818ce2698f
|
feat(memory): N2a 第一块砖 —— 主图记忆的受限句柄（query_only），子是"读得到写不进"
按用户确认的形态：**独立存储实例**（不是给共享记忆层加 space 列）。
## 结构性保证
新增 `OpenGraphDBReadOnly(path)`：以**受限句柄**打开图库 ——
连接保持正常打开能力（可读、可恢复 WAL），但 `PRAGMA query_only=1` 让
任何 INSERT/UPDATE/DELETE 被 SQLite **直接拒绝**。
为什么不用 DSN 的 `mode=ro`：只读连接在 WAL 库上无法自行恢复 -wal，
而主库在父 agent 手里是持续写入的。query_only 只堵写、不堵读，语义正好。
⇒ "子改不了主记忆"是**结构性**的，不靠调用方自觉；也不建表、不迁移
（库由父建好，受限句柄不会凭空造出一个空主库）。
## 设计文档
新增 §5.6「实现形态：独立存储实例（不做 space 列）」，写明轻量内核的记忆装配：
子的轻量内核
├─ temp 图记忆实例（独立存储，读写） ← 与子同生共死
└─ 主图记忆的受限句柄（只读）
子的查询 = 两个实例各查一次 + 应用层合并（并集）
回收时由父读 temp、选记录、写进主图记忆
并记录用户给的备选简化：`AllowTempGraphWrite` 开关（默认开）；设为 false 时
子对图记忆完全只读，没有 temp 实例、没有合入。
## 验收
`internal/memory/graph_readonly_test.go`（2 项）：
- 受限句柄读得到、写被拒（Commit/Purge 双双报错），且**主库不留痕迹**
- 库不存在时受限句柄的查询报错，而不是凭空建表后返回空结果
全仓 go test ./... 37 包 ok / 0 FAIL。
|
2026-09-13 09:32:29 +08:00 |
|
|
|
f7c3a4e81d
|
feat(channel): N1b —— 输出通道授权集合（三处过滤一致）+ 输出通道→目标 agent 的 inputch 解析
设计：docs/zh/resident-subagent-design.md §4.5（里程碑 N1b）。
## 输出通道授权集合（默认完整授权，父可收窄）
`AgentConfig.AllowedOutputs`（nil/空 = 完整授权）。三处过滤点必须一致，
否则会出现「列表里看不到、按名字还能调」的裂缝：
1. **工具表**：不为未授权的通道生成 output_send__X（模型看不到就不会调）
2. **列表工具**：output_list_channels 只列授权的
3. **调用点**：凭名字直调未授权的输出门必须被拒（纵深防御）
## 输出通道 → 目标 agent 的 inputch 解析
`ChannelRegistry.BindOutputTarget / ResolveOutputTarget`：
把输出通道解析成「目标 agent + 目标 inputch」，这是"输出可寻址到具体 agent"
（子→父、父→指定子）的**数据面**；真正的跨 agent 投递在里程碑 N4。
未登记的输出通道 ok=false —— 表示由传输层 device 自行处理（qq/webui 这类）。
已登记目标的输出通道，在 output_list_channels 里会标出「目标: <agent> / inputch <名字>」。
## 验收
`internal/agent/core/output_grant_test.go`（3 项）：
- 默认完整授权：全部输出门生成 + 列表含全部
- 白名单收窄：三个过滤点同时生效（工具表 / 列表 / 直调被拒）
- 目标解析：绑定/解析、未登记由传输层处理、列表标出目标、空名报错
全仓 go test ./... 37 包 ok / 0 FAIL。
|
2026-09-13 09:13:19 +08:00 |
|
|
|
a2dcd96fee
|
chore: 撤回误提交的未跟踪文件 internal/plugins/deepsearch_e2e_test.go
该文件是工作区里**别人 in-flight** 的未跟踪文件（我上一步用 git add -A internal/ 时被顺带收进来）。
它不是我这次改动的一部分，因此从索引里撤出，文件本体保留在工作区（仍为未跟踪状态），
由它的作者决定何时提交。
|
2026-09-13 09:07:02 +08:00 |
|
|
|
3c961b7bd7
|
feat(channel): N1a —— inputch 一等化（归属插件/归属 agent/容量/共享登记表）+ 单工具多视图总览
设计：docs/zh/resident-subagent-design.md §4.6（里程碑 N1a）。
## 用户要求
「父 agent 可以看到所有已注册的 inputch 以及 inputch 的划分情况，用**单工具多视图**方式构筑」
## 登记层（internal/agent/io/inputch.go）
inputch 是**最基本的输入路由单位**（由插件注册，一个插件可注册多个），
所以登记表以 inputch 为键，每条记录：
名字 / 归属插件 / 归属 agent(被划给谁) / 容量 / 默认回程 outputch / 记忆策略(ChannelDef)
- 新增 `ChannelRegistry`，设计成**可共享对象**（`*ChannelRegistry`）：
根 agent 与驻留子共用同一份，"划入/授权"才有意义；`SetChannelRegistry` 注入。
- **插件重载不得抹掉划分**：重复登记只更新「归属插件 + 策略」，
保留已有 Owner/Capacity/Output（否则一次 reload 就把父做的划分清空）。
- `Assign` 语义按设计 R6 默认：**读写授权，不转移所有权**（Plugin 与 Owner 分别记录）。
- 原 `inputChannels map[string]ChannelDef` 被登记表取代；`GetInputChannelDef` 保持兼容。
- `plugin.Registry` 注册时带上**归属插件名**（此前完全无归属信息）。
## 总览工具（internal/agent/core/inputch.go）
单工具 **`input_channels`** + `view` 参数（不是一堆小工具）：
all（默认）= 全部已注册（带归属插件）
mine = 划给本 agent 的
unassigned = 尚未划出的
by_agent = 划分情况总览（按归属分组）
detail = 单个 inputch 全字段（需 name）
未知 view **报错并列出可用值**（拼错不得被静默当成默认视图）；登记表为空时明确说明。
## 验收
- `internal/agent/io/inputch_test.go`：归属记录、重载保划分、Assign/视图数据面、
**跨 manager 共享登记表**、策略查询向后兼容 —— 5 项
- `internal/agent/core/inputch_test.go`：单工具多视图逐视图断言（含未知 view 与空表）—— 2 项
- 全仓 `go test ./...` 37 包 ok / 0 FAIL；`-race ./internal/agent/... ./internal/plugin/...` 干净
|
2026-09-13 09:06:50 +08:00 |
|
|
|
f2ec46480e
|
refactor(core)!: N0 无状态化 —— 删除 Agent.currentOutputChannel，通道只跟输入事件/帧走
驻留式子 agent 设计（docs/zh/resident-subagent-design.md）的里程碑 N0。
## 问题
`a.currentOutputChannel` 是 **agent 级可变字段**，只在 prepare 段写入，而被打断任务
恢复时**不重新 prepare**（resumeTask 只 rebase 前缀）。于是中断任务 prepare 时把它
覆盖成自己的通道，被恢复的任务再把回复发到**中断任务的通道**上——两个任务串台。
后果不只是标签错：工具提示词里那句"当前输入来源通道是 X，对应输出门工具是
output_send__X"会诱导模型**把回复主动发到错误的通道**。
## 两处一起改（用户指出的两件事）
1. **内核不应持有"当前通道"**：通道是随输入事件带进来的，路由发生在**进内核之前**，
输出是 agent 的**主动调用**。删除该字段，改为一律从输入事件推导
（`outputChannelOf(evt)`）或读本任务的帧（`f.OutputChannel`）。
2. **提示词不应预设 outputch**：删掉"当前输入来源通道是 X → 用 output_send__X"那两行，
改为"不要假设当前通道是固定值；先看消息本身与上下文的来源信息，不确定时先调
output_list_channels"。
## 改动面（把通道一路显式传下去，而不是读共享状态）
- `agent.go`：删字段
- `task.go`：新增 `outputChannelOf` / `isCriticalChannel`；帧记录通道；
安全点与 setCritical 用帧/事件推导；步骤内事件标签改用 `f.OutputChannel`；
`executeToolCall(f.CurTool, f.OutputChannel)`；`callLLMWithFallback(..., f.OutputChannel)`
- `process.go`：`chatStreamWithFallback` / `accumulateStream` 增加 channel 参数
（增量事件的 channel 标签由此而来）
- `stage.go`：`runStage` 从 `ctx.Extra["output_channel"]` 读（发起方写入）
- `eventloop.go`：`emitResponse` 用 `outputChannelOf(evt)`；stageCtx 带上通道
- `spawn.go` / `toolcall.go`：`executeSpawnChild` 的 parentChannel 由调用方（帧）传入
（子任务完成通知要回到**发起这次 spawn 的那个任务**的通道）
- `distill.go`：删掉 consolidation 路径里的赋值
- `tooldefs.go`：删掉提示词里的通道预设
## 验收
- `scheduler_channel_routing_test.go`（N0 守卫）：中断任务跑过之后，被恢复任务的
输出通道仍是它自己的（改前实测为 cli，期望 qq）
- `TestCriticalSection_ConsolidationMarked`：补上推导链
「输入事件 → 通道 → isCriticalChannel → scheduler.critical」的集成断言
- 全仓 `go test ./...` 37 包 ok / 0 FAIL；`-race ./internal/agent/...` 干净
- 残留 `currentOutputChannel` 引用为 0（只剩描述历史的注释）
|
2026-09-13 08:59:15 +08:00 |
|
|
|
158395bfdf
|
test(scheduler): 优先级压力测试（100 排队 + 100 中断各级混合、嵌套到 4 帧上限）
按需造一个固定内容的 fakeprovider，做两件事：
E4：混合载荷（用户指定的形状）
100 条排队输入 + 100 条中断（L1/L2/L3/L4 各 25）混合打入。每条中断都等到
“该被它打断的受害者正在跑”时才注入——调度器是单线程的，闭着眼睛猛灌只会
让绝大多数中断退化成排队，压力就压不到抢占/挂起路径上。
判据：200 个任务全部到达终态、Rejected=0、各级登记数=25、**各级抢占数都>0**、
排空后 Suspended==Resumed、每次“取消流式段”都换来一次挂起。
E5：嵌套到结构上限
排队任务运行中依次注入 L1→L2→L3→L4（每级都等上一级在跑）。判据：栈深峰值
恰好 4（= 结构上限，此时 canSuspend()=false），恢复顺序严格 LIFO
[L3,L2,L1,排队]，Suspended==Resumed==4。
顺带修掉两处：
- **Resumed 双计**：nextRef 弹栈与 resumeTask 各计一次，使“排空后
Suspended==Resumed”这条不变量失真。现在只在 resumeTask 计（nextRef 只负责选出）。
- 新增分级可观测：SchedulerStats.InterruptsByLevel[1..4] / PreemptsByLevel[1..4]。
只看总数会掩盖“总数一样但级别分布完全不同”，按级别验收才是这套调度器的判据。
注意 PreemptsByLevel 是“判定可抢占并进入 immediate”的次数，与 Suspended 不等价：
受害者可能在让位生效前就自行结束，此时抢占者只是“下一个运行”，没有挂起发生。
教训：provider 必须感知 ctx 取消。第一版没做，结果 LLM完成==任务数、挂起≈0——
抢占全落在“步骤之间”，流式段（真正需要保存/恢复现场的地方）一次都没压到。
验收：go test ./... 37 包 ok 0 FAIL；-race 全绿；压力连跑 3 次稳定；
新内核 go build 通过并真实启动冒烟 OK。
|
2026-09-13 07:31:32 +08:00 |
|
|
|
f3232000f4
|
feat(scheduler): L4 也归内核级插件 —— WebUI 终止按钮可用“立即打断”
上一提交把 L4 写成“内核独占（panic / selfip）”，漏了内核级插件这类来源。
用户澄清：**内核级插件应当能声明 L4，用于实现中断能力**，例如 WebUI 的终止按钮。
判据（两道闸，纵深防御）：
1. proc 桥（外部进程唯一入口）一律把 L4 夹到 L3。在这里夹而不是只按 source 判，
是因为 source 是插件自报字段、可以冒名；本函数所在位置能确知“来自外部进程”。
2. core：isKernelLevelSource(source) 查 pluginReg.IsBuiltinPlugin，只有编译期内置
插件（init() 自注册的工厂）才承认 L4。
source 约定 `插件名` 或 `插件名/实例`（webui/<deviceID>），判据取第一段——
否则带设备身份的 WebUI 来源会被误判成外部插件而拿不到 L4。
改动：
- core: interruptLevel(evt, privileged bool)；新增 isKernelLevelSource；
requestPreempt 不再夹取（级别已由 interruptLevel 解析，否则内核级插件的 L4 被削掉）。
- eventloop: 传入 a.isKernelLevelSource(evt.Source)。
- proc 桥: 新增 clampExternalPriority，pubSdkInjectOpts 一律夹取。
- internal/sdk: 再导出 PriorityL1..L4（内置插件用 sdk.PriorityL4）。
- webui handleChatInterrupt（终止按钮）声明 PriorityL4。
- timer 声明 PriorityL3：定时器是“时钟那种实时工作”，比 QQ 那类可无限等待的
异步消息高（L1）——这是对用户“它不是时钟那种实时工作”的直接推论，可改。
- 测试: L4 特权矩阵（非特权夹取 / 特权承认）、source 判据（内置、内置/实例、
外部、空、前缀不误匹配）、内核级插件 L4 一路到达调度器、proc 夹取两条。
- 设计稿 §2/§3.2/§11.1/§14/§15 按“L4 = 内核 + 内核级插件”更正。
验收：go build/vet 干净；go test ./... 37 包 ok 0 FAIL；-race 全绿（含 webui/timer）。
|
2026-09-13 07:18:03 +08:00 |
|
|
|
cb32032f76
|
feat(scheduler)!: 中断/排队两类别模型 + 插件声明 L1-L3、L4 内核独占
用户澄清推翻了早期设计的三处前提，本提交按新模型重做调度核心（行为有意变化）：
1) 类别由注入 API 决定，与通道名无关
- InjectInterrupt* -> TaskInterrupt（带级别，可被严格更高级中断打断）
- InjectText*/InjectInputSync*/内核自循环 -> TaskQueued（无级别，可被任何中断打断）
- 删除按通道名推断的 taskLevel()：qq 走 InjectInterruptTextOpts，本就是中断
2) 级别只属于中断
- 插件在 InjectOptions.Priority 声明 L1-L3（空/非法降级 L1，声明 L4 夹到 L3）
- L4 内核独占：新增 raiseKernelInterrupt（panic / selfip）；requestKernelPreempt 不夹取
- panic 现在产生一条带 kernel 标记的 L4 中断；L4 自身 panic 不再产生新 L4（防自我放大）
3) 选择结构：四容器固定次序，删除统一比较器
- immediate（抢占者立即运行）-> 中断队列 L4..L1 -> 栈顶(与队头比级别) -> 排队 FIFO
- 删除 pickTaskIndex/taskBefore 与“同级 pending 优先”补丁（根因是抢占者进了队列）
- 中断栈上界改为结构推论 = 4（= 中断级数）；删除“超限转 pendingInterrupts”降级
公开 SDK（feature 分支有意新增，纯追加）：InjectOptions.Priority + PriorityL1/2/3；
内核 io / proc 桥 / 插件模板同步透传。
设计稿 §2/§3/§4.1/§6.3/§9/§11/§12/§13/§15 按新模型重写。
验收：go build/vet 干净；go test ./... 37 包 ok 0 FAIL；-race 全绿；
e2e（抢占-挂起-恢复）+ 压力（200 排队 + 50 中断，L1/L2/L3 轮转）通过。
|
2026-09-13 07:00:51 +08:00 |
|
|
|
86a702b3b0
|
fix(scheduler)!: 中断栈语义（嵌套抢占 LIFO），并修掉抢占空转
用户指正：存在**中断被中断**的场景，所以被打断的现场要进**中断栈**。
我此前把 suspendPool 明确写成“不是栈、按优先级取”，是错的。
改动：
- suspendPool 改名 suspendStack，恢复纪律改为**严格 LIFO（只比栈顶）**；
栈内不做优先级重排——嵌套抢占天然使栈自底向上基础级递增，
且“后被打断的先恢复”才是栈语义。取出即弹栈。
- 修掉一个由此暴露的真 bug（抢占空转）：一次抢占生效后，被挂起的原任务
会因饥饿防护提升有效级，与抢占者同级；此时若按“先到先服务”，原任务
（入队更早）会被立刻选回，抢占者永远排不到 —— 抢占等于没发生。
现在**同级时 pendingInterrupts 优先于其它两类**，保证抢占必然生效。
- 状态 DTO：SuspendPool/suspend_pool → SuspendStack/suspend_stack
- 设计稿：§2 用语更正（它**就是**中断栈）、§4.1 选择函数（候选只含栈顶 +
pending 同级优先，并说明为何必需）、§6.2/§6.3/§9/§11 用例同步
测试新增 scheduler_stack_test.go 3 项：
- 嵌套 L1→L2→L3，恢复严格 LIFO（B 先于 A）
- 只比栈顶：人为构造“栈底 L3、栈顶 L2”，必须取栈顶（区分两种实现）
- 嵌套下的深度上限
验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 06:30:23 +08:00 |
|
|
|
d4764e3682
|
fix(scheduler)!: D1 更正为「中断从上一个任务之前的完整状态开始」，并实现现场合回
用户明确语义（我此前对 D1 的解析就是错的——当时回答里的“A”指的是 git 选项，
D1 实际要的是方案 B）：
中断打断时，上个任务到达以来的所有上下文现场被保护（含 toolcall），
然后中断在「上个任务前的那个完整状态」上开始运行；
中断结束后再把被挂起的任务与其上下文现场加载回中断任务之上，并继续运行。
实现：
- 删除 SeedMsgs 与 D1=A 的“只读前缀”机制：中断任务不再继承被打断任务的任何内容，
它就是普通新任务，正常走完整 prepare（system prompt + timeline + 自己的输入）
- TaskFrame 新增 PrefixLen（基础前缀长度）与 InputBlocks；
stepPrepare 在 buildMessages 之后记录 PrefixLen
- 新增 rebaseFramePrefix：恢复时重建基础前缀（中断已提交进 a.context，
重建的 timeline 含中断效果＝“加载回中断之上”），再把本任务自己的尾部
（Stage 上下文 + 工具轮产物 + 占位）接回；并补回 IsInterrupt 标记与多模态块
- resumeTask 在 runTaskSteps 之前调用 rebaseFramePrefix
- 设计稿 §5.3 改写为「已定：D1=B」并写明实现对应；§6.2 补“重建前缀→接回尾部”；
§12 的 D1 行更新
测试：
- TestPreempt_HigherPreemptsAndResumes 改为断言「中断不继承、恢复后看得见中断内容」
- 新增 TestPreempt_ResumeRebaseRestoresTailDecorations（前缀重建后尾部装饰补回）
- 原 TestPreempt_SeedPathDoesNotLeakInterruptFlag 随之删除（机制已不存在）
验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 06:24:20 +08:00 |
|
|
|
8372f5bd8f
|
fix(scheduler)!: 撤掉“优先级=可配置策略表”的错误设计，回归内核内部属性
用户指正：**优先级是内核内部属性**，不是配置项，更不该由插件声明。
我此前把它建模成“策略表 + 字符串解析”，甚至准备接配置中心
（core.agent.priority.<channel>）——方向性错误，故整体撤销。
撤销：
- 删除 ParseLevel（字符串解析只服务于“外部可配”这个错误前提）
- 删除 AgentConfig.PriorityLookup / Agent.priorityLookup 及 taskLevel 中的查表分支；
taskLevel 回归为纯内核内部规则（cli/webui/http→L3，system/_consolidation_→L1，
其余 L1），注释明确“不对外暴露、不做运维可调项”
- 设计稿 §3.2 改写为“内核内部属性，不做成配置项”，并删除 §15 里
“ChannelDef.Priority / InjectOptions.Priority 进公开 SDK”这一方向（同属外化）
- 未触碰配置中心（registry.go/main.go 的优先级配置一行未加）
同时落地 D6（与本撤销无关、此前遗漏的承诺）：
- AgentConfig.MaxToolTurns + runTaskSteps 在发起新一轮 LLM 前按 f.Turn 收尾；
0 = 不限；cmd/homed/main.go 从既有 core.agent.max_tool_turns 取值
- 新增 task_test.go 2 项：上限 3 时恰好跑 3 批工具/3 次 LLM 并收尾；
0 = 不限（跑完脚本）
验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 06:17:49 +08:00 |
|
|
|
98d67559d1
|
fix(scheduler): 补齐 M3 与设计稿的两处语义偏离（发现即修）
两处都不是风格差异，而是真的偏离设计语义（其一为回归），
已按“先写判据确认失败、再修”的方式处理，判据保留为回归测试。
1. 空闲时到达的中断永远不会被处理（设计 §5.1 ③ 未落地）
调度器空闲时只阻塞在 select{InputChan, selfInputCh, ctx.Done}，
而 pendingInterrupts 不是 channel——interceptLoop 把中断入队后
没有任何东西唤醒调度器，中断要等“下一条输入”才被看到。
修复：调度器加 wake channel，enqueueInterrupt 非阻塞 signalWake，
空闲分支增加 wake 分支。
2. 临界区内只“不让位”却仍被“取消”（设计 §4.3/§5.2）
requestPreempt 不判临界区，interceptLoop 照常 cancelLLM，
于是正在流式的记忆整理被中断，stepLLM 以 error 提前结束——
整理任务被砍掉一半，而设计要求的是“请求排队等它结束”。
修复：scheduler 增加原子 critical 标志（帧仍只由调度器读写），
runInputTask 在 prepare 后设置、结束（含挂起）时清除；
requestPreempt 在临界区内不 arm、不取消，中断只入队。
- 新增 scheduler_regression_test.go 2 项（先失败后通过）
- 验收：agent 全量 + -race；全仓 vet 通过
|
2026-09-13 06:10:44 +08:00 |
|
|
|
f11de37bf2
|
feat(scheduler): M7 可观测性 + 压力测试 + 端到端测试
设计依据 docs/zh/input-scheduler-design.md §11.5（O1/O2）、§11.6（E1/E2）。
- 可观测性：KernelStatus 新增 Scheduler 段（running/三集合深度/计数/
深度上限），由 GetKernelStatus 从 DumpScheduler 原子快照填充；
新增 events.EventScheduler，挂起/恢复各发一条（action/task/level）
- TaskKind.String() 便于日志与状态输出
- 新增 scheduler_e2e_test.go 3 项：
· 压力：200 排队输入 + 50 中断全部经真实 loop 执行，结束时三集合排空、
LLM 调用数精确等于输入数、无 Rejected
· 可观测性：挂起/恢复事件齐备，状态快照计数一致
· 端到端：完整启动 schedulerLoop+interceptLoop，经真实 channel 投递
L1 任务与 L4 中断，验证「LLM 流式中断 → 挂起 → 中断先完成 → 原任务恢复」
整条链路（LLM 调用数 = 丢弃1+中断1+恢复1+常规1）
- 验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 00:45:28 +08:00 |
|
|
|
4e4e0ad656
|
feat(scheduler): M6 任务级回执 + 断链点统一为终态事件
设计依据 docs/zh/input-scheduler-design.md §7（I5）、§11.3（X1/X2/X4）。
- 新增 emitSkippedReply：跳过路径（去重命中、空输入）给同步调用方一个
skipped 终态，但**不发 agent_output 事件**（避免 WebUI 聊天记录凭空多出
空消息）。修复前 cli/clawhubadapter 这类无超时的同步注入在去重命中时永久挂起
- 回执按任务归属：中断任务的回执只写自己的 ResponseCh，绝不误投给被挂起的等待者；
被挂起任务恢复并结束后才拿到自己的回执
- 新增 task_terminal_test.go 3 项：X1 回执不误投、X2 空输入有 skipped 终态、
X4 无超时同步调用方 1s 内拿到终态（回归判据）
- 更新 M3a 去重用例：由「不得回执」改为「必须有 skipped 终态」
- 验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 00:39:56 +08:00 |
|
|
|
a971fc8877
|
feat(scheduler): M5 饥饿防护（抢占计数提升有效级 + 抢占冷却）
设计依据 docs/zh/input-scheduler-design.md §9、§11.5（G1/G2）。
- Task 增加 PreemptCount / LastPreemptAt；effectiveLevel(t) =
min(L4, Level + min(PreemptCount, 2))：被抢占越多越“值钱”，
逐步追上抢占它的流，但封顶 L4 因而抢不过真正的紧急输入
- 选择函数 taskBefore 改用有效级；requestPreempt 与 preemptGrantedFor
同样以有效级比较
- 抢占冷却 preemptCooldown=2s：刚被抢占的任务期内不再被抢占，
避免同一任务被反复打断到永不完结
- 新增 scheduler_starvation_test.go 4 项：提升与封顶、冷却期内不得再抢占、
提升后同级不得抢占而更高可、选择函数确实用有效级
- 验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 00:38:30 +08:00 |
|
|
|
7565248f61
|
feat(scheduler): M4 临界区显式化 + 清掉被 pendingInterrupts 取代的 interceptCh
设计依据 docs/zh/input-scheduler-design.md §4.3、§11.1（P5/P6）。
- 临界区语义显式化：让位检查**只在 step 之间**做，执行中的 step
（工具 RPC / ONNX / CAS 落盘）天然不可抢占；_consolidation_ 整任务
经 inCriticalSection() 判为不可抢占（它直接改图库）
- 删除 interceptCh 与 drainInterrupts：M3b 起中断一律走 pendingInterrupts，
旧的「同行注入 + 三处 drain + 批次放弃」已无写入者，属死代码
- 新增 scheduler_critical_test.go 3 项：
P5/P6 工具执行中 arm 了让位信号也不得挂起、必须等工具返回后的安全点；
_consolidation_ 判为临界区；无抢占时同批工具必须全部执行（新语义回归）
- 验收：agent 全量 + -race；全仓 build/vet 通过
|
2026-09-13 00:34:39 +08:00 |
|
|
|
c69a1f11af
|
feat(scheduler): M3a+M3b 任务生命周期重构 + 四级优先级抢占
设计依据 docs/zh/input-scheduler-design.md §3–§8、§14。
M3a（行为等价的所有权重构）：
- processInput 拆为 prepareInputTask / runTaskSteps / finishInputTask，
帧覆盖 prepare→step…→finish；提交与回执只在 finish 段发生一次，
为安全点挂起做准备（挂起不重复提交）
- process() 不再持 a.mu（挂起不能持锁），a.mu 字段随之移除
- TaskFrame 增加任务层现场（Evt/CleanInput/IsInterrupt/StartedAt/Terminal/
Level/SeedMsgs）与 taskTerminal / outcomeSuspended
- 新增 task_lifecycle_test.go 5 项：正常恰好一次终态、去重 skipped、
on_input 短路、错误终态、consolidation 路由
M3b（优先级与抢占）：
- interceptLoop 重写：只做「收中断 → 定级 → requestPreempt → 必要时取消
LLM」，绝不触碰帧（不变量 I2）；三条降级路径与 interceptCh 兜底退场，
改为统一的 pendingInterrupts
- scheduler：pendingInterrupts / suspendPool / 让位信号，nextRef 在三集合上
按统一排序键取值；深度上限 4（canSuspend 在安全点拦下）
- 抢占判据 incoming.level > running.level；相等与更低只入队
- 安全点只在 step 之间；执行中的 step（工具 RPC/ONNX/CAS）天然不可抢占；
_consolidation_ 整任务视为临界区
- 恢复走 resumeTask：从 frame.Step 继续，不重跑 prepare
- D1=A：suspend 把被打断任务的只读前缀交给抢占比它的中断任务（SeedMsgs）
- 新增 scheduler_preempt_test.go 5 项：抢占-挂起-恢复（含 R1/R5）、同级更低
不抢占、深度上限、空闲中断不丢、seed 路径不污染标志位
验收：agent 全量 + -race 通过；全仓 build/vet 通过
|
2026-09-13 00:25:52 +08:00 |
|
|
|
7082a50365
|
feat(scheduler): M2 调度器骨架（就绪队列 + 选择函数 + 快照 + 任务级 panic 隔离）
设计依据 docs/zh/input-scheduler-design.md §14 M2。
- 新增 scheduler.go：四级 Level 常量（默认 L1，显式才是特权）、
Task/TaskKind、scheduler（有界队列/running/统计）、纯函数 pickTaskIndex
（排序键 -Level → EnqueuedAt → ID）、schedulerLoop/pumpInbox/executeTask、
DumpScheduler 原子快照
- eventLoop 退场，职责由 schedulerLoop 承担；M2 全部任务为 L1，
因而行为等价于原先的 channel FIFO
- 每任务 panic 隔离（不变量 I6）：panic 只失败该任务，调度器存活，
取代原先「重启整个循环」
- Start() 改起 schedulerLoop；interceptLoop 暂不动（M3 重写）
- 新增 scheduler_test.go：Q1 排序 4 组、Q4 背压、生命周期、K1 panic 隔离、
O1 快照一致性、Level 取值契约
- 验收：agent 全量 + -race 通过
|
2026-09-12 23:49:55 +08:00 |
|
|
|
9a588780b9
|
refactor(scheduler): M1 把 process() 拆成 step 状态机 + TaskFrame（行为等价）
设计依据 docs/zh/input-scheduler-design.md §14 M1。
- 新增 task.go：Step 游标、TaskFrame，以及 stepPrepare/stepLLM/
stepToolBegin/stepToolExec/stepToolAfter/stepTurnEnd 六个 step；
原函数内嵌的 provider 回退/重试抽为 resolveProviders + callLLMWithFallback
- process() 改为驱动状态机的薄壳：签名不变，调用方（processInput/
processConsolidation/测试）零改动
- StepToolExec 显式标注为临界区：工具副作用不可回滚，执行中不是安全点
- 步数上限护栏：转移缺失时以错误退出而非死循环
- 新增 task_test.go：R3（工具往返结果与配对正确）、X3（多轮必然终止）、
批中途中断必须放弃剩余工具、未知 step 必须失败退出
- 验收：既有 agent 全量测试通过；-race 通过（TMPDIR 指向真实磁盘，
/tmp tmpfs 已 98% 满会导致链接失败，与代码无关）
|
2026-09-12 23:47:12 +08:00 |
|
|
|
07e08352b9
|
feat(waiter,devicebridge): 设备桥连接带授权态，命令处理器类型统一
- `runDeviceBridgeLoop`/`connectDeviceBridge` 增加 `authorized` 入参（未授权不再尝试建立桥连）；
- `Bridge.OnCmd` 的处理器类型改为具名 `BridgeCmdHandler`，与 waiter 侧签名对齐。
|
2026-09-12 20:21:01 +08:00 |
|
|
|
fe883d5362
|
test(plugins): 真实插件产物先校验平台再 exec，错误平台给可读提示而不是 exec format error
排查知识库改动是否引入回归时，internal/plugins 6 个测试全红、报
"fork/exec .../plugin.bin: exec format error"。查了半小时才发现与代码无关：
早前验证跨平台示例构建时，最后一次构建（darwin/arm64）把
`example/*/build/plugin.bin` 覆盖成了 Mach-O arm64，而 realPluginBinary
只按文件名找候选、**不校验平台**，于是拿 macOS 产物在本机 exec。
两个陷阱一起堵：
- 校验魔数（ELF / Mach-O / PE），平台不符则 **SKIP 并给出可直接粘贴的重建命令**
（`hmapdev build --target <host> --no-bundle`），不再用误导性的 exec format error；
- 明确写出「产物缺失即 skip」的语义，避免"全绿其实什么都没验"
（本次对照实验里，改动前的 worktree 因无产物而全绿，看着像通过）。
反向验证：把 weather 产物换成 PE 假头 → 相关测试转为 SKIP 且提示平台与重建命令 ✓。
|
2026-09-12 18:38:24 +08:00 |
|
|
|
5fbd6514c2
|
fix(knowledge): 知识库检索改为「稠密 + 词法」两路融合（真实 KB 自检索 MRR 0.271→0.376）
追「实例看起来没更新」时发现知识库检索本身也不可信，先把病因查清再动手：
- **两段式召回不是瓶颈**：Store 的结果与全量暴力 cosine 完全一致；
- **真因是向量没有区分度**：词向量取平均后各向异性明显，真实 KB（33 条）上自检索
top-1 只有 15%、前两名平均只差 0.013，排序基本是噪声；
- 且全为停用词的查询会得到**空向量**（"最近更新"），直接搜不出任何东西。
先在真实数据上把候选方案量了一遍（用自检索 top-1 / MRR）再动手：IDF 维度加权零收益、
去均值反而更差，**都不做**；唯一有收益的是与词法路（TF-IDF）融合。
改动：
- `Store` 增设词法路索引，`Search` 融合两路：各自按**查询内最大值**归一化后加权。
权重 0.5 由权重扫描定：1.0（旧行为）MRR 0.271 / 0.8→0.354 / 0.7→0.358 / **0.5→0.376** /
0.3→0.336 / 0.0→0.307；语义查询也从"全是 openharmony 噪声"变成命中正确条目
（「首启人格门禁」→changelog_v1.2.1、「插件怎么开发和部署」→plugin_dev_build）；
- `vector.Store` 的候选中选阈值改为**可设**（默认 0.05 保持既有行为）：TF-IDF 余弦量级
只有 0.0~0.2，沿用 0.05 会把词法路有效候选**静默砍掉**——这一条正是 0.376→0.197 的
差距来源，且当时没有任何报错；
- Add/Remove/scanAll/ReindexWithVectorizer 同步维护两路；分数相同时按名字定序（结果可重复）。
**顺带修一个真实毛病**：Add/Remove 原先用**无追踪的 goroutine** 写索引（因为
writeIndex→BuildTree 会 RLock，而调用方持写锁，同步调用会死锁）→ 失败只打日志，
且与调用方竞态（测试的临时目录清理就撞上了）。改为持锁就地 flush
（buildTreeLocked / writeIndexLocked）。
判据（不依赖人工标注问答对）：新增 `internal/knowledge/rankdiag_test.go`，用**自检索
top-1 / MRR** 量区分度，`KB_DIAG=1` 跑、`KB_DIAG_ASSERT=1` 断言（MRR ≥ 0.34）。
另有不依赖真实数据的单测 6 条（空稠密向量靠词法路救回、稠密并列时词法路定序、
词法路阈值接线、Add/Remove 双路一致、并列时确定性、空库不 panic）。
**反向验证**（证明判据真能发现缺陷）：权重退回 1.0、词法路阈值改回 0.05、
把阈值写死回 0.05 —— 对应测试逐条变红。另：我第一版夹具余弦 0.365/0.273 远高于阈值，
注入缺陷也不报错（等于没验），故加了「夹具前提」断言并改成两层判据
（语义层由 vector 包测试证明、接线层由知识库测试钉住）。
顺带纳入上一轮漏提交的 `TestAddOverwriteReplacesVector`（同名覆盖必须摘掉旧向量，
生产改动当时已提交，测试一直未入库）。
|
2026-09-12 18:14:22 +08:00 |
|
|
|
5aaae93367
|
feat(healthcheck): 内核状态快照报出内核版本号与 ONNX 模型启用状态
healthcheck_kernel 此前没有任何「ONNX 模型是否在用」的信息，只报「向量可用/不可用」，
分不清「统一多模态空间已加载」与「退回到词嵌入/TF-IDF 路径」；人格卡要求
「版本以运行时快照为准」，也缺一个可查字段（build.version 早就在，但没人知道）。
- KernelStatus 新增 onnx 段：enabled / provider / dim / fingerprint / modalities / reason。
判据取 Loaded()（provider 真正打开且元数据合法），**不是**「配置里写了 provider」
—— 后者在模型缺失 / 运行时缺失时也为真，报出去就是假绿。
- 未启用时 reason 给**具体原因**：未配置（说明会走回退路径）/ 打开失败的具体错误。
homed 把「配置的 provider 名」与「打开失败原因」透传给 Agent，仅供状态报告。
- ProviderAdapter 新增 Modalities()（可选能力，按接口断言取用，不改公开契约）。
- healthcheck_kernel 的工具描述同步说明它回答这两件事。
**顺带修一个真实 panic**：collectKernelStatus 的 knowledge 是**接口**参数，
(*knowledge.Store)(nil) 塞进接口后 `ks != nil` 仍为真 → 调 List() 直接 panic，
而 healthcheck_kernel 正是走这条路径（panic 发生在工具 goroutine 里）。
GetKernelStatus 改为先按具体指针判空、再赋给接口；并加刻画测试钉住这个成因
（一旦不再 panic 说明参数形状已变，守卫与该测试应同步删除）。
验证：单测 4 例（已启用 / 打开失败 / 未配置 / 未加载）+ 刻画测试；
隔离实例 E2E 7/7：正例 provider=chineseclip → enabled=true、dim=512、模态 2；
反例 provider=nonexistent → enabled=false 且 reason 含具体错误与 provider 名，
真实对话仍通。
|
2026-09-12 14:56:25 +08:00 |
|
|
|
46e014a8ca
|
feat(persona): 首启人格门禁跨通道化 + 内核 persona_set 工具
WebUI 首启向导只覆盖 WebUI 这一条通道，而「人格该问一次」是所有通道的事：
走 QQ / CLI / ACP / 邮件来的人永远见不到那个向导，人格就永远是没确认过。
- 门禁移到 buildSystemPrompt（每轮重建 → WebUI/QQ/CLI/ACP/邮件全覆盖），
以 core.internal.persona_initialized 为准：未确认时要求模型主动询问用户
（默认 / 自定义 / 以后再说），确认后该段消失；personaStore 为 nil 时静默关闭。
- 新增内核内置工具 persona_set(mode=default|custom|later[, content])，
落库逻辑与 WebUI 向导**共用 internal/config**（一个实现 + 两个薄入口：
ConfigRegistry 直连 / 插件侧 SettingsAPI），避免两套语义各自漂移。
- AgentConfig 增加 PersonaStore 接口，cmd/homed 用 RegistryPersonaStore 实现。
- 非法输入（未知 mode / custom 空内容）在打标记**之前**拒绝：否则标记置位、
向导被跳过，用户再没机会设。
E2E（隔离实例 + 真实 LLM 往返走 /v1/chat/completions，/var/tmp/persona/e2e.sh）9/9 PASS：
未确认时模型主动询问 → 用户答「用默认的」→ 模型调用 persona_set 落库并置位标记
→ 之后不再追问；反向对照（清标记 + 清会话上下文 + 重启）重新开始询问，
排除了「同一段对话里已问过」这一混淆。
|
2026-09-12 13:57:06 +08:00 |
|
|
|
10367b384e
|
feat(webui): 首启人格向导（默认 / 自定义 / 稍后）+ 一次性标记
接续人格配置项化（597f07c）：现在人格是 core.agent.personal_prompt，
本次加上「首启问一次」的界面，之后不再打扰。
后端（GET/POST /api/v1/persona）：
- GET → {initialized, current_prompt, file_override}
未设置时 current_prompt 回落到内置默认模板；存在 personal/personal.md
时报告 file_override（它会覆盖配置项，向导据此提示用户）
- POST → {"mode":"default"|"custom"|"later","content":"…"}
写配置 + 打一次性标记 core.internal.persona_initialized；
custom 返回 restart_required=true（人格在启动时载入）；
「稍后」= 保留当前默认 + 打标记，**绝不阻塞任何流程**
- 空内容的 custom 与未知 mode 一律 400，且**不打标记**（否则向导会被跳过）
前端（dashboard.html）：
- 首启拉一次 /api/v1/persona，未初始化则弹向导（复用一直没人用的 .confirm-* 样式）
- 「自定义…」第一次点击展开文本域并预填当前人格，再次点击才提交（避免误提交）
- 中英双语走既有 __() 机制；保存失败/空内容用 toast 提示
测试：TestPersonaWizardFlow（首启状态、later 打标记不改人格、custom 写入 + 需重启、
空内容与未知 mode 被拒且不打标记）、TestPersonaWizardReportsFileOverride。
E2E（真实实例）：首启 initialized=false → POST later → initialized=true，
config 中标记=1、人格键为默认模板；前端页面含向导函数。
|
2026-09-12 13:02:18 +08:00 |
|
|
|
7318a10828
|
feat(persona): 人格设定配置项化 + 默认模板契约测试 + 腐坏告警
起因（v1.2.0 压测）：线上实例内核日志/接口都报 1.2.0，agent 被问版本时却按人格卡
自述 v0.9.0 + C ABI v2（该机制 v1.0.0 已删除）。根因是人格只有「文件」一个来源且无人
维护——写死的版本号必然随发版腐坏。
改动：
1. 新增配置项 core.agent.personal_prompt（多行文本），默认值为内置模板
config.DefaultPersonaPrompt，随其它默认值同批播种（老安装不注入，语义不变）
2. 默认模板**不含任何版本号字面量**，并显式要求「被问到版本/构建信息时以运行时快照
（healthcheck_kernel）为准」——从根上消掉这类腐坏
3. 人格来源优先级：personal/personal.md（存在且非空）> 配置项 > 无
启动日志明确打印来源；文件含腐坏内容（版本号字面量 / 已删除机制的说法）时告警并
建议迁移到配置项
4. internal/agent.PersonaStaleHints：腐坏检测（版本号正则 + 已删除机制词表）
契约测试（防复发）：
- TestDefaultPersonaPromptHasNoVersionLiterals：默认模板不得含 v?\d+\.\d+\.\d+，
且必须含「运行时快照」要求
- TestPersonaPromptRegisteredWithDefault：注册存在、默认值一致、播种真的写入
- TestPersonaStaleHints：线上人格卡原文必须被识别（v0.9.0 / C ABI v2），干净文本不误报
验证：go build ./cmd/homed ok；go vet 三个包 ok；go test ./internal/config ./internal/agent ok；
端到端两场景（无文件→来源=配置项 1307 字节；有旧文件→来源=文件 + 告警列出 v0.9.0 与 C ABI v2）。
|
2026-09-12 12:42:43 +08:00 |
|
|
|
b15d0bd114
|
refactor(plugin)!: 重编提示与模板路径改用 hmapdev；文档全面对齐 1.2.0
工具链在 SDK 1.2.0 更名为 hmapdev（原 plugindev）。核心侧三处功能耦合同步：
1. 用户可见报错：旧 C ABI 产物 / 协议版本不匹配 / 共享段版本不匹配
三处「请用配套 plugindev 重编」→ hmapdev（对应两条测试断言同步）
2. e2e_template_test 的模板路径改为 tools/hmapdev/templates，
并保留旧路径回退（旧 SDK 检出仍能跑测试）
3. 注释与文档同步
文档更新（用户可见面）：
- assets/docs/{zh,en}/PLUGIN_DEV.md：工具链章节整体改为 hmapdev，
补改名说明与 SDK 存储目录迁移；命令示例全部更新
- assets/docs/{zh,en}/ARCHITECTURE.md：**流程图与章节对齐 v1.2.0** ——
· 向量化章节改为三层降级：统一多模态空间（主）→ 词嵌入 → TF-IDF（回退），
写明「同指纹且同维度才参与融合」
· 媒体记忆章节重写：媒体是一等记忆块（无独立 GC / 无引用计数 / 无描述式索引 /
正文不再写 media marker），并写明 reembedStaleMedia 的跨空间迁移与写回
- README{,_EN}.md、docs/zh/plugin-interface-matrix.md：工具名与模板路径同步
（历史条目标注「当时名为 plugindev」）
验证：go test ./internal/plugin/ ./internal/plugin/proc/ ok，
含 4 条真实模板 E2E（模板路径切换后仍通过）。
|
2026-09-12 12:42:43 +08:00 |
|
|
|
34628720f2
|
fix(memory): 修 beta.2 压测发现的三个向量/文档缺陷
来源：v1.2.0-beta.2 全方位压测（报告 /var/tmp/stress/REPORT.md）
1. 文档向量迁移结果不落盘（生产已复现）
- BuildDenseIndex 改完内存不置 dirty；docStore.Stop() 全仓无调用者 → flush 成死代码
- 后果：每次启动重算同一批文档（线上 496 篇约 17s），磁盘 dense_fp 永不收敛
- 修：迁移当场落盘（抽出 flushLocked 以免重入锁）+ main.go 关停链 defer docStore.Stop()
- 生产证据：线上 488 篇文档仅 4 篇含 dense_fp，且这 4 篇均为运行期 Insert 的新文档
2. 块指纹对但维度错时污染文档向量（健壮性缺口）
- denseFor 只校验 b.Fingerprint，不校验长度；FuseVectors 取最大维度并跳过长度不符者
→ 512 维文本 + 2048 维块 = 2048 维且打上当前指纹
→ 该文档在检索侧被长度守卫永久跳过，且每次启动重算（不收敛）
- 修：denseFor 要求 len(b.Vector) == 空间维度
- 可达性：内核两个块产出点均成对取自同一行（it.Vec ↔ it.VecModel），故属防御性修复
3. Insert 与 loadAll 的 ID 约定不对称（低）
- Insert 落盘任意 <id>.json，loadAll 只加载 doc_ 前缀 → 自定义 ID 文档重启后静默消失
- 修：loadAll 只要求 .json（空 ID 仍跳过）
回归测试 4 条：迁移跨重启落盘 + 已对齐 0 重算（用向量空间调用计数判定，
不靠日志）、坏块不参与融合且同维度正常块仍参与、自定义 ID 可加载、Stop 落盘。
反向验证（纪律要求）：临时回退本次修复后，前 3 条均变红且报错正是缺陷签名
（dim=999/space-OLD-999 永不收敛、文档向量 2048 维、文件重启后消失）；恢复后全绿。
验证：go build ./cmd/homed ok；go vet ./internal/memory/document ./cmd/homed ok；
go test ./internal/memory/... 7 包全绿。
|
2026-09-12 11:05:11 +08:00 |
|
|
|
dc80855540
|
feat(status): 暴露构建源码地址，WebUI 状态页给出 AGPL §13 的源码入口
选了 AGPL-3.0-only 之后，§13（Remote Network Interaction）就不只是声明问题：
把修改过的版本作为网络服务提供出去时，必须给使用者取得 Corresponding Source 的机会。
只在仓库里放 LICENSE 并不自动满足这一条——**使用者拿到的是服务，不是仓库**。
所以把它做进产品里，而不是写进文档就算完：
- `internal/meta.SourceURL`：本次构建对应的源码地址，默认指向本仓库。
注释里写明「修改后对外部署的分支必须改指向自己的仓库」，并给出 -ldflags 覆盖方式
（`-X .../internal/meta.SourceURL=<你的仓库>`），不需要改源码。
- `BuildStatus.SourceURL`（`json:"source_url,omitempty"`）+ 内核状态填充：
走已有的 `/api/v1/kernel` 构建身份链路，不新增端点。
- WebUI 状态页在「版本」行下渲染「源码 / Source」链接（URL 经 escHtml 转义后进属性；
`target="_blank" rel="noopener noreferrer"`）。
- 用 `omitempty`：未注入该值的旧构建不会在 JSON 里多出一个空字段。
验证：
- `internal/plugins/webui/dashboard.html` 的两个内联 script 块 `node --check` 均通过；
- 全仓库 `go build ./...` 通过，`internal/meta/meta.go` gofmt 干净
（`internal/agent/core/status.go` 有**既有**的 gofmt 差异，与本改动无关，按纪律未整体重排）；
- 端到端：本地构建 homed → 冷启动 → `GET /api/v1/kernel` 的 `build.source_url`
实测为 `https://gitcode.com/JianFeeeee/HomeAgent`。
|
2026-09-12 09:41:39 +08:00 |
|
|
|
685ed7e4a0
|
fix(knowledge): 覆盖同名条目时摘掉旧向量
从一次真实的知识库更新里发现：在线实例更新一个已有条目之后，
knowledge_count=32 而 vector_count=33——多出来的那一条是上一版的副本。
成因：vector.Store.Insert 是**追加**语义（s.docs = append + index.Add），不按 id 去重；
而 Store.Add 走的是「写 content.md + 覆盖 items[id] + Insert 向量」。
文件与内存条目都被正确替换了，只有向量索引多留了一份。
危害不在于多占内存：**检索可能命中已被替换掉的旧内容**，而且完全静默——
条目数看起来是对的，只有向量数比条目数多。
修法：Insert 之前先 s.vec.Remove(id)（Remove 已按 id 过滤 docs 与倒排索引）。
回归测试 TestAddOverwriteReplacesVector 钉住 knowledge_count / vector_count /
content.md 三者都必须只剩新版。
注：该文件在 origin/main 上本就有 32 行 gofmt 差异（结构体字段注释对齐），
不属本次改动，按纪律不做整体重排。
|
2026-09-12 08:30:22 +08:00 |
|
|
|
1fb5700662
|
chore(meta): main 的版本路牌推到 1.3.0
按 docs/git-branching.md §2.1，main 的 meta.Version 始终是**下一个未发布中版本**。
1.2.x 线已开（release/v1.2.x 承载 1.2.0），所以 main 指向 1.3.0。
它标记「main 正在积攒 1.3 的东西」，不表示 1.3.0 已经存在——1.3.0 没有任何 tag。
1.2.0 已由 release/v1.2.x 承载；main 不能再挂着 1.2.0，否则 main 的版本号
就与某一次发布的版本号相同，违反 §2.1「main 的版本号不是任何一次发布的版本号」。
两仓同步：SDK 仓 main 也在同一时刻推到 1.3.0（commit 44bd915）——SDK 版本跟随
核心中版本（§七.1），且两仓 main 都表示下一个未发布中版本（§七.4）。
本 commit 同时把 vendored SDK 镜像（third_party/homeagent-sdk/meta/meta.go）
更新到与 SDK 仓一致。
SDKCompatibleVersion 保持 1.2.0：那是本内核**实际实现并兼容的最高 SDK 接口版本**，
与「下一个未发布中版本」是两件事（参见 e4be966 时 main 的 1.2.0 / SDK 兼容 1.1.0）。
**此 commit 不 cherry-pick 到发布分支**（§五：版本号 bump 不跨分支搬）。
|
2026-09-12 08:25:30 +08:00 |
|
|
|
f1091676f8
|
style: gofmt 两处对齐（graphmedia_test.go 注释、tfidf.go 结构体字段）
这两处是本次特性分支带入的格式回归（origin/main 上不脏）。
纯空白/对齐调整，无语义变化；不整体重排文件。
|
2026-09-12 08:23:30 +08:00 |
|
|
|
5299e18cd8
|
fix(config): 全新安装的默认值播种判据改为显式标记
播种判据曾经是「config 表为空」。而发行包的 postinst 先跑 setup.sh →
initconfig，后者会写一行 webui.listen_addr，于是**全新安装**被判定为
"已有配置"并整体跳过播种：没有 core.plugin.dir（装完 0 个插件）、没有
core.memory.* 路径、也没有随包模型对应的多模态 provider——754MB 产物与
24MB 运行库全成死重量。同样的机制此前已在协议 2 迁移演练里被观察到。
也不能改成"每次都补缺键"：老安装升级时被注进新默认值，会让它突然去加载
一个 1.8GB 的模型，那是刻意要避免的静默变重。
故改为显式标记 core.internal.seed_version：
有标记 → 已播种，返回
无标记但有 core.daemon.data_dir → 老安装，只补标记、不播种
两者都没有 → 全新安装，播种并打标记
测试：TestSeedDefaultsAfterInitconfigPrepopulate（精确复现 initconfig 的
那一行写入）、TestSeedDefaultsDoesNotInjectIntoLegacyInstall。
|
2026-09-12 08:10:34 +08:00 |
|
|
|
ba0b5a1fe0
|
feat(release): 发行版默认启用本地向量空间（onnxruntime 标签 + chineseclip 默认）
用户要求：后续发行版默认带 ONNX 模型能力。这条要求落到两处，并顺带修掉一个
被它**暴露出来**的真缺陷。
## 1. 构建默认带 onnxruntime（deploy/packaging/build.sh）
`HOMED_TAGS` 默认 `onnxruntime`，需要极简构建时显式 `HOMED_TAGS=` 关闭。
不带标签时 provider 仍注册、但打开即报「requires build tag」并优雅降级——
不静默假装成功。运行期还需要 `libonnxruntime.so`（provider 按
/opt/onnxruntime、/usr/local/lib、/usr/lib 顺序查找），缺失时同样是
「日志里明确错误 + 降级」。
## 2. 新装默认选 chineseclip（internal/config/registry.go）
`SeedDefaults` 写入：
core.memory.multimodal_space.provider = chineseclip
core.memory.multimodal_space.options.model_dir = <dataDir>/models/chinese-clip-vit-b16-onnx
选它而不是 qwen3vl：后者实测常驻 9.4GB，多数机器装不下；chineseclip 是
1.99GB（实测，见下）。同时更新两个 ConfigDef 的默认值与描述（WebUI 显示用）。
**老安装不会自动拿到这两个默认值**，这是有意的：`seedDBValues` 对非空配置库
直接返回，`GetString` 缺键时回落到调用方默认值（main.go 传的是空串）。
升级就静默加载 ~1.8GB 模型不是无副作用的事，应由部署显式开启。已写进文档。
## 3. 修掉 ORT 环境被重复初始化 + 误销毁（internal/nlp/onnx.go）
这是「默认带标签」才暴露的缺陷：此前不带标签时进程内不会有多个 ORT 消费者。
- `NewONNXParser` 无条件 `InitializeEnvironment()` → 若多模态 provider 先初始化，
这里报「The onnxruntime has already been initialized」并**降级**（实测日志：
`ONNX parser init: init onnx env: ... using fallback`）。
- 更严重的是失败路径与 `Close()` 里的 `DestroyEnvironment()`：它会把别人
（多模态 provider）正在用的进程级环境一起拆掉，让对方的会话失效。
改为：初始化前先 `IsInitialized()`；**任何消费者都不销毁环境**（随进程存活），
只销毁自己的会话。providers/chineseclip 与 providers/qwen3vl 本来就是这个约定，
现在三处一致。
## 验证（实测）
- 全新数据目录启动：配置库出现上述两个默认值。
- 模型未安装：`multimodal space active` 不出现，代之以明确错误
（点名缺失的 embed_config.json 路径 + 已注册 provider 列表）+ 降级，不静默。
- 模型就位：`multimodal space active: provider=chineseclip dim=512 fp=cd2a495cf990
modalities=[text image]`。
- 内存：同一份 homed，启用时 RSS **1.99GB**（峰值 2.09GB），不启用 **0.17GB**。
- NLP 修复：日志由 `ONNX parser init: ... using fallback` 变为 `dep parser initialized`。
- 构建矩阵：`go build/vet ./...` 与 `-tags onnxruntime` 两种都过；
`bash -n deploy/packaging/build.sh` 通过。
## 未做（明确记录）
- `libonnxruntime.so`（24MB）与 Chinese-CLIP 产物（754MB）目前都需自行安装/导出，
发行版尚未打包它们。若要让「默认启用」在干净机器上真正开箱可用，需要决定
是随包分发、安装时下载、还是保持文档指引。
|
2026-09-12 00:10:32 +08:00 |
|
|
|
d1959cbe80
|
feat(core): 注入行为的记忆/裁剪标志位落地 + jieba 词库内嵌 + Windows 改走 WSL
配套 SDK 提交：homeagent-sdk ba49dfd（公开 API 纯追加，无签名变更）。
本仓第三方的库镜像同步至该版本，以保证全新 clone 能编译。
## 1. 注入标志位（内核侧）
- 7 条注入路径（排队/中断/同步 × 纯文本/带媒体 + 旧 NoMem 变体）解析并转发
no_memory / context_policy / cleaner_name；策略在入口**校验**，
非法值报错而不是静默降级成 none（降级会让调用方以为自己声明的裁剪在生效）。
- 新增 validateContextPolicy（与 tool.register 同一套规则）与 pubSdkInjectOpts。
- input.register 不再手写字段白名单重建 ChannelDef，改为整体传递 + 补 ContextPolicy。
- io 层：applyInjectOpts 把标志位写进事件 payload，仅非零时写
（零值与旧 payload 逐字节一致，事件订阅方与旧内核都不受影响）。
- ioAdapter / procCore / internal-sdk 别名补齐六个 *Opts 实现。
## 2. 修掉「输入无条件裁剪」这个真缺陷
eventloop 此前对**每条非中断输入**都调 `context.Prune(...)`：破坏性（低相关事件被
归档移出上下文）且无法从调用点看出是谁触发的。改为 pruneOnInput/pruneDeclared：
优先级：注入点声明（payload.context_policy）> 通道声明（ChannelDef.ContextPolicy）
> 默认**不裁剪**
查询向量仍取清洗后的内容；新增 cleanInputFor 解析清洗文本，优先级为
注入点声明的 cleaner（cleaner_name）> 按 source 查到的通道 cleaner > 原文，
名字查不到时**记日志再回退**（注入是 fire-and-forget，插件看不到错误，
至少要在内核日志留下「你声明的清洗没生效」的痕迹）。
## 3. jieba 词库内嵌（修「猜 GOMODCACHE → 静默失效」）
原 jiebaDictDir() 去猜 GOMODCACHE/GOPATH/~/go/pkg/mod，部署机上通常没有 Go 模块
缓存 → GetJieba() 返回 nil → 分词/关键词提取/NLP 依存解析（进而 doc→graph 三元组
抽取）/静态词向量 tokenizer **一律静默返回空列表**，只有一行日志。本机看起来正常
只因开发机与生产机重合、恰好有那份缓存。
现在词库随二进制分发：internal/memory/jiebadict/ 5 文件约 11.6MB + go:embed，
按**内容哈希**命名缓存目录落盘（词库升级不复用旧文件），已齐全则跳过写入。
模块缓存降为兜底。homed 体积 32MB。
顺带确认（并有测试佐证）：gojieba 的 Tag() 不需要 pos_dict/ 目录——
cppjieba 的 PosTagger 从主词典每行的词性列取 tag。
## 4. homed 放弃 Windows 原生，改走 WSL2
插件体系依赖「继承的 fd」+「统一共享内存区的段内偏移解引用」，Windows 既无 fd
继承语义，其句柄模型也无法表达后者；强行适配等于再维护一套平台专属 ABI
（C ABI 时代三套 ABI 并存曾导致改写型插件在某平台静默失效）。
- cmd/homed/platform_{windows,other}.go：原生 Windows 启动即拒绝并打印 WSL2 指引。
- internal/plugin/proc/shmalloc_windows.go：allocShm 直接返回「请用 WSL2」，
**不返回半可用的段**（与 shmalloc_other.go 同风格：未支持平台显式报错）；
procEnvForShm 返回 nil。顺手修掉两处长期编译错误
（cryptorand→rand、h.evData→h.unified.evtData），使 GOOS=windows 至少能编译。
注：homed 本就编不出 Windows——internal/memory 依赖 cgo-only 的 gojieba。
- deploy/packaging/installer.nsi：不再安装 homed.exe/initconfig.exe，改为携带
**linux payload** 并调用新的 install-via-wsl.ps1；退出码 20/21 表示
「需先装 WSL/发行版」，走指引而非报错。
- deploy/packaging/windows/install-via-wsl.ps1（新）：检测 WSL → 引导安装 →
确保 WSL2 → 送包进发行版 → 在 WSL 内按 Linux 方式安装。**复用 Linux 包与
linux/setup.sh**，不另写一套安装逻辑；落点与 deb 布局统一
（/usr/bin/homed + /usr/lib/homeagent/setup.sh）。
- deploy/packaging/linux/setup.sh：API Key 允许 HOMEAGENT_API_KEY 覆盖
（否则安装器界面显示一份、config.db 里另一份 → 登录不上）。
- deploy/packaging/build.sh：windows 目标只构建 waiter + gui，并新增
stage_linux_payload 把 Linux 包暂存给安装器；homed/initconfig 在 windows
目标下明确拒绝。
## 5. 插件调用点统一写明意图
- webui 的 OpenAI 兼容端点（固定提示词模板）→ InjectTextSyncNoMemory。
- agentcli 的 5 处纯状态通知（已启动/超时/执行结束/进程退出/读取结束）→ NoMemory；
**带输出**的 2 处（定时反馈、有新输出）刻意保留记忆并注明理由。
- timer 的定时提醒 → NoMemory（中断本来也隐含 NoMemory，这里是写明意图）。
## 6. 版本
meta.Version 仍为 1.2.0（main 是下一个未发布中版本）；
SDKCompatibleVersion 1.1.0 → **1.2.0**（本内核已实现 SDK 1.2.0 全部新增方法）。
## 测试
- core：默认不裁剪（无声明/none/空）、通道 opt-in、注入点双向覆盖通道、
nil context/io 安全、cleaner 优先级与未知名回退。
- io：零值 opts 与历史 payload 逐键相同；text/中断/媒体三类注入标志位都落到
payload；旧方法仍生效。
- proc：validateContextPolicy 只接受 ""/none/prune，报错含位置与实际值；
**跨进程** e2e——testdata 插件经 io.injectText 送出三个标志位，断言它们穿过 RPC
到达内核。
- memory：模块缓存不可见时内嵌词库仍可用（分词与 POS 内容词均非空）、
落盘幂等、内容哈希稳定。
验证：go build ./... / go vet ./... / go vet -tags onnxruntime ./...
go test -short ./internal/memory/... ./internal/nlp/... ./internal/plugin/...
./internal/agent/{core,io}/... ./pkg/...
|
2026-09-11 20:31:50 +08:00 |
|
|
|
a37bc7333e
|
refactor(memory): 核心不再适配具体模型——公共 embedding provider SPI + 注册表
问题：cmd/homed 里 `case "onnx": qwen.New(modelDir)` 把模型适配写进了核心，
`type=onnx` 名义上是格式、实际写死了一个模型家族；2117 行 Qwen 专属代码
（BPE、chat template、M-RoPE、Vision_gN 命名）住在内核树里，还带着一对
`//go:build onnxruntime` 的 stub。加任何新模型都要改内核。
现在核心只认一个模型无关的公共契约（pkg/embedding）：
- 输入是不透明的 Data+MIME，解码/预处理/时序分组全归 provider
- 能力是数据（Info.Modalities），不是接口方法——新增模态无需改核心接口
- 不支持的模态返回 embedding.ErrUnsupportedModality（可 errors.Is 识别）
- 按名字注册，重复注册 panic；Options 是 provider 私有命名空间，核心不解释
改动：
- 新增 pkg/embedding：Modality/Purpose/Input/Info/Provider/Config + 注册表
（Open 校验 Info，ValidateVector 在入库前拦下维度错与非有限值）
- providers/qwen3vl：Qwen 实现整体移出内核（git mv），实现公共 SPI 并自注册
- internal/memory/vector：新增 ProviderAdapter（公共 SPI → 内部小接口）；
ErrModalityUnsupported 改为公共哨兵别名；删除 VideoEmbedder 可选接口
（那正是「核心为每个新模态长方法」的坏味道）
- http embedder 也变成普通 provider（注册名 http）
- cmd/homed：删除 qwen import 与 onnx/http 分支，改为按 provider 名打开 +
透传 options.*；provider 打开失败只警告并禁用多模态检索，不影响启动
- config：multimodal_space.type/onnx./http.* → provider + options.*
- 删除 internal/memory/qwen（整体搬迁）
测试：
- pkg/embedding：注册表隔离/未知名字/非法 Info 自动关闭/ValidateVector
- vector：适配器原样透传字节与 MIME、维度错被拦、Close 幂等且停止使用、
两个哨兵 errors.Is 互通
- providers/qwen3vl：新增公共 SPI 全链路集成测试（Open→Info→Embed→
未知模态哨兵），并明确断言 Info 不声明 video
已知未完成（不得当作已验证）：
- 视频冻结回归 TestEmbedderVideoMatchesONNXReference **显式跳过**：Go 侧
video 模板缺少 processor 按时间组插入的字面时间戳文本
（<0.0 seconds>/<1.0 seconds>），同一输入 Python seq=1190(1152+38)、
Go 只有 22 个文本 token。时间戳也占 M-RoPE 位置，故现有 M-RoPE 自洽断言
通过不能证明与官方实现一致。修复属 provider 内部工作。
- 视觉侧三档已导出并逐档校验通过（cos 1.000000119/1.000000119/1.000000000）
验证：go build ./... ；go vet -tags onnxruntime ./... ；
go test -short ./internal/memory/... ./internal/agent/core/... ./internal/sdk/... ./pkg/...
；onnxruntime 下 providers/qwen3vl 全绿（视频为显式 skip）
|
2026-09-11 18:26:19 +08:00 |
|
|
|
1a02971f88
|
feat(memory): 千问三段式 ONNX 嵌入补齐——可复现导出脚本 + Go 侧首次完整验证
此前三段式拆分后 ONNX 路径从未从 Go 侧跑通：embedder_onnx_test.go 仍引用
分段前的 API（e.renderInput、TextTower.onnx、旧目录），go vet -tags onnxruntime
直接编译失败。导出脚本只在 /tmp 且硬编码本机路径、从第三个目录拷贝固定形状的
Vision.onnx，完全不可复现。音频会被视觉塔编码，静默往统一空间灌入错误坐标。
本提交补齐这些缺口：
一、可复现导出脚本（scripts/export_qwen3vl_embedding_onnx.py）
- 自动拉取模型（HuggingFace 优先，失败回落 ModelScope，支持 HF_ENDPOINT 镜像）；
- 导出 TokenEmbedding + Transformer + Vision 三段图，图文共用同一 token
embedding、28 层 Transformer、last-token 池化与 fingerprint；
- 双重自检（不可省）：分段 PyTorch vs 完整模型 + 导出后的 ONNX vs 完整模型，
cos < 0.999999 即非零退出——「能加载」不等于「算得对」；
- 默认把 L2 归一化后的冻结参考向量写入产物目录（qwen_reference.json）——
Go 测试据此做逐维冻结回归，且「该目录是哪次导出的」从文件本身可追溯；
- --verify-only 校验既有产物不重新导出，可用来确认线上在用的图没坏。
关键实测结论（已写入 docs/zh/multimodal-space.md 与长期记忆）：
原生多帧视频不可行——Qwen3-VL 视觉塔把 grid_thw 当 Python 值消费
（grid_thw.tolist()），legacy tracer 固化为常量，导出后图中根本没有 grid_thw
输入，换帧数调用直接 Invalid input name: grid_thw。故视觉塔固定 (1,48,48)，
视频由上层抽帧后逐帧按图像编码（同模型/同维度/同 fingerprint），音频明确
unsupported。
二、模态边界（vector.ErrModalityUnsupported）
- 新增 vector.ErrModalityUnsupported：表示「该模态不在本统一空间的原生覆盖
范围内」，与普通错误语义不同——调用方应把它当「永远不会有向量」而非
「本次失败、下次重试」；
- qwen.EmbedImageDense 按 mime 拒绝 audio/* 与 video/*：此前它会拿视觉塔
去解音频字节，往统一空间灌入语义错误的坐标且静默；
- reembedStaleMedia 对 ErrModalityUnsupported 不计失败、不重试、不用别的
模型向量顶替（TestReembedStaleMedia_SkipsUnsupportedWithoutFaking 守住）。
三、Go ONNX 测试首次完整通过
- 重写 embedder_onnx_test.go：修复编译 + 文本冻结回归 + 图像冻结回归 +
两条阴性对照（不同输入必须不同、图像与文本必须不同）+ 不支持模态断言；
- 参考值从产物目录的 qwen_reference.json 读取（不在测试里硬编码浮点）；
- 用线上部署产物实测全部通过（text cos=0.999999940, image cos=0.999999762）。
四、.gitignore 修复
- /scripts/ 此前被列在「运行时产物」下，但它是作者维护的工具目录
（模型导出、侧车、部署校验），deploy/systemd/embed-sidecar.service 直接
引用 scripts/embed_sidecar.py，忽略它会让那份 unit 在别人的机器上指向
不存在的文件。改为只忽略 __pycache__。
五、文档（docs/zh/multimodal-space.md）
- 获取/启用/产物契约/模态边界/验证/资源成本/与现有部署产物的等价性。
验证：go build ./...、go vet ./...、go vet -tags onnxruntime ./...、
go test -short 全部通过；ONNX 标签测试对线上部署产物全部通过。
|
2026-09-11 13:45:25 +08:00 |
|
|
|
5836c2ce5c
|
refactor(memory): 拆除描述式媒体索引，媒体成为一等块并按原生向量融合
背景：此前媒体是靠「生成的描述文本」将就进记忆的——写 marker 进正文、
再由正则反解成 media_refs 与图库里的 type=Media 实体。这条链路有三个
致命缺陷：描述由异步模型生成（未生成前媒体等于不存在）、语义检索实质上
只搜描述文字、图库里的「媒体节点」是描述文本的投影而不是媒体本身。
本提交把这条链路整体拆除，媒体改为按自己的原生向量参与记忆：
一、描述链彻底删除（无残留、无兼容分支）
- media.Item 去掉 Description/DescribedBy 与对应列；
- 删除 Store.Describe / Store.Search / Store.Pending；
- 删除 Agent.mediaDescribeLoop / describePendingMedia 与配置项
core.memory.media.describe_on_ingest；
- SDK 侧 MediaAttachment 去掉 Description（见 SDK 仓独立提交）。
二、marker 机制删除，媒体归属改为结构化块边
- 删除 mediaMarkerLine/parseMediaMarkers/mediaEntityName/mediaTriplesFromText/
extractMediaDigests/sentenceWithMediaMarkers/docMediaContext；
- memory.Triple 新增 MediaDigests 结构化字段；句子文本保持原样，
不再被 marker 污染；
- 块以 sentence --contains--> block / document --contains--> block 结构边
挂到承载节点（新增 documents 表与 document 节点种类）；
- 模型未给原句时用「主谓宾。」拼一句自然语言作落点，不造 marker 文本。
三、旧数据迁移（幂等）
- 新增 GraphDB.MigrateLegacyMediaEntities：把 type=Media 的旧实体按短 digest
还原成原生块、挂回原句子、删除旧实体与描述关系；Agent 启动时执行；
- CleanupOrphanedSentences 同时看关系引用与块边，避免把只靠块存活的句子
连同块边一起删掉。
四、向量融合：媒体按图本身被召回
- 新增 vector.FuseVectors（逐维求和 + L2 归一化）；
- Doc.DenseVec = 文本向量 ⊕ 文档块的媒体向量（同 fingerprint 才融合），
新增 Doc.DenseFP，指纹变化触发重算；
- ContextEvent.DenseVec 同理融合事件块；事件新增 DenseFP，Prune 只在
同一统一空间内比稠密余弦；
- 跨模态视觉路只召回「仍被某层记忆块持有」的媒体，CAS 全库字节不再
直接充当记忆检索结果。
五、同时纳入本分支既有的嵌入基础改造（此前工作区未提交，缺它 HEAD 不可构建）
- internal/tfidf 懒回退包、千问三段式多模态 ONNX 空间的 Go 侧
（qwen/embedder.go、image.go、model_input.go）、CLIP 移除、
sdk.NewStore 分词器签名与调用点、embed 侧车 systemd 单元。
验证：go build ./... 、go vet ./...（含 -tags medialive）均通过；
在 HEAD 的独立 worktree 上重放本次暂存集后 go test -short ./internal/...
全部通过（端口冲突类用例在隔离环境中亦通过）。未提交工作区中与本改造
无关的改动（HarmonyOS、waiter、devicebridge、plan.md 等）。
|
2026-09-11 11:45:24 +08:00 |
|
|
|
dae01f9c06
|
refactor(memory): 移除 media_refs/引用计数，媒体成为一等记忆块
媒体此前是"文本块 + digest 引用 + owner 账本 + 独立 GC"：ContextEvent.Media
记 digest，media_refs 表用 owner_kind/owner_id 保活，ref_count 决定 GC 能否清。
这与文本记忆块的管理方式不一致，也是本次一并纠正的核心偏差。
改为与文本块完全一致的生命周期：
1. 一等记忆块直接由所在层持有
- ContextEvent.Blocks / Doc.Blocks / GraphDB memory_blocks
- 块带 modality/digest/MIME/size/vector/fingerprint，文本、图片、视频同构
- Context→Document→Graph 迁移的是块本身（ID 不变），迁移后清空源容器，
同一块不同时存在于两层
2. 删除平行生命周期账本
- media.Store 去掉 media_refs 表、OwnerKind 常量、RefCount 字段、
AddRef/DropRef/DropOwner/Refs、ref_count 列与索引
- 删除 mediaGCLoop、GC(keep,minAge)、容量上限与 media.gc_* / media.max_mb 配置
- 媒体内容在块被永久删除时一并删除（media.Store.Delete + forgetPayloads），
与"删除文本块即删除内容"同一语义
3. L3 原生结构
- memory_blocks / memory_block_edges（contains/depicts/derived_from）
- 边端点必须是真实图节点，不再用 owner 字符串伪装关系
- BlocksForNode 支持 sentence --contains--> block 反查
4. SDK 与检索同步
- 插件附件/标记直接变成块，不再 AddRef
- 跨模态检索改用 QueryMediaScored（CAS 内不再有孤儿缓存需要过滤）
测试全部改写为块语义：删除 refcount/media_refs/GC 断言，新增块迁移、
单层不变量、Delete 语义与并发删除回归。
注：cmd/homed/main.go 同时携带工作区中既有的 CLIP→Qwen 模型目录接线改动。
|
2026-09-11 10:57:22 +08:00 |
|
|
|
e44164f5bd
|
feat(memory): Graph 原生一等记忆块节点与结构边(§13.12)
媒体/文本在 L3 不再是正文标记反解出的代理实体，而是带原生
modality/digest/MIME/size/vector/fingerprint 的 memory_blocks 节点；
contains/depicts/derived_from 等语义边落在 memory_block_edges，
端点必须是真实图节点（block/entity/sentence），不复用 owner 字符串。
本步只建立存储与查询能力，不接入 media_refs，也不改变 L0/L2 路径。
|
2026-09-11 10:08:59 +08:00 |
|
