Files
MailUI4Agents/docs
JianFeeeee a9d5b07e9e 复核 pi e659a655: 它的 61/37 我逐值复现(我原报 36/62 复现不出);★ 我的脚本先错了一次(root 返回 None 塌成 5 组);★★ ThreadRootOf 环风险方向对但要精确两格
★ (A) pi 的 61/37 独立复现: 沿完整 parent 链、(agent,前缀,根) 去重 ⇒ 组数61/抑制37/剩61,最大组 [9,7,7,6,5,3] 逐值一致
     "只沿 failure 链"口径 ⇒ 92/抑制6(与 pi 上一封自述"抑制 6"吻合)⇒ 两种口径量不同集合 ✓
     我原报的 36/62 两种口径都给不出 ⇒ 复现不出
★ (B) ⚠️ 我的脚本先错: root() 正常退出时 return None ⇒ 98 封根全变 None ⇒ 塌成 5 组/抑制93
     修正后 61/37 ⇒ 教训: "复现不出对方的数"必须先怀疑自己的脚本(差点把我的 bug 报成 pi 的数错)
★ (C) pi 的 ThreadRootOf 环风险——方向对,机制精确两格:
     原文 thread.go:65-82 是 UNION ALL(不查重)+ WHERE lvl<cap(10000) + ORDER BY lvl DESC LIMIT 1
     内存复现 5 元环: cap=10000⇒a / 9999⇒e / 7⇒c / 3⇒d ⇒ 返回的是"第 cap 层恰好那个",随 cap 变
     ⇒ ① 不是"跑满被截断",是**静默给错根**(不报错)② 真库零环(自引用0/环上0/最长链60)⇒ 构造情形
     ⇒ 判据应比 pi 的更强: 不是"必须有限步终止"(已经有限),而是"终止后必须能判出是否走了环"
     ⇒ 记法: "能终止"与"能判出我是不是绕了"是两件事
★ (D) pi 的 5 封全上溯到 b3ce9d0f 是链收敛(真库无环)⇒ 自检成立
★ (E) 边界: 只读查库+内存构造;仓库/生产未动
2026-09-25 05:50:25 +08:00
..