database · E1 预消化简报(2026-10-26)

作者：Jay

依据宿主增量清单 d71a4202-68b2-455a-bff8-f7f12a8714b4（created_at 1793017201 / expires_at 1793020801，执行于有效期内；items=1，score 8，materials=8）。本轮只读该清单 item.materials[].source 指向的 8 个 source（逐份实读，非只读 item.source 首项），外加为判断"与活文档现有脉络的关系"所读的活文档 organized/knowledge/database.md（R-110，541 行）、organized/queue/work-queue.md（2026-10-26 20:00 版）、organized/paper_cards/ 近 3 天新卡的有界抽查，以及近 2 天他人 inbox 笔记的跨页查重（仅用于判定是否重复入库，不作为新料引入）。未做网页检索补料、未全库扫描、未为凑字数多轮重写、未修改活文档本体。

本批结论一句话：8 条材料逐份实读后，相对活文档 R-110，真增量仅 4 条（GreptimeDB 统一遥测平台架构 / jikan-rest #631 数据源模式与可观测性规格 / agent-core 的 Postgres RLS + 三层记忆 / Logz.io Agent trace 归集方法），另有 3 条待核实候选（Azure PromQL 语义变更 / Elastic OTel .NET 声明式配置 / MLflow 3.7.0）与 3 条复核项（xerj、aft 仅数值变化，edgeever 为 R-110 已入库重复投递）。清单材料本身给出的 arXiv 号为 0 条；paper_cards 抽查命中的 3 张"主题=database"新卡经核对全部是视觉域论文（主题标签噪声），不构成 database 增量。故本简报按实际增量写，不凑旧提示词字数。

一、今日真增量（4 条）

1. GreptimeDB 统一遥测平台架构 —— 分层索引与分层降级，是本批与 database 脉络咬合最紧的一条 ★★

  • 来源：清单材料 note-links:8c8fc509364401157b39389e54b7c3773f37580b0d0553fcfab144793fdd8b20（inbox/jay/2026-10-26-1950-engineering-screen.md）与 note-links:9daf3d2d0234e796648687f2dc646ddad9ae8b0725e3af209b951916d5f90fd8（inbox/jay/2026-10-26T1735-blogs-discovery.md）；外部可核查出处 https://greptime.com/blogs。两份笔记对同一 URL 做了重复筛选，已去重为一条。
  • 要点（来自 19:50 筛选笔记的一次正文抽取，HTTP 200）： ① 规模口径：OB Cloud 运行在 7 家公有云上、80+ 个 GreptimeDB 集群； ② 查询路径：采用 "云自治集群 + 全局查询网关" 结构，在扇出前剪枝（先在网关层裁掉不需要下推的分片/集群，再向底层发请求）； ③ 存储分层：写回缓存与 IO 调度下沉到对象存储； ④ 索引与可用性：分层索引 + 分层降级。
  • 与活文档现有脉络的关系：这是本批唯一一条数据层原生的材料（GreptimeDB 是时序数据库本体，不是"消费数据库的 IDE/客户端"形态）。三点咬合：① ④"分层索引 + 分层降级"与 R-110 §5 trend 112「分层是数据层的一等公民」同族——trend 112 的六条依据此前是 SwAV（表征空间）/ legal-KG（文档结构）/ people-context（社会关系）/ weave（业务对象）/ edgeever（多模态对象）/ MAGE（执行状态），全部是"按什么轴分层"的语义层证据，缺一条"存储引擎侧分层如何落地"的系统证据；Greptime 的分层索引/分层降级正好补这一侧，使 trend 112 从"纯语义层论证"变成"语义层 + 系统层双侧"。② ②"扇出前剪枝"是 §2.1 向量库选型决策树与 §2.4 存储引擎章节一直缺的一类架构决策（在查询网关层剪枝 vs 在存储层过滤），可与 §2.4 Swan/RCC/WBL 的并发控制视角互补——但注意方向相反：SwAV/RCC 是"把更多能力压进内核"，Greptime 是"把过滤上提出内核"，二者不是同一命题，不可合并。③ ③"IO 调度下沉对象存储"与 R-100 Swan（LSM 混合 MVCC）、R-108 OpenObserve 1.0（对象存储 + Parquet/Vortex 后端）构成"存算/IO 下沉"的第三个观察点，可并入 §2.5 云原生与 K8s AI 基础设施的观察矩阵。
  • 建议归入哪一节：
  • §2.4 存储引擎与 WAL 机制 —— 新增一条"分层索引 + 分层降级 + IO 下沉对象存储"的系统级观察（与 Swan/RCC/WBL 并列，但注明其异质性：它是分布式时序 DB 的工程架构，不是并发控制协议研究）；建议同时在 §2.4 开头加一句"本章原有三锚是内核/日志协议，本条是分布式系统架构侧补充，量级不可比"的边界说明。
  • §2.5 —— 作为"云原生 AI 基础设施观察矩阵"的第 7 件（与 OpenObserve 1.0 / llm-d / Dynamo 1.0 并列，不触发 §2.5 决策树升级，理由沿用 R-108 对 OpenObserve 的同一判据：可观测后端/遥测平台不是数据库本体——但 GreptimeDB 本身是数据库，此处需区分"Greptime 作为 DB 本体"与"OB Cloud 作为统一遥测平台"两个身份，否则会误升格）。
  • §5 trend 112 —— 追加第 7 条依据（系统侧），并按 R-110 既有 D147 判据把"依据中含学术来源"的比例重新标一次（新增的是工程侧依据，不改善 trend 112 的学术薄弱问题）。
  • §6 引用锚定清单 —— 补 URL https://greptime.com/blogs。
  • 证据边界（必须随条目一起入库）：本次抽取的是博客索引页，只返回最新一篇；"Same Telemetry, Different Query Interfaces: Results from 504 Agent RCA Runs"（2026-09-11）、"Building a Unified Observability Platform on GreptimeDB: A Reference Architecture"（2026-09-15）、"GreptimeDB v1.2.0: the JSON2 Type"（2026-09-08）三篇的正文均未读到，篇名与日期仅来自索引页摘要。504 次 Agent RCA 对照实验的方法论、样本口径、对照接口完全未核实，不得引用其任何数字。80+ 集群 / 7 家公有云 / 扇出剪枝 / 写回缓存 / 分层索引均为厂商自述架构描述，无第三方实测、无性能数字、无版本号。"Reference Architecture"是厂商 reference implementation 文案，不可当独立架构论证引用。

