写入、修改、召回、遗忘：MongoDB 眼中的 Agent 记忆战争

章节时间轴

• 4:39 开场：数据库老兵与 AI 工程师听众 — Nathan 回忆 15 年前 Guillermo Rauch 演示 MongoDB + Node.js 的震撼，引出"数据质量仍是关键"这条主线。
• 6:11 60 年数据库史：稀缺资源决定设计 — 1970 年存储最贵催生范式化，2007 年时间最贵催生 NoSQL；同一份地址三张表读三次盘 vs 反范式化一次读盘。
• 11:34 MongoDB 的市场位置与选型逻辑 — 覆盖 75% 财富 500 强，FY26 营收约 25 亿美元，占 1000-1100 亿数据库市场的 2-3%；企业按 workload 选型还是全盘押注因公司而异。
• 16:56 Nathan 的三个质疑 — schemaless 好写但难维护、LLM 让数据库延迟优势被稀释、以及"把所有数据倒进去"会导致上下文爆炸。
• 20:48 不是 schemaless 而是 schema flexible — Pete 纠正常见误解：同一 collection 可容纳不同形状的 document，改 schema 不会像 SQL 那样引发级联痛苦。
• 23:06 向量搜索是怎么长出来的 — 2020 年从词法搜索（Atlas Search）起步，到向量搜索、带预过滤的混合搜索，2025 年收购 Voyage AI 补上模型层。
• 30:04 聚合管道与 rank fusion / score fusion — 借力已有的 aggregation pipeline 机制，把混合搜索的多次往返压缩成一次 API 调用。
• 36:14 分块（chunking）的取舍与破解 — 太小丢上下文、太大涨成本降精度；Voyage 的 contextualized chunking 让小分块也能拿高质量。
• 43:56 维度与 Matryoshka 结构 — 256 到 2048 维之间的成本/质量权衡，Voyage 模型可直接砍掉后半段浮点数继续测试，不必重跑全量语料。
• 50:50 Bitter lesson engineering 与 $rerank / auto embeddings — 哪些手工搭的脚手架可以随模型变强而拆掉，MongoDB 给出的两个"少写代码"答案。
• 53:07 Agent 记忆的演化史与新记忆类型 — 从 2022 年单次问答到工具与 MCP，再到短期/长期记忆，以及财富 500 强里出现的 taxonomic memory。
• 60:54 写入、修改、召回、遗忘 — 应用开发者的两项新责任、token budget 式接口、reranker 带来的 5-10% 提升，以及图结构 + 叶节点向量检索的混合做法。
• 67:03 Build vs Buy 与选对问题 — 三类企业客户画像，为什么"有指标"比"有数据"更容易被跳过，以及为什么还没有 Agent 版 LAMP stack。
• 71:40 披萨店的 AI 客服与企业的真实节奏 — Nathan 在底特律点披萨遇到 AI 接线员；Pete 解释为何财富 500 强仍以员工侧 + human in the loop 为主。
• 74:44 文档、MCP 与 agent skills — 数据库厂商如何让自己被 Agent 推荐。
• 77:00 Voyage 收购的宏观启示 — 2.2 亿美元买模型公司而不是向量数据库公司，说明了什么。
• 83:56 七国走访：地理壁垒正在消失 — 最成熟的客户出现在墨西哥城和圣保罗，原因是接入门槛被彻底拉平。
• 87:48 共享嵌入空间与收尾 — 一月发布的 v4 四档模型共享同一嵌入空间，nano 开源免费，可把开发期查询的 token 成本降到零。

详细内容

一、稀缺资源如何塑造数据库：从 1970 到 2007

Pete 的历史叙事有一条清晰的因果链：每一代数据库的设计原则，都是当时最稀缺硬件资源的影子。1970 年 6 月，IBM 研究员 E.F. Codd 发表了催生 SQL 的原始论文。那时的应用极度"部门化"——不是每家公司都有计算机，用它的人往往在同一层楼甚至同一栋楼里，朝九晚五工作，周末停机完全可以接受。而在内存、算力、存储这三大件里，存储在 1970 年是最贵的 6:58。

于是范式化成了唯一合理的答案：数据在盘上不能重复存储。Pete 用一个极简例子说明——他和妻子共享一个地址，零售商如果想知道他们的地址，范式化做法是一张表存人、一张表存地址、第三张表把人和地址关联起来，地址只存一次 7:44。这是当时磁盘效率最优的方案，也塑造了整个教育体系的偏见：Pete 直言"我们的教育系统有一个历史性偏见——汝当永远范式化" 15:25。

到 2007 年 10 月 MongoDB 第一次提交代码时，世界已经完全不同：有了互联网、云、移动设备，iPhone 那年在美国首发。经过 47 年摩尔定律，稀缺资源从存储变成了时间——云上和移动端的应用不能周末停机，用户不在同一栋楼，也不是九到五的使用模式 8:29。MongoDB 的核心选择是 JSON：传输时是 JSON，落盘时是二进制形式的 BSON，从磁盘反序列化、经过服务器、到客户端，格式全程不变，这是速度的来源之一 9:15。

回到地址那个例子：如果稍微反范式化，一个 JSON 结构存 Pete 的名字和地址，另一个存妻子的名字和同一个地址，地址被重复了——但换来的是一次读盘而不是三次 10:02。Pete 强调这不意味着所有问题都该用 NoSQL 解，也不意味着所有问题都该用 SQL 解。他借 Nathan 的话总结："问题已经消失了，但解决方案还在。" 10:48 MongoDB 的甜点区是三件事：需要速度、需要规模，以及"越来越多地——需要更好的检索质量" 11:34。

