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

  • 作者：Stephen（stephen 实例）· E1 日间预消化轮（llm-application）
  • 时间：2026-11-01 21:10 CST
  • 宿主机增量清单：/shared/research-kb/organized/indexes/work-guard/c08ec05d-37de-4c0c-9571-3ead761a4802.json（job c08ec05d-37de-4c0c-9571-3ead761a4802，created 1793538601 / expires 1793542201；读取时剩余约 59 分钟，未过期；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 全文 + changelog 归档 + 其余活文档逐件查重 + organized/queue/work-queue.md + 近 2 天跨实例 inbox 笔记（定向检索）+ organized/paper_cards/ 近 3 天新卡抽查 + 库内既有攻略交叉
  • 边界：只写本文件；未改活文档 / 候选文档 / 清单 / 基线 / 认领记录 / 其他实例目录 / 其他任务文件 / 定时配置；未 git；未输出密钥；未做网页搜索补料；未做全库扫描。

§0 结论先行：8 件 materials → 6 条可立增量 + 2 条低档登记；net-new arXiv = 0

今晚最该带走的一句话：本批 8 件全是 repo_card、0 paper_card ⇒ 本轴连续第 3 天没有任何学术一手证据（承 v130 §1.1 同型结构，说明「repo_card 主导」已成常态）；但与 v130 不同的是，本批没有一件是 v130 的承接件 —— 8 件对 llm-application 轴全部为首次进入本轴（逐件 grep 活文档与 changelog，命中均为 0）⇒ 材料侧是干净的净增；问题不在「重复领料」，而在「同一天被两个不同轴的 E1 轮同时领走 4 件」（§2 矛盾 1，前两天没有的新形态）。

# 材料 本轴判定 证据等级
1 Ancienttwo/repo-harness ✅ 可立增量（harness 栖直接命中） 卡片级（无一手 README）
2 kirodotdev/KiroCrew ✅ 可立增量（跨会话状态治理） 库内攻略级（guides/kirodotdev-kirocrew.md，Tom 2026-08-19）
3 qybaihe/bla ✅ 可立增量（分发面 + 产物面）—— 跨轴重访，只做本轴对位 库内攻略级 + risk 轴 R110
4 docxology/template ✅ 可立增量（可复现发布流水线 + 卡内自相矛盾） 卡片级（含中英双简介，可互证）
5 HenryXiaoYang/realtime-tex ✅ 可立增量（增量重排版） 卡片级（待LLM分类：是）
6 future-agi/traceAI ✅ 可立增量（OpenTelemetry 式 AI 可观测性） 卡片级 + 库内攻略级（guides/future-agi-future-agi.md，Tom 2026-08-10）
7 AI-in-Transportation-Lab/awesome-mcp ⬜ 低档登记，不论证（11★ · 无条目 · 无一手核实） 卡片级
8 openfireflyboy/catalyst-automation-agent ⬜ 低档登记，不论证（主题与本轴弱相关） 卡片级

低档两件：awesome-mcp 与 catalyst-automation-agent 同日在 spark 的 llm-infra 轮已被登记（后者标注「awesome 索引、11★、无条目、无一手核实，不作论证」）⇒ 本轴不重复论证、不重复立标，仅作登记表项。catalyst-automation-agent 未在 llm-infra 轮出现，但卡面唯一信息是「Simple setup agent and logstash automation script for catalyst」——领域特定运维脚本，在不联网的前提下无法判断其与本轴的关系，故只登记。

§1 本轮 6 条可立增量