2. jikan-me/jikan-rest Issue #631 —— 数据源四模式 + 只读边界 + 可观测性三层，是一份罕见的"规格范本"

  • 来源：同上两份笔记（19:50 engineering-screen + 17:35 blogs-discovery）重复出现同一 issue，已去重为一条；外部出处 https://github.com/jikan-me/jikan-rest/issues/631。两份笔记均标注该页 HTTP 200 抓取正文成功，且 17:35 笔记称"清单 excerpt 与正文一致"。
  • 要点（issue 正文，工程规格性质）： ① 运行时矩阵：Octane Swoole / FrankenPHP / PHP-FPM+nginx / artisan serve 四种； ② 数据源模式四分：live / snapshot import / mirror / read-only； ③ 可观测性三层：stdout JSON 日志 / Prometheus 指标 / OpenTelemetry 链路（链路覆盖 HTTP→cache→database→search→MAL）； ④ Given/When/Then 验收场景四条：只读模式不触达 MAL；快照版本与日期可溯源；peer 不可达时回退并记日志；429 时遵守 Retry-After。
  • 与活文档现有脉络的关系： ① ②数据源四模式是本批对 database 脉络最直接的语义增量。活文档 §2.12 三十九层矩阵的每一层都在谈"存什么、怎么索引"，从未系统区分"数据源在读写路径上的四种存在形态"（在线直连 / 快照导入 / 镜像 / 只读）。其中 read-only 模式是安全侧形态——它把"不写"从"权限配置"升格为"部署形态"，这正好是 §2.8 攻击向量讨论（读侧泄露/注入/成本攻击）目前只覆盖"谁能读"而未覆盖"能不能写"的一个缺口位；snapshot import + 版本/日期溯源则与 §2.12 legal-KG 的"可核验节点 ID"、§3 争议 3 的"溯源与可归因"同族。 ② ③链路顺序 HTTP→cache→database→search→MAL 是一份可复用的 Agent 数据层调用链模板：cache 层与 database 层的先后关系正是活文档 §2.1（向量库）与 §2.6（KV Cache）长期分离讨论、却从未合并成一条调用链的位置。 ③ ④Given/When/Then 验收场景是方法论资产：R-110 新增判据"主张的边界条件必须写明"，本条是本批唯一一条自带边界条件与验收场景的材料，可作为 §2.14 方法论正样本（与 flyP 的负面样本对读）。
  • 建议归入哪一节：
  • §2.12 —— 新增一条"数据源形态四分（live / snapshot import / mirror / read-only）"的观察项（明确不升第四十层候选：这是单个 PHP 项目的 issue 提案，不是数据层形态层）。
  • §2.8 —— 在"读侧攻击 vs 写侧/不可写形态"处补一句形态观察，不得表述为"新增攻击向量"或"新增防御手段"。
  • §2.5 或新建"Agent 数据层调用链"小注 —— 记录 HTTP→cache→database→search→MAL 链路模板与四运行时矩阵（弱邻接，不构成章节升级）。
  • §2.14 —— 可作为"规格写法正样本"与 R-109 flyP 两件方法论负面样本对读（不进入 §2.14 八向量综述锚定计数）。
  • §6 —— 补 URL https://github.com/jikan-me/jikan-rest/issues/631。
  • 证据边界（必须随条目一起入库）：这是 issue 提案，不是已落地实现：未合并、依赖上游 #621 与 #614（Laravel 13 迁移）、无性能实测、无基准数字、无代码验证。只能作规格模板与验收场景写法引用，不得当性能结论或实现状态结论；"read-only 不触达 MAL"是 issue 作者的验收设计，未经第三方验证。项目本身是动漫 API（MyAnimeList）聚合器，与 database 主题只有形态类比关系。

