主题综述 · database（2026-07-27）

  • 作者：spark
  • 更新：2026-07-27

本文综合 KB 内 paper_cards/ 主题 = database 的 15 篇纯标签卡片（含 HNSW/RAG 综述/DINOv2 等历史锚点）+ 跨主题多标签论文 4 篇（2606.16707 User as Code / 2607.21503 Agentic Context Management / 2607.20734 LLMs Get Lost in Evolving User Intent / 2606.16903 TrieHI）+ organized/promo/explainers/ 中相关解读（HNSW / MahNMF / DINOv2 / User as Code / Agentic Context Management 等）+ inbox/jay/2026-07-23~07-27-database-e1prep.md 系列预消化 5 份 + inbox/jay/2026-07-23~07-27 vecdb / pgvector / MCP / inference 简报 6 份 + organized/knowledge/database.md R-21 活文档（含 pgmnemo 0.14.0 单计划多模态 Agent 记忆 PGXN extension）+ 1 次 Tavily web 搜索补 2026-07 SIGMOD/PODS '26 + ANNLib arXiv 2607.17582 信号，对「Database × LLM / Agent 数据层」主题做第二轮深度综述（首轮见 2026-07-22-database.md）。本文与首轮互补：首轮聚焦"向量缓存 + ANN 评测 + DiskANN + GPU 混合 + 分布式 OLTP + LLM×DB 安全 + RAG 数据层"七件套；本轮收口到 「Agent 时代的数据库」—— 数据库成为 Agent 的可执行记忆 / 可编程上下文 / 可推理数据层 这一新切面，结合 7-23~7-27 五天的 inbox 增量。所有观点均附引用出处（arXiv 编号或 inbox / 活文档路径），不复用未核验的数字；待核验条目集中标注在 §5.3。

一、主题脉络：从「数据层操作系统」走到「Agent 的可执行记忆」

活文档 knowledge/database.md R-21（2026-07-27 00:40，jay）在第七块「Agent-First DB 三路径并行」已经把 2026 Q3 数据库赛道的核心矛盾点出：数据库不只是 LLM/Agent 的事实层，它正在变成 Agent 的可执行记忆层——既要承担 RAG / Agent 检索的事实层（vector / BM25 / graph hybrid），也要承担 Agent 状态的存储层（记忆系统 + KV cache 持久化 + multi-tier tiering），还要承担 LLM×DB 的双向融合（AI4DB / Text-to-SQL + LLM-as-Query-Engine + DB-as-LLM-Memory）。R-21 已经在「(v) 数据库与 Agent 记忆边界融合」一节追加了 pgmnemo 0.14.0 (PGXN 2026-07-24) 这个单计划多模态 Agent 记忆 extension 作为工程实证锚点。

把时间轴往回拉一格，2026 H2 的 database 主题演化可以压缩成五跳——前两跳在 7-22 综述中已覆盖（向量索引路线 + 关系型引擎吞并向量 + KV cache 当存储引擎 + 跨引擎 KV cache 服务化），本轮重点是后三跳：

跳 时间窗 主导问题 关键载体
跳 4 2025 H2 — 2026 H1 "Database = Agent 检索事实层" pgvector / pgvectorscale / Qdrant / Milvus / Pinecone
跳 5 2026 H1 — 2026 H2 "Database = Agent 持久化 KV cache" vLLM × Mooncake / LMCache / LCA / RetroInfer / HNSW-Merger / VeriCache
跳 6（2026 H2 进行中） 2026-06 ~ 2026-07 "Database = Agent 可执行记忆 / 可编程上下文" pgmnemo 0.14.0 / User as Code (2606.16707) / Agentic Context Management (2607.21503) / Trace (2607.00339) / SurrealDB / Memanto / GenDB
跳 7（即将） 2026 H2 "DB × Agent 安全与字节层新攻击面" pgvector CVE-2026-3172 (0.8.2) / Jailbreak (2607.07696) / PA-HDP (2607.14811) / SafeKV + PrefixWall
跳 8（酝酿） 2026 H2 末 — 2027 H1 "DB-as-Tool 在 Agent 协议层登台" MCP Tasks extension (SEP-2663) / Confidential MCP / agentctl

这五跳对应着一个核心判断：2026 H2 的 "database" 主题正在被 Agent 重写——从「被 LLM 调用的存储引擎」升级为「Agent 运行时一等公民架构基元」（The AI Engineer Substack 2026 引用 2024→2026 Memory 升格路径）。今天的综述围绕跳 6 / 跳 7 / 跳 8，按六个切片（可执行记忆范式 / ACM 生命周期范式 / 向量 DB × Agent 检索 / RAG × DB 隐私 / DB 安全新攻击面 / DB-as-Tool in MCP）展开。

1.1 与首轮（7-22）综述的边界

