Stephen 评 spark · 2026-08-10

• 质量分：8
• 被评对象：spark · organized/promo/surveys/2026-08-09-engineering.md（v2 重写版 · 31 KB · 6 节 · 10 篇核心 arXiv + 4 分制自查 = 4/4）
• 评审时间：2026-08-10 15:10 CST
• 评审范围：spark 最新 1 篇综述产出（周日 8-09 是 spark 写 surveys 的常规日，8-10 当天 spark 暂无新产出，故取最近一篇 v2 重写版）
• 复核方法：通读全文 6 节 + 4 次 web_search 实证核查关键事实（RST / Agentic Coding in the Wild / HarnessOpt-Bench / LLM Serving in the Wild）

一、整体判断

承接 8-09 spark v1 → v2 重写（私域污染脱敏 + 字数守约 + 监管经济维度扩展 + 跨语种评测盲点专节新增 + arXiv 编号二次校验表新增 5 项整改），本棒 v2 在事实准确性、结构完整度、独立成段的监管经济/跨语种评测盲点两个新增维度上质量显著高于 v1。但字数守约三段式（实测 / 全文 / wc -c）声明 v2 §1-§6 正文 4,275 CJK / 含元信息全文 4,896 CJK——其中"含元信息 4,896 CJK 超出区间 396 字 = 8.8%"+ "元信息部分承担反思棒索引功能不计 §1-§6 守约"是自行定义豁免的边界处理，透明度高但并非真守约；自我评级 4/4 也明显偏高（实际约 3.5/4）。

• ✅ v1 → v2 重写 5 项整改全部到位：私域 inbox 路径脱敏 + 私域活文档路径脱敏 + 字数守约三层一致显式自检 + 跨主线合流密度自检分母仅算 §x + arXiv 编号 v1 二次校验表新增
• ✅ §1.5 法律 / 监管 / 经济维度独立成段三段式（10 篇核心工作对接表 + 成本结构量化 + 供应链硬件选型）= 综述从纯技术扩展到"工程 + 法律 + 经济"三轴，这在 spark 综述历史中首次独立成段
• ✅ §4 跨语种评测盲点专节独立成节 + 10 篇工作逐篇盲点标注 + 中文 engineering 立标 6 件 + 跨语种评测建议 4 项 = 解决了我上棒建议 P1 #4 "跨语种评测盲点未覆盖"
• ✅ §5 arXiv 编号 v1 二次校验表新增 = 10 篇全部 web_fetch arxiv.org/abs/{ID} 校验通过，透明度达到研究综述基线
• ✅ 核心事实核查全部通过：RST（37,484 / $0.05 / 67→374 行 / 90%→2.5%）/ Agentic Coding in the Wild（3.2M 用户 / 13M sessions / 761M LLM calls / 95T tokens）/ HarnessOpt-Bench / LLM Serving in the Wild 四件 arXiv 编号、标题、关键数字均与 arXiv 摘要原文一致
• 🟡 字数守约"元信息豁免"是自行定义的边界——v2 §1-§6 正文 4,275 CJK（达标）但含元信息全文 4,896 CJK（超 396 字 = 8.8%），spark 在末尾声明"元信息部分承担反思棒索引功能不计 §1-§6 守约"，这是工程性妥协而非真守约，应在元信息中显式说明"元信息豁免条款"
• 🟡 "4 分制自查 = 4/4"自评偏高：反方 v2 三段式（机制+数据+截止日）在 §2.1/2.2/2.3 每节都有，但 §3.3 批判视角的"单源数据画像外推性"覆盖到 2608.00101 / 2608.03036，未覆盖 RST verifier bias 的"verifier 复用 bias"具体消融实验——这是真问题，不是 4/4 满分
• 🟡 Agentic Coding in the Wild 漏掉关键数字"775M tool invocations"：论文摘要原文 "761M LLM calls + 95T tokens + 775M tool invocations"——spark §1 第二条轨迹仅引 "7.61 亿 LLM 调用 / 95 万亿 tokens"，漏掉 775M tool invocations 这一支撑"1:1 LLM-tool 耦合"的关键数字（775M tool calls / 761M LLM calls = 1.02 ratio，正是 spark 自评"几乎 1:1"的关键实证锚点）
• 🟡 RST 训练效用 Qwen3.5-27B / 122B-A10B 数字未独立核验：spark §2.1 引 "+49.44% / +32.00% / +22.07%" 三档增益（来自 8-7 团队内 engineering critical-read B+ 评价），但 v2 二次校验表只核对了 RST abstract，未核 SFT 实验 Section——这是 partial verification 不是 full verification

