为什么我看好 Turbopuffer，从 Personal Agent 说起
内容提要
文章从Personal Agent记忆切入，质疑通用Memory API的商业价值：记忆与产品设计、架构及模型深度耦合，检索结果是否进入上下文取决于Agent的工作方式，难以标准化。作者认为Search更接近通用基础设施，并以Turbopuffer为例，分析其基于对象存储的索引设计、冷查询代价与多租户挑战，指出其正从向量搜索走向通用查询系统。
延伸解读
Memory API 的标准化困境
文章指出，记忆与产品设计、架构及模型深度耦合，通用 API 难以解决“什么值得提炼为长期记忆”“相反历史如何呈现”“何时主动提起”等关键问题。检索结果是否进入上下文，最终由 Agent 的工作方式决定，而非相似度。因此，尽管 Mem0 等公司在做 Memory API，作者认为其商业价值不如 Search 清晰，因为 Search 解决的是通用的存储与计算问题。
冷查询代价与产品交互的掩盖
Turbopuffer 将持久数据放在对象存储，查询时从远端读取，冷查询延迟显著。官方示例中百万文档首次查询 p50 为 874 毫秒，缓存命中后为 14 毫秒。Notion 在打开搜索对话框时先发预热查询，利用产品交互提前加载数据。Personal Agent 场景也有类似机会，例如在用户可能触发搜索前预取。但冷启动代价仍需正视，不能将特定负载下的数字视为普遍保证。
从向量搜索到通用查询系统的演进与挑战
Turbopuffer 最初围绕向量搜索设计，存储布局以 ANN 索引地址为中心。随着全文搜索、属性过滤和 Linear 的 delta sync 等需求加入，原有设计成为约束：向量聚类变化会引发无关数据写入，多向量表示使文档重复存储。v3 计划将 ANN 降为二级索引，改用列式布局，按属性分组计数比 v2 快约十五倍，但部分全文检索测试仍慢于生产版。起点窄带来清晰架构，也带来相邻需求的适配成本。
多租户与权限设计的复杂性
Personal Agent 的负载特点是租户数多、单租户数据不大、使用时间不均匀。Turbopuffer 通过共享查询节点和对象存储降低常驻开销，但缓存命中率、索引积压和故障恢复等细节影响实际表现。Mem0 迁移时按客户建立独立 namespace，避免全局向量检索后再过滤身份。然而，一个用户不等于一个 namespace，个人与团队数据权限不同，namespace 作为隔离单位不必与 user ID 一一对应，权限设计可能孕育新产品机会。
Q&A
为什么作者认为通用的 Memory API 很难标准化？
因为记忆与产品设计、工程架构和模型深度耦合。什么值得提炼成长期记忆、两条相反的历史如何呈现、Agent 何时主动提起过去，都难以用通用 API 定义。而且检索结果是否进入上下文取决于 Agent 的工作方式，不是仅靠相似度就能决定。
Turbopuffer 的架构如何降低冷数据的存储成本？
Turbopuffer 把 namespace 的持久数据放在对象存储里，query server 由许多 namespace 共用。不活跃的 namespace 不必常驻内存保留索引，请求到来时节点从对象存储读取所需数据，之后查询可利用内存和 local ssd 缓存，路由也会尽量利用已缓存该数据的节点。
Turbopuffer 的冷查询延迟有多高？产品可以如何掩盖冷启动？
官方百万文档例子中，第一次查询 p50 为 874 毫秒，缓存命中后为 14 毫秒。Notion 在打开可能使用搜索的对话框时先发一次预热查询，提前把冷数据读进缓存。Personal Agent 场景也可借产品交互掩盖冷启动。
Mem0 为什么也使用 Turbopuffer？它如何解决多租户检索问题？
Mem0 把原始 memories 放在 Postgres，将文本、embedding、元数据和指回原始记录的 ID 放进 Turbopuffer，检索先在 Turbopuffer 完成再去 Postgres 取完整内容。它按客户建立独立 namespace，避免在全局向量索引中先找候选再过滤身份的低效。
Turbopuffer 从向量搜索走向通用查询系统的原因是什么？
客户在向量搜索之外长出全文检索、属性过滤和 Linear 的 delta sync 等在线读取需求。原有围绕向量地址的存储布局在向量聚类变化、多向量表示和全文分块时成为约束，因此 v3 计划让 ANN 变成二级索引，改用更适合批量读取和列式执行的布局。
对于刚上线的 Personal Agent 产品，应该直接上独立搜索系统还是先用 Postgres？
用户还不多时，把对话和任务存进 Postgres，做必要的全文索引，向量需求出现后再考虑 pgvector/vectorchord，大概率比引入独立搜索系统省事。原始数据、事务和备份都已在那里，历史很短时直接查最近几十条记录交给模型读也可能是最好的办法。