7-22 综述的八个切片 = 向量缓存层 / ANN 横向评测 / DiskANN 路线 / GPU 混合引擎 / 分布式 OLTP 新架构 / LLM×DB 安全 / RAG 数据层 / 跨引擎 KV cache 边界。本轮不重复那八块，而是聚焦：

  • 7-23~7-27 inbox 五天内新进入 KB / 活文档的信号（pgvector 0.8.2 CVE / pgvectorscale 50M 471 QPS 第二次独立量化 / AAAI 2026 Keyword Search 反向论断 / MCP Tasks extension / llm-d CNCF Sandbox 锚定 / pgmnemo 0.14.0）
  • 跨主题多标签论文中真正与 database 主线耦合的 4 篇（2606.16707 / 2607.21503 / 2607.20734 / 2606.16903）
  • HNSW 原始论文（1603-09320）的「被数据库底座化」视角——HNSW 作为 Milvus / QNSW / pgvector / FAISS 底层索引的事实标准，与 2026 H2 「Database-as-Agent-Memory」上层应用的对照

二、各工作贡献与相互关系

下面把 4 篇跨主题多标签论文 + 15 篇纯 database 标签论文 + 2 个顶会信号 + 1 个活文档锚点串起来，按六个切片组织。

2.1 切片 A：可执行记忆范式 —— User as Code 把 Agent 记忆从「事实袋」变成「类型化代码」

arXiv 2606.16707 · User as Code: Executable Memory for Personalized Agents（KB 卡片 paper_cards/010-2606-16707.md，主分类 agent，副分类 database；解读 organized/promo/explainers/2606-16707.md，Tom 2026-07-27 更新）

个性化 Agent 的「用户模型」目前主流有三种存储：非结构化文本（对话摘要）、知识图谱（属性图）、扁平标量存储（KV / 向量）。这三种方案共同的根本缺陷是存储事实与使用事实是分离的两个步骤。当你问 "我去年吃了多少种不同的处方药"，基于检索的记忆需要用这个问题去匹配历史上所有相关记录，再让 LLM 自己统计——这是搜索任务，不是计算任务，准确率必然崩塌。

UaC 范式的核心是让记忆本身可执行——当用户状态是一段有类型的 Python 代码时，"有多少种处方药" 就是一行 Python 代码的求值结果，不需要检索，只需要执行。实验数据：聚合查询准确率 99%，而基于检索的记忆系统仅 6–43%。

两阶段 pipeline：

  • Append-Only Log（只追加日志）：每一次交互以结构化日志形式追加写入，永不删除——保证可追溯性。
  • Checkpoint → Typed Code：定期把日志合并成类型化 Python 代码（用户状态 = typed Python objects，治理规则 = Python functions）。

与 database 主线的对应关系有三层：

  1. 范式层：把「数据库表 vs 向量索引 vs 文件系统」的三选一框架推到「Agent 解释器内的一段代码」。这是一个第四种存储形态——既不是表格，也不是图，也不是向量，而是「可推理的程序」。
  2. 存储层：append-only log 本质是 event sourcing / log-structured merge tree (LSM-tree) 的同构思路，与 §2.2 ACM 五原语里的 Ingesting + Scoping 直接呼应。
  3. 工程层：typed Python 对象替代了数据库 ORM / Vector DB schema——意味着 Agent 团队不需要维护 "数据库迁移 + ORM 演进 + 向量重建" 三条链路，只需维护一段 Python 代码的演进。

⚠️ 待核验：99% vs 6–43% 的对比基准未在论文中详细披露，需精读原文确认 benchmark 数据集规模、评测方法、是否考虑冷启动与跨会话漂移。KB 卡片 010 同时混入 2606.16903 TrieHI 信息，建议读 paper_cards/ 引用时注意区分。

2.2 切片 B：ACM 生命周期范式 —— Agentic Context Management 把记忆当作「生命周期」而非「存储」

arXiv 2607.21503 · Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems（KB 卡片 paper_cards/564-2607-21503.md，主分类 agent；解读 organized/promo/explainers/2607-21503.md，Tom 2026-07-24 更新）

主流思路把 Agent 记忆视为「存储 + 检索」问题，但本工作认为这个框架太窄。Production 场景下 Agent 的核心失败模式是上下文累积（quadratic cost growth）+ 简单摘要的精度悬崖 + 跨会话记忆缺失 + 上下文旋轮（context rot）。论文提出 ACM 学科，分解为五个原语：

原语 含义
Architecting 为不同数据类型设计合适存储架构——不是所有东西都适合放 Vector DB
Ingesting 决定什么信息值得被记忆，提取并结构化
Scoping 决定当前 Turn 需要什么上下文，跨组织范围管理
Anticipating 预判下一个 Turn 可能需要什么，主动提前拉取
（第五个原语未在摘要中详细展开） —

工程含义 = 三个「不要默认」：

  • 不要默认 vector DB 是所有 Agent 记忆的归宿——ACM 的 Architecting 原语要求「为不同数据类型选择最合适的存储」（架构图包含 KV store / Document store / Vector store / Graph store / Cold storage 的异构组合）。
  • 不要默认摘要无损——只有经过验证的压缩才能保持保真度。
  • 不要默认 Context 越大越好——Quadratic cost 是结构问题，不是优化器问题；只能从架构层面（生命周期 + 异构存储 + Anticipating 主动管理）下手。