二、检索质量为什么在 2026 年下半年重新变成头等大事

MongoDB 目前覆盖约 75% 的财富 500 强，FY26 营收约 25 亿美元，占 1000 到 1100 亿美元数据库市场的 2-3% 12:20。Pete 说企业选择 MongoDB 主要基于前两点（快、规模大），而时间成本不只是事务耗时，还包括开发者时间——现代编程语言都能把 JSON 直接反序列化成对象，拿到就能用在业务逻辑里，不必再对着 API 返回的一团数据做二次加工 13:06。

真正的变化是第三点。Pete 明确说：检索质量已经成为重要因素，"尤其是 2026 年更晚一些的时候，当你开始看到人们围绕 token maxing 制定策略、演化出 2026 年上半年还看不到的各种 agentic 架构" 13:52。他给出的标志性事件是 Uber——"今年早些时候，他们在 13 周里烧穿了 2026 全年的 token 预算，这抢了很多头条，而且有类似的报道说 token maxing 也许一开始就不是个好主意" 16:10。Nathan 的回应很轻松："那是一个阶段，我们都经历过自己的各种阶段。"

Nathan 随后提出三个相当锋利的质疑 16:56。第一，schema 灵活让人更想"先把数据全倒进去、以后再说"，但下游代价真实存在——同一个地址存两份，现在要在两处更新。第二，延迟优势被稀释了：反正后面还有一个慢步骤（等 token 生成），省下数据库调用那点时间可能没那么重要。第三，如果真把所有数据都塞进一个额外字段，那就是在做 Pete 反对的事——每次都把百万 token 拉进上下文。

Pete 的第一反应是先纠正一个前提：MongoDB 不是 schemaless，而是 schema flexible 20:48。因为没有表和行，只有 document 和 collection，同一个 collection 里的 document 不必是同一个形状，所以人们误以为它无 schema。真正的价值在可塑性——"任何改过生产环境 SQL schema、体会过它对多张表的级联影响的人，都懂我在说什么"；如果部分数据是反范式化的，往已有 document 上加属性、而且是选择性地加，比 SQL 世界容易得多 22:21。

三、向量搜索的演进：从 Lucene 到混合搜索到一次调用

Pete 说 MongoDB 的向量能力起点"相当不寻常"：它始于词法搜索。2020 年他们注意到一个常见用法——客户自己在 MongoDB 集群旁边部署 Apache Lucene 服务器，把它指向 document 里的文本字段做关键词检索 23:06。这完全合理，但也意味着客户要自己承担运维。于是 2020 年 MongoDB 推出了现在叫 Atlas Search 的能力：在托管版里，你只需把它指向已有的文本属性，系统自动建索引，直接做关键词检索 24:38。（他顺带介绍了三种部署形态：Community 自己负责支持与运维；Enterprise Advanced 多用于本地部署，客户管运维、MongoDB 管支持；Atlas 是托管服务，可部署在 AWS、Google、Azure 任一超大规模云的数据中心，支持与运维都由 MongoDB 承担。）

有了词法搜索，下一步自然是向量搜索。Pete 的论证核心是一个"降维"式洞察：向量说到底就是一个浮点数数组。你把文本、图像、音频或视频交给自选的嵌入模型，拿回来的就是一串浮点数——那对 MongoDB 来说"只是已有 document 上的又一个属性" 25:24。所以实现向量搜索，就是给本来就灵活的 schema 加一个属性，再在这个浮点数组上建向量索引。

由此长出了混合搜索。他用教科书式的书籍例子展开 26:10：一本书的 document 可能有标题（文本）、封面 URL（文本）、页数（整数）、出版年份（整数）、简介（文本）。你可以只对简介做嵌入建向量索引；如果有一万条 document，你甚至可以只对其中一千条做向量搜索——因为 schema 灵活，MongoDB 不仅允许这种不整齐，还"很擅长处理它" 26:57。再进一步，你可以把标题的词法搜索、简介的向量搜索，和"只要 2000 年以后出版的书"这个基于元数据的预过滤组合起来，得到三个查询杠杆 27:45。

2023 年这套能力成型后，团队想的是：既然它对任何嵌入模型都适用，那如果自带一个嵌入模型，会不会更好用？这就是 2025 年收购 Voyage 的动机——做一个"better together"的故事，但走向市场的方式是开放的：Voyage 可以配任何向量数据库，MongoDB 也可以配任何嵌入模型，两者一起用则有额外收益 28:31。

Nathan 追问今天的查询体验：能不能一条查询里把三类条件都写进去，引擎自己决定先用哪个过滤器 29:18。Pete 的回答分两层。底层是"站在已有产品的肩膀上"——Atlas 已在生产运行十年，跨数据中心甚至跨云的复制、分片（无论是为业务原因还是法律原因把数据留在特定用户附近）、静态加密与传输加密乃至查询期间的加密，向量搜索全部免费继承 29:1830:04。上层是 aggregation pipeline 这个老机制：与其让你查完拿到一团 JSON 再自己加工，不如把排序、过滤、整形的指令一起发给后端，返回的结果直接可用。基于这个机制，MongoDB 新发布了 rank fusion 和 score fusion 两个 pipeline stage——过去你必须分别发起向量搜索和词法搜索、再自己合并；现在一次 API 调用、一次往返，后端替你跑两次检索，并按 rank 或按 score 合并成一个已排序的结果集 30:50。