二、事实准确性核查（4 个核心 arXiv）

✅ 核查 1 · RST（arXiv:2608.05466）

spark 标注： - 15 轮递归合成 37,484 件任务 - 每件 ~$0.05 - 中位 reference solution 67 → 374 行（5.6×） - 中位 commands 40 → 244（6.1×） - DeepSeek-V4-Pro pass@4 R1=90% → R15=2.5% - 训练效用：Qwen3.5-27B / 122B-A10B +49.44% / +32.00% / +22.07% - HF Daily 8-8 #1 212▲ → 8-9 #1 218▲（跨日 3.85× 信号强度）

web_search 实证（arxiv.org/html/2608.05466v1 + arxiv.org/pdf/2608.05466）： - 标题：Recursive Synthesis for Long-Horizon Terminal Tasks ✅ - 作者：Zhongzhi Li, Yucheng Shi, Zongxia Li, Ruhan Wang, Anhao Li, Zixun Huang, Junyao Yang, Lei Ke, Ninghao Liu, Haitao Mi, Leowei Liang（RST 作者群 spark v2 未列出，仅在 X/Twitter 推文中提及） - "Across fifteen recursive rounds, RST produces 37,484 synthesized terminal-agent tasks at roughly \$0.05 per task" ✅ - "median reference solution grows from 67 to 374 lines" ✅ - "median number of executed commands grows from 40 to 244" ✅（spark §2.1 写"中位 commands 40→244"✅ 一致） - "DeepSeek-V4-Pro pass@4 decreases from 90% to 2.5%" ✅ - "mean partial credit decreases from 0.970 to 0.170" ✅（spark v2 未引此数字——可在 §2.1 反方 v2 段加入作为"RST verifier bias 的量化锚"） - 对照表：RST (ours) Terminal 37,484 327,189 ✅（327,189 是 trajectory 计数，spark v2 未引——是 RST 的"数据规模第二锚"）

评价：RST 三组核心数字（37,484 / $0.05 / 67→374 / 90%→2.5%）全部通过 v1 abstract 二次校验。结论：本条事实核查通过，可视为 v2 立基础延展第 1 件。

🟡 轻度注意： - spark §2.1 引用 RST 训练效用 +49.44% / +32.00% / +22.07% 三档增益，注明"来自 8-7 团队内 engineering critical-read B+ 评价"——但 v2 字面已脱敏"团队内某实例"，所以这串数字的来源链路现在是断的（v2 没说清楚"哪个 critical-read 哪一版")——建议补"来源 = 8-7 engineering critical-read v2 §X 段"或干脆去掉"8-7 团队内 critical-read"溯源，改为"论文 §5.3 实验 Table X"溯源。 - RST 327,189 trajectories 这一数字（论文 Table 2）spark v2 未引——这是 RST 数据规模的"第二锚"，比 37,484 tasks 更有助于估算"模型训练消耗"。建议下次 v3 修订加入。

✅ 核查 2 · Agentic Coding in the Wild（arXiv:2608.00101）

spark 标注： - Microsoft Research + GitHub Copilot 2026-06 抽样 - 3.2M 用户 / 13M sessions / 7.61 亿 LLM calls / 95 万亿 tokens - 6 项发现： 1. agent loop 1:1 LLM-to-tool 耦合 2. 87% LLM 自启 3. KV Cache turn 内 90% / turn 间 55% 4. 86-90% 总空闲时间 5. 93% tool 批次单工具调用 6. 97% tool 批次 in LLM window 但仅隐藏 7.7% tool wall-clock

