database · E1 预消化简报(2026-11-02)

作者：Jay 范围声明：依宿主机增量清单 d71a4202-68b2-455a-bff8-f7f12a8714b4（创建 20:20，有效期 1 小时），本轮只处理清单 item.materials 的 8 份材料（3 份 note-links + 5 份 repo_card/paper_card 实体），未做全库扫描、未做网页搜索补料、未为凑字数多轮重写。另按任务要求读取了 organized/queue/work-queue.md、organized/knowledge/database.md（活文档 R-111 现状）与 organized/knowledge/.database-candidate.md（R-112 候选稿，10-31 20:51）用于定位脉络，并对 organized/paper_cards/ 近 3 天刷新卡做了「主分类=database」的定向抽查。

一、今日该主题最重要的增量

增量 1（★ 净新增 · 云厂商托管型 Agent 数据层）· TencentCloudBase/CloudBase-AI-Toolkit：把 database / auth / functions 打包成 AI coding agent 的后端

• 来源：organized/repo_cards/4825-tencentcloudbase-cloudbase-ai-toolkit.md（清单材料 repo_cards:tencentcloudbase/cloudbase-ai-toolkit）· https://github.com/TencentCloudBase/CloudBase-AI-Toolkit
• 要点（卡面读数，未读 README）：1153★ · 周增 +0 · TypeScript · MIT · 最近提交 2026-11-02 · 主分类 agent · 形态 app · 分类 skill · 成熟度 research · 首采 2026-11-02；一句话简介 "Backend for AI coding agents on CloudBase — database, auth, functions via Plugin, Skills & MCP."
• 与活文档现有脉络的关系：database.md 与 R-112 候选稿检索「CloudBase」均命中 0，属本轴净新增。三处咬合：① 与 §2.12 生态观察形成「托管 vs 本地」对照轴 —— R-112 刚收的 cdeust/Cortex 与 R-110 的 edgeever 都是 local-first / 自托管，而 CloudBase 是厂商托管的 Agent 后端（云上 database + auth + functions + Plugin/Skills/MCP）；本页「托管型 PaaS 提供 Agent 数据层」此前几乎只有阿里云 Agentic DB（R-62）与 Oracle AI Database 26ai 两条厂商/学术锚，工程侧开源样本缺失。② 与 §3 争议 4「状态源之争：副本 vs 视图」正面对撞 —— R-111 的 zeabur 是减法（删掉自有库、以 K8s 实际配置为权威源），CloudBase 是加法（平台持有并托管数据层）；两件同源于本周，方向相反。③ auth/functions/database 同体托管，使鉴权与数据操作落在同一控制面，是「权限边界是否真的分离」的天然观察点——但卡面无任何架构或权限模型披露，本轮不得据此写任何安全论断。
• 建议归入：§2.12 生态观察新增一条（标注「托管型 · 1153★ · 未读 README · 无实测」）；§2.5 补一句与 zeabur 的方向对照；不升第四十层候选（形态 app / 分类 skill / 主分类 agent），不入 §2.14 综述计数，不触发 §2.1 决策树。
• 证据边界：仅一句简介 + 卡面元数据，未读 README、未核 CloudBase 的数据库引擎（是否 Postgres/自研）、未核 auth 与 functions 的实现边界；1153★ 且 周增 +0、首采当日，一个自然周内不足以判断增长趋势；「1153★ + 分类 skill」是采集态标签，不是质量判定。

增量 2（★ 净新增 · 学术锚点）· arXiv:2604.17227《Cloud-native and Distributed Systems for Efficient and Scalable LLMs — A Research Agenda》：LLM 系统的云原生编排坐标系

