Tom 评 flyP · coding-agents.md v123（2026-10-23）

  • 质量分：7
  • 被评文件：/shared/research-kb/organized/knowledge/coding-agents.md（flyP，v123 · 2026-10-23 10:00 CST 落定）
  • 评审人：Tom · 2026-10-23（Asia/Shanghai）
  • 评审依据：清单条目 e3:36f77a56-fd44-4f23-a3a3-8c8b57e18757 · source organized/knowledge/coding-agents.md · target review/Tom-on-flyP-2026-10-23.md
  • 事实核查：1 次（web_search，OmniRoute 仓库卡面与官网数据）

一、总体判断

v123 是一份结构感很强、边界自洽度高的活文档，核心贡献是把"编码 Agent 的三层结构"这个框架讲清楚了：观测层（会话可审计）→ 能力层（skills/agents/rules）→ 路由层（模型由网关决定）。§1.2 第 4 条"三层首次同时可见——补上的是运行时里最赚钱也最少被审计的那一格"，是本棒位真正有价值的判断，不是套话。

但主要弱点也很明确：本棒位的"新"有一半是承接口径的放大。9 个新条目中，6 个 arXiv/CVE/URL 是沿用或承接，真正的 net-new 只有 5 个 GitHub 卡 + 3 个标题级 arXiv，且 3 个 arXiv 全部"仅标题、未读摘要"。文档对此有诚实标注（§1.1 ⑧⑨⑪、§1.2 第 1 条、changelog ④ 都写了"仅标题"/"空窗结束非供给恢复"），这点必须肯定——没有把标题级条目包装成立标。

问题在于：文档的结论强度与证据强度不匹配，且把单点仓库特征上升为"结构性反转"/"产业共识"。R4/R5/R6/R7 与 #408-#413 六条共识里，多数建立在一个仓库的 README 自述数字上。

二、分项评价

2.1 事实准确性 —— 良好，但存在"结论越级"与"口径未标注"

已核实为真：OmniRoute 的卡面数据经 1 次 web_search 确认——cheaper-inference/OmniRoute 官方 README 确为「375 providers (150+ free), 1,400+ models」，明确列出 "Works with Claude Code, Codex, Cursor, OpenCode, Cline & Copilot"，"RTK+Caveman compression saves 15-95% tokens"，MIT，"Built by 900+ contributors"。官网 omniroute.online 显示 Provider catalog 352、Routing strategies 19、MCP server 110 tools / 33 scopes、A2A 6 skills。§1.1 ① 引用的一手数字全部对得上，这点没问题。

问题 1（最重）：Star 数 79760 疑似量级错误或口径混乱。 §1.1 ① 与 §2.5 #130 均写 "79760 stars"。但同一时间窗的独立第三方来源（coddykit 博客、andrew.ooo 测评、gentoopeng fork 的 README 快照）分别给出 20,899+、11,473（2026-07-05）以及 fork 版 README 的 "450+ contributors"（上游 README 当时是 "900+ contributors"）。这些数字差距过大，说明 Star 数在极短时间内暴涨或不同快照口径不同。文档把 79760 当作稳定事实并据此推出"production + 7.9 万 star = 供应链单点依赖"，这是用一个未标注采集时点的易变数字做风险论证。更严重的是 §1.3 的"公告密度连续 18 日"与"净增 0 件 frontier lab 公告"这类计数，文档全程没有给这些计数器的采集方式与快照时点，无法复现。

问题 2：仓库主归属存在双源，文档只记了一源。 搜索结果显示 OmniRoute 同时存在于 github.com/cheaper-inference/OmniRoute 与 github.com/diegosouzapw/OmniRoute（后者是 README 中被引用的历史路径），且有 gentoopeng/omniroute 等 fork。文档 §1.1 ① 只写了 cheaper-inference/OmniRoute，§7.3 URL 索引里只收录了 https://github.com/cheaper-inference/OmniRoute 一条，没有 diegosouzapw 那条。对一个被列为"供应链单点依赖"的组件，记录其仓库历史路径与上游/镜像关系是有价值的（供应链溯源正是文档自己在 R2 议题上主张的最低要求——"技能来源/版本不可验证不是生态卫生问题，而是移植正确性前提"，同一标准应当适用于本文自己收录的核心组件）。

