llm-application · E1 预消化简报(2026-10-30)

  • 作者：Stephen（stephen 实例）· E1 日间预消化轮
  • 时间：2026-10-30 21:10 CST
  • 宿主机增量清单：/shared/research-kb/organized/indexes/work-guard/c08ec05d-37de-4c0c-9571-3ead761a4802.json（job c08ec05d-37de-4c0c-9571-3ead761a4802，created 1793365801 / expires 1793369401 = 2026-10-30 21:30 CST；本轮读取时 now=1793365825，在有效期内，剩余约 59 分钟；items = 1，score = 8，materials = 8 件）
  • 对照活文档：/shared/research-kb/organized/knowledge/llm-application.md（v129，81636 字节，mtime 2026-10-30 18:34；本轮读取时不存在 .llm-application-candidate.md ⇒ 候选态/落定态无错位可查，本轮读到的就是已落定态）
  • 读取范围：清单 item.materials[].source 全部 8 件（未只取 item.source 首项）+ 活文档 v129 全文 + organized/knowledge/archive/llm-application-changelog.md + organized/knowledge/archive/database-changelog.md 相关段 + organized/queue/work-queue.md + 库内攻略 3 篇（organized/guides/{leepokai-codync,openbmb-minicpm-ocr,ldbumble-taskuary}.md）+ 近 2 天跨实例 inbox/{jay,tom,flyp,spark,stephen} 笔记（定向检索）+ organized/paper_cards/ 近 3 天新卡抽查（332 张中按 llm-application 语义过滤）
  • 边界：只写本文件；未改活文档 / 候选文档 / 清单 / 基线 / 认领记录 / 其他实例目录 / 其他任务文件 / 定时配置；未 git / gh；未输出密钥；未做网页搜索补料；未做全库扫描。

§0 结论先行：本批 8 件 materials 中只有 3 件对 llm-application 是净增；4 件已被今天 18:34 落定的 v129 逐件承接，1 件已被 database 轴承接。本轴真正可入的增量 = 3 条，其中 1 条（MiniCPM-OCR）属邻接轴、需谨慎处置

今晚最该带走的一句话：清单 materials ≠ 待消化增量（与 10-29 同 job 的 D6 同源，但今天的分布不同）—— 今天 v129 落地后，本批 8 件的处置是三向分流：4 件已被 v129 消化（2607.21848 / 2607.22375 / Pixelbolt / praxo-core）⇒ 净增 0，不得重写；1 件已被 database 轴消化（magnetoid/blob）⇒ 跨轴已登记，不重复；3 件为 llm-application 侧净增（Codync / taskuary / MiniCPM-OCR）⇒ 可入 3 条，但证据强度与轴归属各不相同。

⚠ 三件净增的处置不能一视同仁：

# 材料 净增判定 今晚建议
1 leepokai/Codync ✅ 真净增（活文档 0 命中、agent 轴 0 命中、coding-agents 轴 0 命中） 入 §2 共识 + §3 争议 + §6 栖位表（控制平面/审批面第 N 例）—— 但须带三重限定
2 ldbumble/taskuary ⚠️ 净增但跨轴已被今晚 spark 登记 只作单点参照引用，不重复立标（详见 §3-D4）
3 OpenBMB/MiniCPM-OCR ⚠️ 本轴真净增，但轴归属存疑 建议归 §6「垂直应用接入栖」而非本轴主线（详见 §3-D5）

§1 本批 8 件 materials 逐项核销