• 来源：organized/paper_cards/140-2604-17227.md（清单材料 paper_cards:2604.17227）· https://arxiv.org/abs/2604.17227 · DOI 10.48550/arxiv.2604.17227 · OpenAlex W7155070632 · S2 被引 4 / OpenAlex 被引 0 / 影响力被引 0 · 形态 survey · 主分类 llm-infra · 主题标 7 标签（含 database）· green OA · 上游来源文件 inbox/jay/2026-06-10-database-cloudnative-backend.md
• 要点：卡面 TLDR —— 对分布式 LLM 训练、推理服务、云原生编排、资源管理、异构计算与边云协同的代表性进展做分析，指出支撑规模化 LLM 需要从通用云基础设施转向 LLM-aware、跨层、自适应的系统；TLDR 中文补充点到数据管理、资源优化以及对 microservices / autoscaling / hybrid cloud-edge 的需求。一手核验（来自 tom 今日同批简报 inbox/tom/2026-11-02-rag-e1prep.md 的 arXiv API 记录）：标题全称如上，主分类 cs.DC，2026-04-19 提交，comment "51 pages, 5 figures"，作者含 Minxian Xu、Jingfeng Wu、Shengye Song、Satish Narayana Srirama、Mahmoud Javad。
• 与活文档现有脉络的关系：database.md 现行正文命中 0；但库内 archive/database-20260707-full.md 曾以「Cloud-Native and Distributed Systems for LLMs（45 页研究议程）」登记过（三处命中）。故本条是「旧轴曾记、后被瘦身轮次挤掉」的复活条目，不是全库首次发现 —— 今晚须按「补回 + 更正」写。三点咬合：① §2.5 云原生主轴的学术侧骨架 —— 本页 §2.5 现有锚点（K8s DRA / llm-d / Dynamo / Inference Control Plane / Build26-BRK223 / zeabur）全是系统与工程样本，没有一篇综述把「LLM-aware、跨层、自适应」写成方法论主张；与 trend 113/114 的「古典血统」路径不同源（那两条讲度量/规则/基准/接口/切分/目标，不是云原生）。② 「数据管理」与资源管理并列 —— 与本页把数据层当一等公民的立场同向，但综述提到不等于给出数据层方法，不得读出向量库/存储层结论。③ 与 §2.13 评估方法论的关系是坐标系而非证据（与 tom 在 evaluation 轴判读一致）。
• 建议归入：§2.5 作为「LLM-aware 云原生的学术侧上位论证」一小段（不作性能证据）；§2.14 不进综述八向量计数（主分类 llm-infra、且 database 主题标签为库内标签），与 R-111 对 1306.6709 的处理同口径；§6 arXiv 锚定可新增本 ID + DOI（该号确实未在现行 §6 列表中）。
• 证据边界与待核实：① ⚠️ 页数口径冲突 —— 库内 archive 记「45 页研究议程」，arXiv comment 记「51 pages, 5 figures」，以 arXiv 为准，库内旧记录待更正；② ⚠️ 卡片「可复用信息」块被污染 —— 该块写的是「KubeVirt 爆发 / 自动化 FinOps / GatewayAPI / 建议动作：工程实践参考，非学术」，来自上游 database-cloudnative-backend 笔记残留，与本篇学术综述自相矛盾，不得采信；③ 仅摘要层，未读正文；④ S2 4 / OpenAlex 0 / 影响力 0 的口径差只能并列记录，不得单源推断影响力。

增量 3（★ 净新增 · 安全侧骨架）· arXiv:2604.16548 长期记忆安全综述：六阶段 × 四目标

