mcpField
M
MemAuthority

MemAuthority

本地服务
github.com/iasi777记忆与知识67 周前更新

关于 MemAuthority

MemAuthority 是面向 AI Agent 的 Git 支持长期记忆系统,通过 MCP 提供项目记忆的检索与维护。它按角色组织记忆,并以版本校验、幂等写入和事务恢复保护状态。

主要功能

  1. 01按需检索项目记忆
  2. 02区分交接、规则、进度与经验
  3. 03Git 完整修订历史
  4. 04版本校验与重复请求防护
  5. 05事务日志与崩溃恢复
  6. 06检测并阻止高置信度密钥

适用场景

  1. 01让新会话或其他 Agent 接续项目
  2. 02记录并整理任务里程碑
  3. 03查找已知规则和常见陷阱

MCP 相关

作为 MCP 服务,向 Agent 提供项目长期记忆的检索、搜索与维护能力。写入受到角色、版本和完整性校验等机制约束。

配置

本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。

暂未收录安装方式

我们还没有获取到这个服务的安装包或远程地址,请按项目 README 中的说明安装。

代码仓库
安装包
mcpbmemauthority-1.3.2-win-x64.mcpb1.3.2
mcpbmemauthority-1.3.2-win-arm64.mcpb1.3.2
mcpbmemauthority-1.3.2-linux-x64.mcpb1.3.2
mcpbmemauthority-1.3.2-linux-arm64.mcpb1.3.2
mcpbmemauthority-1.3.2-osx-x64.mcpb1.3.2
mcpbmemauthority-1.3.2-osx-arm64.mcpb1.3.2

工具

还没有获取到工具列表

本地服务需要在你的电脑上运行后才能读取工具,维护者暂未提供工具列表。

详细介绍

MemAuthority——面向 AI Agent 的 Git 支持长期记忆系统

中文

MemAuthority 是一个通过 MCP(Model Context Protocol)提供的、由 Git 支持的 AI Agent 长期记忆系统。它能让新会话、另一台机器或另一个 Agent 找回项目积累的上下文并继续工作,而不必重新摸索相同的决策和陷阱。

它不会试图记录每一个细节,而是专注于提炼:

未来的 Agent 不应再从头摸索的经验教训和结论。

明确的职责划分:

  • 你 充当把关者:决定哪些内容真正值得长期保留;
  • Agent 负责执行:理解、检索、总结、更新和清理记忆;
  • MemAuthority 提供安全保障:确保长期记忆可靠,并能按需获取,同时防止过时写入、重复重试和更新中断。

Agent 仍然负责判断内容的含义以及是否应该更改。MemAuthority 则确保保留下来的记忆能够长期保持可靠。


适用对象

MemAuthority 专为重视长期记忆质量的用户设计。

你可能曾在使用各种记忆工具时感到缺乏掌控:

  • 不清楚某项内容被记住的原因;
  • 不确定它何时会被调用;
  • 无法确认信息是否已经过时;
  • 没有简便的方法进行精确编辑或删除。

或者,你可能尝试维护过记忆库,却眼看它随着时间推移变得臃肿杂乱——最终非但没有帮助 Agent,反而令它困惑。

如果你:

希望用最少的精力把关记忆质量,同时将所有日常整理工作交给 Agent。

那么 MemAuthority 很适合你。

“投入精力”并不意味着整天手动编辑文件,而是在关键时刻做出影响重大的决定:

  • 这些信息值得长期保留吗?
  • 什么时候应该检查或清理记忆?
  • 其中是否包含敏感数据或机密信息?
  • Agent 提出的整理方案是否符合你的实际意图?

所有繁重的机械性工作——格式整理、分类、归档和定向检索——都完全由 Agent 负责。


为什么不直接使用 MEMORY.md?

如果项目的记忆内容很少、很少变化,或者你只是不想花精力维护记忆,那么继续使用普通的 MEMORY.md 是最简单的选择。