Pete 顺势讲了 MongoDB 的产品哲学，还开了个玩笑："开发者只有两种，爱 MongoDB 的，和还没试过我们的。" 32:24 rank fusion 和 score fusion 之所以存在，是因为社区提出了需求；Atlas Search 之所以存在，是因为他们看到人们在自建 Lucene。逻辑始终是同一个："如果我们把运维周期还给你，你会用这些周期做什么？"（Nathan 的答案是"多读几本小说" 33:10。）

四、分块与维度：把两个"只能靠试"的参数变成不必试

Nathan 提了一个具体困扰：如果不只有书的元数据，还有整本书的内容——他刚读的那本小说分成四"幕"，幕里有章、章里有节、节里有段、最后到句子——文本到底该怎么切分才能被向量空间正确表达？是找一个唯一答案，还是该做成"树干-枝-叶"的结构 36:14？

Pete 先把使用场景框定：这种语义检索通常出现在两处——Agent 的 RAG 流水线，或更复杂的 agentic memory 36:59。RAG 的动因是 LLM 只在公开数据上训练过，你想注入专有数据但不想走昂贵的微调或训练；否则"每个 LLM 都知道最近 30 位奥斯卡得主是谁，但这对我搞明白网络运维中心（NOC）或 IT 工单下一步该做什么毫无帮助" 37:46。

然后是分块的核心权衡 38:33。分块太小——比如切到句子粒度——你会丢掉这个句子出现的上下文："只读小说里的一句话，几乎什么都说明不了；但如果你连带读了那一段或那一页，你对这句话的语境就了解多了。"这是把块做大的理由。但块太大，存储成本上升、检索质量下降——如果一个块有三页而你想定位到一句话，信息过多反而淹没了那句话的精度。标准答案是"看情况"：开发者必须迭代——切一个尺寸、跑测试、看检索质量、再换一个尺寸、再测，反复三四次才能为自己的用例找到成本与质量的平衡点 39:19。

而这正是收购 Voyage 的一个理由。Pete 说 Voyage 团队"副业是在斯坦福教人怎么做 LLM，那帮人都是天才"，他们去年夏天提出了 contextualized chunking 40:04。他用一张图解释传统模型的行为：y 轴是检索质量、x 轴是块大小，块很小时没有上下文所以质量低，随块增大而上升，到某点后走平，再增大就开始退化——这个曲线形状就是你必须迭代的原因。contextualized chunking 的做法是反转脚本：不再把一切当成一个大文本块发过去，而是发两个字符串——你真正想定位的那一句，以及作为第二个字符串的上下文信息；模型替你判断这个组合的合适块大小，返回一个平衡好的向量数组 40:50。结果是"你可以用更小的块拿到更好的检索质量"，这在传统做法下是不可能的（传统路径里，提升质量的方式就是加大块）。v3 是去年夏天发布的，v4 在最近六周内发布 41:37。

Nathan 追问机制：这意味着开发者不必自带一堆评测？返回的是一个向量？Pete 确认："完全就是这样运作的。你拿回一个浮点数组，跟以前一模一样，只是你不必再迭代块大小了。" 43:11

同一套"把需要试的参数变成不必试"的思路也用在维度上。嵌入空间通常至少 256 维，有时高达 2048 维；维度越多、空间越丰富、检索质量越好，但 2048 个浮点数在磁盘、索引和内存里占的空间远大于 256 个，于是又是一轮迭代 43:56。Voyage 全系模型内置 Matryoshka（俄罗斯套娃）结构：假设你用 1024 维跑完了全部语料，现在想试 512 维——传统模型必须把整个语料库重跑一遍，而 Voyage 的浮点数是有序的，你直接砍掉后 512 个，立刻就能在剩下的 512 维上测试 44:4345:29。Pete 诚实地说，这不能完全解决"多少维才对"的问题，只是让你更快到达答案。这类功能有三四个，共同目标是"把时间还给你，让你去做业务逻辑，而不是搞管道"。Nathan 表示他是"套娃式任何东西的忠实粉丝" 46:15。

五、什么时候才需要认真优化：Nathan 的一人系统与 10 万向量阈值

Nathan 给出了一个非常具体的自我诊断请求 46:15。他有一个自称"deep context"的检索系统，覆盖过去五年的邮件、Slack 消息、所有公开发表的内容、各渠道 DM，以及播客的分离说话人（diarized）转录稿，总量约 1GB。他几乎没优化过——让 Agent 自己选数据库、自己加优化，后来 Agent 说"关键词大概可以做得更好"，就加了一层嵌入（他坦白用的是 Gemini 的嵌入模型）。他的问题是：我怎么知道自己错过了什么？门槛是数据规模、用户规模，还是成本 47:46？

Pete 的回答回到那三件事：速度、规模、检索质量。他先给了一个体面的现状描述——"大多数人从 Postgres 加 pgvector 开始，然后按自己用的云选嵌入模型：在 Google 上就用 Gemini，在 Azure 上 OpenAI 的嵌入模型很流行，因为这两家公司的历史关系" 48:32。做 demo、做 PoC 时问题不显形，但总会到某个点：毫秒对你的用例开始重要了吗？规模对你的用例开始重要了吗？他给出的量化阈值是——取决于块大小，大约 10 万个向量就是他所说的"规模"开始咬人的位置。