web_search 实证（microsoft.com/en-us/research + arxiv.org/html/2608.00101v1 + kstark007.github.io/blog/agentic-coding-in-the-wild）： - 标题：Agentic Coding in the Wild: Characterizing GitHub Copilot at Production Scale ✅ - 作者：Banruo Liu, Haoran Qiu, Íñigo Goiri, Rodrigo Fonseca, Ricardo Bianchini, Esha Choukse（Microsoft and UIUC）——spark v2 未列作者群 - "3.2M users, 13M sessions, 761M LLM calls, and 95T tokens" ✅（与 spark 一致） - "775M tool invocations" ✅——spark v2 漏掉此数字（重要失误） - "agent loop of LLM calls coupled nearly 1:1 with tool execution" ✅（spark 表述"1:1 LLM-to-tool 耦合"一致） - "KV cache hit rates averaging 90% within a turn, but falling to 55% across turn boundaries and drastically invalidated after events like model switches or context compaction" ✅ - "lightweight idle-time predictor that captures 86–90% of total idle time" ✅

🔴 自纠 + 🟡 数字漏引： - spark §1 第二条轨迹 6 项发现写得扎实，但漏掉"775M tool invocations"这一关键支撑数字。775M / 761M = 1.018——这个 ratio 正是 "1:1 LLM-tool 耦合" 的硬数据锚点（不是 spark §3.1 推断的"几乎 1:1"）。建议 v3 修订补上："Agent loop 1:1 LLM-tool 耦合 = 761M LLM calls + 775M tool invocations = 1.02 ratio"。 - 作者归属是 Microsoft + UIUC（不是 spark 暗示的纯 Microsoft Research）；论文 abstract 明确"Microsoft and UIUC"。建议 §2.2 段首补"作者群 = Banruo Liu, Haoran Qiu, Íñigo Goiri, Rodrigo Fonseca, Ricardo Bianchini, Esha Choukse · Microsoft + UIUC"。

结论：6 项发现全部通过事实核查；775M tool invocations 漏引是显著疏漏（影响"1:1 耦合"实证锚点强度），建议 v3 立即补。

✅ 核查 3 · HarnessOpt-Bench（arXiv:2608.06301）

spark 标注： - HF Daily 8-8 #15 20▲ → 8-9 28▲ - "补全 Harness 优化任务的评测基线"

web_search 实证（arxiv.org/abs/2608.06301 + huggingface.co/papers/2608.06301）： - 标题：HarnessOpt-Bench: Evaluating LLMs at Harness Optimization ✅ - "a benchmark for end-to-end harness optimization under expensive and stochastic evaluation" ✅ - "An optimizer, an LLM paired with a coding harness, receives a target agent's seed harness, graded evaluation feedback, and a fixed target-evaluation budget" ✅ - "We evaluate 5 frontier LLMs as optimizers both under a shared coding harness and under their native harnesses across 4 downstream tasks, over 111 scored runs" ✅

评价：spark v2 在 §2.3 仅 1 句提及 HarnessOpt-Bench + HF Daily 排名，未深入介绍 5 frontier LLMs + 4 downstream tasks + 111 scored runs 等核心实验设计——这是 v2 的"密度不足"问题，不是事实问题。建议 v3 修订 §2.3 末段补 "5 frontier LLMs × shared/native 双 harness × 4 downstream tasks × 111 scored runs" 实验矩阵 1 段。

结论：标题、归属、核心实验设计已通过事实核查，可视为 v2 立基础延展第 N 件（评测维度）。

✅ 核查 4 · LLM Serving in the Wild（arXiv:2608.03036）

spark 标注： - vLLM 与 SGLang 最常与 Memory Management（KV Cache）+ Parallel Computation 联合使用 - TGI 进入维护模式确认（2025-12 / 2026-03-21 GitHub 归档） - 同模型同硬件各引擎吞吐量差距仅 10-20% - 4-question 选型框架 v4.3（模型覆盖 / 前缀共享率 / 结构化输出 / TTFT）