当这个文件不再只是一份笔记,而是变成未来会话需要信赖的长期项目状态时,MemAuthority 就开始发挥作用了。

它解决的是更高阶的需求:

将长期记忆维护变成可靠、可控且经过工程化设计的工作流。

它提供的远不只是“让 Agent 编辑 Markdown”,而是一套稳健的运行架构:

  • 按需精准加载:仅在任务确实需要时加载记忆,避免无关内容使上下文窗口膨胀或受到干扰;
  • 职责清晰分离:明确区分交接状态、长期规则、里程碑进度和避坑事项;
  • 并发与版本安全:写入前执行严格的版本检查(CAS — 比较并交换),防止旧版本在不知情的情况下覆盖新内容;
  • 幂等与去重:即使因网络故障或运行中止而重试,也不会产生重复记忆;
  • 收敛与完整历史:保持当前工作记忆精简紧凑,同时依靠 Git 保存完整、可审计的修订历史;
  • 事务与崩溃恢复:提供明确的日志记录和恢复机制,以应对写入中断或失败。

一种有用的理解方式是:

Authority 存储未来的 Agent 现在应该继承的状态;Git 存储完整历史。

简而言之:

MEMORY.md 优先考虑简单性;MemAuthority 则优先确保项目发展壮大后,长期记忆依然可靠。


日常工作流

你可以用自然、简洁的指令与 Agent 交互:

1. 在任务开始时按需检索

Agent 会根据实际任务情况判断是否调用记忆,方式类似于使用 MEMORY.md;你也可以指示 Agent 读取特定记忆:

“检查此项目的 MemAuthority——只提取你需要的内容。”

MemAuthority 不强制使用固定的检索方式,因此 Agent 会选择最短、最合适的检索路径:已知位置时直接读取,未知时进行搜索;需要快速了解项目整体交接情况时使用 handoff。如果当前对话已经包含足够的上下文,就完全不必调用 MemAuthority。

2. 筛选值得记住的内容

“列出这项任务中值得长期保留的要点——我来决定保存什么。”

Agent 会提炼候选内容,由你最终决定保留、编辑还是舍弃。

3. 快速、轻松地记录

“记录这项任务。”

这是常见且省力的指令。默认情况下,Agent 会采取保守策略,将其记录为低风险的 progress 条目,而不会自行更改长期 rules。

4. 任务后的维护

“检查这项任务中实际用到的 MemAuthority 记忆。根据刚刚发生或已验证的情况更新,并删除过时内容。”

刚完成任务的 Agent 掌握着最新的代码、工具结果、运行时事实和用户决定。它只需维护自己实际读取并使用过的记忆,无须每次都扫描整个 Vault。

5. 暂存想法以备日后处理,释放上下文空间

“这个方向值得以后探索——把它放到 MemAuthority TODO 里,别让它占用我们当前的上下文。”

这里的 TODO 不是项目管理问题跟踪工具,而是:

一个暂存区,用于存放值得日后重新审视的想法,而不占用今天的认知带宽。

采取行动后,应删除 TODO 条目,并将由此得出的任何持久结论纳入长期记忆。


“记录此任务”——如何避免记忆膨胀?

MemAuthority 不要求你每次想记录内容时,都要斟酌“应该放进规则还是进度”。

当你给出“记录此任务”这类开放式指令时,Agent 的默认行为是:

  • 默认记录到 progress;
  • 仅记录本次会话中已完成的核心交付成果;
  • 仅记录有意义的状态变更;
  • 仅记录后续继续工作所需的关键信息。

默认应主动过滤的内容:

  • 完整聊天记录、对话填充内容和客套话;
  • 细致到逐项操作的行动日志和反复试错的细节;
  • 没有未来复用价值的短暂失败;
  • 知识库中已有记录的重复事实;
  • 临时、过时、敏感或纯属推测的内容。