与 database 主线的对应关系：

  • 把数据库的「角色」从被动存储推到了「主动上下文调度器」——这是 2026 H2 数据库主题最深刻的范式转移。
  • 与活文档 R-21 §1(v)「数据库与 Agent 记忆边界融合」完全对齐：ACM 提供了生命周期层面的形式化框架，pgmnemo 0.14.0 提供了PG 优化器层面的工程实证（详见 §2.6）。

⚠️ 待核验：第五原语在 explainer 中未展开，需读原 paper 确认完整五原语列表与各自工程化指南。论文 TLDR 明确指出「Actively managing what an agent holds in mind is a lifecycle, not merely a store」——这是 ACM 学科的核心论点。

2.3 切片 C：HNSW 与向量索引的「基础设施化」 —— 从算法到生产底座

arXiv 1603.09320 · Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs（KB 卡片 paper_cards/590-1603-09320.md，主分类 database，被引 188；解读 organized/promo/explainers/1603-09320.md，Tom 2026-07-26 更新）

这是 HNSW 原论文（HNSW = Hierarchical Navigable Small World graphs，由 Yury Malkov & Dmitry Yashunin 2016 提出）。在 2026 H2 把它纳入 database 综述并非「考古」——它的位置是所有现代向量数据库（Milvus / Pinecone / FAISS / Qdrant / pgvector）的底层索引的事实标准。

HNSW 的两个关键创新在 2026 H2 仍然具有生产级不可替代性：

  1. 多层图（multi-layer graph）+ 指数衰减概率分布决定层归属 P(layer > L) = exp(-L / λ)。每个元素插入哪一层由指数衰减概率决定——少数元素被「提拔」到高层，成为连接不同区域的「高速公路」；搜索从上层开始，利用长程边快速定位，再逐层向下精修。
  2. 稳定可预测的亚对数查询复杂度——KD-tree / Ball Tree 在高维稀疏时退化为近似线性扫描（维度灾难），LSH 需要大量哈希表才能保证召回率，NSW 收敛速度不稳定。HNSW 是首次在保证高召回率的同时实现稳定可预测亚对数查询复杂度的图索引。

与 7-22 综述里的 VeloANN / DiskANN / PASE / pg-storm 路线形成「全图景对照」：

  • HNSW (in-memory) 是当下所有生产向量 DB 的默认底层
  • VeloANN (SSD-locality graph) 是 disk-resident 路线的 2026 H2 新成员（10% mem = 92% in-memory 吞吐）
  • DiskANN / PASE / pg-storm 是「把 HNSW 搬到 SSD」的工程化路线
  • pgvector 0.8 halfvec + parallel HNSW + iterative scan 是「HNSW × PostgreSQL 集成」的最新生产化

与 database 主线的对应：HNSW 是「向量索引」从算法研究「基础设施化」的转折点——没有 HNSW 就没有「database × Agent 记忆」这一议题的物质基础。

⚠️ 待核验：HNSW 在 2,000 维以上场景需要 halfvec（FP16 量化），这是 pgvector 0.8 的能力边界——HNSW 本身维度上限在原论文未明确说明，需结合具体实现文档确认（pgvector 0.8 HNSW 限制 2,000 维，超出需用 halfvec）。

2.4 切片 D：向量 DB × Agent 检索 —— 选型收敛 + AAAI 2026 反向论断

arXiv 2607.11933 · Transforming LLMs into Efficient Cross-Encoders via Knowledge Distillation for RAG Reranking（KB 卡片 paper_cards/485-2607-11933.md，主分类 rag，副分类 llm-infra）

7-22 综述 §2.8 已覆盖。本轮在「数据库 × Agent 检索」切片下重新定位：用 4-bit 量化后的 LLaMA 3 (8B) 作为 drop-in cross-encoder reranker，意味着 RAG 流水线里的 rerank 层从「专用 cross-encoder 服务」演化为「与生成 LLM 同源同栈的量化 LLM」——这是 RAG 工程栈的「单 LLM 化」趋势（一个 LLM 同时承担 retrieval rerank + generation）。

AAAI 2026 反向论断：Keyword Search is All You Need（Subramanian et al.，来源 inbox/jay/2026-07-26T2105-evening-briefing-vecdb-mcp-inference-agentic-rag.md）

这是 2026 年 RAG / Database × Agent 检索领域最重要的颠覆性讨论之一：

  • 相同 LLM（Claude 3 Sonnet，200K 上下文），ReAct Agent 调用 pdfmetadata/rga/pdfgrep 等关键词工具 vs Bedrock Knowledge Base Titan Embeddings 向量检索，6 个数据集对比，结果差异极小。
  • FinanceBench（长表格型财务文件）：关键词搜索 30.40% vs 向量搜索 24.24%——关键词搜索反而超越。
  • 主流 Agent 产品已转向工具调用检索：Claude Code / Cursor / Windsurf / Devin / Cline / Sourcegraph Amp，均不再将语料索引进向量数据库，而是将检索暴露为工具让 LLM 自行决定调用时机。

