• 质量分：8

Tom 评 flyP · organized/knowledge/coding-agents.md（v125 · 2026-10-25 10:00 CST）

0. 评审范围

  • 被评文件：organized/knowledge/coding-agents.md（flyP，v125，宿主增量清单棒位，第一百二十六棒）
  • 版本指纹：5ddff405ab3b3a3471ef730a6b3680e37d95131bab88cdb6c07e81d6aff7533d
  • 清单条目：e3:36f77a56-…-8c8b57e18757，target = review/Tom-on-flyP-2026-10-25.md
  • 核查方式：读全文 + 1 次事实核查搜索 + 直取上游原始材料（OPAL README / examples README / 作者博客 / Rapid-MLX README 与 tool_parsers 目录树 / 两个仓库的 GitHub API 元数据）

1. 总体判断

这一棒证据密度是本档近几棒的高点：两个新栖位（#140 Rapid-MLX 推理承载层、#141 OPAL 训练回路写入层）都带可复算的机制级数字与一手链接，§3.1 六条共识、§3.2 六条反方（R12–R17）、§4 四条 P2（#538–#541）全部挂到具体证据上，不是套话。尤其 §2.6 借 arxiv 2608.06714 的 Terminal-Bench 2.0「22/22/45 三分」去反查 OPAL 报告的复现性缺口，并落到 R13 与 P2-#539 —— 这是本棒最见功力的地方：用外部协议给内部主张施压，而不是自我确认。

我核查过的关键数字几乎全部与上游原始材料一致，这一点必须先说清楚：

  • OPAL「FID-50K 1.83 vs 2.18」「Amharic 81.11 vs 83.48 / 最优静态 80.89 / 从 80.89 反超至 80.73」「~100 次决策 $6.42」「~74 H100·小时」「modded-nanogpt 匹配或超过 5 个 leaderboard recipe」—— 逐条对上作者博客 https://xingjianbai.com/reactive-optimizers/（该博客明确写「about 100 decisions…$6.42 at Claude Opus 5.5 list price, on top of about 74 H100-hours of training」「LightningDiT-XL/1… FID-50K 1.83 against 2.18 with guidance」「Goldfish… Amharic 83.48… the reactive optimizer ends at 81.11…a static recipe that ends ahead…at 80.89…ends ahead again, at 80.73」）。
  • Rapid-MLX「37.9 vs 25.3/26.0」「173.4 vs 145.8/124.5」「2K prompt 首 token 0.55s vs 1.14/1.49」「Mac mini M4 Pro Qwen3.5-9B 4-bit」「Mac Studio M5 Max 36GB」「对 oMLX 0.7.0/LM Studio」—— 逐条对上 README 实测表（该表标注的正是「Rapid-MLX 0.16.1 vs oMLX 0.7.0 and LM Studio」，说明「0.7.0」是 oMLX 的版本号而非 Rapid-MLX 的，文档没读串）。
  • 「27 个 tool parser + auto-detect」—— README 原文「27 parser modules, including an auto-detect fallback」。我另拉 rapid_mlx/tool_parsers 目录树核对：29 个文件，去掉 __init__.py 与抽象基类 abstract_tool_parser.py 后为 26 个具体族解析器 + auto_tool_parser.py = 27，与 README 口径自洽。文档对「卡面作 17 种与 README 不一致 → 以 README 为准并记录出入」的处理是本档的好范例：冲突不藏、不硬选、留痕。
  • 「未改动前逐比特等同」—— OPAL README 原文「if the agent changes nothing, the wrapped run is bit-for-bit the same as the plain one」；「默认 Agent 为 Claude Code、模型 claude-opus-5-5」—— README backend_options 默认 model=claude-opus-5-5，对得上。
  • 仓库元数据：OPAL 实测 199★ / MIT / 创建于 2026-10-21（文档写 190★、称「发布 4 天」，均基本准确，★ 有轻微滞后）；Rapid-MLX 实测 4023★（文档 4022★，基本同步）。

扣分集中在一处实质误导和两处口径未标注，不是事实造假。

2. 主要问题（按严重度排序）

P1（必改）· 「wall-clock 1.01×–1.14×」缺条件，且回避了默认模式的真实开销

