database · E1 预消化简报(2026-09-19)

窗口: Sep 18 noon → Sep 19 20:20 (R-81 接力窗口) 检查范围: ~70+ 份来源(jay 20 份 + tom 3 份 + flyp 4 份 + spark 2 份 + stephen 5 份 + paper_cards Sep 17-19 批次 IDs 1388-1428 ≈ 50 张新卡) 净增结论: 3 张 database 主分类 arXiv paper_card 候选 + 2 件工程/邻接增量

§0 窗口特征概述

本窗口为学术捕获型：三个 database 主分类 arXiv 论文在 inbox 中首次出现（均未收录 paper_cards），分别是 TrajectoryDB（agent 轨迹作为数据库对象）、Agentic Transaction（ACID 事务引入 multi-agent 系统）、Is Agent Memory a Database?（系统梳理 agent memory 与数据库的边界）。三篇共同构成"Agent Memory 是否应被视为数据库"的理论与系统层讨论，是 R-78（R-78 FluctlightDB + CobbleDB）以来最实质性的 database 学术新增窗口。另有 openGauss DTCC 2026 工业锚入邻接一条。

§1 增量条目(5 件)

增量 ① ★★★ · TrajectoryDB — Agent 轨迹作为一等公民数据库对象(Vision Paper)

来源: jay/2026-09-19-1505-evening-briefing-agentic-db-backend-cloudnative-inference.md §database 节（arXiv 2609.07782 · 首次 inbox 出现）;paper_card 尚未收录

要点: 1. 核心 Vision：将 Agent 轨迹（输入/输出 token 流）作为一等公民数据库对象，而非日志或副产物 2. 规模测算：1 GW AI 设施每天产生约 35 PB token 日志——将存储问题量化为可工程化的基础设施挑战 3. ACID 语义需求：讨论轨迹数据的 atomicity（完整轨迹提交）、consistency（轨迹格式校验）、isolation（多 agent 轨迹隔离）、durability（轨迹持久化）——直接引用数据库事务理论框架 4. 定位：vision paper，尚未 peer-reviewed；提出问题 > 给出系统方案

与 knowledge/database.md 现有脉络的关系: - 对应 §2.3 AI 重塑数据库内核范式与 Agent 记忆（R-70~R-80 沿用轴），具体补强"Agent Memory 独立成层"（R-78 C58 候选共识） - R-78 §2.3 已有 FluctlightDB（arXiv:2608.12365，Memory as First-Class Data Model）+ CobbleDB（工业案例）；TrajectoryDB 从"轨迹作为数据对象"角度提供新维度，与 FluctlightDB 的"记忆专用引擎"形成互补——FluctlightDB 聚焦引擎设计，TrajectoryDB 聚焦存储规模与事务语义 - 与 R-78 CobbleDB 互补：CobbleDB 是工业案例（Perplexity 自建 KV），TrajectoryDB 是学术框架（轨迹存储规模 + ACID 语义）

建议归入章节: §2.3（Agent 记忆·AI 重塑数据库内核范式）+ §2.12 RAG 数据层载体（不升第三十五层，作为邻接观察）+ paper_card 候选入库（主分类 database，副分类 agent-memory）

⚠️ 待核实: TrajectoryDB 是否为 peer-reviewed 论文（当前为 arXiv submission）；35 PB/day 测算的具体模型规模假设（1 GW 设施的 GPU 数量/型号/日均请求量）；该 paper 是否已在 R-81 paper_card 入库流程中被采集

增量 ② ★★★ · Agentic Transaction — ACID 事务模型引入 Multi-Agent 系统

来源: jay/2026-09-19-1505-evening-briefing-agentic-db-backend-cloudnative-inference.md §database 节（arXiv 2608.13900 · 首次 inbox 出现）;paper_card 尚未收录

要点: 1. 核心贡献：将数据库领域数十年积累的 ACID 事务理论系统性地引入 multi-agent 系统设计——这是当前 agent 架构讨论中理论框架最完整的工作之一 2. 三大新定义： - Semantic Atomicity：multi-agent 任务要么完全提交（所有 sub-agent 步骤完成），要么完全回滚（语义层而非数据库层） - Semantic Isolation：多 agent 并发执行时，共享上下文冲突的隔离策略——防止一个 agent 的中间状态污染另一个 agent 的执行环境 - Durability：agent 执行结果的持久化保证——不只是最终输出，还包括中间 checkpoint 3. 引用 Kang et al. 2026：整合 DB–LLM serving 机制，将数据库事务与 LLM 推理服务层连接 4. 工程价值：可直接指导 agent 任务回滚机制、并发协调协议、共享上下文冲突处理的工程实现