与 7-22 综述的呼应：7-22 §2.8 已识别「向量召回率 vs 过滤性能」的工程权衡；AAAI 2026 这条反向论断把权衡推到了更激进的位置——如果关键词工具 + 长上下文 + ReAct Agent 能跑赢向量 RAG，那么「RAG-as-Database」的天花板可能就是「LLM context + 工具」。

⚠️ 待核验：AAAI 2026 论文原文 6 个数据集的领域、规模、是否包含多模态与跨语言任务，建议精读后确认结论可复现性。这条信号目前仍处于「高颠覆但未稳态」状态。

2.5 切片 E：RAG × DB 隐私 —— PA-HDP 给出「prompt-aware 动态分层」

arXiv 2607.14811 · Is External Database Protection Static in RAG? Rethinking Privacy Preservation under Dynamic Queries（KB 卡片 paper_cards/429-2607-14811.md，主分类 rag，副分类 database）

7-22 综述 §2.7 已覆盖。本轮在 database 主题下补充新视角：PA-HDP 把「保护粒度」从数据库级下沉到查询级——这是 RAG × Database 隐私的代表性新工作，与活文档 §2.5 安全小节互补（pgvector CVE-2026-3172 是 DB 引擎漏洞，PA-HDP 是数据层隐私框架，二者属于不同保护层）。

工程含义：在企业 RAG 场景里，同一个数据库对不同用户的不同 query 应该有不同的隐私保护强度——这是 differential privacy 在 RAG 场景下的「prompt-aware」重新表述。与 §2.6 pgmnemo 的「PG 优化器统一管理 join/filter/sort」形成对照：pgmnemo 是「数据层主动管理」，PA-HDP 是「数据层被动响应 query 风险等级」。

2.6 切片 F：活文档锚点 —— pgmnemo 0.14.0 单计划多模态 Agent 记忆

pgmnemo 0.14.0 (PGXN 2026-07-24)（来源 organized/knowledge/database.md R-21 §1 「🟢 R-21 Agent 记忆工程实证 · pgmnemo 0.14.0」 + inbox/jay/2026-07-27-database-e1prep.md 锚定）

PostgreSQL extension 把 HNSW 向量 + mem_edge BFS 图边 + JSONB GIN 元数据 + relational filters 四路召回融合进单条 SQL 查询计划。PG 优化器统一管理 join/filter/sort，用户调用单一函数。

benchmark 量化（LoCoMo turn-level, paper-canonical DRAGON）：

  • recall@5 = 0.302 / MRR = 0.237 vs DRAGON dense 0.225 → +7.7pp
  • LongMemEval-S (Wu ICLR 2025) retrieval-only = 0.9604 recall / 0.8472 MRR vs BM25 baseline 0.982 → 差距缩至 −2.2pp（v0.6.2 RRF Fix-A）

工程交付：

  • 「pgmnemo is pure SQL — no compilation」——pgxn install pgmnemo==0.9.5 即可装可用
  • Apple Silicon / 任何 PG 13+ 兼容
  • Docker 3 行 Dockerfile

与 database 主线的对应：把 R-19/R-20 §2.3「数据库与 Agent 记忆交叉」从概念 + 学术框架推进到「PGXN 上可装可用」的工程实证。与 SurrealDB 多模型 + Memanto 类型化语义记忆 + Agent Database 概念形式化（arXiv 2605.05287）共同构成 §2.3 完整证据链。

⚠️ 待核验：D18 benchmark 协议「272-session vs paper's 5882-turn (22× smaller)」口径待统一——这是活文档 R-21 新增的争议条目。

2.7 切片 G：DB 安全新攻击面 —— pgvector CVE + Jailbreak + AAAI 反向论断三向叠加

pgvector 0.8.2 (2026-07 安全补丁) CVE-2026-3172：并行 HNSW 构建存在堆缓冲区溢出，可导致跨关系数据泄露或数据库崩溃。所有使用并行 HNSW 构建的生产实例必须升级。托管厂商（Supabase / Neon / AWS RDS）发布往往滞后数周，需主动核验版本。来源：inbox/jay/2026-07-26T2105-evening-briefing-vecdb-mcp-inference-agentic-rag.md。

Jailbreak (arXiv 2607.07696)：7-22 综述 §2.6 已覆盖，LLM 直接读取 DB 存储文件绕过数据库引擎，端到端分析吞吐提升最高 27×，输出 Apache Arrow——既是 OLAP 性能工程化路径，也是「绕过 RBAC / 列权限 / 行过滤」的企业 DB 安全新攻击面。

AAAI 2026 Keyword Search 反向论断（§2.4 已展开）：暗示「Agent 时代的数据库访问模式正在从 SQL/JDBC 标准接口向「LLM-as-Query-Engine」演化——这把传统 DB 的访问控制边界全部打破，是更大的系统性风险」。

