知识飞轮

解决什么问题

许多 Agent 项目的"知识"是静态的：事实写入 facts 表后就不再更新，trust 权重永远停留在初始值。失败经验的归宿通常是某个日志文件，下次遇到同类报错（比如 API 404 模型不存在）时依然从零排查。Knowledge Flywheel 要解决的就是这种"只进不出"的僵局——让使用行为反哺知识本身。

核心机制：三环飞轮

• 内环（fact_flywheel.py inner，每次运行）：对召回的事实做正向反馈，被实际采用的事实权重更高
• 中环（fact_flywheel.py middle，每次运行）：trust 微调，高频事实 trust↑，零检索事实 trust↓
• 外环（fact_flywheel.py outer，每周）：质量校准，归档长期零检索内容、去重重复条目

故障牵引与可观测

fault_traction.py 接收错误文本（cron 报错、日志路径、except 块内调用或用户反馈"又出问题了"），从教训库匹配已知模式，优先自动修复，失败才上报。pipeline_flywheel.py 负责流水线注册与事件追踪，sync_rules.py 在启动时自动驱动飞轮。健康评估给出五维分数（成功率 40%、延迟 20%、Token 用量 10%、错误分布 15%、Pattern 覆盖率 15%），审计报告输出为 Markdown，包含运行统计与自动建议。

适用边界

• 飞轮写入失败不等于主任务失败：trace 记录失败时只降级提示，不回滚主任务结果
• 报告中的"运行次数"是 trace 记录数，不是 cron 调度次数，两者可能不一致
• 高并发下 trace_store 可能被 SQLite 写锁阻塞，建议 trace 表独立于主事实库并保留 JSONL fallback
• 延迟统计需过滤 latency_ms=0 和数量级异常值（如 >24h），否则均分会完全失真
• 它是流水线级方案：单个脚本级故障应交给 self-fix-loop，两者互补而非相互替代