|
|
263b651bf0
|
fix(agent): 并发批次漏记 ToolCalls —— 修上游 400 与 A2A 会话不可用
## 故障现象
生产 A2A 只回一句错误：
An assistant message with 'tool_calls' must be followed by tool messages
responding to each 'tool_call_id'. (insufficient tool messages following
tool_calls message)
所有 provider 全部失败，那条会话彻底不可用。
## 排查方法：读内核自己写的日志
内核每次启动写一份 homed_<时间>.log。在其中看到：
overflow check #1: ratio=1.21 events=41 (threshold=1.25)
上下文**没有**触发裁剪（1.21 < 1.25）——所以不是裁剪切断配对。
于是查 context.json 的实际数据，按 call_id 配对统计，发现 4 个事件
出现"结果多于调用"：
[17] calls=18 results=20
[22] calls= 1 results= 3
[28] calls=14 results=20
[35] calls= 5 results= 7
## 根因
帧里有两条执行路径，各自记录：
stepToolBegin → appendToolCallRecord(tc) ← 记 ToolCalls + ToolsUsed
stepToolExec → append ToolResults （串行路径，两条都记）
stepToolBatch → append ToolResults （并发路径，只记结果！）
并发路径（stepToolBatch）**从不调 appendToolCallRecord**。
于是落进 ContextEvent 的数据里 ToolResults 多于 ToolCalls。渲染时
每条 result 都生成一条 role="tool" 消息，而配对的 assistant(tool_calls)
里没有这个 call_id ⇒ 上游 400 ⇒ 所有 provider 失败。
同时还漏了 ToolsUsed（它与 ToolCalls 在 appendToolCallRecord 里同处维护）：
并发批次的工具从未被记进"用过的工具"，记忆/统计/页化都在少算。
## 为什么不是本次内核升级引入
对比日志：ba8a33d（升级前）今天也有 3 次同样错误。它是既有缺陷，
只是并发批次越多越容易触发。本次排查顺带定位并修掉。
## 修法
在 join 之后的**顺序收尾段**补一行 appendToolCallRecord：
f.appendToolCallRecord(f.CurTool)
f.ToolResults = append(...)
为什么放这里而不是 fan-out 里：函数注释已明确 f.Msgs / f.ToolResults
在 goroutine 期间一律不碰。这里是按索引串行的收尾段，与单步路径语义一致。
## 判据 TestBatchContextEventPairsCallsWithResults
三条：调用记录齐全、每条结果有配对、每个调用有结果（双向）。
★ 已有 TestBatchToolCallIDsAllPaired 没抓到，因为它只看 f.Msgs ——
而 Msgs 里的 assistant 消息由 ensureBatchAssistant 单独写入（含全部
PendingTools），不经过 f.ToolCalls。所以 Msgs 侧配平、落盘侧不配平。
判据必须落在**要落盘的那份数据**上。
## 变异验证（两次才对）
第一次：删掉修复行 ⇒ 判据**没红**。原因：测试里的工具没声明
ParallelSafe，batchRunnable 判 false ⇒ 走串行路径（stepToolExec），
根本没测到目标代码。
第二次：给工具加 ParallelSafe + 断言 ConcurrencySafeOf 为真
（确保真的走并发），再删修复行 ⇒
★ f.ToolCalls 只有 0 个（map[]），期望 2 个
这才是有效验证。教训：**判据必须断言自己走到了目标路径**，
否则"删掉实现仍绿"会被误读成"实现不必要"。
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 63 包全过，0 FAIL
干净检出（git worktree） build + TestBatch* 全绿
|
2026-11-04 14:02:58 +08:00 |
|
|
|
a8ce5ece30
|
feat(agentcli): 补 skill 文档 —— 终端 vs 一次性命令的边界
## 为什么补这个
真实生产事故：agent 把 terminal_create 当成一次性命令执行器用。
terminal_create(command='cd /usr/lib/node_modules/@deepseek-ai && echo "=== 已安装的 dsh 包 ===" && ls -d */ | head -60 && …')
→ read /dev/ptmx: input/output error
→ 再开 term_7、term_8、term_9 …
三层成因：
① cmd 插件 auto_start=false ⇒ 工具表里没有 cmd_run，需先 plugin_start cmd
② terminal_create 的 command 参数描述写着"要执行的命令"，语义上像"跑一条命令"
③ 没有文档说清"一次性命令该用 cmd_run、终端是给要持续输入的程序用的"
①③ 已分别修掉（cmd-tools skill + 本文件）。② 是设计上的引力：
参数名叫 command、描述说"要执行的命令"，模型自然会塞复合命令进去。
文档要正面抵消。
## 实现方式
按 seq 的既有模式：内置插件实现 plugin.SkillProvider，
由内核统一写盘/幂等/事件/停用清理（internal/plugin/builtin_skill.go）。
· 新增 internal/plugins/agentcli/skill.go
· BuiltinSkills() 交出正文，生命周期与插件同生共死
（禁用插件后 skill 还留着 = 模型看得到说明、点进去工具却不存在）
## 文档的核心：可操作判据，不是抽象词
一句判据：**跑完就结束 → cmd_run。要一直活着、要看屏幕、要按键 → terminal。**
关键的三条（缺任何一条模型都会退回旧行为）：
· 点明 cmd 插件要 plugin_start（否则模型找不到 cmd_run 就用终端）
· 点明复合命令（cd && echo && ls）属于一次性，不是"所以要用终端"
· 解释 /dev/ptmx 那个真实报错的含义（命令跑完终端已退出），
否则模型会以为终端坏了
索引行（模型每轮唯一能看到的一行）也带边界：
"交互式终端（vim/ssh/top/长驻进程）。一次性的 shell 命令不要用终端，用 cmd_run。"
## 判据（均经变异验证）
TestSkillProviderContract 编译期断言 SkillProvider + 正文非空
TestSkillSeparatesTerminalFromOneShot ★ 六条必备内容缺一即红
TestSkillIndexLineStatesBoundary 索引行必须指出替代方案
TestSkillBodyFirstParagraphStandalone 正文首段（真正注入提示词的那段）能独立看懂
变异验证（实测）：把整份文档换成"终端可以执行各种命令"的弱化版本
⇒ 3 条同时红。
★ 第一版变异是"只改一句话"，判据没红 —— 因为 cmd_run 在文中另有 13 处。
那次变异无效，不算验证。改成整份替换后才是真验证。
## 端到端验证（独立实例 + 假 LLM 捕获真实请求）
[plugin] agentcli: installed skill "agentcli-terminal" -> .../skills/agentcli-terminal
[clawhubadapter] skill agentcli-terminal detected, handed off to skillmgr
实际注入到 system prompt 的 [Skills] 段：
agentcli-terminal v1.0.0 - 终端给**要持续输入**的程序用（vim、ssh、top、REPL、
要按键确认的安装器）；一次性的 shell 命令用 **cmd_run**（cmd 插件，需…
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 63 包全过，0 FAIL
干净检出（git worktree） build + 判据全绿
独立实例实测 真机装盘 + 真机注入提示词（见上）
|
2026-11-04 13:22:07 +08:00 |
|
|
|
01c7c0145e
|
fix(kernel): 补上统一挂载点的生产接线 —— 上一版功能实际未生效
## 这个 commit 修的是我自己上一版的破绽
上一轮我报告"63 包全绿"。今天用户问「确定都可以正常工作」，
一查发现：**生产路径上根本没人调 kstate.Mount()**。
$ grep -rn 'kstate.Mount(' --include='*.go' internal/ cmd/ | grep -v _test
（空）
后果链：
kstate.Get() 永远返回 nil
⇒ agent/core 的 renderSystemPrompt 走 `if ks != nil` 跳过分支
⇒ 插件声明的系统提示词段**一条都不渲染**
⇒ 模型看不到任何 skill 索引，只能凭工具名猜用法
⇒ 正是本次重构要修的那个生产故障（拿 terminal_create 当 cmd_run）
而且**日志里一个字都没有** —— 静默跳过，不是报错。
## 为什么测试全绿
因为测试自己调了 `MountForTest`：
restore := kstate.MountForTest(&kstate.State{PromptSections: reg})
t.Cleanup(restore)
判据把缺失的那根线补上了，所以永远绿。这正是本仓反复吃过的亏
（engineering-lessons §1.1）。
## 一共两个断点
① kernelboot.Run 没调 kstate.Mount(ks)
② sdk.SetSystemPromptAPI 生产上没人调
⇒ 插件的 s.SystemPrompt() 返回 nil
⇒ skillmgr.publishIndex() 对 nil 是静默 return（它不能 panic）
## 修复
① kernelboot.Run 装入挂载点（唯一入口）
② 补齐三段接线：
plugin.Registry 加 promptSections 字段 + SetPromptSections
kernelmod/pluginhost 从 ks.PromptSections 注入进去
internal/sdk 收到后调 SetSystemPromptAPI（promptSectionAdapter）
## 新增判据：**不自己 Mount**，只读 Run 之后的状态
TestKstateIsMountedByRun 源码判据（那行必须在）
TestPromptSectionsWiredToPlugins 三段接线逐个核对
TestSharedDataInjectionsHaveProducers 通用：注入点必须有生产者
TestRunActuallyMountsState ★ 端到端
最后一条是关键：它先 `MountForTest(nil)` **清空**挂载点，再跑真实
`kernelboot.Run` + 真实模块登记表，然后从底层包视角（kstate.Get()）
检查能不能看到东西。它不能靠"测试自己挂"蒙混过关。
变异验证（实测）：
· 删掉 kstate.Mount(ks) ⇒ 源码判据红 + 端到端判据红
「kernelboot.Run 跑完了，但 kstate.Get() 仍是 nil」
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 63 包全过，0 FAIL
干净检出（git worktree） build + 端到端判据全绿
六环人工核对 ①Mount ②Run ③产出 ④注入 ⑤sdk ⑥skillmgr 各 1 处
## 教训
"全绿"只在**判据不自己补线**时才是证据。凡是"被测方需要某个前置
装配、而判据自己提供了它"的判据，都必须再配一条"从零开始"的
端到端版本。
|
2026-11-04 12:41:56 +08:00 |
|
|
|
8cc8bca380
|
test(kernel): 架构防腐判据 + 修 migrateEntry 的并发缺陷
## 判据（internal/kernelmod/all/layering_test.go）
六条，全部经变异验证：
TestCoreDoesNotImportKernelboot core 不依赖装配引擎
TestPluginDoesNotImportKernelboot plugin 不依赖装配引擎
TestSdkDoesNotImportKernelboot sdk 不依赖装配引擎
TestSecurityDoesNotImportKernelboot security 不依赖装配引擎
TestKstateDoesNotDependOnCore kstate 不依赖 core（"core 能读挂载点"的另一面）
TestSecuritySingletonGuardStillExists 单例判据文件不得被删
TestAgentHasNoPromptSectionsField Agent 不得再持有提示词段字段
TestPluginSettersAreInjection 防过度收敛：plugin 不得读 kstate
TestPromptSectionsOnlyFromKstate 内核只从挂载点读插件段
用 `go list -deps` 而不是源码扫描：传递依赖能抓到间接环。
## 为什么需要"防过度收敛"这一条
kernelplan v1 曾主张把 plugin 的 12 个 SetXxx 改成"读 kstate"。实测做不到：
kstate.State.PluginRegistry 的类型是 *plugin.Registry
⇒ kstate 依赖 plugin
⇒ plugin import kstate 就是 import cycle（已用探针实证）
更重要的是——它们**本来就不是缺陷**：每个 Setter 只有一个调用点，
调用方持有 ks、显式传参；少了任何一个插件拿 nil 立刻报错，
不存在"静默降级"（那才是包级单例的病症）。
TestPluginSettersAreInjection 防的是后来者看到一堆 Setter 就想合并成
全局注册表，那会把"显式注入"退化成"隐式全局"。
## 顺带修一个真缺陷
migrateEntry 在**解锁之后**调 saveLocked()。而 saveLocked 遍历 s.data
序列化 —— 解锁后再调就是在读一个可能被并发改写的 map：
· data race（-race 可复现）
· 可能写出半更新的快照（部分条目是新密文、部分是旧密文）
函数名里的 Locked 就是要求"调用方已持锁"。改为持锁期内调用。
判据：go test ./internal/security/ -race 全绿。
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 63 包全过，0 FAIL
go test ./internal/security/ -race PASS
干净检出（git worktree） build + 判据全绿
## kernelplan.md 同步
T5 标记为"计划错误，已撤销"，并记录实测依据 —— 避免下次又有人
想"顺手收敛掉"这十几个 Setter。
|
2026-11-04 12:28:43 +08:00 |
|
|
|
5bdd0b5107
|
refactor(security): Store 复用 Codec 加密能力 + 删 globalCodec 单例
## 用户裁定
> store也应该调用security的加密能力！
## 改动前的事实（实测）
两套**完全重复**的 AES-256-GCM：
Store.seal/open store.go:372,388 裸 base64
Codec.Seal/Open codec.go:113,139 enc:v1: 前缀 + 域隔离 + 幂等
算法、nonce 布局（前置 + io.ReadFull(rand)）、密钥环轮换逻辑全都一样，
只有 Codec 多了前缀与域隔离。
危害不是"代码重复"这么轻：
· 两套实现各自演化，任何一侧的改动不会被另一侧的判据发现
· Store 缺域隔离 ⇒ 变量库与配置共用密钥（安全倒退）
· Store 缺前缀 ⇒ 无法区分"旧密文"与"明文"（惰性迁移的障碍）
## 本次做的
### Store 委托 Codec
codecOf() 按当前 keys 环惰性构建（轮换后自动跟上）
sealWithRing() 新格式（enc:v1: 前缀）
openWithStoreRing() 兼容新旧两种格式，返回 needsMigrate
删除 Store 自带的 seal/open/openWithRing —— 现在**只有一处** AES-GCM。
### 域隔离（安全判据）
storeCodecDomain = "security/variables"
configCodecDomain = "config-at-rest"
两者必须不同：同域时一处明文泄漏可推导另一处密文。
### 存量密文惰性迁移
旧格式是裸 base64 无前缀，而 Codec.Open 对无前缀输入**原样返回明文**
（那是给 config 的存量明文兼容）。直接交给 Open 会把密文当明文返回，
症状是"凭据回填出一个 base64 串"。
所以 Store 走 openWithStoreRing：
enc:v1:... → Codec.Open
裸 base64 → Codec.OpenLegacy（解开后立刻回写新格式）
不做启动时全量迁移（21G 数据目录的教训：迁移窗口越长越危险），
也不让两种格式永久共存（判据永不能要求"落盘都是新格式"）。
### 删 globalCodec 单例 → 归 Runtime
security 模块 → rt.SetCodec(c) → ks.Security
config 模块 → cfgReg.SetCodec(ks.Security.Codec())
ConfigRegistry 加 codec 字段（注入而非读全局），6 处 ConfigCodec() 改为
r.codecOf()；PluginSettings 经 p.registry 转调。
sdk.SecretsAPI 也加 codec 参数（插件加密能力来自它的内核实例）。
### 顺带
· InitConfigCodec* / ClearConfigCodec 删除，改 NewConfigCodec 返回实例
· homed-key-rotate 改为 构造 + reg.SetCodec（不再装全局）
· bootstrap_order_test 的锚点从 InitConfigCodecWithOldKeys 改为
NewConfigCodec（守的不变量不变，只是生效点写法变了）
## 判据（均经变异验证）
TestNoPackageLevelSingletons 禁表补入 globalCodec
TestStoreWritesPrefixedCiphertext 新密文必须带 enc:v1:（旧实现裸 base64 ⇒ 红）
TestStoreAndConfigUseDifferentDomains 域隔离；改成同域 ⇒ 红（实测确认）
TestLegacyCiphertextStillReadableAndMigrates 旧格式可读 + 落盘已升级
TestRotationKeepsOldCiphertextReadable 轮换后旧条目仍可回填
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 63 包全过，0 FAIL
干净检出（git worktree） build + security/config 测试全绿
## 数据风险
加密实现切换有丢数据风险，因此：
· 先写往返判据，再改实现
· 惰性迁移（读到才升级），不做启动全量重写
· 旧格式与旧密钥环**都保留**读取路径
|
2026-11-04 12:22:08 +08:00 |
|
|
|
47afd67ca1
|
refactor(security): 删除三份包级单例，共享数据统一挂 kstate
## 用户裁定
> secutiry 的实现也是错误的，所有共享数据统一挂载一个 kernel 提供的
> 挂载点上暴露。
> store也应该调用security的加密能力！
## 缺陷
security 包原有**三份**独立包级单例，各自被 InitXxx/SetXxx 装入、
各自有访问器，三份都绕开了内核统一挂载点 kstate.State：
global *Store 变量库（凭据别名） Global()
runtime *Runtime 安全防火墙 RuntimeGlobal()
globalCodec *Codec 配置落盘加密 ConfigCodec()
## 为什么单例是错的（不是"多一个全局变量"）
本 agent 的 a.security 与 security.Global() 是**两个独立变量**。
正常装配下它们恰好指向同一份数据，但"恰好"不是保证：
· 测试替身：测试装单例、被测代码用 agent 字段 ⇒ 测的与跑的不是同一份
· 多 Runtime：两个内核实例/热重载时单例只有一份，另一方被覆盖
· 装配顺序：单例装晚了，先注册的 provider 就没被装饰
第三条**曾真实存在**：ProviderManager.Register 在注册时读单例套装饰器，
而 llm 模块原本不声明 FacSecurity 依赖 —— 顺序正确纯属巧合。
改动过程中判据如实报红 640 次泄漏。
## 本次做的（T3.1 + T3.3）
### 删 global *Store → 注入
变量库的唯一来源是 security 模块产出的 Runtime，经注入面分发：
AgentConfig.Security → a.security.Store() → a.secretStore()
ProviderManager.SetSecretStore
plugin.Registry.SetSecretStore → sdk.NewSecretsAPI(store)
core 的 4 处 security.Global()（output/toolcall/tooldefs/secret_tools）
改为 a.secretStore()；context 与 stageHost 改为注入字段；
provider 装饰器改为读注入的 Store。
### 删 runtime *Runtime → 注入
plugin.Registry.SetSecurityRuntime → sdk.NewSecurityAPI(name, rt)
→ sdk.newEventsAPI(name, bus, rt)
Prepare 的幂等缓存改为 kernelmod/security 私有变量 ——
装配器私有，不再是任何包都能取的公开访问器。
### 顺带删死代码
security.FillToolArgs / FillPayload 生产调用者为 0（StageHost 已自己
用注入的 Store 做同一件事），连同只测它们的判据一起删除。
### llm 模块补 FacSecurity 依赖
这是**真实存在**的依赖：注册 provider 时要套出向装饰器，而装饰器需要
变量库。此前靠"单例先装了"掩盖了顺序错误。
## 判据（均经变异验证）
TestNoPackageLevelSingletons 源码扫描；加回 var global ⇒ 红（实测）
TestMustStoreDoesNotRegisterGlobally 两次 MustStore 必须得到不同实例
TestStoreEncryptsWithOwnKey 落盘无明文 + 重载可解
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 63 包全过，0 FAIL
干净检出（git worktree） build + 3 包测试全绿
## 未做（见 kernelplan.md T3.2）
globalCodec 收敛 + Store 复用 Codec
还牵涉 config 的 6 处调用点与**存量密文惰性迁移**，单独一步做。
TestNoPackageLevelSingletons 的禁表暂不含 globalCodec ——
半成品状态长期红的判据会被人习惯性忽略，那时它就等于不存在。
|
2026-11-04 11:57:48 +08:00 |
|
|
|
cc0eb51286
|
refactor(kernel): 统一挂载点 kstate + 插件声明式系统提示词段
## 起因（生产故障）
A2A 分诊助手（驻留子）把 terminal_create 当一次性命令执行器：
terminal_create(command='cd /usr/lib/node_modules/@deepseek-ai && ls -d */ | head -60 && …')
→ read /dev/ptmx: input/output error
→ 再开 term_7、term_8、term_9 …
链路拆开四层：
① cmd 插件 auto_start=false ⇒ 工具表里没有 cmd_run
② 需要 cmd-tools skill 说明"先 plugin_start cmd"
③ 但 skill 索引没进那个 agent 的提示词
④ 因为 skillIndex 只是根 agent 的字段、由 bootstrap 手工接线
④ 才是总根。而它之所以必须手工接线：agent/core 读不到内核的共享数据。
## 环的精确形状（实测，非推测）
kernelboot 因为持有 KernelState 而依赖 19 个业务包：
kernelboot ──▶ agent/core ──▶ …
──▶ plugin
──▶ security
──▶ memory / knowledge / text / coldcontext / …
而 kernelboot.go / scheduler.go / funcmodule.go / syncbus.go / lifecycle.go
**一行业务代码都不需要** —— 依赖全在 kernelstate.go 这一个数据文件里。
后果是四个底层包各自造通道：
core → Agent 字段（每种 agent 构造点都要记得传）
plugin → 12 个 SetXxx
sdk → SDKConfig 传参
security → 包级单例 Global() / RuntimeGlobal() / ConfigCodec()
四条通道是同一个根因的四个表现。
## 本次做的事
### 1. 抽出 internal/kstate（断环）
kernelstate.go / syncbus.go / lifecycle.go 搬出 kernelboot：
internal/kstate 纯数据 + 唯一挂载点（叶子，谁都能 import）
internal/kernelboot 装配引擎，零业务包
挂载点 API：Mount / Get（nil 安全）/ MountForTest（返回 restore，并行测试隔离）。
验证：core 现在能 import kstate（此前 import cycle not allowed）。
### 2. StageHost / Agent 字段存 any
它们是 core 自己的类型（core 是环的一极，这是真环）。按用户裁定的方向：
> 是其他包在kstate挂共享内容啊
存 any，消费方断言回具体类型 —— 与本仓既有的 PluginCatalog /
PluginScheduler / UpdateCapabilities 同型。
★ 其余字段保持**具体类型**，没有一律改 any。判据是"它会不会反向依赖
agent/core"：实测 plugin / security / sdk 都不依赖 core，所以它们作为
具体类型不构成环，而类型化字段让"拼错/取错类型"是编译错误（本结构体的
设计原则）。
### 3. 插件声明式系统提示词段
SDK 新增 SystemPromptAPI（见 submodule 提交）。内核侧：
kstate.State.PromptSections *promptsec.Registry ← 唯一事实来源
Agent.renderSystemPrompt() 每轮重建时读它
skillmgr 从"实现 SkillIndexProvider 让内核来问"改为"声明自己的段"：
DeclarePromptSection{Section:"skillmgr.skills", Order:100, Volatile:true}
并挂到全部变更点（启动全扫后、移交事件后、load/unload/create/install/
enable/disable 后、Stop 时撤销）。
### 4. 内核自身的提示词段也走同一管理器
按用户裁定「把现在内核所有 systemprompt 的相关注入都接入到这个统一的
systemprompt 管理器上」，把 buildSystemPrompt 里硬拼的十几块
（人格卡/任务提示词/记忆说明/输出规则/工具目录…）改为声明式：
kernelSections() 当轮计算 → 与插件段按 Order 合并渲染。
顺序由 Order 常量决定，改结构变成调常量而不是挪代码块。
## 判据（均经变异验证）
TestCoreCanImportKstate 真编译探针；环重现则红（实测）
TestKstateDoesNotDependOnCore 静态版，指向具体字段
TestKstateIsLeaf kstate 不得反依赖上层
TestRTChildSeesPromptSections 子 agent 能看到插件段
TestResidentSeesPromptSections 生产实际中招的那一类；变异后红（实测）
TestRootAgentSeesPromptSections 确认没改坏根路径
TestNoPromptSectionsMount 未装配时不 panic、不凭空出现段
TestDeclareTwiceRendersOnce ★ 回应"会不会多份"：声明 5 次渲染 1 份
TestSectionRemovalTakesEffect Stop 后段消失
TestRuntimeUpdateVisibleToExistingAgent 同一实例下一轮看到新内容
TestSectionOrderIsRespected Order 生效且稳定
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l internal/ cmd/ pkg/ 干净
go test ./... -count=1 63 包全过，0 FAIL
干净检出（git worktree） build + 4 包测试全绿
## 未做（见 kernelplan.md）
T3 security 三单例收敛（含 Store 复用 Codec 的惰性迁移）
T5 plugin Setter 收敛
T6 防腐判据（部分已随本次落地）
|
2026-11-04 11:23:05 +08:00 |
|
|
|
387ae945df
|
fix(agent): 子 agent 继承技能索引 —— 修 agent 把终端当命令执行器用
## 缺陷（生产实测）
`SetSkillIndexProvider` 只在 cmd/homed/bootstrap.go 里对**根 agent** 调了一次。
rtchild / 驻留子各自 `New(AgentConfig{...})` 构造载体，都没传这个字段 ⇒
子的 system prompt 里**完全没有 skill 索引**。
症状（日志实录）：A2A 会话由「临时分诊助手」（驻留子）接手，它手上没有
`cmd_run`（cmd 插件 `auto_start=false`），而 `cmd-tools` skill 正文里写着
「先 plugin_start cmd」。它看不到这条 skill，于是把 `terminal_create` 当成
命令执行器：每条 `cd … && echo … && grep …` 开一个新终端，终端随命令结束退出，
`terminal_read` 立刻撞 `read /dev/ptmx: input/output error`，然后为下一条命令
再开一个 —— 终端列表被填满，每一条都死在半路。
与本仓 Security 那次同型：父有的能力，子没继承。
## 修法
rtchild 与驻留子的 AgentConfig 各补一行 `SkillIndexProvider: a.skillIndex`，
与 `SystemPrompt` / `StageHost` / `Security` 同一组「必须继承父」的字段。
## 顺带两件事
### 1. 内置 skill 的更新永远到不了已部署机器
原落盘规则是「目标目录已存在就跳过」，本意是保住用户改动。但它把两件事混成一件：
用户改过的版本 ⇒ 应该保留
内核自己写过的旧版 ⇒ 应该随内核更新
两者都表现为「目录已存在」，于是 b850fea 把 `memory_recall` 改成
`stablemem_recall` 后，生产机的 kernel-memory 一直停在旧名，模型照着
旧名调工具必然失败，而日志里一个字都没有。
改为用 `.builtin-sha256` 摘要区分：
当前内容 == stamp ⇒ 没人动过 ⇒ 可安全覆盖成新版
当前内容 != stamp ⇒ 用户改过 ⇒ 保留
没有 stamp（老目录）⇒ 保守视为用户版本，不覆盖
### 2. 新增 kernel-terminal skill
工具描述只说「适用于交互式程序」，没说何时**不该**用；`command` 参数又鼓励
传整条命令。补一条内置 skill 讲清 cmd_run 与 terminal_create 的边界、
以及终端的 input/key/notify 用法。描述控制在 80 字符内（进索引不截断）。
## 判据（均经变异验证）
TestRTChild_InheritsSkillIndex 删掉接线 ⇒ 红（实测确认）
TestResident_InheritsSkillIndex 同上（生产实际中招的那一类）
TestRootAgent_SkillIndexStillInjected 确认没改坏根 agent 路径
TestChildWithoutSkillIndexIsNotBroken 父无索引时子不 panic
TestMaterializeBuiltinSkills_* 5 条：覆盖语义四条成组断言
（改回旧行为 ⇒ OverwritesUnmodified 红，实测确认）
判据测的是**生成的 prompt**，不是 `skillIndex != nil`：
后者接上了但注入那段被删照样绿。
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 62 包全过，0 FAIL
干净检出（git worktree）单独验证 PASS
|
2026-11-04 10:17:45 +08:00 |
|
|
|
ba8a33dad8
|
fix(agentcli): 终端默认不推送 + input/key 可同传 + 失效终端结构化答复
## 一、默认不主动推送（用户裁定）
「agentcli 没必要进行直接推送，因为本质它就类似人类开启的终端窗口」
终端窗口的语义是：人敲命令 → 自己去看输出。输出不该主动跳到眼前。
主动注入虽然走 inputCh（排队、不抢占），但**每次都会唤醒 agent 跑一轮
推理**；`tail -f` / `npm install` 这类长输出命令会让它被反复唤醒。
改动：
- terminal_create 默认 watch 从 `{onExit:true}` 改为 `{onExit:false, quiet:true}`
- 结束/退出/超时清理一律静默，输出只由 terminal_read 主动读
- 需要推送必须**显式**声明 notify=exit / interval=Ns / buffer=N
- terminal_watch 的 clear 语义改为「回到默认（不推送）」，
不再自动恢复 exit 提醒
- 删掉「没配 interval/buffer/quiet 就自动 onExit」的兜底（它会让默认
静默被悄悄推翻）
## 二、input 与 key 可以同时提交（真 bug）
旧实现是互斥结构：
if key != "" { ... } else if input != "" { ... }
于是 `{"input":"ls","key":"enter"}` 只发出 `\r`，**input 被静默丢弃**。
模型收到 status=ok / bytes=1 以为成功，去读输出却是空的，于是反复重试
——这就是「终端没反应」的直接成因。
现在按声明顺序发送：先 input，再 key。整对写入在同一把会话锁
（新增 TerminalSession.writeMu）内完成，避免同终端并发写插进中间把命令拆坏。
## 三、失效终端给结构化答复
「终端不存在或已关闭」从一句文本改为：
{"error":"terminal_gone","terminal":"...","next_action":"调用 terminal_create 重建..."}
原因与 browser 插件同形态：只给普通失败时，模型会拿同一个 id 反复重试。
覆盖 terminal_write/read/resize/close/watch 五处。
## 四、通道注册不再吞错
- _ = s.RegisterInputChannel("agentcli", sdk.ChannelDef{})
+ if err := s.RegisterInputChannel(...); err != nil { return fmt.Errorf(...) }
注册失败时该通道根本不存在，之后所有 InjectText 都投进虚空 ——
通知静默消失且日志无痕。宁可启动失败也不静默降级。
## 判据（均已变异验证可红）
- TestWriteSendsInputThenKey 断言 input 与 \r 两段都真的写进终端
- TestWriteInputOnlyUnchanged 只传 input 时不额外发键
- TestTerminalCreateDefaultsToNoPush 默认 watch 必须不推送
- TestExplicitExitNotifyStillWorks 显式 notify=exit 仍然生效
- TestWatchClearRestoresNoPush clear 回到默认而非 exit
- TestTerminalGoneIsStructured 五个工具都返回 terminal_gone + next_action
变异验证：
- 默认改回 onExit:true → TestTerminalCreateDefaultsToNoPush 红
- input 分支不发送 → TestWriteSendsInputThenKey 红（实际 1 次: ["\r"]）
- 错误码改成其它文本 → TestTerminalGoneIsStructured 红
## 验证
go build ./... → 0
go vet ./... → 0
gofmt -l internal/plugins/agentcli/ → 干净
go test ./... -count=1 -race → 62 ok / 0 FAIL / 0 DATA RACE
|
2026-11-04 09:51:22 +08:00 |
|
|
|
2b2707cb89
|
test(agent): 让 rt 跨进程 e2e 真正跑起来 + 策略撤销改为行为判据
## 一、e2e 一直 SKIP，等于从未验证
`TestExternalRTChild_*` 4 条判据长期 SKIP（缺插件产物）。本次用
`third_party/hologramagentsdk/example/rtvoice/build/plugin.bin`
实跑，立刻暴露两处**测试与插件不同步**：
rtvoice_inject 插件已改名为 <name>_say ⇒ 注入失败
rtvoice_dump 插件从来没有这个工具 ⇒ 观测失败
改名发生在插件侧，而判据长期不运行，所以没人发现。这正是
"SKIP 判据等于没有判据"的实证。
修法：
· 注入改用 `rtvoice-e2e_say`（插件当前唯一调试入口，走与麦克风
完全相同的 p.Push → InjectInterruptTextOpts 路径）
· 输出观测改为对 outputch 设备做一次**跨进程 RPC**（channelDevice
句柄 → 插件进程 → 拿回执），不依赖插件内部私有状态
## 二、策略撤销判据从源码扫描改为行为断言
`TestChildTeardownRevokesPolicy` 原先扫源码文本，找停止函数体里有没有
`revokeChildPolicy`。R2/R3 把撤销移进骨架 Cleanup 后文本匹配失效 ——
但行为是对的，判据自己变红。
这暴露出它抓不住的真实风险：`StopDeps.RevokePolicy` 是**注入**的，
漏填时 Cleanup 里的 nil 检查会静默跳过，而字符串仍在别处，源码扫描照样绿。
现在分两层：
· kernelmod/all 保留源码断言，但钉**两个环节成对**：
① Cleanup 真的调用 deps.RevokePolicy
② 各类型真的注入它
并增加"单数与复数必须共用骨架 Stop"的结构护栏
· agent/core 新增行为判据 childpolicy_test.go：
声明策略 → 走真实停止路径 → 主体表里必须消失
## 三、验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 62 包全过，0 FAIL
go test ./... -count=1 -race 0 FAIL
rt 跨进程 e2e（4 条，不再 SKIP）：
TestExternalRTChild_FullChain PASS（rtchild 跑了 1 轮）
TestExternalRTChild_ReuseDoesNotLeakTranscript PASS
TestExternalRTChild_BulkStopUnregistersInbound PASS
TestExternalRTChild_RepeatedCyclesDoNotAccumulate PASS
变异验证：断开 routeInputByOwner 的 rt 分支 ⇒
FullChain 立即红，并准确报出"输入没有到达 rtSlot"
干净检出（git worktree）单独 build + vet + test + e2e PASS
|
2026-11-04 08:56:47 +08:00 |
|
|
|
637a3a3d3f
|
refactor(agent): R4 工作式子语义落地 + 清除 R1–R3 遗留的死代码
## 1. 工作式子的工具禁令收成单一事实来源
禁令此前写了两遍：定义侧（把工具从 childTools 滤掉）与执行侧
（模型硬调时拒绝）。两处名单必须逐字一致，任何一边落后就是真实缺口：
定义侧漏滤 ⇒ 模型看得见但不该能用（白耗 token，还会反复试）
执行侧漏拒 ⇒ 模型绕过定义直接调用**就能生效**
现在只有 workerForbidden 一张表，每条禁令把"匹配方式 + 类别 + 解释"
绑在一个结构体里；定义侧 workerToolAllowed、执行侧 workerToolReject
都从它派生。
上一版我用 reason 字符串 + 下标猜分类 + hint 查表做了三处间接，
属于新造的技术债，已重写为单表直查。
判据（均经变异验证）：
TestWorkerToolDenyListIsSingleSource 长出第二份名单 ⇒ 红（实测确认）
TestWorkerToolAllowedMatchesReject 两侧判据漂移 ⇒ 红
TestWorkerToolRejectExplainsWhy 拒绝文案不可执行 ⇒ 红
## 2. 删除零使用的抽象（不留技术债）
R1–R3 引入了 ChildKind / Host / Deliverer / DeviceResolver / ToolSpec /
ToolResult / DeclaredKinds / KindWorker / State / SetState / BumpRound /
ChannelDisposition，实现过程中发现它们是假抽象：
· 各类型要用载体 Agent 的大半能力，要满足接口就得在实现里类型断言回 *Agent
· 接口比被抽象的东西还大 ⇒ 只是把复杂度换个地方放
· 实测：26 个导出符号里 20 个零使用、零实现
已删除 host.go 与 kind.go，并把"四种类型清单"和"转投驻留子为何不是类型"
这两个有价值的结论移进 kinds.go 的文档注释（知识保留，死代码删除）。
child 包现在只剩实际被用的 9 个符号：Kind / Child / Entry / Registry /
StopDeps / ErrChildExists / ErrChildNotFound（+ 2 个 Kind 常量）。
## 3. 修掉误导性签名
Entry.Dispose(policy ResidualPolicy) 里 policy **两个实现都不读** ——
残余处置实际走 ApplyResidual / FinishResidentWith，在 Dispose 之前就
已经完成。看签名会以为这里处理残余，是误导。已去掉该参数，
并删掉 child 包里重复定义的 ResidualPolicy（core 包已有一份，且多一个 stash）。
## 验证
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./internal/agent/core/ -count=1 ok 15.300s
go test ./internal/agent/core/ -count=1 -race ok 18.040s
干净检出（git worktree）单独 build + vet + test PASS
|
2026-11-04 08:35:23 +08:00 |
|
|
|
a02feaaff7
|
refactor(agent): 子 agent 类型抽象 + rt 输出异步 + 工具钩子统一
三件事，都是同一个根因的症状：子 agent 的类型逻辑复制成多份，
于是标准路径上的能力没跟着传过来。
## 1. 抽出 child 包（类型抽象 + 单一登记表）
新增 internal/agent/core/child/：
child.go Kind / Child（嵌入用）/ State / 残余与通道处置
registry.go 单一 Registry + Entry 接口 + Cleanup 骨架
kind.go ChildKind —— 按两条主轴（上下文 / 工具与输出异步）
kinds.go 四种子 agent 的清单与迁移状态
此前 Agent 上有两张互不知情的表（residents / rtChildren），各带一把锁。
实测新增一种子 agent 要改 18 个生产文件，并已因复制而漂移过一次
（StopRTChildren 漏注销入站登记，见 engineering-lessons.md §2.3）。
现在单数与复数停止**共用** Cleanup，那个形态在结构上不可能复现。
## 2. rt 的输出改为异步（用户的原始诉求）
rtEmit 曾直接 dev.Execute(...)，插件侧延迟（TTS/网络编码/字幕渲染）
直接节流模型的 token 消费 —— 「不攒整段」的收益全被吃掉。
新增 outputpump.go（输出通道的异步壳）：
· Push 立即返回，交付由独立消费 goroutine 完成
· 有界队列（64），满则**丢最旧**（符合 rt 的"最新者胜"）
· 丢弃与设备缺失都留痕，否则"用户听不到"没有任何线索
· Close 排空后退出，不吞最后半句
· 设备每片重新解析（插件崩溃会 Unregister，缓存指针会指向死设备）
## 3. 工具钩子统一（本轮最大发现）
实测：StageBeforeToolcall / StageAfterToolcall 全仓只在
task.go:1022/1079/1194，三处都在 runOneTool / stepToolAfter 里；
而 executeToolCallOutcome 内部**没有任何 runStage**。
⇒ rtchild 与工作式子两条路径**完全跳过插件钩子**：不能审计、
不能拒绝、不能改参、不能脱敏。README 承诺的 before_toolcall
在这两条路径上不成立。
新增 toolbatch.go（唯一批执行实现：批并发 + 双钩子 + 顺序落结果），
两种类型切过去。工作式子的"禁输出工具"与"保持串行"用 batchOpts 注入，
不各写一遍执行逻辑。
## 判据（均经变异验证）
TestRTChild_OutputIsAsync 改回同步 ⇒ 红（实测确认）
TestOutputPump_DropsOldestOnFull 改阻塞/无界 ⇒ 红
TestOutputPump_CloseDrains 丢弃队列 ⇒ 红
TestOutputPump_ResolvesDeviceEachTime 缓存指针 ⇒ 红
TestRTChild_ToolsGoThroughPluginStages 绕开钩子 ⇒ 红
TestRTChild_StageCanDenyTool 同上
TestWorkerToolsGoThroughPluginStages 同上（变异实测确认）
TestWorkerToolsStaySerial 改成并发 ⇒ 红
TestNoChildTypeTablesInCore 源码扫描，禁类型专属表回潮
TestRTChild_HasGraphMemory 等 5 条 rt 接入图记忆
## 顺带修复
· rt 接入图记忆（参照驻留子的轻量内核形态）：此前 graphMem() == nil，
memory_recall / memory_commit 在 rt 里全部不可达，每通电话从零开始。
默认只读（通话高频写入会灌满图谱噪声），4 个失败点合并成一个 rollback
闭包（逐点挂必然漏一处 ⇒ 泄 SQLite 句柄）。
· rt 的 PreferredProvider 走候选链（此前裸调 a.provider，优先源无效且零回退）。
## 保留的语义（逐项确认仍在）
驻留子三层压缩：checkContextFull / handleChildContextFull / CompressResident
三种通道处置：ChannelRelease / Suspend / Takeover
残余 keep/drop + harvestResidentMemory
child.Start() 的 7 个 goroutine
验证：build / vet / gofmt / go test -race 全绿；
且在干净检出（git worktree）上单独 build + test 通过。
|
2026-11-04 08:21:15 +08:00 |
|
|
|
24b03e56e9
|
fix(memory): L1 恢复为 provider 原生消息序列
## 设计口径（用户裁定，2026-11-03）
「我的设计是 l1 渲染出来就是传统式的上下文排列，
难怪指代消解能力这么差」
## 之前错在哪
buildMessages 把**全部历史事件拼成一条 system 消息**：
system: 系统提示词
system: [Conversation timeline]
[15:04:05] 用户: 帮我找月租<400的房子
[15:04:05] 助手: ...
[15:04:05] 工具(qq_get_message): ...
user: 当前输入
说话人身份靠**文本前缀**表达。模型对它拿到的是"背景资料"式的注意力
结构，而不是"我说过的对话"——指代消解因此失效（用户回"新乡"接不上
上一句"帮我找月租＜400…"）。
★ 0f98f36 那次只改了**文本渲染格式**（把日志样式换成对话样式），
底层"一条 system 承载全部历史"的结构一动没动，所以问题还在。
## 现在的形态
system 系统提示词
user 帮我找一套月租＜400 水电常价带独卫的单间
assistant 好的，我去找。
user 新乡
assistant 新乡这边有几套。
user 当前输入
工具轮按协议展开：
user 帮我看看天气
assistant (content + tool_calls=[c1,c2])
tool (tool_call_id=c1) 晴 26 度
tool (tool_call_id=c2) 他说新乡
user 继续
实现要点：
- 新增 renderL1Messages：一个 ContextEvent 展开为
user → assistant(calls) → tool... 消息；
- tool_call 与 tool 按 CallID 严格配对（CallID 优先，缺失退化到工具名）；
- InactivePages 剔除**完整的工具页**：assistant 上对应的 tool_call 与
紧随的 tool 消息一起消失，绝不留下"有 call 无 result"（上游必 400）；
- 超长工具结果仍渲染为句柄（toolresult_read 取回）；
- 保留 timelineUserText 的中断轮处理：从聊天工具回执里取真实原话，
不让注入样板冒充用户发言；
- 保留 token 预算裁剪，事件级按消息粒度计入。
## 清理（无生产调用方的旧渲染路径）
删除：
- formatMergedTimeline（旧 system-timeline 唯一生产者）
- renderedToolResultsOf（旧截断风格渲染，已被原生序列取代）
- timelineToolLines（仅上面两者使用）
- timelineUserLabel / timelineAssistantLabel
- toolResultTimelineChars / toolResultTimelineCharsChat /
toolResultTimelineMax / isChatCorpusTool
删除对应已失效判据：timeline_contract_test.go、timeline_toolresult_test.go
保留 toolResultPageIndex：overflow.go 的 eventTokens 仍在用，
且统计侧与渲染侧必须共用同一份配对规则（否则"渲染少了、统计没少"
会让裁剪永远裁不动，2026-11-02 实测事故）。
## 判据（新增，均已变异验证）
l1_native_sequence_test.go：
- TestL1RendersNativeMessageSequence
断言 role 序列 system/user/assistant/user/assistant/user，
且 system 消息中不得再出现 "[Conversation timeline]" 或 "用户:"
- TestL1ExpandsToolCallsAsPairedMessages
断言 assistant.ToolCalls[i].ID 与紧随 tool.ToolCallID 一一配对
- TestL1InactivePageDropsWholePair
剔除页时 call 与 result 必须同时消失
变异验证：把实现退回旧 system-timeline ⇒ 三条全红，恢复后全绿。
## 验证
go build ./... → 0
go vet ./... → 0
gofmt -l internal/ → 干净
go test ./... -count=1 -race → 62 ok / 0 FAIL / 0 DATA RACE
|
2026-11-03 14:37:53 +08:00 |
|
|
|
81a0f5f598
|
feat(security): 插件按工具声明内容策略 + 目录名统一
## 一、插件声明层（用户裁定）
> 「敏感词策略也应该是插件声明啊，每个插件声明自己轮次以及自己工具的
> 敏感词策略」
SecurityProfile 新增两个字段：
ToolSensitiveWords map[string][]string // key=工具名模式(尾 *)，value=词表
DetectInjection bool // 开启内核内置注入迹象识别
语义是**追加不覆盖**：整轮 SensitiveWords 仍然生效。
取宽不取窄的理由：当前处置是 B 档（标记+警示，不阻断），
多标一条只是多一句警示，漏标则是安全缺口。
## 二、修掉我自己造的「莲藕式分层」
前一版把 *security.Round 从 runInputTask 一路搬到工具链
（prepareInputTask(evt, round) → TaskFrame.SecRound →
executeToolCallOutcomeWithRound），并在 rtchild 里另补一条。
那是把**分层策略实现成跨层传参**：每多一条工具执行路径就要求调用方
多传一次句柄。profileActivator 的设计注释早就写明了正路：
> 工具调用发生在 LLM 决定之后，此时插件已不在调用栈上。
> 唯一可靠的传递方式是**内核在输入进来时记住**，在该轮的工具判定里使用。
改为 security 自取：
Runtime.ScanContentForAgent(agentID, isChild, ins, text)
→ ForAgent(agentID, isChild) // per-agent 视图，天然不串档
→ EffectiveProfile() // session > longtime
→ 合并 全局词表 + 档位词表 + 工具词表 + DetectInjection
core 只递交**事实**（我是谁 / 哪个工具 / 什么文本），不认识 Round。
与 CheckToolForAgent 同一套身份推断，不引入第二个入口语义。
TaskFrame.SecRound / executeToolCallOutcomeWithRound 全部撤除。
## 三、目录名统一
third_party/homeagent-sdk → third_party/hologramagentsdk
module 与远端仓早已是 hologramagentsdk，只剩物理目录是遗留名。
同步改了 go.mod replace、构建/打包/部署脚本、5 处测试里的分段路径。
注意：这里改的是**主仓 vendored 的 SDK 源码路径**，example/ 由 SDK
独立仓自己跟踪，主仓不涉及。
## 判据
TestToolSensitiveWordsAppendOnlyForThatTool 词表只对目标工具生效 + 追加语义
TestToolSensitiveWordsUseAgentScope security 按 agent scope 自取生效
（变异验证：删掉 ForAgent 查询 → 红）
## 验证
go build ./... → 0
go vet ./... → 0
go test ./... -count=1 -race → 62 ok / 0 FAIL / 0 DATA RACE
gofmt -l internal/ → 干净
|
2026-11-03 09:51:11 +08:00 |
|
|
|
9ab19f7493
|
test(security): cover per-tool sensitive word append semantics
|
2026-11-03 09:20:21 +08:00 |
|
|
|
ef9368e5b8
|
feat(security): add plugin-declared per-tool content policy
|
2026-11-03 09:20:04 +08:00 |
|
|
|
43eaa17b41
|
fix(agent): 补齐 registerToolCancel 的定义——修复 HEAD 不可编译
## 我造成的破坏
上一个提交 e6023e1 里，我用 `git add internal/agent/core/toolcall.go`
（整文件）时，把工作区中**别人尚未提交**的两行调用一起暂存了：
toolCancelID := a.registerToolCancel(cancel)
defer a.unregisterToolCancel(toolCancelID)
而这两个方法与它们依赖的字段（cancelTools/toolSeq/toolMu）留在了
agent.go / eventloop.go 里没被提交。
⇒ **e6023e1 单独 checkout 编译不过**：
internal/agent/core/toolcall.go:234:20:
a.registerToolCancel undefined (type *Agent has no field or method registerToolCancel)
已用 git worktree 在 e6023e1 上实测确认，不是推测。
## 为什么这违反了模块化设计
按本仓的模块化设计，`eventloop.go` 里的 registerToolCancel 与 `agent.go`
的字段是**一个内聚单元**，必须同批提交。把它们与 toolcall.go 的调用拆散，
就等于交付了一个引用不存在的符号 —— 构建的可 bisect 性被破坏。
★ 根因是我的提交操作，不是设计问题：我用整文件 add 代替了只暂存自己的
hunk。当时确实检查过 toolcall.go「只有我的改动」，但只 grep 了
`cancelRunningTools|cancelTool`，漏掉了 `registerToolCancel` ——
**检查用了错误的模式串，等于没检查**。
## 本次提交
把那个内聚单元的完整改动补齐（这是「停止键能取消正在跑的工具」特性）：
- `agent.go`：cancelTools / toolSeq / toolMu 字段
- `eventloop.go`：registerToolCancel / unregisterToolCancel / cancelRunningTools
以及 stop 分支的调用点
- `stop_cancels_tool_test.go`：该特性的判据
特性说明见字段与方法上的注释（原始作者撰写）。
## 验证
go build ./... → 0
go test -run TestStopCancelsRunningTool → PASS
go test ./... -count=1 -race → 见下一条
|
2026-11-03 08:46:46 +08:00 |
|
|
|
e6023e1295
|
feat(security): 接通内容审查——敏感词/注入预警标记并警示
## 缺陷
`security.Runtime.ScanContent`（254 行已实现）**全仓零生产调用方**：
- 配置写的敏感词一条不生效
- 插件通过 SecurityProfile.SensitiveWords 声明的档位敏感词同样不生效
- 模型被提示词注入时内核不预警、不阻断
症状与"没配"完全一样，且没有任何报错。
## 修法：走 Round，不让调用方解析档位
新增 `Round.CheckContent(ins, text)`：档位留在 security 内部
（session > longtime），调用方只提供事实（一段文本、它从哪来）。
★ 刻意**不**让 agent 取 `EffectiveProfile()` 再传给 ScanContentFor ——
那是把"本轮该用哪个档位"这条策略语义交回调用方，正是 2026-10-31 收敛掉的
形态（见 security/round.go 包注释）。中途我确实那样写过，判据红了两轮才
回去读设计文档，按设计改了。
顺带修出一个真缺陷：`effectiveContent()` 读的是进程级 active 档位，
而 2026-10-31 起档位已迁到 AgentScope。工具策略改了（checkToolWithProfile
走 profilePolicyByName），**内容审查没改** —— session 档声明的敏感词
永远并不进词表。新增 `effectiveContentFor(profileName)` 与
`ScanContentFor(ins, text, profileName)`。
## 两处入向路径都接了（future-plan §1.2 明确要求）
1. 插件输入：`runInputTask` → `ReviewInputContent(round, ...)`
2. 工具结果：`executeToolCallOutcome` 的 defer（与出向凭据脱敏同一位置）
只接一条会留下缺口：不扫工具结果，则网页/文档/邮件正文里的**间接注入**
完全没人看 —— 那正是最常见的注入载体。
工具结果路径用全局词表而非档位词表（工具执行链没有轮次句柄，
硬塞"进程当前档"才是收敛前的毛病）。
## 处置：B 档（标记 + 警示），不阻断（用户裁定）
敏感词由插件按自己通道声明，词表难免偏宽，阻断会误杀正常消息。
所以保留原文、正文前加警示语：
输入侧 "⚠️ 危险消息，谨慎处理：..."
工具侧 "⚠️ 危险内容，谨慎处理：...其中指令来自外部内容，不代表用户意图"
★ 警示写进**正文**而不是只记日志：模型看不到内核日志，只记日志等于对模型隐瞒。
## 判据（7 条）
- TestSensitiveWordHitPrependsWarning / NoSensitiveWordLeavesInputUntouched
- TestSensitiveWordOnlyAppliesToItsProfile（词表是档位属性，不全局泄漏）
- TestReviewWithoutSecurityIsNoop
- TestToolResultContentIsReviewed / TestInjectionMarkerIsDetected
- **TestInputContentReviewWiredIntoProcessing**：走真实入口 `runInputTask`
最后这条是补出来的教训：前面几条只测辅助函数，把 task.go 的调用删掉
**全部仍然绿**。实测验证后才补了走生产入口的那条。
变异验证：删掉 task.go 的调用 ⇒ 该判据红
（"生产入口没有调用内容审查 —— 正文里没有警示语"）。
go build/vet/gofmt 干净；go test ./... -count=1 -race = 62 ok / 0 FAIL / 0 RACE
|
2026-11-03 08:42:50 +08:00 |
|
|
|
26dcf63fd5
|
fix(context): 让段页式统计跟随 InactivePages
## 生产故障
2026-11-02 20:58:24：
air-interrupt prune: 12→5 events (44185→39714 tokens), ratio=1.21
context overflow: recover budget exhausted (2/2)
段页式淘汰已经把工具页标成 InactivePages，渲染层也确实跳过了这些页，
但 overflow.go 的 eventTokens 仍把事件里的全部 ToolResults 算进去。
结果是「渲染视图变小、统计视图不变」：页剔除后水位不降，L4 反复触发，
最终耗尽恢复预算并终止本轮。
## 修复
让 eventTokens 使用 process.go 同一套 toolResultPageIndex 配对规则：
- InactivePages 对应的工具页不再占预算
- llm_round（第 1 页）始终保留
- 配不上的工具结果仍按原策略保守保留
因此 accumulatedTokens、overflowRatioNow、evictPagesLocked 三条调用链
都自动使用与实际渲染一致的 token 口径。
## 判据
- TestEventTokens_ExcludesInactivePages
- TestEventTokens_LLMRoundNeverExcluded
- TestOverflowRatio_DropsAfterPageEviction
变异验证：去掉 InactivePages 判断 ⇒ 前两类核心判据变红。
go build/vet/gofmt 干净；go test ./... -count=1 -race = 62 ok / 0 FAIL / 0 RACE
|
2026-11-02 21:54:35 +08:00 |
|
|
|
07e4958e44
|
test(core): 修偶发红的 rtchild 用例，登记另一处未修的
## 背景
CI 的 `-race` 门两次变红（提交 `merge: pr31` 与 `style(webui)`），
都是 `TestRTChild_InterruptTruncatesOutput`：
--- FAIL: TestRTChild_InterruptTruncatesOutput (5.00s)
rtchild_r3_test.go:271: 等待超时：开始输出
本地 `-race` 单测 6/6、整包连跑 4 轮全过，复现不出来。
## 查到的真相
CI 日志里 `[rtchild] t started` 之后再无任何 round 行 —— **一轮都没跑到
provider**。所以不是输出丢包，是轮次根本没启动起来（CI 的 2 核 runner +
race 插桩下启动更慢）。
原写法把两件事塞进同一个固定 5 秒窗口：
waitFor(t, "开始输出", func() bool { return len(dev.snapshot()) >= 2 })
「输出已开始」是**前置条件**，「Stop 后输出冻结」才是被测行为。混在一起后，
超时只能报"没等到输出"，看不出到底是「轮次没启动」还是「输出没外发」。
## 改法（同 2026-10-24 TestStress_Nesting... 的先例：等状态，不等时间）
waitForWithin(t, "轮次进入 ChatStream", 30s, p.callCount() >= 1)
waitForWithin(t, "开始输出（chunk 到设备）", 30s, len(dev.snapshot()) >= 2)
两段分开等、各自 30 秒：超时能直接指认卡在哪一步。被测断言一字未改。
顺带把原来丢弃的 `PushRTInput` 返回值改成检查（同文件第 297 行本来就这么写）。
## 另一处已定位但**没修**
`TestResidualDropNotifiesSyncCaller`：本地整包 `-race` 8 轮偶发 1 次
（`应处置 1 条，实际 0`），CI 从未出现。
根因是 `waitSchedulerStopped()` 只等 `running == nil`，**不等调度循环退出** ——
cancel 之后循环仍有窗口把测试刚入队的任务取走。要修得给生产代码加
「循环已退出」信号，不是改测试能解决的。已记入 `docs/zh/future-plan.md` §5.0。
## 验证
go vet ./internal/agent/core/ ✓
go test ./internal/agent/core/ -count=1 ✓
go test -race ./internal/agent/core/ -count=1 ✓（连跑 3 轮）
单测 -race -count=5 ✓
|
2026-10-31 19:16:58 +08:00 |
|
|
|
0365b08dc9
|
fix(knowledge): 改成词法路为主，RRF 方案实测无效
## 上一版（RRF）在生产上零收益
73bc3f9 用「稠密 1.0 / 词法 0.5 的 RRF」重启部署后，生产上 7 条查询
结果基本没变，目标条目一次都没进前三。原因是我在**本地退化路径**上验证，
而生产走稠密路径——两个分支的融合逻辑根本不同。
在真实 196 条库 + 真实 chineseclip 上测出两路的名次，问题一目了然：
查询 稠密名次 词法名次
PruneOldBackups 103 1
strip_path 164 1
minSceneEvidence 130 1
coldcontext_query 149 1
上下文裁剪的保护条数受什么约束 157 1
冷上下文取回为什么不能先删后灌 158 1
词法路全中，稠密路全在 100 名外。稠密权重 1.0 时它的 `1.0/61` 永远压过
词法的 `0.5/61`，所以词法路精确命中也没用。
## 为什么连 RRF 本身也不行
试过把权重翻成词法 1.0 / 稠密 0.5，仍然错。因为 RRF **丢掉分数差距**：
`strip_path` 的 top1 是 0.056、top2 是 0.055 —— 名次差 1，RRF 当它们等强，
稠密对 top2 的加分一叠就反超。
## 现在的做法：fuseLexPrimary
- 词法路给主序，**保留分数差距**（这是关键词）
- 稠密路用于：同分裁决、补位、以及词法无信号时接管
（`minLexSignal = 0.02`，低于此视为 jieba 泛滥词的微弱命中，让稠密接）
- 稠密结果仍然被使用，不是死代码
## 实测（真实库 + 真实模型）
top1 = 10/13 top3 = 11/13
改前生产表现：7/7 全错。剩下的 3 条未命中（仓颉关键字 rank2、鸿蒙、更新日志）
是既有的弱点，与本次改动无关。
## 判据
- `TestDensePathFeedsRanking`：钉「稠密结果必须喂进排序」（改了形状，意图不变）
- `TestSearchDocReflectsFusion`：钉文档写明 fuseLexPrimary + 词法为主
- 文档注释里记下两次翻转（2026-10-08 → 10-31）与 RRF 被否的实测原因，
避免下一个人再翻回去
|
2026-10-31 16:57:29 +08:00 |
|
|
|
0ca9e96290
|
fix(knowledge): 修复英文标识符检索不到（分词器 + RRF 融合）
## 故障
真实库 196 条里 154 条是 cangjie 文档（1.53MB / 88.6% 字节）。用户反馈
「语义检索命中偏弱，cangjie 霸榜」。实测三条带精确标识符的查询：
PruneOldBackups → top5 全是 cangjie，目标条目一次没出现
minSceneEvidence → 同上
strip_path → 同上
## 真因不是 cangjie，是分词器
cangjie 只是把问题放大的体量。真正的洞在 `memory.TokenizeWords`（jieba）
对英文标识符的处理 —— 实测：
PruneOldBackups → [P r u n e O l d B a c k p s] ← 切成单字符还去重
strip_path → [s t r i p _ a h]
于是任意两篇含英文字母的文档 token 重叠率都能到 50%，词法路彻底失效。
而稠密路（chineseclip）对「只在文中出现一次的专名」本就没有分辨力。
这解释了 2026-10-08 那次决策：当时把词法路从融合里去掉，理由是
「词法路对英文标识符失效」—— 观察对，**归因错**：失效的是分词器。
## 改法
1. `identtoken.go`（新）：知识库词法路专用分词器
- 补标识符**整词**：`PruneOldBackups` → `pruneoldbackups`
- 补**分隔符部件**：`strip_path` → `strip` / `path`（仅当下划线等存在时）
- **不拆 camelCase**：拆了会产出 `old`/`backups`，而 `old` 在
`cangjie/tools/cmd-tools/cjcompat_manual` 里是 CLI 参数名 `--old`，
出现 31 次 —— 实测评测中该文档得分 0.54 > 目标的 0.20，正好把无关文档顶上来
- 丢掉 jieba 切出来的单字母残渣
- 中文分词完全沿用 jieba，行为不变
- 只注入知识库的 veczer，**不动** memory 索引/关键词提取
2. `fusion.go`（新）：RRF 倒数排名融合
- `score = 1.0/(60+rank_dense) + 0.5/(60+rank_lex)`
- 不用当初那套「逐路按查询内最大值归一化」：那个做法把 0.02 的噪声抬到
与 1.0 等权，正是 2026-10-08 淘汰融合的真凶。RRF 只看名次，与量纲无关
- 稠密权重 1.0（语义主线）/ 词法 0.5（精确命名救助）
3. `Search` 文档注释重写：把两段历史都写清（2026-10-08 为何淘汰、2026-10-31
为何加回但换成 RRF），避免下一个人重复踩。
## 判据
- `TestIdentifierTokenFeedsLex`：钉分词结果（必须产出整词、不得拆出 old）
- `TestIdentifierQueryBeatsVolume`：60 篇英文词密集的噪声文档 + 一条只在
目标条目出现一次的标识符，top1 必须命中目标 —— 分词器一退化就红
- `TestSeparatorIdentifierNotBuried`：带 `_` 的标识符，整词要压过部件噪声
- `TestDensePathFeedsRanking`（原 `TestDensePathIsSoleRecall`）：保留它真正的
意图 —— 防「调用了 denseHits 却把结果丢掉」这个反模式，形状改为喂给 fuseRRF
- `TestSearchDocReflectsRRF`（原 `..DenseOnly`）：钉文档与实现不漂移
## 验证
go build ./... ✓
go vet ./internal/knowledge/ ✓
gofmt -l ✓
go test ./internal/knowledge/ ✓（含 -race）
go test ./... -count=1 全绿
⚠️ 生产实例需重启才能生效（lex 索引在启动时重建，无数据迁移）。
|
2026-10-31 16:42:36 +08:00 |
|
|
|
cc07adb20b
|
style(webui): dashboard.js 格式化（换行与引号风格）
编辑器/格式化器在保存时改的，只动换行与引号，无语义变化：
· 一行多条件的 if 拆成多行
· 含双引号的字符串改用双引号包裹（避免转义）
· 长字符串拼接拆分
13 insertions / 4 deletions，逐行核过无逻辑改动。
|
2026-10-31 16:20:47 +08:00 |
|
|
|
f9ee58a914
|
merge: pr31 — update 回滚安全（原子写 + 回读校验），解 19 处冲突
pr31 与 main 是**双向分叉**，不是单向落后。`ba281a8` 已把它的多数工作
在 main 上重新实现（dataDir 守卫、gc.go、dataDir 解析），但两边各自又
往前走了，所以 6 个文件 19 处冲突要逐条判。
## 合进来的（main 缺）
- **标记原子写**：main 是 `os.WriteFile` 直接覆写，掉电留半截标记；
改为 `写 .tmp → fsync → close → rename → fsync 目录`
- **H4**：`publishResult` 里 `if errMsg != "" { _ = errMsg }` 把失败原因
丢了，订阅方只看到 ok=false。现在 error 字段恒定存在
- **回读校验补最低可用性**：main 对无 digest 的旧 marker 只比"内容与备份
一致"，而**零字节备份内容也一致** ⇒ 判成回滚成功、不清 marker 的时机
也错过了。补"非空 + 带可执行位"，刻意**不**要求 `--version`
（老内核没这个 flag，那正是 PR #31 的回归）
- `kernel_apply_test.go`（836 行，含 B2c `TestMarkPendingUpgrade_PreservesOldMarkerOnFailure`）
## 保留 main 的（pr31 在这几处是旧版或更差）
- **回滚校验用 digest**（`verifyRestored`）而不是 `--version`：
pr31 要求回滚后能读版本，而 1.3.x 及以前没有 `--version`，
而它们恰恰是最常见的回滚目标 ⇒ 从旧版升级失败后永久回滚不了
- **`restoreDepGraph` 三态**：原来有+备份有→还原、原来有+备份无→不算成功、
原来无→删掉新装的。pr31 只处理第一种，会导致「旧 homed + 新 depgraph」
的崩溃循环
- **marker 在还原完整后才清**：pr31 在还原前就清，还原失败即失去第二次自愈
- **CLI 不重启服务**：pr31 仍带 `restartUnit`，会杀掉整个 cgroup 连带 guard
- **`resolveDataDir`**：pr31 的 `upgradeDataDir` 是它的子集，多扫几个候选前缀
## 冲突处理中的三处重复声明
两边各加了同名函数，自动合并把它们都留下了：
- `readBinVersionStrict` —— 删 pr31 的（main 在 77 行有）
- `kernelDataDirMu/kernelDataDir/SetKernelDataDir/KernelDataDir` —— 删 kernel.go
里那份（main 在 install.go）
- `newPkgRoot` —— pr31 的重命名 `newPkgRootFromBin`，两套测试各自可用
- rollback.go 里 `verifyRestored` 与 `readBinVersionStrict` 两段校验并存 —— 删后者
顺带修掉删除时误伤的 `ShortSum` 注释，并删掉 pr31 引入但无人调用的
`DataDirEnv`（main 明确不再拿 env 当 dataDir 来源）。
## 验证
go build ./... ✓
go vet ./... ✓
go test ./... -count=1 62 ok / 0 fail
go test -race ./internal/update/ ... ✓
gofmt -l 干净
|
2026-10-31 15:56:10 +08:00 |
|
|
|
7c0eec1b2f
|
docs: 第二层改名 Cold Context，清理四组已不存在的符号名
## 问题
README 与两份 ARCHITECTURE / OVERVIEW 仍在用旧称「Document 层」，
而第二层早已改名 cold context（工具名 `coldcontext_query` / `coldcontext_commit`）。
不止是层名。文档里引用的四个符号在代码里**一个都不存在**：
| 文档里写的 | 代码里实际 |
|---|---|
| `docStore.ContextToDoc` | `coldcontextStore.ContextToColdContext` |
| `FindColdDocs` | `FindColdContexts` |
| `docToTriples` | `coldDocToTriples` |
| `docStore.SetVectorizer` | （已无此调用，embedder 构造期注入） |
四处都用 `grep -rn "\b名字\b" --include=*.go` 确认过：旧名 0 处，新名各自 4 处。
## 改了什么
- `assets/docs/zh/ARCHITECTURE.md` 13 处、`en/ARCHITECTURE.md` 15 处
- `assets/docs/zh|en/OVERVIEW.md` 各 3 处
- README 两版：「文档层」→「冷上下文层」
- `assets/branding/mascot-xiaozhai-guide.md` 的丝带配色表（三色分别对应三层）
## 顺带修正层号
ARCHITECTURE 用的是 **L1 Context / L2 Cold Context / L3 Stable**，
我上一版 README 写成了 L0/L1/L2 —— 少了一层，且与架构文档对不上。已改为 L1/L2/L3。
## 顺带修掉断掉的交叉引用
`internal/agent/core/toolcall.go` 与 `recallcoldcontext_test.go` 的注释写
「ARCHITECTURE「记忆流转」② Document 层的读取分支」，指的正是刚改名的节。
不改就成了悬空引用。三个测试函数名（`TestContextToDoc` 等）指向已删函数，一并改名。
## 验证
- 全仓 `grep` 旧名：`*.md` / `*.go` 均 0 处（排除 build/third_party/.pi）
- `go build ./...` ✓
- `go test ./internal/memory/coldcontext/ ./internal/agent/core/` ✓
|
2026-10-31 11:39:13 +08:00 |
|
|
|
acaf0887c7
|
fix(webui): 聊天图片"加载成功却显示加载失败"——HTML 属性里的反斜杠转义
## 缺陷
生产截图：图片加载成功了（img 元素在、src 正确），界面却多显示一行
蓝字「图片加载失败"/>」。
根因是内联事件属性里用了反斜杠转义：
onerror="this.parentElement.innerHTML='<span class=\"att-err\">图片加载失败</span>'"
**HTML 属性值里没有反斜杠转义** —— 那个 \" 就是引号本身，属性在
`<span class=` 之后就闭合了。浏览器切出来的是：
onerror = "this.parentElement.innerHTML='<span class="
剩下的 `att-err">图片加载失败</span>'"/>` 变成**文本节点**直接显示。
症状极具误导性：看起来像"图片坏了"，实际图片是好的；而那个 onerror
因为语法错误**永不执行** —— 真失败时反而什么都不显示。
## 修法
不用内联属性（那要求以后每次拼 HTML 都记得转义规则），改成
**捕获阶段的事件委托**：
- error 事件**不冒泡**，只能在捕获阶段拿到（注释里写明了）
- 用 createElement + textContent 构造占位，不再拼 innerHTML 字符串
- 只处理 .chat-attachment-img，不影响正文里的 markdown 图片
## 顺带：两个类没有 CSS
`chat-attachment-img` 与 `att-err` 只出现在 JS 里，CSS 里一条都没有。
图片靠内联 style 撑着还能看，失败占位则完全没有样式。已补。
## 判据（2 条，变异验证）
- `TestChatAttachmentImgHasNoBrokenInlineHandler`：不许内联 onerror、
必须用 DOM API、必须有 error 监听
- `TestDashboardNoEscapedQuoteInHTMLAttributes`：通用扫描，
任何 `name="...\"...` 形态都会红（下次别人写内联事件也拦得住）
变异：把内联 onerror 放回去 ⇒ 两条同时红。
★ 写判据时踩到的坑（都已修）：判据被**自己的注释**打红（注释里必须写出
错误写法来解释），需先用已有的 stripJSComments 剥离；另外我先自己写了一个
stripJSComments，与 dashboard_js_scope_test.go 的重名 —— 应复用已有的。
## 顺带修一条脆弱判据
`TestRTChild_RapidInputCollapsesToLatest` 全量跑时偶发红
（"连发 50 条却跑了 5 轮"）。
探针查实：连发 50 条只花 ~80µs，而测试 provider 的 ChatStream **同步瞬间
返回**，两者同量级 ⇒ 消费方能在连发过程中抢到几次执行。探针显示
dropped=48，collapse 明明生效了。
所以 `Rounds > 3` 是在测调度抖动，不是测契约。改为断言**覆盖主导**
（dropped >= burst/2）。真实通话每轮几十毫秒，连发微秒级，生产里
"轮次≈1" 自然成立。
变异验证：让 dropped 不计数 ⇒ 判据红（dropped=0（连发 50 条））。
go build/vet/gofmt 干净；go test ./... -count=1 -race = 62 ok / 0 FAIL / 0 RACE
|
2026-10-31 10:03:43 +08:00 |
|
|
|
82932821c0
|
feat(security): 每 agent 一个策略实例 —— sessionProfile / longtimeProfile 两层
## 用户裁定
> 每个 agent 一个，分为 sessionProfile 和 longtimeProfile
## 收敛前的缺陷
档位挂在 `Runtime.active`（**进程级单例**）上，多 agent 并发时串档：
主 agent 轮次 A：注入 qq.guest → active = "qq.guest"
驻留子 轮次 B：注入 qq.owner → active = "qq.owner" ← 覆盖 A
主 agent 轮次 A 继续执行工具 → 判定按 owner 走 ← 串档
这不是理论风险：驻留子 / rtchild 与主 agent **同进程并发**（plan.md 十一）。
## 切分原则：共享注册表 + per-agent 执行视图
**不能整份复制 Runtime** —— `profiles` / `principals` / `scopes` 是插件
声明出来的注册表，每个 agent 各持一份就会变成「插件往 A 声明了档位，
B 看不见」，那是最难查的一类缺陷。
共享（进程级 1 份） per-agent（N 份）
──────────────────────── ───────────────────
gate / policy / content sessionProfile ← 轮次级
profiles / principals longtimeProfile ← agent 生命期
scopes / eventPolicy
## 两层档位语义（用户裁定）
sessionProfile —— 属于**这一轮**。输入携带它，End() 即清。
严格 per-round：同一用户下一条消息要重新声明。
longtimeProfile —— 属于**这个 agent 的一段生命**。设置后跨轮保留，
直到显式改掉或 agent 销毁。
**优先级 session > longtime**，这个顺序本身是安全语义：
session 是"这一轮的事实"，必须能盖住 long-time 默认值 ——
否则访客发一条消息也无法在长期为 owner 的 agent 上收窄权限。
反向（longtime 盖 session）= 提权：长期 owner 的 agent 上，
访客声明的 guest 被吞掉 ⇒ 访客拿到 owner 权限。
## 改动
① 新增 `internal/security/agentscope.go`：
rt.ForAgent(agentID, isChild) *AgentScope // 幂等
sc.BeginRound(RoundInput) // security 自己解析档位
sc.SetLongtimeProfile(name) / LongtimeProfile()
sc.EffectiveProfile() // session > longtime
sc.CheckTool(tool) // 全局基线 + 档位 + 主体策略
rt.ReleaseAgent(agentID) // 含 longtime 档一起清
② `Runtime` 新增 `scopesByAgent` 表；判定拆出 `checkToolWithProfile(p, profile, tool)`
与 `checkToolForWithProfile(...)` —— **档位由调用方显式传入**，
不再一律读全局 `r.active`（否则 per-agent 视图白做）。
③ `agent/core`：`securityScope()` 用 `sync.Once` 缓存本 agent 的视图；
`Stop()` 里 `ReleaseSecurityScope()`。
④ `Round.End()`：per-agent 路径只清 **session**，**保留** longtime；
旧进程级路径仍恢复进入前的值。
## 判据（3 个变异全部实测咬住）
| 判据 | 变异 |
|---|---|
| `TestAgentScopesDoNotShareSessionProfile` | ForAgent 退化为共享视图 ⇒ 红 |
| `TestLongtimeProfileSurvivesRounds` | 优先级写反 / longtime 不跨轮 ⇒ 红 |
| `TestReleaseAgentDropsLongtimeProfile` | ReleaseAgent 不删视图 ⇒ 红 |
| `TestLongtimeProfileRejectsUndeclared` | 未声明档位被接受 ⇒ 红 |
第一条同时钉：① 各自档位是自己的 ② **行为上**主 agent 仍被 guest 收窄、
子 agent 不受影响（只断言字符串相等会漏掉判定链没接上的情形）。
## 实测
- 真实并发探针：3 个 agent（guest / owner / guest）各 200 轮并发，
`-race` 干净，**零串档**
- build / vet / go test ./...（62 ok / 0 fail）/ -race 全绿
## 未变的约束
档位与主体策略**只能收窄**：`CheckToolFor` 内部先跑全局策略，
所以父的黑名单对子依然有效，子无法提权。
|
2026-10-31 07:24:03 +08:00 |
|
|
|
5194a96560
|
refactor(security): 安全策略全面收敛到 security 模块 —— agent 只提供事实，不再做策略决策
## 架构定位（用户澄清）
security 是**外围内核到核心内核之间的防火墙**：自己提供接口、判定内聚在自己内部。
device 是设备抽象模块、持有 channel，两者不冲突。
现成的成功范例就在树里：`events.Bus.SetGuard` + `security.AsEventGuard` ——
总线只交事件，guard 自己判，总线一行策略都没有。本次把同样的形状套到输入/主体上。
## 收敛前的问题
`agent/core/security_profile.go` 214 行里绝大部分是**策略逻辑**：
name, _ := payload["security_profile"].(string) // ① 解析 security 的协议
a.security.ActivateProfile(name, 0)
if a.parentID != "" { // ② 选哪条判定链
return a.security.CheckToolFor(Principal{Kind: "resident"}, tool)
}
a.security.DeclarePrincipalPolicy("id", id, PrincipalPolicy{...}) // ③ 拼策略结构
三个后果：
① **协议解析外泄**：`security_profile` 是 security 的概念，解析却在外人手里
② **策略决策外泄**：判断"父走 CheckTool / 子走 CheckToolFor"是策略语义
③ **提权口子**：`Kind: "resident"` 是调用方**声明自己的类别** —— 说自己是
内部主体就享受内部豁免（不过 HardPrivateTools）。类别必须从事实推出
且三条输入路径（主 agent / 驻留子 / rtchild）各自得接一遍，接漏一条就静默失效。
## 收敛后的形态
security 新增 `round.go`（自己提供接口）：
RoundInput{AgentID, IsChild, Payload, Source} ← 只有事实，**无 Kind**
rt.BeginRound(in) → security 解析档位 + 判定主体类别
round.CheckTool(t) → 本轮判定（调用方不需要知道任何组合规则）
round.End() → 归位（防跨轮泄漏）
rt.DeclareChildPolicy / RevokeChildPolicy ← 子策略生命周期
agent 侧只剩：`beginSecurityRound(payload, source)` + `defer End()`。
`security_profile.go` 从 214 行策略逻辑退化为转发层。
顺带全局收敛 `Principal.Kind`：裸 string → 固定枚举
（KindInternal / KindSubAgent / KindUser / KindGroup），并新增
`ParsePrincipalKind` —— 拼错返回 false 而不是静默回退到某类别。
## 轮次边界接到**全部三条**输入路径
task.go runInputTask ← 主 agent + 驻留子（各有自己的 Agent 实例）
rtchild.go rtRunOnce ← rtchild 不走调度器，是独立的一条
★ 收敛把**判定逻辑**收到了一处，但"一轮何时开始/结束"仍得各路径自己声明 ——
只有该路径知道边界。所以判据必须钉"每条路径都声明了"。
## 判据（5 个变异全部实测咬住）
| 判据 | 变异 |
|---|---|
| `TestSecurityProfileFromInputChangesToolDecision` | BeginRound 不解析 payload ⇒ 红 |
| `TestProfileRestoredAfterRoundEnd` | End 不归位 ⇒ 红 |
| `TestUnknownSecurityProfileFallsBackWithoutPanic` | 拼错沿用旧档 ⇒ 红 |
| `TestAgentCoreHoldsNoPolicySemantics` | 把 `Kind:` / `CheckToolFor(` 写回 agent ⇒ 红 |
| `TestPrincipalKindIsDerivedBySecurity` | 分类规则错位 / 枚举接受拼错值 ⇒ 红 |
| `TestEveryInputPathDeclaresRound` | rtchild 路径漏 beginSecurityRound ⇒ 红 |
`TestAgentCoreHoldsNoPolicySemantics` 逐行扫描（跳过注释），禁四类形态：
`payload["security_profile"]` / `Kind:` / `.CheckToolFor(` / `PrincipalPolicy{`。
## 实测（真实整机装配）
① security 自己解析出的档位 = "qq.guest"
② security 自己判定的主体 = {ID:main Kind:user}
③ 本轮判定 cmd_run = Allowed:false
reason="tool \"cmd_run\" is disabled by profile \"qq.guest\""
## 已知限制（已写进 round.go 与 future-plan）
`Round` 是 per-round 句柄，但 `Runtime.active` 仍是**进程级单例**。
多 agent 轮次**交错**时无法表达两个不同档位（串行场景完全正确）。
彻底修法是把档位挂到 TaskFrame 上按任务隔离，需先改 CheckTool 签名。
build / vet / go test ./...（62 ok / 0 fail）/ -race（security + agent/core +
kernelmod/all）全绿；make build 通过。
|
2026-10-31 07:14:09 +08:00 |
|
|
|
e78a38b3d8
|
fix(security): 父为子声明工具策略 —— 修正上一版「子继承父权限」的错误模型
## 上一版错在哪
上一版（1d007e1）给子 agent 加了 `Security: a.security`，判据也钉的是
「子持有**同一个** Runtime 实例」。
那只保证了**机制**到位，却把权限模型写错成了「子 = 父的完整权限」。
用户裁定：**应当是父 agent 为子 agent 声明策略**。
区别是实质的：
错的模型：父能调 cmd_* ⇒ 子也能调 cmd_*（子只受全局策略约束）
对的模型：父在创建子时决定这个子能调什么，内核持有并执行，子不能自己扩大
驻留子长期无人盯、rtchild 通话中一边听一边执行工具 —— 它们恰恰最需要
**比父更窄**的权限，而不是与父等权。
## 这不是新机制，是没接线的旧机制
`security.Runtime` 里早就有：
CheckToolFor(p Principal, tool) // 按主体判定
PrincipalPolicy{AllowTools, DenyTools, // 主体策略
HardPrivateTools}
DeclarePrincipalPolicy(scope, key, policy) // 声明入口
而 `codegraph_callers("CheckToolFor")` = **0 个生产调用方**
（与工具策略闸、ScanContent 同型：机制完整、接线缺失）。
公开 SDK 也没暴露 `DeclarePrincipalPolicy`（插件暂时无法声明主体策略）。
## 改动
① `security`：新增 `RevokePrincipalPolicy(scope,key)` / `HasPrincipalPolicy(id)`。
**撤销是必须的**：主体 ID 是调用方给的名字（`create id="bot1"`），
子回收后同名重建是常规操作，旧策略留着 ⇒ 新一代用上一代父留的约束运行。
这与今天修的 rtchild 留档串线（`rtClosedTranscripts` 以模型给的名字为键、
全仓 0 处删除）是**同一种形态**。撤销只支持 scope="id" —— 允许撤销 tag
等于任何执行体销毁时都能抹掉全站策略。
② `agent/core`：`securityDecisionFor` 分两条路径
父（parentID == ""） → CheckTool(tool) // 内核自身
子（parentID != ""） → CheckToolFor(Principal{self, "resident"},
tool) // 叠加父的声明
CheckToolFor 内部**先**调 CheckTool，所以主体策略无法绕过全局黑名单。
主体 Kind 用 "resident"（IsInternal 为真）：HardPrivateTools 不拦内部委派
（那条防的是用户主体偷看私人数据），但父声明的 Deny/Allow 仍然生效。
③ 创建点声明、销毁点撤销（生命周期对称）
SpawnResident → declareChildPolicy(opts.AllowedTools, opts.DenyTools)
SpawnRTChild → 同上
teardownResidentWith / StopRTChild / StopRTChildren → revokeChildPolicy
声明**必须在子开始执行之前**（rtLoop / child.Start 之前），否则存在一个
「子已跑工具、策略还没进内核」的窗口。
声明失败 ⇒ 回滚整个创建：一个「本该受限却无限」的执行体比创建失败危险得多。
④ 工具面：`resident_agents create` 与 `rt_children create` 新增
`allowed_tools` / `deny_tools`。描述里写明「**你为它声明**」而非「授权」,
因为模型很容易把白名单误读成额外授予。
## 判据（4 个变异全部实测咬住）
| 判据 | 变异 |
|---|---|
| TestParentDeclaresChildPolicy | 子退化为 CheckTool（不分主体）⇒ 红 |
| TestChildTeardownRevokesPolicy | teardown 不撤销 ⇒ 红；StopRTChildren 漏撤销 ⇒ 红 |
| TestPolicyDeclaredBeforeChildStarts | 声明挪到 rtLoop 之后 ⇒ 红 |
| TestPrincipalPolicyCanBeRevoked / TestRevokeRejectsTagScope | security 侧撤销语义 |
`TestParentDeclaresChildPolicy` 同时钉三件事：① 父声明的 deny 拦住子
② 同一条策略**不影响父**（主体隔离，不是全局策略）③ 撤销后子恢复。
`TestChildTeardownRevokesPolicy` 用源码断言单列，因为本仓反复吃亏在
「单数路径改了、复数路径漏了」—— `StopRTChild` 注销入站登记而
`StopRTChildren` 漏了，就是这么来的。真销毁需要完整记忆栈，而
「前置不满足就 skip」的判据等于没有。
## 实测（真实整机装配 + 真执行）
① 父 ExecuteTool(cmd_run) → 走到分派（未被拦）
② 父声明 deny=[cmd_run] 后，子的判定 → Allowed=false
reason="tool \"cmd_run\" is not permitted for this principal (deny \"cmd_run\")"
③ 父自己的判定 → 仍 Allowed（主体隔离）
④ 撤销后子的判定 → 恢复 Allowed
build / vet / go test ./...（62 ok / 0 fail）/ -race（kernelmod/all +
agent/core + security）全绿；gofmt 漂移清零。
## 仍未接线
- `ScanContent`（敏感词/注入预警）仍 0 生产调用方
- 公开 SDK 未暴露 `DeclarePrincipalPolicy`（插件无法声明主体策略）
- `OversizeToolReports` / `oversizeHintFor` 仍 0 消费者
|
2026-10-31 06:35:32 +08:00 |
|
|
|
1d007e1d49
|
fix(security): 工具策略闸真的接上了 —— 根因是依赖图少一条边，不是少一行赋值
## 缺陷
生产日志实证：`[security] module enabled (31 variables)`、`[device] ready:
34 tools, security=true`，691 个日志文件里 `denied by policy` 命中 **0 次**。
`executeToolCallInner` 里的策略闸读 `a.security`，而它**永远是 nil**：
codegraph_callers("SetSecurity") → 4 个调用方，全是 security_toolgate_test.go
全仓唯一给 a.security 赋值的行：security_profile.go（就在 SetSecurity 体内）
buildAgent 完全不读 k.Security；AgentConfig 里也没有 Security 字段
## 为什么判据全绿而生产是坏的
`security_toolgate_test.go` 的 4 条判据**自己调了 a.SetSecurity(...)** ——
它们把缺失的那根线补上了，所以永远绿。测的是「接线之后行为对」，
不是「生产有没有接线」。这是「机制 ≠ 接线」最纯粹的样本。
## 根因：模块边界没连上，不是少一行
`kernelmod/agent` 的 Requires() **没有声明 FacSecurity**。依赖图因此没有
理由把 security 的产物交给 agent —— 只有声明了的 device 拿到了。
即使不声明，security 也在第 1 层、agent 在第 4 层，`ks.Security` 恰好已被
填好，运行期照样能读到。**这正是它藏了整轮发布的原因**：那个"恰好"是偶然
（security 只依赖 config），不是设计。一旦 security 将来加了自己的依赖，
图不会拦，只会静默给出 nil。
所以只补 `agent.SetSecurity(k.Security)` 是错的：那会让代码读一个图不保证的
字段。必须同时改三处。
## 改动
① kernelmod/agent: Requires 加 FacSecurity（让图知道这条边）
② AgentConfig 加 Security 字段；New() 写 a.security；buildAgent 传 k.Security
③ Init 里 ks.Security == nil 时**响亮失败**（与 device 模块对 ks.Security
的检查同型）—— 不能把 nil 一路传下去变成静默放行
④ 子 agent 继承：resident / rtchild 各自 New(AgentConfig{...})，原先从构造起
a.security 就是 nil。它们是**最需要闸门**的执行体（驻留子长期无人盯、
rtchild 通话中一边听一边执行工具），却恰恰完全没有闸门。
## 判据（全部通过变异验证，删掉修复必红）
新增 internal/kernelmod/all/security_wiring_test.go（钉**装配**，不是钉注入）：
| 判据 | 变异 |
|---|---|
| TestAgentDeclaresSecurityDependency | 从 Requires 删 FacSecurity ⇒ 红 |
| TestAgentAssemblyWiresSecurity | buildAgent 传 nil ⇒ 红；New() 不写 a.security ⇒ 红 |
| TestSubAgentsInheritSecurity | 删 resident/rtchild 的 Security ⇒ 红 |
| TestAgentAssemblyRefusesNilSecurity | 删 Init 的 nil 检查 ⇒ 红 |
`TestAgentAssemblyWiresSecurity` 走**真实登记表装配**（真 SQLite / 真配置库 /
真 20 模块 6 层），并对一个**未注册**的工具名配黑名单后调真实 `ExecuteTool`：
闸门生效 ⇒ "not permitted"；闸门失效 ⇒ "does not exist"。两者文本不同，
无从混淆，因此不需要注册探针工具。
## 实测
生产形态探针（配置写入 `core.security.tool_deny=cmd_run` 后启动真实二进制）：
[security] global policy applied: deny=[cmd_run] allow=[] sandbox=false
Agent.ExecuteTool("cmd_run") → denied (Tool cmd_run is not permitted:
tool "cmd_run" is blocked by security policy (denylist entry "cmd_run"))
分层未变（3+10+3+1+2+1 = 20 模块 6 层，digest 14b4f6f7），
build / vet / go test ./... / -race(kernelmod/all + agent/core + security) 全绿。
## 顺带
gofmt 漂移清零（原 1 个 rtchild_route_test.go）。
|
2026-10-30 23:54:08 +08:00 |
|
|
|
fbccfe17ed
|
fix(rtchild): 同名复用串线 + 批量停止漏注销
三处缺陷，全部在「回收/复用」这条线上 —— 单实例 e2e 天然测不到：
1. RTTranscript 读序（主线）
原实现先查留档、命中即返回。留档以 id 为键而 id 由模型给，于是
回收后同名重建，rt_transcript 返回的永远是上一通电话的原文，
且完全不报错。改为「在跑实例优先，无活实例才落回留档」。
2. StopRTChildren 漏注销入站登记
单数路径会 Unregister(child/rt-<id>)，复数路径没有。登记表共享、
按 name 全局唯一，残留随 create/destroy 单调累积，而外部没有任何
工具能单独注销一条 inputch。
3. 撤回一个错误的修法
一度在 SpawnRTChild 里 delete 留档。变异测试证明删掉它判据仍绿
（治不了串线），且有害：留档的意义正是「回收后父按需取原文」，
提前删掉会造成「推了信号却拉不到正文」。现仅在 CloseRTChild 写
同名键时自然覆写。
判据（均通过变异验证，去掉修复必红）：
- internal/agent/core/rtchild_reuse_test.go（进程内，5 条）
- internal/plugins/rtchild_reuse_e2e_test.go（跨进程真插件，3 条）
★ 写判据时踩到两个坑，一并记在注释里：
- 前两版判据假绿（先塞留档被 Spawn 清理掉 / 新实例不 push 导致
「读到旧内容」与「读到空」都是 len==0），靠变异才发现没测到真东西
- 等 Rounds 不等于历史已入账（rtRunOnce 先 round++ 后 rtAppendHistory），
与 dff745c 同一个坑；已改为等 history 条数
|
2026-10-30 21:54:40 +08:00 |
|
|
|
bcf45498a0
|
feat(skill): 补 kernel-rtchild + 两条判据锁住 rt_children 静默失败
## kernel-rtchild skill
`resident_agents` 有 `resident-subagent-hygiene` skill，而
`rt_children`/`rt_transcript` 这一对整个**没有 skill** —— 模型只能靠
工具描述猜语义。
最容易踩的坑：**工具执行期不可打断**。模型一旦进入工具执行期就听不见
新输入，所以调工具前必须先用 outputch 说一句"稍等"，否则用户会觉得
"它没在听我说话"，而实际上它只是卡在一个 3 秒的命令里。
skill 覆盖：三种子 agent 的分界、通道必须成对且两侧声明 rt、打断语义、
只出文本（TTS 是插件的活）、窗口裁剪但原文保留、回收后用 rt_transcript
分段取、闲置零 token 但必须 stop、四条回收判据、五种常见错误对照表。
## 两条判据（都来自一次真实事故）
生产 e2e 时我用 `input="..."`（工具声明的是 `inputch`）创建 rtchild：
`strArg` 只查精确键名 ⇒ 读到空串 ⇒ **本应报"必须成对给出"，但它成功了**，
还把 output 通道划给了新子。之后灌语音，该子轮次永远是 0。
症状是"通道注册了、插件活着、推送 ok、但子没反应"，
与真因（参数名拼错）隔了三层。
- `WrongParamNameIsRejectedNotSilent`：写错必须失败、必须指名正确参数名、
必须无副作用（不建子、不动通道归属）
- `PairAssignmentIsAtomic`：成对分配第二个失败时第一个必须回滚
（原来那句 `rollback()` 没有判据覆盖，是死代码）
变异验证：让代码对 `input`/`output` 静默兜底 ⇒ 第一条变红
（`参数名写错却创建成功了：[typo-child] —— 这会得到一个收不到输入的哑子`）。
go build/vet/gofmt 干净；go test ./... -count=1 -race = 62 ok / 0 FAIL / 0 RACE
|
2026-10-30 18:09:50 +08:00 |
|
|
|
dff745cde2
|
test(rtchild): rt_children stop 判据改为等历史入账，不等 Rounds
判据偶发红（实测约 1/12）：`stop 没有告诉模型用 rt_transcript 取回原文`。
根因是**判据自己等早了**，不是产品缺陷：
- `Rounds` 在 ChatStream 被调用时就自增（请求刚构建完）
- assistant 那条消息是**流结束后**才追加进 history 的
于是 stop 可能读到 n==0，走"本次通话没有上下文需要交接"分支 ——
而那个分支**本来就该**不提 rt_transcript（真没内容可取）。
改为等 RTTranscript 非空。
★ 这是同一类坑的第二次复发（第一次在 rtchild_r7b_test）：
判据等"请求已发出"而不是"结果已落库"。
"""
|
2026-10-30 17:21:51 +08:00 |
|
|
|
eb1deab5dd
|
feat(agent): rtchild 实时子 agent + 四类 agent 独立模型源 + 残余任务四态
## rtchild（R1–R13）
第三种、**独立**的子 agent 类型，面向语音/视频通话：内核只要文本流，
不定音频（TTS/播放由插件负责）。
- R1 CapRT 能力位 + AgentConfig.IsRealtime；AssignRealtime 两侧校验
- R2 rtSlot 单槽覆盖（latest-wins，从不排队）
- R3 独立 ctx + rtLoop + SpawnRTChild/StopRTChild
- R4 ChatStream 逐块 → outputch(rt).Execute(text)
- R5 打断 = 原地截断，不重试
- R6 工具执行期不可打断（suppressedCancels 让守卫可观测）
- R7 普通上下文 + 窗口裁剪（旧内容不进模型，**原文保留**）
- R9 CloseRTChild → L4 信号 + rt_transcript 按需分页取
- R10 notify_parent（L4，注册一次，停即注销）
- R11 闲置零 token
- R13 rt_children 管理工具（父专属）
刻意**不做** rtPage/anchor/degraded_resets（过设计，已裁定）；
不用四级中断阶梯（preemptCooldown+同级不抢占会让 ~75% 的 rt 打断
静默退化为排队）。
## 四类 agent 各自可配模型源
core.agent.llm.{main,resident,rt,child}_provider，语义是**优先不是独占**：
该源排到候选链最前，其余源仍作回退。硬锁定会让"首选源抖一下"变成
"这个 agent 彻底不工作"，而多源回退链正是本仓为此建立的机制。
名字写错 ⇒ 回退默认源 + 记日志（不静默）。子 agent 未配置时继承父的。
★ 顺带修掉一个真缺陷：spawn.go 原来直接 a.provider.Chat()，
**普通子 agent 完全绕过 provider 回退链** —— 它是唯一绕过的地方：
默认源抖一次整条子任务就"执行失败"，而主 agent 同刻能自动换源。
## 驻留子残余任务四态 + 通道三态
残余任务：keep / takeover（接手，keep 的明确别名）/ stash（暂存到各自
原通道）/ drop。stash 必须**逐条按各自 OutputChannel 归位** —— 一个子
可能同时收 qq 和 webui，混存会让"接回 qq 的人"拿到本该给 webui 的活。
通道：release（零值，向后兼容）/ suspend（挂起，暂存保留）/ takeover
（接回父并立即释放暂存）。原来是无条件 release，于是只有两种坏结局：
通道一直没人分配（消息无人处理且无提示），或刚好被别的 agent 抢到。
一次定完不留窗口：FinishResidentWith → DestroyResidentWith →
teardownResidentWith。任一环退回不带 disp 的旧函数，disp 就被丢掉、
通道被无条件释放 —— 而 stash 的暂存正挂在那条通道上（实际踩过）。
## 修复"手写字段白名单"丢值（7 处）
同一类缺陷：不传整个结构体，而是手写一份"允许通过的字段清单"。
危险在于**写漏了不报错** —— 字段静默归零，故障出现在很远的地方。
- corehandler.go outputRegister: ChannelDef{NoMemory,Cleaner} → 整体传
- pubSdkInjectOpts: 逐字段摊平丢 ScenePolicy/SecurityProfile → 收整个 injectParams
- injectParams/injectMediaParams: 结构本身缺字段 → 补齐 + asInjectParams()
- 配套反射判据 TestSegment_RoundTripEveryField（取代手写断言，
原判据漏了 Phase/LLMText/FinalText/ToolCalls/ExtraKeyMediaBlocks/ExtraBag）
## 压缩偏离设计
CompressResident 原为截断，与设计（LLM 摘要替换）不符。改走
PlanCompaction → summarizeForCompaction（用子自己的 provider）→
ApplyCompaction，失败回退 TrimKeepRecent。顺带修 ApplyCompaction 的
锁重入 panic 与双重解锁。
并修一处真实生产数据竞争：ctxFullSignaled 由父 goroutine 写、
子调度 goroutine 读，加 ctxFullMu。
## 判据
新增约 70 条。全部验证过能变红（变异测试），包括：
- TestSegment_RoundTripEveryField 的防腐蚀：fullStageContext 反射断言
每个字段非零，否则新字段永远不会被覆盖（"假绿"）
- TestPreferredProvider_PutsSourceFirstAndKeepsFallbacks 成对断言
"在首位且回退仍在"—— 只断言前者的话，硬锁定也会绿
## 判据自身的坑（两次偶发红，都不是产品缺陷）
1. SpawnResident 末尾 Start()，子会在两次 enqueue 之间取走一条
→ "暂存 0 条"。修法：cancel + waitSchedulerStopped。
（offload_test.go 早有记录，我没先读就重踩了一遍）
2. TaskPrompt 异步投递，可能在清空队列之后才到 → "多 1 条"。
靠探针打印内容才认出是 TaskPrompt。修法：本文件用 spawnQuietResident。
go build/vet/gofmt 干净；go test ./... -count=1 -race = 62 包 ok / 0 FAIL / 0 RACE
|
2026-10-30 17:00:47 +08:00 |
|
|
|
b850feaef2
|
feat: 段页式记忆流转、coldcontext 重命名与安全治理
记忆层：
- MemoryBlock 承载 FrameTS/PageSeq/PageKind/BlockRole/CallID
- coldcontext 归档与回填按完整页传递，工具调用参数和配对键不丢失
- 召回先估算总 token，超预算时按全局页相似度标记 inactive
- inactive 仅是 context 渲染期状态，不落盘、不进入 coldcontext，Prune 后重置
- Peek/确认/Remove 两阶段召回，失败保留冷上下文副本
- stablemem 记录 last_recalled_at，删块连带清理边
命名：
- internal/memory/document → internal/memory/coldcontext
- Doc/DocEvent/DocHit → ColdDoc/ColdEvent/ColdHit
- ContextToColdContext/RecentColdContexts/FindColdContexts
- 保留既有 JSON 标签、doc_ 文件前缀与 doc_count 状态键，兼容存量数据
安全治理：
- 工具策略门禁、安全配置、事件总线发布者身份与入站脱敏
- 声明式 SecurityAPI 与 QQ owner/guest profile
- 日志保留策略与相关 e2e/回归判据
验证：go build ./...、go vet ./...、go test ./...（62 包）；
生产副本 e2e：7013 块迁移后 ID/向量/指纹 0 变化、0 缺失。
|
2026-10-29 23:53:48 +08:00 |
|
|
|
ba281a855a
|
feat(update): 差分 OTA + 安装形态分派 + 事件总线统一受安全监控
三条主线，由 e2e 实测驱动。
## 一、差分 OTA（internal/update/delta.go）
实测：改一行逻辑，88MB 的二进制逐字节只差 80 字节，而 OTA 一直下整包。
用 rsync 族的滚动哈希块匹配（4KB 粒度），不是 bsdiff —— 后者需 17×N
峰值内存（88MB → 1.5GB），而升级恰可能发生在内存紧张时。
真实二进制实测：88,036,728 字节 → 补丁 77,316 字节（0.088%）。
三道闸：应用前验旧文件 sha256（错基线会静默产出垃圾）、应用后验结果
sha256、COPY/LITERAL 越界防护。任何失败**退回整包**，不向上抛 ——
差分是优化，不是可用性前提。
接入：Source.Resolve 优先试 delta；CheckRelease 按 -from-<commit8>.delta
匹配（不猜基线）；CLI 新增 -make-delta；打包脚本 build_delta（需
PREVIOUS_HOMED），delta 进 SHA256SUMS。
## 二、安装形态分派（internal/update/install.go + channel.go）
内核对「能不能自己升级」此前只有一个答案：直接替换二进制。而 deb/rpm
形态下那样做会让 dpkg/rpm 数据库与实际内容不一致（下次 apt upgrade
覆盖回旧版，或 dpkg 拒绝后续升级）。
新增探测：deb/rpm/tar/container/source 五类形态 + 变体（full/server/
client/toolchain）+ 目录写权限。判据全部来自可观测系统事实（dpkg 的
info 目录、容器标记文件），不做路径推断。
三端统一走 PlanUpgrade 分派；形态闸门放在**下载 880MB 之前**。
## 三、事件总线统一受安全监控（internal/events + security）
用户指正：「eventbus 上所有事件都要接受安全模块的监控」。
此前 EventPolicy 只被 internal/sdk/events.go 调用，而那是四条路径中的
一条。s.Publish / s.Subscribe / s.EventBus() 拿的是裸 *events.Bus，
任何插件都能绕过策略发任意事件（含伪造内核事件）。
现在闸门在 Bus.Publish/Subscribe 本体上（Guard 接口注入，避免 events
↔ security 成环），四条路径全部覆盖。sdk.EventBus() 改返回带身份的
BusHandle。内核身份免授权，但载荷照样过凭据闸门。
白名单按主体收窄：agent_output/stage/terminal_output 只允许承载者
（webui/cli/agentcli）发布 —— 它们是内核向外的输出面，谁都能发就等于
能伪造 agent 说的话。
## e2e 暴露并修掉的三个真实回归
[bus] subscribe denied: pluginmgr type=update_request
[bus] subscribe denied: skillmgr type=skill_detected
前两个让升级请求静默丢失、职责链交接断掉。内部协作事件必须可订阅
（安全边界在发布侧，订阅只是「听得到」）。
## 顺带的止血修复
- 回滚判据从 `--version` 改为 digest：旧内核（1.3.x 及以前）没有该
flag，而它恰是最常见的回滚目标 —— 原逻辑让「从旧版升级失败」永久
无法回滚。
- CopyFile 补 fsync（替换 homed 本体时掉电会留半截文件）。
- restore 完整还原才清 marker（原先先清再还原，还原失败就失去第二次
自愈机会）。
- 回滚时移除升级中新增的 depgraph（否则「旧 homed + 新 depgraph」
会因 digest 不匹配崩溃循环）。
- homed-upgrade 不再硬编码 systemctl restart（丢 guard 状态、unit 名
漂移）；改用内核已有的 restartCh → exit 42 语义。
- homed-upgrade 不再用 CGO_ENABLED=0 编却依赖 go-sqlite3（stub 下
静默失效，该路径从未工作过）；改用 internal/config。
- 服务单元补 User=hologramagent + 三条安装路径补建用户（此前发行物里
完全没有落实降权）。
- rpm 的 fpm 调用补 --after-install（此前 rpm 装完根本不建用户）。
## 判据
新增 30 条：差分 8（往返/压缩比/错基线/截断/篡改/边界）、通道 8、
执行器 6、事件闸门 8、按主体授权 8。全仓 go test ./... 0 失败。
|
2026-10-29 09:54:55 +08:00 |
|
|
|
86d1f4c547
|
test(update): 补 TestMarkPendingUpgrade_PreservesOldMarkerOnFailure（判据 B2c）
## 为什么还要再加一条
前两条 commit 之后，B2 的「原子写」在判据侧其实是哑的 —— 我复核时实测
过：把 MarkPendingUpgrade 的 `tmp := p + ".tmp"` 改成 `tmp := p`
（退回最初的原地覆写 bug），以及把整个函数退回 os.WriteFile，
`TestMarkPendingUpgrade_IsAtomic` **都照样绿**。
因为它断言的是「最终状态对」：不留 .tmp 残留、内容可解析、可覆写。
os.WriteFile 这三条全都满足。也就是说那条用例证明的是「结果正确」，
没证明「写的过程不会毁掉已有数据」—— 而后者才是 B2 要防的事故。
## 这条用例钉什么
用它逼出两者唯一可观测的差异：**失败路径上旧文件还在不在**。
① 先写一个完好的旧 marker（FromVer=1.0.0）
② 把 pendingPath+".tmp" 占成**目录** ⇒ OpenFile 必 EISDIR
（稳定可复现，不依赖权限/磁盘/平台；失败点与「磁盘满/掉电」同类：
已打开目标、还没写完全部内容）
③ MarkPendingUpgrade 必须返回 error（不能假装标记已就绪）
④ 旧 marker 必须原样保留：FromVer 仍为 1.0.0、ToVer 仍为 1.1.0
③④ 都用 Error 而非 Fatal：让两个症状一起报出来。
## 语义差异
原子写（现状）：新内容写进 .tmp 时失败 ⇒ 目标文件仍是完整旧版本
原地覆写 ：O_TRUNC 先清空再写，中途失败 ⇒ 目标文件被截断，
旧 marker 永久丢失 ⇒ 不知道上次升了什么，也没了回滚依据
## 变异（已实测）
B2c-M1 rollback.go `tmp := p + ".tmp"` → `tmp := p` ⇒ RED
实际输出：旧 marker 被破坏了：FromVer 应为 1.0.0，实际 "2.0.0"
零用例假绿也堵住了：判据脚本对 `no tests to run` 直接 FATAL。
仅动 internal/update/kernel_apply_test.go（测试文件），生产代码零改动。
|
2026-10-28 17:56:44 +08:00 |
|
|
|
1319d6619c
|
fix(update): dataDir 取内核权威源 + 回滚可信校验 + marker 原子写
承上一个 commit（回退 85fd38b）。本 commit 是 R2 主体：B0/B1/B2 三项修复，
以及为 P1–P4 补齐的**行为级**判据。
━━━ B0 · dataDir 不再推导，取内核真实 -data ━━━
`internal/update/kernel.go`
· 删除 ResolveDataDir（env → `<exe>/data` 兜底）。
· 新增 SetKernelDataDir / KernelDataDir：值由内核适配层在启动时
用 ks.DataDir 注入。进程内调用方（pluginmgr / webui）直接取，
不做任何推导；取不到返回**空串**。
· DataDirEnv 保留但降级为诊断参考（不再是合法来源）。
`internal/kernelmod/update/mod.go`
· Init 里 upd.SetKernelDataDir(ks.DataDir)；为空时打响亮告警
（不阻断启动 —— 第 0 层职责是回滚判定，不是参数校验）。
`internal/plugins/pluginmgr/kernel_update.go`、`internal/plugins/webui/kernel_update.go`
· kernelDataDir / dataDirOf 都改为 return update.KernelDataDir()。
`cmd/homed-upgrade/main.go`
· upgradeDataDir(explicit)：① `-data <dir>`；② config.db 的
core.daemon.data_dir（只读连接 + PRAGMA query_only=1，不建表不迁移）。
· 两者都拿不到 ⇒ 返回空串 ⇒ `-apply` 在动手之前就 fail 并说明怎么修。
→ 这样 P1 的空值守卫重新变成**活的**：拿不到真实 dataDir 就真的会拦。
━━━ B1 · 回滚可信：回读校验是唯一判据（判据 B1）━━━
`internal/update/rollback.go` — RollbackIfUnconfirmed
· rollback.go:315 `rb, verr := readBinVersionStrict(binPath)`
替换后**必须**回读成功且 rb.Version == rec.FromVer，否则
rolled=false + error + **不清 marker**（下次启动再试，并让人看到日志）。
CopyFile 返回 nil 只代表字节搬完了，不代表搬过去的东西能执行。
· rollback.go:254 确认分支同样改用 readBinVersionStrict。
这里曾经用 ReadBinVersion —— 它含 InferVersionFromRunning 回退，
已实测：binPath 是不可执行残文件、marker.ToVer 恰好等于本机 waiter
版本时，会从 waiter **借到**版本号 ⇒ confirmed=true ⇒ 清 marker、
不回滚 ⇒ 机器带着跑不起来的二进制继续启动且失去自愈机会。
该缺陷环境相关（CI 没装 homed/waiter 会绿），故判据不能依赖本机环境。
· 备份缺失 / 回读失败 / 版本不符 / depgraph 回滚失败 —— 四种情形
一律不清 marker。
· 新增 readBinVersionStrict（kernel.go）：只认「这个文件自己能报出版本」，
无任何回退；ReadBinVersion 改为其包装器（保留探测用回退），
注释写明它**不能**用作回滚校验。
━━━ B2 · marker 原子 + 损坏不卡启动（判据 B2）━━━
`internal/update/rollback.go` — MarkPendingUpgrade
· 旧实现 os.WriteFile 直接覆写（O_TRUNC），掉电留半截 JSON。
· 现改为：写 <path>.tmp → fsync(文件) → rename(原子) → fsync(目录)。
目录 fsync 失败仅告警（容器/tmpfs 下 EINVAL 不该阻断升级）。
rollback.go:112 `if err := f.Sync(); err != nil {` 即这条链路的第一道闸。
· RollbackIfUnconfirmed 遇到解析不了的 marker：quarantineMarker 改名
留存（不删，保留现场）+ 告警 + return false,"","",nil
⇒ 当作「无待确认升级」继续启动。把内核卡在启动阶段是最差选择：
能执行到这行已证明当前二进制可执行。
`internal/kernelmod/update/mod.go`
· 补注释钉住语义：rerr != nil 必须中止启动；但 marker **损坏**不算
失败（已由 RollbackIfUnconfirmed 吞掉并改名留存）。
━━━ 判据补齐（行为级，修掉 M6 真空洞）━━━
`internal/update/kernel_apply_test.go`
· P1 TestApplyRefusesEmptyDataDir 加强：切到 t.TempDir() 并拍快照，
断言拒绝升级时**根本没写任何文件**（旧用例只查「目标二进制没变」，
把守卫挪到预检之后依旧绿 —— 因为 filepath.Join("", prefix) 会把
备份目录建到 CWD）。
· P3 新增 TestApplyPrunesOldBackups：预置 5 个历史备份后跑真实 Apply，
断言旧的被 GC。★ 这是补 M6 的真空洞 —— 旧的变异脚本只跑
`-run TestPruneOldBackups`（只证明函数能跑，3 毫秒），把 Apply 里
那一行 PruneOldBackups(dataDir) 删掉它照样绿；新脚本必须同时跑
TestApplyPrunesOldBackups，删掉调用后立刻报红。
「函数能跑」≠「Apply 真的调了它」。
· B1 新增 TestRollback_RefusesCorruptBackup（零字节/坏备份 ⇒ 必须
回滚失败且不清 marker）、TestRollback_RefusesVersionMismatch
（备份版本 ≠ FromVer ⇒ 同样失败）、
TestRollback_ConfirmedBranchIgnoresInferredVersion 与
TestConfirmedBranch_StrictProbeBitesOnUnparseable（确认分支不得
使用推断值；用可注入的 inferHomedPath/inferWaiterPath 造出
「能借到版本」的场景，不依赖本机是否装了 homed/waiter）。
· B2 新增 TestMarkPendingUpgrade_IsAtomic、
TestRollback_CorruptMarkerDoesNotBlockBoot。
`internal/update/rollback_test.go`
· TestRollback_RestoresBackup / TestRollback_RollsBackWhenRunningOldVersion
的备份从纯字节 "OLD-GOOD" 改为**真正可执行**的假二进制（1.4.0），
并按版本而非按字节断言。旧的写法只能测「字节搬对了」，测不到
「搬过去的东西能跑」—— 而后者才是回滚能救机器的前提。
`internal/update/kernel.go`
· inferHomedPath / inferWaiterPath 提为包级变量（生产默认值不变），
唯一目的是让「确认分支不得使用推断值」这条判据可稳定复现。
━━━ 判据锚点自检（grep -F 命中数均为 1，行号已核对）━━━
P1 kernel.go:348 if dataDir == "" {
P2 kernel.go:370 backup := filepath.Join(dataDir, BackupDirPrefix+ts)
P3 kernel.go:449 PruneOldBackups(dataDir)
P4 kernel.go:445 publishResult(bus, "kernel", "", true, …)
P4 events.go:69 "error": errMsg,
B1 rollback.go:254 if cur, cerr := readBinVersionStrict(binPath); cerr == nil {
B1 rollback.go:315 rb, verr := readBinVersionStrict(binPath)
B2 rollback.go:112 if err := f.Sync(); err != nil {
验证：go build ./... 通过；go test ./internal/update/ 通过。
|
2026-10-28 17:51:52 +08:00 |
|
|
|
a8ecb8257c
|
revert: 回退 85fd38b（ResolveDataDir 从 exe 猜 dataDir，生产必挂）
This reverts commit 85fd38b7d1.
## 为什么回退
85fd38b 把三端 dataDir 推导统一成 update.ResolveDataDir(exePath)：
`HOMEAGENT_DATA_DIR` → `<exe 所在目录>/data` 兜底。方向（三端必须算出
同一个值）是对的，但**兜底那一项在生产上是错的**：
ExecStart=/usr/bin/homed --role=guard --data /var/lib/hologram
ResolveDataDir("/usr/bin/homed") == "/usr/bin/data" ← 与真实值不符
`HOMEAGENT_DATA_DIR` 在现有部署里并没有设置，所以实际生效的就是这个兜底。
后果两个，都是致命的：
① Apply 第一步要在 dataDir 下建备份目录，而 /usr/bin 在
ProtectSystem=strict 下只读 ⇒ EROFS ⇒ 升级必挂
② pending 标记落到内核读不到的位置 ⇒ 升级启动失败后静默不回滚
## 附带问题：空值守卫变成死代码
ecde8dd 的 H1（P1）加的是「dataDir 为空就拒绝升级」。85fd38b 的
ResolveDataDir 兜底**永不为空**（exePath 为空时还会自己去取
KernelBinaryPath），于是三个调用点传进来的 dataDir 恒非空 ——
守卫还在，但守的是一个永远非空的常量，实际不会再拦任何东西。
「不知道」伪装成「知道」比没有守卫更危险：守卫看起来在守，出事时才发现
它从来没生效。所以判据 P1 在 85fd38b 之上是咬不住的。
## 回退范围
只回退 85fd38b 的三个文件（CLI / pluginmgr / webui 的推导逻辑），
回到 ecde8dd 的状态；不影响 ecde8dd 本身。回退后：
· ResolveDataDir 及其所有调用点消失，无悬空引用
· go build ./... 通过
· 三端暂时回到「各端自己推导」——这正是紧随其后的下一个 commit
要替换掉的形态（改为取内核权威源，不做任何推导）
回退 + 后续修复合起来才完整：单看本 commit，dataDir 解析又散回三处；
下一个 commit 用「注入内核真实 -data」取代全部推导。
|
2026-10-28 17:51:16 +08:00 |
|
|
|
85fd38b7d1
|
fix(update): 统一 dataDir 推导，三端共用 update.ResolveDataDir
范围说明：本 commit 与 H1 属同一缺陷的另一面。Apply 现在会拒绝空
dataDir，而三端各自的推导逻辑此前会**真的返回空**（或写死生产路径），
不一起改则 H1 会把所有升级都拒掉、或让 pending 落到内核读不到的地方。
三处原来的推导：
· cmd/homed-upgrade/main.go env → 写死 /home/newqqagent
· pluginmgr/kernel_update.go env → Dir(pluginDir)
· webui/kernel_update.go env → 空（由调用方报错）
问题：① 硬编码 /home/newqqagent 在目录/用户迁移后指向不存在的路径；
② 从 pluginDir 反推与 webui 侧不一致，同一台机器两条升级通道算出
两个 dataDir ⇒ 标记落在 A、第 0 层 update 从 B 读 ⇒ 升级启动
失败时静默不回滚（症状是崩溃循环，极难反查到标记）。
现在三端统一调用 update.ResolveDataDir(exePath)：
① HOMEAGENT_DATA_DIR（部署方显式声明，唯一可靠来源）
② <exe 所在目录>/data 兜底（替代原先的硬编码生产路径）
并删掉 cmd/homed-upgrade 里写死的 /home/newqqagent。
本 commit 可单独回退：回退后仅剩「各端自己推导」，与 H1 组合会退化为
「空 dataDir 一律拒绝升级」（安全侧失败，不会产生无回滚能力的升级）。
|
2026-10-28 17:20:40 +08:00 |
|
|
|
ecde8dd515
|
fix(update): 补上内核升级缺失的四道安全闸（H1–H4）
四条缺陷的共同点都是「静默产出一个看起来成功的升级」，而失败的表现
是机器进崩溃循环且没人知道原因。
H1 dataDir 为空必须拒绝升级
Apply 此前只在 dataDir 非空时写 pending，空值仅跳过标记、后照常替换
二进制 ⇒ 产出「无回滚能力」的升级。现改为在动任何文件之前直接失败。
另新增导出 update.ResolveDataDir（env → <exe>/data 兜底）。
H2 备份目录不能写 /root
backup 原为 /root/homed-upgrade-backup-<ts>，服务在 ProtectSystem=strict
+ ReadWritePaths=/var/lib/hologram 下运行，非 root 对 /root 无写权限
⇒ MkdirAll 必 EACCES ⇒ 首次升级必挂。改为落在 dataDir 下。
rollback 的 homed-broken-<ts> 同样从（通常只读的）二进制目录挪到 dataDir。
H3 备份目录要有 GC
旧注释写「确认稳定后可删」，但全仓无任何删除逻辑。新增
PruneOldBackups：保留最近 3 个 homed-upgrade-backup-* 与最近 1 个
homed-broken-*，其余 RemoveAll，在 Apply 成功返回前调用。
只处理名字精确为「前缀 + NowStamp 形态」的目录，不误删 pending 标记
或前缀相近的第三方目录。
H4 结果事件吞错误 + 成功不发 result
publishResult 里 `if errMsg != "" { _ = errMsg }` 把失败原因丢弃，payload
也没有 error 字段 ⇒ 订阅方只看到 ok=false。现在 error 字段恒定存在。
Apply 成功路径此前从不发 result，现补发 ok=true。
测试：kernel_apply_test.go 新增 5 个用例（含题目要求的四个函数名）。
|
2026-10-28 17:20:35 +08:00 |
|
|
|
7f68d2b1bf
|
test(proc): 流式发布耗时判据改为 race 感知阈值
CI 红（run 40473247694，Race detector job）：
--- FAIL: TestStreaming_PublishLatencyFlatAcrossSubscribers
1 个消费者：8.81662ms（均摊 2.938µs/次）
8 个消费者：36.407338ms（均摊 12.135µs/次）→ >4 倍判据
与该次提交的内容无关（改动都在 agent/core、memory、qq 插件级别与
scheduler 日志），是"按耗时比值"的判据在共享 runner + -race 下抖动。
改法（不削弱拦截能力）：
- 常规构建阈值 4 倍（本机实测 1.1~1.5 倍）；
- -race 构建阈值 6 倍（影子内存检查放大常数因子）；
- 两者都低于 O(N) 广播的 8 倍量级，真出现线性恶化仍会被抓。
新增 race_off.go / race_on.go 提供 raceEnabled 常量（build tag 判定），
而不是用环境变量或时间门槛（后者要么本机永远跳过、要么 CI 永远误报）。
刻意**没有**改成"重复测量取最小值"：实测会让本用例成本 ×3，-race 下
撞 600s 超时（试过，已撤回）。
|
2026-10-27 17:49:05 +08:00 |
|
|
|
0f98f36e71
|
fix(memory): L1 恢复为"工作记忆区 = 时序对话"，工具结果展开、仅超长折叠
用户裁定的 L1 契约（2026-10-27）：
· 保留 m 条（core.agent.max_context_size）、保护最新 n 条
（core.agent.context.protected_count）、其余按相似度淘汰 → 我的上一版把
m 写到了不存在的键（core.agent.context.max_context_size），运行时仍读
core.agent.max_context_size=200 ⇒ L1 堆到 119 条，工作记忆退化成历史堆。
· 送给模型的是**时序排列的对话** → 曾被渲染成"摘要 + 工具管道"
（"—/ → 调用工具: a, b → 已回复…"，助手回复还截 120 字），
指代消解因此失效（用户回"新乡"，接不上"帮我找一套月租＜400…"）。
· 工具结果在 context 中**展开全文**，只有**超长**结果折叠成句柄
（toolresult_store + toolresult_read 按区间读回）→ 曾额外加 160/400 字、
每事件 3 条的截断，等于把已展开的结果又藏回去。
本次改动（仅渲染层，不动淘汰/归档/中断语义）：
· formatMergedTimeline 渲染 [ts] 用户: … / [ts] 助手: …（回复全文）
· 中断轮的"用户原话"取自 qq_get_message/qq_get_history 的回执正文
（Input 是注入样板，不是人话）
· timelineToolLines：普通结果全文展开；ToolResultStores 命中的只给句柄
· 预算估算按实际渲染内容计（用户行 + 助手全文 + 工具行）
判据：internal/agent/core/timeline_contract_test.go
（时序对话/原话来源/全文展开/仅超长折叠）
|
2026-10-27 16:24:09 +08:00 |
|
|
|
279b61198c
|
fix(scheduler): 空闲时入队不再误报 "level insufficient"
现场：日志满屏
[agent] interrupt queued: task#2 class=interrupt level=3 from qq (L3)
vs <nil> (?) — level insufficient
而实际成因是"当前没有运行任务可抢占"，与级别毫无关系。这类假因会
把运维引到"是不是级别配低了"的错误方向（本仓反复吃亏的静默/误导同族）。
改成四种成因分开写：
idle (no running task; queued for next pick) / running in critical section
/ preempt cooldown / level insufficient
|
2026-10-27 15:58:55 +08:00 |
|
|
|
9ffdebbb0b
|
fix(agent): 续写占位不再把「承诺后没做的事」一并劝退
现场（用户原话："那你去啊？说完就停了"）：模型经 output_send__qq 说了一句
"我这就去办"，内核判定本批全是输出通道发送（ReplyOnly）后补的占位只有终止许可
——"若你的回复已完成，直接返回纯文本即可结束本轮，无需再调用任何工具"——
模型照做返回纯文本，本轮结束，活没干。
但这条护栏不能简单删掉：注释里记着一次事故，通用「请继续」被读成
"再发一条消息"，生产实测单轮 34 次 output_send__qq、持续 514 秒。
改法：把两种授权分开说清楚，护栏不削弱。
- 没做完的操作 → 现在继续做完（继续指**非发送类**工具）
- 真的做完了 → 返回纯文本收尾，并明确「不要再发第二条消息」
判据：continuation_placeholder_test.go（必须同时含"继续做完"与
"不要再发第二条消息"；不得再出现"无需再调用任何工具"）
|
2026-10-27 15:53:49 +08:00 |
|
|
|
20cf138d3b
|
fix(memory): 把插件的 NoMemory 声明落到事件上
声明链此前断在最后一步：
InjectOptions.NoMemory / ChannelDef.NoMemory
→ payload["no_memory"] → stageCtx.NoMemory ✅ 已合成
→ ContextEvent.NoMemory ❌ 从未赋值
后果：QQ 那句取件样板（"来自「X」的私聊消息(message_id=…) 先用
qq_get_message 取正文…"）每轮都进计算层（向量化/关键词/蒸馏），
而它是指令不是内容 —— 真实对话内容在记忆里被它挤薄。
按字段**既有契约**处置（context.go 的注释写明）：只影响计算层，
归档照常。理由是同一条注释里的 2026-10-22 教训 —— coldcontext_query
的 Consume 已从 L2 删除原文，回填事件必须能落回 L2，否则三层全无。
判据：nomemory_flag_test.go
（NoMemory 事件 textForVector 为空但 Input/Response 保留；普通事件不受影响）
|
2026-10-27 15:40:43 +08:00 |
|
|
|
14daf5b584
|
fix(memory): 超长工具结果在时间线里只渲染句柄（不渲染正文）
用户口径（2026-10-27）：渲染工具回执，但**超长的才不渲染** —— 那些结果
已经落盘进工具环（toolresult_store），时间线里只应给「有多少、怎么读」，
正文由 toolresult_read(event_id, offset, limit) 按需取。
为什么不能渲染它的预览：预览是多行文本，塞进历史只会压成"半截结果"，
信息量还不如一个句柄；而模型真正需要的是"知道有这份东西、从哪儿读"。
判据：TestTimelineOversizedResultRendersHandleOnly
（落盘结果不出现预览正文、必须含 toolresult_read 与 event_id；未落盘回执照旧渲染）
|
2026-10-27 15:27:35 +08:00 |
|
|
|
5deb3eb10d
|
Revert "fix(memory): 中断的取件样板不再写入 L1（颗粒度=单条消息）"
This reverts commit 3a7440a2fe.
|
2026-10-27 15:04:55 +08:00 |
|
|
|
3a7440a2fe
|
fix(memory): 中断的取件样板不再写入 L1（颗粒度=单条消息）
用户口径（反复强调）：进记忆的禁忌是**中断消息本身**，不是整轮。
此前 finishInputTask 无条件把 CleanInput 写进事件，而中断轮的 CleanInput 是
"来自「X」的私聊消息(message_id=…) 先用 qq_get_message 取正文…" 这类样板：
每轮一字不差堆进 L1，真实对话内容只能靠工具回执碎片体现 ——
实测用户回一句 "233719"，模型反问"那串数字什么意思"（指代消解失效）。
改法：只清样板，不清内容。
- isInjectionBoilerplate 识别插件取件指令（"来自「…」…message_id=" 或 "先用…取正文"），
命中则 Input 置空；
- 本轮的工具回执（qq_get_message 正文，NoMemory=false）、agent 回复照常入库；
- 内核中断正文不清空：测试 D1=B 要求「中断任务的上下文加载回被抢占任务之上」。
判据：internal/agent/core/interrupt_input_memory_test.go（样板被清、内核中断保留、
普通输入不受影响、回执与回复保留）
|
2026-10-27 15:02:57 +08:00 |
|
|
|
b2938ed4a7
|
fix(memory): 场景召回按块向量余弦排序 + 召回 query 可见性 + 对话回执放宽
① 场景召回是每轮常驻注入，此前按「场景权重→时间倒序」排，与 query 无关：
老图库的 rt/rtchild/inputch 等历史事实常年霸榜，实测 1833 字符里九成是它们，
刚聊的群聊内容一句没有 —— 这就是"忘事"的机制。
块里本来就存着向量，相关性就是一次余弦比较：RecallByScene 带出端点/原句块
向量，Indexer 按 max(cos) 排序并设 0.20 下限，取前 8。
无稠密空间时保持原顺序（不能用字面匹配冒充语义 —— 既有判据要求
「措辞与记忆零字面重合时场景路必须兜住」）。
② recall query 可见性：cleaner 缺失/生效/回空三种情况都打日志。此前静默回退
原文，"召回 query 其实是工具原始回执"这件事在日志里完全看不到。
实测 qq_get_message: 199 -> 27 bytes（cleaner 生效）。
③ 对话正文类工具（get_message/get_history/list_chats）时间线渲染放宽到 400 字
（160 字会把群聊上下文切成碎片）。
判据：internal/memory/scene_relevance_test.go
|
2026-10-27 13:25:25 +08:00 |
|