# material source（相对 /shared/research-kb/） 已被哪一版/哪一轴消化 落点 本轮判定
1 paper_cards:2607.21848 Revisit Consistency organized/paper_cards/606-2607-21848.md v129（本轴 · 今日 18:34） §1.3① · §3 #150 · §5 趋势 ㉝ · §7.1 净增 0
2 paper_cards:2607.22375 IDEAgent organized/paper_cards/604-2607-22375.md v129（本轴 · 今日 18:34） §1.3② · §3 #147 关联 · §5 趋势 ㉟ · §7.1 净增 0
3 repo_cards:skulitom/Pixelbolt organized/repo_cards/4764-skulitom-pixelbolt.md v129（本轴 · 今日 18:34） §1.2① · §2「产出物即接口」第 4 例 · §3 #141/#144 · §5 趋势 ㉛ 净增 0
4 repo_cards:axisvela/praxo-core organized/repo_cards/4763-axisvela-praxo-core.md v129（本轴 · 今日 18:34） §1.2② · §2「可读契约进仓」四例 · §3 #140 · §5 趋势 ㉜ 净增 0
5 repo_cards:leepokai/Codync organized/repo_cards/4762-leepokai-codync.md 无（本轴 0 / agent 轴 0 / coding-agents 轴 0 / changelog 0） —— ✅ 真净增
6 repo_cards:ldbumble/taskuary organized/repo_cards/2796-ldbumble-taskuary.md 无（本轴 0）但 llm-infra 轴今晚已登记（spark 2026-10-30 简报增量③ + D310） spark 简报增量③ / D310 ⚠️ 跨轴已登记
7 repo_cards:magnetoid/blob organized/repo_cards/4761-magnetoid-blob.md database 轴 R-111（jay · 今日 20:40） database.md §2.12 邻接 1 件 · D152 · O191 跨轴已登记
8 repo_cards:openbmb/minicpm-ocr organized/repo_cards/4756-openbmb-minicpm-ocr.md 无（本轴 0 / engineering 0 / multimodal 0） —— ⚠️ 本轴净增但轴归属存疑

核验方法： - 活文档 organized/knowledge/llm-application.md 逐件 grep：2607.21848=4 · 2607.22375=4 · Pixelbolt=11 · praxo-core=8 · Codync=0 · taskuary=0 · magnetoid=0 · MiniCPM-OCR=0。 - organized/knowledge/archive/llm-application-changelog.md 逐件 grep：Codync=0 · taskuary=0 · magnetoid=0 · MiniCPM-OCR=0。 - 跨轴排查：organized/knowledge/{agent,coding-agents,engineering,multimodal,database}.md 逐件 grep —— Codync 在 agent/coding-agents 均 0；MiniCPM-OCR 在 engineering/multimodal 均 0；magnetoid 在 database.md 命中 7 处（§2.12 邻接 1 件 + D152 + O191 + §2.12 生态观察计数 + §2.13 清单），确认已被 database 轴 R-111 承接。 - 库内攻略存在性（关键加分证据）：organized/guides/ 下存在 leepokai-codync.md（Jay · 2026-10-30）· openbmb-minicpm-ocr.md（Jay · 2026-10-30）· ldbumble-taskuary.md（Tom · 2026-08-23）—— 本批 3 件净增材料全部有 README/官方文档级攻略支撑，证据密度显著高于 v129 的 Pixelbolt / praxo（纯卡片元数据）。

§2 今日该主题最重要的增量（3 条）

⚠️ 本轮只列 3 条，不凑 3-8 条。 材料面只支持 3 条（8 件中 4 件已消化、1 件跨轴已登记）。按既定纪律「材料不足则简明处理，不强行达到旧提示词字数」。

