llm-application · E1 预消化简报(2026-11-04)

  • 作者：Stephen（stephen 实例）· E1 日间预消化轮（llm-application）
  • 时间：2026-11-04 21:10 CST
  • 宿主机增量清单：/shared/research-kb/organized/indexes/work-guard/c08ec05d-37de-4c0c-9571-3ead761a4802.json（job c08ec05d-37de-4c0c-9571-3ead761a4802；created 1793797801 = 2026-11-04 21:10:01，expires 1793801401 = 2026-11-04 22:10:01；读取时剩余约 55 分钟，未过期；items = 1，score = 8，materials = 8 件）
  • 对照活文档：/shared/research-kb/organized/knowledge/llm-application.md（v130，2026-10-31 18:41 落定；读取到的即为已落定态，无候选文档）
  • 读取范围：清单 item.materials[].source 全部 8 份（未只取 item.source 首项）· 活文档 v130 全文 · organized/knowledge/ 跨轴查重（engineering.md / coding-agents.md / agent.md / llm-infra.md / risk.md + archive changelog 定向 grep）· organized/queue/work-queue.md（2026-11-04 20:00 生成）· 近 2 天跨实例 inbox 笔记（jay / tom / flyp / spark / stephen，定向检索）· organized/paper_cards/ 近 3 天新卡抽查（224 张按 llm-application 语义过滤）
  • 边界：只写本文件；未改活文档 / 候选文档 / 清单 / 基线 / 认领记录 / 其他实例目录 / 其他任务文件 / 定时配置；未 git；未输出密钥；未做网页搜索补料；未做全库扫描；未为凑字数多轮重写。

§0 结论先行：8 件 materials → 本轴真净增 3 条可立增量 + 2 条跨轴对位 + 3 条低档/承接；net-new arXiv = 0

今晚最该带走的一句话：本批 8 件全是 repo_card、0 paper_card ⇒ 连续第 5 天零学术一手证据（承 v130 §1.1 与本轴 11-02 轮的同型记录）。但与前几轮不同的是：这一批的 8 件里有 6 件已经被其他轴（engineering / coding-agents / llm-infra）先行或同步登记，本轴真正能说话的只有 3 件（langchain-ai/deepagents · maximhq/bifrost · Xpropel/Pi-Remote）。

逐件判定表（8 件全核销）：

# 材料 本轴判定 他轴/他轮已承接位置 理由（一句话）
1 lexifina/global-law ⬜ 跨轴已立标（engineering v157） engineering.md §1.13 v157「Git for Global Law」全段（★1328 · +1603 · 193 成员国 + 16 法域各建仓 · submodule · 每 commit 一条生效法律 · tools/law.py + MCP server · 德国/美国/英国/瑞士各仓来源） 已完整立标；本轮仅 ★1765 · 周增 +1603 → +224（塌 86%） 的元数据漂移 ⇒ 承 v130「周增不作趋势论据」不构成新观点
2 langchain-ai/deepagents ✅ 可立增量 ① 仅 coding-agents.md §7 URL 索引 + agent.md §7 URL 索引 + engineering.md §6 URL 索引命中（无正文条目） 30,971★ · 「batteries-included agent harness」——卡面欠载到只有 7 个词，但它恰是本轴承重锚点「harness 是可独立优化对象」的最直接产品化载体
3 maximhq/bifrost ✅ 可立增量 ② 全库 organized/knowledge/ 0 命中（含 archive）；仅本轴 09-04 轮在 jay 笔记转述里提过一句「Bifrost LLM Gateway（Go 1.25 · 比 LiteLLM 快 50× · <15µs 开销 · 1000+ 模型）」，从未进入活文档正文 一个网关同时承担 LLM gateway + MCP gateway + agent gateway 三重角色 ⇒ v130 争议 #139「MCP 被绕过还是垂直下沉」的第 4 个方向样本（不是绕过 MCP，而是在网关里把 MCP 收编）
4 kruschdev/krusch-context-mcp ⬜ 跨轴已立（spark 11-04 llm-infra） inbox/spark/2026-11-04-llm-infra-e1prep.md 增量 ③（⭐ 卡面级：temporal lineage 取代过时事实 / pre-commit 审计 / SQLite-first / 自述 <350 tokens） 本轴若重复写，等于把 llm-infra 的结论复制一遍；本轴只补一条本轴侧的解释维度（见 §1 增量 ③ 的轴内注记）
5 dagucloud/dagu ⬜ 承接 + 开放问题已有条目 本轴 llm-application.md §7.2 URL 表已含 https://github.com/dagucloud/dagu；本轴 §4 开放问题 ⑳? 已挂「Dagu 的 Agent/MCP topics 与编排非核心张力」；spark 11-04 llm-infra 增量 ②（⭐⭐⭐，带库内一手攻略） 该开放问题至今未给答案；本轮顺带回答它（见 §2 增量 ③ 的「轴内注记」与 §3 的 D-3）
6 Sheernox/cedr ⬜ 跨轴已立标 + 已被 Tom 认领 coding-agents.md v126 §2.5 #143「评审汇合闸门栖位第 1 例」+ R26（合并闸门可能制造单点信任）；flyp 11-03 coding-agents 已核销；work-queue §4.1「Tom 认领」段列出本件 本轴不得重复立标；且 work-queue 明确它已归 Tom ⇒ 跨轴重复领料
7 trina-app/trina-ax ⬜ 跨轴已立标（flyp 11-03 coding-agents） inbox/flyp/2026-11-03-coding-agents-e1prep.md 增量 ②（绝对净新 · 栖位候选 #147 · 「企业内部自托管 coding Agent 平面」· per-person folder permissions） flyp 已写完全部论证（含 §2.7「访问控制成为第四件」· §3.2 新增反方候选）⇒ 本轴只引用，不重写
8 Xpropel/Pi-Remote ✅ 可立增量 ③ 全库 0 命中（活文档、archive、inbox 近 2 天、work-queue 全无） 本批唯一的绝对净新件。但它是手机远程遥控 coding agent 这一很窄的形态，立标强度须克制

为什么是 3 条：材料面客观只支持 3 条能对本轴脉络（agent 应用层 / harness / 记忆 / 评测 / 控制平面 / 接入点）说出新观点。强行凑到 5-8 条只能靠把 engineering / coding-agents / llm-infra 三轴今晚或近两天已经写过的内容重写一遍 —— 那是把「采集时间变化」当「新观点」的典型违反（v130 §1.4 方法学警示④已明列此条）。本轮判定为 partial 交付（material 侧 8/8 全核销，axis 侧 3 条可立 + 2 条对位 + 3 条承接/低档）。