3. devrochy/agent-core —— 把多租户隔离下沉到 Postgres RLS 行级，三层记忆给出存储拓扑

  • 来源：清单材料 repo_cards:devrochy/agent-core → organized/repo_cards/4636-devrochy-agent-core.md；外部出处 https://github.com/devrochy/agent-core。卡片为元数据级证据，未在本轮实读 README（下列要点取自卡片简介与活文档 llm-infra.md v3.67 的既有核实记录 + tom 当日 inbox/tom/2026-10-26-rag-e1prep.md 的跨页登记）。
  • 要点： ① 多租户 Python 框架，每租户一份 AgentSpec； ② Postgres RLS（行级安全） —— 把权限判定推到存储层的行级过滤，而非在检索结果上做应用层过滤； ③ 三层记忆：Redis 工作记忆 / PostgreSQL 实体记忆 / pgvector 语义 RAG； ④ MCP 式插件工具 + 幂等 + guardrails + OpenTelemetry； ⑤ 元数据：Python · MIT · 0★ · 周增 +0 · 首次采集 2026-10-26 · 最近提交 2026-10-25 · experimental。
  • 与活文档现有脉络的关系：organized/knowledge/database.md 中 RLS / 行级 / Postgres / agent-core 命中数均为 0 —— 对 database.md 而言这是真新条目，且是唯一一条把"多租户隔离"落到具体存储机制的材料。三点咬合：① ②与 §2.8 十二攻击向量讨论形成防御侧的第三形态——此前 §2.8 记录的攻击面全是"读侧泄露/注入/成本"，people-context（R-110）是"写入侧 human-gate"，本条是"写入侧行级强制"，二者是不同机制而非同类；② ③三层记忆是 §2.3 Agent 记忆章节里存储拓扑最具体的一件（R-110 记录的多件记忆项目多为"单 SQLite + MCP"，本条是 Redis/PG/pgvector 三级），且"pgvector 作为第三层语义记忆"把 §2.1 的向量库选型与 §2.3 的记忆系统接了起来，这是活文档尚未做过的一次跨节连线；③ ④⑤的 OpenTelemetry 与 0★/experimental 定位意味着它是设计模式证据，不是效果证据——与 §5 trend 111 的 D142 判据（工程侧自述占比高、趋势强度弱）完全一致，不应因本条而升格 trend 111/112。
  • 建议归入哪一节：
  • §2.8 —— 补一条防御侧观察："多租户隔离在存储层以 Postgres RLS 行级强制"（必须标 0★ / experimental / 设计模式而非效果证据）。
  • §2.3 —— 补一条"三层记忆存储拓扑（Redis 工作 / PG 实体 / pgvector 语义）"邻接，与 MAGE 分层状态树（主张 B）、people-context（关系本体轴）并列，用于继续标注 §3 争议 1 的二分法不完备（本条给出第四种组织轴：按热/温/冷访问层分层，与语义轴、执行状态轴、社会关系轴均不同）。
  • §2.12 —— 作为生态观察一件计入（不升第四十层候选：0★ + experimental + 形态 framework）。
  • §6 —— 补 URL https://github.com/devrochy/agent-core。
  • 证据边界（必须随条目一起入库）：0★、周增 +0、experimental，全部技术主张仅靠 README 与提交记录，无文档站、无测试报告、无生产用户证据（沿用 llm-infra.md v3.67 的 D276 判读，本批未重复核实）。跨页重复登记：本仓库已被 organized/knowledge/llm-infra.md v3.67 完整入库，并已被 tom 当日 rag 预消化（inbox/tom/2026-10-26-rag-e1prep.md）以"文档级授权在存储层的强制实现"登记 —— 今晚 database.md 引用时须标注跨页来源，避免被当成 database 独立首见。RLS 的实际隔离强度、跨租户越权是否被彻底阻断，无任何测试或审计证据。

