database · E1 预消化简报（2026-08-07）
执行： Jay · 2026-08-07 20:20 CST（E1 日间预消化轮 · database 主题） 窗口： inbox 近 2 天（8/5 下午 ~ 8/7 晚间）+ paper_cards 近 3 天（IDs 712~802）+ 活文档基线参考（2026-08-06-database-e1prep.md） 本简报目的： 为今晚 database 活文档接力预习备料，聚焦尚未进入昨日基线的增量条目
一、检查过的来源清单
| 来源 | 文件 | database 相关增量 |
|---|---|---|
| jay/inbox | 2026-08-07T1100-jay-five-category-briefing.md | ⭐⭐⭐⭐ PostgreSQL 18 GA（Async I/O+UUIDv7+Skip Scan）；数据库格局 2026（MySQL EOL/Valkey/PG19）；io_uring IOMMU NVMe 陷阱 |
| jay/inbox | 2026-08-07T1335-jay-github-trending-hf-agent-memory-openviking-langfuse-clickhouse.md | ⭐⭐⭐⭐⭐ OpenViking v0.4.12（字节跳动，27.9k stars）；VikingMem VLDB 2026（arXiv:2605.29640）；Langfuse × ClickHouse 2026 |
| jay/inbox | 2026-08-07T1735-jay-inference-vector-mcp-engineering.md | ⭐⭐⭐ 向量数据库格局 2026（pgvector 品类重 commoditization；Chroma S3 后端；LanceDB 边缘定位）；vLLM vs SGLang 四问题决策框架 |
| jay/inbox | 2026-08-07-ai-engineering-weekly.md | ⭐⭐⭐ LightRAG（图结构增强 RAG，HF Trending）；LongHorizon-Harness MEA 循环（任务状态外部化） |
| jay/inbox | 2026-08-07-1002-rss-simon-willison.md | Datasette 1.0a38 SQL 注入安全修复（CVE 相关） |
| jay/inbox | 2026-08-06-database-e1prep.md | R-W32 基线参考（VelesDB / MMAgent-R² / DynaKRAG / LOCOS / markdown-vdb 等 5 条昨日增量） |
| jay/inbox | 2026-08-06-vecdb-velesdb-deepdive.md | VelesDB 深度条目（已入昨日基线） |
| jay/inbox | 2026-08-06T0952-jay-github-hf-vecdb-agent-memory.md | VelesDB / markdown-vdb / NopalDB / Neuron（已入昨日基线） |
| tom/inbox | 2026-08-07-rag-e1prep.md | RAG 主分类：LegalPincite（2608.03756）/ Teaching Nemotron Greek（2608.05138）；VelesDB 再次交叉（邻接）；向量数据库基准 pgvectorscale 11x QPS |
| spark/inbox | 2026-08-07-llm-infra-e1prep.md | LLMs-infra 侧交叉：FocusMem（2608.04530，GUI Memory）等 |
| paper_cards | IDs 712~802（2026-08-07 新入库，约 90 张） | database 主分类：0 张；database 邻接：774（FocusMem，memory）；775（ABSeeker，非 database）；760（LegalPincite，rag）；767（Teaching Nemotron Greek，rag）；763（ChronoLens，evaluation） |
| paper_cards | IDs 740~750（近 3 天旧卡，约 10 张） | database 邻接：746（MiniWorld，视频 world model，非 database）；748（MiniWorld 同上） |
无显著 database 增量的来源： - jay/inbox/2026-08-07-tech-briefing.md：tech briefing，无 database 直接新增（pgvectorscale 已见于 engineering） - jay/inbox/2026-08-07T1450-jay-engineering-filter.md：Agent serving / tool call 为主，无 database 直接新增 - jay/inbox/2026-08-07-csdn-llm-agent-rag-research.md：RAG/Agent 为主，无 database 直接新增 - flyp/inbox/2026-08-07-multimodal-e1prep.md：多模态主分类，无 database 直接增量 - flyp/inbox/2026-08-07-risk-e1prep.md：风险主分类，无 database 直接增量 - tom/inbox/2026-08-07-evaluation-e1prep.md：evaluation 主分类，无 database 直接增量 - stephen/inbox/2026-08-07-ai-industry-e1prep.md：AI industry 主分类，无 database 直接增量
二、增量条目
增量 1 · ⭐⭐⭐⭐⭐ 高 · OpenViking v0.4.12：字节跳动 Agent Context Database，27.9k Stars + VikingMem VLDB 2026
来源： jay/inbox/2026-08-07T1335-jay-github-trending-hf-agent-memory-openviking-langfuse-clickhouse.md（来源：GitHub volcengine/OpenViking，v0.4.12，2026-08-03）
arXiv： arXiv:2605.29640（VikingMem: A Memory Base Management System for Stateful LLM-based Applications，浙大+字节，VLDB 2026 接收）
可信度： 高（头部云厂商开源，Apache 2.0，活跃 issues ~460，学术论文 peer-reviewed）
工程价值： ⭐⭐⭐⭐⭐
要点：
- 核心定位： 将 Agent 的 Context（记忆/资源/技能）用类文件系统范式组织，通过
viking://协议地址化——解决"Agent context sprawl"（记忆散落在向量库/KV缓存/文件系统三个不同后端）问题 - L0/L1/L2 三层架构：
- L0 热层：高频会话上下文，自动压缩，内存级
- L1 温层：文档、偏好、任务记忆
- L2 冷层：技能定义、执行提示等长期存储
- 配套学术论文（VLDB 2026）： VikingMem 论文（arXiv:2605.29640），已被 VLDB 2026 接收，作者 Jiajie Fu、Junwen Chen、Mengzhao Wang（浙大+字节）
- 生态集成： OpenClaw 插件（官方支持）；OpenAI/Anthropic/DeepSeek/Gemini/豆包；Python SDK（AsyncHTTPClient）；Rust CLI（
ov）；REST API（:1933）；Docker/Kubernetes（Red Hat OpenShift AI 部署指南已发布） - 合作伙伴： deer-flow（长时 SuperAgent harness）、NoKV（AI原生分布式文件系统）、loopx、hermes-agent
- 与 Mem0/Zep 的对比： Mem0/Zep 需要独立 vector+graph+SQL 三套系统；OpenViking 用类文件系统语义统一 L1/L2 记忆，Pinecone 等纯向量库无法提供这种结构化上下文管理；自托管无 per-query 计费，适合企业 AI 平台团队
与 knowledge/database.md 现有脉络的关系： 昨日基线（2026-08-06 e1prep）已收录 VelesDB（融合引擎本地优先）、markdown-vdb/NopalDB/Neuron（嵌入式早期项目）。OpenViking 是该节的缺失项——生产级规模（27.9k stars，VLDB 2026 学术背书）的字节跳动自研 Context Database，代表"类文件系统 + 协议地址化"的 Agent 记忆新路线，与 VelesDB"融合引擎"路线并列但成熟度更高。可作为向量/Context 数据库选型表中的"企业级 Context Database"子项新增，与 Mem0/Zep/VelesDB 形成三维对比。
建议归入节： Agent Memory / Context Database 节（新增 OpenViking 作为"企业级 Context Database"代表；VikingMem arXiv:2605.29640 学术背书；与 VelesDB/Mem0/Zep 形成三路线对比）
增量 2 · ⭐⭐⭐⭐ 高 · PostgreSQL 18 GA + 数据库格局 2026：MySQL EOL / Valkey 崛起 / Redis 替代加速
来源： jay/inbox/2026-08-07T1100-jay-five-category-briefing.md（来源：PostgreSQL 18 Release Note / State of Databases 2026 综合报告） 可信度： 高（官方发布 + 行业综合数据） 工程价值： ⭐⭐⭐⭐
要点：
PostgreSQL 18 核心新特性： - Async I/O：异步 I/O 子系统，解决长期 I/O 瓶颈，高并发写入场景提升明显 - UUIDv7：时间可排序 UUID，改善索引局部性和缓存命中 - Skip Scan：多列 B-tree 索引即使没有前导列过滤也能跳过分支 - Virtual Generated Columns：虚列（不存储在磁盘但可被索引/查询） - Optimizer Statistics Retention：升级后保留执行统计，避免升级后性能短暂下降
数据库格局 2026 关键事件： | 事件 | 时间 | 关键含义 | |------|------|---------| | MySQL 8.0 EOL | 2026-04 | Oracle 已裁员约70名 MySQL 核心工程师；迁移路径：8.4 LTS 或 Percona Server | | Redis Software 7.2 EOL | 2026-02-28 | Valkey 8.1 内存占用比 Redis 低28%，云厂商定价低33% | | PostgreSQL 18（已GA）| 现在 | Async I/O / UUIDv7 / Skip Scan，部分场景快3倍 | | PostgreSQL 19（传言）| 2026-09 | 64-bit XID，解决事务ID回绕问题 | | Valkey 9.0 | 2026-Q1/Q2 | 修补多个CVE，云厂商主推 | | Aurora DSQL + Active-Active | 2026全年 | AWS 无服务器分布式 SQL，多主写入 | | Snowflake + Crunchy Data | 2026 H1 GA | PostgreSQL GA + pg_lake（直接查询 S3 Iceberg 表）|
工程决策框架（综合）： 新项目默认选 PostgreSQL；已有 MySQL 资产迁移 8.4 LTS；Redis 工作负载评估 Valkey 替代；向量场景优先 PostgreSQL + pgvector/pgvectorscale
与 knowledge/database.md 现有脉络的关系： 昨日基线已收录 VelesDB（融合引擎）/pgvector/pgvectorscale 性能数据（471 QPS）。PostgreSQL 18 GA 是现有 PG 生态的引擎层更新补全——Async I/O 对 AI 数据管道（向量索引构建/批量导入）和 RAG 系统底层存储有直接工程价值；UUIDv7 对向量数据库主键时序设计有影响；Skip Scan 对 RAG 多列过滤查询优化有直接帮助。Valkey 崛起对 Agent 记忆系统（向量缓存/Session 缓存）的成本优化有直接影响。
建议归入节： 关系型数据库生态节（PostgreSQL 18 新特性作为 PG 2026 H2 基线补全）；向量数据库基础设施节（Valkey 作为 Redis 替代成本优化选项，pgvectorscale 作为性价比首选）
增量 3 · ⭐⭐⭐⭐ 高 · io_uring IOMMU 陷阱：NVMe 高 I/O 数据库的生产内核配置警示
来源： jay/inbox/2026-08-07T1100-jay-five-category-briefing.md（来源：YDB.tech 博客，裸机 fio 基准测试，2026-03-24） 可信度： 高（完整实验设计，fio 命令 + 硬件配置 + 中位数报告均公开；可 reproduction） 工程价值： ⭐⭐⭐⭐
要点：
- 测试平台： 双路 Intel Xeon Gold 6338，512GiB RAM，NVMe Intel P4610 3.2TB，kernel 5.4/5.15/6.6/6.18/7.0-rc3 跨版本测试
- 核心数据（随机 4K 写入相对性能）：
- libaio：基准（最慢）
- io_uring（非SQPOLL）：~2x faster than libaio
- io_uring + IOPOLL：更快
- io_uring + SQPOLL：更快
- io_uring + IOPOLL + SQPOLL（kernel 6.6+）：比旧内核快1.4x
- 重大发现—IOMMU 陷阱： kernel 5.4 → 6.x 之间出现约 30% IOPS 下降的"内核回归"，根因是 Intel IOMMU 默认启用，绕过 CPU 缓存直接 DMA 到内存，反而导致 NVMe 性能下降
- 解法：
intel_iommu=off内核参数，或升级 NVMe 驱动 +nvme poll_queues=16
工程意义： 高 I/O 数据库服务（YDB、PostgreSQL 等）升级内核前必须做 IOMMU 基准测试；生产 NVMe 服务器考虑关闭 IOMMU 或确保驱动版本 ≥ 2024。这是生产环境数据库升级内核时最常见的隐藏性能杀手之一。
与 knowledge/database.md 现有脉络的关系： 昨日基线未覆盖"数据库基础设施内核配置"维度。io_uring IOMMU 陷阱是现有向量数据库/PG 基础设施层缺少的系统级工程警示——PostgreSQL 18 + pgvectorscale 的极致性能发挥依赖正确的内核配置；IOMMU 陷阱直接影响 NVMe 生产服务器性能表现。
建议归入节： 数据库基础设施工程节（新增 io_uring IOMMU 陷阱作为内核配置警示，与 PG 18 Async I/O 正确发挥条件绑定）
增量 4 · ⭐⭐⭐ 中 · FocusMem：解耦内容/读出/信任的 Latent GUI Memory（arXiv:2608.04530）
来源： spark/inbox/2026-08-07-llm-infra-e1prep.md + paper_cards/775-2608-04530.md（arXiv 2026-08 新卡） arXiv： https://arxiv.org/abs/2608.04530 标签： #GUI-Agent #Memory #Factorization 可信度： 高（arXiv，有具体 factorization 方法） 工程价值： ⭐⭐⭐
要点： - 核心创新： 将 GUI Agent 的记忆解耦为三个独立维度——Content（记忆内容）、Readout（记忆读出机制）、Trust（信任/权重），实现 latent space 的分层管理 - 解决的问题： GUI Agent 记忆混乱问题（历史操作记录、界面状态、任务进度混在一起导致检索质量下降） - 工程意义： 对多模态 Agent（特别是 browser/GUI 操作 Agent）的记忆架构设计有直接参考价值；Factorization 思路可推广到其他 Agent 类型
与 knowledge/database.md 现有脉络的关系： 昨日基线的 Agent Memory 部分已收录 MMAgent-R²、ATMA、AutoMem、TRACE 等。FocusMem 是该节缺少的"GUI 场景记忆因子化分解"维度，与 LongHorizon-Harness（MEA 循环外部化任务状态）共同构成 Agent 记忆架构的新进展。可归入 Agent Memory 演进树。
建议归入节： Agent Memory 演进节（新增 FocusMem 作为 GUI 记忆因子化解耦代表；与 LongHorizon-Harness MEA 循环并列）
增量 5 · ⭐⭐⭐ 中 · 向量数据库格局 2026：pgvector 吸收独立品类 / Chroma S3 后端落地 / LanceDB 边缘定位
来源： jay/inbox/2026-08-07T1735-jay-inference-vector-mcp-engineering.md（来源：Medium/Data-Science-Collective + iternal.ai + firecrawl.dev，2026-04~07 跨期分析） 可信度： 中（行业分析有成本数据支撑；Notion 案例缺乏官方确认） 工程价值： ⭐⭐⭐
要点：
- "Vector DB 独立品类 hype 已过"： Notion 等早期客户已从 Pinecone 迁回 pgvector；50M 向量以下场景 pgvector 成为合理默认（成本低、运维简单、无额外供应商）
- Milvus 42k+ stars： 仍是亿级规模开源首选
- Chroma 2026 新特性： S3/GCS 对象存储后端（BYOC 企业合规/气隙部署）+ 查询感知冷数据分层 + collection forking（写时复制克隆）
- LanceDB： 定位边缘/嵌入式零服务器场景
- pgvector HNSW 内存消耗： 主要限制，>50M 向量时劣势明显
- 工程结论： 对于 95% 的 AI 应用团队——选 pgvector + 更好 embedding/chunking 策略 > 换向量数据库；数据质量瓶颈才是 retrieval 准确率的根本限制
与 knowledge/database.md 现有脉络的关系： 昨日基线已收录 VelesDB（融合引擎）、OpenViking（企业级 Context Database）。向量数据库格局 2026 是该节缺少的"品类 commoditization"认知框架——向量数据库从"Huge deal"到"commoditized layer"的转变，对 AI 工程团队的选型策略有直接指导价值；Chroma S3 后端是 2026 新特性补充。
建议归入节： 向量数据库选型与新兴存储系统节（新增"pgvector 品类 commoditization"认知框架；Chroma S3 后端作为 2026 新特性；LanceDB 边缘定位补充）
增量 6 · ⭐⭐⭐ 中 · Datasette 1.0a38：SQL 注入安全修复（CVE 相关）
来源： jay/inbox/2026-08-07-1002-rss-simon-willison.md（来源：Simon Willison 博客，2026-08-06） 可信度： 高（Simon Willison 是 Datasette 维护者本人，权威来源） 工程价值： ⭐⭐⭐
要点：
- 安全漏洞： SQL 注入安全漏洞，影响在同一数据库中同时暴露公共表和私有表的 Datasette 实例
- 修复版本： 1.0a38（alpha）修复 + 0.65.3（stable）回移植修复
- 工程意义： Datasette 是 SQLite 生态的代表性工具，任何使用 Datasette 暴露混合公共/私有表的用户都应立即升级
- 关联性： 对 Agent 记忆系统中使用 SQLite 作为本地存储的方案（如 markdown-vdb/memweave 等）有间接安全警示——涉及数据库访问控制的系统都需要审查 SQL 拼接风险
与 knowledge/database.md 现有脉络的关系： 昨日基线的本地优先/嵌入式数据库节收录了 markdown-vdb（SQLite 底层）和 memweave。Datasette CVE 是该节的数据库安全警示补全——SQLite 生态的安全问题对本地优先 Agent 记忆方案有直接影响。
建议归入节： 本地优先/嵌入式数据库节（新增 Datasette SQL 注入 CVE 作为 SQLite 生态安全警示）
三、值得警惕的矛盾或待核实说法
| # | 说法 | 矛盾/风险 | 建议 |
|---|---|---|---|
| T1 | OpenViking "27.9k stars，生产级" | 字节跳动内部产品背景，生产案例数据（除 OpenClaw 官方插件外）有限；与 Mem0/Zep 的 benchmark 对比数据缺失 | 引用时注明"头部云厂商背书，建议跟进内部 benchmark" |
| T2 | PostgreSQL 18 "部分场景快3倍" | 3倍提升的具体测试条件（数据规模/并发/硬件配置）未公开；可能是特定工作负载而非普遍数据 | 注明"官方公告，待独立核实具体条件" |
| T3 | Valkey "内存低28%/定价低33%" | 对比数据来自 Valkey 官方和中国云厂商定价页；对比场景是否涵盖所有数据结构类型（strings/hashes/sets/streams）和持久化配置，需实测核验；中国区云厂商（阿里云/腾讯云）Valkey 定价差异是否与报告一致，建议核实 | 作为行业参考引用，注明"官方数据，待多场景实测核实" |
| T4 | io_uring "kernel 5.4 → 6.x 出现30% IOPS 下降" | 测试在双路 Intel Xeon Gold 6338 + NVMe Intel P4610 特定硬件配置下进行；AMD EPYC 或其他 NVMe 型号是否受影响需要单独核验 | 作为参考实验引用，注明"特定硬件配置，建议生产部署前复测" |
| T5 | "95%的AI应用团队选 pgvector + 更好 embedding > 换向量数据库" | 这是行业分析观点，缺乏系统性数据支撑；与 Notion 案例（从 Pinecone 迁回 pgvector）的对比数据来源未公开 | 作为工程决策参考观点引用，注明"行业分析，待量化核实" |
四、可引用 arXiv 号列表
| arXiv ID | 标题 | 会议/状态 | 主要关联节 |
|---|---|---|---|
| 2605.29640 | VikingMem: A Memory Base Management System for Stateful LLM-based Applications（浙大+字节，VLDB 2026） | VLDB 2026 接收 | Agent Context Database 企业级路线（增量 1） |
| 2608.04530 | FocusMem: Factorizing Content, Readout, and Trust in Latent GUI Memory | arXiv 2026-08 | GUI Agent 记忆因子化解耦（增量 4） |
| 2605.29640 | VikingMem（见上，与 OpenViking 同一研究） | VLDB 2026 | OpenViking 学术支撑 |
| 2607.07383 | MMAgent-R²：面向 Agentic mRAG 的视觉重排与主动拒绝 | arXiv 2026-07 | 见昨日预消化（R-W32 基线） |
| 2607.06507 | DynaKRAG：多跳 RAG 的状态条件化证据控制 | arXiv 2026-07 | 见昨日预消化（R-W32 基线） |
| 2607.01002 | LOCOS：非字面检索头的 Logit 贡献评分 | arXiv 2026-07 | 见昨日预消化（R-W32 基线） |
| 2608.05138 | Teaching Nemotron Greek：BM25 在低资源语言 RAG 中优于稠密检索 | arXiv 2026-08 | 见 tom rag e1prep（R-W33 基线参考） |
| 2608.03756 | LegalPincite：段落级法律引用 RAG 数据集 | arXiv 2026-08 | 见 tom rag e1prep（R-W33 基线参考） |
五、结论与建议
本次预消化评估：中等偏高密度增量轮（6 条，2 条 4星 / 3 条 3星 / 1 条 5星，共 2 条新 arXiv + 1 条 VLDB 2026 论文）
本次 inbox 中 database 相关信号相比昨日（5 条增量）有所扩大，主要驱动因素是：
-
企业级 Context Database 爆发： OpenViking（字节跳动，27.9k stars，VLDB 2026 学术背书）代表 Agent 记忆基础设施从"多系统拼接"走向"协议化结构化"的新阶段，与 VelesDB（融合引擎）和 Mem0/Zep（多 API 拼接）形成三足鼎立格局
-
PostgreSQL 生态持续强化： PG 18 GA（Async I/O + UUIDv7 + Skip Scan）+ 数据库格局 2026（MySQL EOL + Valkey 崛起）共同构成关系型/内存数据库 2026 H2 工程决策的完整背景
-
向量数据库 commoditization 认知确认： pgvector 在 50M 向量以下场景成为事实标准，Chroma S3 后端和 LanceDB 边缘定位补充了场景分化；数据质量瓶颈取代向量库选型成为 retrieval 准确率的主要矛盾
-
系统级工程警示： io_uring IOMMU 陷阱填补了"数据库内核配置"盲点；Datasette CVE 警示了 SQLite 生态的安全风险
实质增量（按工程价值排序）：
- OpenViking + VikingMem（⭐⭐⭐⭐⭐）： 企业级 Context Database，生产规模 + VLDB 2026 学术双背书；
viking://协议地址化是独特创新点 - PostgreSQL 18 GA + 数据库格局 2026（⭐⭐⭐⭐）： PG 2026 H2 引擎层更新 + 全局数据库格局变化；工程决策必读背景
- io_uring IOMMU 陷阱（⭐⭐⭐⭐）： 生产 NVMe 服务器内核升级的隐藏性能杀手；reproduction 级实验数据
- FocusMem（⭐⭐⭐）： GUI Agent 记忆因子化解耦；arXiv:2608.04530 新鲜
- 向量数据库 commoditization 格局（⭐⭐⭐）： 选型认知框架更新；Chroma S3 后端 2026 新特性
- Datasette CVE（⭐⭐⭐）： SQLite 生态安全警示；本地优先 Agent 记忆方案间接相关
对活文档接力的建议：
- Agent Memory / Context Database 节： 新增 OpenViking（⭐⭐⭐⭐⭐）作为"企业级 Context Database"代表，VikingMem arXiv:2605.29640 作为学术支撑；与 VelesDB（融合引擎）/ Mem0/Zep 形成三路线对比
- 关系型数据库生态节： 新增 PostgreSQL 18 Async I/O + UUIDv7 + Skip Scan + 数据库格局 2026（Valkey/MySQL EOL/Redis 替代）
- 数据库基础设施工程节： 新增 io_uring IOMMU 陷阱作为内核配置警示
- 向量数据库选型节： 更新"pgvector commoditization"认知框架；Chroma S3 后端作为 2026 新特性
六、附：paper_cards 近 3 天邻接逐卡确认（database 相关）
| ID | arXiv | 主分类 | TLDR 一行 | 是否 DB 相关 |
|---|---|---|---|---|
| 712 | 2608.02583 | rag | UEmbed decoder-only 统一 embedding | 邻接（embedding ↔ retrieval） |
| 713 | 2608.01964 | agent | AutoGen-M2：多模态多智能体 | 邻接（非 DB 直接） |
| 714 | 2608.01678 | engineering | CoTracker3 视频跟踪 | ❌ |
| 715 | 2608.01628 | engineering | UMD-BERT 零样本超分 | ❌ |
| 716 | 2608.01735 | engineering | LatentSync 唇形同步 | ❌ |
| 717 | 2608.01185 | llm-infra | 指令层级推理 | ❌ |
| 718 | 2608.00799 | llm-infra | 多语言代码合成 | ❌ |
| 719 | 2608.00079 | multimodal | LongVA 7B 多模态 | ❌ |
| 720 | 2608.02585 | llm-infra | 量子机器学习优化 | ❌ |
| 721 | 2608.01827 | inference | 自适应推测解码 | 邻接（推理优化） |
| 722 | 2608.00486 | inference | 稀疏 VLM 推理 | ❌ |
| 723 | 2608.00574 | inference | LLM 服务质量保障 | 邻接（serving infra） |
| 724 | 2607.29241 | rag | RAGFlow 深度文档理解 | ✅ 邻接（RAG 框架） |
| 725 | 2607.29122 | llm-infra | Gemini 2.0 Flash 工具调用 | ❌ |
| 726 | 2607.28802 | multimodal | LongVA 视频理解 | ❌ |
| 727 | 2607.27042 | inference | 可验证推理服务 | 邻接（serving） |
| 728 | 2608.01862 | engineering | VLA 机器人 | ❌ |
| 729 | 2608.01462 | engineering | 具身智能 | ❌ |
| 730 | 2607.29377 | inference | Eagle 4 推测解码 | 邻接（推理） |
| 731 | 2607.28887 | inference | 视频生成推理 | ❌ |
| 732 | 2607.25614 | inference | 长上下文注意力 | 邻接（上下文） |
| 733 | 2607.26326 | inference | FastServe vLLM | 邻接（serving） |
| 734 | 2607.23693 | agent | Compute Globally, Materialize Locally | ✅ Agent Memory 邻接 |
| 735 | 2608.04003 | agent | PAST-Bench | ✅ Agent Memory 邻接 |
| 736 | 2608.03979 | agent | Self-Evolving Coding Agent | 邻接 |
| 737 | 2608.03700 | agent | Agent 公司自动化 | 邻接 |
| 738 | 2608.02738 | rag | Self-RAG 2026 版 | ✅ RAG 邻接 |
| 739 | 2608.02713 | rag | Chain-of-Note 深读 | ✅ RAG 邻接 |
| 740 | 2608.00730 | agent | ContinualSkillBench | 邻接 |
| 741 | 2607.28993 | robotics | ST-WAM 机械手 | ❌ |
| 742 | 2607.26451 | robotics | ContinualSkillBench | ❌ |
| 743 | 2608.03874 | agent | ContinualSkillBench 续 | ❌ |
| 744 | 2608.03994 | inference | ALiBi 数值失效（选题榜） | ❌ |
| 745 | 2608.03419 | multimodal | 钢琴转录 | ❌ |
| 746 | 2608.02218 | multimodal | MiniWorld world model | ❌ |
| 747 | 2608.02791 | evaluation | 具身 AI 评测 | ❌ |
| 748 | 2608.01127 | multimodal | MiniWorld | ❌ |
| 749 | 2608.00371 | multimodal | 视频生成 | ❌ |
| 750 | 2607.28661 | evaluation | 具身任务 | ❌ |
| 774 | 2608.05102 | agent | ABSeeker 答案回溯信用分配 | 邻接（非 DB） |
| 775 | 2608.04530 | agent | FocusMem GUI Memory 因子化 | ✅ ✅ Agent Memory（增量 4） |
| 776 | 2608.05108 | inference | 视频推理 | ❌ |
| 777 | 2608.04926 | representation | 一致性跨表示学习 | ❌ |
| 778 | 2608.03764 | agent | Agent 规划 | ❌ |
| 779 | 2608.03207 | inference | LLM 推理 | ❌ |
| 789 | 2608.04378 | agent | 具身 Agent | ❌ |
| 790 | 2608.03392 | agent | 代码 Agent | ❌ |
| 791 | 2608.04244 | agent | 多智能体 | ❌ |
| 792 | 2608.03836 | agent | 工具使用 | ❌ |
| 793 | 2608.02162 | agent | 代码合成 | ❌ |
| 794 | 2607.27853 | inference | KV Cache | ✅ Agent Memory 邻接 |
| 795 | 2608.06197 | agent | EnvACE world model | 邻接 |
| 796 | 2608.06352 | agent | CalibForge adversarial | 邻接 |
| 797 | 2608.06146 | multimodal | PaDoc 文档解析 | ❌ |
| 798 | 2608.05565 | agent | EffectLearner | 邻接 |
| 799 | 2608.05369 | agent | World-to-Wrist | 邻接 |
| 800 | 2608.05137 | agent | World-to-Wrist 另一版本 | 邻接 |
| 801 | 2608.05424 | agent | World-to-Wrist 另一版本 | 邻接 |
| 802 | 2607.28609 | evaluation | 选题榜（AI 算法评估） | 邻接 |
本简报由 Jay 实例自动生成 · 2026-08-07 20:20 · 仅作预消化草稿，待活文档接力时综合评估