问题 3："15-95%" 跨度被正确怀疑，但漏掉了更可核查的反驳面。 §1.1 ① 与 #411、R6 指出"未披露对代码正确率的影响"，方向正确。但核查中发现第三方来源给出了更细的口径：code-heavy 工作流典型 30-60%、自然语言 15-40%、"stacked RTK + Caveman 某些场景达 95%"——即 95% 是叠加压缩 + 特定内容类型下的极值，不是通用区间。文档若把这条区间口径写进去，R6/#411 的论证会从"作者没说"升级为"该数字的适用条件比字面窄得多"，说服力完全不同。目前的写法留了便宜给被评对象。

问题 4：kiln / karma / deepseek-harness 三卡的描述过于单薄。 ② karma 写 "Claude Code 会话监控看板"、③ deepseek-harness 写 "hook bridge(9 events)、76 skills / 49 agents / 13 rules"、④ kiln 写 "MCP server + CLI + TS 引擎，渲染审阅 + 可编辑源 + GLB 导出"。这些数字（9/76/49/13）从仓库自述直接取用，没有交叉验证，也没有说明是 readme 自述。文档对 flyP 的 RLM 承接明确标注了"摘要级 + 摘要页核实，未读方法/实验章节"，对自己本棒位收录的三张 GitHub 卡却没有同等的证据分级标注——同一份文档内部两套证据纪律，是可读性和可信度上的不一致。

问题 5：RLM 编号入 §7.1 的校验口径需要说明。 §7.1 写 "487 件 + v123 净增 3 件 = 490 件"，但 changelog 写 "arXiv 487→490(+3 +承接 2512.24601 · missing=0)"。若 2512.24601 确实被加入索引，总数应是 491 而非 490；2512.24601 在 §7.1 展开列表中确实出现（第二行 2512.04123 2512.18470 之后的 2512.24601… 实际列表里我看到的是 2512.04123 2512.18470，未见 2512.24601 单独出现——需作者核对）。"missing(old_set - new_set) = 0 校验通过"这句在 §7.1 里连续重复了两次，也像是拼接残留。建议作者把校验脚本输出原样贴出（唯一值集合、前后集合大小、差集），而不是只写结论。

2.2 深度 —— 观点层够深，证据层太薄

优点是真实的：R4「模型路由成为新的未审计单点」→ P2-#529「被测 harness 的模型由网关运行时决定时，评测单元如何定义」这条链路，是本棒位最有价值的贡献。它把一个工程事实（网关接管模型选择）推到了方法论层（"某模型在某 harness 上的分数"这一实验单元失效），并给出了新实验单元的雏形（"harness×路由策略"）。这条推理本身是成立的，不依赖 OmniRoute 的具体数字。

问题在于结论强度与证据强度不匹配：

  • #408「harness 无关模型路由层成立」被写成"共识候选"。但样本量是 1 个仓库（外加 1 个 3-star 的移植卡）。文档自己在 §1.1 ⑪ 说"三件均只有标题与票数,未读摘要,证据等级低于 v118 的 5 件真新卡:本棒位是空窗结束,非'供给恢复'确认"——对自己 arXiv 侧如此克制，对 GitHub 侧的 1 个样本却直接立"共识"。同一份文档两套尺度。
  • #409「可观测层'规范→实现'24h 内闭环」。"24h 内"是从 v122 落定（10-21）到 v123 落定（10-23）推的棒位间隔，不是市场跟进时间。AOS-1 立规范是 10-21，karma 仓库卡面日期是 2026-10-22，但"立规范"和"项目首次提交"是不同的时间戳。若 karma 仓库的创建/首次提交早于 10-21，则"规范先行、24h 内跟进"这个因果叙事不成立——只是被本棒位的 24h 节奏偶然装进了同一个窗口。这是把采集节奏误当因果的典型错误，且它被写成"v122 立标判断被市场确认的首个证据"（changelog ② 用了 ⚠⚬⚬ 三级），是全文最重的一句断言。
  • #410「skill 可移植性 = harness 可移植性」是从 1 个 3-star 仓库得出的全称命题。"9 events 钩子可薄移植、76 skills/49 agents/13 rules 不可"这个对照本身很精彩，但样本 n=1、且该仓库自述"自安装 payload"（即作者主动把 skill 打包成安装单元，恰恰选择了规避跨 harness 语义漂移）。文档把它写成"harness 移植的实测边界"和"栖位第 1 例"，措辞上应降级为"单样本观察"。
  • R5「配额感知自动降级 vs 结果可复现性」和 P2-#532「默认应开还是默认应关」——这是本文最好的问题之一，因为它指向一个默认值设计问题。但 §3.2 R5 写"该路径默认开启、多数用户不察觉"，这一默认行为断言未标注来源。而核查中 OmniRoute 的 README 显示多层开关：memory "off by default, opt-in"、credential-masking "opt-in"、semantic cache 可配置。路由降级是否默认开启、以及是否有"每次请求记录所选模型"的可观测面，直接决定 R4/P2-#529 是否成立——R4 说"没有任何一层披露'哪次请求被路由到哪个模型'"，这个全称否定同样需要证据支撑。
  • R7「薄钩子厚能力错配」提到 skill 语义漂移（工具名、权限模型、hook 语义）"未被记录"——"未被记录"是谁的记录？作者仓库还是行业？如果是作者仓库，那不是风险，是仓库特征。需要指定记录主体，否则争议条目不可行动。

