jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-21 09:28:14 +00:00
Code Issues Packages Projects Releases Wiki Activity
436 Commits 6 Branches 27 Tags
cba33d2a6f8d06791b0b91f9708ec0e1a625f8ab
Commit Graph

436 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
c5b1242980 docs(resident-subagent): 更正 N2c 方案 —— 窄接口（只剩 Recall/Commit）+ nil 即禁用 
用户指出：a.memory 的多数使用点属于**主 agent 整理记忆**与**记忆整理流水线**，子根本不该有那些
代码路径。据此把上一版"约 20 方法的接口 + 受限包装"改成**实测分类 + 窄接口**。

按调用方实测分类（42 处）：
- A 记忆整理流水线（distill.go 10 处：archive/review/merge 循环）→ root-only
- B 记忆块 + 媒体桥（graphmedia.go 18 + medialoop.go 4）→ root-only
- C 记忆整理工具（executeMemoryTool 8 处：merge/delete/block_merge/purge/edit/stats）→ root-only
- D 共同面：**只有 Recall + Commit**（自动写入路径 + memory_recall 工具）
- E 22 处 if a.memory != nil 既有关卡 + 状态/工具表判空

更正后的方案：
- `GraphMemory` 接口**只含 Recall + Commit**
- 根：a.graph = a.memory = 同一个 *GraphDB
- 子：a.graph = *LightMemory，**a.memory = nil** ⇒ 既有 22 处 nil 关卡自动禁掉全部 root-only 路径
  （executeMemoryTool 开头本来就是 `if a.memory == nil { return "图记忆系统不可用" }`）
- 唯一要拆的：自动写入 commitTriplesWithMedia（图部分走 a.graph.Commit；块/媒体部分用 a.memory != nil 守卫）
- 整理类工具**不进子的工具表**（而不是进去再报不可用）

⇒ 不必写"18 个方法都返回错误"的受限包装 —— 子压根没有那些路径。
 2026-09-13 09:42:43 +08:00
JianFeeeee
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
JianFeeeee
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
JianFeeeee
36e7556a02 docs(resident-subagent): 子的记忆面收窄为「传统上下文 + 图记忆」 
用户澄清：**doc 记忆**与 **context 动态上下文**是内核独立设计的记忆能力（父专属），
子 agent 的记忆面只有 **图记忆**。据此更正设计：

- §5 开头加适用范围界定：两级空间（读 temp∪main / 写 temp）**只针对图记忆**
- 新增 §5.5「子的记忆面」对照表：
    | 能力 | 根 | 驻留子 |
    | 图记忆（含向量检索） | ✅ main 读写 | ✅ 作用域化 |
    | doc 记忆 / context 动态上下文 / 蒸馏 / 归档 / consolidation / 文本 / 知识库 / 媒体 / 社交 | ✅ | ❌ 父专属 |
- 修正「轻量内核」的表述：不是"记忆变轻"，而是**记忆面裁到只剩图记忆 + 图记忆被作用域化**
- §16.1 记忆面清单加「子可用？」列；**v1 只给图记忆（含其向量检索）加 space 维度**
  —— 其余面子根本够不到，加 space 是白工
- 里程碑：N2a = 图记忆 space 维度；N2b = 图记忆的向量检索接入同一过滤
- 决策表补 R3b

纯文档更正；全仓 go test ./... 37 包 ok。
 2026-09-13 09:24:09 +08:00
JianFeeeee
069552e921 docs(resident-subagent): 把 N2 拆成 N2a–N2d（记忆作用域逐面铺开）+ 记忆面清单 
N2（轻量内核 + 记忆作用域）是目前最大的一块：记忆子系统有 7 个面
（图记忆/向量索引/文档/知识库/文本/媒体/社交），每个面都要加 space 维度。

拆成可独立验收的四步：
- N2a 作用域对象 + **图记忆** space 维度（先做这一条纵切）
- N2b 其余记忆面加 space（逐面验收）
- N2c Agent 级作用域接线（根 = {main,[main]}；驻留子 = {sub/<id>,[sub/<id>,main]}）
- N2d 晋升与丢弃（回收时父把选中的 temp promote 进 main；销毁/回收丢弃 temp）

文档新增 §16.1 记忆面清单（面 → 载体 → 表），说明为何先做图记忆这条纵切。
 2026-09-13 09:15:58 +08:00