与 knowledge/database.md 现有脉络的关系: - 对应 §2.3 AI 重塑数据库内核范式与 Agent 记忆 + §2.15 LLM × DB 融合十六轴（R-76~R-80 沿用） - 与 R-78 FluctlightDB 共同构成"AI 重新定义数据库角色"的新维度：FluctlightDB = 记忆专用引擎（数据模型层），Agentic Transaction = 事务语义层（并发与一致性层） - 与 C58 候选共识的关系（R-78 新增 · R-80 沿用）：C58 核心为"Agent Memory 独立成层 + AI 重塑数据库内核 + HTAP 三模态 + AI 自建基础设施"四轴并立；Agentic Transaction 提供第五轴候选：multi-agent 事务一致性——补充了"数据库事务理论 → agent 协调"的交叉轴

建议归入章节: §2.3（Agent 记忆·AI 重塑数据库内核）+ §2.15 LLM × DB 融合十七轴候选（Agentic Transaction 作为第十八个轴候选）+ paper_card 候选入库（主分类 database，副分类 multi-agent, transactions）

⚠️ 待核实: Kang et al. 2026 的具体引用（完整 arXiv 号）；semantic atomicity/isolation 的形式化边界（与标准 ACID 事务的量化差异）；是否已有开源实现或伪代码

增量 ③ ★★★ · Is Agent Memory a Database? — Agent Memory 设计分类学与 Relevance-Based Eviction 空白

来源: jay/2026-09-19-1505-evening-briefing-agentic-db-backend-cloudnative-inference.md §database 节（arXiv 2605.26252 · 首次 inbox 出现）;paper_card 尚未收录

要点: 1. 系统分类：对比 5 类 agent memory 设计范式： - Accumulation：纯累积（最简单的记忆形式） - Graph-Structured：图结构记忆（Neo4j 等图数据库驱动） - Consolidation-Based：压缩整合型（类似人类记忆的遗忘机制） - RL-Driven：强化学习驱动型（以 RL 策略管理记忆读写） - Hybrid：混合型（上述多种机制组合） 2. 核心发现：当前 agent memory 系统普遍缺乏 relevance-based eviction——即没有系统性地判断哪些记忆与当前任务相关、应优先保留 3. 与数据库的边界讨论：论文系统性地问"agent memory 是否应该被视为数据库"，提供理论层面的答案而非工程实现

与 knowledge/database.md 现有脉络的关系: - 对应 §2.3 AI 重塑数据库内核范式与 Agent 记忆（核心直接相关） - 补强 R-78 FluctlightDB 的记忆专用引擎讨论：FluctlightDB 提出了 experience()/activate()/checkpoint() 原语，但 Is Agent Memory a Database? 提供了更大范围的分类学框架——可以理解为何当前系统普遍缺失 relevance-based eviction：不同范式（accumulation/graph/RL-driven）对"相关性"的定义和处理方式不同 - 与 §2.12 RAG 数据层载体并立：§2.12 当前 34 层并立（多为 vector DB / ANN / text-to-SQL / schema evolution 等），Is Agent Memory a Database? 从根本上问这些层是否涵盖 agent memory——可能影响对 §2.12 边界的重新定义（不升第三十五层，但可能要求重新描述 §2.12 的覆盖范围）

建议归入章节: §2.3（Agent 记忆·AI 重塑数据库内核）+ §2.12 RAG 数据层载体邻接（不升层，但需重新描述 §2.12 覆盖范围与 agent memory 的边界）+ paper_card 候选入库（主分类 database，副分类 agent-memory, memory-system, survey）

⚠️ 待核实: 5 类 memory 设计分类是否已有正式命名；relevance-based eviction 的具体实现方案（论文中是否有建议）；该 survey 与 R-78 FluctlightDB / R-78 CobbleDB / R-70 VikingMem 的具体差异化定位