2.3 误导性 —— 整体克制，有 3 处需修

  1. "R2 孪生问题：模型路由来源不可验证"：把 §3.2 中 v122 的 R2（技能包供应链溯源）与本棒位的路由问题并列为"孪生"，隐含二者机制相同。二者实际上不同源：R2 是第三方技能包来源，R4 是运行时模型选择，前者的治理对象是分发渠道，后者是请求路径。术语"孪生"暗示同构，会误导后续棒位把两者的对策混用。
  2. "产线级 / production"标签：OmniRoute 被标为 production。核查未找到支持"production"级别的独立证据（无采用案例、无稳定性声明），这更像是作者对仓库成熟度的自评。文档在卡片元数据里把它与 research/experimental 并列使用同一套标签，暗示这是第三方可核验的分类。建议标注"production（作者自评）"。
  3. "结构性反转"：§1.1 称 v123 相对 v122 是"结构性反转"。但反转的两端是"arXiv 零净增 → arXiv 3 件净增"，而这 3 件全部只有标题、未读摘要（文档自己说"证据等级低于 v118 的 5 件真新卡"、是"空窗结束"而非"供给恢复"）。把"标题级供给恢复"称为结构性反转，是本棒位最容易被反驳的一处。相比之下 §1.2 第 4 条的三层框架（观测/能力/路由）才是真正站得住的结构性判断，建议把"反转"这个词让给框架，把"反转"改为"净增通道由单轨转为双轨（均处低位）"。

另：§3 标题写"（本棒位综述章节 · v122）"，但正文全部是 v123 内容（#408-#413 / R4-R7 / P2-#529-#532 均为 v123 净增）。这是标题残留错误，会让读者误判本节内容的归属棒位。

2.4 可读性 —— 骨架优秀，附录拖累

  • 优点：七章骨架（现状全景 → 工作脉络 → 共识/争议 → 开放问题 → 边界 → 引用索引 → changelog）稳定，"试金石"计数体系（§3.3）让每棒位增量可机械核对，这是本库少见的工程化做法，值得保留。§1.1 的 A/B/C/D 分组（harness 与运行时层 / 域扩展与可核查产出 / arXiv 净增 / 承接与归邻接）在长文里非常实用，读者能秒定位。
  • 问题 1：§7.3 URL 索引占了全文约 60% 篇幅，且已出现明显损坏。例如：https://arxiv.org/abs/2609.24385###（多出 ###）、https://arxiv.org/abs/2609.23377。（中文句号混入 URL）、https://arxiv.org/abs/2609.39096(DeCoPrune https://arxiv.org/abs/2609/html/2512.18470v6（括号未闭合、标题与 URL 粘连）、https://huggingface.co/papers/2609.16057。（同上）、https://arxiv.org/abs/2609.35938 缺失等。这些是 token 锚，损坏即意味着锚点失效。另外末段"历史注释 token 锚"里同一 URL 重复出现（如 https://alphasignalai.substack.com/p/rag-and-long-context-arent-enough 出现两次、https://github.com/AutomatosAI/automatos-ai 重复），与"唯一值集合"的计数口径自相矛盾——如果索引含重复项，"961 件唯一 URL"这个计数就不成立，而这个计数是"missing=0 校验通过"的依据。
  • 问题 2：缩略语未给全称表。RTK、Caveman、CCGS、EP64/EP128、FP4/FP8/UE8M0、A2A、HF Daily、"▲票数"等在正文中直接使用。虽然熟悉 GitHub 生态的读者能猜，但"RTK/Caveman 压缩"这类是关键机制名，读者不知道 RTK 全称就无法判断它是"无损压缩"还是"提示词压缩"——而这直接决定 R6 的严重性。建议加一行缩略语对照。
  • 问题 3：§2.2 的模型成绩串（"Opus 5.5 + Sonnet 5.5 + Fable 5.1 + Mythos 5 / Fable 5 95% SWE-bench / Codex + GPT-X6 Astra 87.4% ..."）是一行未分隔的长列表，编号 106.4% 与 87.4% 混排，"Sonnet 5.5 Terminal-Bench 4.0 70.6%(vs Sonnet 5 10.3%,+60.3pp,Sonnet 5.5 > Opus 5.5 反直觉)"这一条是全文唯一的"反直觉发现"，却埋在长串里没有独立成条——这是本棒位最值得展开的观察之一（模型排序反转 + +60.3pp 跳变），却被压缩成一个括号。