JianFeeeee
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
JianFeeeee
a2dcd96fee chore: 撤回误提交的未跟踪文件 internal/plugins/deepsearch_e2e_test.go 
该文件是工作区里**别人 in-flight** 的未跟踪文件（我上一步用 git add -A internal/ 时被顺带收进来）。
它不是我这次改动的一部分，因此从索引里撤出，文件本体保留在工作区（仍为未跟踪状态），
由它的作者决定何时提交。
 2026-09-13 09:07:02 +08:00
JianFeeeee
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
JianFeeeee
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
JianFeeeee
3956610134 docs(resident-subagent): inputch 是最基本的输入路由单位（插件可注册多个） 
按用户补充收窄定义：
- inputch 是**最基本的输入路由单位** —— 路由粒度到此为止（比「插件」细、比「通道名字符串」实）
- **由插件注册，且一个插件可注册多个**（登记接口即现有 RegisterInputChannel，
  调 N 次就是 N 个 inputch；同一插件的多个 inputch 彼此独立，可绑给不同 agent、可分别限额）
- 「划入输入通道」的单位 = **inputch**（不是插件、不是通道组）
- 通道注册层以 inputch 为键（一个插件 → N 个 inputch），每个 inputch 带
  归属/被划给的 agent · 容量 · 可接收类别 · 输出目标解析

新增测试点 S21（同一插件两个 inputch 分别划给父与子，互不串台）。
 2026-09-13 08:40:04 +08:00
JianFeeeee
fc41e160db docs(resident-subagent): 驻留式子 agent 设计稿（轻量内核 · 两级记忆 · 父子中断） 
把用户口述的设计固化成文档，与已落地的 input-scheduler-design.md 配套。

定下来的核心：
- inputch = 对「中断输入/排队输入」两者的高层抽象，是**路由与分配**单位
  （路由发生在进内核之前；类别与级别是每条输入的属性，不是 inputch 的属性）
- 输出是 agent 的**主动调用**（output_send__{通道}）；内核不持「当前通道」可变状态、
  提示词不预设 outputch
- 通道不配对：父**划入若干输入通道** + 授权**一组可用输出通道**；输出可寻址到具体 agent
- 驻留子 = **独立轻量内核**：读 temp∪main、写 temp（记忆层按 agent 作用域化 ——
  这才是「轻量」的真正理由，不是砍功能）
- 两条独立中断阶梯：父侧 子的主动消息=L3 / contextfull=L4；子侧 **父的消息=L4**
  （L4 通则：某 agent 的 L4 只属于它的内核 ⇒ isKernelLevelSource 泛化为「该 agent 的上级」；
  子内部一切来源被夹到 ≤L3，所以父的消息确定能打断子）
- 父对子 6 个动作：创建/发送消息/查看/压缩/回收/销毁（原语在内核、决策在父的模型）；
  插件与工具由父授权，**默认完整授权**
- contextfull 三处置：压缩=保留（清处理表）/ 回收=取消（promote 选中的 temp 进 main）/
  销毁=立刻销毁并移除
- inputch 处理表：子持有、父 pull；主动写入优先，否则系统自动写；生命周期 = 当前上下文窗口
- 登记表 + 硬约束：父可随时销毁，父退出必须销毁全部，子不得比父活得久
- 工作式轻量子 agent **原样保留**，两类并存

含 20 个测试点（S1–S20）与 8 个里程碑（N0–N7，每步独立可验收）、
12 条待确认决策（全部带可逆默认值）。
 2026-09-13 08:39:40 +08:00
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
6bd3313a22 docs(scheduler): 回写 M1–M7 实现状态与 5 处实现期偏差 
- 里程碑表补提交号与验收结果
- 记下与设计稿的偏差：M3 拆分、a.mu 移除、interceptCh 删除、
  M0 伪时钟未做（用阻塞 provider 替代）、工具执行临界区由结构保证
 2026-09-13 00:48:20 +08:00
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
716ee46471 docs(scheduler): M3 拆为 M3a（所有权重构）/M3b（抢占语义） 
真正的中途挂起要求帧跨越 prepare→step…→finish 全生命周期；若只让
process() 可挂起，processInput 会在挂起返回后继续 context.Append 与
emitResponse，造成重复提交。故 M3 分为两步：M3a 行为等价的所有权重构
（含移除 process() 整轮持有的 a.mu），M3b 再引入优先级与抢占。
 2026-09-12 23:51:13 +08:00