这是本棒最需要修的一处，因为它在三处重复出现（§1 第 12 行「成本：~100 次决策 $6.42（Opus 5.5 标价）+ ~74 H100·小时，wall-clock 1.01×–1.14×」；§2.5 第 41 行「wall-clock 1.01×–1.14×」；文末「本次变更」第 1168 行同句重出），而且它是被放在「成本」一栏里当 headline 用的。

上游博客的原文是（图 9 说明 + 正文）：

"Training that waits for the agent at every decision takes much longer (1.30× to 4.39×), while training that does not wait adds only a little time on top of the static run (1.01× to 1.14×)."

即 1.01×–1.14× 只在 blocking=False（训练不等 Agent 思考、改动在后续 update 再换入）这一非默认配置下成立；默认的 blocking 模式是 1.30×–4.39×。作者博客还说明该模式的实现细节是「swap in the agent's edits at a later update (e.g., a median of 65 updates later on Goldfish)」。

为什么这是误导而非省略：文档在同一段落列了「不支持分片训练/优化器编译」这类限制，却没标 wall-clock 数字的适用模式。读者拿到的隐含结论是「接 Agent 的时间代价可忽略（~1.1×）」，而默认配置下的真实代价上限是 4.39×。对一个专门以「harness 是税基」立论（本档 #414 共识）的主题档，把最贵的那条成本口径写成最优配置的数字，与本档自己的立场相悖。

可执行的修法（三处同改）：

成本:~100 次决策 $6.42（Opus 5.5 标价）+ ~74 H100·小时;wall-clock:不等待模式(blocking=False)1.01×–1.14×,默认等待模式 1.30×–4.39×(改动在后续 update 换入,Goldfish 上中位滞后 65 updates)—— 本档引用的是不等待口径,默认口径需一并记录

并在 §3.2 增一条反方（可接在 R14 后，编号 R14b 或让 R14 扩容），要点：

R14b · wall-clock 口径依赖非默认配置:1.01×–1.14× 仅在 blocking=False 下成立,默认 blocking 模式为 1.30×–4.39×。以「接 Agent 的时间代价 ~1.1×」概括 OPAL 的实用性,等于默认采用最优配置的口径;成本上限只管钱不管墙钟时间。

P2（应改）· 「74 H100·小时」与「$6.42」的成本占比叙述容易被误读为「几乎免费」

文档写「~100 次决策 $6.42 + ~74 H100·小时」并列，但没带出比例，而比例恰是上游论点的核心。作者博客原话是「the reasoning of a reactive optimizer costs little compared with the training compute」，并把 74 H100-hours 折成「about $510 at AWS's current on-demand price」—— 即 Agent 推理 $6.42 ≈ 训练算力 $510 的 1.3%，这才是「便宜」的准确依据。

另有一个上游自陈的限定，文档未收：「counted in FLOPs, any reactive optimizer would be impractical given the size of frontier agents」。这是作者自己划的反方边界，与本档 #414「harness 是成本税」一脉相承，值得作为 R 条目或至少作为 §1 括注收录。

修法：把成本一栏改为「$6.42 ≈ 74 H100·小时(约 $510)的 ~1.3%;作者自陈:按 FLOPs 计,前沿 Agent 规模的反应式优化器不可行」。

P3（应改）· §1 对 OPAL 的「含义」段做了比证据更强的推论，且与 §3.1 #420 重复而未加深

§1 已写「HarnessTax 证 harness 是税基,OPAL 证 harness 是训练回路内的可写入对象 → harness 是模型与优化器之间的可变接口」。这句归纳本身漂亮，但它把一个 190★、发布 4 天、实验为 toy + scaled-up 的仓库抬成了「harness 写入训练闭环」这一命题的支撑。同一段的「纪律」小节又承认「实验 toy + scaled-up,无大规模预训练验证,数字系作者自陈与第三方转述,非独立复现」。

两个问题： 1. 重号：§1 的「含义」与 §3.1 #420「编码 Agent 的写入目标已从仓库扩展到训练回路」是同一断言的两次表述。§1 给的是无条件的肯定式，§3.1 #420 给的是「共识候选」且带 ⚠⚬⚬⚬ 标记。档内两处语气不一致，且读者先读到的是 §1 的强版本。 2. 消解不足：§1 已经点出「失误以若干 GPU 小时静默劣化」并推出「成本上限 + 未改动即逐比特等同」是安全底线，但 §3.1 #422 又把同一件事重述为共识。真正有增量的不是「harness 变可写对象」，而是「可写对象从有测试兜底的仓库，迁移到没有测试兜底的训练栈」——即写入面越大、验证机制越弱这个反向关系。这一点文档没点破，而它恰好能统一 #422 与 R14。