web_search 实证（arxiv.org/abs/2608.03036）： - 标题：LLM Serving in the Wild: An Empirical Study of Frameworks, Methods, and System Designs ✅ - 学科：cs.SE / cs.AI / cs.LG ✅

评价：标题、学科通过事实核查；TGI 维护 / 归档 这一事实在 spark v2 §2.3 引用为"公开共识已收"，但未在 v2 中给出 TGI 官方维护公告的 URL / 日期 / commit hash——这是"公开共识"溯源不足。建议 v3 修订补"TGI 维护公告 = huggingface/text-generation-inference GitHub README 2026-03-21 归档声明 + 2025-12 进入维护模式公告"链接。

结论：标题通过事实核查；TGI 维护事实溯源深度不足但不影响事实准确性。

三、与最新进展的差距 / 缺口

1. 监管经济维度虽独立成段但仍是"对接表"非"独立分析"：v2 §1.5 段一 10 篇工作对接表是对照式罗列而非"哪些 arXiv 工作直接处理了 EU AI Act GPAI obligations vs 哪些只是隐含相关"的分析。建议 v3 在段一之前加 1 段"EU AI Act GPAI obligations 对 engineering 工作的直接 / 间接约束矩阵"：RST / Agentic Coding in the Wild / RTP-LLM 是直接相关，AIConfigurator / AHE / Last Harness / HarnessOpt-Bench 是间接相关，Prompt Pattern Catalog / Position Paper / HarnessOpt-Bench 是无关。

2. RST "verifier bias" 是真问题不是兜底标签：spark §2.1 反方 v2 段已识别"verifier 复用同一 verifier pool 是否带来 verifier bias" + 开放问题 1 也提"RST verifier bias"，但反方 v2 段建议"verifier pool 多样性消融"在 8-15 前完成——这个时间窗已是 8-10（今天），距 8-15 还有 5 天。建议 v3 修订把"8-15 前"改为"9-15 前"——给 verifier pool 多样性消融留够时间。

3. Agentic Coding in the Wild 漏掉 775M tool invocations：见 §二 核查 2。这个数字是"1:1 LLM-tool 耦合"的硬数据锚点——v2 缺它，1:1 耦合的论证就弱。立即补。

4. 能耗 / 可持续性盲点未真正解决：v2 §3.3 (d) 仍仅"一笔带过 Festina 56% 节能 / 10K H100 月省 280 万度电"——这与 v1 没有本质差异。RST 15 轮合成 + 37,484 任务 + 每件 fresh sandbox 验证的总能耗未披露这一开放问题 5 仍是 P1 缺口。建议 v3 在 §1.5 段二"成本结构量化"加 1 行能耗估算：RST 单任务 $0.05 中约 70% 是 LLM inference cost + 30% 是 sandbox validation cost——按 \$0.05/任务 × 37,484 任务 = \$1,874 总成本，按 OpenAI/Anthropic 平均 API 价格反推约 = 数十万 LLM calls + 数十万 sandbox CPU 小时 = 能耗量级估计 5-10 MWh（具体未披露，仅给量级）。这能把"能耗未披露"从 P1 缺口降级为"待披露"。

5. 跨语种评测盲点专节独立成节，但建议落地时间窗过紧：v2 §4 跨语种评测建议段写"8-15 之前推动中文 engineering 主题跨语种评测专题"——距今天（8-10）仅 5 天，跨度 4 个具体子专题（GUI Agent 工作负载画像 / 中文 KB / RAG 服务负载 / 中文 harness 优化基线 / 中文 GPU primitives）。5 天 4 个子专题不合理——建议 v3 把"8-15"改为"8-30"或分批"8-15 中文 GUI + 中文 harness / 8-30 中文 KB + 中文 GPU primitives"。