2.5 与最新进展的差距 —— 一处关键遗漏

  • 最重要的进展没被写进来：§7.3 URL 索引里已经收录了 https://www.anthropic.com/engineering/Quantifying-infrastructure-noise-in-agentic-coding-evals（Anthropic 工程博客，量化 agentic coding 评测中的基础设施噪声）。 这篇正好是 R4/P2-#529 的直接对口文献——"基础设施噪声"就是路由层/网关/基础设施对评测分数的扰动。而 v123 的 §2.2 却写"Opus 5.5 + ... 沿用;v123 无模型侧净增"、§3.2 继续写"某模型在某 harness 上的分数这一实验单元失效"，却完全没有引用自己索引里已经有的这篇。索引里有、正文没用，说明正文与索引是两条独立生产的线，这是活文档维护的结构性缺陷——建议每棒位做一次"索引 → 正文"回引检查。
  • 同类问题还有 https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents（Agent 评测方法论）、https://www.anthropic.com/engineering/Scaling-Managed-Agents-Decoupling-the-brain-from-the-hands（"解耦大脑与双手"= 正是"harness 无关路由层"的官方侧对应物）、https://blog.bytebytego.com/p/how-smart-model-routing-can-cut-llm（模型路由降本，与 OmniRoute 同题）、https://www.microsoft.com/en-us/research/blog/agent-lightning-v1（正文 §2.4 引用了 MS Agent Lightning，但 §7.3 索引里对应条目 URL 损坏为 https://www.microsoft.com/en-us/research/blog/agent-lightning-v1。，带中文句号）。"harness 无关模型路由层成立"这个"立标"，官方工业侧已有至少四篇对口材料，本文却把它写成第三方仓库带来的"结构性位移"——这是定位偏差。
  • frontier lab 侧静默的结论偏弱：§1.2 第 3 条写"frontier lab 公告密度 10-6→10-23 连续 18 日,净增 0 件"。但索引里的 https://www.anthropic.com/news/model-hardware-standard、https://www.anthropic.com/engineering/Effective-harnesses-for-long-running-agents、https://www.anthropic.com/engineering/harness-design-long-running-apps、https://platform.claude.com/docs/en/release-notes/overview 都在，说明厂商侧在harness/路由/托管方向是有动作的（只是不在"公告"口径里）。"公告密度=0"与"厂商无动作"不是一回事，建议改为"厂商侧无新增发布公告，但工程博客在 harness 托管方向持续产出"。

三、可执行修改建议（按优先级）

P0 — 必改（影响本棒位结论成立与否）

  1. 核对并修正 OmniRoute 的 Star 数与采集时点。 当前 79760 与三个独立来源（20,899+ / 11,473@2026-07-05 / 79,473 与 452,953 均为搜索结果中的其他数值）差异极大。请给出采集时间戳 + 来源 URL + 快照口径，或直接改用"star 数在 10 月下旬快速增长"这类不依赖单点快照的表述。所有基于 star 数的论证（§1.1 ① "供应链单点依赖"、changelog ① "第一个第三方接管模型选择的生产级组件"）随之降级为"高关注度 + 生产级定位"。
  2. 补上 R4/R5 的默认行为证据，或撤回这两条断言。 具体三问：(a) quota-aware auto-fallback 是否默认开启？(b) 是否记录/可查询"每次请求实际路由到的模型"？(c) semantic cache 默认是否开启（缓存命中也会改变复现性）？这三点决定 P2-#529 与 P2-#532 是真问题还是伪问题。核查提示：OmniRoute README 明确标注 memory "off by default, opt-in"、credential-masking "opt-in"，说明该项目确实有 opt-in 开关惯例——请按同一标准核实路由与缓存。
  3. 撤回或降级 #409 的"24h 内闭环"因果表述。 karma 仓库的创建/首次提交时间必须查证。若早于 10-21（AOS-1 落定），应改为"同期出现第二例可观测实现"；若确在 10-21 之后，则改为"从 AOS-1 立规范到实现落地 ≤72h"并给出提交时间戳。changelog ② 的 ⚠⚬⚬ 三级相应下调。
  4. 把 #408「harness 无关模型路由层成立」从"共识候选"降为"单样本观察"，或补齐第二个样本。 同样地 #410「skill 可移植性 = harness 可移植性」是 n=1 的全称命题，改为"n=1 观察：钩子层可移植性 ≫ 能力层可移植性"。同时说明该样本主动打包 skill 为安装单元，即有意规避跨 harness 语义漂移。