三向叠加的 database 主线含义：2026 H2 数据库安全的攻击面已从「DB 引擎漏洞 + 字节层绕过」扩展到「LLM 直接消费 DB 文件 + Agent 工具调用检索 + 跨会话记忆泄露」三维——传统 DB 安全的「RBAC + 加密 + 审计」三件套需要新增「LLM-aware access policy + memory privacy budget + cross-session isolation」三件套。

2.8 切片 H：DB-as-Tool in MCP —— Tasks extension 重塑异步工具调用

MCP 2026-07-28 Release Candidate（来源 inbox/jay/2026-07-26T2105-evening-briefing-vecdb-mcp-inference-agentic-rag.md，官方博客 modelcontextprotocol.io）

SEP 内容 database 主线含义
SEP-2663 Tasks extension 重塑生命周期：Server 返回 task handle，客户端通过 tasks/get/update/cancel 驱动异步任务 PostgreSQL MCP server 的查询从「同步请求/响应」升级为「异步任务」——长 query、批量 ETL、CDC 复制流可作为 task handle 暴露
SEP-2133 Extensions 独立版本管理（reverse-DNS ID） MCP 生态从「大统一规范」向「模块化插件」演进，database 相关 extension（pgvector / MySQL / DuckDB）可独立演进
SEP-1865 MCP Apps：server 推送 sandboxed iframe HTML 界面 富交互式数据库工具（schema explorer / query builder / vector sandbox）无需每个 host 单独实现 UI

与 database 主线的对应：

  • Tasks extension 直接影响数据库 MCP server 的设计范式——之前 MCP 的 tool call 都是 request/response，DB 长 query 会卡住 client；Tasks 把它升格为长生命周期对象。
  • Conf42 Cloud Native 2026 Meta 工程师演讲「Confidential MCP」（cMCP 三 zone 架构）= 数据库敏感数据在 MCP 层就有加密执行环境的工程化路径。

⚠️ 待核验：MCP 2026-07-28 RC 是「candidate」而非 stable，主流 client（Claude Desktop / Zed IDE / Cursor）支持时间表待观察。

2.9 切片 I：ANNLib 框架与顶会信号 —— SIGMOD/PODS '26 + AIDB@VLDB 2026

arXiv 2607.17582 · ANNLib: A Development Framework for Efficient ...（2026-07-20 提交）

ANNS 研究过去几年集中在「拓展功能」与「提升性能」两条路径上，但少有系统同时擅长两者。本工作提出 ANNLib 框架，统一容器（graph container，包括 HNSW / HCNNG / Vamana / Filtered Vamana）+ Bases（Static HNSW / Deletable Vamana / Vamana with snapshots）+ Mods（chrono list / 等增量更新机制）+ 树状 / 序列索引结构——给 ANNS 系统提供类似数据库领域的「存储引擎 + 索引 + 物化视图」分层架构思路。

SIGMOD/PODS '26 May 31 - June 5, 2026 Bengaluru：19/26 acceptance rate ≈ 73%（高接收率，顶会信号），含 Token-Centric Metrics for Agentic Schema Access（dl.acm.org/doi/10.1145/3814940.3815325）——这是 2026 H1 第一个明确把「Agentic Schema Access」当作一级研究对象的 SIGMOD 论文，把 Agent 访问数据库的「token 成本」立为新评测维度。

VLDB 2026 VecDB Workshop 2026-09-04 Boston + AIDB@VLDB 2026：作为 2026 H2 数据库 × AI 顶点场。

与 database 主线的对应：ANNS 研究从「单点优化」走向「框架化 + 模块化」；SIGMOD 把「Agentic Schema Access」立标；VecDB Workshop 与 AIDB 联会固化「database × AI」为一支独立学科——三件套共同把 database 主线在 2026 H2 推到了「学术学科化」的临界点。

三、三视角解读（工程 / 研究 / 批判）

3.1 工程视角（可落地性）

2026 H2 最具落地价值的三件：

  1. pgvector 0.8 + pgvectorscale = <50M 向量零决策默认（knowledge/database.md R-21 §1 + 7-25 database-e1prep 增量 1 + 7-26T2105 briefing 二次独立量化）。50M 471 QPS @ 99% recall / 11.4× vs Qdrant / 28× latency advantage vs Pinecone s1——这套组合把「关系型引擎吞并向量」从口号推进到「生产可比 benchmark」级实证。工程操作：<50M 已有 PG → pgvector+pgvectorscale；<10M 零运维 → pgvector 默认；>50M 强需求 → Qdrant；亿级 + 多租户 → Milvus。

  2. pgmnemo 0.14.0 = Agent 记忆「单 SQL 查询计划」落地（活文档 R-21 §1 + 7-27 database-e1prep 锚定）。工程操作：pgxn install pgmnemo==0.9.5 即可装可用，Docker 3 行 Dockerfile + Apple Silicon 兼容 + 任何 PG 13+。价值定位：中小规模 RAG / Agent 团队的「数据库原生记忆」首次有了工程化入口。

  3. MCP Tasks extension = 数据库作为长生命周期异步工具（§2.8）。工程操作：PostgreSQL MCP server 升级到支持 tasks/get/update/cancel，长 query / CDC 流 / 批量 ETL 暴露为 task handle。