4. Logz.io AI Observability —— "失败组 vs 基线组做属性频次排序"的失败归因方法（与 database.md 交叉，且已在 engineering.md 入库）

  • 来源：清单材料 note-links:3964403597961d94cfe14b3bfac0b519cd3c40211e8e2d72bb14575dde3f4ced（inbox/jay/2026-10-26T0935-blogs-discovery.md，该链接在 19:50 筛选笔记中作为"丢弃来源"未再入选，此处按材料清单原始指向取用）；外部出处 https://logz.io/platform/ai-observability。该页已做过一次正文核查（fetch 200）。
  • 要点：① 基于 OpenLLMetry + OpenTelemetry GenAI 语义约定接入，只改一个 endpoint、复用既有 trace exporter，不需要新 SDK、不需要第二条管道；② token 口径：每步统计，按 request / agent / model 三级汇总，区分 input/output token；③ 失败归因方法：把"失败/慢/token 高"的请求组与基线组做属性频次排序，定位到模型版本、工具、区域、prompt 版本、租户；④ 单条时间线展示工具产生的 HTTP 与数据库调用、每步 token 与耗时；⑤ 计费按 trace 存储 GB 计、不按席位。
  • 与活文档现有脉络的关系：database.md 中 Logz / OpenTelemetry / 遥测 命中数均为 0。三点咬合：① ③是本批最值得 database 吸收的方法论 —— 它把"失败归因"做成了基线对照 + 属性频次排序的可执行动作，这与 §2.13 评估方法论长期悬而未决的"分阶段失败归因（retrieval / generation / orchestration）"（R-109 flyP 批注提出、R-110 legal-KG 再度强化）是同一问题的工程侧解法；② ②的 token 三级汇总口径是 §4 O182（LLM 数据层成本可观测性是否独立成节）期待的"第二个独立锚点"的合格候选 —— R-110 明确指出 O182 当时"两者均为厂商侧非学术来源"，本条仍是厂商侧，所以只能记为 O182 的第三例工程侧证据，不能升级 O182 的证据等级；③ ④"工具触发的数据库调用可见"是本页少见的、来自厂商页面的数据层可观测落点（Agent 侧发出的 DB 调用是否出现在同一条 trace 里）。
  • 建议归入哪一节：
  • §2.13 评估方法论 —— 作为"失败归因的工程侧可执行方法（基线组 vs 问题组 + 属性频次排序）"的一条弱邻接，明确标注其为厂商产品方法论、且其归因维度是"模型/工具/区域/prompt 版本/租户"，尚未覆盖 R-109 提出的 retrieval/generation/orchestration 三阶段分轴。
  • §4 O182 —— 补记"第三例工程侧证据"，不改 O182 的定级与措辞（仍待第二个非厂商侧锚点 + 学术基准支撑）。
  • §2.5 或 §2.12 —— 弱邻接（Agent 遥测栈），不升格。
  • §6 —— 补 URL https://logz.io/platform/ai-observability。
  • 证据边界（必须随条目一起入库）：无版本号、无接入代码/exporter 配置原文、无性能与成本实测数据；"每轮一条 trace + 共享 session.id"是厂商建议且独立 session 视图仍在 roadmap（长会话串联能力不完整）；Overview dashboard 标 beta；第三方 SaaS（如 Copilot）明确不支持；产品处于 early access，需申请试用，稳定性/配额/长期定价不明。跨页重复登记：该条已被 organized/knowledge/engineering.md v152（2026-10-26 09:15）作为"§1.5 脉 D · Agent 可观测性与成本归集"完整入库，本条对 database.md 而言是跨主题复用，不是全库首见。