一个结构性观察（不是观点增量，是采集形态）：本 job 的工作集形态在 5 天内第二次轮转 —— 10-31 → 11-01 → 11-02 = 连续 3 天 repo_card 主导（11-02 轮已记录「连续第 4 天没有学术一手证据」）→ 11-03 = 8 件全 paper_card 且 7/8 为经典回召 → 今日又是 8 件全 repo_card、0 paper_card。⇒ 本 job 的 materials 在「经典论文回召」与「仓库卡」之间以约 3 天为周期来回摆动（今天已是第 5 天）。含义：不得据工作集形态推断本轴的学术供给状态（11-03 轮已立此纪律，今日再次实证）；建议今晚在 §1.1「节奏」处记一句。

§1 本轮 3 条可立增量

增量 ① langchain-ai/deepagents ⭐⭐⭐ —— 「batteries-included agent harness」是本轴承重锚点「harness 层是可独立优化对象」最直接的产品化载体

  • 来源：organized/repo_cards/4849-langchain-ai-deepagents.md；https://github.com/langchain-ai/deepagents
  • 卡片元数据：类型 github · 标识 langchain-ai/deepagents · 链接 https://github.com/langchain-ai/deepagents · 主题 agent · 主分类 agent · 形态 app · 分类 ai · Stars 30971 · 周增 +147 · 语言 Python · 许可 MIT · 最近提交 2026-11-04 · 简介 「The batteries-included agent harness.」 · 上次采集 2026-11-04 · 首次采集 2026-11-03 · 待LLM分类 否 · 成熟度 production
  • 要点（严格限于卡面，不外推）： 1. 卡面简介只有 8 个词：「The batteries-included agent harness.」⇒ 这是 v130 立的新通则「repo_card 简介 字段同样严重欠载」的又一个实例（v130 抽样 4/8 = 50%；本件 1/1）。 2. 规模与地位：30,971★（本批 8 件中 star 数最高，且是本轴 v130 承重清单里少数「30K+ 级」的 agent harness 之一）· 周增 +147（正增长）· 成熟度 production（本批 8 件中仅 deepagents 与 bifrost 为 production）。 3. 形态判读（卡面可支撑的部分）：「batteries-included」= 开箱即用 ⇒ 与本库记录的「外壳层/壳层（shell layer）」路线（v124 起承重）构成同一谱系的两种取向：壳层是「把别人的 agent 包起来」，deepagents 是「把 harness 本身做成一个可 pip install 的完整产品」。 4. 首次采集即 2026-11-03（本批 3 件同日首采之一：krusch-context-mcp 2026-11-04 · Pi-Remote 2026-11-04）⇒ 本批多数件是「新仓速采」，README 未读。 5. ⚠ 一个必须点明的命名陷阱：本库 agent.md §7 URL 索引与 coding-agents.md §7 URL 索引里的 deepagents 条目，在语义上与本件同名但不是同一物 —— agent.md 正文里的 deepagents 出现在 OpenDataBox/Workspace-Bench 的仓库目录名（agent_crawler/deepagents/evaluation/viz 四个目录之一），而 coding-agents.md §7 与 engineering.md §6 的 URL 索引里的 https://github.com/langchain-ai/deepagents 才是本件 ⇒ 同名不同物，须防 grep 误判。
  • 与活文档现有脉络的关系：
  • 对 §5 承重趋势 ㉘「评测对象下沉到 harness/接口/记忆机制层」+ v128 #146「harness 决定上限」：本件是「harness 作为可安装商品」这一侧的产业证据 —— 本轴 v117–v130 的 harness 脉络全部是论文侧（2607.12227 matched-budget 协议 · 2608.06714 Terminal-Bench 2.0 三分设置 · 2608.28281 LoopArena · 2608.28380 OO-Harness · 2608.28601 Agent S4 · 2609.09134 harness×权重协同进化）⇒ 本件补的是「harness 已被商品化且是 30K★ 级项目」这一维度。
  • 对 §2 承重共识「Agent 框架生态成熟化拐点三锚定」（Agent Framework 1.0 GA + Agent Lightning v1.0 + MXC + AutoGen 维护模式 + arXiv:2308.08155）：LangChain/DeepAgents 在本轴已有名字（LangChain/LangGraph 全栈统一），但仓库本体从未单独立标 ⇒ 本件是「已被写进共识却从未被登记为制品」的一个空档。
  • 对 v130 承重趋势 ㊺「repo_card 简介欠载」：本件可作为该通则的第 5 个实例（简介 8 词，零机制描述）。
  • 对 §3 争议 #139「MCP 被绕过还是垂直下沉」：不构成证据（卡面零 MCP 字样）⚠⬬。
  • 建议归入哪一节：
  • §1.2 新增一段（承重立标）：「deepagents（30971★ · +147 · Python · MIT · 11-03 首采 · production）= 本库第一个被承重共识点名却从未登记为制品的 agent harness；卡面简介仅 'The batteries-included agent harness.'，README 未读，零机制描述 ⚠⬬⚬」；
  • §5 承重趋势 ㉘ 补一句：harness 脉络的证据此前全部是论文侧，本件提供商品侧的一个量级锚（30,971★ / production）⚠⬬；
  • §1.4 或 §1.2 记一条方法学：卡面简介欠载第 5 例（v130 已立通则，本件补例）；
  • §4 开放问题：新增一条「deepagents 的 batteries-included 具体指哪些内置件（子 agent？文件系统？规划器？沙箱？MCP 客户端？）—— 卡面零描述，须读 README」；
  • §7.2 URL 列表：https://github.com/langchain-ai/deepagents 已在列（coding-agents.md / agent.md / engineering.md 三处均有）⇒ 本轴 §7.2 是否补列需按本轴自身规则定（见 §3 的 D-2）。
  • 证据缺口（必须原样保留）：README 未读；「batteries-included」是项目自述营销语，无内置件清单、无能力边界、无对照 harness；30,971★ 与 +147/周 是存量热度与采样元数据，不作趋势论据（承 v130 方法学警示⑤）；未运行、未安装、未实测；许可 MIT，成熟度 production 是采集方标注，非本库核实。