与此同时,Agent 不会仅仅因为某条内容“听起来很重要”,就将其提升为长期 rules 条目。真正可靠的规则、交接状态和经验教训,应通过实际工作逐步提炼。

MemAuthority 提供的系统级防护措施:

  • 对所有写入内容强制使用标准架构;
  • 根据记忆角色限制修改操作(基于角色的访问控制);
  • 自动扫描并拦截高置信度的机密信息和凭据;
  • 使用幂等机制,防止重试不断堆积重复条目;
  • 使用版本校验(CAS),避免过期版本静默覆盖更新版本;
  • 在提交写入前验证候选知识库的完整性;
  • 支持带日志记录且可在崩溃后恢复的事务。

目标不是“绝不产生一条低质量记录”,而是:

Agent 谨慎记录,MemAuthority 保证底层状态完整性,持续进行的实际工作不断完善并精简记忆。

一致性分为两个不同层面:

  • 语义一致性:由 Agent 维护,将新任务成果与现有知识协调起来;
  • 状态一致性:由 MemAuthority 强制保障,并由 Git Authority、修订版本 CAS、幂等机制和事务日志提供支持。

请记住:progress 是一种低门槛的里程碑记录入口,不是不可变的只追加档案。


如果我已经有 MEMORY.md 或旧版笔记,该怎么办?

无需手动重写所有内容。

对于旧版内容迁移,MemAuthority 采用了一种有原则的方法:

让 Agent 执行语义迁移,而不是为每种旧版格式都构建自定义导入器,将其导入 MemAuthority。

只要 Agent 能够读取并理解你的旧版资料,就可以从任何来源迁移:

  • 现有的 MEMORY.md 文件;
  • 通用 Markdown 或纯文本文档;
  • JSON 导出文件;
  • 系统提示词文件;
  • 历史交接记录和聊天摘要;
  • 存在冲突的多来源笔记;
  • 大模型能够解析的任何其他文本格式。

标准迁移流程:

  1. Agent 学习 MemAuthority 的结构规范和记忆标准;
  2. Agent 阅读旧版笔记;
  3. 对信息进行去重、合并、更新和分类;
  4. 删除过时事实、冗余条目、原始日志、临时笔记和不适合的内容;
  5. 将整理后的内容导出到标准的 MemAuthority 知识库结构中。

你只需这样指示 Agent:

“先阅读 MemAuthority 的记忆规范,再检查这个旧版记忆文件。对值得长期保留的内容进行去重、合并、更新和重构。删除过时、重复的内容、原始日志、临时笔记,以及不适合长期存储的内容。先提出迁移草案供我审核,再进行写入。”

迁移本质上是一项内容筛选决策,而不是机械的复制粘贴。

对于初始接入或大规模迁移,建议使用 v1 工作流:

init (initialize empty vault)
  -> Agent curates vault in detached mode
  -> validate (verify integrity & schema)
  -> Human review
  -> Git commit (commit revision)
  -> managed serve (launch MCP service)

完整指南请参阅 docs/ONBOARDING.md。


MemAuthority 中应该包含什么?

MemAuthority 中的长期记忆严格划分为四种角色:

handoff(交接状态)

Agent 立即接手项目所需的最精简关键上下文。 保持简洁、可执行并持续更新。切勿让它膨胀成第二份 README。

rules(长期规则)

未来 Agent 必须遵循的架构约束、既定决策和行为准则。 只记录已确定的决策,不记录冗长的辩论或历史讨论。

progress(里程碑进展)

与未来工作仍有关联的关键里程碑和状态转变。 这是记录信息时阻力最低的入口,但它不是只增不减的事务日志。

pitfalls(陷阱与经验)

未来 Agent 可能遇到的反复出现的失败模式、不易察觉的陷阱和经过验证的解决方法。 常见错误和偶发的拼写错误不应记录在这里。

一个可靠的判断方法:

了解这件事会改变未来 Agent 的决策、节省大量反复试错,或避免重复犯错吗?

如果不会,它可能就不该进入长期记忆。