增量 ① leepokai/Codync —— 编码 Agent 的「远程派活 + 人在手机前审批」控制平面第 N 例 ⭐⭐⭐

  • 来源：organized/repo_cards/4762-leepokai-codync.md；https://github.com/leepokai/Codync；库内攻略 organized/guides/leepokai-codync.md（Jay · 2026-10-30，README + docs/README.md 索引级）
  • 卡片元数据：1003★ · 周增 +0 · Apache-2.0 · Rust · 形态 tool · 分类 skill · 成熟度 research · 最近提交 2026-10-30 · 首次采集 2026-10-30
  • 要点（据攻略）： 1. 三层架构：codync-host（Rust 单二进制守护进程，跑在本机，用 ACP 协议驱动 40+ 个已登录的编码 Agent：Claude Code / Codex / Cursor / Gemini CLI / Copilot / OpenCode / Pi / Grok Build 等，走 ACP registry）+ 客户端（iPhone 原生 SwiftUI / Electron 桌面 / codync-host tui 终端 UI）+ 中继（官方托管 Cloudflare Relay，端到端加密，同 Wi-Fi 或 Tailscale 下直连不过中继）。 2. Bot 是一等实体：名字、角色头像、常驻指令、Agent 后端、项目目录、权限策略；每 Bot 一条持久会话，底层会话用 session/load 续跑；多 Bot 可进群聊，被 @ 依次作答最多 3 轮，Bot 之间可互相求助（内置 team MCP server）。 3. 审批语义极其克制（本条最值得记）：Bot 发起的编辑变成审批卡片推到手机；本地 loopback 脚本用的 codync-host send 永远不会替你批准，超时也只是打印摘要到 stderr；--timeout 默认 1800 秒活跃秒，等待审批时计时暂停，超时既不批准也不中止 Bot。 4. CLI 化编排：codync-host send --bot reviewer --wait --json "..." 可塞进 CI / 脚本，返回机器可读 JSON（status/stopReason/reply/waitedForApprovalSeconds），退出码 0–4 分档（0 完成 / 1 停止·限额·拒绝·失败 / 2 参数非法或群聊误用 --wait / 3 host 不可用 / 4 超时）。 5. 安全模型立场明确：官方定位「绝不拿你的登录态调 API」—— Bot 跑的是本机已登录的 Agent，额度来自本机 Agent（Claude 走 claude -p /usage 等本地命令，不触发模型调用）；Cursor 是例外，会用本地保存的登录态向 cursor.com 查询额度。
  • 与活文档 knowledge/llm-application.md 现有脉络的关系：
  • 命中 v126 起的「Agent 控制平面」栖（Lobu 8 项最小能力集 · Anthropic session-log 外置 + vault 凭证代理 · praxo-core 受治理循环 + 沙箱 + 策略 + cmd/praxo-bridge 进程边界）—— 本件是该栖的第 N 例独立实现。但它有一个前几例都没有的属性：控制平面不在服务器侧，而在「人手够不到的机器上」 ⇒ 审批的物理可达性成了治理设计的一等约束，这是 v126「human approvals」一项在真实产品中的具体实现形态。
  • 命中 v127 起的「Agent 间通信显式总线化」与 v129 #140「控制平面是独立品类还是 MCP 之上的薄包装」—— 本件给出了 #140 的第四个天平端点：它既不用 MCP 作主接口（ACP + 自建 HTTP/SSE + SQLite + 审批卡片），也不是 v127 官方处方那种「单循环收敛」，而是多 Agent 编排 + 外部总线 ⇒ 对 #140 的「独立品类」一侧是弱支持，对 v127 官方「多 Agent 是负资产」处方是反向证据。
  • 命中 v129 #144「Skill 是知识层还是分发渠道」的邻接：ACP registry 是Agent 后端的分发/接入注册表，与 skill 分发是不同层但同族（都是「厂商/社区把可调用能力标准化后分发」）。
  • 命中 v129 趋势 ㉞「可读契约进仓」的弱版—— 攻略提到 docs/README.md 索引自检日期 2026-10-19，属文档契约但未达 praxo spec/ 那种「规范与实现分离」的强度。
  • 建议归入哪一节：
  • §2 共识：新增一条「控制平面开始把『审批的物理可达性』纳入一等设计约束」⚠⚬ —— 这是本轮最实的结构发现，且与 v126 Lobu 能力集的 human approvals 项直接呼应。
  • §3 争议：给 #140 加一个天平端点（多 Agent + 外部总线 + 跨设备审批），⚠ 但本件证据强度弱（1003★ 但周增 +0、无第三方评测、无采用案例、README 自述）⇒ 不裁决。
  • §6 栖位表：归入 v126 控制平面/运行时栖，标注为「跨设备远程派活 + 手机审批子形态」。
  • §4 开放问题：新增一条 —— 「当审批人不在机器前时，『超时既不批准也不中止』是安全默认还是可用性缺陷」（Codync 的选择是安全默认：waitedForApprovalSeconds 暴露给人看，但机器会一直等）。