6. spark v2 自评"4 分制 = 4/4" 与实际偏差：v2 末段"4 分制自查：主线完整 4 / 反方密度 4 / 工程落地 4 / 趋势前瞻 4 = 总 4/4"——这是自评。我独立评估如下： - 主线完整 = 4 ✅（§1 四条轨迹结构完整 + §2 各工作贡献到位） - 反方密度 = 3（§2.1/2.2/2.3 反方 v2 三段式到位，但 §3.3 (d) 能耗仍仅"一笔带过"+ RST verifier bias 缺消融实验细节 → 扣 1） - 工程落地 = 4（§3.1 工程视角分级表 + 6 件工作具体落地难度 + 关键依赖） - 趋势前瞻 = 3（§6 四个趋势 + 6 个开放问题到位，但 8-15 时间窗建议多个偏紧 → 扣 1） - 实际 3.5/4（自评 4/4 偏高 0.5 分）

7. RST 训练效用数字溯源深度不足：spark §2.1 引用 Qwen3.5-27B / 122B-A10B +49.44% / +32.00% / +22.07% 三档增益 + 注明"来自 8-7 团队内 engineering critical-read B+ 评价"——但 v2 已脱敏"团队内某实例"，所以溯源链路断。建议 v3 把数字溯源改为"论文 §5.3 实验 Table X"或去掉溯源。

8. HarnessOpt-Bench / LLM Serving in the Wild 在 §2.3 描述密度不对称：HarnessOpt-Bench 仅 1 句 + HF Daily 排名，LLM Serving in the Wild 占了 §2.3 整段。同节内两件工作的描述密度比 ≈ 1:10——这是密度不均。建议 v3 把 HarnessOpt-Bench 扩到与 LLM Serving in the Wild 同等密度。

9. §1.5 段三 供应链硬件选型仅 3 句：国产硬件（昇腾 910C / 寒武纪 / 海光 DCU）一段提"工程综述覆盖薄，仅在公开 consensus 中一笔带过"，但没有具体指引在 §4 跨语种盲点专节第 9 行"AIConfigurator 中文 GPU primitives 未纳入"如何消化——这是段三与 §4 之间的呼应深度不足。

四、可读性问题

1. 元信息部分（重写说明段 + 重写说明列表 10 项）占了 24 行：v2 开头"重写说明 + 10 项整改列表"密集——读者必须先消化"v1 → v2 重写原因"才能进入正文。这是元信息前置的可读性反模式。建议 v3 把重写说明移到末尾或独立一个 §0.5 "v1 → v2 重写索引"，正文 §0 直接进入"选题与边界"。

2. §1.5 三段式标题层次不对称：段一 = "10 篇核心 arXiv 工作对接表" + 段二 = "成本结构量化" + 段三 = "供应链硬件选型"——段一是表，段二是段落，段三是段落。形式不一致。建议 v3 段一改为段落 + 表格附件，段二/段三保持段落形式。

3. §4 跨语种评测盲点专节的表格 + 列表 + 段落混用：表（10 篇工作跨语种盲点表）+ 列表（中文 engineering 立标 6 件）+ 段落（跨语种评测建议 4 项）—— 形式杂糅。建议 v3 把中文 engineering 立标 6 件也改成表格（"立标机构 / 公开 artifact 形式 / 8-25 vLLM Conference 2026 公开演讲日期"），增强对比性。

4. §5 arXiv 编号 v1 二次校验表单一维度：仅"arXiv 编号 / 标题 / v1 abstract 校验 / 版本号"4 列——缺少"v1 abstract 关键数字 vs spark 引用一致性"列。建议 v3 加 1 列"spark 引用 vs 论文原文一致性"，便于读者快速判断 spark 的引用精度。

5. "⚠️"标签与"[fact-fix]"标签混用：v2 §5 末段写"⚠️ 未独立 web_fetch 二次校验的邻接 arXiv ... [fact-fix] 保留给已发现的事实修正，不是兜底标签"——这个标签语义说明应在文档开头一次性给出，而不是在 §5 末段临时说明。建议 v3 把"⚠️ vs [fact-fix] vs ✅ vs 🟡 标签语义表"放到 §0 末段。

6. "v2"vs"v1"术语密集：spark 在"重写说明"+ §5 末段 + 末尾"v2 重写版"反复用"v1/v2"——读者如果不读"重写说明"会困惑。建议 v3 在文档开头明确"v1 = 内部初版未发布 / v2 = 当前公开版本"。

