本节摘要:meta-MCP 脊柱讲到最后,还有一个特殊的「能力」值得单独成节——Memory Bank(记忆库)。它是每用户持久化的明文记忆,也是通过 meta-MCP 暴露的一种能力。本节讲清它是什么、为什么用明文存储、如何按用户隔离、以及它如何让 Agent「记住」用户的偏好与上下文。这是第 7 章的收尾——理解了 Memory Bank,你就完成了对 meta-MCP 脊柱的完整理解。
先想清楚 Agent 的一个天然局限:会话之间是失忆的。默认情况下,Agent 在会话 A 里知道的事,到了会话 B 就忘了——因为每个会话的上下文是独立的(OpenCode 教程第 8 章)。
这在很多场景下是缺点。比如:
Memory Bank 解决的就是这种「跨会话记忆」——它持久化存下用户的偏好、事实、上下文,让 Agent 在任意会话里都能取出来用。
Memory Bank 是每用户持久化的明文记忆。几个关键特性:
| 特性 | 含义 |
|---|---|
| 每用户 | 每个用户有自己的记忆库,互不干扰 |
| 持久化 | 存在盘上,关掉重开还在 |
| 明文 | 记忆以可读文本存,不是加密/向量 |
用户甲的记忆库 ├─ 偏好:代码风格用某某规范 ├─ 事实:项目部署在某地址 └─ 上下文:团队约定某某 用户乙的记忆库 ├─ ...(完全独立)
它通过 meta-MCP 暴露——也就是说,Agent 通过「检索能力」能找到「读取记忆」这个能力,通过「执行能力」能读取或写入记忆。Memory Bank 本质上是能力库里的一个特殊能力。
这一点值得展开,因为它是个有意的设计选择,不是疏忽。明文存储意味着:
对比「向量化的隐式记忆」(很多 RAG 系统的做法),明文记忆牺牲了「模糊匹配」,换来了「透明可控」。OpenWork 选明文,是因为它更尊重用户对「自己被记住了什么」的知情权和控制权。
💡 设计哲学:记忆是用户的资产,用户有权知道、有权删改。明文存储让这份权利落到实处。这和「隐私优先」的产品定位一致。
Memory Bank 严格按用户隔离——用户甲绝对访问不到用户乙的记忆。这通过两层保证:
这种隔离在企业场景下尤其重要——员工甲的偏好不能被员工乙看到,更不能跨组织泄露。
把 Memory Bank 放进 meta-MCP 的工作流,它大概是这样被用的:
会话进行中,Agent 觉得「这个偏好值得记住」 │ ▼ execute_capability("写入记忆", { 内容: "用户偏好某某代码风格" }) │ ▼ 写入当前用户的 Memory Bank 下次会话,Agent 想知道用户偏好 │ ▼ search_capabilities("用户偏好") ──► 匹配到「读取记忆」能力 │ ▼ execute_capability("读取记忆", { 查询: "代码风格" }) │ ▼ 从当前用户的 Memory Bank 取出 │ ▼ Agent 拿到偏好,据此调整行为
注意 Memory Bank 完全走 meta-MCP 的「检索 + 执行」——它不是特殊通道,而是能力库里的一种能力。这保证了它和其他能力走同一套治理(权限/审计/计费)。
诚实地说,Memory Bank 不是万能的。它的边界:
⚠️ 别误解:Memory Bank 不是「Agent 的脑子里自动记住一切」。它是「一个需要 Agent 主动检索/写入的能力」,用得好是助力,不用就等于没有。
读完第 7 章四节,你完成了全书最精巧一章的攀登:
| 节 | 讲了什么 |
|---|---|
| 01 四源检索 | search_capabilities 如何在四源里找能力 |
| 02 统一执行 | execute_capability 如何抹平四源差异 |
| 03 策略治理 | 权限/审计/计费 + 外部能力严管 |
| 04 Memory Bank | 每用户持久化明文记忆,作为能力经 meta-MCP 暴露 |
这套脊柱是 OpenWork 的产品灵魂——「两工具无限能力 + 统一治理 + 持久记忆」。它的核心思想是:能力收敛到四源、入口收敛到两工具、治理收敛到一层、记忆作为能力的一种。理解了它,你就理解了 OpenWork 为什么能成为「能力的平台」。
第 7 章结束。下一章讲支撑「改了能力立刻生效」的机制——Reload 事件系统与实时协同。