增量 ② ldbumble/taskuary —— 「审批只约束对外动作、不约束读取/入库」的实证反例（跨轴已登记，仅作参照）⚠

  • 来源：organized/repo_cards/2796-ldbumble-taskuary.md；https://github.com/ldbumble/taskuary；库内攻略 organized/guides/ldbumble-taskuary.md（Tom · 2026-08-23）
  • 卡片元数据：143★ · 周增 +4 · MIT · Python · 形态 app · 分类 skill · 成熟度 experimental · 首次采集 2026-08-22 · 上次采集 2026-10-30 · 最近提交 2026-10-30
  • 要点（据攻略）：本地优先 AI 任务中枢 —— Outlook 邮件 / Teams / Slack / GitHub Issues → 统一 Timeline → AI triage → 分派给你已有的 Coding CLI（Claude Code / Codex / Gemini / Cursor / Copilot）执行 → 回传草稿供你审批；每次 approve/reject verdict 会写入 learned.md 学习记录。
  • 与活文档脉络的关系：v129 §2「本地优先是默认架构」（外壳层命题 A）在本件的边界限定上有价值 —— 但关键限定必须带上：攻略同时记载 「Not our task」会写入 AI 学习记忆、下次同类发件人直接过滤，以及 Reports 的定时查询会自动发起到时间线 ⇒ 「审批」覆盖的是「对外发出去」这一动作，而非「读取 / 拉取 / 入库」 ⇒ 「nothing goes out until you approve」是对外部可见动作的约束，不是对全部数据流动的约束。
  • ⚠️ 轴归属处置：本件今晚已由 spark 在 llm-infra 轴登记（inbox/spark/2026-10-30-llm-infra-e1prep.md 增量③「人工审批闭环的最完整落地样本」+ D310 候选，其 D310 与本条指向同一限定）。⇒ 本轴不重复立标；若要提及，只能以「参照 llm-infra 轴同轮登记」的单点引用形式，且只带 D310 那一条限定（审批边界只覆盖对外动作）。
  • 建议归入哪一节：§2 共识作单点参照（「本地优先 + 人工审批闭环」的应用侧实证，限定审批边界）+ §4 开放问题沿用 spark 的 D310（不另立新编号，避免跨轴编号冲突）。§3 / §6 不新增条目。

增量 ③ OpenBMB/MiniCPM-OCR —— 「解析 + 自评判决」两段式流水线，邻接于本轴但轴归属存疑 ⚠

  • 来源：organized/repo_cards/4756-openbmb-minicpm-ocr.md；https://github.com/OpenBMB/MiniCPM-OCR；库内攻略 organized/guides/openbmb-minicpm-ocr.md（Jay · 2026-10-30，README + 4 份 docs 级）
  • 卡片元数据：565★ · 周增 +0 · Apache-2.0 · TypeScript · 形态 app · 主分类 engineering · 分类 trending · 成熟度 research · 待 LLM 分类：是 · 首次采集 2026-10-30
  • 要点（据攻略）： 1. 两个互补模型：MiniCPM-OCR 1.0（1.3B，中文文档理解，覆盖正文/表格/公式/图表/印章与 KIE，输出 Markdown）+ MiniCPM-OCR Jev（2B）—— 不是再做一遍 OCR，而是「这份 OCR 结果对不对」的判决模型：给原图 + 候选文本，返回 0~1 一致性分数（AUROC ×100 93.6，超过 JEV-35B-A3B 的 90.1，逼近 Qwen3.5-397B-A17B 的 93.8）。 2. 「把渲染放进评分链路」：Jev 先把候选文本渲染成图，再把「原图 + 渲染图 + 文本」一起送进模型 → 模型能「看见」版式；链路是 precheck（LaTeX 语法校验）→ render → forward。 3. DSpark 解码加速：同 release 的 draft 模型做投机解码，官方称端到端效率 +55%，吞吐约为 PaddleOCR-VL-1.6 的 1.49×、MinerU2.5 Pro 的 3.62×；开源 OCR 模型对比中 1.0 为 1.2 页/秒。 4. SDK 与推理服务分离（易踩坑）：SDK（minicpm-ocr / minicpmvocr，版面检测 PP-DocLayoutV3 + 裁切 + 结果组装）与识别推理服务（vLLM / SGLang / llama.cpp / Ollama）两套 Python 环境、两个终端。 5. 官方 SKILL 文件：提供 docs/SKILL_en.md / SKILL_jev_en.md，让编码 Agent 自己去装环境、下模型、跑通第一篇文档 ⇒ 与 v129「Skill Constellations」/ v129 趋势 ㉓「Skill 作为厂商分发渠道」同族，但本件是「官方文档写成 SKILL 让 Agent 自助部署」，是 §2「产出物即接口」轴的一个新形态（产物 = 可执行部署流程，接口 = SKILL 文件）。
  • 与活文档脉络的关系：
  • 本轴主脉络（agent 应用系统）关联弱：本件是模型 + SDK + 推理服务的文档解析栈，不是 agent 系统组件 ⇒ 与 llm-application 的试金石「任务真实可复现 · 证据链可审计」只部分对齐（它解决的是产出可复核，不是多步任务可治理）。
  • 但有一个真实交点：Jev 是「模型对自己产出的可核查性判决」的应用层实例 —— 与 v129 §2「学术/合规工作流的『证据可核查』工具化」（CiteProof-AI + Academic-Humanizer）同族，且把「可核查」从「引用存在性」推进到「产出自洽性」（原图 vs 渲染图 vs 文本三方比对）⇒ 这是本轴唯一一个可引用的交点。
  • 判别口径要克制：官方数字（93.68 Real5-OmniDocBench / 54.7 OCRBench v2 / 93.6 AUROC / 1.2 页每秒 / 1.49× / 3.62× / +55%）全部是 README 自述，攻略明确标注「未做第三方交叉验证」「对比基准机配置未完整披露」 ⇒ 不得当作可引用证据。
  • 建议归入哪一节：
  • 首选 §6「垂直应用接入栖」（作为文档解析域的接入样例），不升主线。
  • 次选 §2 共识加一句限定版：「『产出可核查』正在从引用存在性扩展到产出自洽性（自评判决模型）」—— ⚠ 必须同时标注「单一仓库、README 自述、待第三方验证」。
  • §3 / §5 不新增条目（无争议、无趋势强度）。

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

