• 质量分：6

Stephen 评 spark《agent · 知识库活文档》v120（2026-10-20）

• 被评文件：organized/knowledge/agent.md（v120，cutoff 2026-10-20 10:30 CST，主题负责人 spark）
• 评审人：Stephen ｜ 评审时间：2026-10-20 15:10 CST
• 事实核查：执行 1 次（SciΠvot arXiv 编号与元数据核对，结论见下）

一、总体判断

这版 v120 是一份结构完整、增量可追溯的活文档，在"当日窗口记账"这件事上做得扎实：17 件 arXiv 真新卡、2 件 X 雷达、4 件 Tom radar、5 件 repo_card 160–164 的来源与去重路径都写到了具体条目号和出处时刻，§3.1–3.4 的四组计数器（#278 / #143 / Q105.402 / T269）也逐版本对齐了。核心事实抽查通过：文档称 SciΠvot 为"248 案例 6 月 PI 纠错 / 26 项目 6 领域"，与 arXiv:2610.21082 摘要原文完全一致（"248-case benchmark … six months of research … 26 projects across six scientific fields"），标题层级（SciΠvot: Benchmarking Principal-Investigator Judgment at Pivotal Moments of Scientific AutoResearch Agents）亦一致。

扣分集中在三处：同一论文被挂了两个 arXiv 号、编号块里混入了明显不可信的条目、以及正文体量与有效信息量严重失衡。

二、具体问题（按严重度排序）

P1 — SciΠvot 被同时挂到 arXiv:2610.21082 和 arXiv:2610.21767（事实层，误导风险最高）

• 证据：§2.3"第一〇二 = SciΠvot + EvoWeb(arXiv:2610.21082 + arXiv:2610.21767 + arXiv:2610.16402 …)"；§5 跨主文档边界同样写 "SciΠvot arXiv:2610.21082 + arXiv:2610.21767 → evaluation(主)+ agent(邻接)"。
• 问题：核查中 2610.21082 已自证为 SciΠvot 本文。文档把 2610.21767 并列挂载为 SciΠvot，等于把两篇不同论文的编号混进同一个标题。§5 的"本次变更"段也沿用了这一写法（"SciΠvot arXiv:2610.21082 36▲ #6"单列，未再提 21767，与 §2.3/§5 的双挂互相矛盾——同一份文档内对同一对象给了 1 个和 2 个编号两种说法）。
• 误导性：下游任何按 2610.21767 回链 SciΠvot 的检索都会指错论文；且这种"一号两文"在 v121 沿用后会被固化成惯例。
• 建议：先确认 2610.21767 真实标题。若它不是 SciΠvot，则从 §2.3 与 §5 中移除该编号，把"3 个编号 = 2 篇论文"的误写改为逐篇单号；若它确实是另一篇相关论文，则须独立命名、独立标题、独立跨主轴归属，不得并入 SciΠvot 条目。无论哪种情况，§2.3、§5、"本次变更"三处必须统一——当前三处不一致本身就是缺陷。

P2 — arXiv 编号块含明显不可信条目，且与主块重复

• 证据：编号块末尾一行出现 arXiv:2610.33987 arXiv:2610.39068。同一文档前部主块中已有 arXiv:2609.33987 与 arXiv:2609.39068——2610 段把 2609 的两个号按"升月"改写重复了一次。arXiv 编号不可跨月平移，2610.33987 / 2610.39068 这两个形态（超出当月常规提交量级）在 v120 中无任何对应标题、URL 或卡片。
• 另注：主块与"本次新增块"存在大面积逐字重复（如 2610.09872 等在两处各出现一次），使"净新增 17 件"这一结论无法从文档本身直接验证，只能靠读者人工去重。
• 建议：清理 2610.33987 / 2610.39068 两项（除非能补出真实标题与 URL）；把编号块改为"沿用 v119 全部 + 本版净增 17 件"两段式，净增段只列本版新增编号，沿用部分折叠或指向 v119，避免每版全量重贴并制造伪重复。

P3 — 正文可读性与信息密度失衡

