8.0
热点
AI SCORE
技术实践2026-08-22 04:27
AI Agent 记忆为何成为黑盒及改进实践
dev.to · AI#AI Agent#MCP#Memory
Editor brief · 编辑速览
分析 AI 记忆只做召回（向量检索）而忽视溯源、所有权、更新和冲突等问题，并介绍通过 MCP 协议提供可治理记忆的项目 Managed Memory Workspace。
大多数 AI 记忆演示都以同一个令人满足的时刻开始。
你在一个会话中告诉 agent 某些信息。开启另一个会话后，agent 记住了它。
这种感觉就像成功了——直到你提出下一组问题：
这个事实从何而来？
哪个用户、项目或工作区拥有它？
记忆创建后，来源是否发生过变化？
当两个来源不一致时怎么办？
我能删除它并验证它真的消失了吗？
到了这一步，"agent 记住了"已经远远不够。
我一直在一个名为 Managed Memory Workspace（简称 MMW）的项目中研究这个问题。这是一个早期系统，通过 Model Context Protocol（MCP）向 AI agent 提供受治理的记忆。
这篇文章不是某个成熟 SaaS 的发布公告。MMW 正在公共预发环境中运行，但没有生产级 SLA、企业合规声明或付费客户。我现在写它，是因为有了真实实现可以测试，agent 记忆的困难之处变得更容易讨论。
常见的捷径是把记忆当作检索问题来处理：
将文本转为 embedding。
存入向量数据库。
之后搜索相似文本。
将结果放回模型上下文。
这可能有用的，但检索只是记忆的一部分。
相似性结果不会自动告诉你返回的事实是否属于当前租户。它不会告诉你来源是否被修订过、是否有人检查过该记录、是否存在相互冲突的事实。它也不会给你审计跟踪或可靠的删除工作流。
这些都是数据管理问题，而非模型问题。
这个区别很重要，因为 agent 可以从错误的记忆中生成流畅的回答。即使记录来自另一个工作区、丢失了来源、或在数周前已过时，输出仍可能看起来合理。
我开始设计 MMW 时基于一个不同的假设：
一条被记住的事实是一条有生命周期管理的记录，而不是一段匿名的文本块。
在 MMW 中，一条记忆记录可以携带超出其内容本身的更多信息。有用的上下文包括：
确切的 schema 会随着产品发展而改变。重要的是这些属性是显式的。它们不应该在出问题之后才从 prompt 中重建。
这引出了一个简单的操作循环：
remember -> search -> validate -> forget
remember 存储一条有作用域限制的记录及其溯源信息。
search 在授权边界内检索记录。
validate 允许系统或操作员在来源被检查时更新记录状态。
forget 执行受控删除，而不是让模型在未来忽略某些东西。
这些名字是刻意朴素的。硬骨头在于每个操作周围的边界和证据。
当每个 agent 框架需要不同的集成方式时，记忆的可移植性就会降低。一个团队也可能在存储的知识应该消失之前很久，就更换模型、agent 运行时或托管环境。
MCP 给 MMW 提供了一个 agent 和记忆工作区之间的中立契约。
一个 MCP 兼容的客户端连接到一个项目作用域的端点。客户端收到一个 MMW 凭证，服务器决定哪些原生记忆操作和下游工具在该项目内可见。
预期的关系是这样的：
AI agent
|
| MCP + project credential
v
MMW project boundary
|-- native memory tools
|-- provenance and lifecycle state
|-- payload-free audit metadata
`-- curated downstream MCP tools
记忆应该能承受模型或客户端的更换，而不丢失其所有权和溯源规则。
MCP 本身不解决治理问题。它给系统一个一致的地方来强制执行治理。
一旦 agent 可以使用多个 MCP 服务器，另一个问题就出现了。每个下游服务器可能有自己的 token、工具名称、权限、限制和失败模式。
将每个下游凭证直接传递给每个客户端会产生很大的信任面。工具名称可能冲突。一个宽松的服务器可能暴露超出当前工作流所需的能力。审计记录可能意外捕获请求或响应载荷。
因此 MMW 在 pilot 中包含了一个 MCP Gateway。
当前设计刻意收窄：
第一个真实的连接器是 GitHub 只读。它暴露三个白名单工具：
github_readonly.get_file_contents
github_readonly.get_me
github_readonly.pull_request_read
GitHub token 保留在服务端。MCP 客户端只收到 MMW 项目凭证。
这比接受任意服务器 URL 和任意 header 的灵活性要低。这是 pilot 的有意权衡。我宁愿测试一个我能解释的小策略，也不愿意发布一个开放代理然后称之为平台。
网关不应该让原生记忆系统依赖每个已连接的服务。
当下游 MCP 超时或变得不健康时，其命名空间工具应该以受控方式失败。原生命令如 remember 和 search 应该保持可用。
MMW 记录网关调用的工具标识、状态、时间和大小时序元数据。它不在审计记录中存储下游参数或响应载荷。
这不能消除所有隐私或安全风险。它减少了复制到操作日志中的敏感材料量，这对早期 pilot 是一个有用的默认做法。
MMW 尚未使用我想要的成熟系统的检索栈。当前的搜索路径仍是早期实现。Embedding、重排、评估数据集和更高级的摄取工作仍在前面。
这不是隐藏在模糊路线图后面。它是当前产品边界的一部分。
我选择在优化语义检索之前研究租户隔离、溯源、删除、审计、密钥处理和失败隔离。如果把一个复杂的检索器挂在不清晰的所有权规则上，会让系统在演示中更有说服力，却不会让操作更安全。
这个序列可能不适用于每个记忆产品。这是我能替 MMW 辩护的序列。
当前的预发版本已经通过一个一次性公共 pilot 生命周期进行了演练。
合成测试覆盖了：
同一个版本也通过托管的 GitHub MCP 连接器完成了一次只读调用。临时凭证和合成测试数据在检查后被移除。
恢复测试涵盖数据库完整性、加密项目密钥恢复、下游失败隔离，以及在一次性环境中的应用回滚。
这些测试证明了特定预发流程在测试条件下工作正常。它们不能证明生产可靠性、安全认证或对敏感客户数据的适用性。
这个区别很重要。测试证据应该缩小声明，而不是夸大它。
当前的预览版不是放置生产客户记录、受监管数据或依赖正常运行时间保证的工作流的正确地方。
第一个 pilot 有几个明确的限制：
也没有公共源代码仓库。GitHub 仓库在我完善产品边界并决定哪些 SDK、示例和文档可以在不暴露运营材料的情况下开源之前保持私有。
这使得外部技术审查更加困难。我认为这是一个真正的限制，不是一个着陆页能解决的。
我在寻找少数已经拥有 AI agent 或 MCP 工作流、并且能描述一个具体记忆失败的开发者。
例子可能包括：
第一次运行刻意控制在小规模：
不收费也不需要信用卡。我需要直接的技术反馈，而不是虚荣的注册数字。
如果这个问题接近你的工作，设计合作者预览在这里：
https://mmw-staging.grifun.ru/design-partners/
我也想听听相反的观点。如果你认为 agent 记忆应该完全放在 agent 内部，或者外部治理工作区创造了错误的抽象，请解释边界应该在哪里。在现阶段这种争论是有益的。
我正在测试的问题不是 agent 能否记住。
而是团队能否在演示结束后理解、控制、移动和删除 agent 记住的内容。