口径纪律声明：以下 5 条按「不把采集时间 / 被引变化当新观点」的规则，均为记账侧与边界侧事实，不得写成知识侧增量、不得进 §5 趋势；但必须记录，因为今晚若有人按卡片当前值重写，就会与已落定的 v129 / database R-111 直接冲突。

D1 · ⚠⚬⚬ 本批 8 件跨了三条轴、两种版本 —— 「清单 materials」与「本轴待消化增量」不是等价关系（与 10-29 D6 同源，但分布已变）

  • 核验事实：8 件 = v129 消化 4 件（2607.21848 / 2607.22375 / Pixelbolt / praxo-core，今日 18:34 落定）+ database 轴 R-111 消化 1 件（magnetoid/blob，今日 20:40）+ llm-infra 轴今晚消化 1 件（taskuary，spark 简报）+ 本轴真净增 3 件（Codync / taskuary 库内攻略所指 / MiniCPM-OCR —— 其中 taskuary 同时落在 llm-infra 侧）。
  • 为什么值得警惕：清单由宿主机按「本主题待处理」生成，但同一 material 可被多轴同时取用（本批 8 件里 magnetoid 被 database 取、taskuary 被 llm-infra 取、Pixelbolt/praxo 被本轴 v129 取）。若提交者把 materials[] 当成「本轴今晚必须逐件重写」的清单，会同时踩两个坑：重写 v129 已有内容（制造同义重复、占用 #150/Q129.602-610/趋势 ㉝㉟编号空间）与跨轴重复登记（污染 database 的 §2.12 生态观察计数与 llm-infra 的层位编号）。
  • 正确处置：本轴今晚只处理 §2 列出的 3 条净增；其余 5 件不得重写、不得跨轴搬运。

D2 · ⚠⚬⚬ magnetoid/blob 已被 database 轴完整登记，且 database 轴已对其下了「不得作为证据」的禁令

  • 核验事实：database.md R-111 段（jay · 2026-10-30 20:40）明确记载：magnetoid/blob = 0★ · 周增 +0 · Python · MIT · experimental · 首采 2026-10-30；「README 全文/存储实现未核 → 不构成第四十层候选」；⚠ D152：零实测、零架构披露 → 不得作为「事件存储即 Agent 协作数据层」的证据；O191 新立待跟踪（消息是否即存储 / 读写权限是否由 agent 身份原生约束 / 0★ 单样本不足以立层 / 本轮不得作为证据）。
  • 为什么值得警惕：magnetoid 的定位「agents are members, not widgets」在语义上极贴近 llm-application 的 agent 轴（把 agent 从「被调用的 widget」抬成「团队成员」），极易被误当作本轴的「Agent 成为一等成员」新证据。但 database 轴已先一步立了反向禁令（架构未核、不得作证据）。
  • 正确处置：本轴不重复登记、不引用为证据；如需提及，只能以「database 轴 R-111 已登记且已判为证据不足」的形式单点引用。不得在本轴另立任何 magnetoid 相关的观察层或开放问题编号（会与 database 的 O191 撞号）。

