mcpField
M
memory-hygiene

memory-hygiene

github.com/huytieuAgent 工作流1.3k134 次安装1 周前更新
代码仓库

关于 memory-hygiene

memory-hygiene 是用于审查 Agent 持久记忆和环境相关知识笔记的技能，适合定期清理或排查错误回忆。它要求依据当前环境核验事实、记录可信度，并将归档或删除留待用户确认。

主要功能

  1. 01扫描记忆与知识笔记
  2. 02分类环境相关声明
  3. 03按条目核验并更新可信度
  4. 04生成审计报告并提出归档建议

适用场景

  1. 01定期检查路径、网址和 ID 是否过时
  2. 02排查错误记忆导致的任务失误
  3. 03修正已核实的过期事实
  4. 04汇总记忆审查变化与待确认归档项

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/huytieu/cog-second-brain --skill memory-hygiene

安装后在 Claude Code 中输入/memory-hygiene确认已加载。

详细介绍

COG Memory Hygiene Skill

目的

防止出现 过时但仍自信 的失效模式：某条记忆或知识笔记在写入时是正确的（“webhook 位于 X”“board ID 是 Y”），环境变化后却悄然过时，但检索时仍排名靠前并被据此采取行动。

系统层面的做法（改编自 “From Model Scaling to System Scaling: Scaling the Harness in Agentic AI”，Gu，UC Berkeley，arXiv:2605.26112）：将信任设为运行时决策，而非存储条目的固有属性。根据实时环境重新验证，并将每条目的 last_verified 和 confidence 保留为一等字段，以便未来检索时权衡可信度。

何时调用

  • /memory-hygiene
  • “Audit my memories” / “check for stale memories”
  • 记忆失效后（检索出的事实被证明有误）
  • 默认频率：每月一次

范围

扫描两个存储位置：

  1. Agent 记忆 — Agent 存储持久记忆文件的位置（例如 Claude Code 的自动记忆目录）。扫描除索引本身之外的所有条目。
  2. 持久知识笔记 — 声明涉及环境信息（路径、URL、ID、工具名称）的 05-knowledge/** 文件。

如果有人提出要求，也可以只做部分扫描（“只检查参考条目”）。

声明分类

将每个条目的声明分为两类：

类别示例操作
依赖环境文件/目录路径、仓库名称、分支名称、频道 ID、board ID、URL、API 端点、cron/例程 ID、CLI 名称、版本号、“X 位于 Y”根据实时环境验证
偏好 / 判断语气规则、格式规则、“绝不做 X”、人物相关事实、策略背景无法进行环境检查；仅验证是否与较新的条目存在内部矛盾

验证操作（先做成本低的）

  • 路径和文件：使用 ls / test -e。条目中提及的技能、命令和 Agent 必须仍存在于指定路径。
  • URL：使用 HEAD/GET 进行解析（curl -sI）；标记 404 或重定向到登录页的情况。
  • 仓库/分支：在成本低时使用 gh repo view、git ls-remote。
  • ID（频道、board、例程触发器）：仅当 MCP/CLI 检查可以通过一次调用完成时才验证；否则标记为 unverifiable-cheaply，并保持置信度不变。
  • 条目间的矛盾：以较新的条目为准；标记较旧的条目。

每个条目的检查时间绝不要超过约 1 分钟。这是维护工作，不是调查。无法廉价验证 ≠ 已过时。

标记

检查条目后，在原处更新其 frontmatter 的 metadata: 块（除非要修复已验证错误的事实，否则不要改动正文）：

metadata:
  type: reference
  last_verified: 2026-07-10
  confidence: high   # high = verified now | medium = unverifiable cheaply | low = partially drifted
  • 验证无误 → 设置 confidence: high，并标记日期。
  • 无法廉价验证 → 保留原有置信度（或设为 medium），并标记日期。
  • 部分过时 → 直接在正文中修复过时事实（可通过报告进行审核）；只有在不确定是否已完整修复时才设置 confidence: low。
  • 完全过时 → 建议归档，不要删除。 在报告的“建议归档”部分列出；只有在用户确认后才归档。

工作循环（参见 /loop-engineering）

按条目列表持续扫描，直至完成，并对每个条目设置预算限制（约 1 分钟）。确定性验证依据是环境本身（test -e、curl、gh），绝不能依据 Agent 对某项内容“理应”仍存在的回忆。需要人工确认：所有删除/归档操作。

报告（单个文件）

每次巡检在 01-daily/YYYY-MM-DD-memory-hygiene.md 中撰写一份报告，围绕四个演进问题展开：

  1. 哪些内容会保留？——按类型统计数量（用户/反馈/项目/参考）。
  2. 更新了什么？——正文经过更正的条目，列出旧内容 → 新内容。
  3. 测量了什么？——评分卡：verified / unverifiable / drifted / propose-archive 的数量，以及与上一份巡检报告相比的变化量（漂移趋势是单次检查无法发现的长期信号）。
  4. 哪些内容可审计？——本次巡检中的每项变更都要在报告中列为一行；对于 Git 不跟踪的存储，报告就是审计记录。

在报告末尾添加 建议归档 部分（明确列出条目，每项附一行证据）；如果有事项需要你决定，则添加一行 等待你决定。

规则

  • 删除/归档仅提出建议；时间戳和已核实的事实更正可直接应用。
  • 巡检期间绝不改写条目的语气或重组其结构。
  • 如果记忆索引指向已重命名/缺失的文件，请修正索引。
  • 不要将巡检本身写入记忆：报告文件就是记录。

评论

支持 Markdown