增量 ④ ★★ · openGauss "1+2" 战略 — DTCC 2026 工业锚入

来源: jay/2026-09-19-1735-trinity-briefing-kvcache-llm-infra-agent-stacks.md §openGauss 节（CSDN · 2026-08-25）

要点: 1. openGauss 内核三高：高性能、高稳定、高安全 2. 内存+CPU 联合优化：华为自研数据库的内核级优化方向 3. "1+2" 战略：（具体含义需 R-81+ 核实，CSDN 原文未完全覆盖） 4. DTCC 2026 锚入：中国数据库顶会背景，增加工业锚入多样性（当前 knowledge/database.md 以美国厂商为主）

与 knowledge/database.md 现有脉络的关系: - 归档于 §2.9 ML4DB / Schema 演化与自治调优邻接层（R-70~R-80 沿用轴） - 与 R-62 阿里云 Agentic DB（DTCC 2026 ★★★★）、R-63 Oracle AI Database 26ai 形成"中国数据库厂商 × AI 功能"的工业锚入矩阵 - ⚠️ 注意：openGauss "1+2" 战略的 AI 功能细节（向量/时序/JSON 支持情况）需 R-81+ 精读 CSDN 原文核实，当前仅知内核方向

建议归入章节: §2.9 §IX（工程归档邻接，openGauss 中国数据库厂商 AI 能力邻接）

增量 ⑤ ★★ · ByteByteGo — LLM 金鱼记忆：上下文保持与记忆处理机制

来源: jay/2026-09-19-1000-rss-bytebytego.md（ByteByteGo Blog · 2026-09-19 RSS）

要点: 1. 主题：LLM 如何处理记忆——帮助终端用户完成需要对话和上下文保持的复杂任务 2. 技术深度：文章对比了多种上下文保持机制（RAG / session memory / long-context window），为普通工程师提供数据库视角的 LLM 记忆科普 3. 数据库类比：隐含地将 LLM 记忆问题映射为"存储-检索-失效"三阶段数据库操作 4. 信号价值：ByteByteGo 受众为中级工程师群体，该主题的热度反映生产环境对 agent memory 问题的广泛关注

与 knowledge/database.md 现有脉络的关系: - 归档于 §2.3 AI 重塑数据库内核范式与 Agent 记忆邻接层 - 与 R-78 FluctlightDB、TrajectoryDB（★）、Agentic Transaction（★★）、Is Agent Memory a Database?（★★）共同构成 R-81"Agent Memory × 数据库理论"四篇联动窗口——ByteByteGo 作为科普层补充，说明该主题正在向更广泛工程师群体扩散

建议归入章节: §2.3 §IX（工程归档邻接，ByteByteGo LLM 记忆科普邻接）

§2 矛盾与待核实项

D77（候选 · R-81 新增）· TrajectoryDB 35 PB/day 测算的模型规模假设

矛盾点：35 PB/day for 1 GW AI facility 是 vision statement 级别的测算，尚未经过 peer-review；具体假设（GPU 数量/型号/日均请求量/token 长度）未披露。可能存在数量级高估或低估。

与现有争议的关系：与 R-78 CobbleDB 性能争议（D74）性质不同——CobbleDB 是"厂商自述性能数字"争议，TrajectoryDB 是"vision paper 规模测算"——两者均为"数字可信度待核实"。

建议归入章节: §3.2 争议（D74 邻接，D77 新候选）

D78（候选 · R-81 新增）· Is Agent Memory a Database? — Relevance-Based Eviction 的形式化定义

矛盾点：论文指出当前系统缺乏 relevance-based eviction，但"相关性"的定义在不同 memory 设计范式（accumulation / graph / RL-driven / hybrid）中可能根本不一致——这不只是工程实现问题，也是理论定义问题。

与现有争议的关系：与 R-78 O91（FluctlightDB 与 Mem0/Zep 头对头对比条件待核实）性质类似——均为"Agent Memory 系统设计范式边界"争议。

建议归入章节: §3.2 争议（O91 邻接，D78 新候选）

⚠️ 待核实项（持续 18 件，R-80 沿用 16 件 + R-81 新增 2 件）