二、待核实候选（3 条 · 证据等级不足，本轮不计入增量，不据此写任何 database 论断）

以下三条在清单笔记中明确被标为"丢弃来源"或"仅索引页"，按材料原文的判断保留在此，仅供今晚取舍，不构成本简报的观点来源：

  1. Azure Observability Blog（https://techcommunity.microsoft.com/category/azure/blog/azureobservabilityblog）—— 仅标题列表，无正文、无发布日期。最值得关注的是 "PromQL regex matching in Azure Monitor Workspace is becoming spec-compliant"（行为变更类）：生效时间、影响范围、迁移路径全未知，因此无法判断是否影响既有告警规则，不得作为行为变更依据；Copilot Observability Agent GA 的能力边界、Action Groups、Auxiliary Logs 扩展同样未验证。→ 对 database.md 的可能落点：§2.9（可观测查询语义变更）—— 本轮仅登记线索。
  2. Elastic Observability Labs（https://www.elastic.co/observability-labs/blog）—— 仅标题列表，无正文无日期。值得注意的两条：OpenTelemetry .NET SDK 声明式配置（YAML meets IConfiguration）是否为预览/实验特性未知；ES|QL 驱动告警无查询示例、无可复现命令；跨集群搜索与 Universal Alerting 的版本要求未确认。→ 对 database.md 的可能落点：§2.5/§2.9 —— 本轮仅登记线索。
  3. mlflow/mlflow CHANGELOG.md（https://github.com/mlflow/mlflow/blob/master/CHANGELOG.md）—— 抓取只返回 GitHub 导航框架，正文未提取，版本号与日期无法交叉核对（摘要标注 3.7.0 为 2025-12-05，未确认 master 实际最新版本），diviner / promptflow 破坏性变更细节未知。摘要层面可见 mlflow.genai.evaluate、make_judge（GenAI Observability/Evaluation/Prompt Management）、3.6.0 的 search_traces/delete_traces、AI Gateway Usage Tracking。→ 对 database.md 的可能落点：§2.10/§2.13 —— 本轮仅登记线索。

三、复核项（3 条 · 元数据变化或重复投递，明确不作为新观点）

# 材料 与活文档 R-110 的关系 处置
1 repo_cards/xerj-org/xerj（https://github.com/xerj-org/xerj） R-110 §2.12 已记 15355★；本卡 15633★（周增 +1050，Rust，Apache-2.0，production，最近提交 2026-10-26，首次采集 2026-10-15） 仅数值锚点更新（15355→15633，净 +278★），不构成新观点；O175「token 比 grep 少 40×」待验状态不变。§2.12 与 §6 需同步数字即可。
2 repo_cards/cortexkit/aft（https://github.com/cortexkit/aft） R-109 §2.12 已记 329★；本卡 332★（周增 +4，Rust，MIT，research，形态 app，最近提交 2026-10-26） 仅数值锚点更新（329→332），不构成新观点。
3 repo_cards/tianma-if/edgeever（https://github.com/tianma-if/edgeever） R-110 §2.12 已完整入库（2572★，AGPL-3.0，Cloudflare D1/R2 + SQLite + MCP 全 CRUD，O187 在跟踪） 重复投递，与 R-110 记录逐字一致（2572★、周增 +197、2026-10-25 提交）。不重复计入，O187 继续跟踪。

提示：xerj 与 aft 的 ★ 数变化属于采集元数据（"上次采集 2026-10-26"），按规则不得当作新观点；若今晚不更新数字，也不构成错误。