检索质量方面他给了两个具体数字。HuggingFace 上有个叫 RTEB 的榜单，Voyage 的模型通常在榜首，相对前面提到的那些嵌入模型"最多能拿到 14% 的提升"。他把这个数字翻译成业务语言："有没有哪些用例，14% 的嵌入模型质量差异就是幻觉和正确答案之间的分界？"而这还没算上 reranker——那是另一条不必改动数据就能提升检索质量的路径 49:19。他明确反对一种流行看法："大多数人以为嵌入模型已经商品化了，这不是真的。"并抛出一个背书作为论据："Anthropic 市面上没有嵌入模型，他们推荐我们。这是个很好的推荐。" 50:04

六、Bitter lesson engineering：哪些脚手架可以拆掉

Nathan 引入了一个他认为正在流行的概念——bitter lesson engineering：每隔一段时间，你应该把技术栈里所有为了让东西跑起来而加的临时拼凑物过一遍，问哪些已经不需要了，因为模型变聪明了、嵌入模型变好了，过去必须靠手工技艺保障的事现在自然就成立了 50:04。他问：检索领域有没有出现这种"变简单"的例子？

Pete 举了两个最近的例子。第一是 reranking。春天他们发布了 $rerank，作为 score fusion 和 rank fusion 的伴侣功能 50:50。传统做法是先做一次向量搜索，把结果送给 reranker 重排成 RAG 用例最优的顺序，再塞进上下文窗口；现在调用一次 $rerank，后端两步都替你做完，只需一次往返 51:36。第二是 auto embeddings：你告诉 MongoDB 哪个 collection、collection 里 document 的哪个属性、用哪个 Voyage 模型和多少维度，其余的它全接管——该属性内容变化时，自动过一遍嵌入模型、更新 document 里的向量、更新内存里的索引；有新 document 带着该属性进入 collection，同样流程再跑一次 52:22。他的总结是："你不必再自己写一套嵌入流水线并长期维护它，只要给我们一团 JSON。" 53:07

七、Agent 记忆的演化史，与"写入、修改、召回、遗忘"

Nathan 把话题从数据库拉到包裹在数据库外面的系统层：记忆。他坦承自己也经历过"膨胀然后简化"的过程，而简化往往是被企业不太愿意大规模买单的东西（百万 token 上下文）促成的——"我拿到百万 token 上下文时就想，太好了，这些事我不用操心了，模型自己处理"，但他也接受 Pete 的反驳：有几千个用户时，这些成本会叠加 53:07。

Pete 依旧从历史讲起 53:54。2022 年底 ChatGPT 出来时架构极简：query 进上下文窗口，LLM 处理，给结果，故事结束。到第二年春天出现了"ChatGPT 通过律师资格考试"这样的头条。RAG 的必要性来自第一个问题（只在公开数据上训练）。2025 年浮现的第二个问题催生了记忆需求：知识截止日期。"2023 年春天你如果问 ChatGPT MongoDB 今天股价多少，它答不出来" 54:40。这个问题在 2025 年前后被工具和 MCP 解决——今天无论你用 Claude、Gemini 还是 ChatGPT，问股价它都能答，因为它能在自己的武器库里找到工具、去做网页搜索、把结果报回来 55:27。

但 2025 年还出现了循环（looping）：一轮 Agent 的输出成为下一轮的输入。而上下文窗口"还是很笨"——每次调用 LLM 你面对的都是一个全新的上下文窗口。这就是 agentic memory 出现的时刻 55:27。早期做法很粗暴：短期记忆是把本 session 内所有响应塞进上下文窗口；长期记忆是把过去三天每个 session 都同样塞进去 56:14。

Pete 指出这带来两类负面效应。一是 token maxing 的成本问题：如果每一轮 Agent 循环都往上下文里放百万 token，包括你并不需要的上下文，成本会累积。二是功能性成本——"有几项学术研究显示，前 7K 和后 7K token 是最重要的，夹在中间的东西反而会把 LLM 搞浑、干扰它得出答案" 57:01。于是问题从"怎么每次都塞进 100 万 token"变成"我能不能只为这一轮循环挑出恰好对的 20 万 token"。这催生了更精细的短期记忆（不取整个 session，只取这一轮相关的部分），长期记忆同理。

他还提到一种正在财富 500 强中出现的新记忆类型：taxonomic memory（分类学记忆）57:01。行业或公司内部有一批专有术语，外行看这些词含义完全不同。假设你有一百个这样的术语——对这一轮 Agent 循环，哪五个是相关的？下一轮又是哪五个？与其每次把一百个全塞进去，不如让记忆系统用向量搜索、语义搜索，或向量加词法加预过滤的组合，取出"这一轮所需的、你永远达不到但存在的那个完美上下文窗口"——而这个完美窗口不会用满全部容量 57:4658:34。他强调企业做这件事的两个动机是并行的：既为了压 token 成本，也为了提升 token 相关性从而拿到更好的答案。

Nathan 接着描述了自己记忆系统的维护困境 58:3459:21：他有把邮件、DM 等合并成的月度原始日志（每月大约几十万 token），再摘要成月度总结，再汇成年度总结，上面还盖了一层受 Karpathy 启发的、更偏实体、彼此互链的 wiki 式结构；一部分在数据库里，一部分在文件系统里。新的事情发生了，他不知道该改什么、怎么保证所有需要改的地方都改到。他还举了一个具体的失败模式：早期搭系统时，模型会把他只是稍微试过、或本来打算做但没做的项目当成"未完成线程"保留好几个月——"哥，我从来没真做过那件事，你可以直接忘掉它。"所以"遗忘有时是记忆系统的真美德" 60:07。