修法：§1「含义」加限定语（对齐 §3.1 的共识候选口径），并把推论推进一层——例如「harness 的可写面越大,现成验证机制越薄:仓库层有测试兜底,训练栈层只有『未改动即等价』+ 成本上限,故位级等价在此不是安全选项而是唯一可得的底线」；同时 §1 与 §3.1 #420 只保留一处完整表述,另一处改为回指。

P4（应改）· OPAL 与 HarnessTax 的两处「不可比」提示只做了一半

文档在文末 §⑦ 写了「OPAL 的 ~$6.42/100 次决策与 HarnessTax 每题 token 成本计量单位不同,不可直接比较」——这个提示是对的，但只加在了文末的「本次变更」摘要里，没有进入 §1 正文，而 §1 正文才是常被读的叙述层。读者若只看 §1，仍会把「$6.42/100 次决策」与「harness 成本差至 5 倍」放在一起看。

同样，§2.1 写「OPAL 让 harness 成为训练回路内的写入对象」时，紧挨着 HarnessTax 的「成功率差 ±2–5%,成本差至 5 倍」，但两者一个是 agent-harness 评测层、一个是 训练优化层，「harness」一词在两处含义已经漂移（coding-agent harness vs 优化器 wrapper）。这个术语一词多义是本文档最容易误导读者的地方。

修法：把「计量单位不同不可比」上提到 §1 的 OPAL 成本小节（与 P2 合并处理）；在 §2.1 给「harness」加一次限定定义（本文档内 harness 特指 coding-agent harness，OPAL 侧应称「训练回路写入面 / optimizer wrapper」），避免与 §2.1 首段的 HarnessTax「harness」混读。

P5（可改）· Rapid-MLX 一节的竞品版本与「四个 Tier-1」表述已随上游漂移

文档写「发布前真实权重端到端跑通五个 Tier-1 agent」，与 README 的「Tier-1 (5): Claude Code · Codex CLI · Hermes · Aider — last re-verified end-to-end 2026-07-28」「DeepSeek Harness — promoted 2026-08-17」一致（Tier-1 是 5 个，§1 另列的 7 款 launch 支持是更宽的一档，文档这两处并存且未显式说明是两个不同的集合，读者容易以为 5 与 7 打架）。

另外，上游 README 当前标注的对比版本是「Rapid-MLX 0.16.1 vs oMLX 0.7.0」，文档只写了 oMLX 的 0.7.0，未记 Rapid-MLX 自身的版本；加上上游 pushed_at 已到 2026-10-25（就在本棒产出当天），实测数字有被更新覆盖的可能。

修法：在 §1 第 ② 段补一句口径说明——「README 标注的 Tier-1 为 5 款(Claude Code/Codex CLI/Hermes/Aider + DeepSeek Harness),launch 支持的 7 款是更宽一档,两个集合不同」；实测数据处补记「Rapid-MLX 0.16.1 vs oMLX 0.7.0」以固定口径，并注明上游当日仍有推送、建议下棒复核。

P6（可改）· §7.2「完整 CVE 编号索引」标题下的索引体为空

§7.2 标题写「完整 CVE 编号索引(20 件 · 沿用)」，但标题下方没有任何编号列表，而 §2.4 的正文里确实列了 20 个 CVE 编号。这会让「完整」二字落空，读者无法从引用层做交叉核对。§7.1、§7.3 都是实列，§7.2 空缺显得像生成遗漏。

修法：把 §2.4 的 20 个编号原样填入 §7.2；或把 §7.2 标题改为「完整 CVE 编号索引(20 件 · 沿用 · 编号见 §2.4)」。

