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 防腐判据(部分已随本次落地)
112 lines
3.5 KiB
Go
112 lines
3.5 KiB
Go
package kernelboot
|
||
|
||
// KernelState(公共数据结构体)的判据。
|
||
//
|
||
// ## ★ 这个文件为什么是被重建的(一个真实的覆盖漏洞)
|
||
//
|
||
// `CloseAll` 的逆序判据原先在 `bootctx_test.go` 里。我后来用 `KernelState`
|
||
// 取代 `BootCtx` 时**删掉了那个文件**,而新文件里**没有**补回这条判据。
|
||
//
|
||
// 是**变异测试**发现的:把 `CloseAll` 改成正序执行,测试**全绿**
|
||
// (没有任何判据在检查它)⇒ 覆盖漏洞。
|
||
//
|
||
// 教训:删文件/重写实现时,必须**逐条核对原判据是否都补回了**
|
||
// (判据的"数量"不是指标,"每条原判据都有对应"才是)。
|
||
|
||
import (
|
||
"github.com/JianFeeeee/HologramAgent/internal/kstate"
|
||
"strings"
|
||
"sync"
|
||
"sync/atomic"
|
||
"testing"
|
||
)
|
||
|
||
// ★★★ 判据:**CloseAll 逆序执行**(LIFO,与 defer 一致)。
|
||
//
|
||
// 为何逆序:先初始化的一般是底层(config → memory → llm),
|
||
// 停机应**反向拆**,否则可能拆掉别人还在用的东西。
|
||
func TestKernelStateCloseAllIsReverseOrder(t *testing.T) {
|
||
ks := kstate.New()
|
||
var mu sync.Mutex
|
||
var order []string
|
||
|
||
for _, name := range []string{"config", "memory", "llm"} {
|
||
n := name
|
||
ks.AddCloser(func() {
|
||
mu.Lock()
|
||
order = append(order, n)
|
||
mu.Unlock()
|
||
})
|
||
}
|
||
if err := ks.CloseAll(); err != nil {
|
||
t.Fatalf("CloseAll: %v", err)
|
||
}
|
||
want := []string{"llm", "memory", "config"}
|
||
if strings.Join(order, ",") != strings.Join(want, ",") {
|
||
t.Fatalf("★ CloseAll 应逆序(LIFO,与 defer 一致): 期望 %v 实际 %v", want, order)
|
||
}
|
||
}
|
||
|
||
// ★★★ 判据:**CloseAll 不因单个关闭函数 panic 而中断**。
|
||
func TestKernelStateCloseAllSurvivesPanic(t *testing.T) {
|
||
ks := kstate.New()
|
||
closed := false
|
||
ks.AddCloser(func() { panic("关闭时炸了") })
|
||
ks.AddCloser(func() { closed = true })
|
||
|
||
_ = ks.CloseAll()
|
||
if !closed {
|
||
t.Fatal("★ 一个关闭函数 panic 导致其他模块没被关闭(资源泄漏)")
|
||
}
|
||
}
|
||
|
||
// ★★★ 判据:**CloseAll 幂等**(清空后再次调用不重复执行)。
|
||
func TestKernelStateCloseAllIsIdempotent(t *testing.T) {
|
||
ks := kstate.New()
|
||
var n int32
|
||
ks.AddCloser(func() { atomic.AddInt32(&n, 1) })
|
||
|
||
_ = ks.CloseAll()
|
||
_ = ks.CloseAll() // 第二次不应再执行
|
||
if got := atomic.LoadInt32(&n); got != 1 {
|
||
t.Fatalf("★ 关闭函数被执行 %d 次(应恰好 1 次)", got)
|
||
}
|
||
}
|
||
|
||
// ★★★ 判据:**AddCloser 并发安全**(同层模块并行 Init 都会调它)。
|
||
//
|
||
// ★ 这条是压力测试+race 抓到的**真缺陷**的回归判据:
|
||
// 第 1 层有 8 个模块并行,其中 5 个注册关闭函数 ⇒ 并发 append
|
||
// ⇒ 数据竞争 + 可能丢失元素(某个模块的关闭函数永不调用 ⇒ 资源泄漏)。
|
||
func TestKernelStateAddCloserConcurrent(t *testing.T) {
|
||
ks := kstate.New()
|
||
const n = 500
|
||
|
||
var wg sync.WaitGroup
|
||
for i := 0; i < n; i++ {
|
||
wg.Add(1)
|
||
go func(i int) {
|
||
defer wg.Done()
|
||
ks.AddCloser(func() {})
|
||
}(i)
|
||
}
|
||
wg.Wait()
|
||
|
||
if len(ks.Closers) != n {
|
||
t.Fatalf("★ 并发 AddCloser 丢失了关闭函数:应 %d 个,实际 %d(slice append 竞争)",
|
||
n, len(ks.Closers))
|
||
}
|
||
}
|
||
|
||
// ★★★ 判据:**nil 关闭函数被忽略**(不 panic、不占位)。
|
||
func TestKernelStateAddCloserIgnoresNil(t *testing.T) {
|
||
ks := kstate.New()
|
||
ks.AddCloser(nil)
|
||
if len(ks.Closers) != 0 {
|
||
t.Fatalf("nil 关闭函数应被忽略,实际记录 %d 个", len(ks.Closers))
|
||
}
|
||
if err := ks.CloseAll(); err != nil {
|
||
t.Fatalf("空表 CloseAll 应成功: %v", err)
|
||
}
|
||
}
|