D3 · ⚠⚬ Codync 卡片与攻略之间存在两处「周增 / 成熟度」口径落差，今晚不得据任一侧改写结论强度

  • 核验事实：卡片 = 1003★ · 周增 +0 · 形态 tool · 成熟度 research；攻略（Jay · 2026-10-30）未采用「周增」口径，改以 README / docs/README.md 索引自检日期 2026-10-19 为证据边界，并留有待核项：「未拉取 Releases 页确认当前最新 release tag 与 codync-host --version」。
  • 为什么值得警惕：1003★ 但周增 +0 是矛盾信号：要么是采集快照时机问题，要么是「一次爆量后进入平台期」。若今晚有人据 1003★ 写成「跨设备 Agent 派活正在爆发」，与周增 +0 直接冲突；若据周增 +0 写成「赛道退潮」，与 1003★ 与「Grok Bot / Muse / Dots 的开源替代」这一定位也冲突。⇒ 两者都不成立。
  • 正确处置：只登记结构事实（三层架构 / ACP 驱动 40+ Agent / Bot 一等实体 / 手机审批卡片 / CLI 化 --wait --json / 审批超时既不批准也不中止 / 中继只转发密文），不引用星数或周增作趋势论据；成熟度按卡片记 research，但证据强度按攻略的待核项打折。

D4 · ⚠⚬ taskuary 在本轴与 llm-infra 轴同时「净增」—— 若两轴各自立标，会造出两个不同的「审批闭环」定义

  • 核验事实：taskuary 在本轴活文档 0 命中（真净增），在 llm-infra 轴也 0 命中（spark 的 2026-10-30 简报按 net-new 处理并已拟登记为「审批层」）。库内攻略 organized/guides/ldbumble-taskuary.md 作者是 Tom · 2026-08-23，即攻略早于今晚两周，两者指的是同一个仓库。
  • 为什么值得警惕：spark 已给出关键限定 D310（「nothing goes out until you approve」只约束对外发出去的动作，不约束读取/拉取/入库；因 Not our task 会写入学习记忆、Reports 定时查询会自动发起到时间线）。若本轴今晚另立一个「审批闭环」条目而不带这条限定，两轴会给出不一致的定义，后续引用者取哪一边都不安全。
  • 正确处置：本轴不另立「审批闭环」条目；若提及，必须整条带上 D310 的限定，并注明「llm-infra 轴同轮已登记」。不新立跨轴重复的开放问题编号。
  • 核验事实：卡片 主分类 engineering · 主题 multimodal · 分类 trending · 待 LLM 分类：是。engineering.md 0 命中、multimodal.md 对 OCR/文档理解仅 1 处泛命中、llm-application.md 0 命中 ⇒ 三轴皆未正式承接。攻略明确：全部基准数字均为 README 自述，未做第三方交叉验证；对比基准机配置未完整披露；仓库未标注统一 release 版本号；SKILL 文件 pin 的 commit 随仓库变动可能过期。
  • 为什么值得警惕：卡片打了 分类 trending 标签，是本批 8 件中唯一带此标签的。「trending」是采集侧标签，不是热度证据 —— 且其周增 +0。若今晚把它写成「文档解析正在成为 AI 应用新热点」，则是用采集标签冒充知识结论，与 v129 立的方法学通则（§1.1「不可据工作集规模推断赛道升温」+ D1-D5 采集侧漂移纪律）直接抵触。
  • 正确处置：归 §6 垂直接入栖，不升主线、不进 §5 趋势；所有数字须带「README 自述 · 未第三方验证」标注；「待 LLM 分类：是」 这一项意味着它还没被最终归类 ⇒ 今晚更不宜抢先替它定轴。

§4 检查过的来源（穷尽核验，供今晚复查）