• 来源：organized/paper_cards/076-2604-16548.md（清单材料 paper_cards:2604.16548）· https://arxiv.org/abs/2604.16548 · https://arxiv.org/html/2604.16548v1 · DOI 10.48550/arxiv.2604.16548 · OpenAlex W7155049992 · S2 被引 26 / OpenAlex 被引 0 / 影响力被引 1 · 形态 method（主分类 rag）· 主题标含 database
• 要点：提出记忆生命周期框架，沿两轴组织攻击、防御及其跨阶段依赖 —— 六阶段（Write / Store / Retrieve / Execute / Share&Propagate / Forget&Rollback）× 四安全目标（Integrity / Confidentiality / Availability / Governance）；卡片 TLDR 中文给出其核心判断：鲁棒的长期记忆安全无法只在 retrieval 或执行阶段后置加固，必须从一开始就以存储阶段的溯源、版本化与策略感知 retention 为基础锚定。卡内另记「截至 2026 年 4 月，LLM 记忆安全研究证据基础异质性高」，并给出证据分级（Tier 1 顶会同行评审 / Tier 2 arXiv+workshop / Tier 3 博客与公司报告）。
• 与活文档现有脉络的关系：database.md 现行正文命中 0（本轴 NET-new）。三处咬合：① §2.8 十二攻击向量的分类学缺口 —— 本页十二向量是按攻击机制横切（pgvector CVE / 黑洞 / 推理成本攻击 / HDF5-Jinja2 / ImmRAG / SD-RAG / CLM 自注入 / HONEYBEE / 可见性边界等），从未给出「攻击发生在记忆生命周期哪一阶段」的纵轴；本篇六阶段是与现有横切正交的第二维，可作「攻击向量 × 生命周期阶段」矩阵的纵轴来源。② §2.3 记忆与 §2.4 存储引擎的接口 —— 「Forget&Rollback」对应 §2.4 的 WAL / redo log 双重用途与回滚语义，「Store 阶段的溯源与版本化」对应 §2.12 里的持久化层工作；这是本页唯一一份把「回滚/遗忘」写成治理义务的外部坐标。③ §3 争议 1 的第三类约束 —— 争议 1 争「按相似度 vs 按执行状态组织」，R-112 争议 5 争「谁拥有数据」；本篇提示第四问：这份记忆的保留与删除由谁定、依据什么定（Governance），且明确不能后置加固——与争议 5「权限落在确定性系统层而非生成侧」同源。
• 建议归入：§2.8 作为攻击向量的纵轴坐标系（一小段，明确「不新增第十四攻击向量」）；§2.3 补一句「Forget&Rollback 阶段的存储语义」交叉引用；§4 可考虑新立一条 O：六阶段是否值得成为本页记忆类工作的一级组织维度。不入 §3 共识（本轴无独立验证）。
• 证据边界：① ⚠️ 本篇在 engineering.md v111 已入库为锚点，risk.md / coding-agents.md / agent.md 均有登记 → 对 database 轴虽为 NET-new，但跨轴重复计数风险高，database 侧只能记「借用的坐标系」；② ⚠️ 卡片「可复用信息」块实为 TOKI（arXiv:2606.06240）内容误并，与本篇主题无关，不得采信；③ 证据分级三档是该综述自述，本页引用须写成「该综述自述」；④ 「90% 中毒率」等具体数字仅存于 engineering.md 历史归档，本简报不转述。

增量 4（净新增 · 检索后端）· arXiv:2610.35840 ACARE：Agent 上下文化的迭代式重排器

• 来源：inbox/jay/2026-10-28-1105-engineering-brief.md（清单材料 note-links:1172b85b…）· 清单链接 https://papers.cool/arxiv/2610.35840
• 要点：ACARE（Agent-Context-Aware Reranker for Iterative Search）针对「agent 生成子查询 → 文档打分 → 迭代收敛」这一形态，指出普通 reranker 只对子查询单独打分是该形态的失效模式；作者含 Jimmy Lin（已核实）；其主张为「小 agent 借更好检索工具缩小与大 agent 的差距」。权重、训练数据、代码均标注 will be released soon。
• 与活文档现有脉络的关系：database.md 命中 0（本轴 NET-new）。① 直接补 §2.1 决策树长期缺的一维 —— 该树只问「用什么索引 / 跑多快 / 重建成本」，从不问「检索结果的质量由哪一层决定」；ACARE 提示向量库之上还有一层重排层，且该层对 agentic 检索的失效模式与对人类查询不同。② 与 §2.13「RAG ≠ 向量 DB」九源锚定同族：提供「重排器对 agent 上下文敏感」这一机制候选，但不构成第十源锚定（无公开权重、无同层基线）。③ 与 §3 争议 3 相邻但不同轴 —— 谈的是打分粒度与查询上下文耦合。
• 建议归入：§2.1 作为「重排层：向量库之上的一层」补一小段（标「设计参考级，非可落地方案」）；§2.13 列为待跟踪源候选而非锚；不触发决策树版本升级。
• 证据边界：权重/数据/代码均未发布 → 当前不可跑通、不可复现，不能作为可落地方案或性能承诺；4B 具体型号、推理成本、search 次数降幅、训练配方、评测脚本均无 excerpt 支撑；论文标题页数等元数据未核。

增量 5（净新增 · 弱邻接）· arXiv:2610.35846 Preserve to Expand：能力扩展时用「合并」而非「重放」抑制遗忘

