|
|
8756f8d77f
|
fix(webui): 通道归属把「根 agent id」与驻留子分开（根不再被标成「驻留子 main」）
实测（创建一个驻留子 uitest 并把 timer 划给它）暴露的归类错误：
inputch 的 owner 在登记表里可以是**根 agent 自己的 id**（如 "main"）——
child/<id> 这条就是 owner="main"。前端只按「owner 非空」判为驻留子，
于是根自己那条被标成「驻留子 main」，而同一条通道在 residents 里根本不存在。
改法：
- /api/v1/runtime 补 agent_id（根 agent 的 id）；
- 前端把 owner == 根 id 与 owner == "" 归一成同一组「根 agent / 内核默认」，
只有既非空又非根 id 的才是子容器。
|
2026-09-14 11:08:27 +08:00 |
|
|
|
d502fc1bf5
|
fix(webui): 运行态面板逐段更新（真修「一闪一闪」）+ 补第五条排队队列
1) 上一版只做了整体签名缓存，实测仍会重建：设备通道列表本身就在来回变
（远程设备通道 11→9 条），签名一变就整块 innerHTML，没变的段落（含条
transition）也跟着推倒重来——视觉上仍是闪。改法：外壳只建一次，之后
**逐段**（tiles/levels/stack/owners/topo）比较 HTML，只替换真正变了的那段。
2) 设计是「四条中断队列（L1–L4）+ 一条排队队列」= 五个队列，面板只画了四条：
排队输入这条线在运行态里凭空消失。补第五行「排队（无级别）」，用中性色 +
虚线分隔（它不是优先级，而是另一**类别**），并把它计入条形归一化基准。
段标题从「中断队列（按级别）」改为「队列（四级中断 + 排队）」。
3) 顺带把累计计数（入队/执行/抢占/挂起恢复/拒绝/背压）显式列在数字块下方——
背压是新指标，之前只能看接口看不到面板。
验证：node --check 通过；go build ./... 干净；webui/core/sdk 测试全绿。
|
2026-09-14 11:03:37 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
c0e9dc1818
|
fix(webui): 聊天记录不再"每次都发完整记录"，并修掉视口跳顶
两个都是你指出的症状，都定位到了具体代码路径。
① 「每次都发完整聊天记录」
a) API 缺省值错了：/api/v1/chat/history 的 limit 缺省是 0 = **不限制**，
于是任何不带 limit 的调用每次都拿到整段记录。实测（126 条）：
不带 limit 635,297 字节；现在默认只回一页 180,668 字节。
显式 limit=0 仍可整取（逃生口）。WebUI/GUI 本来都带 limit，不受影响。
b) 前端 30s 轮询（以及每次 SSE 报错）都直接拉一页 40 条：
浏览器实测单次 180,813 字节。现在先做"尾巴探测"（limit=1，362 字节），
尾巴一致就直接跳过；不一致才拉整页。
② 「聊天记录会跳到顶部」——两条会导致视口丢失的路径都堵上
a) syncChatFromHistory 在"找不到重合点"时直接 `state.messages = serverMsgs`：
服务端只回一页，而本地可能已经向上翻了好几页；一覆盖，容器立刻变矮，
视口被夹回顶部，用户翻过的旧消息也凭空消失。现在只在服务端页**不短于**本地时
才整体替换。
b) renderChat 全量重建 innerHTML 后，仅在粘底时滚到底；非粘底（用户正在向上读）
时位置没人管。改为重建前记住 scrollTop、非粘底时原样还回去。
浏览器实测（CDP 驱动真实页面，126 条历史）：
* 15s/30s 定时器跑满 40s：聊天区滚动位置 **0 px 变化**，未跳顶；
* 期间 chat/history 请求：limit=1 × 2（各 362 字节）+ 首屏 limit=40 一次；
* 控制台无报错；新增消息后轮询仍能正确并进来（尾巴探测→拉整页→合并）。
测试：新增 TestChatHistoryDefaultIsPaged（默认一页 / has_more / limit=0 整取 / 显式分页）。
顺带修测试串味：迁移用例往 os.TempDir() 写共享历史文件，会让其它用例的
NewHandler 加载到脏历史（表现为条数多 1）；现在各用例用自己的临时文件。
|
2026-09-14 08:06:16 +08:00 |
|
|
|
764939ed90
|
refactor(webui): dashboard.html 6637 行拆成「外壳 + 样式 + 脚本」
前端刻意没有构建链（纯 CSS + Vanilla JS，go:embed 进二进制），所以拆法是：
外壳 dashboard.html 留 {{DASHBOARD_CSS}} / {{DASHBOARD_JS}} 两个占位符，
init() 启动时把两份资产原样填回去 —— **发出的 HTML 与拆分前逐字节一致**，
但 6637 行的单文件变成三份，便于编辑与评审。
dashboard.html 168 行 外壳（head/body 结构 + 两个占位符）
dashboard.css 2099 行 样式
dashboard.js 4371 行 脚本
逐字节校验（三重）：
* 组装结果 sha256 == git HEAD 里拆分前的 dashboard.html；
* 真实实例 GET /（带 API key）返回体 sha256 同上：0ef14b49…c053；
* 新增 TestDashboardAssetsSplit：占位符必须存在、样式/脚本不得再内联回外壳、
组装结果不得残留占位符且必须含样式与脚本特征串。
按行号切片时踩过一次坑并已修正：`</style>`/`</script>` 两个闭合标签被切掉
（正好少 27 字节）——正是因为当时少了逐字节校验，现在把它固化成断言。
|
2026-09-14 07:17:23 +08:00 |
|
|
|
4cbfdc970c
|
perf(webui)+feat(config): 聊天记录写盘节流 + 配置库空闲页回收
两条都是我上一封里点出、你说继续的问题。
① 聊天记录：每条消息都整段重写 → 节流合并写
原来 persistChatLocked 每次变更就整段重写记录文件，而一轮对话会触发多次
（用户消息、每个工具事件、收尾消息）。200 条上限下文件可达数 MB，单轮就能
放大出几十 MB 写。文件里还留着一个 chatSaveThrottle=3s 常量——声明了但从未
被使用（疑似上次 revert 的遗留），等于节流从来没生效。
现在：persistChatLocked 只置脏 + 唤醒写盘协程；chatPersistLoop 去抖
chatSaveThrottle(3s)、并以 chatSaveMaxDelay(10s) 兜底（持续输出也不会无限拖延）；
写盘前把快照拷出来，**不持 chatMu 做文件 IO**；写失败重新标脏下轮重试。
插件 Stop 里调 Handler.Close()：停协程 + 强制落最后一次（幂等），否则丢最后一轮。
实测（临时实例，连发 3 条消息）：3s 窗口内记录文件**尚未创建**（节流生效）；
SIGTERM 后文件出现且 6 条（3 用户 + 3 助手，无 LLM key 故为错误回复）全在
——关停落盘没丢。
② config.db：SQLite 的 DELETE 不缩文件 → 空闲页够多时 VACUUM
新增 ConfigRegistry.MaybeCompact(minFreeBytes, minRatio)：空闲页 >= 1MB 且
占页数 >= 25% 才做一次 VACUUM，避免每次启动都重写整库。库里是 WAL 模式，
VACUUM 之后必须再 wal_checkpoint(TRUNCATE)，否则主库文件看着没变小。
调用点放在插件加载**之后**（大值的搬走/删除发生在插件 Start 里，之前调没意义）。
实测（一个刚被搬走 5MB 聊天记录的实例）：
freelist 1288 页 × 4096B；启动日志「配置库已压缩: 5394432 -> 118784 字节」
config.db 5,394,432 → 118,784 字节；记录文件 5,279,491 字节完好未动。
测试：TestChatPersistenceIsThrottled（节流窗口内不写盘 + Close 必落盘 + Close 幂等）、
TestMaybeCompactReclaimsFreePages（删大值后文件确实变小 + 数据完好 + 阈值不达标时不白做功）。
|
2026-09-14 07:14:55 +08:00 |
|
|
|
642e1c39b1
|
refactor(webui): handler.go 2993 行按资源拆成 11 个同包文件
拆法：按「资源面」搬家，每个顶层声明（func/type/var/const）整体搬到目标文件，
声明体一字未改，各文件按实际用到的包重新生成 import。文件头加一行说明本文件负责哪一面。
handler.go 骨架：嵌入前端资源、Handler/构造、路由表、鉴权会话日志中间件、静态页
handler_chat.go 对话面：消息模型与内存历史、SSE 事件订阅、对话/历史接口
handler_upload.go 上传面：handleChatFile / handleUploads / 中断对话
handler_memory.go 记忆面：图/文档/文本记忆、知识库、LLM 源、变更追踪
handler_agents.go 内核与代理面：状态、kernel、人格、代理/快照/回滚
handler_settings.go 设置与插件面：配置读写、插件列表详情（含 pluginmgr 反代）
handler_terminal.go 终端面：终端会话、终端接口、命令历史
handler_sse.go SSE 环形缓冲（断线重连补发）
handler_openai.go OpenAI 兼容面：/v1/chat/completions
handler_device.go 设备网关反代（HTTP + WS 升级透传）
handler_files.go /files/ 与 /uploads/ 下载
零漂移校验：拿重构前的 handler.go 与新 11 个文件逐行比对（忽略空行、package/import 头），
**丢失行 0**；新增行恰好是 11 个文件头注释（14 行）。
顺带修掉 import 里两处假使用：handler_openai 的 sdk 只作为 Handler 字段名出现（h.sdk.），
handler_settings 的 fmt 只出现在注释里 —— 都从 import 里去掉。
验证：go build ./... / go vet / webui+config+sdk 测试全绿；
起真实实例（沿用已有 data 目录）后 /status /settings /chat/history /plugins /terminals
/kernel /memory /config /login 全部 200，设置在注入 5MB 历史的情况下仍是 33,921 字节。
最大文件从 2993 → 706 行（handler_chat.go）。
|
2026-09-14 07:03:47 +08:00 |
|
|
|
c4998bb102
|
feat(webui): 聊天记录改为独立文件存储（位置可配）+ 存量自动迁移
起因：聊天记录原先作为插件配置项 plugin.webui.chathistory 存在 config.db 里，
带来三个后果（都在生产实例上实测过）：
1. 整段记录 5,176,016 字节会被 GET /api/v1/settings 当普通配置项整块返回；
2. 每来一条消息就把整段记录重新 marshal 后写回 config 表，而那次写要拿
config registry 的全局写锁 —— 消息频繁时所有配置读写都被拖着排队；
3. 位置不可配（想放独立挂载盘只能改整个 data_dir）。
改动：
* 新增 internal/plugins/webui/history.go：
- historyStore：默认 <data>/webui_chat_history.json，写盘用同目录 tmp+rename
原子替换，崩溃不会留半截 JSON；读失败/JSON 损坏按空历史处理并告警
（聊天记录不是关键数据，不该让它拖垮 WebUI）。
- resolveHistoryFile：插件设置 history_file > 默认路径；相对路径按 data 目录
解析（可指向独立挂载盘），data 目录未知时落到系统临时目录而不是进程 CWD。
- LoadWithMigration：文件为准；文件为空而老配置项有内容时，把记录搬到文件、
搬成功才删配置项（删不掉就保留并告警，不丢数据）；文件已有数据时顺手清掉
上次没删干净的遗留键。
* 新增插件设置项 history_file（设置页可见可改）：留空 = 默认路径。
* handler.go：chatHistory 的读/写改走 historyStore，不再碰 settings；
顺带把「写失败静默忽略」改成告警。
存量迁移实测（拿仍持有 5,271,690 字节老记录的实例跑新二进制）：
日志：聊天记录已迁移到独立文件 .../webui_chat_history.json（1300 条），并从插件配置表移除
迁移后：config_webui 里 chathistory 行数 = 0；记录文件 5,279,491 字节
GET /api/v1/settings = 33,921 字节（迁移前 8,244,108）
GET /api/v1/chat/history 正常（从文件读回 1300 条里最新的 3 条）
新增测试：TestResolveHistoryFile、TestHistoryStoreMigratesFromConfig（含二次加载
不重复迁移 + 损坏文件不 panic）、TestHistoryStoreSaveIsAtomicAndRoundTrips。
|
2026-09-14 07:00:07 +08:00 |
|
|
|
0beb389223
|
fix(webui): 设置接口不再吐内部数据；--webui 覆盖生效；端口占用不再静默成功
三处实测确认的缺陷：
① 设置接口整块吐出聊天记录
plugin.webui.chathistory 是 webui 自己持久化的整段聊天记录（生产实例
实测 5,176,016 字节），躺在插件配置表里被设置接口当普通配置项整块返回，
前端还会把它渲染成一个巨大的文本框。
修复：GET 跳过该键（按插件+键精确判定），PUT 直接 400，避免误改。
② CLI --webui 与 webui.listen_addr 一直是死配置
内核原本在插件加载前写 settings["addr"]，但那时 config_<name> 表还没建
（表只在插件注册 def 时创建），PluginSettings.Set 的 INSERT 失败，而错误被
"_ =" 忽略了；随后插件 Start 里 RegisterDef 才建表并写入默认 :8080。
实测：传 "-webui 127.0.0.1:18099" 仍然监听 :8080。
修复：覆盖值改由插件自己接收（webui.SetListenOverride，loadPlugins 前调用），
优先级 CLI > webui.listen_addr（非默认值才算显式配置）> settings["addr"]。
实测修复后："-webui 127.0.0.1:18099" 正确监听 18099，与生产的 :8080 并存。
③ 端口被占时 webui 静默死亡
Start 在后台 goroutine 里 ListenAndServe，先打印 "listening on" 再尝试绑定，
失败只留一行日志，Start 永远返回 nil → 插件仍被当成加载成功。
修复：net.Listen 同步做，失败即返回 error（交给加载器/守护），
成功后才起 Serve，并打印真实绑定地址。
A/B 实测（两个实例都撞生产的 :8080）：
修复前："listening on :8080" + "server error: address already in use" + LOADED: webui
修复后："[plugin] start webui: webui: 监听 :8080 失败: ..."，不再有 LOADED: webui
效果实测（同一实例，先注入 5,271,690 字节 chathistory）：
GET /api/v1/settings 8,244,108 → 28,652 字节（约 1/288）
meta 条数 5,208 → 105，幻影键 0 条
设置页仍正常：?prefix=plugin.webui 返回 8 条 def；普通键 PUT 落库；
校验：GET/PUT 内部键被拒；-webui 覆盖真实生效。
新增测试：TestSettingsNoCrossPluginLeak（跨插件泄漏/幻影键/chathistory 读写）、
TestListenOverrideAndBindFailure（覆盖生效 + 端口占用必须报错）、
TestResolveListenAddrPrecedence（优先级）。
|
2026-09-14 06:54:16 +08:00 |
|
|
|
9e6627f0c3
|
fix(config): 插件 def 查询不再越界 —— ListDefs 作用域 + 新增 ListCoreDefs
两个方向相反的越界，合起来把 WebUI 设置接口的 meta 撑成 5208 条（96% 重复）：
1) PluginSettings.ListDefs(prefix) 把 prefix 直接透传给全局 ListDefs，
等于「返回全仓所有 def」——调用方以为在问某个插件，实际拿到全部。
修复：限定到 plugin.<name>. 命名空间，并把 Key 剥回插件内局部键
（调用方看到的键必须与 Set/Get/ListPlugin 的局部键一致）。
2) DefsCore(prefix) → reg.ListDefs(prefix) 会连插件 def 一起返回，
于是 meta 里出现 plugin.<name>.<key> 的「核心侧副本」。
修复：新增 ConfigRegistry.ListCoreDefs，显式排除 plugin.* 命名空间。
生产实例实测（旧代码）：GET /api/v1/settings 的 meta = 5208 条，
其中 core.agent.* 等每个 def 都被复制 28 份（每个插件命名空间一份），
并派生出 plugin.<a>.plugin.<b>.<key> 这类幻影键。
⚠️ 幻影键不只是脏数据：设置接口的 PUT 走 SplitN(key, ".", 3)，
对 plugin.<a>.plugin.<b>.<key> 会解出 (a, "plugin.<b>.<key>")，
即按 UI 上的幻影条目保存会**写进错误插件的配置表**。
新增 TestPluginDefsAreNamespaced 钉住两条作用域。
|
2026-09-14 06:53:58 +08:00 |
|
|
|
129a3aeb38
|
refactor(proc): coreHandler.Handle 550 行按 method 组拆成 14 个分部函数
原 Handle 是一个 550 行的巨型 switch（C ABI 51 个 case 的整块平移），
按协议面拆进同包 5 个新文件、14 个小函数：
corehandler_register.go handleRegister 注册面（tool/stage/output/api/input）
corehandler_inject.go handleInject IO 注入 + SetToolBlocks
corehandler_memory.go handleGraphMemory 图记忆
handleDocMemory 文档记忆
handleKnowledge 知识库
handleTextMemory 文本记忆
corehandler_settings.go handleSettings 设置（14 个 method 共用一条实现）
handleLLM LLM 源
handleSocial 社交图只读
handleLifecycle 生命周期开关
corehandler_runtime.go handlePluginMgr 插件管理
handleStageLocks 段锁仲裁
handleEvents 事件订阅
handleArena 共享槽池
Handle 保留 capability 强制检查，只做「method → 分部函数」一跳。
零漂移保证：case 标签由脚本从原文提取（不手抄常量名），case 体逐字搬迁，
逐函数比对确认 59 个标签 / 510 行 case 体与原文件完全一致（仅行首缩进经 gofmt 重排）。
验证：go build ./... / go vet / go test ./internal/plugin/... / -race 全绿。
|
2026-09-13 23:29:13 +08:00 |
|
|
|
dcae21b24c
|
refactor(lua): replaceSDKReal 633 行按 SDK 子表拆分
抽 luaReg 上下文（L/t/plg/s + subTable/pushVal/pushList/pushErr/pushNil
五个助手方法），把单函数拆成 registerRegistrars / registerInjectors /
registerDataAPIs / registerSettings / registerEventsAndMgr 五个方法。
被移动的代码体**逐字保留**：各方法头部把 L/t/s/plg 与五个助手注入为局部
别名，所以内部一行未改，行为零漂移。luaSyncUnavailable 提为包级函数
（原来它在被拆到另一个方法的作用域里会 undefined）。
实测：replaceSDKReal 从 633 行消失，最大子方法 265 行；非测试函数
>=300 行的数量 3→2。go build/vet/test -race 全绿。
|
2026-09-13 22:44:39 +08:00 |
|
|
|
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 |
|
|
|
6878f0126d
|
fix(lua): 同步注入在 Lua 中明确报不可用（避免自锁）+ 文档/mock 同步
sdk.inject_input_sync / *_opts / inject_input_media_sync* 在 Lua 里必然自锁：
Lua 代码只在 Start/工具/阶段/输出/事件回调中执行，这些路径都持有 plg.mu，
而同步注入要等本轮回复（回复路径上的回调又需要同一把锁）。原实现会挂死
直到超时；现改为立即返回明确错误，并在中英文 PLUGIN_DEV 里标注不可用 +
指向 Go 插件/异步注入。mock sdk.lua（SDK 仓为事实源）同步为同样的错误语义。
新增 TestLuaSyncInjectUnavailable 钉住不挂死。
|
2026-09-13 21:59:23 +08:00 |
|
|
|
52127a3323
|
fix(resident): CreateResident 注册入站 inputch 后加 defer 回滚
注册点与 residents 登记之间当前无可失败步骤，但缺回滚路径就是 child/<id>
残留那只 bug 的另一条入口。加 registered 标志 + defer：未走到成功返回就注销。
|
2026-09-13 21:59:10 +08:00 |
|
|
|
11d9038927
|
fix(io): ChannelRegistry 补 UnbindOutputTarget，Unregister 清理 outputTargets
outputTargets 只增不减：Unregister 一个 inputch 后，指向它的输出目标登记仍
留在表里，ResolveOutputTarget 会继续把消息路由到已不存在的 agent/inputch。
与刚修的驻留 inputch 残留同属「注册未注销」类。现补 UnbindOutputTarget
（幂等），并让 Unregister 顺手清掉显式绑定与同名回退两种目标登记。
|
2026-09-13 21:59:10 +08:00 |
|
|
|
4518c3eb03
|
fix(lua): events.subscribe 改用内部 Subscribe + 订阅生命周期（修死锁/use-after-close）
上一版 Lua 对齐引入的 sdk.events.subscribe 有两个真问题，本提交修掉：
1) 用了公共 SDK 的 Events()，但本内核从未注入 event subscriber
（SetEventSubscriber 全仓无调用点），拿到永远是 nil ⇒ subscribe 只会
返回 "events unavailable"。改用内部 SDK 的 s.Subscribe——内置插件走的就是
这条路径（cli/webui/skillmgr 全用它）。
2) 自死锁：subscribe 会在 Lua 的 plugin.start(sdk) 回调里被调用，而
luaPlugin.Start 正持有 p.mu；原实现在 subscribe 里再 lock p.mu 追加 subs，
不可重入 ⇒ 测试实测 30s 超时。改用独立的 subsMu。
3) use-after-close：Stop 会 Close LState，但事件订阅此前无人取消，残留回调
再触发就会碰已关的 L。现在：Stop 先（不持 p.mu，避免与 Bus.Publish
锁序反转）取 subsMu 取消全部订阅，再置 closed 并关 L；事件回调持 p.mu 后
先查 closed，已进入等锁的旧回调会直接返回。
4) plugin_mgr 访问补 nil 保护（部分单测构造的 SDK 不含 pluginMgr）。
回归：TestLuaEventsSubscribeAndStopCleanup——订阅后 Publish 命中、Stop 后
再 Publish 不 panic。全套 Lua 测试在 -race 下通过。
|
2026-09-13 20:33:13 +08:00 |
|
|
|
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 |
|
|
|
162f33f81e
|
feat(lua): Lua 插件桥全量对齐 SDK 1.3.0（媒体/注入标志位/优先级/事件/通道注销）
内核 Lua 桥（internal/plugin/lua_plugin.go）此前停在 v0.8.0 时代能力面，
1.1/1.2/1.3 新增能力只在 Go 侧存在，而 PLUGIN_DEV.md 宣称『能力完全对齐』。
本补丁把 Lua 侧补齐到与公开 SDK 1.3.0 对齐：
- 1.1 媒体：memory.commit 支持 sentence_text/media_digests；
doc.insert_with_media + attachments；text_memory.append attachments；
set_tool_blocks / inject_input_media(_sync) / inject_interrupt_media。
- 1.2 注入语义：inject_input_sync(_opts)、六个 *_opts 变体
（no_memory/context_policy/cleaner_name/priority）；
ToolDef/ChannelDef 解析 context_policy。
- 1.3 优先级与动态通道：priority 常量透传；unregister_output_channel。
- StageContext 暴露 reasoning_content/context_msgs/token_usage/memory/extra/errors。
- 新增 sdk.events.subscribe 与 sdk.plugin_mgr.*。
- sdk.lua mock 同步（单一事实源在 SDK 仓 sdk/lua/sdk.lua，内核副本由
third_party/homeagent-sdk/scripts/sync-lua-sdk.sh 同步）。
契约测试（lua_surface_test.go）：
- 守住内核内嵌 mock 与 SDK 仓事实源一致；
- 守住 mock 承诺的每个函数都有运行时 RawSetString 绑定；
- 覆盖 opts/media/attachments 解析与 context_policy 透传。
文档：中英 PLUGIN_DEV.md 的 Lua API 表补齐并改为『对齐至 SDK 1.3.0』。
|
2026-09-13 19:56:32 +08:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
ba3ab5a7d9
|
chore(meta): main 的版本路牌推到 1.4.0（1.3.0 已归 release/v1.3.x 所有）
规范 §2.1 / §七.4：切出 release/v1.3.x 后，1.3.0 就归发布线所有，main 立即推进到
下一个未发布中版本。此前停在 1.3.0 属遗漏 —— 会让 main 构建出来的二进制自称已发布版本。
|
2026-09-13 14:34:46 +08:00 |
|
|
|
a4ebcb6e96
|
fix(config): 播种时不再把版本号写进人格文本 + 存量实例一次性去版本化
用户发现：agent 自报版本 **1.0.3**，内核早已 1.3.x。
根因（两层）：
1. `SeedDefaults` 当年用 `fmt.Sprintf("…HΔ-Kernel v%s…", meta.Version)` **在播种时**
就把版本写进了 `core.agent.system_prompt` —— 装完即冻住，之后每次升级都不会
去改配置里的文本，于是实例终生自称装机那天的版本。默认模板用 meta.Version
插值本是"不写死"的做法，但**播种 = 把插值结果固化**，等于写死。
2. `core.agent.personal_prompt`（新人格机制）本身是对的（DefaultPersonaPrompt
无版本字面量，由 TestDefaultPersonaPromptHasNoVersionLiterals 钉住），
但旧键仍在系统提示词里说话，模型就照抄旧键的版本。
改动：
- **不再播种** `core.agent.system_prompt`：留空 → 组装时取 cmd/homed 的内置底座
提示词；人格由 personal_prompt 承载。全新安装不再预置会腐坏的文本。
- 新增 `migrateSeededSystemPrompt()`（在 SeedDefaults 最前，故不被播种标记早退）：
只对"当年那段播种模板"（前缀 + `HΔ-Kernel v<数字>` 字面量双判据）做
`v<数字>` → `v{{kernel_version}}`；用户自己写的人格卡一律不碰。
一次性标记 `core.internal.system_prompt_deversion_v1` 守住幂等 ——
幂等语句不等于语义幂等，重复执行会把用户后来手写的版本号也改掉。
- 与 v1.3.5 的占位符展开配套：占位符在组装系统提示词时按真实构建展开。
回归判据 4 条（`prompt_migration_test.go`）：存量卡被去版本化且正文不动 /
迁移只跑一次 / 用户自写卡不动 / 全新安装不播种该键。
|
2026-09-13 14:34:44 +08:00 |
|
|
|
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 |
|
|
|
937359b4df
|
feat(pluginmgr): plugin_install 支持本机 path（配合 plugindev_build 的产物）
背景：Agent 现在能自己构建插件了（plugindev 插件封装了 hmapdev），但安装只支持
http(s) URL —— 本地刚构建出来的 `dist/*.hmap` 装不上，链路断在最后一步。
pluginmgr 的 HTTP API 本来就接受 `{path}`（installFromPath），只是工具面没暴露。
改动：`plugin_install` 增加可选 `path`（本机 .hmap 路径），与 `url` 二选一，
同时给出时以 `path` 为准；`path` 必须存在且不是目录。描述里写明
「配合 plugindev_build 的产物用这个」。
于是 Agent 的完整闭环成立：
plugindev_init → plugindev_build → plugin_install(path) → plgreload
|
2026-09-13 14:17:11 +08:00 |
|
|
|
55dc6545f5
|
perf(memory): 静态词向量改用 float32 存储（省 ~0.65GB 常驻）
生产实测：`[static_embedder] loaded 200000 words`(zh) + `378151 words`(en) = 57.8 万词 × 300 维，
`map[string][]float64` 光向量本体就 **1.29GB**（外加 map 开销 ~0.1-0.2GB），占 homed
4.14GB RSS 的约三分之一。
源数据（fastText 文本格式）本身就是 float32 精度，用 float64 存没有任何收益：
- `words map[string][]float32` / `unkVec []float32`；
- 加载时按 `ParseFloat(..., 32)` 解析（与源精度一致）；
- 相似度累加仍在 float64（`sum []float64`，读时提升），计算精度不受影响。
⇒ 向量本体 1.29GB → 0.65GB，**省 0.65GB**。（与配置侧 `#topN` 可叠加：
生产把两份 vec 各限 5 万词后，向量降到 ~0.22GB。）
防复发：`TestStaticEmbedder_VectorMemIsFloat32` 用**编译期类型断言**
（`var typed []float32 = vec`）+ 字节数断言（词数×维数×4）钉住 —— 改回 float64 会直接编译失败。
验证：`go test ./internal/memory/ ./internal/agent/core/ ./internal/nlp/` 全绿。
|
2026-09-13 14:09:35 +08:00 |
|
|
|
fddefc78a1
|
fix(plugin): "只声明出站通道"的告警改为插件加载完成后判定（此前按注册顺序误报 qq）
## 现象
生产日志（v1.3.1 启动）出现：
`[plugin] qq 只声明了输出通道 "qq"，已按双向通道兜底登记 inputch；若要明确意图请显式 RegisterInputChannel`
用户据此问"qq 插件你没更新？"
## 查证：qq 没漏，是我的判据错了
- SDK 示例 `example/qq/plugin.go`：`RegisterOutputChannel("qq")` 在 368 行、
`RegisterInputChannel("qq", {NoMemory:true, Cleaner: inputCleaner})` 在 399 行 —— **先出站后入站**；
- 生产 `plugins/qq/plugin.bin`：版本 1.4.0，且二进制里含 `inputCleaner` 痕迹 ⇒ 确实调用了入站声明；
- 我的兜底告警在 **RegisterOutputChannel 的那一刻**判"有没有入站声明" ⇒ 对"先出站后入站"
这种完全合法的写法必然误报（a2a/acp/weather 同理）。
## 修法
告警判据从"注册时刻"改为"**插件 Start 结束后最终声明了什么**"：
- `regOutput` 只保留兜底登记（功能不变），不再告警；
- 新增 `warnOutputOnlyChannels(plugin)`，在插件加载/重载成功后统一判定：
遍历该插件**最终**声明过的出站通道，只有始终没有对应入站声明的才告警，
且措辞改为"内核已兜底登记 inputch，若这是有意为之可忽略"。
- 判据与顺序解耦后，告警才代表真实缺口（例：weather 的 `weather_out` 与
`weather_in` 名字不同，出站名从未被声明为入站 —— 那条告警就是真的）。
## 验证
- 新增 `TestWarnOutputOnlyChannels`：①先出站后入站（qq 写法）**不告警**；
②只声明出站（weather 写法）**告警且只报那一个通道**。
- `go test ./internal/plugin/ ./internal/plugins/...` 全绿。
|
2026-09-13 13:40:24 +08:00 |
|
|
|
18d7ad3a36
|
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:10:38 +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 |
|