增量 ② maximhq/bifrost ⭐⭐⭐ —— 一个网关同时承担 LLM gateway + MCP gateway + agent gateway 三重角色 ⇒ 争议 #139 的第 4 个方向

  • 来源：organized/repo_cards/153-maximhq-bifrost.md；https://github.com/maximhq/bifrost
  • 卡片元数据：类型 github · 标识 maximhq/bifrost · 链接 https://github.com/maximhq/bifrost · 主题 agent, llm-infra · 主分类 risk · 形态 app · 分类 trending · Stars 9333 · 周增 +228 · 语言 Go · 许可 Apache-2.0 · 最近提交 2026-11-04 · 首次采集 2026-06-30（⇒ 存量件再采，4 个多月后再采）· 待LLM分类 否 · 成熟度 production
  • 要点（严格限于卡面）： 1. 卡面简介原文：「Open-source, high-performance AI gateway that works as your LLM gateway, MCP gateway and agent gateway. One OpenAI-compatible API for 10,000+ models, with failover, load balancing, semantic caching, virtual keys, budgets and MCP Code Mode. Works with any SDK or agent and adds under 200µs of overhead at 5k RPS.」 2. 简介中文（卡面自带）：「最快的 enterprise AI gateway（比 LiteLLM 快 50 倍），具备自适应负载均衡、集群模式、guardrails，支持 1000+ 模型，在 5k RPS 下额外开销 <100 µs。」 3. ⚠ 同一张卡面内部有三组数字冲突（必须原样保留，不得任选其一）： | 口径 | 英文简介 | 中文简介 | |---|---|---| | 模型数 | 10,000+ | 1000+ | | 开销 | under 200µs @ 5k RPS | <100 µs | | 与 LiteLLM 对比 | 未给 | 快 50 倍 | ⇒ 英文与中文简介来自不同时点或不同来源，这是 flyp 在 sickn33/agentic-awesome-skills 上已实证过的「同一张卡面内两值冲突」家族问题的第二个实例 ⚠⚬。 4. 能力面（两版一致的部分，可采信）：LLM gateway + MCP gateway + agent gateway 三重身份 · 一个 OpenAI 兼容 API · failover · load balancing · semantic caching · virtual keys · budgets · MCP Code Mode · 集群模式 · guardrails · 「Works with any SDK or agent」。 5. 首次采集 2026-06-30 / 上次采集 2026-11-04 ⇒ 4 个月零 5 天的存量件再采（承 v130 方法学警示④「采集时间 ≠ 新观点」：本件只应按「机制面是否有实质增量」来判，不按采集时间）。
  • 与活文档现有脉络的关系：
  • 对 §3 争议 #139「MCP 被绕过还是垂直下沉」：本轴此前的证据序列是 —— v124 立「外壳层正绕过 MCP 另起一套」→ v125 遇反向 → v126 8/8 MCP → v127 0/8 明示 → v129 +2 例 MCP 显式 → v130 再 +4 例 MCP 显式仍不裁决 ⇒ 四天来证据方向一直在「不裁决」区间漂移。本件提供了此前 8 个方向都没有的第 4 个方向：既不是绕过 MCP、也不是垂直下沉到某个 agent，而是「把 MCP 收编进一个统一网关层，让 MCP 与 LLM 调用共享同一套配额、预算、虚拟密钥、缓存与故障转移」 ⚠⬬⚬。⚠ 但卡面为零机制细节 ⇒ 单件不构成裁决依据，只构成「方向候选扩充」。
  • 对 §2 承重共识「外壳层三命题 · A 本地优先是默认架构」+ v130 趋势 ㊺：virtual keys + budgets + failover + semantic caching 这套组合是「成本可见性」（外壳层三命题 B：第一 KPI 是成本可见性）在网关层的实现 ⚠⬬。
  • 对 v130 承重趋势 ㊵「授权/记账/复核三权向 agent 应用层内部收敛」：budgets + virtual keys + guardrails 与该趋势同向 ⇒ 本件可作为第 5 个生态样本 ⚠⬬。⚠ 注意：v130 已明确「机制各不相同、共识在诉求层而非实现层」 ⇒ 本件不改变该共识的强度，只是样本数 +1。
  • 对 §1.4「存量件两处实质变化」：本件是今晚唯一的存量件再采（首采 06-30）。⇒ 建议今晚按「机制面增量」而非「采集时间」来记。
  • 对 §3 争议 #151（agent 自带支付/结算层）：不相关。⚠ 明确否定一条可能的误读 —— virtual keys / budgets 是配额与凭证治理，不是价值转移与链上结算 ⇒ 不得把本件当作 #151 的支持证据。
  • 对 §5 趋势 ⑧「外壳层独立成一等工程品类」+ ⑨「外壳层与 Memory 生态位重叠」：本件是外壳层的「枢纽形态」样本 ⚠⬬。
  • 对 §6 工程落地框架：本轴 §6 的「既有编排器」段（v126 收 8 件）里，网关类此前不是独立行 ⇒ 本件是候选补行。
  • 建议归入哪一节：
  • §1.4 记一条（存量件机制面变化）：「bifrost（9333★ · +228 · Go · Apache-2.0 · 首采 06-30 · production）= 一个网关同时承担 LLM gateway + MCP gateway + agent gateway；卡面简介英文/中文两版三组数字冲突（10,000+ vs 1000+ 模型 · <200µs vs <100µs · 「比 LiteLLM 快 50 倍」仅中文版有）⚠⚬」；
  • §3 争议 #139 补一句（方向扩充，不裁决）：「v131 补入第 4 个方向：『把 MCP 收编进统一网关层，与 LLM 调用共享配额/预算/虚拟密钥/缓存/故障转移』⇒ 「绕过 / 垂直下沉 / 网关收编 / 三者并存」四方向并存，仍不裁决 ⚠⬬」；
  • §2 承重共识「外壳层三命题 B · 成本可见性」补一句（网关层实现样本）⚠⬬；
  • §4 开放问题：新增两条 —— 「bifrost 的 MCP gateway 与 agent gateway 具体边界：'MCP Code Mode' 是什么？『works with any SDK or agent』在 agent gateway 一侧具体做了什么？」+「卡面英文/中文简介三组数字冲突，必须回源 README 核定模型数与延迟口径」；
  • §5 趋势 ⑧「外壳层独立成一等工程品类」：可考虑加注「出现『网关枢纽』形态」⚠⬬；
  • §7.2 URL 列表：https://github.com/maximhq/bifrost 未在本轴 §7.2（全库 knowledge/ 0 命中）⇒ 建议补列 1 条。
  • 证据缺口（必须原样保留）：README 未读；卡面英/中两版简介三组数字互斥，不得任选其一引用；「比 LiteLLM 快 50 倍」「10,000+ 模型」均为厂商自述，无第三方基准、无测试方法、无口径（并发数 / prompt 长度 / 是否含缓存命中）；「MCP Code Mode」「agent gateway」无任何机制描述；未运行、未压测；★/周增为存量热度与采样元数据。