增量 ① Ancienttwo/repo-harness ⭐⭐⭐ —— 「专用 harness」落到具体厂商 harness 组合上

  • 来源：organized/repo_cards/4793-ancienttwo-repo-harness.md；https://github.com/Ancienttwo/repo-harness
  • 卡片元数据：TypeScript · MIT · 435★ · 周增 +0 · 最近提交 2026-11-01 · 主分类 evaluation · 形态 app · 分类 ai · 成熟度 research · 首次采集 2026-11-01 · 待LLM分类 否
  • 卡片简介原文（唯一可用的一手措辞）：「File-backed workflow harness for reliable Claude Code and Codex sessions.」
  • 要点（严格限于卡面，不外推）： 1. 形态 = harness，且是文件支撑（file-backed）的 workflow harness —— 与本库已登记的 A-Evolve（文件系统契约 + holdout 门控 + git tag + 回滚）、praxo-core（spec/ + AGENTS.md）属同一「用文件系统当可读契约」家族 ⚠⬬。 2. 适配对象是 Claude Code 与 Codex 两个既有厂商 harness，不是通用编排器 ⇒ 正是 v128 争议 #145「全局 vs 专用 harness」 里「专用」一侧的又一个样本。 3. 目标词是 reliable（可靠性）而非 capability ⇒ 直指试金石第 4 条「失败可分解定位」与 v128 趋势 ㉔「评测对象下沉到 harness / 接口 / 记忆机制层」。 4. 主分类被采集器判为 evaluation ⚠⬬ —— 这是分类器偏差的一例：一张讲「让厂商 harness 会话更可靠」的运行时装备卡被归到评测栖。
  • 与活文档现有脉络的关系：v128 趋势 ㉔ ⇒ 候选样本，但只算「专用 harness」侧；争议 #145 ⇒ 倾向证据再 +1 例，仍不裁决 ⚠⬬；争议 #146（harness 决定上限）⇒ 不构成正面证据（卡面无评测数字、无对照、无任务集）；v127 趋势 ⑱⑲（单循环 + 渐进披露）⇒「file-backed workflow」很可能是渐进披露在编排层的落法，但卡面零机制描述，不得据此断言 ⚠⬬。
  • 建议归入哪一节：§1.2 新增段（标「专用 harness 侧 · 卡片级 · 无一手核实」）+ §3 争议 #145 加天平端点（不裁决）+ §5 趋势 ㉔ 只补样本数、不新增编号（1 件不构成趋势）+ §4 开放问题新增「file-backed workflow 的『文件』承载什么（状态 / 计划 / 审计轨迹）—— 卡面未说明」⚠⬬ + §6 栖位表归入 v128 起的「harness 设计自动化四路径」相邻位。

增量 ② kirodotdev/KiroCrew ⭐⭐⭐ —— 试金石第三条「跨会话状态可治理」的第一个双生态样本（桌面 App + 消息渠道）

  • 来源：organized/repo_cards/2400-kirodotdev-kirocrew.md；https://github.com/kirodotdev/KiroCrew；库内攻略 organized/guides/kirodotdev-kirocrew.md（Tom，2026-08-19，已核 README + docs/guides/windows-install.md）
  • 卡片元数据：Python · Apache-2.0 · 4696★ · 周增 +116 · 最近提交 2026-11-01 · 主分类 agent · 形态 tool · 分类 ai · 成熟度 experimental · 首次采集 2026-08-18 · 上次采集 2026-11-01 · 场景：persistent workspace、self-improving agent
  • 要点（据库内攻略，已标版本核对；非推测）： 1. 三层架构：Surface（桌面 App / Web Dashboard / CLI / Slack / Discord / Telegram / Teams / Webex / WeCom / WeChat，10 个消息渠道）→ Gateway（长期运行的本地进程，管会话、记忆、定时任务、审批、策略）→ Agent（经 kiro-cli 驱动 LLM，支持 MCP 工具、子 Agent、checkpointed 任务）。 2. 跨会话三件套：会话、记忆、检查点均可跨会话恢复；用户纠正可转为持久 lesson（记忆存事实、lesson 存纠正，二分建模）；checkpointed 长任务（数小时/数天）失败可续跑。 3. 内置 3 个 MCP server：kirocrew-core（任务/子 Agent/记忆/审批）、kirocrew-cron、kirocrew-computer；cron + 主动 nudging（AutoNudge / goal-loop skills）。 4. 可复现性前提（攻略坑 1/2/5）：kiro-cli 必须独立安装并登录（KiroCrew 本身不含 LLM 驱动）；首次启动自动下载 Qwen3-Embedding-0.6B GGUF（约 610MB）；全部会话/记忆/任务状态默认只存 ~/.kiro/crew（或 KIROCREW_HOME），清理即全丢。 5. 安全边界（攻略坑 6）：Gateway 有 tool approvals / OS sandboxing / sensitive-path checks 多层保护，但 Agent 仍具真实工具访问权限，配置不当有风险。
  • 与活文档现有脉络的关系：试金石第三条「跨会话状态可治理」 ⇒ 本库目前最完整的正面落地（会话 + 记忆 + 检查点三者跨会话，且失败可续跑直击第 4 条「失败可分解定位」）；v127 趋势 ⑰（Agent 运行时从「长任务」扩展到「常驻」） ⇒ 强样本（Gateway 常驻 + cron 主动触发 + 10 渠道入口）；v126 趋势 ⑭⑮（控制平面成为独立工程品类 / 四层分工跨社区同时实现） ⇒ 第 4 次独立实现潮，但形态不同：Lobu 是外部控制平面，KiroCrew 把控制平面做进自家 Gateway 进程内 ⇒ 与 v130 §1.2「三权内收」主线同族，且是「复核 + 审批落到常驻进程」的一例 ⚠⬬；开放问题 ㉕（Pi-Phone 持久化是否满足失败可分解定位） ⇒ 方向性正例，未裁决 ⚠⬬；v127 趋势 ⑯（产出物即接口） ⇒ lesson 与 checkpoint 都是持久化一等制品，可作第 5 例 ⚠⬬。
  • 建议归入哪一节：§1.2（本轮「跨会话状态治理」主条目）+ §2 共识（「会话/记忆/检查点三件套跨会话 + 纠正转 lesson + 审批作为 MCP 一等能力」可与 v130「三权内收」并列为候选，须注明单源）⚠⬬ + §3 给 #140（控制平面三解） 加「解 ① 外部控制平面 ↔ 解 ③ 控制平面内建于产品进程」的分叉提示，不裁决 ⚠⬬ + §4 新增「『可治理』是否要求保留/迁移/审计接口 —— KiroCrew 的状态是单目录本地态，清理即全丢，治理权在用户而非产品」⚠⬬ + §6 栖位表归入「常驻运行时 / 控制平面」栖。
  • ⚠️ 限定：本件首次采集 2026-08-18，本轮为存量件元数据刷新 + 首次进入本轴主棒位，不是新研究（承 v130 §1.4 纪律：只登记「首次进入本轴」，不把 4696★ / +116 周增当热度证据）。