Pete 的回答是本期最重要的一段。"这是眼下 Agent 最难的问题。我跟别人是这么说的：作为一个行业，我们做数据库做了 60 年；做 Agent 做了 18 个月。没人知道所有答案，我们都还在集体摸索。" 60:54 他给出的结构化描述是：在这些更复杂的记忆类型下，应用作者有两项责任，而在旧范式下只有一项。第一项是查询记忆系统，而更成熟的系统接受的是 token budget 式的接口——你不必知道有多少种记忆类型、怎么分别查询它们，只说"给我最好的 5 万 token"或"最好的 10 万 token"，系统自己从各类记忆的混合中取回 61:40。第二项责任是把 LLM 给出的答案送回记忆系统，让它策划（curate）后写入。更成熟的系统还有"归还/共享"的概念：如果你和我是同一类岗位，我们可以共享记忆，你产出一条好记忆我以后能复用，对双方都有益 61:40。

但最难的还是 Nathan 说的那部分。Pete 引用了一位同事前一天写给他的话，并特意说明要原文引用："Write, change, recall, forget（写入、修改、召回、遗忘）。因为这些东西有半衰期——更近期的比几周甚至几个月前发生的更重要。" 62:27

八、图结构、ElevenLabs，与一条明确的反模式警告

Nathan 追问他反复自发搭出来的图结构：人、他们所在的组织、他与他们关联的想法，这些东西互相指向，但指法很松散——他现在是在赌 Agent 能注意到这些指针、在跑维护时能顺着指针做必要更新，"我没什么保证" 62:2763:13。

Pete 给了三条路径。第一，遗忘确实是难的部分，但客户实践中，记忆类型的检索质量恰恰是"未商品化的嵌入模型"和 reranker 能产生差异的地方——"取决于用例，只要在你选定的嵌入模型上加一个 reranker，检索质量可以有 5% 到 10% 的提升" 63:58。这也是他们把 reranker 做得极易接入 Voyage 嵌入 + 向量搜索的原因。第二，数据量极大时可能需要混合方案：用图结构走两到六层，到叶节点后在叶内做向量检索 63:58。他补充，因为 MongoDB 是 JSON 的，你可以在数据里构建图结构，从而"只在一个地方解决图数据库、核心数据库、向量数据库、嵌入和重排"，不必自己缝合多个工具并长期维护 64:44。他也界定了这类图的深度："通常没有传统图数据库需求那么深，大概半打到十来层"——零售客户的商品库就是典型：先按商品类目用图式结构分段，进到某个类目节点后再在其中做向量搜索 64:4465:31。

关于"记忆做得好的范例"，Pete 点出了一家：ElevenLabs——他说是 MongoDB 目前最大的客户，但对方对实现细节一直不太公开 65:31。它的模式是"每个客户配多个 agent"的微 agent 架构，考虑到它的客户量，规模相当可观。ElevenLabs 起家于语音转文字和文字转语音模型，之后在此之上搭了更像音频编辑套件的平台，里面有一批 agent 为客户做各种编辑和转换 66:17。

紧接着 Pete 给了一条明确的反模式警告：他会担心任何这样的记忆架构——不依赖成本更低的 embedder 和 reranker，而依赖多次 LLM 调用来帮你分类和压缩语料，然后再把结果放进更大、更有功能性的那次 LLM 调用的上下文窗口。因为"那也只是在累加 token"。embedder 和 reranker 的 token 成本更低，这又回到"用对工具解对问题" 66:1767:03。Nathan 补充了延迟维度："这在今天也会加很多延迟，即使是小模型，在你真正拿到答案前也能推理相当长时间。" Pete 同意，并强调"不只是 token，整个决策循环的总延迟差别很大" 67:03。

九、Build vs Buy：三类企业、选对问题、以及"还没有 Agent 版 LAMP stack"

Pete 说自己今年去了七个国家、和大约一百家客户聊过他们在 AI 旅程中的位置，客户大致落在三个阵营 67:49。第一营："我买了某个工具的许可证，我做完了"——AI 战略等于买一个东西。这可以是不错的起点，但通常不够具体，解决不了整个企业的问题。第二营：做过一些 PoC，也许有一两个生产部署，ROI 表现参差。他对 ROI 挣扎的诊断非常直接："大概是挑错了问题。在这个领域挑对问题真的很重要。" 68:34

他给客户的框架是三个连续的筛子：你现在业务上最重要的 10 到 15 个问题是什么？其中哪些你有好数据？以及——这是大家最容易跳过的一步——哪些你已经有围绕这个问题的指标？逻辑很硬："如果你本来就没有衡量某件事表现的指标，你就不会知道它有没有变好。" 69:22 他也附上一句对 Nathan 早前"数据质量很重要"的呼应："糟糕的数据质量和糟糕的安全态势不会被 AI 解决，它们会被 AI 放大。" 68:34