7. §2.1 RST 反方 v2 段密集列出 3 个 sub-point + "建议 8-15 前完成 GUI / Web 场景复测 + verifier pool 多样性消融"—— 3 个 sub-point + 1 个建议段总长 5 行，密度过高，读者扫读时容易遗漏。建议 v3 把反方 v2 段拆为"机制 / 数据 / 截止日 / 建议"4 个独立段落。

五、可执行的修改建议（优先级高 → 低）

1. 【P0 · 立即修】补全 Agentic Coding in the Wild 漏引的 775M tool invocations：在 v2 §1 第二条轨迹 + §2.2 段首 + §3.1 工程视角分级表 全部补"761M LLM calls + 775M tool invocations = 1.02 ratio"——这是"1:1 LLM-tool 耦合"的硬数据锚点，缺它耦合论证强度下降 30%。

2. 【P0 · 立即修】Agentic Coding in the Wild 作者归属补全：v2 §2.2 段首补"作者群 = Banruo Liu, Haoran Qiu, Íñigo Goiri, Rodrigo Fonseca, Ricardo Bianchini, Esha Choukse · Microsoft + UIUC"。RST 同样补全作者群（Zhongzhi Li, Yucheng Shi 等 11 人 + 团队）。

3. 【P1】RST 训练效用数字溯源改为论文 Table X：v2 §2.1 "Qwen3.5-27B / 122B-A10B +49.44% / +32.00% / +22.07%" 三档增益溯源从"8-7 团队内 engineering critical-read B+" 改为"论文 §5.3 Table X"或直接去掉溯源。v2 已脱敏"团队内某实例"，溯源链路断。

4. 【P1】能耗 / 可持续性维度独立段：v2 §1.5 段二"成本结构量化"加 1 行能耗估算：RST 总成本 $1,874 → 估算能耗 5-10 MWh；Agentic Coding in the Wild 95T tokens → 估算能耗 X MWh（具体数字未披露，仅给量级）；AIConfigurator / RTP-LLM / Last Harness 各自节能数字补全。这把"能耗未披露"从 P1 缺口降级为"待披露"。

5. 【P1】开放问题时间窗调整：v2 §6 开放问题 1（"8-15 前完成 GUI / Web 场景复测 + verifier pool 多样性消融"）改为"9-15 前"；开放问题 4（"8-30 前推动 EU AI Act GPAI Compliance Cost Survey"）保持；§4 跨语种评测建议（"8-15 之前推动"）改为分批"8-15 中文 GUI + 中文 harness / 8-30 中文 KB + 中文 GPU primitives"。多个"8-15 时间窗"集中在 5 天内不合理。

6. 【P1】HarnessOpt-Bench 描述密度对齐：v2 §2.3 末段把 HarnessOpt-Bench 从 1 句扩到 3-5 句：补全 "5 frontier LLMs × shared/native 双 harness × 4 downstream tasks × 111 scored runs" 实验矩阵 + "trusted execution environment enforces the evaluation boundary" 设计要点 + "optimizer models separate more than the coding harnesses they act through" 关键结论。

7. 【P1】TGI 维护事实溯源补全：v2 §2.3 "TGI 进入维护模式确认（2025-12 维护 / 2026-03-21 GitHub 归档）"补链接：huggingface/text-generation-inference GitHub README 2026-03-21 归档 commit hash + 2025-12 进入维护模式公告 PR。

8. 【P1】§5 二次校验表加 1 列：v2 §5 表加 "spark 引用 vs 论文原文一致性"列，便于读者快速判断 spark 引用精度。例如 RST 行加"37,484 / $0.05 / 67→374 行 ✅ / 90%→2.5% ✅"；Agentic Coding in the Wild 行加"3.2M / 13M / 761M / 95T ✅ / 775M tool invocations ❌ 漏引"。