JianFeeeee
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
JianFeeeee
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
JianFeeeee
06edff1af2 docs(scheduler): 输入调度器设计稿（四级优先级/可抢占/现场保存 + 测试点与里程碑） 
背景：现状排队与中断两条语义建立在串行 eventLoop 上，存在队头阻塞、
中断三条隐式降级路径、回执无任务归属、断链点静默、背压策略分裂、
假取消、不可观测七个已确认问题。

设计：四级内核预定义优先级（严格大于才抢占）、显式临界区、
单调度线程 + 单中断线程、step 化任务帧与安全点、suspendPool/pendingInterrupts/
readyQueue 三集合统一选择函数、任务级 responseCh。

含 11 组测试点（优先级/恢复/回执/队列/深度饥饿并发/端到端），
测试方式与预期结果逐条写明；M0–M7 里程碑逐步实现。
公开 SDK 在 v1 保持冻结（diff 必须为 0）。
 2026-09-12 23:39:10 +08:00
JianFeeeee
163c5f70b3 chore(sdk-mirror): 同步 vendored SDK 到 SDK main（browser_search 现代 Bing 版式解析修复） 
镜像追平 SDK main（`ebd700e`）：
- browser 示例：browser_search 三处根因修复（www.bing.com 302 → cn.bing.com；
  标题取 h2 > a 而非块内第一个 <a>；摘要兼容 p.b_lineclamp*）并解开 /ck/a 跳转包装，
  解析不出结果时显式报错；附真实响应夹具与 5 项单测；版本 2.4.0 → 2.4.1。

注：SDK 仓新增的 example/deepsearch（联网检索 + SearXNG 生命周期托管）与
example/vikunja（任务管理）按本仓策略（.gitignore 忽略 example/ 下未跟踪文件）不入镜像。
 2026-09-12 23:39:10 +08:00
JianFeeeee
ca5e62f775 docs(plan): 记忆与多模态目标纠正（媒体为一等节点、同一指纹空间、音频 unsupported） 
把计划里过时的描述式索引路线改正：媒体/媒体块是 L3 一等节点与原生边，
multimodal doc/context 的向量与裁剪须与 text/媒体块在同一指纹空间共同参与；
音频在该模型下明确 unsupported（不做文本描述式索引）。
 2026-09-12 20:21:01 +08:00
JianFeeeee
07e08352b9 feat(waiter,devicebridge): 设备桥连接带授权态，命令处理器类型统一 
- `runDeviceBridgeLoop`/`connectDeviceBridge` 增加 `authorized` 入参（未授权不再尝试建立桥连）；
- `Bridge.OnCmd` 的处理器类型改为具名 `BridgeCmdHandler`，与 waiter 侧签名对齐。
 2026-09-12 20:21:01 +08:00
JianFeeeee
8f40b91dea feat(ohos): 设备桥会话管理、状态/设备信息载荷与能力路由完善 
- 新增 `DeviceBridgeSession.ets`：会话生命周期（创建/复用/回收）与 TTS 会话显式 shutdown；
- `BridgeCaps`/`BridgeRouter` 与内核实际支持的本机命令保持一一对应，补齐 status/deviceinfo；
- 页面与状态存储调整（DevicePage/Index/SettingsPage/StatusStore/SubPage）、新增 ScreensuePage；
- module.json5 与 string.json 同步（新增页面与文案）。
 2026-09-12 20:21:01 +08:00
JianFeeeee
d1662e77cf chore(sdk-mirror): 同步 vendored SDK 到 SDK main（qq 插件重写、browser 会话超时必填、路牌 1.3.0） 
核心仓 `third_party/homeagent-sdk` 是 SDK 仓的 vendored 副本，内容以 SDK 仓 main 为准
（本仓 `.gitignore` 忽略 example/ 下的未跟踪文件，已跟踪的镜像文件用 `git add -u` 更新）。
本次把镜像追平到 SDK main（`8c10b7e`）：

- qq 插件重写（+498 行）：`output_send` 回声/自激路径的根因修复与去重；
- browser 示例：交互式会话 `timeout` 由默认 10m 改为**必填**（附参数校验与测试）；
- `meta.Version` 1.2.0 → **1.3.0**（SDK v1.2.0 已定版，SDK main 按纪律推进到下一个中版本）。
 2026-09-12 20:21:01 +08:00