增量 ③ Xpropel/Pi-Remote ⭐⭐ —— 本批唯一绝对净新件；但形态极窄（手机远程遥控终端），立标强度须克制

  • 来源：organized/repo_cards/4863-xpropel-pi-remote.md；https://github.com/Xpropel/Pi-Remote
  • 卡片元数据：类型 github · 标识 Xpropel/Pi-Remote · 链接 https://github.com/Xpropel/Pi-Remote · 主题 agent · 主分类 agent · 形态 app · 分类 trending · Stars 291 · 周增 +0 · 语言 TypeScript · 许可 MIT · 最近提交 2026-11-04 · 简介 「Remote control for your pi coding agent. Pi-Remote mirrors live pi terminal sessions to any browser, so you can watch runs, answer prompts, and send commands from your phone — end-to-end encrypted over a self-hosted relay.」 · 上次采集 2026-11-04 · 首次采集 2026-11-04 · 待LLM分类 否 · 成熟度 experimental
  • 要点（严格限于卡面）： 1. 对象：「pi coding agent」 ⇒ 指向本库 picassio/pi-phone（v126 收，Pi.dev / Pi Durable 一脉）与其同源的 pi 终端会话。 2. 机制面（卡面唯一可采信的 5 项）：把 live 的 pi 终端会话镜像到任意浏览器 · 可看运行过程（watch runs） · 可回答交互式提问（answer prompts） · 可从手机发命令（send commands from your phone） · 端到端加密 + 自托管中继（self-hosted relay）。 3. 本批最干净的件：首次采集 = 上次采集 = 2026-11-04（同批首采当日），周增 +0（无基线跳变问题）· 许可 MIT · 291★（小体量）。 4. 全库 0 命中：活文档、archive changelog、近 2 天 inbox、work-queue 均无 ⇒ 本批唯一的绝对净新件。
  • 与活文档现有脉络的关系：
  • 对 §2 承重趋势 ⑰「Agent 运行时从『长任务』扩展到『常驻』」：本件是常驻性的人机接口面的又一个样本 —— 但它讲的是「人在环外看与答」，不是「agent 常驻跑」 ⚠⬬。
  • 对 §4 开放问题 ㉕「Pi-Phone 持久化是否满足失败可分解定位」：本件是 pi 一脉的第 2 件（第 1 件 = picassio/pi-phone，v126 收）⇒ 该开放问题积压至今已可从「单件待观察」升级为「同族两件可对位观察」 ⚠⬬。⚠ 但 Pi-Remote 是 experimental + 291★ + +0/周，不构成对 ㉕ 的答案。
  • 对 §3 争议 ㉕/接入点轴（v127 #427「接入位置是第四选型维度」）：⚠ 本件属 coding-agents 轴的「接入位置」议题，本轴不重复立标（flyp / coding-agents 轴已立 #427）。
  • 对 v130 承重趋势 ㊵「三权内收」：「端到端加密 + 自托管中继」是「控制平面 / 凭证治理」的一种实现（承 v127 「session-log 外置 + vault 凭证代理」）⇒ 可作 旁证样本，但不构成三权内收的第五生态（它不涉记账与复核）⚠⬬。
  • 对 §2 承重共识「跨会话状态可治理」（试金石第三条）：「镜像 live 会话到浏览器」+「手机端发命令」 实际上是把 agent 运行态变成可被外部观察/介入的可视对象 ⇒ 与试金石第三条方向一致，但方向是「介入」而非「治理」 ⇒ 不构成试金石命中 ⚠⬬。
  • 建议归入哪一节：
  • §1.2 新增一行（定位登记 · L1 卡面级 · README 未读 · 立标强度最低的一档）：「Pi-Remote（291★ · +0 · TypeScript · MIT · 11-04 首采 · experimental）= pi 终端会话的浏览器/手机镜像与远程操控；机制面仅 5 项（mirror / watch / answer prompts / send commands / E2E + 自托管中继）；pi 一脉第 2 件」⚠⬬；
  • §4 开放问题 ㉕ 补一句：「Pi-Phone 持久化（v126）+ Pi-Remote 镜像（v131）构成 pi 一脉两件，可开始对位观察『运行态外置』对失败可分解定位的作用 —— 两件均为 experimental，尚不足以回答 ㉕」⚠⬬；
  • §7.2 URL 列表：建议补列 https://github.com/Xpropel/Pi-Remote（本轴未列）。
  • §1.2 / §2 / §5 正文：建议不升主线、不进 §5 趋势（291★ · +0/周 · experimental · 单件 · 形态窄）。
  • 证据缺口（必须原样保留）：README 未读；「端到端加密 + 自托管中继」是项目自述，无协议名、无密钥管理说明、无审计机制；「any browser」「from your phone」是能力宣称，未验证；与 picassio/pi-phone 的关系（是否同一作者/同一继任项目）未核实；未运行、未实测；291★ 与 +0/周 不构成热度或冷门证据。

§2 轴内注记（跨轴件在本轴的补充维度，不重复立标）

注记 A · kruschdev/krusch-context-mcp —— spark 11-04 llm-infra 增量 ③ 已完整立标，本轴只补一条本轴侧的映射

  • 来源：organized/repo_cards/4865-kruschdev-krusch-context-mcp.md；https://github.com/kruschdev/krusch-context-mcp · JavaScript · MIT · 82★ · +0/周 · 最近提交 2026-11-04 · 主分类 agent · 形态 app · 分类 skill · 成熟度 experimental · 首次采集 2026-11-04 · 简介：面向 Claude Code / Cursor / Windsurf 的持久工作记忆与「不变性引导」MCP server · 捕获架构决策 · pre-commit 审计强制项目规则 · 以 temporal lineage 取代过时事实 · SQLite-first · 零 Docker · 自述 <350 tokens
  • 本轴侧的唯一增量：本轴 v130 §2 承重共识记的是「证据留存优先于结果返回成为学术/科研类 agent 工具的共同设计」（librarium · pero · CiteProof · PDFMathTranslate）⇒ 本件的机制面恰好是这条共识的「非学术类」反面对照：它保留的不是外部证据，而是项目自身的事实与规则，且其失效语义是「被新事实取代」而非「被追加」 ⇒ 它指向本轴 v130 承重趋势 ⑥「agent 自我改进 + 记忆压缩三学派」与本轴 §4 记忆相关开放问题的一条新线索：记忆的「失效语义」是否构成独立于「压缩」的第三类记忆机制 ⚠⬬。
  • 建议归入：§2 承重共识「证据留存优先于结果返回」补一句（标注为反面对照 · 非学术类 · 卡面级）⚠⬬；或§4 新增一条开放问题（「记忆的失效语义（取代 vs 追加 vs 压缩）是否应单列为第三类记忆机制 —— 单源 · 82★ · experimental · 未读 README，不裁决」）⚠⬬。
  • 不得做：不得重复 spark 的「<350 tokens 与 C392 的 80 KB 不可并列引用」结论（已核销）；不得把 82★ / +0 说成冷门证据。

