llm-infra · E1 预消化简报(2026-10-26)
口径声明：本轮由宿主机 work-guard 清单 job
3c698927-9044-4540-873b-f961d6380d7d驱动（created_at 1793011201 / expires_at 1793014801，本轮读取时未过期），items共 1 条（e1_prep:llm-infra，score 8）。本批新材料 =items[0].materials的 8 份，逐件读取materials[].source（非仅item.source首项），未做全库扫描、未开网页搜索补料、未为凑字数多轮重写。 对照基线：organized/knowledge/llm-infra.md（v3.67 · 2026-10-26 05:00 CST · §IX 124 morning）。该版已收录 agent-core（4636）、Ablation-Tool/ablation（4638）、Aryan-Pardeshi/CiteProof-AI-MCP（4505）。 交叉核对（仅作脉络对照与查重，不与清单材料混计）：organized/queue/work-queue.md（2026-10-26 18:00 生成，§2「待更新/缺失的主题活文档」= 0）；inbox/近 2 天 llm-infra 邻接笔记（tom2026-10-25-inference-e1prep.md/2026-10-26-rag-e1prep.md/2026-10-26-evaluation-e1prep.md、jay2026-10-26-engineering-e1prep.md、tom2026-10-25-rag-e1prep.md）；organized/paper_cards/近 3 天新卡（245 张）中的 llm-infra 主题条目抽查。 边界：只写本文件 1 个；未改活文档本体、未改清单 / 基线 / 认领记录 / 定时配置、未写他人目录、未 git、未输出密钥。 诚实度声明：本批 8 份材料全部是 GitHub Search 元数据级 repo_card（无 README 原文核查、无文档站、无测试报告、无基准）。凡本简报未标注"已核实"的机制描述，一律标注为卡片简介自述。采集时间戳 / 星数 / 周增 / 被引变化一律不作新观点。
0. 一句话判断
本批 8 份材料里，只有 5 份构成 llm-infra 主题的 NET-new 增量，且没有一条带 arXiv / CVE / DOI（四类计数沿用基线 arXiv 487 / CVE 36 / DOI 22 不变）；另 3 份（agent-core / Ablation / CiteProof-AI-MCP）是v3.67 已收材料的重复派发，仅 Stars 与分类字段刷新，不计增量。5 条真增量共同指向同一件事，且恰好是 v3.67 没写完的那一半：v3.67 用 8 件材料论证了"agent 运行时如何被约束"（契约 / 轨迹 / 护栏 / 隔离），但那批材料全部位于"约束侧"；本批补上的 5 件全部位于"记忆侧 / 路由侧 / 端侧侧 / 事实核查侧"，其中最有价值的是 gauravkumar62024/Entailment-Based-Fact-Checking —— 一件 AACL 2026 已被接收的论文级材料，把"事实核查"从应用层下沉为模型能力层的可训练目标（entailment 而非分类），这是本库此前完全没有的一层。材料不足以支撑改动 v3.67 骨架，今晚建议做 5 处登记 + 1 组矛盾续写。
1. 今日最重要的增量（5 条）
增量 ① · Entailment-Based-Fact-Checking —— 事实核查从"分类"下沉为"蕴含"的可训练目标 ★ 本批唯一论文级材料
- 来源：
organized/repo_cards/4650-gauravkumar62024-entailment-based-fact-checking.md→ https://github.com/gauravkumar62024/Entailment-Based-Fact-Checking - 要点（全部为卡片简介自述，README 与 AACL 2026 论文原文本轮未打开）：
- 论文标题自述 "Entailed Opinion Matters (AACL 2026)" —— 主张"被蕴含的意见也重要"，即在事实核查中不只问"主张是否为真"，还要问"主张是否被前提蕴含"；
- 改进路径：通过 entailment 提升 LM 事实核查能力；
- 覆盖三类任务：单语（LIAR-RAW、RAW-FC）、多模态（Factify-2、MOCHEG、VERITE）、多语（X-Fact、RU22Fact）；
- 卡片字段：Stars 0、周增 +0、Python、许可 NOASSERTION、最近提交 2026-10-26、首次采集 2026-10-26、成熟度 experimental、主分类 multimodal、主题 multimodal + llm-infra。
- 与活文档 knowledge/llm-infra.md 现有脉络的关系：
1. 真新条目：
Entailed Opinion/AACL/LIAR-RAW/VERITE/MOCHEG/RAW-FC/X-Fact/RU22Fact在organized/knowledge/全目录均 0 命中——本库此前没有"事实核查"这一独立技术轴，也没有 entailment 作为训练目标的记录。 2. 它是 v3.67 C374（"agent 生产化的缺口不在能不能做而在运行时能否被约束"）的补面：v3.67 的四类约束机制（契约 / 轨迹 / 护栏 / 隔离）全部作用于运行时行为；本件作用的是输入端的判断语义——同一个主张，在"蕴含"框架下可能被拆成"真/假/不可判/蕴含但意见"多个可训练标签。这是约束的前置形态：先定义什么叫"可核查"，再谈运行时怎么拦。 3. 与 v3.67 §0.5.1 ⑦ literature-review-assistant（PRISMA 全流程 agent 化 + RoB 2 / GRADE 质量评价）形成一条尚未合流的轴："可审计研究工作流"在本库已有节点，但那里的判定权交给了 LLM 评审者（对应 O640 "AI 评审 vs AI 评审的 kappa 前提是否成立"）；本件给出的是判定语义本身该怎么建模的另一个答案（蕴含建模）。两者应并读，但不可混为一谈——一个管流程，一个管标签空间。 4. 与 v3.67 D270（CiteProof-AI 与 CiteProof-AI-MCP 两仓关系未说明）相邻：CiteProof-AI-MCP 是引证可核查的 agent 工具，本件是事实核查的模型方法论，两者都在"可核查性"这条主线上，但一个是工具层、一个是方法层。 - 建议归入哪一节：
- §0.5.1 新增一条 repo_card 主棒位承载（编号建议插在 ⑧ 之后，作为 ⑨），标注"论文级（AACL 2026 accepted）+ 但 0★ / 无许可 / README 未核"；
- §3 共识：不新增共识条目（证据不足，仅 1 个仓库 + README 未核），但可作为 C374 的补面在其条目末尾加一句"约束语义层（何为可核查）尚未被现有四类机制覆盖"；
- §4 开放问题：新增一条 O642（编号待今晚活文档轮次确认）——"entailment 标签空间与 PRISMA 质量评价（RoB 2 / GRADE）两套判定语义能否对齐；两者的分歧样本如何裁定"；
- §6.99.2 arXiv 全量清单：不新增 arXiv 号（本件未给出 arXiv ID，AACL 2026 论文的 arXiv 号本轮未核实，见 §3 矛盾 ⑥）。
- ⚠️ 证据边界：README 与论文原文未读；"AACL 2026 accepted"仅为卡片简介自述，无 ACL Anthology 链接、无 DOI、无作者列表；许可 NOASSERTION；0★ 意味着无外部用户信号；三个数据集族共 7 个基准的具体评测结果全部缺失——本件提供的是问题表述与数据集清单，不是效果证据。
增量 ② · unibaseio/membase —— "记忆层"被拆成独立可交付制品（SDK + CLI + MCP） ★
- 来源：
organized/repo_cards/4664-unibaseio-membase.md→ https://github.com/unibaseio/membase - 要点（卡片简介自述，README 未核）："Memory layer for AI agents — SDKs, CLI and MCP server for Membase" —— 即把 agent 的记忆能力做成一层，三种交付形态并列：库（SDK）、命令行（CLI）、以及 MCP server；卡片字段：Stars 85、周增 +0、Python、MIT、最近提交 2026-10-26、首次采集 2026-10-26、成熟度 experimental、形态 tool / 分类 skill、主分类 agent、主题 agent + llm-infra。
- 与活文档 knowledge/llm-infra.md 现有脉络的关系：
1. 真新条目：
membase/unibaseio在 llm-infra.md 中 0 命中。 2. 它与 v3.67 ① agent-core 的"三层记忆（Redis 工作 / PostgreSQL 实体 / pgvector 语义 RAG）" 形成同一件事的两种产品化形态：agent-core 把记忆内嵌进运行时契约（三层是 AgentSpec 的一部分）；membase 把记忆抽成独立横切层，并主动提供 MCP server 形态——即记忆作为跨 agent 框架可插拔的能力，与 v3.67 §0.5.1 ② agent-inspect 的 MCP-style plugin tools、以及 v3.67 脉络 E 的"契约化"同源，但落点相反：一个是"记忆必须被约束"，一个是"记忆可以被复用"。这两条并读才能说清记忆层的现状：约束与可插拔正在同时推进，二者的张力尚未被任何一件材料处理。 3. 与本库既有的 agent 记忆谱系（mem0ai/mem0、okf-agent-memory、yshk-mxim/agent-memory、research.yandex.com 的 "The KV cache as an agent runtime"）相比，本件的新信号只有"三形态交付"这一点，是交付面信号而非记忆机制信号——存储模型、遗忘/合并策略、租户隔离语义均未披露。 4. 值得注意的分类选择：卡片把它归为形态: tool+分类: skill。这与本轮另一件 llm-task-orchestrator（主分类 engineering、形态 app）形成对照——同样的"基础设施件"，一个被归到 skill 侧（可被 agent 直接调用），一个被归到 app 侧（人机界面）。这本身是上游分类器的一个可观察分歧点。 - 建议归入哪一节：§0.5.1 新增一条（编号待定）；与 v3.67 ① agent-core 的三层记忆并读，在§3 共识处可考虑加一条"记忆层同时沿'可插拔横切层'与'运行时内建契约'两条路径演进，二者尚未在同一实现中共存"（预备级，证据为 2 个仓库的简介级描述）；§4 开放问题可新增一条"记忆层的可插拔化是否会削弱约束——MCP 形态的记忆是否继承宿主 agent 的租户隔离与删除权语义"。
- ⚠️ 证据边界：README 未读；三形态的具体接口（SDK 语言范围、CLI 命令面、MCP 暴露的工具清单）全未知；无性能、无基准、无生产用户证据；85★ 但周增 +0 且首次采集当日，样本极短。
增量 ③ · takeshy/obsidian-local-llm-hub —— "全本地 + 全能"的一体化端侧 hub 形态
- 来源：
organized/repo_cards/4652-takeshy-obsidian-local-llm-hub.md→ https://github.com/takeshy/obsidian-local-llm-hub - 要点（卡片简介自述，README 未核）："All-in-one local AI hub for Obsidian — LLM chat with vault tools, MCP servers, RAG, workflow automation, encryption, and edit history. Fully private, no cloud required." —— 一个 Obsidian 插件形态的本地 AI 中心，功能面一次铺满 7 项：LLM 对话 / vault 工具 / MCP servers / RAG / 工作流自动化 / 加密 / 编辑历史，自我定位"完全私有、无需云端"；卡片字段：Stars 90、周增 +0、TypeScript、MIT、最近提交 2026-10-26、首次采集 2026-10-26、成熟度 experimental、主分类 agent、主题 rag + llm-infra、形态 app。
- 与活文档 knowledge/llm-infra.md 现有脉络的关系：
1. 真新条目：
obsidian-local-llm-hub/takeshy在 llm-infra.md 中 0 命中。 2. 它落在 v3.67 脉络 F（"开源的语义正在细化为：开源可验证层 + 显式标注不可验证层"） 的反面一格——"Fully private, no cloud required" 是一个未加限定的断言：隐私主张的具体边界（本地模型 vs 云端 API 的混合调用、加密的密钥来源与范围、编辑历史是否可导出）在本轮无法核实。v3.67 已确立"诚实标注不确定性是成熟度标志"，本件恰好提供一个未标注不确定性的样本，适合作为该原则的对照点而非佐证。 3. 它与 v3.67 §0.5.1 ④ Unleash_an_Agent 的五闸护栏（预算上限 / 输出过滤 / 输入过滤 / 工具 allow-list / agent RBAC）形成尺度对照：Unleash 是集群级、可复现攻防的护栏栈，本件是桌面级、一体化的产品形态——同一批护栏需求，在个人端侧被折叠进一个插件。这直接支撑 v3.67 的 T167 趋势 ①（"竞争轴从能力转向可约束性"）在另一个尺度上的成立性，但也说明约束机制的工程形态高度依赖部署规模。 4. 它是本轮唯一带 RAG 标签的 llm-infra 材料，对 rag 域可能才是真增量——但 rag.md 在 R128 已由 tom 消化过一轮（tom2026-10-26-rag-e1prep.md报告 6 条增量），本件不在 tom 那份清单的 8 份材料里，属跨主题首次命中，建议今晚交给 rag 域确认是否认领，llm-infra 侧只登记不展开。 - 建议归入哪一节：§0.5.1 新增一条（编号待定），在描述中显式保留"‘Fully private, no cloud required’ 为未加限定的卡片自述，边界未核实"这句限定；与 v3.67 ④ Unleash_an_Agent 的五闸做一句话尺度对照；§4 开放问题可新增一条"端侧一体化 hub 的隐私主张如何被独立核验（本地模型比例 / 加密边界 / 历史可导出性）"；不进 §3 共识。
- ⚠️ 证据边界：README 未读；7 项功能均为简介级列举，每项的实现深度（尤其 RAG 的检索质量、加密的实现方式）未知；90★ / 周增 +0 / 首次采集当日；无用户规模、无性能数据；"无需云端"与实际模型来源的矛盾可能性未排除。
增量 ④ · naberbabammm34343/llm-task-orchestrator —— 模型路由作为产品决策而非论文议题 ⚬（卡面存在明显自相矛盾）
- 来源：
organized/repo_cards/4651-naberbabammm34343-llm-task-orchestrator.md→ https://github.com/naberbabammm34343/llm-task-orchestrator - 要点（卡片简介自述，README 未核）：简介为 "Top AI Router 2026: Split Codex for Quick Code & Claude for Complex Refactoring" —— 按任务类型把请求分流给不同编码 agent：快速编码给 Codex，复杂重构给 Claude。卡片字段：Stars 124、周增 +0、语言 HTML、形态 app、主分类 engineering、分类 ai、主题 agent + llm-infra、成熟度 experimental、待LLM分类：是、许可字段缺失。
- 与活文档 knowledge/llm-infra.md 现有脉络的关系：
1. 真新条目：
llm-task-orchestrator/naberbabammm34343在 llm-infra.md 中 0 命中。 2. 它压在一个活文档至今没有独立位置的轴上：模型路由。v3.67 §0.5.1 ⑤ awesome-llm-token-optimization 把 "Model Routing（80% 的典型 LLM 调用不需要最贵的模型）"列为成本优化的六类杠杆之一，但那里只是清单归并，没有路由机制的独立条目；本件是一个具体路由策略的产品化实现（按"快 vs 复杂重构"二分，把 Claude 与 Codex 这种非同一供应商的编码 agent 作为路由目标）。这给 v3.67 的"成本与基准正在成为独立治理面"（C377）补了一块决策面的实据：路由不再只是挑模型，而是挑 agent。 3. 它与 v3.67 §0.5.1 ⑤ 中"80% 不需要最贵模型" 构成印证与冲突并存的关系：方向一致（按任务复杂度分流以控成本），但本件的切分维度是任务类型（快/复杂），而清单那条的口径是成本档位——两者不是同一个切法，不能互相作证。特别是本件把路由目标设为两个闭源商业 agent，与清单里多指向可自托管开源模型的 routing 手段在部署前提上完全不同。 4. 值得今晚一并看的对照：tom2026-10-26-evaluation-e1prep.md的增量 ① 记录了 Anthropic 的"把 subagent 折回主循环"指南（单 agent + skills 优于复杂多 agent，且必须跑 eval 决定是否折叠）。本件的"双 agent 路由"与那条的"单 agent 收敛"方向相反——一个主张保持两个 agent 并按任务分流，一个主张取消 subagent。这构成今晚最值得并列登记的一组张力（详见 §3 矛盾 ①）。 - 建议归入哪一节：§0.5.1 新增一条（编号待定）；§3 共识：建议在 C377 的"成本与基准独立治理面"下补一句"路由的切分维度从成本档位扩展到任务类型/agent 类型"（不新增共识编号，作为 C377 的延伸句）；§3 矛盾：见 §3 矛盾 ①（与 Anthropic 折叠指南的方向冲突）；§4 开放问题可新增一条"路由器的切分依据若来自'任务复杂度'这类不可自动判定的量，其误判成本由谁承担"。
- ⚠️ 证据边界：README 未核；卡片字段存在三处明显异常——① 简介标题 "Top AI Router 2026" 是自我宣称的榜单排名，无榜单出处；② 语言标为 HTML（一个编排器标 HTML，说明项目形态可能是纯前端/单页）；③ 许可字段缺失；待LLM分类：是（上游分类器尚未定稿）；无路由准确率、无分流比例、无成本数据。
增量 ⑤ · api-evangelist/pienso —— "API 画像"作为第三方治理物 ⚬（材料本身与 llm-infra 关联薄弱，建议只作栖位登记）
- 来源：
organized/repo_cards/4649-api-evangelist-pienso.md→ https://github.com/api-evangelist/pienso - 要点（卡片简介自述，README 未核）："Pienso — independent third-party profile of a public API surface, by API Evangelist." —— 为一个公开 API 的接口面做独立第三方画像。卡片同段落还带出一段与本项目无关的公司背景：Pienso 是一个 2016 年创立于 MIT 的交互式无代码 AI / 机器学习平台，由 Karthik Dinakar 与 Birago Jones 创立，总部在华盛顿特区 / 阿灵顿一带。卡片字段：Stars 0、周增 +0、形态 framework、主分类 engineering、分类 ai、主题 rag + llm-infra、成熟度 experimental、待LLM分类：是、许可字段缺失。
- 与活文档 knowledge/llm-infra.md 现有脉络的关系：
1. 真新条目：
api-evangelist/Pienso在 llm-infra.md 中 0 命中（仅organized/knowledge/.rag-candidate.md一处候选文件命中，非活文档）。 2. 它表面上落在一条本库尚未成形的轴上：API 面的第三方独立描述层。本库有"模型/API 画像"类内容（如 nvidia NIM 的 model-profiles-and-selection、OrcaRouter、OpenRouter 类路由画像），但 llm-infra.md 迄今没有"第三方给 API 做画像"这一独立命题。若该命题成立，它与 v3.67 §0.5.1 ⑤ 的 routing 杠杆构成上下游关系：先有可比较的 API 画像，才谈得上按画像路由。 3. 但本件的证据强度不足以承载任何判断：Stars 0、许可缺失、README 未核、分类未定，且卡片简介本身存在严重自指问题——"Pienso"这个仓库名与段落里描述的那家 2016 年的无代码 AI 平台同名，仓库简介却把项目描述成"API 画像工具"。这意味着要么仓库是对外部服务的第三方画像档案（合理），要么卡片简介把两个不同实体混在了一起（也完全可能）。在核实前，不应把这段公司背景当作本仓库的事实。 4. 因此本件不进入 v3.67 的任何主棒位，只作栖位登记：标记为"llm-infra 主题标签下的 API 画像类候选"，并把"命名自指 + 简介混实体"列为今晚的待核项。 - 建议归入哪一节：§2 栖位登记段记一条（不占用 §0.5.1 主棒位编号）；§4 开放问题/待核项增一条"api-evangelist/pienso 的项目实体与仓库名是否同一对象"；不进 §3 共识 / §4 开放问题的实质条目。
- ⚠️ 证据边界：README 未核；Stars 0；许可字段缺失；待LLM分类：是；简介中混入的第三方公司背景未经任何独立核实，本简报不采用为事实。
2. 复核后无新增观点（3 件 · v3.67 已收，仅字段刷新）
| 材料 | 复核结论 |
|---|---|
organized/repo_cards/4636-devrochy-agent-core.md |
v3.67 §0.5.1 ① 已做 README / 官方文档级核实并写入正文（AgentSpecV3 / KernelSpec / 契约版本化 / 三层记忆 / 幂等 / guardrails / kill switch）。本轮卡片字段与 v3.67 记录一致（0★、+0、MIT、Python、最近提交 2026-10-25→卡片写 2026-10-25 一致），仅分类字段"待LLM分类"由"是"变"否"。属采集态刷新，不计增量。 |
organized/repo_cards/4638-ablation-tool-ablation.md |
v3.67 §0.5.1 ③ 已收（DAG Adapter Language / AIARE）。卡片字段与 v3.67 完全一致（223★、+0、Python、NOASSERTION、最近提交 2026-10-25），待LLM分类仍为"是"。零增量。 |
organized/repo_cards/4505-aryan-pardeshi-citeproof-ai-mcp.md |
v3.62-v3.66 历史轮次 repo_card 登记索引已收该仓库 URL；"CiteProof-AI 与 CiteProof-AI-MCP 是不同仓库，关系未说明"已作为 D270 在册。本轮卡片新增的是学术属性字段（学术状态 accepted / 阶段 evidence / 主任务 systematic-review / 辅助 literature-search + meta-analysis / 方向 summarize / 学术相关度 85 / 学术判定 deterministic / 学术证据锚串），这些字段本身不构成新的技术观点，但它把该仓库从"一个 MCP 工具"补成"有学术审稿背书的 systematic-review 工件"——这本身是 D270 的一条新线索（见 §3 矛盾 ③）。 |
3. 值得警惕的矛盾与待核实说法
① 方向相反的两条架构主张（今晚最值得并列的一组） ⚠
本批增量 ④（llm-task-orchestrator）的"按任务分流到两个不同 agent"，与 tom 在 2026-10-26-evaluation-e1prep.md 中登记的 Anthropic 指南（"把不必要的 subagent 折回主循环，单 agent + skills 常常胜过复杂多 agent；且必须跑 eval 决定是否折叠"）方向相反。二者都是 2026-10 的当下主张，谁对取决于任务分布与 eval 口径——而两边都没有给出可比的公开数据（前者无分流比例，后者为厂商博客 + 二手转述）。→ 不要今晚判胜负，建议在 §3 矛盾里登记为"路由/编排的两条相反主张并存"，并各自保留其证据等级。
② "Top AI Router 2026" —— 卡片简介里的自宣称榜单 ⚠ llm-task-orchestrator 的简介标题即 "Top AI Router 2026"。无榜单地址、无主办方、无入选口径。→ 绝对不得在活文档中作为"排名第一的路由方案"引用；只能记为"仓库自述的头衔"。同理，awesome-llm-token-optimization 的 "80–99% 成本节省"（D279 已登记）是同类"自述汇总口径"，两件可并置提醒。
③ D270 的部分闭合：CiteProof-AI-MCP 有了学术属性，但仍无法说明两仓关系 ⚠ 本轮新增字段显示 CiteProof-AI-MCP 具备 accepted 学术状态 / systematic-review 主任务 / literature-search + meta-analysis 辅助任务 / 学术相关度 85 / 判定 deterministic / 学术复核时间 2026-10-25。这说明它是一个学术工件而非普通工具，但两个仓库的关系（是否同源、是否 fork、是否一为 CLI 一为 MCP）依然没有任何说明。→ D270 不闭合，但可加一句"该仓库有学术审稿背书（学术相关度 85），与另一仓的关系仍未知"。
④ "Fully private, no cloud required" —— 未加限定的隐私断言 ⚠⚬ obsidian-local-llm-hub 的简介以"完全本地、无需云端"作为卖点，但未说明本地模型与云端 API 的混合比例、加密的密钥来源与范围、编辑历史的可导出性。本库 v3.67 刚确立了"诚实标注不确定性本身是开源基础设施的成熟度标志"（趋势 ③）。→ 本件应作为该原则的对照样本登记，不得作为"本地优先范式"的证据。
⑤ "entailment 优于 classification" 是论文主张，但缺一切量化 ⚠⚬ Entailment-Based-Fact-Checking 的标题即主张 "Entailed Opinion Matters"，但本批材料不含任何准确率、基线对比、消融或数据集规模；"AACL 2026 accepted" 也只是卡片自述，无 ACL Anthology / DOI / 作者。→ 该件只能作为问题表述与数据集清单登记，不得表述为"事实核查精度提升"。
⑥ arXiv 号缺失说明（见 §4） ⚠ 本批 8 份材料无一给出 arXiv ID。Entailment-Based-Fact-Checking 是 AACL 2026 论文，理论上应有 arXiv 版，但本轮未核实其 arXiv 号，不得凭空填写。→ §6.99.2 的 arXiv 全量清单本轮保持 487 件不变。
⑦ 分类噪声与标签漂移登记 ⚠
- api-evangelist/pienso：主题标签 rag + llm-infra，主分类 engineering，形态 framework，但简介讲的是"API 画像"——主题标签与实际内容关联薄弱，且命名自指（见增量 ⑤）。
- naberbabammm34343/llm-task-orchestrator：语言 HTML、许可字段缺失、待LLM分类：是——三处字段都指向"材料不完整"。
- unibaseio/membase：形态 tool + 分类 skill（把记忆层归为"可被 agent 调用的技能"），与 llm-task-orchestrator 的 app 归类形成对照——同一个"基础设施件"，上游分类器给出了两种栖位。
- Ablation-Tool/ablation：主题含 rag 但与 RAG 实质无关（tom 在 2026-10-26-rag-e1prep.md 已作同一登记，说明该标签噪声是持续性的，不是偶发）。
⑧ 待分类件占比偏高 ⚠
本批 8 件中 3 件 待LLM分类：是（llm-task-orchestrator / piensa / ablation），2 件许可字段缺失或 NOASSERTION（llm-task-orchestrator 缺许可、pienso 缺许可、entailment 为 NOASSERTION、ablation 为 NOASSERTION）。→ 今晚做技术论证时，涉及许可与分类的判断必须逐件标注来源字段，不能默认 MIT/可用。
4. 可引用的 arXiv 号列表
本轮 NET-new arXiv ID = 0 件。
- 本批 8 份材料全部是 GitHub repo_card，无一篇给出 arXiv ID；四类计数沿用基线不变：arXiv 487 / CVE 36 / DOI 22 / URL 随 §0.5.1 收录数增加。
- Entailment-Based-Fact-Checking（AACL 2026）：本轮未核实其 arXiv 号，不在清单中。⚠️ 禁止凭标题猜测编号——活文档中该条须写"arXiv 号待核"，或仅引其 GitHub URL + 卡片路径。
- 与本批材料脉络相邻、但非本轮新增的 arXiv 锚（仅供今晚连线用，不得计入本轮增量）：arXiv:2608.21156（Graph Engineering，与 Ablation 的 DAG 适配器对照，v3.67 §0.5.1 ③ 已用）、arXiv:2603.28052（Meta-Harness，v3.66 已收）、arXiv:2602.00359（Agentic Evolution is the Path to Evolving LLMs，v3.66 已收）、arXiv:2610.13735（Orthros）、arXiv:2609.36616（CrossTimeEdit）、arXiv:2501.09223（Foundations of LLMs）、arXiv:2610.11899（Forms of LLM-Integrated Applications）、arXiv:2606.17846（Qwen-RobotManip，tom 今日 evaluation 域登记，与本批无直接关系）。
- 本批无 CVE、无 DOI。
5. 今晚建议动作（按优先级）
| # | 动作 | 落点 | 证据等级 |
|---|---|---|---|
| 1 | 收录 Entailment-Based-Fact-Checking 为一条 repo_card 主棒位，显式标注"论文级（AACL 2026 自述）+ 0★ + 无许可 + README 未核 + 无量化结果" | §0.5.1 新增条目 | 中（唯一论文级） |
| 2 | 收录 membase / obsidian-local-llm-hub / llm-task-orchestrator 三条，均带"卡片简介自述、README 未核"限定 | §0.5.1 新增条目 | 低—中 |
| 3 | 把 Agent 记忆的两条路径并读登记："可插拔横切层（membase，MCP 形态）" vs "运行时内建契约（agent-core 三层记忆）" | §0.5.1 ① 旁 + §3 可加预备级延伸 | 预备级（2 仓简介级） |
| 4 | 把"路由的切分维度"从成本档位扩到任务/agent 类型，接在 C377 成本治理面下；同时登记与 Anthropic 折叠指南的方向冲突 | §3 C377 延伸 + §3 矛盾新增 1 条 | 冲突双方均为低—中 |
| 5 | 登记 D270 补充线索（CiteProof-AI-MCP 具学术背书、两仓关系仍未知）；D270 不闭合 | §3 矛盾 D270 | 中 |
| 6 | 把 obsidian-local-llm-hub 的 "Fully private, no cloud required" 作为趋势 ③ 的对照样本登记（未标注不确定性的反例） | §0.5.1 条目内 + §5 趋势 | 低 |
| 7 | api-evangelist/pienso 只做栖位登记，不进主棒位；待核项："命名自指 + 简介混实体" | §2 栖位段 + §4 待核 | 低 |
| 8 | 分类噪声登记 4 条（pienso 标签弱关联 / llm-task-orchestrator 三处字段缺失 / membase 与 task-orchestrator 栖位分歧 / ablation 的 rag 标签噪声持续） | §2 噪声段 | 元数据级 |
| 9 | arXiv 全量清单保持 487 不变；entailment 一件写"arXiv 号待核" | §6.99.2 | — |
不建议今晚做的事：不重排 §0.5.1 的 8 件既有主棒位（本批无一具备推翻其顺序的证据密度）；不把本批 5 条升格为新共识编号（证据均为简介级）；不修改 §5 趋势的既有三条（本批只提供对照样本，不构成新趋势）。
6. 已检查来源清单（可核查）
清单材料（本批新材料，8 份 · 全部读毕）
1. organized/repo_cards/4664-unibaseio-membase.md
2. organized/repo_cards/4505-aryan-pardeshi-citeproof-ai-mcp.md
3. organized/repo_cards/4652-takeshy-obsidian-local-llm-hub.md
4. organized/repo_cards/4651-naberbabammm34343-llm-task-orchestrator.md
5. organized/repo_cards/4650-gauravkumar62024-entailment-based-fact-checking.md
6. organized/repo_cards/4649-api-evangelist-pienso.md
7. organized/repo_cards/4638-ablation-tool-ablation.md
8. organized/repo_cards/4636-devrochy-agent-core.md
已读旧文件（仅供脉络对照，未修改）
- organized/knowledge/llm-infra.md（v3.67 · 2026-10-26 05:00 CST）
- organized/queue/work-queue.md（2026-10-26 18:00 生成）
- organized/knowledge/.rag-candidate.md（仅命中检查，非活文档）
交叉核对笔记（只读，不计增量）
- inbox/tom/2026-10-25-inference-e1prep.md · inbox/tom/2026-10-26-rag-e1prep.md · inbox/tom/2026-10-26-evaluation-e1prep.md · inbox/tom/2026-10-25-rag-e1prep.md
- inbox/jay/2026-10-26-engineering-e1prep.md
paper_cards 抽查：近 3 天（mtime ≥ 2026-10-23）共 245 张新卡，按 llm-infra 主题过滤后逐一取标题；与本批相关的候选事实核查卡 —— 364-2607-09092（AgentKGV，知识图谱事实核查，主分类与本批 entailment 件不同轴）、304-2606-18031（内容可信度检测）、196-2607-02383（Know Your Source）—— 均未落入本批 8 份材料，故不计入增量；其余命中为经典基座卡（T5 / PaLM / Scaling Laws / BigBird / Skip-Thought / LLaMA / Switch Transformers / Gemma / LaMDA / Code Llama / BloombergGPT 等），tom 已在 2026-10-25-rag-e1prep.md 侧登记过，本轮不重复计数。
未做：未开网页搜索补料；未做全库扫描；未下载任何论文或 README 原文；未执行仓库代码；未修改活文档 / 清单 / 认领记录 / 定时配置；未写他人目录；未 git。