多人共用 Agent 记忆时，怎样不把“记得住”变成“看得见”？mwe-mcp 的片段级治理方案
给 AI Agent 加“长期记忆”并不难：把对话切片、嵌入、存进向量库，再在下一轮检索回来即可。真正棘手的是共享场景。团队成员、个人助理和编码 Agent 若都访问同一份记忆，某条信息往往既需要被某个 Agent 记住，又不能被另一位使用者读到；而项目决策、待办事项和个人偏好也会随时间失效。
2026 年 7 月发布的 mwe-mcp 是一个自托管的 Rust MCP 服务，试图把这个问题拆成“可读的 Markdown 记忆”和“由引擎执行的事实治理”两层。它采用 AGPL-3.0-or-later，提供单机服务端、内置仪表盘与 HTTP MCP 端点。本文不把它当作普通向量库替代品，而是检查它在多人共享、跨 Agent 和记忆随时间变化时，究竟多做了什么，以及哪些边界仍应由部署者承担。
共享记忆的难点不在检索，而在事实的归属和可见性
一个典型团队场景是：Alice 告诉助手“Bob 换到新项目”，Claude Code 需要在仓库里延续架构决策，另一个家庭或跨团队助手却不应看到人事信息。若仅以“文档”或“会话”授权，常见结果只有两种：要么整页对所有人可见，要么整页都不可见；两种都无法表达“一段页面内有不同读者权限”。
mwe-mcp 的做法是将最终可浏览的内容编译为 Markdown wiki 页面，但将事实的所有者、消息发送者、允许读者、有效期和向量等治理元数据放在同目录的 engine.db 中。README 展示的页面标记只保留稳定键；服务端依据读取者在返回前做片段级脱敏。因此，权限并非由提示词要求模型“不要泄露”，而是在文本交给消费 Agent 之前由引擎裁剪。
这一区分值得重视：Markdown 是人类可审阅的表示，数据库索引才是权限决策的权威来源。 直接复制磁盘上的 wiki 文件、把仪表盘截图丢进其他系统，或让不受控进程读取数据目录，都会绕开 MCP 返回路径上的脱敏。它适合把受控 Agent 接到同一记忆，而不是替代操作系统、备份仓库或网络边界的访问控制。
让“旧事实”退场，而不是与新事实混在召回结果里
长期记忆的另一类故障是过期信息。取消的行程、已完成的待办和被新决定取代的架构选择，如果只追加进向量索引，很容易在相似度检索时再次被当成当前事实。
mwe-mcp 为每个事实维护有效期窗口，并把矛盾、到期和完成视为关闭事件，而不是删除。关闭后的记录仍可保留历史；检索时它们被降权，而不是从世界上抹去。这样，用户询问“当时为什么选 PostgreSQL”与“现在为什么选 PostgreSQL”可以有不同的上下文基础。README 还说明，导入历史消息时可携带各自的语义时间，避免今天导入旧记录后把“明天”错误解释成明天。
这不是自动正确性的保证。自然语言里的“它”“那个项目”“不用了”依然可能指向多个事实。项目的设计选择是在目标不够明确时宁可不关闭；部署时仍应把高风险的撤销、权限变更和生产操作留在独立审批流程里。记忆系统可以提供上下文，不应获得替人做不可逆判断的权限。
先跑起来：单机服务与 Claude Code 连接
项目为 Linux x86_64 和 Apple Silicon macOS 提供安装脚本，启动后在同一个监听端口提供 MCP 和仪表盘。官方 Quick Start 给出的最小流程如下：
curl -fsSL https://raw.githubusercontent.com/Fr4nZ82/mwe-mcp/main/install.sh | sh mwe-mcp serve
首次启动后，在浏览器打开 http://127.0.0.1:8742/dashboard/setup 创建管理员、用户和组，并选择内部 LLM 的运行方式。官方说明支持全本地、混合或 API 模式；预编译版本包含本地嵌入器。对需要可复现构建的团队，源码构建使用 Rust，默认构建可配置外部嵌入服务；带 local-embedder 特性时会包含本地嵌入器。
完成初始化后，README 给出的 Claude Code 接入命令是：
claude mcp add --transport http mwe-mcp http://127.0.0.1:8742/mcp --scope user
这里的 127.0.0.1 是一个重要的默认安全边界：先在本机验证用户、组和页面脱敏是否符合预期，再考虑反向代理或跨主机暴露。不要因为 MCP 是 HTTP 就直接监听公网；若必须远程使用，应另外设计 TLS、身份验证、网络隔离、备份加密和审计保留策略。
还要把“服务端能脱敏”与“端点本身可信”分开看。连接 MCP 的客户端若被恶意插件、提示注入或本机其他高权限进程控制，攻击者仍可能以该客户端已获授的身份发起合法读取；片段 ACL 不会自动阻止这一类身份冒用。实际部署应遵循最小权限：为不同 Agent 配置不同用户或访问令牌，按项目和成员拆分组，不把管理员会话交给日常编码 Agent，并审计哪些客户端能够访问共享端点。对包含个人信息或生产凭据线索的记忆，备份副本也必须采用同等的加密与访问控制。
Agent 需要的不是一长串底层写入 API
mwe-mcp 没有把内部的 wiki_capture、wiki_supersede 等原子操作直接暴露给消费 Agent。它将每轮的常规入口收敛为 wiki_ingest_message：服务端在内部组合召回、归属判断、捕获和有效期处理。读取侧则提供 wiki_read、wiki_search 与 wiki_navigate，并以当前读者身份返回经过 ACL 处理的结果。
这种表面收敛有两个工程收益。第一，Agent 不必自行拼接“先搜索、再判断、再写入、再关闭旧事实”的多步协议，降低不同客户端行为不一致的概率。第二，权限和时间窗口的判断留在服务端，避免每个 Agent 各自实现一套容易漂移的规则。代价也很清楚：服务端内部路由会使用 LLM，项目说明其热路径包含每轮一次内部路由调用，并可选地增加导航调用。对于低延迟、严格离线或成本上限很低的环境，应先做本地压测，而不是只根据“记忆可共享”这一点直接迁移。
夜间整理解决的是可维护性，不是无人值守的可信变更
随着事实累积，页面会出现近重复主题、相对日期和已完成事项。mwe-mcp 将较重的整理放进 REM 周期：确认语义重复、合并近义页面、补充遗漏的完成或矛盾关闭、重新锚定相对日期，并重新编译 wiki 页面。项目称结构调整采用“先执行、后回执”的方式，仪表盘提供回退窗口。
这比每轮对话都做全量整理更利于保持响应路径稳定，但也改变了运维习惯：团队需要定期审阅回执、为数据目录建立快照备份，并在升级前用副本验证。尤其是共享工作区，自动合并“看似相近”的主题可能影响人类的组织习惯。把它当作可回退的维护任务，而不是静默且绝对可靠的清理程序，才是更稳妥的部署方式。
适用判断：何时值得引入这层系统
mwe-mcp 最适合的不是一次性问答，而是同时满足以下条件的环境：多个 Agent 或多个使用者要共享长期上下文；事实需要按读者隔离；旧结论必须保留历史却不能持续污染当前召回；团队希望把记忆以可阅读、可备份的 Markdown 形式保留在自己控制的目录中。
如果只有单一聊天机器人、没有共享权限需求，简单的本地笔记或向量检索可能更轻。反过来，如果需求是跨组织的合规审计、集中身份治理或高可用集群，mwe-mcp 的单机起步形态只是基础：仍需自行补齐部署拓扑、密钥管理、监控和灾难恢复。
它最有价值的启发并非“又一个记忆 MCP”，而是把共享记忆拆成几项可验证的工程约束：谁拥有事实、谁报告事实、谁能看到事实、它在何时有效，以及人类能否读懂并撤回系统所做的整理。先用这组问题审视自己的 Agent 记忆，再决定是否采用具体实现，通常比先选一个向量数据库更不容易走偏。
相关链接