AI惊叹号 - Agent 记忆全知道：四条路线，一张坐标系
一周里四个项目冲上榜单：一个存会话，一个存口径，一个存“谁在改哪个文件”，一个直接给 Agent 发电脑。
引言：四个项目，四张不同的桌子
11 月 5 日的 GitHub 日榜上，claude-mem 一天涨了 1,165 星，总量到 112,534。NVIDIA 的 auto-ontology 一天涨 2,053 星，总量 4,093。Product Hunt 那边，agentmash 拿了 137 票排第 6，Render Sandboxes 拿 98 票排第 7。
四件不同的事。
claude-mem 记的是工具调用：你让它改过哪个文件、跑过哪条命令、修过哪个 bug。auto-ontology 记的是业务口径：收入到底指哪张表、哪个字段、跟谁 join。agentmash 记的是同事的 Agent 正在动哪几个文件。Render Sandboxes 更直接：给每个 Agent 一台隔离的 Linux 机器。
它们都被装进“Agent 记忆”这个词。可这个词现在太松。有人拿它指上下文窗口，有人指向量数据库，有人指一份 CLAUDE.md。定义一混，选型就错：拿向量库去解决口径问题，或者拿共享文档去解决并发写冲突，钱花了，问题一动不动。
这篇文章不评谁最好。只把四类东西放到同一条坐标轴上，回答一个问题：你的 Agent，记忆该存在哪一层。
给 Agent 接一个向量库，第二天它为什么还是忘了昨天的事？
很多团队的第一反应是接一个向量库，把历史对话全灌进去。跑一周，发现两个问题：该记的没记住，不该记的全在里面。
先把“记忆”拆成三个动作看：捕获、压缩、注入。任何一环出问题，用户看到的现象都一样——模型失忆。
claude-mem 把这三步都做成了自动的。捕获靠宿主的生命周期 hooks，工具调用、文件修改、命令输出在会话进行时就被记录，不用你手写“请记住这条”。压缩交给一个本地 worker 服务，一次会话结束后，它把观察记录压成语义摘要，按 decision、bugfix、security_alert、sensitive 打标签，带日期存下来。注入发生在下一次会话开头，按当前任务检索相关片段，塞进上下文。
存储也不是“一个向量库打天下”。SQLite 加 FTS5 管全文和元数据，Chroma 管向量，两路混合检索。全文检索兜住精确的词，向量检索兜住意思相近的说法，缺一路都会漏。
具体到一个场景：装完重启 Claude Code，终端会打印一个本地 worker 地址；再开一个新会话，开头已经多出昨天那条“修了某个回归”的摘要。你没有说“回忆一下”。
那为什么还是有人装了没效果？三个断点。
描述写得太窄，检索不触发；写得太宽，每条都触发，等于没筛。
摘要把细节压没了。“已修复”三个字，对下一次会话毫无用处。
注入预算被挤占。上下文窗口就那么大，记忆占多了，任务本身就没地方放。
它的应对是渐进披露：先给摘要和编号，需要细节再按引用展开。token 成本也做成可见的，你能看到这次注入了多少。
自查三问：捕获是否自动？摘要是否带类型和日期？注入是否能看到 token 成本？三个都是否，那你装的只是个搜索框。
所以“第二天忘了”多半不是存储失败，是捕获太粗、压缩太狠、注入太晚。换库解决不了这三件事。
记在本机 SQLite 和记在团队共享库，差的是隐私还是协作？
claude-mem 的默认形态很本地：记忆文件在用户目录下，敏感内容可以用 <private> 标签排除，截图默认关闭，开启后才会上传。
但协作需求一上来，边界就变了。它提供可选的 Cloud Sync，写入时同步；也提供 TeamBrain，一个团队共享工作区，成员各自决定分享什么，个人请求和复核笔记保持独立。
于是“存哪”其实是三个问题。
哪些内容永远不入库。密钥、客户原文、未脱敏日志。
哪些只进个人库。调试过程、临时判断、半成品结论。
哪些必须进团队库。做过的决策、踩过的坑、口径变更。
这三条不写清楚，工具再换也一样。今天用 SQLite，明天用 Postgres，事故原因还是“谁都能读”。
还有一个容易被忽略的细节：记忆是有归属的。一条结论是谁记的、什么时候改过、被谁引用，决定了它在出问题时能不能追责。共享库如果没有成员归属和引用记录，最后会退化成一份没人敢删的聊天记录。
边界题：本机记忆解决“我下次还想得起”，团队记忆解决“换个人也接得上”。前者要的是保留，后者要的是授权。
差的不是数据库类型，是“谁能看到”和“谁来删”。
企业数据为什么不能靠“把表结构塞进提示词”？
text-to-SQL 的失败，多数不是语法错。“上个月收入多少”这句话里，收入指订单金额、开票金额还是回款？含不含退款？跨不跨主体？这些问题，表结构答不了，提示词也塞不下。
auto-ontology 换了个方向：先把“词”定义清楚，再让模型取数。
流程是：从数据库元数据生成本体；导入已有的语义模型；把同一概念在不同表、不同库里的定义对齐；定义要人审、要认证；提问前先判断“这个问题能不能答”；答完把 SQL 和执行步骤一起返回。
技术栈也说明它的定位。Postgres 加 pgvector 存目录、本体和向量；Next.js 做前端；FastAPI 加 LangChain 做 NL-to-SQL；通过 MCP、CLI、API 暴露给任何 Agent 宿主。权限用 RBAC 管，连接凭据可以放 Vault。
官方示例里有个具体问题：2015 年 6 月宾夕法尼亚州某款 U 盘寿司卷的收入。它把 revenue、product、state 三个词落到本体术语，顺着关系找到六张表的 join 路径，返回 588.80 美元、3 条发票行，以及完整 SQL 和每一步。
这里的关键不是“能查数”，是“每个答案带出处”。数字错了，能追到哪一步错；口径改了，能看出影响了哪些问题。
判断标准：同一个问题，换个人问，SQL 是否一致？数字错了，能否追到口径？两条都做不到，本体只是换了个名字的提示词。
企业记忆的核心是口径，不是文档。文档会过期，口径一旦认证，才可能被反复使用。
两个 Agent 同时改一个仓库，先撞车的不是模型，是什么？
三个 Agent 并行，最常见的故障不是模型答错，是两个 Agent 同时写同一个文件，合并时互相覆盖。
agentmash 给了一组同团队、同模型、同任务的对照：有共享上下文层时，重叠工作在被写进文件前拦下 98.6%；没有时是 55%。以集成冲突收尾的任务，从 17.5% 降到 4.7%。每人每周被接受的 task 从 12 个到 17.2 个，单任务 token 少约三分之一。
机制不复杂：每个 Agent 的编辑意图先进共享层，别人能看到“这个文件有人在改”，可以 @ 一下直接对话，避免同时写。它还支持在不同模型的任务之间切换，把 skills、聊天和自动化保持同步。
这解释了一个常见误判：多 Agent 的瓶颈被归到模型能力，实际是共享状态。模型再强，也不知道隔壁正在写同一行。
锁粒度是新的难题。按文件锁，太粗，两个人改同一个文件的不同段落也会互斥；按行锁，太细，开销和误判都上来。工程上通常先在“意图”层拦，再在写入层兜底。
看指标：别只看任务完成数，看“集成冲突率”和“重复劳动率”。前者决定返工，后者决定账单。
多 Agent 的第一性问题是“谁在改什么”，不是“谁更聪明”。
给每个 Agent 一台机器，这算记忆还是算隔离？
Render Sandboxes 的描述不像记忆产品：每个 Agent 一台隔离 Linux，启动不到 1 秒；空闲挂起、停止计费；唤醒后文件和内存都在；出网域名由你控制；可以同时跑几千个。
但“唤醒后文件还在”，就是记忆。只是载体从向量库换成了文件系统。
这带来一个判断：当 Agent 的记忆主要是“这个项目怎么跑起来”——依赖、环境变量、构建缓存、上次的中间产物——文件系统比向量库更直接。你不用把 Dockerfile 讲给模型听，它就在那儿。它还能用 Docker Compose 把应用跑起来，验证自己的改动。
代价也清楚：冷启动、镜像维护、域名策略，都是运维活。沙箱给了隔离，也把“环境漂移”变成新问题。
安全上还有一层。出网白名单是必需项，不是加分项。一个能读代码、能执行命令、还能访问任意域名的 Agent，等于把生产凭据放在浏览器里。
容器不是记忆的替代品，是记忆的物理边界。它决定这份记忆能不能被信任。
四条路线摆上同一张表，你的场景该落在哪一格？
把前面四类再加上隔离环境，放在一起看。差别不在技术栈，在三个维度：生命周期、读者范围、失效方式。
| 路线 | 记什么 | 生命周期 | 谁能看 | 典型工具 | 主要失效方式 |
|---|---|---|---|---|---|
| 会话内上下文 | 当前任务的中间产物 | 分钟到小时 | 单个会话 | 原生窗口 + 压缩 | 超窗、注意力被稀释 |
| 跨会话记忆 | 决策、bug、偏好 | 天到月 | 个人或小团队 | claude-mem | 检索不触发、摘要失真 |
| 组织语义层 | 指标口径、血缘 | 年 | 全公司 | auto-ontology | 口径无人维护 |
| 多 Agent 共享态 | 文件占用、任务归属 | 秒到小时 | 同团队 | agentmash | 锁粒度、同步延迟 |
| 隔离环境 | 文件、依赖、缓存 | 任务周期 | 单 Agent | Render Sandboxes | 冷启动、镜像漂移 |
怎么选？三个判断题。
- 谁会读这条记忆？只有当前会话、只有我、还是全团队。
- 它多久失效一次？分钟、天、还是年？失效了谁负责改。
- 记错的代价多大？多花点 token，还是报错一个财务数字。
一般的落地顺序：先把会话内做干净——上下文预算、结构化中间产物、失败可恢复；再上跨会话，从决策日志开始，不要一上来就全量对话；最后才碰组织语义层，那是有数据治理预算才做的事。
反过来做，常见结局是给一个没人维护的本体续命。
最小组合：会话内上下文 + 一份决策日志 + 文件占用共享。三样都不贵，先跑一个月，再判断要不要加语义层。
先按读者分层，再按失效代价选载体。
记忆装得越多，Agent 会更强还是更糊涂？
三个成本。
token。注入的每一段都占窗口，而且每一轮都要付。
污染。过期结论比没有结论更危险，模型会当真，还会拿它去推下一步。
攻击面。MCP 的 OAuth 重定向就是现成例子：允许任意回调地址，等于把授权码寄到别人家；只允许白名单，自建客户端又接不进来，报 invalid_redirect_uri。记忆一旦跨系统，授权边界就是安全边界。
三件该主动忘的事。
一次性的调试输出。日志和报错栈留结论，不留原文。
已被推翻的结论。标失效日期，不要静默留着。
含密钥、客户身份、未脱敏数据的原文。永不入库。
一个最小可行方案：会话内记忆加一份决策日志，先跑一个月；确认检索命中率，再开跨会话；团队共享从“文件占用”这种低敏状态开始，别从客户数据开始。
先学会忘，再谈记。
总结：先决定谁能看到，再决定存在哪
回到开头四个项目。没有一个是通用记忆方案。claude-mem 管会话，auto-ontology 管口径，agentmash 管并发，Render 管环境。各解决一层。
选型最容易犯的错，是拿一层的工具去补另一层的洞。
顺序应该反过来：先决定这条记忆给谁看、错了谁负责，再决定它存在 SQLite、Postgres、文件系统，还是干脆不存。
这句话不好听，但能省钱。