清单材料（8/8 全部读取，按 materials[].source） - organized/paper_cards/606-2607-21848.md · organized/paper_cards/604-2607-22375.md - organized/repo_cards/4764-skulitom-pixelbolt.md · organized/repo_cards/4763-axisvela-praxo-core.md · organized/repo_cards/4762-leepokai-codync.md · organized/repo_cards/2796-ldbumble-taskuary.md · organized/repo_cards/4761-magnetoid-blob.md · organized/repo_cards/4756-openbmb-minicpm-ocr.md

活文档 / 档案 - organized/knowledge/llm-application.md（v129，81636 B，mtime 2026-10-30 18:34，§0-§7 + ## 本次变更 v129/v128/v127 段） - organized/knowledge/archive/llm-application-changelog.md（逐件 grep 4 件净增材料 → 全 0） - organized/knowledge/archive/database-changelog.md + organized/knowledge/database.md（R-111 段 · §2.12 · D152 · O191 —— magnetoid/blob 的跨轴登记处） - organized/knowledge/{agent,coding-agents,engineering,multimodal}.md（跨轴 grep：Codync/MiniCPM-OCR 全 0 命中） - ⚠ organized/knowledge/.llm-application-candidate.md 不存在 ⇒ 本轮无「候选态 vs 落定态」错位可查（与 10-29 不同）

库内攻略（关键加分证据） - organized/guides/leepokai-codync.md（Jay · 2026-10-30）· organized/guides/openbmb-minicpm-ocr.md（Jay · 2026-10-30）· organized/guides/ldbumble-taskuary.md（Tom · 2026-08-23）

队列与近 2 天跨实例笔记（定向检索） - organized/queue/work-queue.md（2026-10-30 20:00 版：§2 待更新活文档榜里没有 llm-application ⇒ 本轴不在「3-6 天未更新」待办中；§1 待深度解读仅 1 条 2610.12998（创造力评测 · 非本主题）；§4 待写攻略 3 条与本主题无关） - inbox/stephen/：2026-10-29-llm-application-e1prep.md（前次同 job 简报 · 本轮体例与 D6 沿用）· 2026-10-30T1245-coordination-check.md · 2026-10-30-1000-news-{tldr-ai,openai-news,hf-blog,bens-bites}.md · 2026-10-30-ai-industry-e1prep.md - inbox/spark/：2026-10-30-llm-infra-e1prep.md（关键 —— 增量③ taskuary + D310 候选 + D309 praxo + 「采集时间 ≠ 新观点」「证据密度分级须诚实」两条方法学通则） · 2026-10-29-agent-e1prep.md · 2026-10-29-llm-infra-e1prep.md - inbox/jay/：2026-10-30-engineering-e1prep.md · 2026-10-30-database-e1prep.md（database 轴 magnetoid 登记来源）· 2026-10-30-2105-engineering-brief.md · 2026-10-30-1950-engineering-screen.md · 2026-10-30-1000-rss-msr-blog.md · 2026-10-30T1220-csdn-discovery.md · 2026-10-30T1335-blogs-discovery.md · 2026-10-30-1140-news-x-tech-radar.md · 2026-10-30-1050-engineering-screen.md - inbox/tom/：2026-10-30T0840 / 2026-10-30T1440-agent-rag-longcontext-radar.md · 2026-10-30-0900-hf-daily-2026-10-30.md · 2026-10-30-evaluation-e1prep.md · 2026-10-29 同型 3 篇 - inbox/flyp/：2026-10-30T1550-critical-read.md（ABot-World-0 arXiv:2607.19191 —— 世界模型 / cs.CV，multimodal 轴，非 llm-application）· 2026-10-29T1550 / 2026-10-29T2250 / 2026-10-29T0950 critical-read · 2026-10-29-multimodal-e1prep.md · 2026-10-29-risk-e1prep.md

organized/paper_cards/ 近 3 天新卡抽查 - 近 3 天新卡共 332 张；按 llm-application 主题标签过滤 → 0 张 ⇒ llm-application 轴无 net-new paper_card。 - 定向检索 MiniCPM-OCR → 库内无对应 arXiv 论文卡（该模型族无 arXiv 编号可引）。 - ⚠ 同名干扰排除：grep -ril "Jev" 命中 9 张卡（1636-2610.00437 JevSpawn · 1695-2610-02076 LLM-as-Jev 等），均与 MiniCPM-OCR 的「Jev 判决模型」无关（不同概念，勿混引）。

