实测（2026-10-13，本机空闲，活库 cyrene/user 分区 201 条、均长 34.7 汉字）： - 一条入库审查召回链 = 51 个「4 条」请求 = 23.070 / 21.860 s；旧审查预算 20s 比链长还短 ⇒ 每一条候选满额的审查都超时，且超时后 **一行留痕都不写** （7 天里 92.1% 的审查 recall_mode 为空、2274 条超时降级的根因） - 同一条链改成「8 条」= 26 个请求 = 21.435 / 21.597 s：请求数减半，墙钟几乎不变 —— 链路耗时由「条数 × 每条成本」主导，批次只改请求数 - 「16 条」在**真实代码路径**上 3 次里 2 次让单请求越过 5s 单次超时（1.818 / 5.016 超时 / 5.001 超时）⇒ 批上限不越过 8；隔离测量里 12 条 0.996~1.017 s 仍在界内 改动： - embedding: perItemBudget 500ms→300ms（实测摊销 70~107ms/条的约 3 倍） ⇒ DefaultBatchLimit 由 (5s/2−100ms)/300ms = **8**，同一套推演、两维都成立 （条数 100ms+8×300ms=2.5s；字符 100ms+480×5ms=2.5s，均在超时的一半内） - embedding: 新增 maxSafeBatchLimit=12（实测外沿）+ 编译期断言（越界即 uint 溢出、 编译失败），与 tidy_config.go 那条同手法 - memory: defaultReviewTimeout 20s→**90s**（> 实测最坏链：空闲 21.6s⇒4.2 倍余量、 与整理链并发 56.7s + T1 8s ⇒ 1.4 倍；不再大的理由=单 worker 有界队列 256 的 最坏积压 256×90s≈6.4h、服务真挂死时第一片 5s 就降级用不到这条预算） 测试（不留过时断言）：budget_test.go 加「钉值 8/480 + 两维不等式 + ≤12 外沿 + 16 条必须仍判越界」四层；api_url_test.go 的 reviewBudgetRef 20s→90s； preinsert_recall_test.go 新增跨包断言「预算 > 实测最坏链 + defaultT1Timeout」。 变异自证：perItemBudget 回 500ms ⇒ 钉值断言红；reviewTimeout 回 20s ⇒ 跨包断言红； perItemBudget 150ms（⇒16）⇒ 编译失败（constant -4 overflows uint）。三者均已逐字还原。 遗留（如实登记，未修）：① 整理轮每轮重嵌整个分区（user 一轮仍 250 个请求）， 解法方向是复用已入库的 vec_items 或给整理轮一个 embedding 请求预算；② 链路对单点 慢分片没有韧性 —— 一个分片失败即整条 Embed 失败、丢掉其余分片的工作量，且实测 任何批次形状都会偶发 >5s 尖峰（4 条 7.139s / 8 条 9.711s，与批次无关），方向是 重试/分片级容错，调常量解决不了。
【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 无该文件权限，由我按其代码语义补写）。
AskaEth
AskaEth
AskaEth
AskaEth