|
|
892247946a
|
fix: staticcheck 24 条存量全部清零（含 4 个真实缺陷）
staticcheck 门接入时把存量设为基线 24 条，本次全部清掉，基线改为 0。
## 生产代码里的真实缺陷（4 个）
### ① memory/fusion.go —— BFS 的 depth 参数形同虚设
for d := 1; d <= depth; d++ {
neighbors, _ := g.NeighbourBlocks(seed.BlockID) // ← 永远是 seed
...
break // ← 只跑一轮
}
三处叠加：循环体末尾无条件 `break`；每层传的还是 `seed.BlockID`；
于是 depth=2 与 depth=3 召回结果**完全一样**。
staticcheck SA4008（"变量在循环条件里从不改变"）正是从这里报出来的 ——
它看出来 `d` 除了打分没有参与寻址。
改成真正的逐层 BFS（frontier 推进到上一层新发现的节点）。实测：
depth=1 → 2 个 [节点0 节点1]
depth=2 → 3 个 [节点0 节点1 节点2] ← 修复前停在这里
depth=3 → 4 个 [节点0 节点1 节点2 节点3]
补判据 `TestBFS召回_层深真实生效`：必须用**链**（n0-n1-n2-n3），
星型在 depth=1 就能召回全部叶子、断不出有没有走深。
变异（改回单层）⇒ 实测红：`★ depth=2 召回 2 个，期望 3`。
### ② nlp/extractor.go —— subjRels/objRels 只写不读
两个切片被 append 了 4 处，但**从未被读取**。三元组的关系类型来自
`relLabel := result.Tokens[vi]`，置信度来自 `result.DepRels[si]`，
与这两个切片无关。删除。
### ③ plugins/cmd/plugin.go —— 配置解析失败会把上限写成 0
if n, err := fmt.Sscanf(s, "%d", &p.maxOutput); err == nil && n > 0 {
} // ← 空分支
直接 Sscanf 到 &p.maxOutput：解析失败时它可能已被写成 0 或部分值，
而空分支无法回滚 ⇒ 配置写错一个字符就把输出上限变成 0
（下游 `maxLen := p.maxOutput` 直接拿它算截断长度）。
改为解析到临时变量、失败时保持默认并记日志。
### ④ cmd/homed/bootstrap.go —— 空的 else 分支
`if err != nil { log } else { }` —— 删掉 else。
## 测试判据里的真实缺陷（3 个）
### ⑤ stop_semantics_test —— 短路求值让第二次调用从不执行
if !a.sched.consumeCancel() || !a.sched.consumeCancel()
第一次返回 true 时第二次**根本不会执行**，于是"两条配额都可消费"
这条断言实际只测了一次。拆成两次独立调用（两处同型）。
### ⑥ seq/store_test —— 永假断言
if maxCallDepth != maxCallDepth { t.Fatal("maxCallDepth 不稳定") }
自己跟自己比，从诞生起就不可能失败。改成显式读两次比较。
### ⑦ pluginhost/catalog_test —— typed-nil 守卫永假
var nb *kstate.SyncBus
var iface kstate.SyncState = nb
if iface == nil { t.Skip(...) } // ← 恒 false
把 typed-nil 装进接口后，接口的 (type, value) 二元组都不为 nil。
这道前置守卫**从未生效** —— 而这正是该判据要演示的陷阱本身。
改用 `reflect.ValueOf(iface).IsNil()`。
## 其余（写法/冗余，无行为变化）
agent.go / context.go / toolresult_store_test / apply_regression_test
空 if 块（注释移到真实分支上方）
codec_chunkfast_golden_test 未使用的三个返回值 + 空 if
scheduler_critical/stack_test `if _, _ = f(); true { }` → 直接调用
overflow_test / upgrade_test 变量被整体覆盖，首次赋值未使用
dense_test m[string(x)] 替代临时变量
lex_rules_test range over string 而非 []rune(string)
## 验证
staticcheck -checks 'SA4*,SA5*,SA6*,SA9*' 0 条（基线 24 → 0）
go build ./... PASS
go vet ./... PASS
gofmt -l 干净
go test ./... -count=1 65 包全过，0 FAIL
干净检出（worktree） build + memory/nlp/core 全绿
|
2026-11-04 19:49:21 +08:00 |
|
|
|
428aad74db
|
fix(seq): 修掉 seq_create 的 O(n²)，并加极端压测
## 起因：1000×1000 压测直接跑爆
用户要求「1000 条序列 × 每条 1000 个组内 toolcall」。第一版跑满 8 分钟超时。
分阶段计时定位到瓶颈：
| 阶段 | 200 条 × 1000 工具 |
|---|---|
| 创建 | **27.0s**（135ms/条，**随序列数线性增长**） |
| 执行（组内 1000 并发） | 0.55s（20 万次调用，2.7µs/次） |
| 删除 | 4.7ms |
瓶颈在创建，不在执行。
## 根因
```go
// handlers.go:70 —— 每次 seq_create 之后
graphErr := p.store.CheckGraph()
// store.go:166 —— List() 全量 + 逐条 Load() 全部序列
```
1000 条各 250KB ⇒ 每次创建都重读 250MB 并反序列化。第 N 条的创建代价
随 N 线性增长，总计 O(n²)。
## ★ 走过的弯路：我一度建议「把校验挪到运行期」—— 那是错的
store.go:163 明确写着：
两条检查（都必须在**建序列/保存**时做，而不是等运行）：
1. 每个 seq_call 的目标必须存在（不存在会在运行期才发现，浪费一整轮）
**校验时机是语义，不是性能旋钮。** 目标不存在若等到运行才发现，模型已经
白白花掉一整轮工具调用。性能问题不能靠挪语义来解。
## 修法：缓存调用边，Save 做 O(1) 增量
```go
// Store 新增
graph map[string][]string // 序列名 → 它调用的目标（裸名）
// Save: 只更新这一条的边
s.graph[seq.Name] = edgesOf(seq)
// Delete: 移除这一条的边
delete(s.graph, name)
```
`callTargets` 只依赖 AST，不必每次从盘重建。**校验语义完全不变** —— 目标
存在性与三色 DFS 环检测都照旧在建序列时执行。
## 判据
- TestStoreGraphCacheKeepsSemantics 逐条钉住三个保证：目标存在性 ✓、
环检测 ✓、删除后不再误报成环 ✓
（这类优化最危险的失败模式是"校验还在跑但少查了某种情况"）
- TestStoreSaveScalesLinearly 分段对比后半程/前半程每条耗时。
★ 判据自己改过一次：初版用「总耗时 ÷ 单条耗时」，而单条只有 48µs 时
噪声占比过高，同一份代码两次跑出 84× 和 203× —— 判据不稳定时报的
失败就是噪声，比没判据更糟。改成分段对比（平方时后半程会慢约 n/2
倍，线性时基本持平），阈值 3 倍留足磁盘与 GC 抖动余量。
实测 300 条：84~203× 单条（线性期望 300×），平方会是 90000×。
## 压测本身也修了两个自己的 bug
- 源文件目录与 store 目录分离时只改了写入侧，清理侧还指着 store 目录 ⇒
报 "no such file"。看起来像文件被提前删了，真因是路径拼错。
- newE2EPlugin 的 runner 参数写死 *e2eRunner，压测换替身就编译不过 ⇒
改为接受 seqRunner 接口。
## 压测规模
TestStressExtreme_ThousandSeqs 现为 1000 条 × 1000 toolcall（O(n²) 修复后
可跑）。判据全是**不变量**：每工具恰好调一次、1000 槽在交错延迟下仍按
声明序合并（并发下若按完成序合并必然错位）、删除后无残留。
|
2026-09-27 15:58:54 +08:00 |
|
