AskaEth
6e28b38b08
【MT-A：护栏 + 诚实截断 + 试算异步】
- maxTidyCompareItems 400(写死)→2000 并开放为 MEMORY_TIDY_COMPARE_LIMIT；
MEMORY_TIDY_CANDIDATE_LIMIT 默认 20→200（语义不变，仍每分区）
- 依据是首跑实测：459 条的分区被 400 截断 ⇒ compared(705) < scanned(784)，
候选数(77)由上限而不是规则决定；三处上限的 WARN 都补齐了总数/上限/分区名
- 新增「上限 + 时间预算」双闸（实测 2000 条/分区 ≈234s > 3 分钟墙钟）：
整分区跳过 / 两两比对中途收手，一律如实记 (budget) + WARN
- ?async=1 ⇒ 202 {runId,status}；GET …/{runId} 轮询（writeAuth 同档）；
done 的 result 与同步 data 逐字节同形；并发=复用既有 runId、TTL 30min 自完成起算、
重启即如实 404 tidy_run_not_found；不带 async 时同步路径逐字不变
【MT-B：D3 入库前审查（design/23 §15.1）】
- 新记忆经 Store.Add（仓库里唯一 INSERT INTO memory_items）落库后，由独立记忆管理
会话（sess-memorytidy）在有界后台队列异步判定 skip/merge/modify/create
- 软合并回写（status + merged_into/merged_from/merge_count，可 revert、绝不改 content）
- 隔离来源（群聊/陌生人）**概不审查**、召回/超时失败**零改写**（fail-safe 结构性成立）
- 写入侧仅 +62.7µs/条（非阻塞入队）；默认 ENABLED=true（主人裁定：入库前先审查）
【耦合说明（重要）】两片同包且互相依赖：MT-B 的 preinsert_recall.go 用 MT-A 的
collectTidyPairs 新签名 + tidyBudget ⇒ **各自单独都 build 不过**，故一并落地。
MT-A 为让整包编译，最小幅度适配了 MT-B 的 preinsert_recall.go / preinsert_test.go
（零值预算=行为不变；符号重名改名）。
【我的验收】隔离 worktree（37 文件）build/vet/linux/darwin 全过，切片包全绿；
我亲手打红两个变异：① 去掉 (compare) 截断标记 ⇒ TestTidyCompareLimit_HitIsLoud 红；
② 中和隔离来源守卫 ⇒ TestReviewRestrictedSourceIsNeverTouched 红。
唯一红是 internal/runtime/tool 的两条超时用例（该包无人改）⇒ 主仓库 -count=8 全绿，
判定为负载敏感 flake（当时两个整树验收 + 子代理并发），已记入开发习惯与约定 §7。
.env.example 补 MEMORY_REVIEW_* 四键（MT-B 无该文件权限，由我按其代码语义补写）。
52 lines
2.5 KiB
Go
52 lines
2.5 KiB
Go
package config
|
||
|
||
import (
|
||
"fmt"
|
||
"reflect"
|
||
)
|
||
|
||
// MemoryReviewConfig 是 D3「入库前审查」（design/23-记忆整理与去重 §15.1 D3）
|
||
// 在配置层的旋钮：新记忆落库后，由独立的记忆管理会话异步判定它是
|
||
// merge / modify / create / skip。
|
||
//
|
||
// 为什么用独立加载器而不是挂进 Config 根结构：Config 由 Load 统一解码，而
|
||
// 本切片刻意**不碰** Config / 记忆整理那组键（并行切片正在改它们）。这里复用
|
||
// 与 LoadLLMDefaults 同一手法（parseDotEnv + 同一份 `env:"…"` 解码器），
|
||
// 因此优先级与 Load 逐字一致：进程环境变量 > `.env` > 标签默认值。
|
||
// envPath 为空表示不看 `.env`（与 Load 的约定一致）。
|
||
type MemoryReviewConfig struct {
|
||
// Enabled 是入库前审查总开关，默认 true。依据：主人 2026-10-05 的裁定
|
||
// 就是「入库之前先走记忆管理会话审查，而不是反复新建」，而 T0 判定是
|
||
// **纯规则、零模型调用**，默认开启是安全的增量。置 false 时组合根不建、
|
||
// 不接、不跑 —— 写入路径行为逐字回到本次改动之前。
|
||
Enabled bool `env:"MEMORY_REVIEW_ENABLED" default:"true"`
|
||
// QueueSize 是有界审查队列的长度。队列满时该条**不做审查**：记忆本身
|
||
// 早已落库（绝不因队列满而丢记忆），只记一条带来源的 WARN。
|
||
QueueSize int `env:"MEMORY_REVIEW_QUEUE_SIZE" default:"256"`
|
||
// ScanLimit 是每次审查在同一分区内最多看多少条既有记忆（top-K 上限，
|
||
// design/23 §15 D3-4「每条待写记忆的审查有界」）。
|
||
ScanLimit int `env:"MEMORY_REVIEW_SCAN_LIMIT" default:"200"`
|
||
// TimeoutSec 是单条审查的墙钟上限（秒）。超时 ⇒ **不做任何改写**，
|
||
// 记忆照旧保留 + WARN（design/23 §15 D3-5 的 fail-safe）。
|
||
TimeoutSec int `env:"MEMORY_REVIEW_TIMEOUT_SEC" default:"20"`
|
||
}
|
||
|
||
// LoadMemoryReviewConfig 读取入库前审查的旋钮。非法（负数）值不在这里报错，
|
||
// 而是与项目其它旋钮同一口径 —— **≤0 视为「用默认」**，由 memory 包 normalize
|
||
// 收敛，避免一个笔误让进程起不来。
|
||
func LoadMemoryReviewConfig(envPath string) (MemoryReviewConfig, error) {
|
||
fromEnv := map[string]string{}
|
||
if envPath != "" {
|
||
m, err := parseDotEnv(envPath)
|
||
if err != nil {
|
||
return MemoryReviewConfig{}, fmt.Errorf("config: read %s: %w", envPath, err)
|
||
}
|
||
fromEnv = m
|
||
}
|
||
var cfg MemoryReviewConfig
|
||
if err := decodeValue(reflect.ValueOf(&cfg), fromEnv); err != nil {
|
||
return MemoryReviewConfig{}, err
|
||
}
|
||
return cfg, nil
|
||
}
|