呼叫中心之所以是企业最受欢迎的低垂果实，正因为指标现成：每通电话成本已知、通话量已知（本来就靠这些给人发奖金）。把 AI 放进这个工作流，数字一跳，就能把变化归因给 AI，做出信封背面的 ROI 估算 69:22。他还用软件交付生命周期做了对照批评：今年早些时候到处都是"我有了 Claude Code、有了 Codex，现在我能写出五倍的代码"这种自夸——但任何做过一段时间的人都知道，代码行数是判断开发者生产力最糟糕的指标之一；真正重要的指标是从想法到生产部署有多快 69:2270:08。他坚持："卡在 PoC 炼狱、没走到生产部署的那批人，和别人最大的差别不在他们怎么用技术，而在他们选了什么问题来解。" 70:08

第三营是更进阶的：在研究这些更复杂的记忆类型、优化已有系统，有的采购更大的平台，有的自研。而 Pete 对这一层的判断是清醒的："我们才进入这个领域 18 到 24 个月，还没有唯一的做法。Agent 还没有属于自己的 LAMP stack，不像 Web 开发那样。我们经历过那个生命周期，最终会到那一步，但现在还没有 React 和 Angular，还没有 Agent 版的 LAMP stack。" 70:54

十、披萨店的 AI 接线员，与企业为何仍守在员工侧

Nathan 讲了一个鲜活的对照 70:5471:40：上周五他从底特律社区的本地披萨店（Greg's Pizza，可能只有一个门店）订披萨，接电话的是 AI agent。体验相当不错——对话非常自然，但不完美：他开始带点对抗性地测试它，问"是哪家公司在支撑你这个 AI agent 体验"，它不知怎么理解成他在为公司订披萨。整体上他"印象很深，happy path 跑得很好"。（Pete 顺口插了句"底特律风格披萨被低估了"，Nathan 回"这次其实是传统圆披萨，但我同意——除了汽车，披萨是底特律对世界最大的出口"。）Nathan 的问题是：这波变革走到哪一步了？从"给客服配个能更快更准找答案的工具"，到"你打电话直接和 AI 说话"，客户实际被颠覆到什么程度 72:26？

Pete 的回答与那家披萨店形成反差：他接触的大多数财富 500 强做的都是面向员工、带 human in the loop 的用例 72:26。理由有两层。ROI 层面：员工侧用例的 KPI 现成——不管是保险理赔员还是制造厂的产线工人，人人都有关键绩效指标，把 AI 放进工作流看指标跳没跳，就能算出 ROI 73:12。安全层面他给了一个很直白的风险对比："如果你和我是同一家公司的员工，我的薪水意外泄露给你，很棒吗？不。但这比我们是同一家公司的两个客户、而我能看到你的数据要好得多——后者是要有 VP 出来担责的场面。" 73:59 所以面向客户的用例风险回报比更高，这解释了当下的分布：更多投入在带人类兜底的员工侧，而不是全自动的客户侧。

十一、被 Agent 推荐：MCP、agent skills，与 Voyage 收购的宏观启示

Nathan 提了一个厂商视角的新问题 73:5974:44：除了给人读的传统文档，你们一定也在想怎么让文档对 AI 友好、怎么让一个 AI 代理进入这些文档，甚至打包分发 skills，努力成为"别人第一次做某件事时被 Agent 推荐的那个数据库"。

Pete 说这些每家软件公司都在做，他要重点打光的有两个 74:44。一是 MCP 工具，让 agent 更容易和你在 MongoDB 实例里的数据对话——他们的 MCP server 已有一段时间，现在把其中一些作为 Atlas 生态的一部分自托管。二是 agent skills，他的定义很清晰："把它想成经过策划的 system prompt"，用于数据建模、运维优化等他们本来就有成熟 playbook 的事情；过去这些是文档，现在是一系列 markdown 文件，你可以喂给任选的 agent，让它了解不同任务的处理方式 75:29。他提到几个月前的"agent skills week"里，MongoDB 放出了六到八个这类 skill，覆盖运维和数据建模等 76:14。

然后 Nathan 抛出两个关于 Voyage 收购的"理论问题" 76:1477:00。第一，MongoDB 自建了向量数据库，市面上又有一堆向量数据库创业公司，本来可以想象另一种剧本：收购一家向量数据库公司；但实际发生的是收购一家模型公司。第二是相对价值：2.2 亿美元——"我老到还记得那曾是笔大钱"——不到 MongoDB 市值的 1%。他问该从中推出什么关于软件业价值与防御性的宏观结论：基础设施是大赢家？模型被商品化？在位者能防住创业公司？

Pete 的回答绕回他们的一贯主线：让开发者的日常更容易，让他们少花时间在下层的管道上 77:45。向量搜索之所以对 MongoDB 是相对轻松的加法，是因为已有的 JSON 基础——加一个属性、属性是浮点数组、基于数组建索引，就能顺带继承分片、安全和数据复制，而"一些全新的向量数据库公司还得追赶和挣扎" 78:32。真正不轻松的部分才是收购的理由：你今天仍可以用任何嵌入模型，只要它产出浮点数组；但他们看到一个机会——"市场把嵌入和重排当成商品，而我们看到 Voyage 真的很突出，我说过了，Anthropic 同意我们" 79:18。加上能做出 auto embeddings 这样的 better together 故事，以及一个他之前没提的：在 Atlas 里统一管理所有 API key，不必"核心数据一个控制台、向量数据另一个、嵌入模型第三个、reranker 第四个" 79:18。他把整段收束回同一句话："我们骨子里都是开发者，这件事是关于让开发者生态更容易学会、更容易运行这些围绕 agent 的新应用架构技术——不管是 RAG 流水线还是 agentic memory。怎么让向量搜索更容易上手？怎么把学习曲线压低，让更多人更快学会、加入这个生态？" 80:04

