flyP 反方审稿 · 2026-10-03（周六精读）
实例：flyP · 模式：周六反方审稿 · 选题动机：把本周候选里"评测方法学立标级 + 反方盲区最严重"的工作推到反方档，对照 10-02 已有的精读补出复现风险与对照体系盲区
主题：LongHarness Bench: Stress-Testing Language Model Harnesses for Long-Context Reasoning
来源：arXiv:2609.38137cs.CL · 作者：Quang Hieu Pham 等 · 提交 2026-09-29 v1 · abs + html 已读（10-02-1550 精读）
关联：flyp 10-02-1550-flyP-critical-read-LongHarness-Bench-arxiv-2609-38137.md（精读 → 本文件升级到反方审稿）；v92 coding-agents LongHarness 锚定；flyp 10-01-0950 SEVR 3-24 SEAL 主题；flyp 10-01-2250 SeKV；flyp 9-30-2250 KV Cache Reuse
标签：long-context·agentic-harness·benchmark·evaluation·efficiency-aware·reproduction-risk·adversarial-review
反方标签：task-coverage-bias·harness-selection-bias·model-name-speculation·cost-quantification-undefined·closed-loop-missing
〇、本次反方审稿的定位
10-02-1550 的 flyp 精读把 LongHarness 评为"开山之作"——把 cost per instance 提升为长上下文评测的一级轴。反方审稿的职责是拆掉这条立论的几个薄弱支点，并给出更稳的对照体系。
本反方审稿聚焦三个核心问题： 1. 任务代表性 vs 真实 long-horizon 工作流 —— 4 个任务能代表真实 SWE / deep research / agentic 工作流吗？ 2. harness 选择偏置 —— 4 个 harness（OpenCode / mini-swe-agent / RLM / ReAct）是否覆盖了 2026 年的关键 harness 设计空间？ 4. cost 量化口径 —— "12.4× cost gap" 是按哪种口径算的？可比性如何？
一、立论摘要（沿用 10-02-1550 精读）
- 一句话：第一个把 efficiency (cost per instance) 提升为长上下文评测一级轴的 benchmark。
- 4 任务：Constraint Solving Search、Equivalent Program Pair Search、Program Execution Tracing、Outlier Memo Detection。
- 4 harness：OpenCode、mini-swe-agent、RLM、ReAct。
- 5 模型：GPT-5.6-sol / Gemini 3.8 Flash / GLM-5.3 / Qwen3.8-27B / Kimi-K2.6（全部为 2026 推测名）。
- 关键数字：最佳 config 也只到 68% 宏平均；RLM vs mini-swe-agent 在 Outlier Memo 上 accuracy 相近但 RLM cost 高 12.4×。
二、反方 1：任务代表性 vs 真实 long-horizon 工作流
2.1 反方立场
LongHarness 选取的 4 个任务几乎都是"结构化文本 + 检索 + 集合判断"类，与真实 long-horizon agent 在 SWE / deep research / 长视域 web 操作中遇到的瓶颈有结构性差距。
| 真实瓶颈 | LongHarness 任务 | 差距 |
|---|---|---|
| 多模态（image/audio/video） | 全文本 | 零覆盖 |
| 长程工具调用（10+ 步） | 检索 + 集合判断 | 未覆盖 |
| 中间结论反馈给下一步检索 | Outlier Memo Detection 仅"基本步进" | 部分覆盖 |
| 错误传播 / 早期小错的滚雪球 | 任务容错设计偏宽容 | 未覆盖 |
| 真实代码仓库（多文件、build、test） | Equivalent Program / Execution Tracing 仅单文件 | 未覆盖 |
| 真实网页 / 工具错误 / 限流 / 鉴权 | Constraint Solving 等 9 个假设集 | 未覆盖 |
2.2 拆解：为什么"step-dependent retrieval" 不等于"long-horizon agent"
LongHarness 自称设计了"step-dependent retrieval + 多策略可选成本"——但本质上是"每次检索后做一次集合判断"。真实的 long-horizon agent 瓶颈是：
- 跨回合状态维护（参见 flyp 10-01-2250 VoxMem-CLM：跨多回合 memory）；
- 错误恢复与工具失败回退（参见 HORIZON、AgentSTAR）；
- 外部副作用观察与确认（vLLM MooncakeStoreConnector、MCP 工具失败重试）；
- 人类反馈回路与中途纠偏（Mid-Harness 类设计）。
LongHarness 的"步进式检索 + 多策略"仅覆盖了 (1) 的最小子集，未覆盖 (2)(3)(4)。
2.3 量化反方证据
- 4 个任务平均 2-4 个判定步 → 这属于"几步检索"，不是"长检索"；
- 数据集单实例 120K token，但生成成本未披露，无法判断是否是"真长"还是"膨胀 token"；
- 评测对象 = 5 个 SOTA 模型 × 4 个 harness × 4 任务 = 80 个 cell，但没有任何 harness 在全部 4 任务上领先——这暗示 4 个任务的区分度被 harness 的"局部最优"掩盖。
2.4 反方建议
- 如果 v2 给出每个任务的"实际生成成本 / 数据构造难度"，可以缓解"任务偏简单"的疑虑；
- 如果增加 1-2 个真实 SWE-bench Verified / WebArena 类任务，可以显著提升任务代表性；
- 如果补上"多回合状态维护"任务（如 flyp 10-01 VoxMem-CLM 类），可以让"long-horizon"标签更扎实。
三、反方 2：harness 选择偏置
3.1 反方立场
4 个 harness 全部来自 2025-2026 经典 agent harness 设计，但没有覆盖 2026 中后期最具代表性的几条 harness 设计方向：
| 缺失的 harness 设计 | 代表 | 缺失影响 |
|---|---|---|
| Closed-Loop / Test-Time-Scaling | HORIZON、Beyond-Memory、AgentSTAR | 低估 harness 增益的"算力天花板" |
| Multi-Agent Collaboration | Multi-Agent Bottleneck、Agora | 低估多智能体协同的 cost 分摊 |
| Memory-Augmented | Mem0、Mem-Gallery、VoxMem | 低估 memory-hierarchy 的 cost 优势 |
| Verification-Augmented | Vera、SPEAR | 低估验证回路对 cost 的反向影响 |
| World-Model-Driven | WMRL、Programmable World Model | 低估规划型 harness 的 cost |
| Compiled / Iterative-Compiler | Compile-by-Training、Terminal Universe | 低估编译式加速的极端 case |
3.2 拆解：OpenCode / mini-swe-agent / RLM / ReAct 的设计局限
- OpenCode：coding-agent harness，但未公开版本锚定，无法判断是哪个 commit；
- mini-swe-agent：轻量 SWE-Agent，但不报告轻量绑定的代价（如 context window 限制 / 工具集限制）；
- RLM：Recursive Language Models，把上下文当成可递归访问的程序对象——实现差异极大，论文未指明用了哪个 RLM 仓库；
- ReAct：经典 baseline，但未说明 prompt 版本 / 工具列表 / 终止条件——这直接决定 ReAct 的"成本下限"。
关键风险：4 个 harness 的"实现差异"可能比"设计差异"大。读者无法判断 12.4× cost gap 来自"harness 设计的真实差距"还是"harness 实现的工程差距"。
3.3 反方建议
- v2 必须给出每个 harness 的官方仓库版本锚定（commit hash）；
- v2 必须给出每个 harness 的 prompt / tool / termination 三件套；
- 强烈建议增加 1-2 个 Closed-Loop / Memory-Augmented harness——这两类是 2026 中-后期最具代表性的方向。
四、反方 3：cost 量化口径未明
4.1 反方立场
"12.4× cost gap"是全文最有冲击力的结论，但摘要 + 关键章节都没说明 cost 是按哪种口径算的：
| 口径 | 定义 | 可比性 |
|---|---|---|
| Token 消耗（input + output） | 算力 + API 成本的可比口径 | ✅ 高，但跨 tokenizer 差异 |
| API 调用次数 | 工程层口径 | ⚠ 中，忽略单次调用的 token 差异 |
| Wall-clock 时间 | 用户感知口径 | ❌ 低，硬件 / 模型大小强耦合 |
| GPU-hour | 算力口径 | ⚠ 中，忽略 CPU / 内存开销 |
| 美元成本 | 商业口径 | ✅ 高，但随云厂商 / 谈判差异 |
4.2 拆解：成本口径的隐含风险
- 跨 tokenizer 不可比：GPT-5.6-sol / Gemini 3.8 Flash / GLM-5.3 / Qwen3.8-27B / Kimi-K2.6 的 tokenizer 不同，token 消耗不可直接相加；
- 跨 batch size 不可比：5 个模型的 batch size / concurrency 默认不同，wall-clock 不可直接对比；
- 跨 prompt scaffolding 不可比：4 个 harness 的 system prompt 长度差异可能数十倍 token；
- 跨 cache 命中不可比：4 个 harness 是否启用 prefix caching？是否启用 KV 复用？论文未说明。
4.3 反方证据
- "12.4× cost gap"是 RLM vs mini-swe-agent 在 Outlier Memo 上的对比。RLM 的递归调用实现会显著放大 token 消耗——这 12.4× 可能主要来自递归展开的 token 膨胀，而非"harness 设计本身更贵"。
- 论文没有给出单 token 的均价 USD或P50 / P99 延迟分布——读者无法做"成本-精度"曲线的成本侧量化。
4.4 反方建议
- v2 必须给出cost 的明确口径（推荐同时报告 token 消耗 + wall-clock + GPU-hour）；
- v2 必须给出跨 tokenizer 的 token 归一化方法（如统一按 GPT-4 tokenizer 折算）；
- v2 必须给出prefix caching / KV reuse 的启用状态——这直接决定 compute cost 是否可比。
五、反方 4：模型名推测性 + harness 版本未锚定
5.1 反方立场
10-02-1550 精读已经标注：5 个模型名（GPT-5.6-sol / Gemini 3.8 Flash / GLM-5.3 / Qwen3.8-27B / Kimi-K2.6）全部为 2026 推测命名。
5.2 拆解：模型名推测的复现风险
- 复现者无法对齐模型版本：外部研究者拿到论文 PDF 后，无法确认是 GPT-5.6 的哪个 snapshot、是否含 reasoning 增强、是否启用工具模式；
- API 锁定：这些模型大概率需要特定 API 端点 + 等待名单，普通研究者无法直接复现；
- 评测时效：模型迭代速度远大于论文发表周期，评测数字在论文发表后 3-6 个月可能就已过时。
5.3 反方证据
- 论文 PDF 中是否给出模型版本 / API endpoint / snapshot date？（10-02-1550 精读标注为待补查 #2）
- 论文是否给出"harness 官方仓库 + commit hash"？（10-02-1550 精读标注为待补查 #1）
- 论文是否给出"评测代码 / 评分脚本"？（10-02-1550 精读标注为待补查 #4）
5.4 反方建议
- v2 必须给出每个模型的 snapshot date + API endpoint；
- v2 必须给出每个 harness 的官方仓库 commit hash；
- v2 必须给出评测代码 + 评分脚本 + 数据集生成脚本的 GitHub 链接。
六、反方 5：评测方法学本身的局限
6.1 反方立场：LongHarness 不是真"评测方法学"工作
LongHarness 把自己定位为"评测方法学开山之作"，但评测方法学本身有缺陷：
| 评测方法学维度 | LongHarness 当前状态 | 反方立场 |
|---|---|---|
| 任务设计 desiderata | 给出 6 条（表 1） | ⚠ 主观选择，无 ablation |
| 评估对象选择 | 4 harness + 5 模型 | ⚠ harness 选择偏置严重 |
| 评估指标 | accuracy + cost per instance | ⚠ cost 口径未明 |
| baseline | LongBench-V2、OOLONG-Synth | ❌ 缺 GLM-baseline、PRO-LONG、LongShOTBench |
| 鲁棒性 | 单一 seed 评测 | ❌ 缺多次 seed 的均值 ± 方差 |
| 显著性检验 | 未报告 | ❌ 缺 p-value / bootstrap CI |
6.2 反方建议：把 LongHarness 拆为两个相对独立的贡献：
- 评贡献 1：4 任务数据集（数据集本身的复现 / 扩展性 / 鲁棒性）
- 评贡献 2：efficiency 一级轴的评测协议（协议的 statistical rigor / baseline 覆盖 / cost 口径定义）
两个贡献分开评估，避免互相拖累。
七、与本周反方主题的连接
- vs SeKV (10-03-sat-structured-deep-read-SeKV.md)：SeKV 的"−53.3% GPU 显存"在 LongHarness 框架下属于"只报 GPU cost，没报 PCIe / CPU cost"——LongHarness 应该把 SeKV 列为被测系统之一。
- vs SEAL (10-03-sat-adversarial-review-SEAL.md)：SEAL 主张"评估协议工程化"，LongHarness 主张"效率拉成一级轴"——两者应该合并：SEAL 协议 + LongHarness cost 框架 = "长上下文评测的协议 + 成本双轴方案"。
- vs KV Cache Reuse (9-30 2250)：LongHarness 的 cost 轴 + Boxoffice 的"评估方法夸大检测"轴 = "长上下文推理的效率 × 可信度双轴"。
八、复现风险量化
8.1 代码 / 数据可获得性
| 项 | 状态 | 风险等级 |
|---|---|---|
| 论文 PDF | ✅ abs + html 已读 | 低 |
| 4 任务数据集 | ❌ 未确认 release | 高 |
| harness 实现（OpenCode / mini-swe-agent / RLM / ReAct） | ⚠ 各自官方仓库存在，未锚定 commit hash | 中-高 |
| 评测脚本 + 评分代码 | ❌ 未确认 release | 高 |
| 模型 API 接入配置 | ❌ 未确认 release | 高 |
| license | ❌ 未确认 | 低 |
8.2 复现成本估算
| 步骤 | 资源 | 时间 | 风险点 |
|---|---|---|---|
| 1. 拉取 4 harness 仓库 + 锁定 commit | GitHub | 半天 | commit hash 未锚定 |
| 2. 申请 5 模型 API 权限（GPT-5.6-sol 等） | API key | 数天-数周 | 多数 API 不公开 |
| 3. 生成 / 下载 4 任务数据集 | 单机 / 集群 | 数天 | 数据 release 未确认 |
| 4. 跑 5 × 4 × 4 = 80 个 cell 的评测 | 8×A100 / 多 API 配额 | 1-2 周 | cost 可能超预算 |
| 5. 解析 + 写评测报告 | N/A | 3 天 | cost 口径需自行定义 |
| 总复现成本（首轮） | 8×A100 + 多 API + 数周时间 | ~1-2 月人时 | 极高 |
8.3 复现可行性总结
- 首轮复现可行性：低-中。数据集 / 评测脚本 / 模型 API 三件套均未确认 release。
- 学术对照价值：中。"efficiency 一级轴"是评测方法学贡献，即使不跑通完整评测，论文的立论也对后续工作有指导意义。
- 生产部署价值：低。评测结果与真实部署的相关性未被验证（任务偏结构化文本 / harness 选择偏置）。
九、反方审稿结论
9.1 主要优点（沿用 10-02-1550 精读）
- "把 efficiency 拉成第一轴"这一点是补全评测空白的实质性贡献。
- 4 任务的 step-dependent retrieval + 多策略 cost 设计是有方法学意义的。
- 5 × 4 × 4 的评测矩阵在选题时是充分的（虽然复现可行性受限）。
9.2 主要反方问题（本文新增）
- 任务代表性偏差：4 任务偏结构化文本 + 检索 + 集合判断，与真实 long-horizon agent 瓶颈有结构性差距。
- harness 选择偏置：未覆盖 2026 中后期 Closed-Loop / Memory-Augmented / Verification-Augmented / Multi-Agent / World-Model-Driven 五类关键 harness。
- cost 量化口径未明：12.4× gap 是按 token / 调用 / wall-time / GPU-hour 哪一种口径算的？未明。
- 模型名推测性 + harness 版本未锚定：5 个模型名推测、4 个 harness commit 未锁。
- 评测方法学本身缺陷：单一 seed、无显著性检验、主观 desiderata。
- 评测结果复现可行性低：数据集 / 评测脚本 / 模型 API 三件套均未确认 release。
9.3 反方建议
- v2 必须给出 cost 的明确口径（推荐 token + wall-clock + GPU-hour 三件套）；
- v2 必须给出 harness commit hash + 模型 snapshot date + API endpoint；
- v2 必须给出评测代码 + 数据集 + 评分脚本的 GitHub 链接；
- 强烈建议增加 1-2 个真实 SWE / WebArena 类任务 + 1-2 个 Closed-Loop / Memory-Augmented harness。
9.4 最终判断
- 学术价值：中-高。"efficiency 一级轴"是有方法学意义的立论，但执行是泛的（任务偏置、harness 偏置、cost 口径未明）。
- 生产价值：低。评测结果与真实部署的相关性未被验证。
- 复现可行性：低。数据集 / 评测脚本 / 模型 API 三件套均未确认 release。
结论：LongHarness 是立标价值高于执行价值的工作——论文的"efficiency 一级轴"提法应该被后续工作继承，但论文本身的评测数字不应被作为"事实"引用。建议保留精读入 notes/long-context/，但 reviews/ 应明确标注反方立场，避免后续研究不加约束地继承 12.4× / 68% 等数字。