• 来源：同一份 note（note-links:1172b85b…）· https://papers.cool/arxiv/2610.35846
• 要点：问题设定为「扩展新语言/新能力时不重放源语言训练数据也保住已有能力」，机制是 source-aware 适配 + model merging 抑制遗忘。
• 与活文档现有脉络的关系：database.md 命中 0（本轴 NET-new）。与 §2.3「Agent 记忆/能力随模型版本更迭而失效」的问题族相邻 —— 本页在 O185、R-112 的记忆治理线索里都在追「记忆如何随模型换代仍有效」，本篇给的是参数侧的合并路线。必须明确标为跨域借鉴：本地无 ASR 栈，论文属语音识别域，方法学与本页数据层不同源。
• 建议归入：§2.3 补一条弱邻接（一行，注明「参数侧类比，非数据层证据」）；不入锚。
• 证据边界：excerpt 仅给问题定义与方法名，无参数量、版本、合并超参、基准数字与提升幅度，无法复现也无法估算成本；合并权重敏感性、遗忘量化口径、与 adapter-only 路线的对比均需原文正文。

增量 6（净新增 · 生态观察）· samrusani/AliceMemory：把事实、决策、未闭环事项放进同一个本地 SQLite 文件的 MCP 记忆

• 来源：organized/repo_cards/4784-samrusani-alicememory.md（清单材料 repo_cards:samrusani/alicememory）· https://github.com/samrusani/AliceMemory
• 要点（卡面读数，未读 README）：4★ · 周增 +0 · Python · MIT · 最近提交 2026-10-31 · 主分类 agent · 形态 app · 分类 ai · 成熟度 experimental · 首采 2026-11-01；一句话简介 "Open-source, local-first memory for AI agents. An MCP server that keeps facts, decisions and open loops in one SQLite file on your machine. MIT, public alpha."
• 与活文档现有脉络的关系：database.md 与 R-112 候选稿命中 0（本轴 NET-new）。① 与 §2.12 生态观察同形态簇 —— 与 R-112 刚收的 cdeust/Cortex（75★ · experimental · 本地 SQLite/PostgreSQL · 记忆 MCP）同属「单文件 SQLite 记忆 MCP」形态，而 Cortex 因自带可复现基准脚本才被记为「第四十层候选观察」；AliceMemory 无基准、无脚本 → 不得与 Cortex 并列升格。② 但它有一个 Cortex 没有的可写设计选择 —— 「事实 / 决策 / 未闭环事项（open loops）三类同文件」把 §3 争议 1 的「记忆按什么轴组织」从相似度轴换成事务生命周期轴（决策未闭环 = 状态未终止），与 MAGE「按执行状态连续性组织」工程侧同向但更朴素，且比 R-112 的 Crux AI（append-only 事件日志）更接近关系型表语义。③ 对照 O191 —— AliceMemory 同族但不同形态（单文件关系型记忆 vs 共享事件日志），可作 O191 的补充观察，不解决 O191。
• 建议归入：§2.12 生态观察新增一条（标「⭐最低档 · 4★ · public alpha · 标题级未核」）；§2.3 补一句「open loops = 事务生命周期轴组织」的设计观察；不升第四十层候选，不入任何源计数。
• 证据边界：4★ + 周增 +0 + public alpha + 仅一句简介，README 全文、存储 schema、并发与一致性模型全未核；「一个 SQLite 文件」是自述，不得据此推断其并发能力或规模；spark 已在 llm-infra 轴以最低档登记过同一件（跨轴重复，注意别两边各算一次）。

增量 7（净新增 · 工程批次）· MCP 网关鉴权与凭据泄露面、网关版本口径、OTel AI 埋点边界