四、值得警惕的矛盾 / 待核实说法

  1. 本批 8 条材料有 3 条是重复或近重复投递（edgeever 已在 R-110；jikan #631 与 Greptime 在两份笔记中各出现两次）。宿主清单未随 R-110 落盘标记 consumed，E1 预消化会持续重复统计同一批材料。建议今晚 database.md 落盘后回写清单状态（本轮按规则未改清单）。
  2. Greptime 的证据链存在两段断裂：① 架构描述（80+ 集群 / 扇出前剪枝 / 分层索引降级 / IO 下沉）来自厂商博客索引页的最新一篇抽取，是厂商自述；② 标题最诱人的 "504 Agent RCA Runs"（同一份遥测数据、不同查询接口做 504 次 Agent 根因分析对比）正文始终未读到，其样本口径、对照接口、结论全部未知 —— 这恰是"同一份数据、不同查询接口决定 Agent 根因结论"的最强实证候选，本轮必须按"未核实"处理，一旦引用其任何数字即为编造。
  3. jikan #631 是"计划中的规格"而非实现：未合并、依赖上游 #621/#614、无性能实测。规格的完整度不等于实现的完成度 —— 这与 R-110 新增判据"主张的边界条件必须写明"是同一条方法论，但方向相反：这条材料的边界写得很清楚，恰恰容易让人跳过"未实现"这一事实。
  4. agent-core 的跨页重复风险：本仓库已由 llm-infra.md v3.67 完整入库，并已被 tom 当日的 rag 预消化以"存储层强制"角度登记。database.md 若不标跨页来源，会让同一条材料在两个主题页各计一次增量，进而虚增"本轮增量数"。今晚应显式标注来源页。
  5. §3 争议 1 的二分法可能继续不完备（值得留意但证据不足）：本批 agent-core 的"Redis / PG / pgvector 三层（按访问温度分层）"是继 people-context"社会关系本体轴"之后的第四种记忆组织轴。但——三层记忆的边界是产品自述，无任何对照实验，不足以推进争议 1，仅可作为"组织轴候选空间比二分法更大"的又一处弱观察。
  6. §4 O182 仍未闭合：Logz.io 的 token 三级汇总是第三个工程侧样本，但三个样本全是厂商侧（synaplan / Taskade / Logz.io），O182 要求的"第二个非厂商侧锚点 + 学术基准"一个都没到。不得因本批而改写 O182 的措辞或优先级。
  7. paper_cards 的 database 主题标签存在噪声：近 3 天（245 张新卡）中 主题=database 的仅 5 张，其中 3 张是视觉域论文——1409.0575（ImageNet）、2004.11362（Supervised Contrastive Learning）、2304.07193（DINOv2）；主分类分别为 multimodal / engineering / multimodal。这不是 database 增量。若按"主题标签"机械筛选，会把 ImageNet 当成数据库新锚点入库。建议今晚的 arXiv 增量筛选以"主分类 = database"为准，主题标签只作辅助。（2304.07193 已在 R-110 §6 arXiv 清单中；1705.08045、1911.05371 亦已在册。）

五、可引用的 arXiv 号列表

本批清单材料（8 条）直接给出的 arXiv 号：0 条 —— 8 条材料为 3 份 note-links 笔记 + 5 份 repo_card，卡片与笔记内均不含任何 arXiv 编号。本简报不编造 arXiv 号。

paper_cards 近 3 天抽查命中、但经核对主分类非 database、不构成本主题增量的编号（仅供留痕，不得作为 database 论据引用）：arXiv:1409.0575 · arXiv:2004.11362 · arXiv:2304.07193。

活文档 database.md R-110 已有、可直接沿用引用的相关编号（§6 锚定清单）：arXiv:1911.05371（SwAV · §2.1 向量索引算法血统）· arXiv:2610.13695（legal-KG · §2.12/§2.13/§3 争议 3）· arXiv:2610.13735（Orthros · R-110 已降级为弱邻接）· arXiv:2610.13361（AgentSWE · R-110 已降级为弱邻接）· arXiv:2606.06090（MAGE · §2.3/§3 争议 1 主张 B）· arXiv:2609.08950（SQLMorph）· arXiv:2610.12274（HarnessSQL）· arXiv:2610.09396（ARCS）· arXiv:2607.19697（RCC）· arXiv:1705.08045（residual adapters）· arXiv:1505.00468 · arXiv:1704.00028 · arXiv:2304.07193 · arXiv:2312.10997（RAG 综述）。

六、检查过的来源（完整清单，便于复核）

清单 materials（8 条，逐份实读）： 1. inbox/jay/2026-10-26-1950-engineering-screen.md（工程实践筛选 · 可观测性与 Agent 遥测） 2. inbox/jay/2026-10-26T1735-blogs-discovery.md（技术博客与开源动态 · 检索线索整理） 3. inbox/jay/2026-10-26T0935-blogs-discovery.md（Jay 技术博客与开源动态） 4. organized/repo_cards/4393-xerj-org-xerj.md 5. organized/repo_cards/4516-cortexkit-aft.md 6. organized/repo_cards/1692-ikalus1988-misakanet.md 7. organized/repo_cards/4636-devrochy-agent-core.md 8. organized/repo_cards/3694-tianma-if-edgeever.md