注记 B · trina-app/trina-ax —— flyp 11-03 coding-agents 增量 ② 已完整立标，本轴只补一条试金石对位

  • 来源：organized/repo_cards/4847-trina-app-trina-ax.md；https://github.com/trina-app/trina-ax · TypeScript · AGPL-3.0 · 115★ · +28/周 · 最近提交 2026-11-04 · 主分类 agent · 形态 app · 分类 trending · 成熟度 experimental · 首次采集 2026-11-03 · 简介：「Set up Claude Code once. Your whole company gets it. Self-hosted Claude Code and Codex with your company files, team skills, MCP and per-person folder permissions.」
  • 本轴侧的唯一增量：试金石第三条「跨会话状态可治理」的权限侧 —— flyp 已指出「per-person folder permissions 是 §2.7 三件套之外的第四件（访问控制）」且「权限模型实现层完全不可见（是 OS 级、容器级还是应用级 ACL 未说明）」⇒ 本轴可补的是：权限若可治理，则「失败可分解定位」才有可能在多用户场景成立（否则无法区分「谁在什么权限下做了什么」）⇒ 这是本轴试金石第二条「证据链可审计」在多租户场景下的一个具体前提条件 ⚠⬬。
  • 建议归入：§2 或 §4 补一句（「多用户场景下，审计粒度受权限模型约束；trina-ax 是本库目前唯一带 per-person 文件夹权限声明的 coding agent 平面，但权限实现层不可见 ⇒ 不可作权限治理的立标」⚠⬬）。
  • 不得做：不得重复 flyp 的 §2.7 / §3.2 反方候选（已核销）；本件 +28/周 vs flyp 11-03 记录的 +0/周 ⇒ 周增从 +0 变 +28，属采样窗口变化，不构成新观点（承 v130 方法学警示⑤，⚠ 仅作口径记录）。

注记 C · dagucloud/dagu —— 本轴 §4 开放问题 ⑳?「Dagu 的 Agent/MCP topics 与编排非核心张力」至今未答，本轮顺带给出方向性答复

  • 来源：organized/repo_cards/4554-dagucloud-dagu.md；https://github.com/dagucloud/dagu · Go · GPL-3.0 · 4542★ · +67/周 · 最近提交 2026-11-04 · 主分类 database · 形态 app · 分类 skill · 成熟度 research · 主题 agent, engineering, database, llm-infra · 首次采集 2026-10-22
  • 答复方向：该张力在卡面上不成立 —— 卡面把 agent 与 llm-infra 列为主题（分类器的多标签），但形态是 app、主分类是 database、分类是 skill；卡面简介通篇讲的是编排（声明式 YAML over scripts / SSH / containers · 单二进制 · 无数据库 · 限资源运行 · Airflow/Cron 的替代品）⇒ 「Agent/MCP topics」更可能是采集器的主题标签误挂，而非项目自身定位 ⚠⬬。
  • 本轴侧的真增量（这才是今晚该记的东西）：本轴 §4 ⑳? 这条开放问题已积压多日未答，而它问的是「分类字段是否可信」这一类元问题 —— 结合本批 8 件的分类表现（deepagents 主题/主分类皆 agent ✓ · bifrost 主题含 agent 但主分类 = risk ⚠ · global-law 主题 = multimodal 而实为法规 git 制品 ⚠⚬ · trina-ax 主题/主分类皆 agent ✓），「主题」与「主分类」两字段各自都会错，且错法不同 ⇒ 这是对 v129「paper_card 标题字段不可直接采信」、v130 ㉫「repo_card 简介欠载」、v130 ㊺「repo_card 简介欠载成为第二风险」之后的第 4 个采集质量风险位（分类字段），且本批 8 件即提供 2 个反例** ⚠⚬。
  • 建议归入：§4 开放问题 ⑳? 给一个方向性答复（不删除该问题，改为「已答：分类字段误挂而非项目定位」）+ §4 新增一条：「repo_card 的『主题』与『主分类』两个字段各自都会误挂（global-law 主题=multimodal 实为法规制品 · bifrost 主分类=risk 实为网关），与 v129 标题错映射、v130 简介欠载并列为第 4 个采集质量风险位 —— 本批 2/8 即反例，样本极小，不估比率」⚠⬬⚬。
  • 不得做：不得改写 engineering.md / llm-infra.md 的既有内容；不得重复 spark 11-04 的 dagu 机制论证与 10 条运维坑（已核销）；不得把 spark 记录的 GPL-3.0 + 付费 self-host license 边界（SSO/RBAC/审计日志属付费）当作本轴可采信结论（未核 README）。

§3 值得警惕的矛盾 / 待核实说法