• 来源：inbox/jay/2026-10-27-2105-engineering-brief.md（清单材料 note-links:a9f19eb0…）三条
• 要点（全部来自已核验 note 原文，本简报不联网复核）：① googleapis/mcp-toolbox CHANGELOG 最新 1.15.0（2026-10-22） —— 变更集中在自建 MCP 网关的鉴权与工具清单稳定性：Tool 接口移除 Authorized()、改由集中 authRequired 检查；auth/generic 校验 issuer claim；resource/file 路径清洗；bigquery allowedDatasets 排序以保证工具清单确定性；GCP exporter 关闭自追踪。note 内另记录一处外部摘要纠正（prebuilt/cloudsqlpg、mysql 查询计划、neo4j、observability 等条目实属 0.15.0 / 2025-09-18，非最新版）。② future-agi releases —— 页面正文确认 1.53.0（2026-10-21）存在且已有更新的 1.54.0（2026-10-22）；可引用条目：gateway provider 超时返回 504 且错误可写、gateway 强制执行 token 速率限制、每个重定向按配置 origin 校验、Gemini API key 排除出 URL 与错误信息、routing alias 的 model_override 透传上游。③ Fiddler《OpenTelemetry AI 可观测性指南》 —— OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT（采集 prompt/completion 前须评估数据治理与脱敏）、五层调用链结构化属性（应用/会话/代理/追踪/跨度）、Collector 统一管道；其论点是 APM 只看延迟分位与错误率，看不到检索代理的选源依据、摘要模型的幻觉、合规代理是否真的执行策略。
• 与活文档现有脉络的关系：database.md 检索「mcp-toolbox / Fiddler / future-agi」命中 0。三处咬合：① §2.5 / §2.12 的 MCP 数据面 —— 本页此前对 MCP 的记录停在「MCP 无状态化」「mcp-local-rag」「协议层」；这批给出网关层的具体实现面（鉴权集中化、清单确定性、速率限制、凭据不外泄），是「数据层可被安全暴露给 agent」的工程侧证据，与 R-105「工具接口稳定 → 清单确定性 → 缓存可复用」的推理链一致。② §2.8 的边界外样本 —— 「Gemini API key 排除出 URL 与错误信息」属凭据泄露面收敛，与 R-112 对 Cortex「凭据级权限 + 本地不出网」的处理同口径：属攻击面收敛，不构成第十四攻击向量。③ §2.11 可观测性（O182） —— Fiddler 那条给出「LLM 数据层可观测性的边界清单」（哪些能埋、哪些埋了要担数据治理责任），可作 O182 的输入材料而非结论。④ 版本口径纪律：1.53.0→1.54.0、0.15.0≠1.15.0 这类更正说明「最新版本」陈述极易过期，写入须带日期。
• 建议归入：§2.5 补一段「MCP 网关的鉴权与工具清单确定性」；§2.8 补一句防御侧记录；§2.11 补一句可观测性边界（挂 O182）；均不入层数/轴/综述计数。
• 证据边界：仅读 CHANGELOG / releases 页面 / 厂商博客正文，未看 PR diff 与配置文档、未验证向后兼容与升级影响面；Fiddler 为厂商视角营销内容，性能收益无实测支撑，正文尾部未逐段确认；504 与 token 限流的触发阈值与配置位置、重定向 origin 校验粒度、model_override 透传兼容性均未核。

二、台账（口径记录，不作新观点）

三、值得警惕的矛盾或待核实说法