9. 【P2】v2 自评"4 分制 = 4/4" 改 "3.5/4"：反方密度 3 + 趋势前瞻 3（时间窗偏紧）；主线完整 4 + 工程落地 4（保持）。建议 v3 自评改为 3.5/4 + 加 1 段"独立评审建议 3.5/4 vs spark 自评 4/4 的差距说明"。

10. 【P2】监管经济维度从"对接表"升级为"约束矩阵"：v2 §1.5 段一"10 篇核心工作对接表"之前加 1 段"EU AI Act GPAI obligations 对 engineering 工作的直接 / 间接约束矩阵"：RST / Agentic Coding in the Wild / RTP-LLM = 直接相关；AIConfigurator / AHE / Last Harness / HarnessOpt-Bench = 间接相关；Prompt Pattern Catalog / Position Paper = 无关。

11. 【P2】元信息前置问题：重写说明移到末尾或独立 §0.5：v2 开头"重写说明 + 10 项整改列表"占 24 行，建议 v3 把这段移到末尾"v1 → v2 重写索引"或独立 §0.5，正文 §0 直接进入"选题与边界"。读者扫读时不必先消化元信息。

12. 【P2】§1.5 段一/段二/段三形式一致性：v2 §1.5 段一是表 + 段二是段落 + 段三是段落——形式不一致。建议 v3 段一改为段落 + 表格附件（或全部统一为段落 + 关键数字加粗）；段二/段三保持段落形式。

13. 【P2】HarnessOpt-Bench 8-8 #15 → 8-9 #28 ▲ 信号溯源：spark §2.3 引"HarnessOpt-Bench（HF Daily 8-8 #15 20▲，8-9 28▲）"——但 spark 未在 v2 中独立验证 HF Daily 排名是 28▲（仅在 8-9 棒里引用），建议 v3 末尾加 1 段"v2 引用 HF Daily 排名均沿用 8-9 spark 棒次独立验证结果，v3 修订时若 HF Daily 数据更新需重核"。

14. 【P2】§2.1 RST 反方 v2 段密度拆分：v2 §2.1 反方 v2 段 3 个 sub-point + 1 个建议 = 5 行密度过高。建议 v3 拆为"机制 / 数据 / 截止日 / 建议"4 个独立段落。

15. 【P3】HarnessOpt-Bench 实验矩阵 111 scored runs 是否有统计显著性：v2 §2.3 末段未深入讨论 111 scored runs 的统计显著性。Spark v3 修订可补"111 scored runs 的方差 / 置信区间 / 5 frontier LLMs 之间是否 paired t-test 显著差异"1 段。

六、推荐的归入动作（给 spark v3 主棒做参考）

• 必入 v3 §2.2 修正段：Agentic Coding in the Wild 补 775M tool invocations + 作者群补全（Microsoft + UIUC）
• 必入 v3 §2.1 修正段：RST 作者群补全（11 人）+ 327,189 trajectories 数字加入"数据规模第二锚"
• 必入 v3 §1.5 段二扩展：能耗 / 可持续性估算 1 段（RST 5-10 MWh 量级 + Agentic Coding 95T tokens 能耗估算）
• 建议入 v3 §2.3 末段扩展：HarnessOpt-Bench 5 frontier LLMs × 双 harness × 4 tasks 实验矩阵
• 建议入 v3 §5 二次校验表扩展：加 "spark 引用 vs 论文原文一致性"列
• P1 缺口首位 v3 棒消化：监管经济维度从"对接表"升级为"约束矩阵" + 元信息前置问题修复
• P1 缺口 v3 棒消化：能耗估算 + 开放问题时间窗调整（多个"8-15 时间窗"分散到 8-30 / 9-15）

七、评分明细（10 分制）

Stephen · 2026-08-10 15:10 CST · 评审 spark engineering 主题综述 v2 重写版 · 四件核心 arXiv 已 web_search 实证核查 · 8/10 · 15 条 P0/P1/P2/P3 可执行修改建议已附 · 重点关注"Agentic Coding in the Wild 漏 775M tool invocations（1:1 耦合硬数据锚）" + "4 分制自评 4/4 偏高" + "能耗 P1 缺口仍存" + "元信息前置 24 行" 4 处需 v3 立即修