如何避免不必要的 MemAuthority 记忆进入对话上下文?

MemAuthority 支持渐进式回忆,但不要求 Agent 遵循固定流程:

  1. 如果当前对话已有足够的上下文,就完全不要调用 MemAuthority;
  2. 如果不清楚是哪个项目,先定位并确认项目;
  3. 如果已知确切的 URI 或章节,直接读取;
  4. 如果知道项目但不清楚位置,就在该项目内搜索;
  5. 如果需要快速了解整体交接情况,通常从 handoff 开始最合适;
  6. Agent 自行判断哪些内容相关,并只读取真正有助于当前任务的内容。

搜索结果是坐标,不是上下文。

目标很简单:不要让无关记忆进入当前对话上下文,并由执行任务的 Agent 自行判断需要多少证据才足够。


多个 Agent 会造成冲突吗?

MemAuthority v1 围绕一项核心原则构建:

多 Agent,单一权威来源。

不同 Agent 或客户端可以轮流读取同一个 Managed Authority 并请求更改,而 MemAuthority 会维护一份单一、线性且确定的版本历史。v1 仍是为单个用户和单个写入者设计的,并非用于团队同时编辑的协作数据库。

如果 Agent A 更新了记忆,而 Agent B 尝试基于过期版本进行修改,MemAuthority 会明确返回冲突并拒绝写入,而不会让过期状态覆盖最新状态。

此时,Agent B 必须重新获取最新状态,并决定是合并、覆盖、中止,还是询问用户。

MemAuthority 不会判断哪种主观看法才正确。它的职责更有限:

明确指出并发冲突,避免不同的编辑悄无声息地让 Authority 变得不正确。


如何避免 MemAuthority 日益臃肿

Git 会忠实记录 Authority 的完整演变过程,方便随时追溯记忆;但 Agent 在实际工作中不会读取 Git 历史,只会读取当前生效的记忆。当前记忆可以自由修改,而 Git 会确保其可恢复:

  • 规则变化时,直接就地更新规则;
  • 状态演变时,更新交接状态;
  • 内容过时且不再需要回忆时,直接删除。

安装

MemAuthority 需要 Git 和 Go 1.26.5 或更高版本。使用以下命令安装当前稳定版:

go install github.com/iasi777/v-memory/cmd/[email protected]

为保持兼容性,v1.x Go 模块的标识有意保留为 github.com/iasi777/v-memory,尽管规范仓库和产品名称现为 MemAuthority。GitHub 会将原仓库 URL 重定向至 iasi777/memauthority。

验证:

memauthority version

预期输出:

memauthority 1.3.2

现有自动化流程可以继续安装并调用兼容可执行文件:

go install github.com/iasi777/v-memory/cmd/[email protected]
v-memory version

目前尚未发布预构建的版本二进制文件。若要从源代码检出版本构建:

go build -trimpath -o ./memauthority ./cmd/memauthority
./memauthority version

发布 CI 会在 Linux、macOS 和 Windows 上运行测试套件、vet 和原生 CLI 构建;Linux CI 还会验证生产环境的 Linux/ARM64 目标。


入门

1. 初始化空保险库
memauthority init ./vault
2. 入门配置与整理

引导新保险库或迁移大型旧语料库时,让拥有文件和 Git 权限的 Agent 阅读: docs/AGENT-GUIDE.md

整理完成后,验证保险库:

memauthority validate ./vault
3. 提交并启动服务

检查更改,将其提交到 Git,然后启动托管 MCP 服务:

memauthority serve \
  --vault /absolute/path/to/vault \
  --state-dir /absolute/path/to/state \
  --write-enabled
  • 省略 --write-enabled 时,服务将以只读模式运行;
  • state-dir 必须位于 Vault Authority 目录之外;
  • 不要同时混用分离模式(直接编辑文件)和托管模式(运行服务);
  • 当保险库没有已注册的运行时,可选的声明式运行时元数据默认关闭。大多数单机用户应保持关闭。已有 runtime_resource 的保险库会自动启用运行时工具;仅当你有意开始记录工作/部署拓扑时,才使用 --runtime-enabled。