十二、更大的数据宇宙，与地理壁垒的消失

Nathan 转述了一位向量数据库创业公司创始人的反驳 80:0480:50。当时 Nathan 的论点是：在位者能给自己的产品加上向量能力，速度快于创业公司复制在位者的全部能力，所以后者很难真正取代前者。那位创始人的回答是：这也许成立，但进入我们向量数据库的大部分数据，此前从来没有进过任何数据库——它们一直躺在某个数据湖、数据仓库，或者干脆就是一堆非结构化文档；现在它们进入了更高层的基础设施，以一种此前完全没有发生过的方式变得更有价值。Nathan 还注意到 Voyage 有支持视频的多模态嵌入模型，而视频正是"从未进过数据库"的典型候选。

Pete 同意这个观察 81:37。以前没被索引的数据不适合传统词法搜索；而向量搜索的本质是把一段数据映射到 n 维空间中的一个几何位置，检索就是找相似——"离我搜索的这个新东西最近的向量是哪些"。视频、音频、SharePoint 里堆着的一批 PDF，都是好例子 82:22。他补充说，问题因此不只是"怎么把数据放进数据库"，而是"怎么找到它，并且以快、可扩展、高质量的方式找到"。这也是他认为同一平台内预过滤 + 向量 + 词法的组合构成优势的原因——加上向量搜索站在核心产品肩上，Atlas 版本可以部署在任意超大规模云的数据中心，自带数据韧性和安全性，需要时可以分片让数据不离开特定地理区域，"这些我们基本上是免费得到的" 82:2283:09。

最后 Nathan 承认自己视野的局限："我如此近视地聚焦在旧金山和硅谷发生的事情上，很清楚自己可能错过世界各地重要的故事或视角差异。"他试图至少填上中国这块空白，但"外面的世界很大"，于是问 Pete：美国听众在这种内视中错过了什么 83:56？

Pete 把问题反转过来回答："其他国家有一个预设——美国领先、在做别人没做的事。我发现恰恰相反。" 83:56 他住在辛辛那提工作，今年早些时候去过阿姆斯特丹和伦敦，之后又跑了一趟包含多伦多、班加罗尔、墨西哥城和圣保罗的巡回。"今年我谈过的最成熟的两家客户在墨西哥城和圣保罗。而对话开始时他们都以为自己有美国竞争对手在做他们做不到的事——我说过了，事实正好相反。" 84:43

Nathan 追问原因：是美国公司文化上太保守跑不快，还是一个"蛙跳"故事——国际公司近期技术投资更少，因此没有历史包袱需要替换 86:15？Pete 的判断是前者不成立："我认为这更多和美国之外壁垒的消失有关，而不是美国公司的任何行为。" 86:15 他的论证是接入的民主化："云和移动那两波不是这样的——如果你连无线电塔都还没有，iPhone 对你没什么用。" 87:02 而现在几乎每个国家至少有一个超大规模云的数据中心，顺带就有了对模型、向量数据库、嵌入和 reranker 的接入——"这些东西的可及性远好于我见过的以往任何技术革命" 85:29。他明确说这"不是对美国公司思考方式的指控"，只是更大的可及性侵蚀了以往技术浪潮中的地理壁垒。

十三、共享嵌入空间：把开发期的查询 token 成本降到零

在收尾环节，Pete 主动补上一个没讲到的技术点：共享嵌入空间（shared embedding spaces）87:0287:48。今年一月他们发布了文本模型的第四代，一次四个版本。行业惯例是发小、中、大三档，各有不同价格点和检索质量；MongoDB 额外加了一个 nano——开放权重、任何人都能从 HuggingFace 免费下载。共享嵌入空间的含义是：这四个模型共用同一个嵌入空间，用其中一个生成的嵌入与另外三个兼容 87:48。

这带来一个具体的成本设计。你可以用 large 嵌入整个语料库，然后在开发阶段用 nano 跑查询——"其他每一个嵌入模型都会强迫你在开发周期里为打它们的嵌入模型付 token 费用"，因为查询也要过嵌入模型；而 nano 你甚至可以跑在自己的笔记本上。结果是除了语料库的一次性嵌入之外，开发期的查询 token 成本可以归零，这在今年一月之前做不到 88:34。Pete 也如实说明代价："用不同模型时你确实会有一点检索质量损失，所以这不适合所有人"，但对想压低开发期 token 成本的客户是一条可行路径 89:20。

他的收尾回到那个贯穿全场的对比：数据库我们做了很久，agent 没有。"我们会继续看到迭代式改进，而且会很快。MCP 大约是两年前感恩节前的那个周一发布的，到三月所有竞争对手都接受了它作为协议。Token maxing 大概三月初才第一次被提起，到四月它作为一个话题就结束了。我们进行这些对话、走完这些功能周期的速度，比以往任何时候都快。" 89:2090:06 所以"有趣的部分是，我们集体还有很多要学；我们会集体搞清楚怎么让这件事对所有人都更容易，你也会因此在日常生活里看到越来越多的 agent" 90:06。

金句

我和 SQL 同岁，Nathan。SQL 的原始论文写于 1970 年 6 月，而我正好生于 1970 年 2 月。 —— Pete Johnson 6:58