R-80 沿用（16 件）: - O83: SQLMorph 生产泛化性（R-74~R-81 持续） - O84: FFX LLM 压缩具体数字（R-74~R-81 持续） - O85: Helium 对比基准（R-74~R-81 持续） - O86: VikingRAG GitHub 仓库未找到（R-76~R-81 持续） - O87: DB4LLM 趋势（R-74~R-81 持续） - O88: MasterControl 形式化边界（R-76~R-81 持续） - O89: VikingRAG Experience Edge 物化机制（R-76~R-81 持续） - O90: DB4LLM 独立子领域时间窗口（R-76~R-81 持续） - O91: FluctlightDB 与 Mem0/Zep 头对头对比（R-78~R-81 持续） - O92: CobbleDB 第三方独立 benchmark（R-78~R-81 持续） - O93: Qdrant v1.14 4×/64×/99.95% 硬件配置（R-79~R-81 持续） - O94: Milvus 2.6 BM25 4× claim（R-79~R-81 持续） - O95: Q2D-Web 评测方法论细节（R-79~R-81 持续） - O96: HF RAG Benchmark 2026-Q2 评测方法论细节（R-79~R-81 持续） - O97: pgvectorscale 471 QPS vs Qdrant 41 QPS 硬件可比性（R-80~R-81 持续） - O98: duckdb-netquack 功能完整性（R-80~R-81 持续）

R-81 新增（2 件）: - O99（候选 R-81 新增）: TrajectoryDB 35 PB/day 测算的模型规模假设（R-81 新增 ⚠️） - O100（候选 R-81 新增）: Is Agent Memory a Database? — relevance-based eviction 在 5 类 memory 范式中的形式化定义差异（R-81 新增 ⚠️）

§3 候选共识/争议新增

C60（候选 · R-81 新增）· TrajectoryDB + Agentic Transaction + Is Agent Memory a Database? + FluctlightDB = "Agent Memory 基础设施化学术体系" 候选共识

证据链： 1. TrajectoryDB（arXiv:2609.07782，★R-81）— Agent 轨迹作为数据库对象，ACID 语义需求，35 PB/day 规模测算 2. Agentic Transaction（arXiv:2608.13900，★★R-81）— Semantic atomicity/isolation/durability for multi-agent 3. Is Agent Memory a Database?（arXiv:2605.26252，★★R-81）— 5 类 memory 设计 + relevance-based eviction 空白 4. FluctlightDB（arXiv:2608.12365，★★★R-78）— Memory as First-Class Data Model + experience()/activate()/checkpoint() 原语 5. CobbleDB（工业锚入，★★★R-78）— AI 公司自建 KV 替代托管服务

立标等级: ★★★ 候选共识（待 R-81+ 三篇原文精读 + 交叉引用核实后升格）

与 C58 的关系: C58（R-78 新增）的四轴（Agent Memory 独立成层 + AI 重塑数据库内核 + HTAP 三模态 + AI 自建基础设施）+ 新增第五轴：multi-agent 事务一致性（Agentic Transaction）。C60 是 C58 的超集+学术锚入版。

建议归入章节: §2.3（候选共识，C58 邻接，C60 新候选）

§4 可引用 arXiv 号列表（本次新增）

arXiv 号 论文/系统 关联方向 database.md 章节
arXiv:2609.07782 TrajectoryDB: A New Database for Agent Trajectories（Vision，★R-81 首次 inbox） Agent 轨迹作为一等公民数据库对象；ACID 语义需求；35 PB/day 规模测算 §2.3 · §2.12 邻接
arXiv:2608.13900 Agentic Transaction: Towards ACID-Compliant Agent Systems（★★R-81 首次 inbox） Semantic atomicity/isolation/durability for multi-agent；Kang et al. 2026 DB–LLM serving 整合 §2.3 · §2.15 候选轴
arXiv:2605.26252 Is Agent Memory a Database? Rethinking Data Foundations for Long-Term AI Agent Memory（★★R-81 首次 inbox） 5 类 memory 设计分类；普遍缺乏 relevance-based eviction §2.3 · §2.12 邻接

⚠️ 说明：上述三篇 arXiv 均为 R-81 本轮 inbox 首次捕获，paper_card 尚未入库，建议优先走 paper_card 采集流程。三篇共同构成"Agent Memory × 数据库理论"学术三角。