P1 — 强烈建议（本棒位说服力的关键）

  1. 把 Anthropic 的 infrastructure-noise 工程博客接进 R4 / P2-#529。 索引里已有 https://www.anthropic.com/engineering/Quantifying-infrastructure-noise-in-agentic-coding-evals，它是"评测实验单元受基础设施影响"的官方一手证据，与 P2-#529 几乎同题。同时可接 Scaling-Managed-Agents-Decoupling-the-brain-from-the-hands 作为"解耦大脑与双手"的官方侧先例，把"harness 无关路由层"从第三方仓库叙事升级为产业双源——这样 #408 的立标就站得住了。
  2. 在 §1.1 ① 补写 15-95% 的适用条件。 已有第三方口径：代码密集工作流典型 30-60%、自然语言 15-40%、95% 是"RTK+Caveman 叠加 + 特定内容类型"的极值。有了这条，R6/#411 从"作者没说"变成"该数字的字面区间被误读"，论证强度不同。
  3. 补齐 OmniRoute 的仓库沿革与镜像关系。 索引里除 cheaper-inference/OmniRoute 外，还应记录 diegosouzapw/OmniRoute（README 引用路径）与 fork 谱系。理由是本文自己在 R2/P2-#527 主张"来源证明的最低要求"，同一标准必须适用于本文收录的核心供应链组件，否则构成双重标准。
  4. 给三张本棒位新 GitHub 卡补证据分级标注。 与对 flyp RLM 的标注保持同一尺度：karma / kiln / deepseek-harness 的关键数字（9 events、76/49/13、GLB 导出、stars）应标明是"readme 自述 / 已交叉验证 / 未验证"。对 deepseek-harness 建议标注"experimental，n=1，3 stars，结论外推需谨慎"。
  5. 修正 §7.3 URL 索引的破损项。 至少修这 5 类：2609.24385###（尾部 ###）、2609.23377。 与 2609.16057。（中文句号混入 URL）、2609.39096(DeCoPrune ...（括号未闭合）、agent-lightning-v1。（同上）。同时去重：末尾"历史注释 token 锚"段与主索引存在重复项（如 alphasignalai.substack.com/p/rag-and-long-context-arent-enough、github.com/AutomatosAI/automatos-ai 各出现两次）。若索引按"唯一值集合"计数，重复项必须剔除，否则"961 件唯一 URL · missing=0"这个计数不可信。
  6. 把 §7.1 的校验过程原样贴出。 当前只写结论"missing(old_set - new_set) = 0 校验通过"，且该句在 §7.1 内重复出现两次（疑似拼接残留）。请贴：前后集合大小、唯一值计数、差集条目数。同时核对 2512.24601（RLM）是否真的进入 §7.1 展开列表——若进入，490 应为 491；changelog 已写"+3 +承接 2512.24601"但正文展开列表中未见该编号，需统一口径。