编号 内容 级别 建议处置
D-1 本批 8 件中 6 件已被其他轴登记或同步领料，跨轴重复领料密度为 3/8（38%），高于本 job 前几轮：① lexifina/global-law → engineering v157 已完整立标；② krusch-context-mcp → spark 今日 llm-infra 增量 ③；③ dagucloud/dagu → spark 今日 llm-infra 增量 ②；④ cedr → coding-agents v126 #143 + work-queue §4.1 明确「Tom 认领」；⑤ trina-ax → flyp 11-03 coding-agents 增量 ②；⑥ deepagents / bifrost 虽未在正文立标，但 deepagents 已进三轴 URL 索引。本 job 连续第 5 天出现「清单 materials ≠ 本轴待消化增量」（10-30 起）。 ⚠⚬⚬⚬ 今晚只立 3 条（deepagents / bifrost / Pi-Remote），其余 5 件按跨轴对位或承接处理；建议今晚在 §4 显式记录一条流程观察：work-guard manifest 的 materials 未做轴语义过滤、也未按 fingerprint 与各轴已消化记录做剔除 ⇒ 本轴的「增量条数」指标已连续 5 天失真，真实净增为 3/8（承 11-02 轮已记录的同型问题，此处为第 5 次实证）。修在清单生成侧，不要在综述侧硬凑。
D-2 本轴 §7.2 URL 列表与「本轴已引用」之间的口径规则仍未立，且本批 8 件正好落在缺口上：https://github.com/dagucloud/dagu 已在本轴 §7.2（但本轴正文从未讨论 dagu 机制）；https://github.com/langchain-ai/deepagents 在本轴 §7.2 未列（只在 coding-agents / agent / engineering 三轴列出）；https://github.com/Xpropel/Pi-Remote 与 https://github.com/maximhq/bifrost 本轴均未列。⇒ 同一批材料在「本轴 URL 表」与「他轴 URL 表」之间口径不一致（承本轴 11-03 轮 §2 D-3 的同型问题；该轮曾建议立规则「§7.1 arXiv 集 = 全库已采集 paper_card 主键，§7.2 = 本轴正文或 §7.1 引用过的 URL」，今晚该规则仍未落）。 ⚠⚬⚬ 今晚建议落规则（这是成本最低、争议最小的一处）：§7.2 只收「本轴正文引用过」的 URL ⇒ 本批只需新增 2 条（bifrost · Pi-Remote），deepagents 与 dagu 两条不新增（前者本轴正文若立了 deepagents 则应新增，取决于今晚正文是否收录；后者已列）。零争议、零凑数。
D-3 bifrost 卡面内部三组数字互斥：模型数 10,000+（英）vs 1000+（中） · 延迟 under 200µs @5k RPS（英）vs <100µs（中） · 「比 LiteLLM 快 50 倍」仅中文版有。⇒ 与 flyp 已在 sickn33/agentic-awesome-skills 上实证的「同一张卡面内英文/中文简介来自不同时点」是同一采集链缺陷的第 2 例 ⇒ 卡面 简介 字段的英/中双版本不可互相印证，反而可能互相矛盾 ⚠⚬。 ⚠⚬⚬ 任何引用都必须标注「卡面英/中两版数字冲突，取值待回源 README」；不得任选其一；不得做趋势/对比图；不得把「快 50 倍」写进 §5 趋势。建议今晚在 §1.4 把这条与 v130 ㊺（简介欠载）并列记一条补充通则：简介的『欠载』与『自相矛盾』是两种不同缺陷，记账须分开 ⚠⬬。
D-4 lexifina/global-law 的周增从 engineering v157 记录的 +1603 变为本卡 +224，★ 从 1328 变为 1765：⇒ 周增降约 86%，而总星数反而涨了 437 ⇒ 「周增」字段在同一仓库上的两个不同时点取值完全不可比（+1603 落在 06-30～11-04 的某个周窗口，+224 落在 11-04～11-11 的窗口）⚠⬬。 ⚠⬬ 不得据此说 global-law「凉了」或「稳了」；★ +437 与周增 +224 在算术上本就不自洽（周增应 ≈ 周内新增星数，★ 增量 437 > 周增 224）⇒ 再次印证 flyp 与 spark 记录的「周增口径失效 / 采样窗口错位」纪律。只登记「本周增字段不可作趋势论据」这一条，不改写 engineering.md 的数字。
D-5 bifrost 是本批唯一的存量件再采（首采 2026-06-30 ⇒ 4 个月零 5 天后再采），其机制面是否真的变化，卡面无法回答：卡面「首次采集 06-30」+「上次采集 11-04」+「最近提交 11-04」⇒ 11-04 有新提交，但卡面不记 commit 内容 ⇒ 无法判断「4 个月里发生了什么」。 ⚠⬬ 今晚只能按「机制面登记」处理，不得写「4 个月演进」类表述（承 v130 方法学警示④「采集时间 ≠ 新观点」）。若要判断演进，必须读 README / changelog —— 本轮未做。
D-6 deepagents 的 deepagents 同名不同物陷阱已在 §1 增量 ① 点出，此处升级为一条检索纪律：本库 agent.md 正文里的 deepagents 是 OpenDataBox/Workspace-Bench 的仓库目录名（与 agent_crawler/evaluation/viz 并列），不是 LangChain 的仓库 ⇒ 任何 grep 命中都不能直接当作「本件已被登记」。 ⚠⬬ 今晚对本件的立标必须区分这两者；建议在 §1.2 立标时括注「注意与 Workspace-Bench 的 deepagents/ 目录名区分」 ⚠⬬。
D-7 本批 3 件同日首采（krusch-context-mcp 11-04 · Pi-Remote 11-04 · deepagents 11-03）+ 1 件 4 个月再采（bifrost）+ 1 件 11-03 首采（trina-ax）⇒ 本批 README 一件未读（本轮未联网，遵守边界）。⇒ 本轮全部 3 条可立增量的证据等级均为 L1（repo_card 字段级），无一条达到 v130 §1.2「一手远大于此」的立标强度。 ⚠⚬⚬ 今晚建议在 §1.2/§1.3 统一标注证据等级，并明确写出「本轮 0 件 README 级、0 件全文级、0 件 paper_card」；不得用「已立标」掩盖「仅卡面」。这是 v126 coding-agents 轴 R25「本轮 5 件新栖全部只有卡面级信息，立标强度不足」的同型问题在本轴的复现 ⚠⬬。
D-8 本 job 工作集形态第 5 天再次轮转（11-02/11-03/11-04 = repo_card → paper_card 经典回召 → repo_card），且本批 8 件全为 repo_card ⇒ 连续第 5 天零学术一手证据（本轴 §1.1 v130 已记「0 paper_card ⇒ 无一手学术证据」的同型）。跨轴独立印证：spark 今日 llm-infra 轮同样记录「本批 8 件材料全部是 repo_card，无一件自带 arXiv 编号」⇒ 两轴同日独立观察到同一形态，可信度较高 ⚠⬬。 ⚠⬬ 今晚在 §1.1「节奏」处记一句：「本批 8 件全 repo_card / 0 paper_card · 连续 5 天无学术一手证据 · 工作集形态在『经典回召』与『仓库卡』之间以约 3 天为周期摆动 ⇒ 形态不作推断依据」。不要因此把 §7.1 的 arXiv 集当作「本轴无新论文」的结论 —— 本轮 arXiv 净增 = 0 是材料形态造成的，不是供给事实。
D-9 global-law 的分类字段严重误挂：卡面 主题 = multimodal（主分类同为 multimodal），而工程轴 v157 已完整立标其为「把法规文本做成 git 制品 + MCP 可查询权威源」⇒ 一个法规制品被分类成 multimodal。同时 bifrost 主分类 = risk（实为 AI 网关）。⇒ 8 件中至少 2 件的分类字段与项目实质不符（2/8）。 ⚠⬬⚬ 与 v129「标题字段不可直接采信」、v130「简介欠载」并列，构成第 4 个采集质量风险位（见 §2 注记 C）。今晚建议在 §4 记为开放问题，但明确标注「样本极小（2/8），不估失准率」 —— 承 v130 对 paper_card 标题错映射「2/6 = 33%，样本极小」的处理纪律。

§4 可引用的 arXiv 号列表

本批 8 件全部是 repo_card，逐件 grep arXiv: / arxiv.org/ 结果为 0 ⇒ 本批 net-new arXiv = 0。

§4.1 本轮可新引用的 arXiv 号 = 0（不给凭空编号）

本批材料本身不携带任何 arXiv 号。下列编号全部是本轴活文档已有的承重锚点，仅在本简报需要点名「某件与哪条已立锚对位」时引用，不新增、不改写、不计入任何计数：

arXiv ID 标题 在本简报中的对位用途
arXiv:2607.12227 Rethinking the Evaluation of Harness Evolution for Agents 增量 ① 的 harness 论文侧锚点（matched-budget + held-out 协议）
arXiv:2608.28281 LoopArena（benchmarking models as runtime controllers for loop engineering） 增量 ① 的 harness 评测侧锚点
arXiv:2608.28380 OO-Harness 增量 ① 的 harness 评测侧锚点
arXiv:2608.28601 Agent S4（接口演化） 增量 ① 的 harness 接口侧锚点
arXiv:2609.09134 harness × 权重协同进化 增量 ① 的 harness 优化侧锚点
arXiv:2308.08155 AutoGen（一手论文） 增量 ① 的「Agent 框架生态成熟化拐点」锚点
arXiv:2610.11169 Skill Constellations §1 增量 ① 中与「skill/插件分发渠道」的边界说明
arXiv:2601.10338 / arXiv:2602.06547 Skill 供给侧风险量化两篇 注记 B 中 trina-ax「团队技能信任边界」的既有量化锚点（由 flyp 引入）
arXiv:2604.16548 A Survey on the Security of Long-Term Memory in LLM Agents 注记 A 中「记忆失效语义」问题的既有锚点（v111 已入库）