增量 ③ qybaihe/bla ⭐⭐⭐ —— 「防御工具以 MCP + skill 形态预装进各家 harness」的第 2 例（跨轴重访，只取分发侧与产物面对位）

  • 来源：organized/repo_cards/4742-qybaihe-bla.md；https://github.com/qybaihe/bla；库内攻略 organized/guides/qybaihe-bla.md（Tom，2026-10-30，已核 README + docs/installation.md + docs/releases/v1.4.0.md）；risk 轴已完整消化（organized/knowledge/risk.md R110，flyP 2026-10-30）
  • 卡片元数据：JavaScript（卡面）· MIT · 1742★（卡面）· 周增 +455 · 最近提交 2026-11-01 · 主题 agent/risk/llm-infra · 主分类 agent · 形态 app · 分类 trending · 成熟度 research · 首次采集 2026-10-30
  • 要点（本轴只取三条与分发/产物相关者，其余见 risk 轴 R110，不重写）： 1. 分发形态：CLI 与 MCP server 同名 bla-agents，另注册名为 blind-llm-agents 的 skill；npx bla-agents setup 自动把 MCP server 与 skill 注册进主流客户端（攻略点名 Claude Code / Cursor / Codex / Windsurf / Gemini CLI / OpenCode；risk 轴 R110 记为 9 家，多出 Google Antigravity / VS Code / GitHub Copilot CLI —— 两处口径不一致，见 §2 矛盾 4）。 2. MCP 工具面（注册后由 agent 调用）：bla_defend / bla_audit / bla_protect / bla_verify / bla_benchmark / bla_emit_headers / bla_doctor ⇒ 七件套里五件是「治理动作」而非「查询动作」，即 agent 被授权对产物执行不可逆的加固写入。 3. 产物面的攻防对偶：README 自述「发布产物 = 免费源码」；inspect-release 专查 .map 的 sourcesContent 与 sourceMappingURL ⇒ 本库此前记录的是「给 agent 看什么」（成本账），本件是「agent 能从你的产物里拿走什么」（对抗面）。
  • 与活文档现有脉络的关系：v127 趋势 ㉓（Skill 成为厂商官方分发渠道） + v130 趋势 ㊸（skill/插件预装进各家 agent harness） ⇒ 「分发渠道」解读的第 3 例，且首例由防御侧工具贡献（v127 的 typesafe-ai/skills 与 v130 的 xberg 官方 bundle 都属能力供给侧）⇒ 可补「分发渠道机制与工具的能力属性无关」这一限定 ⚠⬬；v130 争议 #144（Skill 是知识层还是分发渠道） ⇒ 继续向「分发渠道」倾斜，不裁决 ⚠⬬；v130 §1.2 主线「三权内收」⇒ 本件落在「授权」侧的反面：它把写权限交给 agent，而「谁批准、谁留痕」在卡面与攻略中均未出现 ⇒ 对 #152（「受理不等于执行授权」是否普适）是反向压力点，⚠⬬ 不裁决；v125 趋势 ⑬⑰ ⇒ 无关，不并入。
  • 建议归入哪一节：§1.2 新增段（明确标注「跨轴重访：risk 轴 R110 已完整消化，本条只做本轴分发面/产物面对位」）+ §3 争议 #144 加端点、#152 加反向压力点（均不裁决）+ §5 趋势 ㊸ 补「第 3 例 / 首例防御侧」（不新增编号）+ §6 栖位表归入「Skill 与分发渠道」栖，不重复占 agent 安全栖。
  • ⚠️ 限定：① 跨轴重访，本轴不得重写其攻防链与技术细节（已在 risk.md R110 与 llm-infra 今日轮）；② star 口径两说（卡面 1742★ vs 攻略/R110 541★，见 §2 矛盾 3）；③ README 的 612.5× token / 292.2× 成本是内部估算，verify:rea 不得当作防护证据，原样沿用 risk 轴证据红线，不转写为实测。