工程警示三件：

  • pgvector 0.8.2 CVE-2026-3172 必须升级——所有使用 CREATE INDEX ... USING hnsw 的生产系统都应立即核验版本。
  • pgvector HNSW ef_search ≤ 200 是工程经验阈值（DBI-Services 2026-03）——超过 200 PostgreSQL 优化器会改走 Seq Scan + Sort（365ms vs 2.5ms），「建了索引但不生效」。
  • 索引体积警告：HNSW + B-tree 总体积约为数据本体 2–4.5×，高维向量场景须提前规划存储。

3.2 研究视角（创新性）

2026 H2 最有学术分量的三件：

  1. User as Code (2606.16707) —— 把 Agent 记忆从「事实袋」推到「可执行程序」。99% vs 6–43% 的聚合查询对比是该工作最具学术分量的实证——它证明了「存储与推理一体化」范式对「存储与检索分离」范式的代际优势。学术贡献：开辟了「Agent Interpretable State = Typed Program」研究方向，与软件工程领域的 live programming / notebook paradigm 形成对照。

  2. Agentic Context Management (2607.21503) —— 把 Agent 记忆从「存储-检索」推到「生命周期」框架。学术贡献：把「Architecting / Ingesting / Scoping / Anticipating」五原语形式化（第五原语待精读确认），建立了 ACM 学科的元方法论。与 7-22 综述的关系：7-22 §2.8 提到跨引擎 KV cache 已成「系统服务」；ACM 把 KV cache / Vector store / Document store / Graph store 全部纳入「Architecting 原语」的异构组合——这是更上层的形式化。

  3. ANNS 框架化 (2607.17582 ANNLib) + Agentic Schema Access (SIGMOD/PODS '26) —— 把 ANNS 从「算法研究」推到「系统框架」层；把数据库 × Agent 从「应用交叉」推到「评测学科」层。学术贡献：为后续 ANN 系统提供模块化基础（graph container + bases + mods）；为 Agentic DB 立评测基线（token-centric metrics）。

与活文档 R-21 §1(vii)「跨引擎 KV cache 2026 H1 = 系统服务」的关系：ACM 学科 + pgmnemo + User as Code + Agentic Schema Access 四件套共同把 R-21 七块切分推到「八块 = database × Agent 时代」——第八块就是「Database as Agent's Executable Memory」。

3.3 批判视角（局限）

最值得警惕的三个局限：

  1. AAAI 2026 Keyword Search 论断的颠覆性 vs 可复现性——如果 6 数据集 / FinanceBench 30.40% vs 24.24% 的结论在更大规模 / 更多领域上不成立，「数据库作为 Agent 检索层」这一命题就需要重新审视。批判角度：论文 6 数据集未必覆盖 RAG 真实工业场景（百万级 chunks + 多模态 + 跨语言 + 实时数据），长上下文 + 关键词工具的方案在 1M tokens 量级是否仍然成立是个开放问题。

  2. UAH 99% vs 6–43% 的工程可推广性——UaC 把 Agent 记忆变成 typed Python 代码，但类型系统本身的演进、依赖管理、错误恢复、并发安全都没有讨论。批判角度：typed Python 对象在生产 Agent 系统的可观测性 / 可调试性 / 可迁移性都未量化；与 ORM 在 2010s 面临的「schema evolution 灾难」是同构问题——typed memory 在 2027 H1 会不会也踩同样的坑？

  3. pgmnemo 0.14.0 单计划四路召回的优化器压力——把 HNSW 向量 + mem_edge BFS 图边 + JSONB GIN 元数据 + relational filters 全部塞进 PG 优化器，活文档 R-21 D18 标注：「benchmark 协议 272-session vs paper's 5882-turn (22× smaller)」口径待统一——这是 single-source-of-truth（PG 优化器）成为新性能瓶颈的预警。

3.4 反方证据：2026 H2 数据库主线的三个反直觉

  • HPC Scaling Paradox (arXiv 2606.08950)：256 workers 仅带来 5.46× 提速（从 16 worker 起点），更多核心反降低吞吐——「越大越好」在向量 DB 不成立。
  • GPU Vector Search 反直觉 (arXiv 2605.15957)：关系组件从 GPU 中受益 > 向量搜索组件——「GPU 一定加速向量搜索」不成立，NVLink 互联才是决定性。
  • pgvector 优化器异常 (D7)：ef_search > 200 优化器绕道 Seq Scan + Sort——「建了索引就生效」不成立。

这三个反直觉与本轮新增的两个反方信号一起构成 2026 H2 数据库主线的「反方证据带」：

  • AAAI 2026 Keyword Search 反向论断——「向量 DB 是 RAG 默认」不成立。
  • CVE-2026-3172 跨关系数据泄露——「向量扩展是数据库主键无害功能」不成立。

四、趋势判断与开放问题

4.1 2026 H2 三大趋势判断

  1. 「Database = Agent 可执行记忆」成为新范式：从 UaC (2606.16707) + ACM (2607.21503) + pgmnemo 0.14.0 + User as Code 到 SurrealDB 多模型 + Memanto + Agent Database (2605.05287) —— 这是数据库 × AI 在 2026 H2 最确定的演进方向。「数据库 = LLM/Agent 的事实层」是 2025 H1 共识，「数据库 = Agent 可执行记忆」是 2026 H2 新共识。

  2. 「向量 DB = RAG 默认」开始动摇：AAAI 2026 Keyword Search 论断 + 主流 Agent 产品（Claude Code / Cursor / Windsurf / Devin）全部转向工具调用检索 + pgvector CVE 安全顾虑 + HPC Scaling Paradox——三向叠加让「向量 DB = RAG 默认」在 2026 H2 从「不可撼动」降级为「待重新论证」。判断：2026 H2 末 — 2027 H1 「RAG-as-Database」vs 「Agent-as-Database-Tool」会出现新一轮立场分化。

  3. 「数据库安全」从 RBAC + 加密 + 审计 → LLM-aware access policy + memory privacy budget + cross-session isolation：CVE-2026-3172 + Jailbreak + AAAI 反向论断 + PA-HDP 四件套共同把数据库安全推向「必须考虑 LLM/Agent 攻击面」的新阶段。

4.2 2026 H2 四大开放问题

  • O1：向量 DB × Agent 检索的天花板到底在哪里？AAAI 2026 论文的 6 数据集结论在百万级 chunks + 多模态 + 跨语言 + 实时数据上是否仍然成立？
  • O2：typed memory (UaC) 在生产 Agent 系统的可观测性 / 可调试性 / 可迁移性如何？typed Python 对象演化会不会重蹈 2010s ORM schema evolution 灾难？
  • O3：pgmnemo 0.14.0 把 HNSW + mem_edge BFS + JSONB GIN + relational filters 全部塞进 PG 优化器，单优化器成为新瓶颈的概率有多高？是否需要「多优化器协同」架构（如 Cedar / NoisePage 路线）？
  • O4：MCP Tasks extension (SEP-2663) 在数据库工具上的成熟度——PostgreSQL MCP server 的长 query / CDC 流 / 批量 ETL 暴露为 task handle 后，主流 client（Claude Desktop / Zed / Cursor）何时支持？这决定 database-as-MCP-tool 在 2026 H2 末能否进入生产。

4.3 与七轮前（R-15）对比的范式跃迁

把 R-15（2026-07-20 左右）的「数据库赛道七块」与 R-21（2026-07-27）的「九块」并列，可以清晰看到过去 7 天 database 主线的范式跃迁：

R-15 七块 R-21 九块 新增块
(i) 关系型吞并向量 (i) 关系型吞并向量 —
(ii) 专用向量库推超大 (ii) 专用向量库推超大 —
(iii) HTAP 失败 + 云原生成熟 (iii) HTAP 失败 + 云原生成熟 —
(iv) AI4DB 数据质量 > 模型架构 (iv) AI4DB 数据质量 > 模型架构 —
(v) DB × Agent 记忆边界融合 + 反方证据 (v) DB × Agent 记忆边界融合 + 反方证据 + pgmnemo 0.14.0 工程实证 🟢 R-21 pgmnemo 单计划多模态记忆 PGXN extension
(vi) Agent-First DB 三路径 (vi) Agent-First DB 三路径 —
(vii) 跨引擎 KV cache = 系统服务 (vii) 跨引擎 KV cache = 系统服务 —
— (viii) R-19 LLM×DB 字节层安全 + 分布式 OLTP 解耦 + 向量 DB 工程化评测 🟢 R-19 强化
— (ix) R-19/R-20 强化「存储引擎现代化 + 解耦向量路线 + 索引原地更新 + HPC 扩展悖论 + 学术 VecDB Workshop + 云原生嵌入式向量索引」 🟢 R-19/R-20 强化

关键判断：R-15 → R-21 过去 7 天 database 主线的「物理增量」极少（pgmnemo 0.14.0 + 几条 inbox 信号），但「范式跃迁」极深——「Database × Agent 时代」的元命题从背景走到台前，从概念框架走到工程实证。

五、参考与待核验清单

5.1 主要参考来源

  • paper_cards/：15 篇纯 database 标签 + 4 篇跨主题多标签（2606.16707 / 2607.21503 / 2607.20734 / 2606.16903）
  • explainers/：1603-09320 HNSW (Tom 7-26) / 2606-16707 User as Code (Tom 7-27) / 2607-21503 ACM (Tom 7-24) / 1207-3438 MahNMF (flyP 7-26) / 2304-07193 DINOv2 (spark 7-21) / 2607-16859 Inf-Match (flyP 7-27)
  • knowledge/database.md R-21（2026-07-27 00:40，jay，388 行）
  • inbox/jay/：2026-07-23 ~ 07-27-database-e1prep × 5 + 2026-07-23-evening-database-backend-cloudnative-inference + 2026-07-23-1509-database-backend-cloudnative-reproduction-briefing + 2026-07-23-ai-engineering-backend-db-deployment + 2026-07-24-1105-noon-kv-rag-db-substack + 2026-07-24-1506-db-cloud-backend-csdn + 2026-07-24_engineering-database-csdn + 2026-07-25-1105-db-backend-cloudnative-inference-briefing + 2026-07-25-1610-evening-briefing-cncf-llm-d-rag-inference-vecdb + 2026-07-25-2105-evening-briefing-vecdb-arxiv-llm-stack-jul2026 + 2026-07-25-csdn-llm-rag-agent-vecdb + 2026-07-26T1735-jay-briefing-mcp-spec-agentframeworks-inference-vecdb + 2026-07-26T2105-evening-briefing-vecdb-mcp-inference-agentic-rag + 2026-07-27-1507-jay-briefing-agent-vecdb-k8s-stack2026
  • web search：2026-07 SIGMOD/PODS '26 + arXiv 2607.17582 ANNLib

5.2 综述 arXiv 号列表（按编号排序）

arXiv 号 标题 database 切片 主分类 来源
2606.16707 User as Code: Executable Memory for Personalized Agents A 可执行记忆 agent paper_card 010 + explainer
2607.21503 Agentic Context Management: Solving Agent Memory and Cost as Lifecycle and Architecture Problems B ACM 生命周期 agent paper_card 564 + explainer
1603.09320 HNSW: Efficient and Robust Approximate Nearest Neighbor Search using Hierarchical Navigable Small World graphs C HNSW 基础设施化 database paper_card 590 + explainer
2607.11933 Transforming LLMs into Efficient Cross-Encoders via Knowledge Distillation for RAG Reranking D 向量 DB × Agent 检索 rag paper_card 485（首轮 7-22 已覆盖）
2607.14811 PA-HDP: Prompt-Aware Dynamic Hierarchical DP for RAG External DB Protection E RAG × DB 隐私 rag paper_card 429（首轮 7-22 已覆盖）
2606.16903 TrieHI: Directory-Aware Query in Vector DBs (索引结构，跨切片) database paper_card 013（首轮 7-22 / R-20 已覆盖）
2607.17582 ANNLib: A Development Framework for Efficient ANN Search I ANNS 框架化 cs.LG web search 补充
2607.20734 LLMs Get Lost in Evolving User Intent (Agent 主题，跨切片) agent paper_card 569
2312.10997 RAG for LLMs: A Survey (RAG 历史锚点) rag paper_card 438
2607.07696 Jailbreak: LLM Reading DB Storage Files G DB 安全新攻击面 — arXiv（首轮 7-22 已覆盖）
2607.00339 TRACE: 时序证据图状态感知查询 (跨切片，RAG 数据层) — explainer 7-24
2605.17613 VeriCache: KV Cache Compression (跨切片，DB × AI 推理) — inbox 7-25（首轮 R-20 已覆盖）

5.3 待核验条目

# 说法 风险类型 状态
1 UaC 聚合查询准确率 99% vs 检索记忆 6–43%（arXiv 2606.16707） ⚠️ benchmark 数据集规模 + 评测方法 + 冷启动与跨会话漂移未披露 维持警示
2 ACM 五原语完整列表（arXiv 2607.21503，explainer 仅列四原语） ⚠️ 第五原语在 explainer 摘录中未展开 待精读
3 AAAI 2026 Keyword Search 论断 6 数据集结论可推广性 ⚠️ 6 数据集未必覆盖工业 RAG 真实场景（百万级 chunks + 多模态 + 跨语言 + 实时数据） 待精读
4 pgmnemo 0.14.0 「272-session vs paper's 5882-turn (22× smaller)」口径 ⚠️ benchmark 协议不一致，单优化器成为新瓶颈概率 维持警示（活文档 D18）
5 pgvector 0.8.2 CVE-2026-3172 跨关系数据泄露 ⚠️ 需立即核验所有生产 pgvector 版本（SELECT extversion FROM pg_extension WHERE extname = 'vector';） 维持警示
6 MCP Tasks extension SEP-2663 主流 client 支持时间表 ⚠️ RC 而非 stable，2026-07-28 后持续观察 待观察
7 ANNS 框架化 ANNLib (arXiv 2607.17582) 模块化是否真能平衡「拓展功能」与「提升性能」 ⚠️ 单一论文独立实验，模块组合爆炸的工程化挑战 待第三方复现
8 pgmnemo 0.14.0 vs DRAGON / LongMemEval-S 量化（+7.7pp / −2.2pp） ⚠️ paper-canonical DRAGON 配置与开源 DRAGON 实现细节是否一致 待精读

Spark · 2026-07-27 20:50 CST · cron_a7d6254f · database 主题第二轮综述（首轮 2026-07-22）