mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-11-05 16:57:32 +00:00
## 起因(生产故障)
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 防腐判据(部分已随本次落地)
86 lines
3.4 KiB
Go
86 lines
3.4 KiB
Go
package memory
|
||
|
||
// 蒸馏器接线回归判据(从 cmd/homed/bootstrap_test.go 迁移而来)。
|
||
//
|
||
// ## 为什么这条判据必须存在(历史 bug)
|
||
//
|
||
// `main()` 拆分时,initMemoryStack 函数体内残留一句 `defer distiller.Stop()`,
|
||
// 函数一 return 就 cancel 掉刚启动的循环 ⇒ **规则蒸馏 10min 心跳从不运行**。
|
||
//
|
||
// ★ 该缺陷**不会让任何单测变红** —— pipeline 的 `TestDistillOnce*` 直接调
|
||
// `distillOnce`,**绕过了 Start/Stop 接线**。只有按「启动阶段函数」的真实
|
||
// 调用方式断言(调用 → 检查仍在跑 → 调 cleanup → 检查已停),才照得出来。
|
||
//
|
||
// ## 迁移说明
|
||
//
|
||
// 本判据原先针对 `cmd/homed` 的 `initMemoryStack`。模块化后该逻辑搬进
|
||
// `internal/kernelmod/memory.Module.Init`,所以判据跟着搬 —— 且**必须保留**:
|
||
// 迁移过程中"忘了 AddCloser"或"改成 defer"是同一类缺陷的新形态。
|
||
//
|
||
// 判据改为直接跑真实模块(经 kernelboot.Run),确保测的是**真实入口**。
|
||
|
||
import (
|
||
"github.com/JianFeeeee/HologramAgent/internal/kstate"
|
||
"os"
|
||
"path/filepath"
|
||
"testing"
|
||
|
||
internalConfig "github.com/JianFeeeee/HologramAgent/internal/config"
|
||
)
|
||
|
||
// ★★★ 判据:模块 Init 返回后蒸馏器**仍在运行**(无 defer Stop 残留)。
|
||
func TestMemoryModuleKeepsDistillerRunning(t *testing.T) {
|
||
dir := t.TempDir()
|
||
if err := os.MkdirAll(filepath.Join(dir, "memory"), 0o755); err != nil {
|
||
t.Fatal(err)
|
||
}
|
||
// ★ 需要真 cfgReg:memory 模块读 core.agent.embedding_model_path,
|
||
// 而它对 nil 会现在**明确报错**(而不是 panic 在 strings.Split)。
|
||
reg := internalConfig.NewConfigRegistry(filepath.Join(dir, "config.db"))
|
||
defer reg.Close()
|
||
ks := &kstate.State{DataDir: dir, CfgReg: reg}
|
||
|
||
if err := (Module{}).Init(ks); err != nil {
|
||
t.Fatalf("memory 模块 Init: %v", err)
|
||
}
|
||
if ks.Memory == nil || ks.Memory.Distiller == nil {
|
||
t.Fatal("memory 模块未产出蒸馏器")
|
||
}
|
||
if ks.Memory.DB == nil {
|
||
t.Skip("图库未初始化,无法验证蒸馏接线")
|
||
}
|
||
// ★ 关键断言:Init 已返回,蒸馏循环必须还在跑
|
||
if ks.Memory.Distiller.Stopped() {
|
||
t.Fatal("★ memory 模块 Init 返回后蒸馏循环已被停掉" +
|
||
"(defer Stop 残留?)—— 规则蒸馏 10min 心跳将从不运行")
|
||
}
|
||
|
||
// 关闭函数是唯一的停机点(经 AddCloser 登记,由 KernelState.CloseAll 逆序执行)
|
||
if err := ks.CloseAll(); err != nil {
|
||
t.Fatalf("CloseAll: %v", err)
|
||
}
|
||
if !ks.Memory.Distiller.Stopped() {
|
||
t.Fatal("CloseAll 之后蒸馏器应已停止(关闭函数未登记?)")
|
||
}
|
||
}
|
||
|
||
// ★★★ 判据:**关闭函数经 AddCloser 登记**(不是 defer)。
|
||
//
|
||
// 这是上一条的机制保证:若有人把 AddCloser 改回 defer,
|
||
// 上一条判据报红;本判据报"没登记",两条互相印证、定位更快。
|
||
func TestMemoryModuleRegistersCloser(t *testing.T) {
|
||
dir := t.TempDir()
|
||
os.MkdirAll(filepath.Join(dir, "memory"), 0o755)
|
||
reg := internalConfig.NewConfigRegistry(filepath.Join(dir, "config.db"))
|
||
defer reg.Close()
|
||
ks := &kstate.State{DataDir: dir, CfgReg: reg}
|
||
if err := (Module{}).Init(ks); err != nil {
|
||
t.Fatal(err)
|
||
}
|
||
// 内存模块应恰好登记 1 个关闭函数(停蒸馏器 + 关图库,合在一个闭包里)
|
||
if len(ks.Closers) != 1 {
|
||
t.Fatalf("★ 应登记 1 个关闭函数,实际 %d —— "+
|
||
"若为 0 说明改成了 defer(Init 返回即停机)", len(ks.Closers))
|
||
}
|
||
}
|