增量 ④ docxology/template ⭐⭐ —— 「可复现研究发布」被做成声明式流水线；同时暴露卡内中英简介互斥

  • 来源：organized/repo_cards/1841-docxology-template.md；https://github.com/docxology/template
  • 卡片元数据：Apache-2.0 · Python · 20★ · 周增 +0 · 最近提交 2026-10-31 · 主分类 agent · 形态 tutorial · 分类 academic-writing · 成熟度 experimental · 首次采集 2026-08-14 · 上次采集 2026-11-01 · 学术状态 accepted · 学术阶段 publishing · 学术主任务 typesetting-templates · 学术方向 typeset · 能力分面 pdf/latex/template · 学术相关度 80 · 学术判定 deterministic
  • 要点（中英两版简介并列，差异本身是证据）： 1. 英文简介原文：「Reproducible research publishing for Python 3.12+: 17 declared pipeline stages, 25 canonical exemplars, and multi-format outputs.」 2. 中文简介原文：「……两层 Python 3.10+/uv monorepo，将通用基础设施与各项目代码分离，附带 pytest 覆盖率门槛（基础设施 60%、项目 90%）、17 阶段构建流水线、通过 pandoc/LaTeX 的 markdown-to-PDF 渲染，以及 24 个标准示例。」 3. ⇒ 同一张卡的两版简介互斥：Python 3.12+ vs 3.10+、25 vs 24 个标准示例（17 阶段一致）。这是本轮可核查的最硬的一条采集质量问题。 4. 中文版另给三条英文版没有的机制：基础设施与项目代码分离的两层 monorepo、pytest 覆盖率门槛（基础设施 60% / 项目 90%）、pandoc/LaTeX 的 markdown→PDF 渲染。
  • 与活文档现有脉络的关系：v125 趋势 ⑬（学术诚信工具化） 与 v130 趋势 ㊶（「证据留存优先于结果返回」） ⇒ 本件是学术向的「可复现发布」侧，与 librarium（证据留存）· pero（受理不授权）· CiteProof（引文报告 + PRISMA） 同族，但机制不同：那三件治「证据」，本件治「产物的可重建性」⚠⬬；v127 趋势 ㉒（中间表示即产物契约） ⇒ 「17 阶段声明式流水线 + 覆盖率门槛」是「产出物即接口」在学术排版侧的同族实现（把排版当作可声明、可重放的阶段产物而非人工操作）⚠⬬；v130 §1.3 / Q130.611（repo_card 简介 字段系统性欠载率有多高） ⇒ 本件把该风险从「欠载」推进到「互斥」：v130 立的是「卡片简介漏了决定性事实」，本件是「卡片简介的两个版本互相矛盾」⇒ 建议今晚为 Q130.611 补一个子分类「卡内中英简介互斥」（可核查、可复现，属独立于欠载的第三种采集缺陷）⚠⬬。
  • 建议归入哪一节：§1.2 新增段（标「卡内中英简介互斥 · 20★ · 卡片级 · 无一手核实」）+ §1.3 追加「欠载 → 互斥：本轮再添一例」+ §4 在 Q130.611 下补子项「卡内中英简介互斥的实例是否仅此一例」⚠⬬ + §5 趋势 ㊶ 只作同族补例、不改表述 + §6 栖位表归入「学术/合规工作流」栖。
  • ⚠️ 限定：20★、周增 +0、无一手核实（库内无该仓库攻略）⇒ 不得据卡面推出「可复现研究发布已成标准实践」；中文版独有的三条机制只有中文简介这一路来源，须标「单侧来源，待一手核对」⚠⬬。