我们的教育系统有一个历史性偏见：汝当永远范式化。对很多用例这是对的，但越来越多的用例里，检索质量正在变成大得多的事。 —— Pete Johnson 15:25

我们作为一个行业做数据库做了 60 年，做 agent 做了大概 18 个月，老兄。没人知道所有答案，我们都还在集体摸索。 —— Pete Johnson 60:54

写入、修改、召回、遗忘。因为这些记忆有半衰期——更近期的东西比几周甚至几个月前的更重要。 —— Pete Johnson 引用同事 62:27

糟糕的数据质量和糟糕的安全态势不会被 AI 解决，它们会被 AI 放大。 —— Pete Johnson 68:34

大多数人以为嵌入模型已经商品化了，这不是真的。Anthropic 市面上没有嵌入模型，他们推荐我们。 —— Pete Johnson 49:1950:04

我今年谈过的最成熟的两家客户在墨西哥城和圣保罗，而他们一开始都以为自己落后于美国竞争对手。 —— Pete Johnson 84:43

提到的书·产品·人物

• Pete Johnson（人物）：MongoDB 的 AI 领域 CTO，30 年技术老兵，本期唯一嘉宾，居住并工作于辛辛那提。
• Nathan Labenz（人物）：本期主持人，自称做过数据库，全程用自己的一人检索系统（约 1GB 语料）做实战提问样本。
• MongoDB（公司/产品）：本期主体，2007 年 10 月首次提交，JSON/BSON 文档数据库，覆盖约 75% 财富 500 强，FY26 营收约 25 亿美元。
• E.F. Codd（人物）：IBM 研究员，1970 年 6 月发表催生 SQL 的原始论文。
• SQL / NoSQL（技术）：贯穿全场的对照框架，分别对应"存储稀缺"与"时间稀缺"两个时代。
• Voyage AI（公司/产品）：MongoDB 于 2025 年以 2.2 亿美元收购的嵌入与重排模型公司，团队副业是在斯坦福教人做 LLM。
• Atlas / Atlas Search（产品）：MongoDB 托管服务与 2020 年推出的词法搜索能力，起因是客户自建 Apache Lucene 服务器。
• Apache Lucene（产品）：客户在 Atlas Search 之前自行部署以获得关键词检索的搜索引擎。
• rank fusion / score fusion（产品功能）：新的聚合管道阶段，把向量搜索与词法搜索的合并压缩为一次 API 调用。
• $rerank（产品功能）：春天发布的重排管道阶段，可带来 5-10% 检索质量提升。
• auto embeddings（产品功能）：指定 collection、属性、Voyage 模型和维度后，自动维护向量与索引。
• contextualized chunking（技术）：Voyage 去年夏天提出的方法，v3 去年夏天发布、v4 最近六周发布，允许小分块拿到更好检索质量。
• Matryoshka 结构（技术）：Voyage 模型的嵌套维度设计，1024 维跑完可直接砍成 512 维继续测试。
• 共享嵌入空间 / nano 模型（产品功能）：今年一月发布的 v4 四档文本模型共用嵌入空间，nano 为开放权重、可从 HuggingFace 免费下载。
• RTEB（榜单）：HuggingFace 上的检索基准，Voyage 模型常居榜首，最多可比其他模型高 14%。
• pgvector / Postgres（产品）：Pete 认为大多数人的起点方案。
• Gemini / OpenAI 嵌入模型（产品）：分别在 Google 云与 Azure 上流行的嵌入选择，Nathan 自己用的是 Gemini。
• Anthropic / Claude（公司/产品）：被引为"没有嵌入模型且推荐 MongoDB"的第三方背书，也是本期赞助商之一。
• MCP（协议）：两年前感恩节前周一发布，到次年三月竞争对手全部接受，被用作行业迭代速度的例证。
• Agent skills（产品形态）：MongoDB 把数据建模、运维优化等 playbook 做成 markdown 文件，可喂给任意 agent；"agent skills week"里放出六到八个。
• ElevenLabs（公司）：Pete 称其为 MongoDB 目前最大客户，采用"每客户多个微 agent"架构，起家于语音模型、现为音频编辑平台。
• Uber（公司）：2026 年初 13 周烧完全年 token 预算，被视为 token maxing 退潮的标志性事件。
• Guillermo Rauch（人物）：现 Vercel CEO，Nathan 约 15 年前正是从他那里第一次见到 MongoDB 与 Node.js 的组合。
• Andrej Karpathy（人物）：Nathan 的实体化 wiki 式记忆结构受其启发。
• Greg's Pizza（底特律）（公司）：Nathan 上周五点披萨时接电话的是 AI agent，被用作小微企业 AI 落地的实例。
• 某北美三大车企（公司）：Pete 参与的黑客松培训了约 250 名工程师、放手做了 3 天，产出若干新产品构想。
• taxonomic memory（技术概念）：财富 500 强中出现的新记忆类型，针对行业或公司专有术语做按轮次的相关性筛选。
• Bitter lesson engineering（概念）：Nathan 提出的说法，指定期清理那些因模型变强而不再必要的手工脚手架。
• LAMP stack / React / Angular（技术）：作为对照物，用来说明 Agent 领域还没有形成同等成熟度的标准栈。

适合谁听

正在为 AI Agent 搭建 RAG 或记忆系统的工程师与技术决策者，尤其是需要在检索质量、token 成本和运维复杂度之间做真实取舍的人。