mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-11-05 16:57:32 +00:00
cc0eb51286
## 起因（生产故障）
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 防腐判据（部分已随本次落地）
80 lines
3.0 KiB
Go
80 lines
3.0 KiB
Go
package kernelboot
|
||
|
||
import "github.com/JianFeeeee/HologramAgent/internal/kstate"
|
||
|
||
// 把既有的内核 `init*` 函数**适配**成 Module，而不必重写它们的签名。
|
||
//
|
||
// ## 为什么不直接改 init* 的签名
|
||
//
|
||
// `init*` 函数是**既有代码**，各有不同签名（有的返回 1 个值、有的 2 个、
|
||
// 有的带 close 函数、有的只做副作用）。逐个改签名意味着：
|
||
// · 大面积改动（评审困难、易引入回归）
|
||
// · 且 `init*` 函数本身是清晰的（`initLuaVM(cfg) (*VM, func())`）——
|
||
// 为迁就调度器的接口而把它改丑，是**倒置的取舍**
|
||
//
|
||
// 所以本文件提供**适配层**：声明式地描述"这个模块的名字/依赖/产物/怎么调用"，
|
||
// `init*` 函数一行都不改。
|
||
//
|
||
// ## 设计：FuncModule
|
||
//
|
||
// ```go
|
||
// kernelboot.FuncModule(kernelboot.FuncSpec{
|
||
// Name: "lua",
|
||
// Requires: []string{"config"},
|
||
// Provides: []string{"lua"},
|
||
// Init: func(ks *kstate.State) error {
|
||
// vm, closeFn := initLuaVM(ks.Cfg) // 依赖的产物：直接读字段
|
||
// ks.LuaVM = vm // 自己的产物：写回字段
|
||
// ks.AddCloser(closeFn) // 关闭函数统一登记
|
||
// return nil
|
||
// },
|
||
// })
|
||
// ```
|
||
//
|
||
// ## 为什么"关闭函数"也要作为产物发布
|
||
//
|
||
// `init*` 常返回 `(value, func())`：value 要用，close 要在停机时调。
|
||
// 若适配器只发布 value，**close 就丢了** ⇒ 资源泄漏（实测有先例：
|
||
// tracker 的 overlay 挂载、memory stack 的关闭）。
|
||
//
|
||
// 把 close 也当产物（约定名 `<facility>.close`）的好处：
|
||
// 停机时统一遍历容器调用所有 close，**不依赖人记得在 main 末尾手写**。
|
||
// 这正好顺手解决了 main() 里那一堆 `defer closeMem()` 的散落问题。
|
||
|
||
// FuncSpec 描述一个由函数适配的模块。
|
||
type FuncSpec struct {
|
||
Name string
|
||
Requires []string
|
||
Provides []string
|
||
// Init 执行装配：从 ctx 取依赖、调既有函数、把产物 Put 回 ctx。
|
||
Init func(ks *kstate.State) error
|
||
}
|
||
|
||
// funcModule 是 FuncSpec 的 Module 实现。
|
||
type funcModule struct {
|
||
spec FuncSpec
|
||
}
|
||
|
||
func (m *funcModule) Name() string { return m.spec.Name }
|
||
func (m *funcModule) Provides() []string { return m.spec.Provides }
|
||
func (m *funcModule) Requires() []string { return m.spec.Requires }
|
||
func (m *funcModule) Init(ks *kstate.State) error {
|
||
if m.spec.Init == nil {
|
||
return nil
|
||
}
|
||
return m.spec.Init(ks)
|
||
}
|
||
|
||
// FuncModule 创建一个由函数适配的模块。
|
||
func FuncModule(spec FuncSpec) Module {
|
||
return &funcModule{spec: spec}
|
||
}
|
||
|
||
// --- 关闭函数的统一回收 ---
|
||
//
|
||
// 约定：模块在 Init 里用 ks.AddCloser(fn) 注册关闭函数。
|
||
// 停机时由 KernelState.CloseAll 按**注册顺序的逆序**执行（LIFO，与 defer 一致）。
|
||
//
|
||
// ★ 为何不再用"设施名以 .close 结尾"的约定：那个约定要靠字符串判断，
|
||
// 而结构体方案下直接 AddCloser 更直白（且不会因为设施改名而失效）。
|