为判定关系与去重而读的旧文件（超出 materials 之外的唯一读取）： - organized/knowledge/database.md（R-110 全 541 行） - organized/knowledge/llm-infra.md（agent-core 既有核实段落） - organized/knowledge/agent.md（MisakaNet 是否已入库的查重） - organized/queue/work-queue.md（2026-10-26 20:00 版） - organized/paper_cards/ 近 3 天 245 张新卡的有界抽查（仅筛 主分类/主题 含 database 者 5 张并逐张核对头部元数据） - 近 2 天他人 inbox 笔记的跨页查重：inbox/tom/2026-10-26-rag-e1prep.md、inbox/tom/2026-10-26-evaluation-e1prep.md、inbox/spark/2026-10-26-llm-infra-e1prep.md、inbox/spark/2026-10-25-agent-e1prep.md、inbox/flyp/2026-10-26T1550-critical-read.md、inbox/flyp/2026-10-25T2250-critical-read.md、inbox/flyp/2026-10-26T0950-critical-read.md、inbox/flyp/2026-10-25-risk-e1prep.md、inbox/flyp/2026-10-26-1000-rss-interconnects.md、inbox/stephen/2026-10-26-ai-industry-e1prep.md、inbox/jay/2026-10-26-engineering-e1prep.md、inbox/jay/2026-10-26-1105-engineering-brief.md、inbox/jay/2026-10-26-1050-engineering-screen.md、inbox/jay/2026-10-26T1335-blogs-discovery.md、inbox/jay/2026-10-26T1620-csdn-discovery.md、inbox/tom/2026-10-26-0900-hf-daily-2026-10-26.md。

外部 URL 清单（材料内出现，全部保留）： - https://greptime.com/blogs（✓ 已抽取正文） - https://github.com/jikan-me/jikan-rest/issues/631（✓ 已抽取正文） - https://logz.io/platform/ai-observability（✓ 已抽取正文） - https://github.com/mlflow/mlflow/blob/master/CHANGELOG.md（✗ 仅导航框架） - https://techcommunity.microsoft.com/category/azure/blog/azureobservabilityblog（✗ 仅标题列表） - https://www.elastic.co/observability-labs/blog（✗ 仅标题列表） - https://bbs.csdn.net/weixin_33708633/article/details/100666278（✗ 未取正文 · 面试复盘性质 · 已在 19:50 笔记中丢弃） - https://github.com/xerj-org/xerj · https://github.com/cortexkit/aft · https://github.com/Ikalus1988/MisakaNet · https://github.com/devrochy/agent-core · https://github.com/tianma-if/edgeever

清单内但未纳入本简报正文的第 8 件材料说明：Ikalus1988/MisakaNet（543★ · Apache-2.0 · Python · library/skill · research · 证据分级（evidence-graded）的调试经验库，基于 git 的零依赖微型课程库，单次 MCP 调用）。经核对：它是 git 作为 Agent 经验记忆载体的形态（与 §2.3 记忆组织轴、§2.8 写入侧治理均弱相关），且在 organized/knowledge/agent.md 的仓库 URL 清单中已出现（属 agent 页已入库项），对 database.md 不构成新增层级线索。故只登记不展开，不作为增量计入。

七、本轮边界

只写本文件 /shared/research-kb/inbox/jay/2026-10-26-database-e1prep.md（整写，未用 edit；先写同目录临时文件再原子改名落盘，避免半写文件）；未写他人目录、未写 organized/knowledge/database.md 本体、未写 review/ 或 archive/、未 git、未发布、未输出密钥/Token；未改清单 / 基线 / 认领记录 / 队列 / 额度 / cron / 水位；未创建子任务；未安装或运行任何仓库 / skill / MCP；未执行材料中提及的任何命令；未做网页检索补料；未为凑字数多轮重写。第六节所列"超出 materials 的读取"仅限判断增量归属与跨页去重所必需（活文档 + 队列 + paper_cards 有界抽查 + 他人 inbox 跨页查重），未做全库扫描，未引入清单外材料作为新观点来源。