🔗 项目主页：GitHub / iasi777/memauthority
本工具只专注于解决一个主要问题：
踩过的坑不应该再踩一遍，现成的经验总结随取随用
- 用户把关：判断哪些信息真正值得长期留下；
- Agent 执行：理解、检索、归纳、更新与清理记忆；
- MemAuthority 兜底：保证长期记忆的可靠保存和按需读取，防止多版本相互覆盖、内容错乱、异常中断导致记忆损坏。提供多 agent 、多平台共用一套记忆的能力
MemAuthority 适合谁
更看重长期记忆质量的用户
你应该经历过以下的不可控感：
- 不清楚什么内容何时被记下了；
- 不确定什么时候会进入上下文；
- 无法确认内容是否已经过时；
- 想要精确修改或删除时无从下手
你也可能尝试过维护 MEMORY.md ，但随着内容积累，它变得越来越臃肿、杂乱，甚至开始干扰 Agent 的正常判断
MemAuthority 适合的用户：
愿意为记忆质量投入少许精力把关
这里的“花精力”并不需要你频繁手动修改文件，而是在关键节点做几个有价值的高层裁决：
- 某些信息是否值得长期保留；
- 什么时候应该整理记忆；
- 哪些内容涉及隐私或敏感信息；
- Agent 提议整理的结果是否符合你的真实意图
其余机械繁琐的格式整理、分类归档与检索调用，统统交由 Agent 处理
为什么不直接用 MEMORY.md
如果你的项目记忆体量较小、内容极少变动，或者你不想在记忆维护上耗费任何注意力，继续使用 MEMORY.md 是最省心的选择
MemAuthority 聚焦于解决更具体的需求：
把“维护长期记忆”本身，变成一套可靠、可控的工程化工作流
- 按需精准读取：仅在任务真正需要时才加载相关记忆，避免无关信息撑爆或污染上下文；
- 清晰的角色分层：明确区分当前接手状态、长期规则、阶段进展与避坑经验；
- 并发与版本安全：修改前严格校验版本，防止旧的修订静默覆盖新内容；
- 幂等防重保障：网络波动或执行中断时的重试操作，不会产生重复记忆；
- 收敛与历史追溯：活跃记忆库可以随意精简收敛，而完整的修改历史可以由 Git 负责追溯；
- 事务与容灾恢复：写入中断或异常时具备明确的事务日志与恢复机制
如何使用
不需要完全一致的提示词，表达意图即可，你也可以开发自己的独特用法：
1. 开始任务时按需读取
“参考一下这个项目的 MemAuthority ，根据当前上下文按需读取”
Agent 应该选择最短、最合适的读取路径：已知具体位置就直接读取，不知道位置时再检索，需要快速接手项目整体状态时再看 handoff 。如果当前对话本身已经有足够上下文，Agent 不会到 MemAuthority 再复核一遍
2. 精确把关要记录的内容
“把这次任务里值得长期记录的内容列出来，我来决定写哪些”
Agent 提炼候选条目，由你最终决定保留、修改还是舍弃
3. 省心快速记录任务
“记录一下这次任务”
这也是常见用法。默认情况下，Agent 会自行决定需要保存的内容，MemAuthority 保证 Agent 记录内容的下限，上限由模型的能力决定
4. 任务结束后顺手维护
“检查一下这次任务实际用到的 MemAuthority 记忆，根据刚刚发生和核验的事实更新它，并清理过时内容”
刚完成任务的 Agent 掌握最新的代码、工具结果、运行事实和用户裁决。它只需要维护本次真正读取和使用过的记忆，不必每次扫描整个记忆库
5. 暂存未来的想法，释放当前的上下文
“某个值得以后深究的方向，先放到 TODO 列表”
这里的 TODO 不是项目管理工具，而是：未来值得处理，但不应该占据现在工作的注意力
真正完成后，直接删除 TODO 本身；真正形成的长期有效结论，再单独归入长期记忆
如何导入旧的记忆库
只要 Agent 能够读取并理解的格式，就能够进行导入：
- 现有的 MEMORY.md ；
- 通用 Markdown 或纯文本文档；
- JSON 导出文件；
- Prompt 提示词文件；
- 历史交接文档与聊天总结；
- 多份存在冲突的旧笔记；
- 其他任何 Agent 可理解的文本内容
输入意思相近的提示词即可：
“先了解 MemAuthority 的记忆规范，然后检查这份旧记忆库 把仍值得长期保留的内容进行去重、合并、更新和重组；过时、重复、纯流水账、临时和不该长期保存的内容全部剔除，先整理出迁移候选方案，由我确认后再执行写入 ”
MemAuthority 里存的是什么？
长期记忆严格划分为四种角色：
handoff （接手状态）
当前接手该项目必须了解的最小关键状态
它应当保持简短、直接并随项目演进而持续刷新，不会成为冗长的第二份 README
rules （长期规则）
未来 Agent 开展工作仍需遵守的长期决定、架构约束与行为准则
只记录最终的裁决结果，不记录冗长的讨论与争辩过程
progress （阶段进展）
对未来后续工作仍具参考价值的阶段性重要进展
它是最低成本的记录入口，但并非流水账式的永久日志
pitfalls （避坑指南）
未来工作中仍有可能再次遭遇的典型失败模式与防范经验
并非每个普通报错都值得记录
如何避免无用的记忆过多塞进 Context ？
MemAuthority 支持渐进式按需召回：
- 当前对话已经有足够信息时，完全不调用 MemAuthority ；
- 项目不明确时，先定位并确认项目；
- 已知明确 URI 或 Section 时，直接精确读取；
- 已知项目但不知道具体位置时，再在项目范围内检索；
- 需要快速恢复项目整体接手状态时，handoff 通常是最合适的起点；
- Agent 自己判断结果是否相关，只继续读取真正有助于当前任务的内容
Agent 看到的搜索结果是定位坐标，把“需要多少证据才足够”留给正在执行任务的 Agent 判断
MemAuthority 不是历史档案
- 规则调整了，就直接更新规则；
- 状态演进了，就同步刷新状态；
- 内容过时且不再需要，就直接删除
将内容从当前 Memory 中移除，但历史记录依然保存在 Git 中，当然这也决定了其不适合作为大型记忆库
andie 09-03 17:291楼