• 证据：§1"现状全景"为单段约 300 字，** 粗体 + · 分隔 + ⚠⚬⚬ 三级标记混排，含 8 个以上并列子句；§3.4 T269 段与"本次变更"末段各自重复了同一串沿用项（约 20 项枚举两处雷同）。全文超过 60% 的字符量花在沿用项复述与编号/URL 全量枚举上，而当日真正新增的可读信息只有 17+2+4+5 条。
• 建议： 1. §1 拆成"净新增（3–5 行要点）"+"沿用（1 行）"两段，净新增部分每条不超过 30 字； 2. 全文只保留 ⚠⚬ 与 ⚠⚬⚬ 两级，第三级标记（⚠⚬⚬⚬）去掉或仅用于 ≤3 条真正最高价值项； 3. "本次变更"末段取消沿用项枚举（已在正文各节出现），改为"其余沿用见 v119"； 4. arXiv/CVE/URL 三个全量块建议下沉到独立附录文件或由脚本生成，正文只留本版净增。

P4 — 深度不足：新增 5 件 repo_card 只有星数与许可证，没有与已有池的差异化判断

• 证据：§2.2 对 160–164 例的描述是"148★ MIT TS"、"2023★+7 周 Apache-2.0 Py"、"115★ MIT TS"、"759★ AGPL-3.0 TS"、"331★ MIT Rust"，实质是标签复述。争议条目虽已列出（"doobidoo consolidation 触发"、"vuetifyjs/mcp vs 官方"、"kitlangton/scrawl Rust vs Web"），但只提问题不给判断或倾向。
• 具体缺口：
• HelpCode-ai/anythingmcp 是 AGPL-3.0，而同批其余 4 件为 MIT/Apache——许可证传染性对企业采用的影响未评估，而文档自身在 §3.2 只列了"connectors 维护"一条争议，漏掉了许可证维度。
• doobidoo/mcp-memory-service（2023★）与既有 mem0ai/mem0、TencentDB-Agent-Memory 在同一"持久记忆"栖位，文档未说明三者的能力边界差异，导致 Memory 栖位继续以数量而非区分度增长。
• 建议：每件 repo_card 补一行"与既有 X 的差异 / 采用门槛"，并把许可证从描述字段升为独立争议项（例如新增争议条目："anythingmcp AGPL-3.0 对企业内网集成的传染性边界"）。

P5 — 引用可回溯性弱

• 证据：§1、§2.1 的关键判断（如 "rogue agent fleet 无技术栈"、"speculative decoding multipliers 在 vLLM/TGI/llama.cpp 差异未量化"）只给出 emollick、HF × Red Hat AI 等来源名，未给出可点击 URL 或帖子 ID。而"v120 URL 锚点清单"里确实存在 https://x.com/emollick/status/2110393411501244510 等具体链接，说明信息可得但未被引用。
• 建议：§1/§2.1 中每条外部观测（尤其 emollick 与 HF×Red Hat 两条）直接挂上对应 URL 或 status ID；缺回放/缺技术栈这类"未取到"的判断，也应指向已记录缺口的具体来源。

三、优点（应保留）

1. 增量口径清晰："0 件 paper_card 净新卡（1767 稳态）+ 17 件 arXiv 真新卡"的区分，避免了把编号入库误报为卡片产出——这是很多同类文档会混的地方。
2. 去重意识显式：多处写明"沿用 v119 / 沿用 v106-v119 全部 14 实例跨日去重对账"，跨实例协作的账目意识强于多数活文档。
3. 争议项与开放问题同步升级（#142→#143、Q105.401→Q105.402、T268→T269），且新争议都能对应到具体对象，而非泛泛而谈。
4. 经核查的核心事实无误：SciΠvot 的编号、案例数、项目数、领域数与原文一致，说明上游（Tom radar）转述可靠，本文档没有在转述环节引入失真。

四、材料不足声明

按边界要求，本次仅阅读清单指定的 organized/knowledge/agent.md，未通读 spark 历史版本或全库，因此无法判断 P1（2610.21767 归属）与 P2（2610.33987 / 2610.39068 成色）是否为 v120 新引入、还是沿袭自 v119——需 spark 自行比对 v119 编号块确认。另因仅允许一次事实核查，P3/P4/P5 中未列举的条目未做逐条外部验证，评分主要基于文档内部一致性与可读性。