140 Commits

Author	SHA1	Message	Date
JianFeeeee	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
JianFeeeee	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
JianFeeeee	37924b295b	feat(webui): 总览底部源码区改为独立的「开源许可」框（协议 + 全文 + 源码） ... 此前总览底部只在 KPI 卡里挂了一行小链接（.ov-foot），既看不出受什么许可 约束，也看不出 AGPL 网络服务场景下的义务。现在单独成一张卡： 开销许可 许可协议 AGPL-3.0-only → GNU 官方全文 源码仓库 <source_url> → 仓库 网络服务条款（§13）：把修改后的版本作为网络服务对外提供时， 必须向使用者提供取得对应源码的途径。 内核侧（License 是新事实，不能只靠前端写死）： - internal/meta：新增 License（SPDX 标识）与 LicenseURL，都可 -ldflags 覆盖。 LicenseURL 默认指向 GNU 官方 AGPL-3.0 全文页 —— 与仓库托管方、分支名、 文件路径都无关，换仓库/换分支不会失效。 - internal/sdk/status.go 的 BuildStatus：新增 License / LicenseURL 两个 json 字段（additive，旧消费方忽略未知字段即可）。 ❗注意 internal/sdk 不受公开接口冻结约束（docs/git-branching.md §六）， 本次未触碰 third_party/homeagent-sdk/sdk/。 - internal/agent/core/status.go：从 meta 填充。 前端： - 骨架里 .ov-foot 换成独立的 <div class="card" id="ov-legal">（放在 KPI 卡之后）。 - 网络条款那一段按许可标识是否含 AGPL 决定是否渲染，不硬写协议名。 - 内容对一次构建是常量，沿用 __html 比对，填一次后不再重建（不引入闪烁）。 验证（现网 1400x920，CDP 实测）： - /api/v1/kernel 的 build 现在带 license="AGPL-3.0-only"、 license_url="https://www.gnu.org/licenses/agpl-3.0.html" - 卡片为真框：class=card、border 1px、radius 14px；总览结构 = rt-panel | card | ov-legal - 两个链接均为真 <a>，target=_blank + rel=noopener noreferrer - updateOverview() 再跑一次，卡片子节点身份不变（不重建、不闪） - 回归：KPI 版本副行、阶段管道 5 节点/5 列/6 SVG、队列 5 行×5 格 均正常 - 无横向溢出；总览/侧栏/顶栏渲染文本无 emoji - go vet 干净；agent/core、plugins/webui、plugins 全量测试通过	2026-09-14 17:48:54 +08:00
JianFeeeee	9eebd96ab7	fix(core): 插件拒绝工具时把 ctx.Response 的理由透给模型 ... before_toolcall 的 ctx.Response 是插件写的**拒绝理由**，但工具结果被写死成 「工具 X 已被插件拒绝」，理由从不到达模型——模型于是不知道能不能重试， 会反复重试被拒的调用。抽出 denialResultText 并在有理由时原样透出。	2026-09-14 16:45:04 +08:00
JianFeeeee	e4d69fa140	feat(webui): 总览改版 —— 阶段管道滑块 / per-agent 负载环 / 通道→agent 拓扑与光点 ... 总览页此前是一堆数字与文字块，看不出「这一轮走到哪、谁忙、消息从哪进哪出」。 本次把运行态面板改成以图形为主： - 阶段管道：七阶段滑块，由 SSE stage 事件驱动，当前阶段高亮、滑块滑过去； 一轮结束（after_output 或 2.5s 无事件）自动回到空闲，不做假动画。 - 队列与中断栈：沿用五条进度条（L1–L4 + 排队），中断栈补一条深度进度条。 - Agent 拓扑：改成「每 agent 一条横带」——左 inputch、中 agent 节点（圆环 = 负载）、 右 outputch，连线即路由；删掉旧的「归属框 + 单个内核盒」画法（看得出哪个子接了哪条输入）。 - 光点动画：channel_input（新增轻量 SSE 事件）沿 inputch→agent 连线跑； agent_output 沿 agent→outputch 连线跑。用 SMIL animateMotion，不需要 rAF 循环。 - 负载：由该 agent **自己的**调度器积压（排队 / 四级中断 / 中断栈）按级别加权折算， 环形图展示。为此把驻留子的调度器积压透出到状态面（SDK 纯追加字段）。 后端：sdk.ResidentStatus / core.ResidentInfo 增加子 agent 调度器积压四项； WebUI SSE 增加 channel_input 轻量事件（只带通道名与 agent id，不带正文）。 顺带收口对话区视觉（页签改分段控件、消息间距/气泡区分、输入区分隔线）。	2026-09-14 15:33:23 +08:00
JianFeeeee	43536ba326	fix(webui): 运行态面板不再闪、通道分配带归属（含驻留子）、改图形化 ... 三个用户可见问题，逐个说明根因与改法。 1) 首页「一闪一闪」——运行态每 3s 轮询一次，renderRuntime 无条件重建 #rt-panel 的 innerHTML：数据没变也把整块 DOM（含各级条的 transition） 推倒重来。改法：缓存数据签名（**不含 uptime**——它每秒都变，带上等于没缓存）， 签名相同直接 return，一个字节都不动。另：renderOverview 会整块重建 #rt-panel（面板本身是空的），所以那里必须让签名失效，否则空面板填不上。 2) 通道分配只显示内核/根 agent，看不见驻留子——根因是状态面只暴露了设备能力 （KernelStatus.Channels，来自 iom.ListChannels），而「这条输入归谁」是 ChannelRegistry 的属性（InputChannel.Owner/Capacity/Output），从未出过内核。 而登记表本来就是根 agent 与驻留子**共用同一份**，所以数据一直都在，只是没画。 改法：KernelStatus 新增 InputChannels（+ sdk.InputChannelInfo）， /api/v1/runtime 带出 input_channels；前端把它按 owner 分进「归属容器」， 驻留子即使一条 inputch 都没划到也照样出现在图里（否则"子存在但看不见" 与"子不存在"无法区分），并显示其 allowed_outputs / 轮次 / 上下文满标记。 3) 「这些信息明明可以图形化」——四级中断的登记/抢占由纯文本改成并排迷你条； 通道分配用归属容器 + 容量滑块（轨道/填充/把手/读数），并把回程通道、 注册插件做成胶囊标签。设备能力拓扑（原有）保留。 验证：go build/vet 干净；go test ./internal/agent/... ./internal/plugin/... ./internal/sdk/... ./cmd/... 全绿；node --check dashboard.js 语法通过。 TestRuntimeEndpoint 扩展为同时钉住 input_channels 的归属与「驻留子划走的那条」。	2026-09-14 10:55:45 +08:00
JianFeeeee	c321388a21	fix(scheduler): 安全点重新求值中断队列 + 抢占/背压计数修正 + 停机补终态 ... 对照 docs/zh/input-scheduler-design.md 原文修四处（前两处是真缺陷，后两处是 观测面与设计承诺不一致），均配回归用例： 1. §4.3/§5.2「临界区结束后的第一个安全点重新求值」此前**没有实现**： 全仓唯一的武装点是 registerInterrupt，凡被拦成「入队」的中断只能等当前任务 自然结束。可达症状：WebUI 终止按钮连按两次，第二次落在 2s 抢占冷却窗内 → 入队 → 再也不会被求值。修：runTaskSteps 的安全点先 rearmPending()—— 判据与 registerInterrupt 完全同一套（canPreempt + 冷却 + 临界区闸门）。 2. PreemptsByLevel 的语义是「进入 immediate 槽的次数」，但计数发生在 setImmediateLocked 之前：immediate 是单槽，同一安全点前到达的两条同级中断里 被降级的那条也被计成抢占。修：setImmediateLocked 只在真占住槽时返回 true， 计数随之为真；同时把「降级入队」的责任收归调用方，消除同一任务被入队两次的 隐患（实测该隐患会让中断任务执行两次、Executed 虚高）。 3. 状态面 Preempted 此前拿 Stats.Suspended 顶替，与 preempts_by_level 自相矛盾。 修：Preempted = Σ PreemptsByLevel[1..4]。 4. §4.4/Q4「满时阻塞发送方 + 计数并打日志」只做了阻塞：pumpInbox 满时直接返回， 一个字都不计。修：新增 Stats.Backpressure(+DTO 字段) 与只报一次的状态翻转日志； 同时显式处理 enqueue 返回值（静默丢弃会让同步调用方永久挂起）。 另：Stop() 停机前排空待办——给从未运行与已挂起的、带 ResponseCh 的任务补 skipped 终态，否则 cli/clawhubadapter 这类无超时同步注入方永久挂起（§7 I5、§11.3 X4）。 emitResponse 的 ResponseCh 写入改为非阻塞 + 告警，避免一行写错就卡死调度器 goroutine。 验证：go build/vet 干净；go test -count=1 ./internal/agent/... ./internal/plugin/... ./internal/sdk/... ./cmd/... 全绿；go test -race ./internal/agent/core/ ./internal/sdk/ 干净。 新增 scheduler_rearm_test.go 六个用例（冷却期满重新求值/同级降级不计数/Preempted 求和/ 停机补终态/背压计数与翻转/pumpInbox 满计数）。	2026-09-14 10:39:25 +08:00
HomeAgent Agent	1ce3a917a5	feat(status+webui): 运行态图形化 —— 排队/四级中断队列/中断栈/驻留子/通道拓扑 ... 需求：首页不该只有文字，要能一眼看出内核在忙什么——排队消息数、各级中断 排队与中断栈、驻留子 agent 数量；这些要向**内部 SDK 暴露接口**，供 WebUI 等应用 展示；通道划分也要能画出来。 ## 一、内核状态面（internal/sdk，内部 SDK，不受公开 SDK 冻结约束） * SchedulerStatus 补： - interrupt_queues[5]：**四级中断队列各自的深度**（下标即级别 1..4，下标 0 恒 0， 这样 level 能直接当数组下标用）。此前只有 pending_interrupts 总数， 看不出"堵在 L1 还是 L4"——四级是抢占优先级，堵在哪级是完全不同的运行状态。 - immediate：刚抢占成功、下一个安全点立即运行的那个中断（此前完全不可见）。 - suspend_frames：中断栈的帧（栈底→栈顶，只给任务标识），depth 之外还能看出 "谁被谁打断"。 - interrupts_by_level / preempts_by_level：各级累计登记数与抢占成功数。 * KernelStatus 补 residents（驻留子运行时视图：状态/轮次/上下文已满/输入通道/允许输出）。 刻意**不带**每个驻留子的 inputch 登记明细——状态面会被反复轮询，明细会让 每次 /status 背上几十 KB；只给表大小，要明细走专门接口。 * ChannelInfo 补 direction(in/out/io)、description、tools、output_caps、caps_text。 此前 collectKernelStatus 只透传 Name/Type，把描述/工具/能力**全丢了**， 前端只能画出一排光秃秃的名字。 ## 二、WebUI * 新增只读 `/api/v1/runtime`：只回运行态三件事（scheduler/residents/channels）， 实测 **1.0KB**（/kernel 是 30KB 级）——所以能 3 秒轮询做"实时"感， 而不必反复拉全量状态。 * 首页新增「运行态」面板（纯 CSS + 内联 SVG，前端仍无构建链）： - 四个数字块：排队任务 / 待处理中断 / 中断栈(深度/上限) / 驻留子 Agent，带占比条； - 四级中断队列条形图：每级"深度 · 登记/抢占"，四级语义**照抄内核** （L4 内核独占 / L3 交互 / L2 消息 / L1 后台），不自己起名字； - 中断栈层叠图（栈顶在上）+ ⚡立即运行项； - 通道拓扑：输入通道 → 内核 → 输出通道，双向通道两侧都出现，能力以胶囊标签显示。 * 3 秒轮询只在总览页可见时才发请求；切回总览时 renderAll 会立刻补一次。 ## 验证 * 新增 TestSchedulerStatusExposesLevelsAndStack（四级队列/立即项/栈帧/各级计数映射， 并断言"未使用的级别必须为 0"与"下标 0 恒 0"）、TestChannelInfoCarriesTopology、 TestRuntimeEndpoint（形状 + 不携带 tools/plugins + 无状态源时 503）。 * go build / vet / agent+core+sdk+plugin+webui 全量测试绿。 * 真实浏览器实测（CDP 驱动，注入运行态样本走真实渲染路径）： 数字块 [3, 5, 2/4, 2]；四级条 L4=1/L3=2/L2=1/L1=1 与数据一致； 栈帧按"栈底→栈顶"渲染且标出栈顶；通道左右分列、io 通道两侧都出现。	2026-09-14 09:05:14 +08:00
HomeAgent Agent	431bb5a0c9	refactor(tooldefs): buildToolDefs 614→273 行（抽 toolDef 助手，schema 形状不变） ... 原实现每条工具都是 4 层嵌套的 map[string]interface{} 字面量（约 20 行/条）， 40+ 条堆成 614 行的巨型函数。新增 toolDef(name, desc, props, required...) 助手消除外层样板；所有 name/description/properties/required 文本**逐字保留** （用 go/ast 定位原样搬迁，非重新键入），schema 形状与 JSON 输出不变。 验证：go build ./... / go vet / go test ./internal/agent/core/ 全绿； AST 实测 614→273 行，非测试函数 ≥300 行数由 4 降到 3。	2026-09-13 22:17:45 +08:00
HomeAgent Agent	52127a3323	fix(resident): CreateResident 注册入站 inputch 后加 defer 回滚 ... 注册点与 residents 登记之间当前无可失败步骤，但缺回滚路径就是 child/<id> 残留那只 bug 的另一条入口。加 registered 标志 + defer：未走到成功返回就注销。	2026-09-13 21:59:10 +08:00
HomeAgent Agent	11d9038927	fix(io): ChannelRegistry 补 UnbindOutputTarget，Unregister 清理 outputTargets ... outputTargets 只增不减：Unregister 一个 inputch 后，指向它的输出目标登记仍 留在表里，ResolveOutputTarget 会继续把消息路由到已不存在的 agent/inputch。 与刚修的驻留 inputch 残留同属「注册未注销」类。现补 UnbindOutputTarget （幂等），并让 Unregister 顺手清掉显式绑定与同名回退两种目标登记。	2026-09-13 21:59:10 +08:00
HomeAgent Agent	44cb7243c5	fix(resident): 销毁驻留子时注销其入站 inputch（child/<id>）—— 修登记表脏数据累积 ... 根因：residentInboundChannel 在 create 时把 child/<id> 登记进共享登记表 （Plugin=resident, Owner=父），但 teardownResident 只把划入的 inputch （如 timer）归还为未分配，从未注销这条入站登记。于是每次 create/destroy 都在登记表里留下一条脏记录，且随次数单调累积。 实测（HomeAgent 侧，HΔ-Kernel v1.3.10 / 1b49365）： resident_agents destroy 之后，input_channels by_agent 仍列出 child/<id>， 归属 main；而 HomeAgent 没有任何工具能单独注销 inputch，只能重启 homed 清。 修法：teardownResident 里用纯函数 inboundChannelName 算出名字并 Unregister。 不能复用 residentInboundChannel——它有重新登记的副作用。 该路径同时覆盖 destroy / reclaim / StopResidents（父退出）。 测试：TestResident_LifecycleAndNoOrphans 增加两条断言——销毁后与父退出后 child/<id> 都必须从登记表消失。	2026-09-13 20:19:37 +08:00
JianFeeeee	1d4f2beeea	fix(prompt): 去掉"每轮只能发一次 output_send"的凭空限制；type 缺省即 text ... 用户现场指出：**qq 插件的输出通道判据太严了**（那条判据在插件侧，已单独修： `output_send__qq` 不再受"当前会话身份"限制）。同时内核提示词里还有一条**同类的凭空限制**： 「每轮对话**通常只需调用一次** output_send__{通道名} 即可完成回复。 仅在内容确实超过单条消息长度上限（如 >4000 字）时才拆分为多条」 可设计上输出是 agent 的**主动调用**：收到一次输入后，可以往**任意（已授权的）通道** 发**任意多次**（分段播报、先回执后结论、同时通知多个通道都合法）。这句话会让模型 自己收起合理的多次输出 —— 而且它不是任何机制的要求，只是当初为压 output-loop 写的 措辞（真正的防环机制是"回执只回 ok、不回传富结果"，那条保留）。 改法： - 提示词改为明确授权：**输出次数与目标通道由你自己决定**，没有「一轮只能发一次」的限制； 只保留两条真话：单条长度上限（超长拆完整段落）、别反复重发**完全相同**的内容。 - `output_send__*` 的 `type` 参数改为**可选**（缺省 text）：判据该拦的是"不知道发什么"， 不是"没写众所周知的默认值"——此前缺 type 会直接失败并让模型重试一次。 判据 3 条（新增 `output_rules_test.go`）：提示词不得含输出次数限制且必须显式授权 / 省略 type 时按 text 发送成功且 schema 的 required 只有 payload / 空 payload 仍被拦。 (cherry picked from commit 17ea7fd5f0)	2026-09-13 16:04:16 +08:00
JianFeeeee	e2500035d5	fix(resident): 子的「轮次」一直显示 0 —— info() 根本没填 Rounds ... 现象（用户线上联调实录 + 我复验）：父侧 `resident_agents` 列出 `输入ch=[timer] 轮次=0 处理表=2` —— **处理表已有两条记录，轮次却是 0**，自相矛盾，容易被读成"子没干活"。 根因：`residentChild.info()` 构造 `ResidentInfo` 时**从来没有填过 Rounds 字段** （结构体里有这个字段，于是永远输出零值），不是计数漏加。 改法：`Rounds = 已执行轮次数`（调度器执行计数，单调不减）。新增 `Agent.roundsExecuted()` 并写明为什么**不能**用 inputch 处理表条数当轮次：那张表记的是"当前上下文窗口内"的轮次， 压缩会清空（设计 §8.3）—— 用它会让父看到轮次倒退。 判据：inputch 路由测试里补一条断言 —— 子处理完输入后 `info().Rounds > 0`。 (cherry picked from commit cd88b2dfe5)	2026-09-13 15:41:07 +08:00
JianFeeeee	886ba78b11	fix(scheduler): inputch 划给子后输入只流向子 —— 补上「进内核之前」的输入路由 ... 用户指出的语义（设计稿 §4.1 早已写明）： **inputch 是可分配资源**，「路由发生在**进内核之前**」—— 划给某个 agent 后， 该通道的输入**只流向那个 agent**；outputch 不同，授权是**非独占**的， 父依旧可以通过它发送内容。 而代码里 inputch 划拨只做了**登记**，没有做**路由**： - 插件注入输入的 io 是**根 agent 的**（`cmd/homed` 里 `pluginReg.SetIOManager(iom)`）； - 唯一消费输入的是「该 io 自己的调度器」（`scheduler.go` 读 `a.io.InputChan()`）； - `ChannelRegistry.Assign` 只把 Owner 写进登记表，**没有任何转发动作**。 ⇒ 现场表现（用户线上联调）：子挂 `inputch=[timer]`，**timer 的输入却打在父身上** （日志 `[agent] interrupt from timer/timer`），子侧 `轮次=0` 永远不动。 登记表里的 Owner 于是沦为标签。 改法（按 §4.1 把路由放回"进内核之前"）： - `IOManager` 增加 `InputRouter`（`SetInputRouter`），并把**五处直接入队**收口到 `deliverInput`：`InjectInput` / `InjectInputSync` / `InjectInputTo` / `InjectInputSyncTo` / `InjectInterrupt`（排队与中断两条路都过路由）。 - 内核注入路由器 `Agent.routeInputByOwner`：查 inputch 的 Owner —— 归自己/未分配 ⇒ 本内核处理；归自己的某个驻留子 ⇒ `DeliverRouted` 交给它（**不再进父的队列**）； 归一个不存在的 agent ⇒ **不吞输入**，父兜底 + 留痕（吞掉输入比多处理一条更糟）。 - `DeliverRouted` 是"已路由"的投递口，不再二次路由（避免成环）。 - 同步输入的 `ResponseCh` 随事件一起走 ⇒ 回答由持有者写回同一回程（§4.3）。 判据（新增 6 条）： - io 层：被接管时排队/中断都**不入本内核队列**（且中断确实经过路由）/ 放行与未设 路由器时与历史行为一致 / `DeliverRouted` 不再触发路由 - 内核层：划给子的 inputch 输入进**子**（子 Executed>0）且**父 Enqueued 不变** / 归属到不存在的 agent 时父兜底（不吞）/ 未分配的 inputch 仍归父 (cherry picked from commit 4707b05498)	2026-09-13 15:35:59 +08:00
JianFeeeee	91c4bc01f1	fix(resident): 驻留子继承父的输出通道 —— 修「子侧 childIO 空壳、子不会发消息」 ... 现场（用户在线上跑驻留子联调，日志实录）： 父 agent 侧「通道装载完整」，子 `demo-resident` 侧 `childIO` 是**空壳**： 子的 `output_list_channels` 为空、`output_send__<通道>` 一律被判 「通道 [X] 不存在或不可用」，连 `output_send__*` 工具都不生成 ⇒ 子不会发消息。 根因：**输出通道在 io 层就是 Device**，而它们由插件登记在**父**的 `IOManager` 上。 `SpawnResident` 给子建的是全新 `IOManager`（它确实该有自己的输入入口与 outputCh）， 却只共享了 inputch 登记表，**没有继承设备/输出通道视图**： - `executeOutputSendTool` → `a.io.GetChannelCapabilities(ch)` 查的是 `devices[ch]` ⇒ 0 - 投递路径 `a.io.GetDevice(ch).Execute("output", …)` ⇒ nil - 工具面 `tooldefs.go` 从 `a.io.ListChannels()` 生成 `output_send__*` ⇒ 空 改法：给 `IOManager` 增加**上级回退**（`SetParentIO`）——驻留子创建时把自己的 io 挂到 父的 io 上，`GetDevice` / `GetChannelCapabilities` / `ListChannels` / `ExecuteTool` 在自己没有时回退到上级。 为什么是**实时回退**而不是创建时复制快照：设备随资源生灭（远程设备上线/掉线以分钟计， 现场日志 60 秒一个来回），复制出来的表转瞬即过期；而回退永远与父一致。 **授权不受影响**：回退只解决"看得见"，能不能用仍由各自的 `AllowedOutputs` 白名单把关 （`executeOutputSendTool` 的授权闸 + 工具生成时的过滤都在白名单之后）； 自己的登记优先，子可以覆盖/屏蔽同名通道。 判据（新增 5 条）： - io 层：无上级时行为与以前完全一致 / 挂上级后看得见 / **实时**（父新登记立刻可见、 注销立刻不可见）/ 同名自己的优先且不重复列出 / `ExecuteTool` 同样回退 - 内核层：子看得见父通道 + 真能发出（父通道收到 1 次 output）/ 白名单外被拒且未送达 / 子工具面只生成授权通道（含 `_help`）/ 父后登记的通道立刻可见 / 默认即完整授权 (cherry picked from commit 8537577123)	2026-09-13 15:09:44 +08:00
JianFeeeee	f168862eaa	fix(prompt): 系统提示词支持版本占位符 —— 人格卡不再写死版本号 ... 现象（用户发现）：agent 向用户自报版本是 **1.0.3**，而内核早已 1.3.x。 根因：**人格卡是配置项**，线上 `core.agent.system_prompt` 里写死了 「HΔ-Kernel v1.0.3 型号的家政型 AI 管家助手」——那是当年装机的文本， 之后每次发版都不会去改它，模型于是照抄给用户。默认模板用 `meta.Version` 拼接（`registry.go` 的 `fmt.Sprintf`）所以一直是对的，**只要被自定义过就会漂**。 修法：在 `buildSystemPrompt` 组装处展开占位符，让这类文本跟随真实构建： {{kernel_version}} → meta.Version（如 1.3.5） {{kernel_commit}} → 构建 commit {{sdk_version}} → 所兼容 SDK 版本（如 1.3.0） - 未知占位符**原样保留**：写错了要看得见，而不是被静默换成空串； - 不含 `{{` 时原样返回（提示词在热路径上）； - 覆盖所有路径：主 agent 与驻留子都经 `buildSystemPrompt`， `persona_set` 写入的文本同样在读取时展开（存的是模板，不是渲染结果）； - 配置项描述里写明可用占位符，引导用户别再写死版本。 回归判据 `TestExpandPromptVars`：展开正确 / 内置占位符不残留 / 线上真实人格卡文本能被纠正 / 未知占位符不被吞 / 无占位符不改写。	2026-09-13 14:34:44 +08:00
JianFeeeee	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
JianFeeeee	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
JianFeeeee	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
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	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	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	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	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	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	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	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	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
JianFeeeee	f1091676f8	style: gofmt 两处对齐（graphmedia_test.go 注释、tfidf.go 结构体字段） ... 这两处是本次特性分支带入的格式回归（origin/main 上不脏）。 纯空白/对齐调整，无语义变化；不整体重排文件。	2026-09-12 08:23:30 +08:00
JianFeeeee	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
JianFeeeee	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
JianFeeeee	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
JianFeeeee	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
JianFeeeee	b393b7072c	fix(ctx): prune 的查询向量改用插件 Cleaner 清洗后的有效内容(§13.8) ... ContextPolicy=prune 上线时直接把**原始**工具结果传给 RelevanceContext.Prune， 而 Prune 的入参是**相关性查询向量**——它决定保留/归档哪些上下文事件。于是 ANSI 转义、base64、JSON 包装等噪声全被编进查询向量，打分失真，裁掉本该 保留的事件。 而 ToolDef.Cleaner 的契约本就写着「仅在向量化/jieba/蒸馏时调用」，裁剪正是 在向量化——所以这是**回归契约**，不是新增能力。此前只在构建事件向量 （context.go 的 toolOutputClean）时用了 Cleaner，裁剪查询这一处漏了。 回退规则（Cleaner 是计算层优化，不能因它失效而丢内容）： - 未注册 Cleaner → 原文 - RPC 失败 → 原文（proc 侧 cleanerProxy 已有此保证） - 返回空串 → 原文（空串会让查询向量退化成零向量，所有事件相关性相同， 等于随机裁剪） 验证：TestToolOutputForQueryAppliesCleaner（Cleaner 被调用恰好一次且用其 结果；无 Cleaner / nil stageHost 回退原文）、 TestToolOutputForQueryEmptyCleanFallsBack。 顺带把 §13.13 第 5 条（反向大结果）按核实结论结掉为「不做」：核实发现根本 不存在 llm.chat（llm.* 只映射切换 LLM 源），唯一可能返回大结果的 doc.query 没有任何外部插件使用且已被 CapDocMemory 能力门限制。留成永久 TODO 只会误导。	2026-09-10 23:59:12 +08:00