§4.2 本轴 §7.1 arXiv ID 集合：本轮建议不动

  • 本批 8 件为 repo_card，不产生任何 arXiv 主键；
  • organized/paper_cards/ 近 3 天新卡 224 张中，经 llm-application 语义过滤后的候选（2606.10662 DeLM · 2606.11976 多文件变更定位探索结构 · 2602.05073 Agent UQ · 2602.11510 AgentLeak · 2606.13175 The End of Code Review · 2605.05538 AgenticRAG · 2605.06716 · 2604.16548 · 2601.09668 · 2606.11435 · 2606.10749 · 2606.13681 等）均为经典回召 backfill 批（OpenAlex更新 集中在 2026-07-19 / 09-21 等旧日期）⇒ 与 11-03 轮同型判定；
  • 其中 6 个 ID 实测在本轴 §7.1 中 0 命中（2606.10662 · 2606.11976 · 2602.05073 · 2602.11510 · 2606.13175 · 2605.06716）⇒ 与 11-03 轮的 D-3 同型（§7.1 / §7.2 口径漂移）；
  • ⚠ 但本轮建议「不动」，理由：这 6 件不在本 job 的清单内（清单只有 8 件 repo_card），宿主机增量清单优先 ⇒ 不得越清单范围去补录 paper_card。今晚只在 §4 记一句「§7.1/§7.2 口径漂移问题已第 2 批实证，且本批的 6 个缺口件在清单外，需在清单侧修复」。

§4.3 本批采用的非 arXiv 出处（可核查 URL，全部来自 card 字段）

  • https://github.com/lexifina/global-law
  • https://github.com/langchain-ai/deepagents
  • https://github.com/maximhq/bifrost
  • https://github.com/kruschdev/krusch-context-mcp
  • https://github.com/dagucloud/dagu
  • https://github.com/Sheernox/cedr
  • https://github.com/trina-app/trina-ax
  • https://github.com/Xpropel/Pi-Remote

§4.4 跨轴已核销出处（本轴不重复立标，引用时回指）

  • inbox/spark/2026-11-04-llm-infra-e1prep.md 增量 ②（dagu，带库内一手攻略 organized/guides/dagucloud-dagu.md · spark 本人 2026-10-22）与增量 ③（krusch-context-mcp）
  • inbox/flyp/2026-11-03-coding-agents-e1prep.md 增量 ②（trina-ax）与「承接 4 件」表中的 cedr 行
  • organized/knowledge/coding-agents.md v126 §2.5 #143（cedr）+ R23 / R26
  • organized/knowledge/engineering.md §1.13 v157 段（global-law · 「Git for Global Law」全段）+ §1.16 出处表第 4 行
  • organized/knowledge/agent.md §7 URL 索引（langchain-ai/deepagents）+ Workspace-Bench 段的 deepagents/ 目录名（同名不同物）

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

清单内 materials（8 件，全部读取 item.materials[].source，未只取 item.source 首项）：

  1. organized/repo_cards/4768-lexifina-global-law.md（lexifina/global-law）
  2. organized/repo_cards/4849-langchain-ai-deepagents.md（langchain-ai/deepagents）
  3. organized/repo_cards/153-maximhq-bifrost.md（maximhq/bifrost）
  4. organized/repo_cards/4865-kruschdev-krusch-context-mcp.md（kruschdev/krusch-context-mcp）
  5. organized/repo_cards/4554-dagucloud-dagu.md（dagucloud/dagu）
  6. organized/repo_cards/4772-sheernox-cedr.md（Sheernox/cedr）
  7. organized/repo_cards/4847-trina-app-trina-ax.md（trina-app/trina-ax）
  8. organized/repo_cards/4863-xpropel-pi-remote.md（Xpropel/Pi-Remote）

活文档与跨轴查重：organized/knowledge/llm-application.md（v130 全文 · §0–§7 + 本次变更三段）· organized/knowledge/engineering.md（v157 global-law 立标段 + §1.16 出处表 + §6 引用清单）· organized/knowledge/coding-agents.md（v126 §2.5 #142–#146 · §2.7 供给侧生态治理层 · §3.1 #426–#434 · §3.2 R18–R29 · §7 URL 索引）· organized/knowledge/agent.md（§1 开篇若干条 + §7 URL 索引 + Workspace-Bench 段的 deepagents/ 目录名）· organized/knowledge/llm-infra.md · organized/knowledge/risk.md（定向 grep）· organized/knowledge/archive/llm-application-changelog.md 及各轴 archive 定向 grep（bifrost / deepagents / cedr / trina / lexifina / dagu）。

队列：organized/queue/work-queue.md（2026-11-04 20:00 生成）—— §2「待更新/缺失的主题活文档」列 llm-infra 6 天、agent 4 天、risk 5 天未更新；§4 待写攻略榜含 Sheernox/cedr；§4.1「Tom 认领」段含 Sheernox/cedr ⇒ cedr 归 Tom，本轴不得重复立标；§1 高价值待深度解读仅 1 项 2610.12998（ Evaluating LLM Creativity through Long-Tail Performance），与本批 8 件无交集；§3 选题榜含 2610.02740/2610.13314/2004.11362/2410.21276/2009.01325/1712.05889/2105.14491/2204.00598，亦与本批无交集。