增量 ⑤ HenryXiaoYang/realtime-tex ⭐⭐ —— 「渐进披露」被用到人机界面层：只重排被编辑的那一段

  • 来源：organized/repo_cards/4794-henryxiaoyang-realtime-tex.md；https://github.com/HenryXiaoYang/realtime-tex
  • 卡片元数据：Rust · MIT · 259★ · 周增 +0 · 最近提交 2026-11-01 · 主分类 engineering · 形态 app · 分类 academic-writing · 主题 rag, engineering · 首次采集 2026-11-01 · 学术状态 accepted · 学术阶段 publishing · 学术主任务 typesetting-templates · 能力分面 pdf, latex · 学术相关度 80 · 学术判定 deterministic · 学术复核时间 2026-11-01T13:30:01+08:00 · 待LLM分类 是
  • 卡片简介原文：「Realtime TeX: re-typesets only the paragraph you edit in ~1 ms with an unmodified LuaTeX. Exact, embeddable.」
  • 要点（严格限于卡面）： 1. 只重排被编辑的那一段（段落级重排），量级 ~1 ms，且强调「unmodified LuaTeX」（不改 LuaTeX 本身）、「Exact（精确）、Embeddable（可嵌入）」。 2. Rust 实现 ⇒ 若纳入，v130 趋势 ㊹（Rust 单二进制 + 多语言绑定 + MCP 三件套） 的 Rust 计数 +1，但卡面既无多语言绑定也无 MCP ⇒ 只能记为「Rust 进入本主题样本的第 7 例」，不能记为「三件套的又一例」 ⚠⬬。 3. 主题字段含 rag，但卡面内容与检索增强无关 ⇒ 分类噪声，登记不采信 ⚠⬬。
  • 与活文档现有脉络的关系：v127 趋势 ⑲（渐进披露成为上下文治理主机制） ⇒ 本件是渐进披露在「渲染反馈回路」上的对应物：不重排整篇、只重排被改的那一段，把渐进披露从上下文治理延伸到人机界面预算（与 ⑲ 承重的接口预算同类，但对象是排版延迟而非模型上下文）⚠⬬；v127 趋势 ⑫（结构化中间语言 + 专用渲染器）第三例印证 ⇒ 本件是专用渲染器方向的又一例 ⚠⬬；v125 ⑬ / v130 ㊶ ⇒ 方向不同（产物渲染 vs 证据留存），不并入 ⚠⬬。
  • 建议归入哪一节：§1.2 新增段（标「卡片级 · ~1 ms 为自述、无基准/硬件条件 · 待 LLM 分类」）+ §2 共识：不立新共识（单源、自述数字、无对照）⚠⬬ + §3：不立争议；可作 #146（harness 决定上限） 的邻位注记（工具上限由渲染策略而非模型决定）⚠⬬ + §5 趋势 ⑲ 只补「渲染侧变体」一句、不新增编号 + §6 栖位表归入「学术写作工具链」栖。
  • ⚠️ 限定：~1 ms 无基准、无硬件与文档规模说明 ⇒ 引用须带「自述」；待LLM分类：是 ⇒ 分类与证据等级均待定。

增量 ⑥ future-agi/traceAI ⭐⭐ —— OpenTelemetry 标准被搬进 AI 应用栈：可观测性从「日志」升级为「标准 trace」

  • 来源：organized/repo_cards/4792-future-agi-traceai.md；https://github.com/future-agi/traceAI；库内攻略 organized/guides/future-agi-future-agi.md（Tom，2026-08-10，覆盖 future-agi 平台六能力，tracing 模块直接点名 traceAI）
  • 卡片元数据：Python · Apache-2.0 · 265★ · 周增 +0 · 最近提交 2026-11-01 · 主分类 engineering · 形态 framework · 分类 ai · 成熟度 experimental · 首次采集 2026-11-01 · 待LLM分类 是
  • 卡片简介原文：「Open Source AI Tracing Framework built on Opentelemetry for AI Applications and Frameworks」
  • 要点（卡面 + 库内攻略可互证者）： 1. 卡面：AI 应用与框架的 OpenTelemetry 基础 tracing 框架 ⇒ 把 agent 的执行过程变成可被标准 tracing 后端消费的结构化事件（span / 属性 / OTLP）。 2. 库内攻略佐证（future-agi 平台，Tom 2026-08-10）：Tracing 模块主张 50+ 框架自动插桩、OpenTelemetry 导出；坑 6：依赖 OTLP 协议，需配套后端（Jaeger / Zipkin / ClickHouse）；坑 7：traceAI、agentic_eval、simulate 等 SDK 可独立使用，整体平台集成需完整 Docker Compose ⇒ traceAI 即该平台拆分出的独立 tracing 组件（攻略示例 from traceai_openai import OpenAIInstrumentor、@traceai/fi-core）。 3. 本轴已有锚点：v130 §7.2 URL 表已含 https://futureagi.com/blog/llm-incident-response-playbook-2026 与 https://futureagi.substack.com ⇒ 公司级内容已在册，但 traceAI 仓库本身未在册（本件是「公司已入、仓库未入」的补全）。
  • 与活文档现有脉络的关系：试金石第 4 条「失败可分解定位」 ⇒ 本件是该条最工程化的一次落地候选（trace = 事后可重放的执行轨迹）；v128 趋势 ⑳（评测对象下沉到 harness / 接口 / 记忆机制层） ⇒ 补上「运行时可观测」这一格（此前本轴从未出现 tracing/可观测性轴样本）⚠⬬；v126 趋势 ⑭ ⇒ 观测面是控制平面的证据面，但本件无治理动作（无审批/无策略）⇒ 不可与 #140「控制平面」并线 ⚠⬬；跨轴：今日 spark 的 llm-infra 轮已把 traceAI 登记为其增量 ④（标「卡面级、未核实、待分类」）⇒ 本轴只做「失败可分解定位 / 试金石第 4 条」侧对位，不重复其可观测性轴论证。
  • 建议归入哪一节：§1.2 新增段（标「卡片级 + 库内攻略级 · 待 LLM 分类 · 跨轴重访」）+ §2 共识：不立新共识（可作「证据留存/可重放」家族补例 ⚠⬬）+ §3：不立争议 + §4 开放问题新增「traceAI 的『记录档』能否满足试金石第 4 条『失败可分解定位』（记录 ≠ 归因 ≠ 可复现；OTLP 后端为外部依赖）」⚠⬬ + §5 趋势 ⑳ 只补样本、不新增编号 + §6 栖位表归入「评测与可观测」栖。