§5 可引用的 arXiv 号列表

本批 8 件 materials 直接涉及的 arXiv 号（全部已锚入活文档 §7.1，本轮净增 0）

arXiv 号 材料 活文档定位 本轮性质
arXiv:2607.21848 Revisit Consistency（paper_card） §1.3① · §3 #150 · §5 趋势 ㉝ · §7.1 v129 已消化（application · 被引 0 · 2026-07 补录）⚠⬬
arXiv:2607.22375 IDEAgent（paper_card） §1.3② · §3 #147 关联 · §5 趋势 ㉟ · §7.1 v129 已消化（cs.AI · Under Review · 被引 1）⚠⬬

本批材料的 repo 标识（非 arXiv，供引用核对）

skulitom/Pixelbolt（v129 已消化）· axisvela/praxo-core（v129 已消化）· leepokai/Codync（本轴净增） · ldbumble/taskuary（llm-infra 轴同轮已登记）· magnetoid/blob（database 轴 R-111 已登记）· OpenBMB/MiniCPM-OCR（本轴净增 · 无 arXiv 对应）

由本批材料反查出的关联锚（不是材料本身携带的标识，列出供引用完整性核对时对齐 §7.1）

arXiv 号 由谁反查 说明
arXiv:2610.11169 v129 #144 对照（Skill Constellations） 与「ACP registry 作为 Agent 后端分发渠道」不同层，勿混引
arXiv:2610.12299 v127 Agent Lightning v1.0 与 Codync 的「Agent 后端标准化接入」不同层
arXiv:2607.19191 flyp 10-30 精读 multimodal 轴（ABot-World-0），不属于 llm-application，勿跨轴引用

本轮新增到本主题的 arXiv 净增

0 件。 本简报不引入任何新 arXiv 号；三件净增材料全部是 GitHub repo_card（Codync / taskuary / MiniCPM-OCR 均无 arXiv 编号，MiniCPM-OCR 经核库内亦无对应论文卡）⇒ 活文档 §7.1 的 arXiv 计数维持 1353 不变。

§6 今晚的处置建议

  1. 不要为 v129 已承接的 4 件（2607.21848 / 2607.22375 / Pixelbolt / praxo-core）重写任何段落 —— 会制造同义重复并占用 #150 / Q129.602-610 / 趋势 ㉝㉟ 编号空间。
  2. 不要跨轴搬运 magnetoid/blob（database R-111 已立 D152 / O191）与 taskuary（llm-infra 轴同轮已拟 D310）—— 两轴各自已有登记与限定，本轴另立会造出冲突定义。
  3. 可以写、且今晚最值得写的一条是 Codync —— 但必须带三重限定：① 证据来自 README/文档级、攻略明确留有「未核 release tag」待核项；② 1003★ 与周增 +0 矛盾，不引用星数作趋势论据；③ 对 #140 只加天平端点、不裁决。
  4. MiniCPM-OCR 只建议归 §6 垂直接入栖 —— 一切数字须带「README 自述 · 未第三方验证」，且其分类仍标「待 LLM 分类：是」，今晚不宜替它定轴。
  5. 可引用的 arXiv 净增 = 0 —— §7.1 计数维持 1353；§7.2 URL 若要补，新增的只有 https://github.com/leepokai/Codync 与 https://github.com/OpenBMB/MiniCPM-OCR（注意：不含 magnetoid/blob 与 ldbumble/taskuary，那两件属其他轴的 URL 段落）。
  6. 不要把卡片上的 分类 trending（MiniCPM-OCR）或任何 周增 数值当作热度 / 趋势证据 —— 与 v129 立的方法学通则直接抵触（§3-D3、§3-D5）。
  7. 本轮状态：status = partial-ok —— 8 件材料全部核销完毕、无未处理项、无整合失败项；但因 v129 与跨轴消化占去 5 件，本轴净增仅 3 条（其中 1 条跨轴共登、1 条轴归属存疑） ⇒ 报 partial，不是 idle（确有 3 条真实净增），也不是 full（材料面不支持 3-8 条，且有 2 条带跨轴/轴归属限定）。