jingxuanc/quant-agent-skills/memory-health

记忆库体检

何时使用

命中以下任一话术（大致意思即可，不必逐字相同）：

• 我的记忆库怎么样？里面都记了些什么？
• 我记录了多少条？攒了多少经验了？
• 清理一下错误的记录 / 有没有记错的？
• 我之前那些预测准吗？命中率多少？
• 我是不是记了两条自相矛盾的结论？
• 帮我的记忆库做个体检。

不适用：用户想查某一段具体的历史经验（那是检索任务，直接用 causal-memory-search_causal / causal-memory-search_memory，不必走本技能的完整体检链路）；用户要针对某只标的做买卖判断——那是研究/交易任务，本技能只管"记忆库本身健不健康"。

核心机制

记忆库和仓位一样需要定期盘点：记脏了不如不记。这个技能做的事就是"体检 + 校准 + 清理"，分三层：

第一层：看存量（有哪些经验）

• causal-memory-causal_directory 拉最近决策目录，一眼看清"我最近到底记了什么、有多少条"。
• 这一步只读不写，回答"我记录了多少"。

第二层：看质量（预测准不准）

• causal-memory-prediction_report 给的是校准报告：历史 counterfactual 预测命中率、分方法命中率、分任务命中率，以及还悬着没结算的预测。
• 命中率低不代表记忆库坏了，只说明"某类任务的预测需要打折看"——这是校准，不是删库。

第三层：看一致性（有没有矛盾、有没有记错）

• causal-memory-search_patterns 找跨任务模式，重点是 contradicts（互相矛盾）与 repeated（重复记录）两类边。
• 矛盾也要分层处理：

1. 只是新证据覆盖旧证据 → 走 causal-memory-resolve_updates（先 apply=false 预览，让用户决定是否落地）。
2. 确认是记错了（笔误、张冠李戴、结论本身错） → 走 causal-memory-invalidate_decision 软失效。

写记忆的时机（本技能里唯一会写库的地方）

• 体检本身默认只读，不产生新记忆。
• 只有当用户明确要求清理某条记录时，才写：resolve_updates(apply=true) 或 invalidate_decision(edge_id, reason)。
• 体检结束后若发现某条旧结论被用户当场确认"错了"，用 causal-memory-record_decision 记一条新结论把这次校准也留下来（同一条 decision 文本重记真实结果，形成更新证据）。
• 软失效是可审计的：边还在库里，只是不再出现在检索结果里。所以宁可软失效，不要真删。

工具链

第 1 步：拉目录，先看存量（只读）

• 调 causal-memory-causal_directory，参数：limit（默认 20，用户想看全量就给 50-100）。
• 产出：最近决策清单（decision 摘要 + task_tag + 结果是否已回填）。
• 判断：有没有大量 outcome 还停在"待验证"——被记为待验证但从未回填的，是记忆库最常见的"垃圾堆积"。

第 2 步：看预测校准（只读）

• 调 causal-memory-prediction_report，无需参数。
• 产出：整体命中率、分方法命中率、分任务命中率、待结算预测数量。
• 读法：
• 命中率显著低于 50% 的 task_tag → 在报告里标"该类判断历史可信度低"。
• 待结算预测很多 → 说明"记了预测却没人回填"，提醒用户及时回填。

第 3 步：找矛盾与重复（只读）

• 调 causal-memory-search_patterns，参数：query（可留空先看全量，或填用户关心的主题）、必要时带 task_tag、limit（默认 10，矛盾多就给 20-30）。
• 重点看两类边：
• contradicts：两条结论互斥 → 进第 4 步。
• repeated / similar_to：同一件事反复记 → 提示可合并，但不自动删，交给用户判断。
• 若用户关心某个具体主题的矛盾，配合 causal-memory-search_causal（query=主题）确认两边原文，不要只看 pattern 标签就下结论。

第 4 步：预览矛盾处理方案（只读，零写入）

• 调 causal-memory-resolve_updates，参数：limit（默认 20，一次别处理太多）、`apply=false`（必须！这是预览模式）。
• 产出：候选矛盾对 + LLM 判定"新证据是否证伪旧结论 + 建议软失效哪一条"。
• 把预览结果摆给用户确认，不要自己直接 apply=true。用户说"确认处理"才执行。

第 5 步：落地处理（写记忆，需用户确认）

• 5a. 只是过期、被新证据覆盖 → 调 causal-memory-resolve_updates，参数 apply=true（沿用第 4 步的 limit）。软失效的旧边会标注"被纠正"，历史仍可审计。
• 5b. 确认是记错了 → 调 causal-memory-invalidate_decision，参数：edge_id（第 3/4 步拿到的边 id）、reason（必填，写清为什么错，例如"当时把 sh600183 的结论误挂到了 sz002916 上"）。不带 reason 的失效半年后没人看得懂。
• 5c. 收尾补记 → 若本次体检产生了新的稳定认知（例如"某类任务的预测历史命中率低，需打折"），用 causal-memory-record_decision 记一条，参数：decision（"对该类预测统一打折处理"）、outcome（"体检显示命中率 xx%，校准后不再直接采信"）、relation（一般 enabled 或 no_effect）、task_tag（如 memory-health）、context（写清体检时间与样本区间）、confidence_source（rule 或 user_feedback）。