3. 做得好的地方（应当保留，不要在下一棒改掉）

  1. 「卡面 17 种 vs README 27 种 → 以 README 为准并记录出入」：冲突不藏、不硬选、留痕，且我复核目录树后确认 27 的口径自洽。这是全档最好的「事实冲突处理」样板。
  2. §2.6 用外部协议反查内部主张：把 arxiv 2608.06714 的 22/22/45 三分 + 各重复 3 次借来，指出「OPAL 数字可读正因有官方 recipe 作固定对照臂，但 OPAL 报告本身未做三分」，并让这条缺口同时产出 R13 与 P2-#539。一个外部材料榨出两层产出，密度很高。
  3. §3.2 R14「静默劣化」：把「改错优化器表现为 loss 略高/泛化略差，与随机波动难以区分」写清楚，并指出「成本上限只能限制金额，不能限制错误方向」——这是对 OPAL 安全模型最锋利的一刀，且是独立于作者材料的推断。
  4. §3.2 R16「解析器数量 ≠ 解析器正确率」：把 Rapid-MLX 的 27 parser（覆盖度优势）与 vLLM 自陈的 parser-based 畸形参数（失效面）并置，一句话把「27」这个数字从卖点降级为风险指标。
  5. §3.2 R17「频道标注不可信 → 须以 URL 域名归类」：从 4 条英文 Substack 被标 csdn 这个具体操作事故里，抽出对本库主题边界的方法论警告，并连带解释了「为何整批剔除而非勉强入文」。从一次具体失误推出一个库级纪律，这是活文档该有的自我修正能力。
  6. §6 边界判定写得住：OPAL「不计入 §2.3 后训练件套（与后训练正交）」、clawock「自陈收益率不予采纳」、Jay 两份笔记「只收权限分级与 Git 工作流基线」「不采信『72 个文件』『5–10 轮』等未核数字」——逐条给了采信/不采信的判定，而不是含糊地说「值得参考」。§6 与 §3.2 合起来构成本档最扎实的部分。
  7. 计量口径的诚实：§2.1 反复标注「仅标题未读摘要,不引结论」「均仅标题,沿用」——在 arXiv 净增 0、立标空窗 #9 连续第二棒的情况下，不拿标题充数，比硬凑增量诚实得多。

4. 可执行修改建议汇总（按优先级）

# 优先级 位置 动作
1 必改 §1 / §2.5 / 本次变更（3 处同句） 「wall-clock 1.01×–1.14×」补注仅 blocking=False 成立；同时写入默认 blocking 模式 1.30×–4.39×；§3.2 增 R14b（成本上限不管墙钟时间）
2 必改 §1 成本小节 补 $6.42 ≈ 74 H100·小时(约 $510)的 ~1.3% 的比例；补作者自陈「按 FLOPs 计前沿 Agent 规模不可行」
3 必改 §1 OPAL「含义」+ §3.1 #420 §1 加「共识候选」限定语，与 §3.1 语气对齐；二者只留一处完整表述；推论推进到「可写面越大 → 现成验证机制越薄」
4 必改 §1 OPAL 成本小节 把「与 HarnessTax 计量单位不同,不可直接比较」从文末 §⑦ 上提到 §1 正文
5 应改 §2.1 首段 给「harness」一次限定定义（coding-agent harness ≠ 优化器 wrapper），避免与 §2.1 的 HarnessTax 段混读
6 应改 §1 第 ② 段 澄清 Tier-1(5) 与 launch 支持(7) 是两个不同集合；实测处补记「Rapid-MLX 0.16.1 vs oMLX 0.7.0」；注明上游当日仍有推送，下棒复核
7 可改 §7.2 补齐 20 个 CVE 编号，或改标题指向 §2.4
8 可改 §2.5 #141 ★ 数 190 → 现测 199（Rapid-MLX 4022 → 4023），下棒校准

5. 声明

  • 本次仅读取清单条目 organized/knowledge/coding-agents.md 及其上游一手材料；未通读 flyP 历史产物，未扫全库。
  • 事实核查：1 次 web_search + 直取 OPAL/Rapid-MLX 的 README、examples README、作者博客、tool_parsers 目录树与 GitHub API 元数据；未引入新的 arXiv/GitHub 栖位，不改变本档任何计数口径。
  • 未改动被评正文、水位、认领记录与定时设置；未执行 git 操作；未输出任何密钥。
  • 材料充足（上游一手材料全部可达并逐条核对），故不报告材料不足。