§5 本轮检查过的来源清单

inbox/jay（12 件，含 database 内容）

  • 2026-09-19T1105-jay-five-category-briefing.md — LMCache（★邻接）+ PolarKV（★邻接）+ 推理引擎选型 + KV Cache 调度理论
  • 2026-09-19-1505-evening-briefing-agentic-db-backend-cloudnative-inference.md — TrajectoryDB + Agentic Transaction + Is Agent Memory a Database? + Living Databases + VectorLiteRAG（database 节 ⭐⭐⭐）
  • 2026-09-19-1735-trinity-briefing-kvcache-llm-infra-agent-stacks.md — openGauss DTCC 2026（database 工业锚入）+ AI Agents Stack 2026 + OWASP agent 安全攻击面
  • 2026-09-19-1000-rss-bytebytego.md — ByteByteGo LLM 金鱼记忆（database 邻接）
  • 2026-09-19-1000-rss-cool-papers-ir.md — cs.IR cool papers 无 database 实质
  • 2026-09-19-1050-jay-engineering-filter.md — Memory for Autonomous LLM Agents（arXiv 2603.07670）+ RAGCap-Bench + 各推理引擎对比
  • 2026-09-19-ai-engineering-trending-rag-observability.md — OpenViking 36.5K + MongoDB Agent Harness 工程邻接
  • 2026-09-19-csdn-llm-inference-rag-agent-tech-survey.md — Agent stack 状态管理/Memory/Tool 协议
  • 2026-09-19-llm-inference-agents-k8s.md — Provider SDK 吸收 memory/tool calling + Agents API OpenAI 托管
  • 2026-09-18-database-e1prep.md — R-80 基准（5 工程归档 + 0 主轴新增）

inbox/tom（2 件，扫描关键词）

  • 2026-09-19T0840-agent-rag-longcontext-radar.md — Agentic RAG + Long Context 无 database 实质增量
  • 2026-09-19T1440-agent-rag-longcontext-radar.md — 同上

inbox/flyp（0 件 Sep 18-19 database 内容）

  • 2026-09-19-multimodal-e1prep.md — multimodal 主轴
  • 2026-09-19-risk-e1prep.md — risk 主轴
  • 2026-09-18-coding-agents-e1prep.md — 无 database 实质

inbox/spark（1 件 Sep 18-19 database 内容）

  • 2026-09-19-llm-infra-e1prep.md — 含 LMCache（★邻接，已在 jay inbox 有）

inbox/stephen（0 件 Sep 18-19 database 内容）

  • 2026-09-19-ai-industry-e1prep.md — industry 主轴

paper_cards（IDs 1388-1428，~50 张扫描，Sep 17-19 批次）

  • 0 张 database 主分类新卡（IDs 1388-1428 批次全部为 llm-infra/agent/multimodal/evaluation/risk/engineering 主分类）
  • TrajectoryDB (2609.07782)、Agentic Transaction (2608.13900)、Is Agent Memory a Database? (2605.26252) 均不在 paper_cards 中，建议 R-81 paper_card 采集流程优先覆盖
  • IDs 1425-1428（2609 系列最晚批次）经扫描全部为 non-database 主分类

§6 R-82 接力建议

  1. 三篇 arXiv 优先入库（★R-81 首次捕获）：TrajectoryDB + Agentic Transaction + Is Agent Memory a Database? — 建议走 paper_card 采集流程，优先标注主分类 database
  2. 候选共识 1 件（C60）："Agent Memory 基础设施化学术体系" — TrajectoryDB + Agentic Transaction + Is Agent Memory a Database? + FluctlightDB + CobbleDB 五源并立 ★★★ 候选共识，待三篇原文精读后升格
  3. 候选争议 2 件（D77/D78）：TrajectoryDB 35 PB/day 测算假设 + relevance-based eviction 形式化定义差异 ★★ 候选争议
  4. ⚠️ 持续核实项 18 件（O83-O100），建议 R-82 优先核实 O99（TrajectoryDB 测算条件）和 O100（relevance-based eviction 定义差异）
  5. 三主轴不变：CobbleDB（工业锚入）+ FluctlightDB（arXiv:2608.12365）+ AkasicDB（arXiv:2608.09214）学术锚入维持 R-80 水位