§2 值得警惕的矛盾或待核实说法

  • ⚠️⚠️⚠️【矛盾 1 · 本轮最具杠杆】「同一批 materials 在同一天被两个不同轴的 E1 轮同时领走」—— 前两天只有跨天重复，今天升级为跨轴同天重复 本 job（c08ec05d）11-01 的 8 件中，有 4 件同时出现在 spark 今日 llm-infra 轮的 8 件清单里（4802-ai-in-transportation-lab-awesome-mcp · 4742-qybaihe-bla · 2400-kirodotdev-kirocrew · 4792-future-agi-traceai），另有 1 件（qybaihe/bla）已被 flyP 在 risk 轴 R110（2026-10-30）完整消化。 与前两天的形态差别：10-30、10-31 的问题是「跨天重复」（前一日活文档已承接，清单次日仍发）；今天变为「跨轴同天重复」⇒ 同一份材料在同一天可能同时进入两条轴的棒位，两边都会读到、都可能立标 ⇒ 同库双源重复立标风险从「跨天」升级为「跨轴同日」，正是我 10-31 简报 §3 矛盾 2 已预警过的失效模式（「引用完整性附录达标 ≠ 内容完整性达标」）的新变体。 处置：本轮不自行改清单（边界禁止），已在 §1 逐条标注「跨轴重访 / 本轴只做侧对位」，建议今晚 v131 主轮把 BLA / KiroCrew / traceAI / awesome-mcp 四件按「只在一轴立标、其余轴只引用」处理。待核实：清单生成侧是否有「已被 X 轴领用 / 已消化 fingerprint」标记位 —— 若没有，这是本 job 连续第三天出现、且今天首次跨轴的同一根因（我 10-31 简报已就同一问题提过建议，本轮再次确认问题仍在，且性质升级）。

  • ⚠️⚠️⚬【矛盾 2 · 可复现、易核验】docxology/template 卡的中英两版简介互相矛盾（Python 3.12+ vs 3.10+；25 vs 24 个标准示例） 同一张卡、同一采集批次（上次采集 2026-11-01）、两个字段给出不兼容的事实。与 v130 已立的两个采集质量风险不同类：v129 立的是「paper_card 标题字段不可直接采信」，v130 立的是「repo_card 简介字段系统性欠载」⇒ 本件是第三类：同一字段的两个语言版本互斥。待核实：是中文简介来自更早/更晚快照，还是翻译环节引入漂移？建议今晚为 Q130.611 增加子分类「卡内中英简介互斥」，并抽查若干张同时带 简介 与 简介中文 的 repo_card（本轮边界内只能报此 1 例实测，未做全库统计）。

  • ⚠️⚬【矛盾 3 · 口径漂移，承 spark 今日轮 D-新1】qybaihe/bla 的 star 与语言两套口径 卡面记 1742★ / JavaScript；库内攻略与 risk 轴 R110 均记 541 star / TypeScript ⇒ 数值差约 3 倍、语言类型也不同。今晚引用一律只写卡面口径并标注「卡面 1742★ / JS」，或两者并列注明抓取时点，不得写任何折中值（沿用 spark 轮处置，不重复立新条目）。

  • ⚠️⚬【矛盾 4 · 同源分歧】BLA 的「注册进哪些客户端」两处口径不一致 库内攻略点名 6 家（Claude Code / Cursor / Codex / Windsurf / Gemini CLI / OpenCode，"等一票客户端"）；risk 轴 R110 记 9 家（多出 Google Antigravity / VS Code / GitHub Copilot CLI）。今晚引用写「≥6 家（库内攻略点名）/ risk 轴记 9 家」，不取折中 ⚠⬬。

  • ⚠️⚬【矛盾 5 · 证据分级红线，须原样沿用】BLA 的倍数与「已验证」边界 README 的 612.5× token / 292.2× 成本 / 2822.7×（JS bundle）为 README 自述的内部估算，14/14 runtime-exact 亦为项目自陈；verify:rea 是常量漂移巡检，不得当防护证据，唯一权威门是 redteam:rea；原生反编译与动态调试路径（Ghidra / Frida / LLDB / Rizin / JADX / 固件 / SPIR-V）明确未验证；且 1.5.1 修复的正是「护盾 trailer 破坏 Bun standalone 程序」的破坏性回归 ⇒ 任何「如何加固 agent 可见产物」的建议都必须附「先在 staging 验证字节级与运行时等价」 ⚠⬬。本轴不重写这些细节，只标注「须原样沿用 risk 轴 R110 的证据红线」。

  • ⚠️【待核实 · 轻量】repo-harness 被采集器归到 主分类: evaluation，但卡面内容是运行时 harness ⇒ 分类器口径与主题字段（agent）不一致；本轮只登记不改分类（不得改他人卡片），建议今晚 v131 立标时显式标注「主分类待复核」，避免它以「评测件」身份被误计入评测轴。

  • ⚠️【待核实 · 轻量】KiroCrew 的「治理」主体其实在用户本机 状态默认全在 ~/.kiro/crew、清理即全丢、且需外部 kiro-cli 登录与 610MB embedding 模型下载 ⇒ 试金石第三条「跨会话状态可治理」在本件上是可恢复、可续跑的，但若「可治理」含保留 / 迁移 / 审计 / 导出接口，则本件不满足 ⇒ 建议今晚把这条写成限定语，而不是当成第三条试金石的达成例 ⚠⬬。

  • ⚠️【口径提醒 · 非矛盾】本轮 8 件中 6 件周增为 +0；仅 bla（+455）与 KiroCrew（+116）有量级增长 ⇒ 承 v130 §1.4「Trending 采样日信号不可作热度证据」与「xerj 周增塌陷 93.5%」的教训，本周增不构成赛道升温证据；且 KiroCrew 是 2026-08-18 首采的存量件，其 +116/周是三个月前的仓库在本周的表现，不可读作「本轮新增热点」 ⚠⬬。

  • ⚠️【结构观察】本轴连续第 3 天零 paper_card 供给 organized/paper_cards/ 近 3 天（2026-10-29 起）共 421 张刷新卡，其中带 llm-infra 标签 63 张，带 llm-application 标签 0 张 ⇒ 本轴近 3 天没有任何新论文卡供给，v130 §1.1「无学术一手证据」的成因不在本轮材料，而在采集侧供给。建议今晚在 v131 里把「本轴 paper_card 供给 = 0」写成显式风险（未做全库统计，仅报本次抽查实测）。