1. ⚠️ 卡片「可复用信息」块系统性污染（本轮三例） —— 140-2604-17227 的块是 database-cloudnative 笔记残留（KubeVirt / FinOps / GatewayAPI /「建议动作：关注；工程实践参考，非学术」）；076-2604-16548 与 104-2606.07001 的块是 TOKI（arXiv:2606.06240） 的双时态运算符代数内容误并。三块均不得作为对应论文的技术主张引用；可采信范围仅限卡头字段 + TLDR + 元数据。这已是本库第二次成组出现（engineering.md v157 已登记为可核查采集缺陷），今晚入库前建议抽 2-3 张卡交叉核对。
2. ⚠️ 页数口径冲突：45 vs 51 —— 2604.17227 在库内 archive/database-20260707-full.md 记「45 页研究议程」，arXiv comment 记「51 pages, 5 figures」。以 arXiv 为准，库内旧记录待更正；database 侧若引用须原样带上这一冲突，不得静默采用其一。
3. ⚠️ 「本轴 NET-new」与「全库首次」不是一回事 —— 2604.17227 曾于 database 旧档（2026-07-07 full）登记、2604.16548 已在 engineering/risk/coding-agents/agent 多轴入库、2606.07001 已在本轴 §6 列表与 archive changelog 内。今晚凡写 NET-new，必须写成「在本轴现行正文 NET-new」，否则会制造三份互相矛盾的「首次发现」记录。
4. ⚠️ 被引口径必须多源并列 —— 2604.17227 = S2 4 / OA 0 / 影响力 0；2604.16548 = S2 26 / OA 0 / 影响力 1；2606.07001 = S2 5 / OA 0 / 影响力 0。S2 有量而 OpenAlex 为 0 是本轮三件的共同形态，不得据此断言影响力低，也不得据此断言高。
5. ⚠️ 未读 README / 未读正文的一律标为标题级 —— CloudBase（1153★）、AliceMemory（4★）均只有一句简介；ACARE 未开源权重与数据、不可复现；2604.17227 与 2604.16548 仅摘要层。「star 数高」「形态像系统」都不构成方法学证据；本周的 CloudBase 还是 +0 周增，不能写进任何增长趋势。
6. ⚠️ 跨域借鉴不得升格 —— 2610.35846 是 ASR 域的 model merging，与本页数据层不同源；ACARE 属检索后端而非数据库内核；Fiddler 属厂商视角营销内容、性能收益无实测。三者只能进 §2 的邻接/设计参考位。
7. ⚠️ 今晚可能被误用的「结构性升级」 —— 本轮材料中无一件构成性能证据，故不触发 §2.1 决策树升级、§2.12 层数递增（CloudBase / AliceMemory 均 app 形态、无实测）、§2.14 综述计数、§2.15 第三十五轴正式版、§3 共识 #1~#7 升级；§2.8 不新增第十四攻击向量（六阶段是纵轴坐标系，mcp-toolbox/future-agi 是攻击面收敛）。

四、可引用的 arXiv 号列表（本轮采用材料相关）

• arXiv:2604.17227 · https://arxiv.org/abs/2604.17227 · https://arxiv.org/html/2604.17227v1 · DOI 10.48550/arxiv.2604.17227 · OpenAlex W7155070632
• arXiv:2604.16548 · https://arxiv.org/abs/2604.16548 · https://arxiv.org/html/2604.16548v1 · DOI 10.48550/arxiv.2604.16548 · OpenAlex W7155049992
• arXiv:2610.35840（清单链接 https://papers.cool/arxiv/2610.35840 · ACARE · 无 DOI / 无 arXiv abs 页元数据在本轮材料内）
• arXiv:2610.35846（清单链接 https://papers.cool/arxiv/2610.35846 · Preserve to Expand · 同上，元数据未核）
• arXiv:2606.07001 · https://arxiv.org/abs/2606.07001 · DOI 10.48550/arxiv.2606.07001（重访，仅口径）
• arXiv:2606.09824 · https://arxiv.org/abs/2606.09824（定向抽查命中，已在 §6 锚定列表内，不重复登记）
• 附：污染来源 arXiv:2606.06240（TOKI）—— 不得作为 2604.16548 / 2606.07001 的内容引用

非 arXiv 出处（本轮采用材料的可核查 URL） - https://github.com/TencentCloudBase/CloudBase-AI-Toolkit - https://github.com/samrusani/AliceMemory - https://github.com/colinhacks/reylo（重访 · 口径漂移） - https://github.com/googleapis/mcp-toolbox/blob/main/CHANGELOG.md - https://github.com/future-agi/future-agi/releases - https://www.fiddler.ai/blog/opentelemetry-ai-observability-guide

五、给今晚接力的一句建议

本轮真正值得落笔的只有三件：2604.16548 的六阶段 × 四目标（给 §2.8 十二攻击向量补一条正交的纵轴，是本轮最有结构性价值的一条）、2604.17227 的复活与页数更正（旧档有、新稿无，且库内页数口径是错的）、CloudBase-AI-Toolkit 作为「托管型 Agent 数据层」的第三格（与 zeabur 的减法路线正好相反）。其余（ACARE / Preserve to Expand / AliceMemory / mcp-toolbox / future-agi / Fiddler）均为设计参考级或弱邻接，建议只进邻接位、不动任何计数。特别提醒：本轮三张 paper_card 的「可复用信息」块全部不可信，写入前请只用卡头字段与 TLDR。