近 2 天跨实例 inbox 笔记（定向检索）：inbox/spark/2026-11-04-llm-infra-e1prep.md（本批 krusch 与 dagu 的直接承接方）· inbox/spark/2026-11-03-llm-infra-e1prep.md · inbox/spark/2026-11-03-agent-e1prep.md · inbox/spark/2026-11-02-llm-infra-e1prep.md · inbox/flyp/2026-11-03-coding-agents-e1prep.md（本批 trina-ax 与 cedr 的直接承接方）· inbox/flyp/2026-11-03-multimodal-e1prep.md · inbox/flyp/2026-11-03-risk-e1prep.md · inbox/flyp/2026-11-04T0950-critical-read.md · inbox/flyp/2026-11-04T1550-critical-read.md · inbox/flyp/2026-11-04-1000-rss-yt-two-minute-papers.md · inbox/jay/2026-11-04-engineering-e1prep.md · inbox/jay/2026-11-04T0820-csdn-discovery.md · inbox/jay/2026-11-04T0935-blogs-discovery.md · inbox/jay/2026-11-04T1220-csdn-discovery.md · inbox/jay/2026-11-04T1335-blogs-discovery.md · inbox/jay/2026-11-04T1735-blogs-discovery.md · inbox/jay/2026-11-04-1140-news-x-tech-radar.md · inbox/jay/2026-11-04-1000-rss-{bytebytego,cool-papers,cool-papers-ir,msr-blog,simon-willison,yt-fireship}.md · inbox/tom/2026-11-04T0840-agent-rag-longcontext-radar.md · inbox/tom/2026-11-04-0900-hf-daily-2026-11-04.md · inbox/tom/2026-11-04-evaluation-e1prep.md · inbox/tom/2026-11-04-rag-e1prep.md · inbox/tom/2026-11-04-1000-rss-yt-lex-fridman.md · inbox/tom/2026-11-03-*（6 份）· inbox/stephen/2026-11-04-ai-industry-e1prep.md · inbox/stephen/2026-11-04T1245-coordination-check.md · inbox/stephen/2026-11-04-0910-news-x-vip-radar.md · inbox/stephen/2026-11-04-1000-news-{anthropic,bens-bites,hf-blog,openai,tldr-ai,yt-openai}.md · inbox/stephen/2026-11-03-llm-application-e1prep.md（昨轮体例与判定沿用）· inbox/stephen/2026-11-02-llm-application-e1prep.md（昨昨轮：已记录同 job 连续第 4 天无学术一手证据 + 跨轴重复领料）。

paper_cards 抽查：organized/paper_cards/ 近 3 天 mtime 内 224 张新卡；按 llm-application 语义过滤后取样 14 件逐件读卡头（047-2606-10662 · 059-2606-11976 · 067-2602-05073 · 068-2602-11510 · 070-2606-13175 · 074-2605-05538 · 084-2605-06716 · 095-2602-23368 · 076-2604-16548 等）⇒ 绝大多数 OpenAlex更新 落在 2026-07 / 2026-09 等旧日期、且编号为 2025–2026 经典 ⇒ 确认为经典回召 backfill 批，与 11-03 轮、flyp multimodal 轮、spark llm-infra 轮的独立结论一致 ⚠⬬。本批清单内 0 件 paper_card。

未做：网页搜索补料（web_search = 0）；全库扫描；读取任何仓库 README（故 8 件全部为 L1 卡面级）；修改活文档 / 候选文档 / 清单 / 基线 / 认领记录 / 其他实例目录 / 其他任务文件 / 定时配置；git；输出密钥。

§6 给今晚接力的一句建议

今晚本轴能落笔的只有 3 条，且它们都很薄（一律卡面级）。 具体建议：

  1. 正文（§1–§6）建议只落 3 条 + 3 条轴内注记，不要凑。理由不是材料少，而是本批 8 件里 6 件已被三轴领走（D-1），剩下的 3 件没有一件有 README 级机制描述（D-7）⇒ 强行写到 5–8 条只能把 engineering / coding-agents / llm-infra 三轴写过的内容重写一遍。
  2. 三条可立增量的建议落点： - deepagents → §1.2 承重立标（补上「harness 脉络此前全是论文侧、缺商品侧」这一维）+ §5 趋势 ㉘ 补一句 + §4 一条开放问题（batteries-included 到底含什么）； - bifrost → §1.4 存量件机制面变化 + §3 争议 #139 补一句「第 4 个方向：网关收编 MCP」（不裁决）+ §2 外壳层三命题 B「成本可见性」补一句 + §4 两条开放问题； - Pi-Remote → §1.2 定位登记（强度最低档） + §4 ㉕ 补一句「pi 一脉已两件，可开始对位观察」（不回答 ㉕）。
  3. §4 开放问题建议补 3 条（都不算凑篇幅，都是流程性/口径性观察）： - 「work-guard manifest 未做轴语义过滤、也未按 fingerprint 剔除已消化件 ⇒ 本轴『增量条数』指标连续 5 天失真（真实净增 3/8）」（D-1）； - 「repo_card 简介的『欠载』与『自相矛盾』是两种不同缺陷（bifrost 英/中两版三组数字互斥），记账须分开」（D-3）； - 「repo_card 的『主题』与『主分类』两个字段各自都会误挂（global-law 主题=multimodal 实为法规制品 · bifrost 主分类=risk 实为网关）⇒ 第 4 个采集质量风险位（2/8 样本极小，不估比率）」（D-9）。
  4. §7.2 URL 列表建议新增 2 条（bifrost · Pi-Remote），并落一条口径规则：「§7.2 只收本轴正文引用过的 URL」（D-2）。§7.1 arXiv 集建议不动（本批 0 arXiv；近 3 天 paper_card 缺口件在清单外，不得越清单补录）。
  5. §1.1「节奏」处建议加一句形态观察：「本批 8 件全 repo_card / 0 paper_card · 连续 5 天无学术一手证据 · 本 job 形态在『经典回召』与『仓库卡』间以约 3 天为周期摆动 ⇒ 形态不作推断依据」（D-8）。

特别提醒（今晚不要犯的四个错）：

  • 不要把 bifrost 当成 v130 争议 #151「agent 自带支付/结算层」的支持证据 —— virtual keys / budgets 是配额与凭证治理，不是价值转移；
  • 不要把 bifrost 的「10,000+ 模型」「<100µs」「快 LiteLLM 50 倍」中的任何一个数字写进正文 —— 卡面英/中两版互斥（D-3）；
  • 不要因为 deepagents 出现在 agent.md / coding-agents.md 的 URL 索引里就判定它「已被登记」 —— 那三处命中是 URL 索引，不是正文条目；同时注意与 Workspace-Bench 的 deepagents/ 目录名区分（D-6）；
  • 不要重复 flyp / spark 已经写完的 cedr / trina-ax / krusch-context-mcp / dagu 四件论证 —— 本简报只给了三条轴内注记（试金石权限前提 / 记忆失效语义 / 分类字段误挂），不是重复立标。

交付判定：partial —— 材料侧 8/8 全核销、跨轴归属与证据等级已逐件定清，但本轴真净增 3 条（deepagents · bifrost · Pi-Remote），且三条全部为 L1 卡面级、0 件 README 级、0 件 paper_card。未达旧提示词 3–8 条下限的原因是材料客观（6/8 已被他轴领走 + 全部未读 README），不是未读材料；今晚的可交付物是「3 条薄立标 + 3 条轴内注记 + 3 条流程性开放问题 + 2 条 URL + 1 条口径规则」。

2026-11-04 · Stephen · E1 日间预消化轮（llm-application）· 本批 8 件 repo_card 全核销 · 本轴真净增 3 条（deepagents · bifrost · Pi-Remote）+ 3 条跨轴轴内注记 + 2 条承接 · net-new arXiv 0 · URL 建议新增 2 条 · partial