§3 可引用的 arXiv 号列表

本批 materials 中的 arXiv 号：0 个。 8 件全部是 GitHub 仓库类 repo_card，卡内无任何 arXiv 标识 ⇒ 本轮 net-new arXiv = 0（连续第 3 天为 0）。

两条需单独记录的「学术状态」口径问题（不可当作论文引用）：docxology/template 与 HenryXiaoYang/realtime-tex 均带 学术状态: accepted、学术阶段: publishing、学术判定: deterministic、学术相关度 80 等字段，但卡内没有 arXiv ID、没有 DOI、没有论文标题 ⇒ 它们是「被判定为学术相关的 GitHub 仓库」，不是论文 ⇒ 今晚只能引仓库，不得转写成「论文/预印本」；这两条目前无法产出任何可核查的 arXiv 引用 ⚠⬬。

今晚可引用、但非本批产出的既有锚点（摘自活文档 v130 §7.1，仅作索引备查，不得计入本轮增量）：2308.08155（AutoGen 一手论文 · v129 三锚定）· 2610.28380（OO-Harness · v128 全局 vs 专用 harness）· 2610.28601（Agent S4 · v128 接口演化）· 2608.15127（AgentSysBench）· 2608.29310（Super-Library Agent）· 2610.11169（Skill Constellations）· 2307.15043（GCG）· 2603.13847（真正的 Sirens' Whisper）· 2606.07001（DataEvolver · 今日 llm-infra 轮另轴登记）· 2604.16548（Memory Lifecycle Framework · risk 轴已注册）· 1409.0575 · 1406.2661。 本轮引用建议：以 8 件材料的仓库 URL + 库内攻略路径为可核查出处；不新增任何 arXiv 号。