对于本地设置,最简单的方法是让 MCP 客户端通过 stdio 直接启动该命令。

连接后,MemAuthority 会自动向 Agent 提供工具定义、输入架构、注释和资源元数据。在日常托管运行期间,无需向 Agent 重新解释参数架构。

有关跨领域使用指南(按需回忆、审慎记录、角色选择和旧版迁移),请参阅 AGENT-GUIDE.md。

若通过 HTTP 传输公开服务,请务必先查看 SECURITY.md 和已冻结的 v1.3.2 传输/身份验证规范。

构建与验证

go test ./...
go vet ./...
go mod verify
go build -trimpath -o ./memauthority ./cmd/memauthority

基准测试

MemAuthority 维护着一套公开、可审计的基准测试套件,用于验证真实 Agent 工作负载下的跨会话记忆可靠性。

最新测试活动:变更可用性回归(2026-09-08)

handoff-pending-01 — 跨会话项目交接与待办工作跟踪

指标结果
总运行次数30/30 PASS
总会话数90/90 PASS
变更操作共 426 次
变更错误2 次(0.5%)
人工语义审查30/30 已确认
独立审计Claude Opus 5,置信度 HIGH

测试的 Agent 技术栈(每种 10 轮):

  • Codex CLI + GPT-5.6 Sol:10/10 次运行,0/136 次变更错误(0.0%)
  • Codex CLI + GPT-5.6 Luna:10/10 次运行,0/138 次变更错误(0.0%)
  • Pi Agent + Gemini 3.8 Flash:10/10 次运行,2/152 次变更错误(1.3%,均已恢复)

关键发现:所有受测 Agent 技术栈都成功在完全独立的会话间保留并恢复了项目状态。修正后的变更错误率为 0.5%(2/426),表明 API 易用性很高。

审计说明:原报告称有 18/426 次错误。经全面分析 MCP 日志后,修正为 2/426 次。两次错误均发生在同一次运行中,涉及同一工具和同一验证问题。Agent 成功恢复。方法说明请参阅审计文档。

📊 完整结果:benchmark/results/mutation-usability-regression/
📋 基准测试规范:benchmark/ | 完整文档
📦 下载证据:GitHub Releases(30 次完整运行,含全部产物)


公共契约

当前公开兼容性基线为 v1.3.2。此前发布的契约快照保持不变。

Vault 存储格式、MCP 工具、Managed 运行时行为、变更/拒绝规则、安全边界、传输/身份验证行为及兼容性政策的权威定义,均维护在 docs/contract/v1.3.2/ 下。

本 README 和用户指南仅作说明;若细节不一致,以版本化契约为准。

版本

memauthority version
memauthority --version

AI Agent Memory、Long-Term Memory、MCP Memory Server、Git-backed Memory、Agent Memory Infrastructure、Agent Continuity

对于 v1.3.2,主命令会打印 memauthority 1.3.2;兼容性命令会打印 v-memory 1.3.2。

安全

通过 HTTP 传输公开服务前,请务必阅读 SECURITY.md。

  • 默认禁用写入权限;请使用 --write-enabled 显式启用;
  • HTTP 变更必须严格遵守冻结版 v1 规范中的 OAuth 和安全要求;
  • MemAuthority 内置高置信度机密扫描功能,但不能替代全面的机密检测工具。

相关文档

社区

MemAuthority 感谢并支持 LINUX DO 社区。

许可证

根据 Apache License 2.0 发布。详情请参阅 LICENSE。

归属和第三方声明记录在 NOTICE 和 THIRD_PARTY_NOTICES.md 中。

评论

支持 Markdown

第一次接触 MCP?

从协议是什么,到在客户端里装上第一个服务,这几条回答覆盖了大多数入门问题。

一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。