Oh My KB · L4 持续学习层架构

数据流总览

L0 · 每日
各 skill Critic 审查
产生 PASS / FAIL

→

L1 · 存储
patterns.md
原始记录

↓ 每周日 09:00 蒸馏触发

L2 · 分析
Trace2Skill 模式
并行分析 → 层次归并

→

L3 · 应用
optimizations.md
永久规则 + 回写 skill

涉及文件

数据产生端（5 个 skill 有 Critic）

配置/skills/kb-compile/SKILL.md — Step N: Critic
配置/agents/kb-memory-agent/skills/kb-report-daily/SKILL.md
配置/skills/kb-memory-distill/SKILL.md
配置/agents/kb-finance-agent/skills/kb-invest-report/SKILL.md
配置/agents/kb-finance-agent/skills/kb-report-finance/SKILL.md

存储端

记忆 (memory)/patterns.md — FAIL/PASS 原始日志
记忆 (memory)/optimizations.md — 已升级的永久规则

分析端

配置/skills/kb-memory-distill/SKILL.md — Step A-E
配置/skills/kb-memory-distill/references/distill-strategies.md

L0 · 数据生成（每日，自动）

Skill	Critic 标注	FAIL 写入格式	触发频率
kb-compile	5 项检查	`[compile] ❌ {问题}`	每日 02:00 / 手动
kb-report-daily	4 项检查	`[daily] ❌ {问题}`	每日 22:30
kb-memory-distill	5 项检查	`[distill] ❌ {问题}`	每周日 09:00
kb-invest-report	4 项检查	`[invest] ❌ {问题}`	工作日 09:17/21:15
kb-report-finance	3 项检查	`[finance] ❌ {问题}`	周日 20:00 / 手动

PASS 也记录：Critic FULL PASS 写入 [compile] ✅ PASS (5/5)。新版 L4 不只盯失败——PASS 里反复出现的有效模式同样会被「成功分析师」提取和固化。

L1 · 存储格式

patterns.md（原始日志）

[compile] ✅ PASS (5/5) — 2026-06-09
[daily] ❌ 飞书节仅2条 — 2026-06-08
[invest] ❌ 持仓漏查中芯 — 2026-06-06
[daily] ✅ PASS (4/4) — 2026-06-07
[compile] ❌ 摘要缺数据 — 2026-06-05
[daily] ❌ 信号覆盖77% — 2026-06-03
[invest] ✅ PASS (4/4) — 2026-06-02
[daily] ❌ 飞书节仅2条 — 2026-06-01

optimizations.md（永久规则）

## 2026-06-14（示例）
飞书日报提取不足 → 升级 daily Critic:
信号覆盖门槛从 60% → 75%
基于 3 条独立 FAIL，2 条个例丢弃

## 2026-06-07（示例）
投资持仓漏查 → 升级 invest Critic:
Step 1 硬约束：逐只搜索全部持仓
基于 4 条独立 FAIL，1 条个例丢弃

L2 · 分析流程（每周日 09:00，kb-memory-distill Step A-E）

Step A
收集全量轨迹

读 patterns.md 最近 10 天。分离为 F-（失败集）和 F+（成功集）。不再只看 FAIL。

Step B
并行分析

每条 FAIL → 错误分析师找根因。
PASS 里反复出现的模式 → 成功分析师提取。

Step C
层次归并

≥3 条不同的 FAIL 指向同一根因 → 保留。
1-2 次个例 → 丢弃。
冲突的提案 → 暂缓。

Step D · 自动升级

类型	写入目标
`[compile]`	`kb-compile/references/` Gotchas
`[daily]`	`kb-memory-agent.md` 日报 Critic
`[distill]`	`kb-memory-agent.md` 蒸馏 Critic
`[invest]` `[finance]`	`kb-finance-agent.md` Critic 标准

Step E · 写日志

追加到 optimizations.md，含归并来源和丢弃数量。

蒸馏报告通知用户：
"本周从 X 条记录归并 Y 条规则，Z 条丢弃"

旧版 vs 新版

旧版 · 阈值统计

读 patterns.md → 统计每个 ❌ 出现次数 → ≥3 次 → 升级

✗ 同一个 bug 在 3 次蒸馏里重复标记 = 假阳性
✗ 只看失败不看成功，单向偏差
✗ 个例和系统性问题无法区分
✗ 没有交叉验证——不同 Critic 标同一个标签可能是不同根因

新版 · Trace2Skill 归纳

收集全量 → 并行分析 → 层次归并 → 只升级被多条独立记录验证的规则

✓ 3 条不同的 FAIL 指向同一根因 = 真模式
✓ PASS + FAIL 双向分析，不偏废
✓ 偶发个例直接丢弃，不污染规则库
✓ 冲突的提案暂缓，等下次蒸馏数据更多再判

使用方式 · 一条 Critic FAIL 的完整旅程

1️⃣ 每日 cron 执行 — kb-report-daily 22:30 运行，Critic 发现「飞书摘要只有 2 条，信号覆盖不足」→ 写入 patterns.md: [daily] ❌ 信号覆盖不足 — 2026-06-09

2️⃣ 累积存储 — 这一周内，其他 cron 也各自产生 PASS/FAIL，全量写入 patterns.md

3️⃣ 周日蒸馏 — kb-memory-distill 09:00 触发，Step A 读 patterns.md 最近 10 天，找到 5 条 [daily] ❌ 记录

4️⃣ 并行分析 — 5 个错误分析师并行，发现其中 3 条根因是「飞书摘要读取步骤不强制 Read」、1 条是偶发网络超时、1 条是用户当天没发飞书消息

5️⃣ 层次归并 — 「强制 Read」模式被 3 条独立记录验证 → 保留。「网络超时」和「无消息」各只有 1 条 → 丢弃

6️⃣ 自动升级 — 写入 kb-memory-agent.md 日报 Critic 表：新增一项「Step 3 飞书摘要必须 Read 文件，不得仅检查文件存在」

7️⃣ 写日志 — optimizations.md 追加：「飞书摘要提取不足 → 升级 daily Critic Step 3 → 基于 3 条独立 FAIL，2 条个例丢弃」

8️⃣ 下次 cron — 下周一 22:30 kb-report-daily 执行时，已加载升级后的 Critic 标准，自动强制 Read 飞书摘要，同类 FAIL 不再出现

文件清单速查

文件	角色	谁写	什么时候
`记忆 (memory)/patterns.md`	原始日志	各 skill Critic	每日 cron
`记忆 (memory)/optimizations.md`	永久规则	蒸馏 Step E	每周日
`配置/skills/kb-memory-distill/SKILL.md`	分析引擎	手动维护	架构变更时
`配置/agents/kb-memory-agent.md`	规则接收端	蒸馏 Step D	归并通过后自动
`配置/agents/kb-finance-agent.md`	规则接收端	蒸馏 Step D	归并通过后自动
`配置/skills/kb-compile/references/`	规则接收端	蒸馏 Step D	归并通过后自动

Oh My KB · L4 持续学习层 架构