Files
HomeAgent/internal/agent/core/overflow_test.go
JianFeeeee a68d6a428c feat: 模块化内核(编译期依赖图定序)+ 密钥防火墙 + 插件三态生命周期 (#10)
* feat(kernel): 模块化内核 + 编译期依赖图定序

把单体 init 序列拆成「模块自声明依赖 + 编译期生成依赖图 + 运行期只读图」。

## 为什么

原 cmd/homed/main.go 里 17 步 init 是**手写顺序**,依赖关系只存在于
注释和人脑里。实测踩到的坑(见 docs/zh/kernel-modularization-design.md):
 · nlp.defaultParser 被 initONNXParser 写、被 distiller 读,两者相距 60 行,
   只靠 ticker 10min 才没炸(隐式依赖,无声明)
 · 加一个模块要人肉找"该插在哪",插错的表现是运行期 nil 解引用
 · 关停是 defer ks.CloseAll(),而热更新路径 os.Exit(42) **跳过 defer**
   ⇒ docStore/distiller/textMem 的 flush 全部丢失(每次热更新都发生)

## 怎么改

- internal/kernelboot/:KernelState(一个结构体收全部包级共享变量,字段
  nil 安全)、Module 接口、graphfile(依赖图编解码 + 与二进制 hash 对账)、
  scheduler(按 BFS 层并行 Init)、syncbus(层边界写通知)、
  lifecycle(Quiesce/Resume 可逆伪关机,区别于一次性 CloseAll)
- internal/kernelmod/<name>/:每个模块一个文件夹,Requires/Provides 自声明;
  all/all.go 是唯一的 import 清单(Go 循环导入约束)
- cmd/homed-depgraph:编译期生成依赖图,Makefile 注入 digest
- 运行期只**读**图,不计算顺序(顺序是编译期决定的,源码里没有中央清单)

## 判据

kernelboot 8 条 + 图失败模式 7 条(全部拒绝并给准确错误)+ 模块目录数
与注册表一致性。变异测试 15/15 咬住,含:
 · 删掉 AddCloser 的锁 → -race 报数据竞争
 · Scheduler 同批跑去重 → 203 vs 200
 · 图 hash 不匹配 → 拒绝启动

## 顺带修的缺陷

热更新路径漏调模块关闭 ⇒ 显式 stopKernelModules(),并用 AST 判据钉住
"必须在 os.Exit 之前"(字符串检查在本仓已骗过我三次)。

实测:冷启动 1630ms(5 层/17 模块,原 17 步串行);生产 22 插件全部建链。

* feat(security): 密钥防火墙 + 配置加密 + close 纪律

## 密钥防火墙

模型只见别名、不见明文;插件工具调用入口(StageHost.ExecuteTool)做入向
回填。三维能力:
 · 出向:工具输出里的密钥被替换成 [[secret:name]] 别名后才进上下文
 · 入向:模型传别名,入口处填回真值(插件完全无感知)
 · 存储:config.db 里不存明文(0644 的库可读),敏感值独立 0600 文件

模式库「宁漏勿误伤」:宁可漏掉一次替换,也不把正常文本误当密钥。

## 配置加密

- internal/security/{codec,key,keyring,store,global}.go:AES-256-GCM,
  enc:v1: 前缀,密钥轮换(OldKeys 解码 + 新钥加密)
- harden.go:数据目录权限收紧
- embedded.go:支持内嵌主密钥(可选,仍保留外部 key 文件路径)
- EncryptExistingSecrets / AuditSecrets:启动时幂等迁移 + 审计

## close 纪律(用户明确要求:只要调 close 就要有前置检查)

internal/safeclose:Safe / SafeFunc。全仓 37 处裸 close(chan) → 0。
关键教训(都写进注释和判据):
 · `select { case <-ch: default: close(ch) }` **不是**并发安全的
   (两个 goroutine 可同时命中 default)—— healthcheck 原先是这种写法
 · `sync.Once` **不可重入**:X.Do(func(){ Safe(&X, ...) }) 会自锁,
   症状是 go test 直接挂住(3 个包 600s 超时),栈里只有嵌套的 Once.Do
 · map 里按请求持有的 channel(mcp/stdio.go、clawhubadapter/sidecar.go)
   改成 *pendingRPC 包装,每通道一个 once

## 判据

security 全量 + TestNoBareCloseOutsideSafeclose(AST 级扫描,含注释剥离)
+ TestNoNestedSelfOnceDeadlock(正则修正:\w+ 不匹配点号,捕获组要含 '.')。
变异 2/2 咬住。全量 52 包 ok。

* feat(plugin+deploy): 插件三态生命周期、数据目录迁移、发行包修复

## 插件三态生命周期(用户要求:自动启动 / 启用但不自动启动 / 禁用)

- Manifest 新增 requires_facilities / auto_start(*bool,用于区分
  "未声明"与"显式 false")
- plugin-host 模块(internal/kernelmod/pluginhost):用 kernelboot.Scheduler
  按依赖时机拉起,**不再手写两阶段**
- 运行态停启 StopPlugin/StartPlugin **可逆**:不写 disabled_plugins
  (不改用户决定)、不置 shuttingDown(之后还能加载)、会摘掉注册面
- 与 StopAll 的区别写进注释 —— StopAll 置 shuttingDown 后**永久无法加载**,
  那是进程退出用的,误用于"暂停"就是关了就死

## 数据目录迁移(伪关机 → 迁移 → 唤醒)

- kernelboot/lifecycle.go:Quiesce/Resume(可逆,区别于一次性 CloseAll),
  逆序暂停、逆序恢复、Pause 失败回滚
- kernelboot/migrate.go:BeginMigration/End 编排(先停插件 → 再停内核写者
  → 等在途归零)
- distiller/textmem 增 Pause/Resume 门(不是 cancel —— cancel 不可逆,
  恢复要重建整个对象)
- 模块 migration:体检 + 生成可执行迁移脚本

★ 迁移脚本的三个实测教训(都写成了判据):
 1. 无条件改 /etc/systemd/system ⇒ 演练把**生产** -data 改成了演练目录。
    加 --dry-run(零改动)+ 强制校验 systemd 当前 -data == OLD
 2. 本机没装 rsync,脚本在"服务已停、数据未搬"处硬失败 ⇒ cp -a 回退,
    并明确警告不保硬链接/ACL(生产 plugindev 有大量 git 硬链接)

## 发行包修复(全部经实测确认)

 1. package-linux.sh **完全漏打 depgraph.bin** ⇒ 内核 exit 1
    ("生产构建(内嵌 hash 非空)但读不到依赖图")
 2. build_homed 不走 Makefile ⇒ 单独修 Makefile 无效,必须同时生成图+注入
 3. build.sh 的 LDFLAGS 用**历史模块路径 gitcode.com** ⇒ -X 静默 no-op
    ⇒ --version 显示 unknown
 4. Makefile -ldflags 用**单引号** ⇒ 注入了字面 $GRAPH_HASH

## ★ build.sh 的版本号必须校验(真实事故)

原 `VERSION="$(git describe --tags --dirty)"`。无 tag 分支上它返回**分支名**
`backup/pre-identity-rewrite-20261005-51-g03d87a4e-dirty`,被注入 meta.Version
⇒ 插件握手判据 MajorVersion() 把整串当主版本 ⇒ **22 个子进程插件全部
握手失败**("主版本不匹配")。内核活着、systemd active、日志每条都像
插件的问题 —— 实际是发行包带着非法版本号。

修法:git describe 只在形如 vX.Y.Z 时采用,否则回退 meta.Version(权威源),
并对最终值做形态守卫。deploy/packaging/version_guard_test.go 3 条判据,
变异 2/2 咬住。

## deb 的 systemd unit 改为 guard 模式

ExecStart=/usr/bin/homed --role=guard --data /var/lib/homeagent
(worker exit 42 → guard 重拉,不经过 systemd、不计失败)
含 RestartSteps/RestartMaxDelaySec/TimeoutStopSec + 硬化
(NoNewPrivileges/ProtectSystem/ProtectHome/DevicePolicy/ReadWritePaths)。

## 其他

- internal/plugin/proc:非法 JSON 帧的报错**可定位**(内容摘要 + 可能原因 +
  修法)。生产实测 1038 条非法帧(插件往 stdout 打日志 = 污染协议通道)
- 示例插件 4 个 14 处 fmt.Printf → log.Printf
- hmapdev 模板同步修复;scaffold 判据剥离注释(模板注释里就含 fmt.Printf)

* chore: 收尾(主密钥轮换命令、IPC/知识库加固、SDK 对齐)

- cmd/homed-key-rotate:把 security 里的 RotateKey/RotateKeyFile/RekeySecrets
  串成一条**可执行**的运维路径。没有它,E-1 就只是库里的能力而不是
  "出事时能做的事",而轮换的价值恰恰在于能执行。
- cmd/homed:kmod_runtime(模块装配入口)、plugins_scheduled(failback
  白名单)、memcandidate、bootstrap_order_test / shutdown_flush_test
- internal/ipc、internal/devicebridge、internal/knowledge:配套加固
- third_party/homeagent-sdk/sdk:PluginMgrAPI 增三态能力(mgrStop/mgrStart/
  mgrIsRuntimeStopped)+ settings 对齐

判据:bootstrap_order_test(启动顺序不依赖手写序列)、
shutdown_flush_test(停机的两条路径必须对称 —— exit 42 会跳过 defer,
热更新路径下模块关闭/flush 曾全部丢失)。

* test(security): 测试夹具改用不可误认的占位值(修 push protection 拦截)

GitHub secret scanning 拦住了推送:三处测试夹具用了"看起来像真密钥"的
字面量:

  internal/security/prefilter_test.go:39
  internal/security/store_test.go:177
  internal/security/survey_test.go:20

它们全是**假密钥**(`AKIAIOSFODNN7EXAMPLE` 是 AWS 官方文档的标准示例,
其余是 `abcdefghij...` 这类可读占位符),但扫描器无法区分 —— 它只看形态。

★ 不绕过(不用 unblock URL、不加 allowlist):直接改夹具。
原因:一旦允许"假密钥可以通过",真密钥混进来时就没有最后一道门了。

改法:保留**模式库匹配所需的结构**,把可识别内容换成 FAKE:
  glpat-abcdefghijklmnopqrst       → glpat-FAKE-TEST-TOKEN-NOT-REAL
  sk-abcdefghij...012345           → sk-FAKE-TEST-KEY-NOT-REAL-0000000
  AKIAIOSFODNN7EXAMPLE             → AKIA0000FAKE0000TEST   (保持 20 字符)
  ASIAIOSFODNN7EXAMPLE             → ASIA0000FAKE0000TEST
  xoxb-123456789012-abcdefghijklmnop → xoxb-FAKE-TEST-TOKEN-NOT-REAL

★ 中途踩到一次:AWS 键的模式是 `\b(AKIA|ASIA)[0-9A-Z]{16}\b`(共 20 字符),
我第一次替换成 19 字符的 `AKIAFAKETESTKEY0000` ⇒ 模式匹配不上 ⇒
TestSurvey_WhatIsCaught / TestRecognizesCommonShapes /
TestPrefilterNeverBlocksRealMatches 三条当场变红。
判据正确地拒绝了"为了过扫描器而削弱覆盖"。

顺带核实:全仓 grep 无任何真实密钥泄漏。

* fix(packaging): package-linux.sh 的版本解析与 build.sh 统一

上一版只修了 build.sh,漏了 package-linux.sh —— 它仍只看 git describe:

  VERSION="${VERSION:-$(git describe --tags --dirty)}"

无 tag 分支上 git describe 返回**分支名**
(backup/pre-identity-rewrite-20261005-56-g98850e1),守卫会正确拒绝,
但要求人**手动传 VERSION** 才能打包。而 build.sh 早已能自动回退 meta.Version
⇒ 同一个版本,走 build.sh 打得出来、走 package-linux.sh 打不出来。

危害不只是"要手动传参":运维为了跑通会去掉守卫,而分支名一旦进
meta.Version 就是**插件协议主版本**的来源 ⇒ 22 个子进程插件全部握手失败
(这是真实发生过的事故,见 3efa4e5)。

修法:两个脚本用同一套规则(git describe 仅在 vX.Y.Z 形态时采用,
否则回退 meta.Version),并对最终值做形态守卫。

判据:TestBothPackagingScriptsShareVersionRules —— 逐个读两个脚本,
要求都能从 meta/meta.go 取权威版本、都校验 git describe 形态。
变异(把 package-linux.sh 改回旧规则)咬住并准确指出是哪个脚本。

实测:不传 VERSION 跑 package-linux.sh,输出
  [PKG] warn: git describe 给出非版本串(...),改用 meta.Version=1.4.0
  Version: 1.4.0

* fix(test): 跨仓判据在 CI 上应 skip 而非 fail(修 PR 双红)

CI 上 "Go build / vet / test" 与 "Build linux/amd64" 双红:

  --- FAIL: TestHmapdevTemplateImplementsAllPluginMgrMethods
      bridge_sync_test.go:170: 读模板: open
      ../../../third_party/homeagent-sdk/tools/hmapdev/templates/proc_main.go.tmpl:
      no such file or directory

## 根因:判据依赖了一个**被 gitignore 的路径**

`.gitignore:33` 有 `third_party/homeagent-sdk/tools/`(SDK 仓自治,本仓不跟踪)。
于是:
  · 本机(完整 SDK 检出)有该文件 ⇒ 判据通过
  · CI(只 checkout 本仓)没有该文件 ⇒ Fatalf ⇒ **必红**

我提交时只在本机跑测试、没看 CI,所以这个问题拖到 PR 才暴露。

## 修法

文件缺失时 `t.Skipf` 而不是 `t.Fatalf`。

★ 这不是"放弃检查":
  · 跨仓一致性由 **SDK 仓自己的判据**守着
    (tools/hmapdev/scaffold_stdout_test.go 等),那里才是模板的真实归属地
  · 本判据在本机开发时**仍然生效**(已验证:有文件时 PASS,缺文件时 SKIP)

## 验证

 · 本机(有文件)  → PASS(判据真跑)
 · 模拟 CI(移走 tools/)→ SKIP(不再 fail)
 · 全量 53 包 ok / 0 fail

## 顺带

同目录还有 e2e_template_test.go 也读 tools/,但它是 `//go:build` 门控的
e2e 判据,CI 默认不跑,无需处理。

---------

Co-authored-by: JianFeeeee <JianFeeeee@users.noreply.gitcode.com>
2026-10-17 19:18:24 +08:00

575 lines
22 KiB
Go
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

package core
import (
"fmt"
"strings"
"sync"
"testing"
agentAPI "github.com/JianFeeeee/HomeAgent/internal/agent/api"
agentIO "github.com/JianFeeeee/HomeAgent/internal/agent/io"
)
// ── 测试替身 ──
// fakeOverflowProvider 只提供 MaxContextTokens(超页判据需要它),
// 其余 Provider 方法不参与本组测试。
type fakeOverflowProvider struct {
agentAPI.Provider
window int
}
func (p *fakeOverflowProvider) MaxContextTokens() int { return p.window }
// newOverflowAgent 造一个够用<E5A49F><E794A8><EFBFBD>超页测试 Agent。
func newOverflowAgent(window, maxContextSize int, events int, chunkChars int) *Agent {
a := &Agent{
io: agentIO.NewIOManager(),
provider: &fakeOverflowProvider{window: window},
maxContextSize: maxContextSize,
context: NewRelevanceContext("", nil),
}
// 固定向量,避免依赖稠密模型;也不进 docStore(nil ⇒ Prune 只重排不写盘)。
for i := 0; i < events; i++ {
a.context.Append(ContextEvent{
Input: fmt.Sprintf("第%d批输入", i) + strings.Repeat("x", chunkChars),
Response: fmt.Sprintf("第%d批回执", i) + strings.Repeat("y", chunkChars),
})
}
return a
}
// ── T1:积累量超限才触发裁剪 ──
func TestOverflow_T1_积累超125触发(t *testing.T) {
// 窗口 1000 token;maxContextSize=2(条数),制造远超容量的积累。
a := newOverflowAgent(2000, 2, 20, 400) // 单条827 < 预算~1067,但总量 16540 远超
before := a.context.Len()
ratio := a.overflowRatioNow()
if ratio < overflowRatio {
t.Fatalf("构造后应已超页,ratio=%.2f 阈值=%.2f", ratio, overflowRatio)
}
handled, pruned := a.maybeHandleContextOverflow(nil, "退款导出")
if !handled {
t.Fatal("超限时 maybeHandleContextOverflow 应返回 handled=true")
}
if pruned <= 0 {
t.Fatal("应裁剪出至少一条")
}
if after := a.context.Len(); after >= before {
t.Fatalf("裁剪后条数未减少:%d → %d", before, after)
}
}
// 未超页时必须零动作(这是热路径,每轮都调)。
func TestOverflow_T1_未超页不动手(t *testing.T) {
// 窗口 10_000_000 token:任何合理积累都远低于 1.25×
a := newOverflowAgent(10_000_000, 2, 5, 100)
before := a.context.Len()
handled, pruned := a.maybeHandleContextOverflow(nil, "查询")
if handled || pruned != 0 {
t.Fatalf("未超页不应处理:handled=%v pruned=%d", handled, pruned)
}
if after := a.context.Len(); after != before {
t.Fatalf("未超页时上下文不应变化:%d → %d", before, after)
}
}
// 轻量内核(驻留子)走的是另一套策略,不做按相关度裁剪。
func TestOverflow_T1_轻量内核跳过(t *testing.T) {
a := newOverflowAgent(1000, 2, 20, 400)
a.parentID = "parent-1" // 触发 isLightKernel
handled, pruned := a.maybeHandleContextOverflow(nil, "查询")
if handled || pruned != 0 {
t.Fatalf("轻量内核不应按相关度裁剪:handled=%v pruned=%d", handled, pruned)
}
}
// ── T2:裁剪后积累量确实下降 ──
func TestOverflow_T2_裁剪后累积下降(t *testing.T) {
a := newOverflowAgent(2000, 2, 20, 400) // 单条装得下,总量超页
before := a.accumulatedTokens()
a.maybeHandleContextOverflow(nil, "退款导出")
after := a.accumulatedTokens()
if after >= before {
t.Fatalf("裁剪后积累 token 未下降:%d → %d", before, after)
}
}
// ── T4(变异项):裁不出东西 ⇒ 终止且不触发 L4 ──
//
// 构造「装得下却超页」:maxContextSize 给得足够大,Prune 会返回 0。
// 期望:记账 Aborted、不调 raiseKernelInterrupt(用 stat.Triggered 验证)。
func TestOverflow_T4_裁不动则终止不中断(t *testing.T) {
// 「裁不动」的真正构造:**只有 1 条事件** —— 裁剪不可能减少任何东西
// (Prune 里 protected 至少 1 条、keep 也至少要留 1 条)。
// 旧构造(maxContextSize=9999 + 5 条)在自适应 protected 下反而能裁掉 3 条,
// 因为预算 534 token 装不下 10 条保护 ⇒ 自动收紧到 1 ⇒ topK=2。
a := newOverflowAgent(1000, 9999, 1, 4000)
if a.overflowRatioNow() < overflowRatio {
t.Fatal("前置条件不成立:构造的会话应超页")
}
a.maybeHandleContextOverflow(nil, "查询")
a.overflowStat.Lock()
aborted, triggered := a.overflowStat.Aborted, a.overflowStat.Triggered
a.overflowStat.Unlock()
if aborted != 1 {
t.Fatalf("应记一次 Aborted,实际 %d", aborted)
}
if triggered != 0 {
t.Fatalf("裁不出东西时**不应**触发 L4,实际 Triggered=%d", triggered)
}
}
// ── T6:中断消息必须带「查不到不等于不存在」──
func TestOverflow_T6_中断消息含认知提示(t *testing.T) {
got := overflowNotice(17)
if got == "" {
t.Fatal("超页通知不应为空")
}
if !strings.Contains(got, "查不到不等于不存在") {
t.Fatalf("中断消息缺少认知提示,agent 会把「没检索到」误判成「不存在」:%q", got)
}
if !strings.Contains(got, "文档记忆") {
t.Fatalf("中断消息应说明被裁内容去了哪里:%q", got)
}
// 来源标识在 raiseKernelInterrupt 的参数里("kernel/overflow"),
// 不在消息正文 —— 那部分留给可读性。这里只保证提示词自洽。
if strings.Contains(got, "查不到等于存在") {
t.Fatalf("提示词语义写反了:%q", got)
}
}
// ── 上游 ErrContextFull 走同一条裁剪路径 ──
func TestOverflow_上游ErrContextFull走同路径(t *testing.T) {
a := newOverflowAgent(2000, 2, 20, 400) // 单条装得下,总量超页
// 累积不足以下次超页也没关系:上游已经明说装不下了
if !a.handleUpstreamContextFull(&agentAPI.ProviderError{
StatusCode: 400,
Kind: agentAPI.ErrContextFull,
Message: "context_length_exceeded",
}) {
t.Fatal("上游 ErrContextFull 应被接住并返回 true(可恢复)")
}
a.overflowStat.Lock()
upstream, triggered := a.overflowStat.Upstream, a.overflowStat.Triggered
a.overflowStat.Unlock()
if upstream != 1 {
t.Fatalf("应记一次上游超页,实际 %d", upstream)
}
if triggered != 1 {
t.Fatalf("上游超页也应经 L4 上报一次,实际 %d", triggered)
}
}
// 非上下文类错误不得被误接。
func TestOverflow_上游其他错误不误接(t *testing.T) {
a := newOverflowAgent(1000, 2, 20, 400)
for _, kind := range []agentAPI.ErrKind{agentAPI.ErrCredential, agentAPI.ErrTransient, agentAPI.ErrUnknown} {
if a.handleUpstreamContextFull(&agentAPI.ProviderError{
StatusCode: 500, Kind: kind, Message: "boom",
}) {
t.Fatalf("kind=%v 不应被当作上下文超限接住", kind)
}
}
}
// nil context / nil provider 不得 panic。
func TestOverflow_零值不panic(t *testing.T) {
var a *Agent
if handled, _ := a.maybeHandleContextOverflow(nil, "q"); handled {
t.Fatal("nil agent 不应处理")
}
empty := &Agent{}
if handled, _ := empty.maybeHandleContextOverflow(nil, "q"); handled {
t.Fatal("零值 agent 不应处理")
}
_ = empty.overflowRatioNow()
_ = empty.accumulatedTokens()
}
// ── T8(回归):并发调用安全 ──
// 超页判据在每轮 LLM 请求前调用,是热路径;AccumulatedTokens 会遍历事件,
// 必须与 Append 并发安全,否则数据竞争。
func TestOverflow_并发安全(t *testing.T) {
a := newOverflowAgent(1000, 2, 50, 200)
var wg sync.WaitGroup
for i := 0; i < 8; i++ {
wg.Add(1)
go func(i int) {
defer wg.Done()
for j := 0; j < 50; j++ {
a.context.Append(ContextEvent{
Input: fmt.Sprintf("并发%d-%d", i, j),
Response: strings.Repeat("z", 300),
})
_ = a.overflowRatioNow()
}
}(i)
}
wg.Wait()
}
// ── T5(变异项):帧内恢复预算耗尽 ⇒ 终止而非死循环 ──
//
// 为什么要单独测:这个防护一度是**死代码**(TaskFrame.OverflowRecover 声明了
// 但从没被读取)。没接线的防护等于没有防护 —— 变异测试正是抓这种。
func TestOverflow_T5_恢复预算耗尽则终止(t *testing.T) {
// (4000,800) 实测:单条 1627 token 装得进预算 2134,但总量 ratio=8.13 超页
a := newOverflowAgent(4000, 30, 20, 800)
f := &TaskFrame{}
// 第一次超页:正常裁剪
handled, pruned := a.maybeHandleContextOverflow(f, "退款导出")
if !handled || pruned <= 0 {
t.Fatalf("首次应正常裁剪:handled=%v pruned=%d", handled, pruned)
}
if f.OverflowRecover != 1 {
t.Fatalf("首次应记一次恢复,<E5A48D><EFBC8C>际 %d", f.OverflowRecover)
}
// 制造「裁不动」:每次检查前把上下文压到只剩 1 条大事件
// (实测 ratio=8.03),裁剪无从下手。
// 注:必须每次重新压 —— 第一次超页已把上下文裁小,不重压就不会再超页,
// 那样测的就不是「反复裁不动」而是「裁一次就好了」。
collapse := func() {
for a.context.Len() > 1 {
a.context.events = a.context.events[:len(a.context.events)-1]
}
a.context.events[0] = &ContextEvent{
Input: strings.Repeat("A", 8_000), Response: strings.Repeat("B", 8_000),
}
}
// 预算内的第二次:仍会尝试
collapse()
handled, _ = a.maybeHandleContextOverflow(f, "退款导出")
if !handled {
t.Fatal("预算内仍应处理")
}
if f.OverflowRecover != 2 {
t.Fatalf("预算内应累计到 2,实际 %d", f.OverflowRecover)
}
// 第三次:超预算 ⇒ 终止,且写明原因
collapse()
handled, _ = a.maybeHandleContextOverflow(f, "退款导出")
if !handled {
t.Fatal("超预算也应算「已处理」(终止),以免调用方再重跑")
}
if f.Terminal != terminalError {
t.Fatalf("超预算应置终止态,实际 terminal=%v", f.Terminal)
}
if f.Err == nil || !strings.Contains(f.Err.Error(), "max_context_size") {
t.Fatalf("终止原因应指向根因(max_context_size 与窗口不匹配):%v", f.Err)
}
}
// 变异自证:把预算调到极大 ⇒ 上面那条必须变红(证明它真的在数)。
func TestOverflow_T5_变异_预算极大则不终止(t *testing.T) {
backup := overflowRecoverBudget
overflowRecoverBudget = 1 << 30
defer func() { overflowRecoverBudget = backup }()
a := newOverflowAgent(1000, 2, 20, 400)
a.maxContextSize = 99999 // 裁不动
f := &TaskFrame{}
for i := 0; i < 5; i++ {
for a.context.Len() > 1 {
a.context.events = a.context.events[:len(a.context.events)-1]
}
a.context.events[0] = &ContextEvent{
Input: strings.Repeat("A", 8_000), Response: strings.Repeat("B", 8_000),
}
a.maybeHandleContextOverflow(f, "退款导出")
}
if f.Terminal == terminalError {
t.Fatalf("预算=2^30 时不应终止 ⇒ 预算判定可能没生效")
}
}
// ── T9:topK 随窗口换算(不再与窗口脱钩)──
//
// 这是 v4 跑分归因的根因二:max_context_size 是条数、与窗口无关,
// 所以「只调 context_window 到 1M 就更好」不成立。
func TestOverflow_T9_topK随窗口变化(t *testing.T) {
// 同样 20 条事件、同样的 max_context_size,只改窗口 ⇒ topK 必须跟着变
build := func(window int) *Agent {
return newOverflowAgent(window, 30, 20, 400) // maxContextSize=30(默认)
}
small := build(10_000) // 小窗口
large := build(1_000_000) // 大窗口(用户关心的 1M 场景)
topKSmall := small.contextTopK()
topKLarge := large.contextTopK()
if topKLarge <= topKSmall {
t.Fatalf("窗口变大后 topK 应变大:%d → %d(说明仍与窗口脱钩)", topKSmall, topKLarge)
}
// 小窗口下预算只够留很少事件;大窗口下应更宽松
if topKLarge < 10 {
t.Fatalf("1M 窗口下 topK=%d 过小,说明预算反推失效", topKLarge)
}
}
// max_context_size 仍是硬上限(改了配置必须生效,否则运维会困惑)。
func TestOverflow_T9_运维配置仍是上限(t *testing.T) {
a := newOverflowAgent(1_000_000, 5, 40, 200) // 窗口很大但硬上限 5
if got := a.contextTopK(); got > 4 {
t.Fatalf("topK=%d 超过 max_context_size-1=4,运维配置失效", got)
}
}
// 无积累样本时不得除零/返回 0。
func TestOverflow_T9_空上下文topK至少为1(t *testing.T) {
a := newOverflowAgent(50_000, 30, 0, 200)
if got := a.contextTopK(); got < 1 {
t.Fatalf("空上下文时 topK=%d,至少应为 1", got)
}
}
// 变异自证:把 contextTopK 退回「固定用 maxContextSize」,
// 上面那条「窗口变大 topK 变大」必须变红(证明该测试真能抓到脱钩)。
func TestOverflow_T9_变异_固定topK则脱钩(t *testing.T) {
build := func(window int) *Agent { return newOverflowAgent(window, 30, 20, 400) }
// 旧行为:topK 只看 max_context_size,与窗口无关 ⇒ 两个窗口得到同一个值。
oldTopK := func(a *Agent) int { return a.maxContextSize - 1 }
if oldTopK(build(10_000)) != oldTopK(build(1_000_000)) {
t.Fatalf("前置不成立:旧行为本应与窗口无关")
}
// 新实现必须与旧行为不同,否则「T9_topK随窗口变化」那条主测试是假绿。
newSmall := build(10_000).contextTopK()
newLarge := build(1_000_000).contextTopK()
if newSmall == oldTopK(build(10_000)) && newLarge == oldTopK(build(1_000_000)) {
t.Fatalf("新实现与旧实现不可区分 ⇒ topK 实际仍与窗口脱钩,主测试是假绿")
}
if newLarge <= newSmall {
t.Fatalf("新实现下窗口变大 topK 未变大:%d → %d", newSmall, newLarge)
}
}
// ── provider 未就绪时不得崩 ──
//
// 回归:contextTopK → computeTokenBudget → ComputeTokenBudgetTuned 里曾直接调
// provider.MaxContextTokens(),provider 为 nil 时 SIGSEGV(实测由
// TestMemoryPass_PruneAndRecallTogether 撞出来)。它同样会发生在
// 「配置早于 provider 就绪」的启动序列上,不只是测试场景。
func TestOverflow_零值Agent不崩(t *testing.T) {
// 完全零值 Agent(非 nil):无 provider、无 context、无配置
empty := &Agent{}
if got := empty.contextTopK(); got < 1 {
t.Fatalf("零值 Agent 的 topK=%d,至少应为 1", got)
}
// 硬上限为 0 时也不能崩
empty.maxContextSize = 0
if got := empty.contextTopK(); got < 1 {
t.Fatalf("maxContextSize=0 时 topK=%d,至少应为 1", got)
}
}
// ComputeTokenBudgetTuned 直接吃 nil provider(不经 Agent)也要安全。
func TestComputeTokenBudgetTuned_nilProvider(t *testing.T) {
b := ComputeTokenBudgetTuned(nil, "", ContextTuning{})
if b.MaxContext <= 0 {
t.Fatalf("nil provider 时应回退到默认窗口,实际 %d", b.MaxContext)
}
if b.ContextTokens < 0 {
t.Fatalf("ContextTokens 不应为负:%d", b.ContextTokens)
}
}
// ── topK 下限:不能被算成 1(会让裁剪完全无效)──
//
// 实测缺陷:v4 的工具大回执型事件平均 48000 token,而 50k 窗口的
// ContextTokens 预算只有 40000 ⇒ 预算反推的 topK = 0 ⇒ 钳到 1。
// 而 Prune 里 keepCount = topK - protected = 1 - 10 < 0 ⇒ keep 为空
// ⇒ **全部事件被归档**:裁完一轮上下文照样超页,超页处理空转。
//
// 正确下限是 protectedCount+1:宁可暂时超页,等预算或事件尺寸回到正常区间。
func TestOverflow_大事件时topK不塌到1(t *testing.T) {
// 窗口 50000 ⇒ ContextTokens 预算约 40000
a := newOverflowAgent(50_000, 30, 30, 0)
// 造「单条就超预算」的事件:Response 48000 token
for i := 0; i < 30; i++ {
a.context.Append(ContextEvent{
Input: strings.Repeat("A", 160_000), // 约 40000 token
Response: strings.Repeat("B", 192_000), // 约 48000 token
})
}
topK := a.contextTopK()
protected := a.effectiveProtectedCount()
if topK <= protected {
t.Fatalf("topK=%d <= protectedCount=%d ⇒ 裁剪会把全部事件归档(keep 为空),"+
"超页处理空转", topK, protected)
}
if topK < protected+1 {
t.Fatalf("topK=%d 必须至少是 protectedCount+1=%d", topK, protected+1)
}
}
// 真实形状验证:topK 下限生效时,Prune 确实还能裁掉东西。
func TestOverflow_大事件时裁剪仍有效(t *testing.T) {
a := newOverflowAgent(50_000, 30, 30, 0)
for i := 0; i < 30; i++ {
a.context.Append(ContextEvent{
Input: strings.Repeat("A", 8_000),
Response: strings.Repeat("B", 40_000),
})
}
before := a.context.Len()
pruned := a.handleContextOverflow("退款导出", 10.0)
after := a.context.Len()
if pruned <= 0 && after >= before {
t.Fatalf("裁剪无效:%d → %d 条,pruned=%d", before, after, pruned)
}
// 裁剪后仍应留下 protected 条以上,不能清空
if after < a.effectiveProtectedCount() {
t.Fatalf("裁剪后只剩 %d 条,少于有效保护数 %d(记忆被清空)",
after, a.effectiveProtectedCount())
}
}
// ── 工具回灌必须计入累积量 ──
//
// 实测缺陷(T10 诊断日志 ratio=0.00 / events=1 抓到):ContextEvent 里工具输出
// 是**独立字段** ToolResults,accumulatedTokens 只算 Input+Response 时,
// 一个「用户说 10 字、模型回 20 字、调了 8 个工具各回 3 万 token」的轮次
// 算出来是 30 token ⇒ 超页判据永远不触发。
//
// 而 prompt 峰值的真正来源恰恰是工具回灌。
func TestOverflow_工具回灌计入累积(t *testing.T) {
a := newOverflowAgent(50_000, 30, 0, 0)
a.context.Append(ContextEvent{
Input: "查一下 order-gw 的端口",
Response: "好的,正在查",
ToolResults: []ToolResultItem{
{Name: "files_read", Output: strings.Repeat("X", 120_000)}, // 约 30000 token
{Name: "cmd_run", Output: strings.Repeat("Y", 120_000)}, // 约 30000 token
},
})
acc := a.accumulatedTokens()
if acc < 50_000 {
t.Fatalf("工具回灌未计入:accumulatedTokens=%d(两条工具各 3 万 token)", acc)
}
// 且应能触发超页:2 轮同样的事件即远超窗口
a.context.Append(ContextEvent{
Input: "再查一次",
Response: "好",
ToolResults: a.context.Recent(1)[0].ToolResults,
})
if ratio := a.overflowRatioNow(); ratio < overflowRatio {
t.Fatalf("两条工具回灌轮次应触发超页,实际 ratio=%.2f", ratio)
}
}
// 反向判据:没有工具结果时,累积量应只等于 Input+Response。
func TestOverflow_无工具时只算对话(t *testing.T) {
a := newOverflowAgent(50_000, 30, 0, 0)
a.context.Append(ContextEvent{Input: strings.Repeat("a", 400), Response: strings.Repeat("b", 400)})
acc := a.accumulatedTokens()
// 800 字符 ≈ 400 token(EstimateTokens 是字符/2 量级),不应有额外放大
if acc > 1000 {
t.Fatalf("无工具结果的短对话被算成 %d token(应≈400)", acc)
}
if acc < 100 {
t.Fatalf("无工具结果的短对话算成 %d token,明显漏算", acc)
}
}
// ── B 方案:protected 按预算自适应(配置值是上限,不是固定值)──
//
// T10c 实测踩出的自相矛盾:protected=10 × 单条 5800 token = 58000 >
// ContextTokens 预算 40000 ⇒「钉住 10 条」本身就装不下 ⇒ 裁剪无解 ⇒
// 每轮触发两次超页 → 预算耗尽 → 任务终止(prompt=0)。召回 44%→22%。
//
// 现在:预算装不下时自动收紧,装得下时用满配置。
func TestOverflow_protected按预算收紧(t *testing.T) {
// 小窗口 + 大事件 ⇒ 预算装不下 10 条
small := newOverflowAgent(20_000, 30, 12, 20_000)
cfgCap := small.context.ProtectedCount() // 配置上限仍是 10
eff := small.effectiveProtectedCount()
if cfgCap != 10 {
t.Fatalf("配置上限应仍为 10,实际 %d", cfgCap)
}
if eff >= cfgCap {
t.Fatalf("预算装不下时应收紧,但 eff=%d >= cfg=%d", eff, cfgCap)
}
// 收紧后若仍装不下,必须能识别出「单条事件本身就超预算」这个真相,
// 让调用方走终止路径,而不是反复裁剪到预算耗尽。
if eff*small.accumulatedTokens()/small.context.Len() > small.computeTokenBudget().ContextTokens {
if small.singleEventFitsBudget() {
t.Fatalf("收紧后装不下却报告单条装得下 ⇒ 判定自相矛盾")
}
}
// 大窗口 ⇒ 用满配置值(这正是「1M 下这套调度器能更好」的机制)
big := newOverflowAgent(1_000_000, 30, 12, 200)
if got := big.effectiveProtectedCount(); got != big.context.ProtectedCount() {
t.Fatalf("大窗口下应<E4B88B><E5BA94>满配置值 %d,实际 %d", big.context.ProtectedCount(), got)
}
}
// 自适应后裁剪必须真的有效(旧逻辑下裁不动)。
func TestOverflow_自适应后裁剪有效(t *testing.T) {
// (4000,800):单条 1627 装得进预算 2134,总量 ratio=8.13 ⇒ 裁剪可帮上忙。
// 对照组是「单条本身就超预算」——那种情况裁剪无解,走终止路径,
// 由TestOverflow_单条超预算则终止 覆盖。
a := newOverflowAgent(4000, 30, 5, 800)
before := a.context.Len()
pruned := a.handleContextOverflow("退款导出", 1.3)
after := a.context.Len()
if after >= before {
t.Fatalf("自适应后裁剪应有效:%d → %d(pruned=%d)", before, after, pruned)
}
if a.effectiveProtectedCount() >= before {
t.Fatalf("有效保护数 %d 不应 ≥ 裁剪前条数 %d",
a.effectiveProtectedCount(), before)
}
}
// 单条事件本身就超预算 ⇒ 裁剪无解 ⇒ 直接终止并报真实原因
// (而不是裁两轮后 Budget 耗尽,后者会丢失已经裁掉的记忆)。
func TestOverflow_单条超预算则终止(t *testing.T) {
// (2000,800):单条 1627 > 预算 1067 ⇒ fits=false
a := newOverflowAgent(2000, 30, 5, 800)
if a.singleEventFitsBudget() {
t.Fatal("前置不成立:单条应装不下预算")
}
before := a.context.Len()
pruned := a.handleContextOverflow("退款导出", 5.0)
if pruned != 0 {
t.Fatalf("单条超预算时不应裁剪(裁了也装不下),实际 pruned=%d", pruned)
}
if after := a.context.Len(); after != before {
t.Fatalf("单条超预算时上下文不应被改动:%d → %d", before, after)
}
a.overflowStat.Lock()
aborted := a.overflowStat.Aborted
a.overflowStat.Unlock()
if aborted == 0 {
t.Fatal("应记一次 Aborted")
}
}