§4 本轮检查过的来源（完整清单）

  • 宿主机增量清单（唯一授权范围）：organized/indexes/work-guard/c08ec05d-37de-4c0c-9571-3ead761a4802.json — 1 item / 8 materials（读取时未过期；内容与生成时一致，未被本轮改动）
  • 逐份全读的 8 份材料（item.materials[].source，相对 /shared/research-kb/）：organized/repo_cards/ 下 4802-ai-in-transportation-lab-awesome-mcp.md · 4742-qybaihe-bla.md · 4796-openfireflyboy-catalyst-automation-agent.md · 1841-docxology-template.md · 4794-henryxiaoyang-realtime-tex.md · 4793-ancienttwo-repo-harness.md · 2400-kirodotdev-kirocrew.md · 4792-future-agi-traceai.md
  • 活文档基线：organized/knowledge/llm-application.md（v130）— 全文读 + 逐件 grep
  • 归档：organized/knowledge/archive/llm-application-changelog.md — 8 件逐件 grep（命中均为 0）
  • 跨轴查重：organized/knowledge/ 下全部活文档（agent / risk / database / llm-infra / coding-agents / evaluation / engineering / rag / multimodal / academic-writing / ai-industry / inference）逐件大小写不敏感 grep —— 命中仅 qybaihe → risk.md、awesome-mcp → database.md（后者是 TensorBlock/awesome-mcp-servers，与本件不是同一仓库）
  • 库内既有攻略：guides/kirodotdev-kirocrew.md（Tom · 2026-08-19）· guides/qybaihe-bla.md（Tom · 2026-10-30）· guides/future-agi-future-agi.md（Tom · 2026-08-10）
  • 工作队列：organized/queue/work-queue.md（2026-11-01 20:00 生成）
  • 近 2 天跨实例 inbox 笔记（定向检索，非全量读）：inbox/stephen/2026-10-31-llm-application-e1prep.md（本人上一轮，同一 job）· inbox/spark/2026-11-01-llm-infra-e1prep.md（今日同批次 llm-infra 轮，与本批 4 件重叠）· inbox/flyp/2026-11-01-risk-e1prep.md · inbox/flyp/2026-11-01T1550-critical-read.md · inbox/flyp/2026-11-01T0950-critical-read.md · inbox/tom/2026-11-01T0840-agent-rag-longcontext-radar.md · inbox/tom/2026-11-01-0900-hf-daily-2026-11-01.md · inbox/jay/2026-11-01T1735-blogs-discovery.md · inbox/jay/2026-11-01T1620-csdn-discovery.md · inbox/jay/2026-11-01-1000-rss-bytebytego.md · inbox/jay/2026-11-01-1000-rss-simon-willison.md · inbox/jay/2026-10-31-2340-news-x-tech-radar.md
  • 近 3 天 paper_cards 抽查：organized/paper_cards/ 2026-10-29 起 421 张刷新卡 → 标签分布（llm-infra 63 / llm-application 0）

边界声明：web_search = 0 次；未做全库扫描；未为凑字数多轮重写；未改动清单、基线、认领记录、其他任务文件、队列或定时配置；未写他人目录；未 git；未输出密钥。本文件为整篇写入（write 整写，未用 edit），目标路径取自 item.target = /shared/research-kb/inbox/stephen/2026-11-01-llm-application-e1prep.md（本轮为新建，写入前该文件不存在 ⇒ 无覆盖）。

§5 交付自评与今晚棒位建议

  • status：ok（材料侧与轴侧均有效整合，6 条可立增量）
  • 本轮实际增量条数：6 条（repo-harness · KiroCrew · bla · docxology/template · realtime-tex · traceAI）+ 2 条低档登记（awesome-mcp · catalyst-automation-agent，不论证）；net-new arXiv = 0
  • 今晚棒位建议（优先级）： 1. §1.2 新增 6 段：KiroCrew（⭐⭐⭐，跨会话状态治理）· repo-harness（⭐⭐⭐，专用 harness）· BLA（⭐⭐⭐，跨轴重访，只做分发面/产物面对位）· docxology（⭐⭐，含卡内互斥证据）· realtime-tex（⭐⭐）· traceAI（⭐⭐）。 2. §3 争议：#144 加 BLA 端点、#145 加 repo-harness 端点、#152 加 BLA 反向压力点、#140 加「控制平面内建于产品进程」分叉提示 —— 四项均不裁决 ⚠⬬。 3. §4 开放问题：Q130.611 增子项「卡内中英简介互斥（实测 1 例：docxology/template）」⚠⬬；新增「file-backed workflow 的文件承载什么」⚠⬬、「traceAI 的记录档能否满足失败可分解定位」⚠⬬、「KiroCrew 的『可治理』是否含保留/迁移/审计接口」⚠⬬。 4. §5 趋势：㊸ 补「第 3 例 / 首例防御侧」；㉔ 补 repo-harness 样本；⑲ 补「渲染侧变体」；㊹ 补「Rust 第 7 例，但非三件套例」—— 本轮不新增趋势编号（单件不成趋势）⚠⬬。 5. §6 栖位表：新增 6 行 + 2 条低档登记行。 6. §1.3 / 方法学：补「欠载 → 互斥」一例；§1.1 补「本轴 paper_card 供给 = 0（近 3 天实测 421 张刷新卡中 0 张带 llm-application 标签）」⚠⬬。
  • 需清单生成侧 / Anan 决策的一条：work-guard 清单是否可记录「已消化 / 已领用 fingerprint」 —— 本 job 连续第三天返回已被下游消化的 materials，且今天首次出现跨轴同天重复领用 4 件（§2 矛盾 1）。本轮未自行改清单（边界禁止），仅登记。