回填时机（记忆库能不能用，全靠这一步）

• causal-memory-record_decision 允许先记"决策"，outcome 暂写"待验证"。
• 回填规则：等结果真的发生了（隔日、隔周、或复盘时），用同一条 `decision` 文本再记一次，这次 outcome 写真实结果。同 task_tag + 同 context 会被识别为同一世界下的可比分支，counterfactual 才有证据。
• 每次体检都要检查"待回填"队列——第 1 步目录里 outcome 还是"待验证"的那些，主动提醒用户。

输出格式

固定输出一份 「记忆库健康报告」，包含以下小节：

1. 体检结论（2-3 句）：一共积累了多少条决策、整体预测命中率大致在什么水平、发现几处矛盾/疑似错误。
2. 存量盘点

• 决策总数 / 最近 N 条目录摘要（decision | task_tag | 结果状态）
• 按 task_tag 分布（哪类任务记得多）
• 待验证、未回填的条数（这是最重要的一个数）

1. 预测校准

• 整体命中率：xx%（样本 n=xx）
• 分方法命中率表：方法 | 命中率 | 样本数
• 分任务命中率表：task_tag | 命中率 | 样本数（标出明显偏低、需打折的类别）
• 待结算预测：xx 条
• 明确注明：命中率是历史统计，样本小的时候波动大，不代表未来。

1. 矛盾与重复清单

• 表：边 id | 类型（contradicts/repeated/similar_to）| 涉及结论 | 建议动作（soft-invalidate / 合并 / 保留）
• 每条标注"待用户确认"。

1. 待清理项（确认后执行）

• 列出准备 resolve_updates(apply=true) 或 invalidate_decision 的具体条数与 id，并写明为什么。
• 执行前必须有一次用户确认；报告里先给"预览版"。

1. 维护建议（仅流程，不含交易建议）

• 例如"有 12 条待回填，建议复盘时补齐"、"某 task_tag 命中率偏低，采信时打折"。

1. 口径说明：体检时间、目录 limit、pattern 检索的 query、resolve_updates 是否已 apply。

记忆价值

用久了会积累出三样别人没有的东西：

1. 一张可信度地图：哪些类型的判断历史上准、哪些不准，一目了然。以后看到系统给某个信号，你知道该打折还是直接采信。
2. 一个会自动纠错的库：矛盾的结论被软失效、错误的记录被标注原因，检索出来的都是干净证据，而不是新旧混杂互相打脸。
3. 一条可审计的决策链：每次"决策 → 结果 → 回填"都留痕，几个月后回头看，能复现当时为什么那么想、后来验证成什么样。这是复盘和参数调优最贵的原料。

反过来，不回填的记忆库等于没记：只有 decision 没有 outcome，counterfactual 拿不到证据，命中率永远是空的。坚持回填，是这套系统产生复利的前提。

合规边界

• 本技能只做记忆库运维：统计、盘点、校准、软失效。输出的是历史统计与流程建议。
• 不输出买入/卖出建议，不出现"建议买/卖某某""该加仓/该止损"这类指令性表述。
• 不输出目标价、涨跌幅预测点位、收益承诺、胜率承诺。命中率只能表述为"过去 n 次记录中 x 次正确"的历史事实，不能表述为"下次也会准"。
• 发现某类预测命中率低，只能提示"历史上该类判断可信度偏低，采信时需打折"，不能反向推导出交易动作。
• invalidate_decision / resolve_updates 属于修改记忆的操作：一律先预览、说明原因、取得用户确认后再落地，不静默删改。
• 涉及具体标的的矛盾结论，只说明"两条记录互斥、其中一条被新证据覆盖"，不判断哪只票更好。

常见问题

1. `resolve_updates` 千万别直接 `apply=true`：它会让 LLM 判定并真实写库。默认流程永远是"先 apply=false 预览 → 把候选摆给用户 → 用户确认 → 再 apply=true"。一次 limit 别超过 20，避免一口气改掉一堆记忆。
2. 矛盾 ≠ 错误，不要见矛盾就删：市场环境变了导致旧结论过时，属于正常更新，走 resolve_updates 的"被新证据覆盖"路径；只有确认是记录本身错了（张冠李戴、笔误、推理硬伤）才用 invalidate_decision，而且 reason 必须写清，否则半年后无法审计。
3. 命中率样本太小就别下结论：n=3 的 100% 命中率毫无意义。分任务表里样本数低于 10 的行要标注"样本不足，仅供参考"，不要拿它去给整个任务类别定性。