JianFeeeee
dc4982464d fix(packaging): SHA256SUMS 只列本批产物，且用平铺名（此前会带上历史版本、且与附件名不符） 
v1.2.2 出包时发现：dist/ 跨多次构建累积，而清单用 `find $DIST_DIR` 全目录扫，
于是 SHA256SUMS 里混进了 1.2.0/1.2.1 的包名——用户从发布页下载这份清单后
`sha256sum -c` 必然报「文件缺失」（那些包并不在本页）。

两处一起修：
- 按本批 `$PKG_VERSION` 过滤（只列这次真正打出来的产物）；
- 名字用 basename（平铺名），与发布页附件名一致；哈希取真实路径（此前若直接
  对 basename 求哈希会找不到文件——就在 `deb/`、`tar/` 子目录里）。

验证：对含 1.2.0/1.2.1/1.2.2 的 dist/ 跑新逻辑 → 4 条（旧逻辑 12 条）；
并拿发布页真下载的 SHA256SUMS 逐条核对四个产物的实际哈希 → 全部一致。
 2026-09-12 19:18:26 +08:00
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
ea21803acb docs(branching): 明确开发者文档的发布归属——以 rel 分支的形态为准，再合入 main 
用户裁定：开发者文档应当在每个 rel 分支被修正为对应 rel 的形式，随后合入 main。

新增 §二.7，写清：
- 规则与做法（release 上按本版口径改 → cherry-pick 到 main，遵守 §三 只 pick 不 merge）
- 为什么不能直接改 main：main 语义是「下一个未发布版本」；assets/docs 会随发行包
  分发并在 WebUI 被阅读，服务的是「这一版」；版本号/工具名/机制有无都随版变动
- main 上描述「下一版才有」的行为必须显式标注（如「（下一版）」）
- 反例表（本仓真实踩过）：人格卡写死 v0.9.0 + 已删除的 C ABI、架构文档把已移除的
  描述式索引/引用计数写成现行、README 停在旧版本
- 配套硬约束：任何会被当作事实的文本不得写死版本号，须插值或读运行时快照并加测试
 2026-09-12 13:05:24 +08:00
JianFeeeee
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
JianFeeeee
ce8bc27db8 docs(architecture): 记忆流转图对齐统一多模态空间 
流程图里 Context/Prune/DocStore 三行仍只写 StaticEmbedder 与 TF-IDF，
读起来像"向量化只有词嵌入一条路"，与 1.2.0 实际（多模态统一空间为主，
带 fingerprint；词嵌入/TF-IDF 是降级层）不符。

- Context Append：补三层向量层级说明
- Context Prune：改为 DenseCosine（仅同指纹比较）→ StaticEmbedder 回退
- DocStore：改为稠密向量 + dense_fp 同指纹要求（不符即重算）
- 中英双版同步
 2026-09-12 12:46:21 +08:00
JianFeeeee
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
JianFeeeee
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
JianFeeeee
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
JianFeeeee
85223fc1c9 docs(matrix): 记录 v1.2.x 的接口扩展，以及本次审计抓出的两处漂移 
§九 原本只写到 v1.1.x。补上 1.2.0 的接口增量（注入侧的 InjectOptions 与六个
*Opts 变体、ContextPolicy 取值、ChannelDef.ContextPolicy 与它的 JSON tag），
并明确一件容易被误读的事：**「接口纯追加」不等于「无需重编」**——同版把插件运行
协议升到了 2（fd3 布局改变），协议不匹配会在握手时被明确拒绝，这两件事必须分开说。

同时把这次扩展自己抓出来的两处漂移入档（都属于本节第 3 条要防的类型）：

1. 模板接线守卫 `TestProcTemplate_CoversAllCoreMethods` 红了：模板不再发
   io.injectTextNoMem（改走 io.injectText + NoMemory），而内核保留该 id 是刻意的
   向后兼容面。修的是判据（显式 deprecated 表 + 反向保护）。
2. mocksdk 与公共 SDK 机械求差，差集为旧的三参数 InjectInputSync（通道类插件闭环
   要调的方法）；git log -S 证实从来就缺，已补齐。

验证表按**本机实跑结果**填写：示例 vet 17/17、plugindev 测试全绿、
sdk -race -count=5 通过、mocksdk 差集为空。
 2026-09-12 09:41:39 +08:00
JianFeeeee
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