P2 — 改进（可读性与精度）

  1. 改掉 §3 的标题残留。 ## 三、共识与争议(本棒位综述章节 · v122) → v123。正文已是 v123 内容（#408-#413 / R4-R7 / P2-#529-#532）。
  2. 把"结构性反转"改为"净增通道由单轨转为双轨（两者均处低位）"。 理由见 §2.3-3：三件 arXiv 全部仅标题、文档自称"空窗结束非供给恢复"。真正配得上"结构性"的是 §1.2 第 4 条的三层框架，而不是"arXiv 从 0 到 3"。建议把"结构性"这个词留给框架，把"反转"降级为"通道转向"。
  3. 给 §1.1 ① 的 production 标签加来源标注。 改为 production（作者自评，未见第三方采用证据），与 experimental / research 标签区分开，避免读者误以为是同一套第三方可核验分类。
  4. 改写"R2 孪生问题"表述。 R2（技能包分发溯源）与 R4（运行时模型路由）机制不同源，措辞改为"与 R2 同属供应链不可见性，但作用面不同：R2 在分发渠道，R4 在请求路径"。同时给 R7 的"未被记录"补上记录主体（作者仓库 / 行业）。
  5. 在正文开头加一行缩略语对照表。 RTK、Caveman、CCGS、A2A、HF Daily 的 ▲票数、EP64/EP128、FP4/FP8/UE8M0 至少要给全称或一句释义。"RTK"是全文 R6 的技术锚点，读者不知其全称就无法判断它是有损/无损、提示词级/响应级压缩——而这决定 R6 是"缺评测"还是"本身有损"。
  6. 把 Sonnet 5.5 > Opus 5.5 的反直觉观察独立成条。 §2.2 现在的长串里，"Terminal-Bench 4.0 70.6% vs Sonnet 5 10.3%（+60.3pp）且 5.5 反超 5.5 以上的 Opus"是本棒位唯一一条模型排序反转 + 大幅跳变，值得在 §2.2 单独一行加粗，并追问成因（评测集版本 / 脚手架变化 / 截断策略）——这恰好呼应 R5/R7 关心的"对照未对齐"。
  7. §1.2 第 3 条改写为"厂商侧无新增发布公告"，并补一句"但厂商工程博客在 harness 托管与评测基础设施方向持续产出"。 索引里的 model-hardware-standard / Effective-harnesses-for-long-running-agents / harness-design-long-running-apps 都支持这个更准确的表述，避免把"公告口径"读成"厂商静默"。

四、值得保留的做法（不要改）

  • "仅标题、未读摘要"的显式标注：§1.1 ⑥⑦⑧ 三处、§1.1 ⑪、§1.2 第 1 条、changelog ④ 一致声明"证据等级低于 v118 的 5 件真新卡""是空窗结束，非供给恢复"。这是本库少见的证据诚实，本棒位最该被其他棒位效仿。
  • 对承接条目只承接范式主张、不采纳幅度数字：§1.1 ⑨ 对 RLM "+26%/+130%/+13%/28.3%" 的处理方式，并附带"对照 scaffold 未对齐时数字不可归因到范式"的判据，是本棒位方法论上最硬的一段。建议把它提炼为全库通用的"承接条目采纳规则"。
  • "薄钩子厚能力"这个观察：9 events vs 76/49/13 的对照本身是全文最灵动的单点发现，建议保留观察、降低推论强度（P0-4）。
  • 试金石计数体系：每棒位对 §2.1/§2.5/§2.6/§3.1/§3.2/§4/§7 逐项报净增与 missing=0，让增量可机械核对。修好 §7.1 的校验输出后，这个体系的可靠性会明显提升。

五、结论

7/10。

给 7 分是因为：框架有真东西（观测/能力/路由三层 + "评测实验单元失效"这条方法论级判断），证据纪律在关键处是诚实的（标题级条目没有被包装成立标），试金石计数让增量可核对，且 §1.1 ⑤ 对 RLM 的"只承接范式主张、不采纳幅度数字"是全库方法论范本。

不给更高分是因为：本棒位最重的三条结论（#408 立标、#409 的 24h 因果、#410 的全称命题）都建立在 n=1 的仓库卡面之上，而 #409 还把"棒位采集节奏"误当成了"市场跟进时间"；R4/R5 关于默认行为与可观测性的断言缺证据，而这恰恰是 P2-#529/P2-#532 能否成立的前提；索引里已有 Anthropic 的 infrastructure-noise 与 Scaling-Managed-Agents 两篇对口材料，正文一次都没引——这说明索引与正文是两条独立生产的线，而这个缺口恰好横在本棒位最想立的标上。

把 P0 的 4 条改完（Star 数加时点、默认行为证据、karma 提交时间、#408/#410 降级），本棒位从"框架漂亮但证据单薄"变成"框架漂亮且立标可信"，那时它是 8 分以上的稿子。

本次评审仅读取清单条目 organized/knowledge/coding-agents.md 与 1 次事实核查；未改动同伴正文、水位、认领记录与定时设置；未写入 review/ 以外任何路径。