LongHorizon-Harness · 短审稿（2026-08-10 15:50 · flyP 精读棒）

• 生成者：flyP · long-horizon / agent 主线（轻量精读模式 · 1 篇 + 1 条 Substack 思想补充）
• 触发：cron 3d8f503a-7aeb-4a17-9550-c2514939fbfa · 研究知识库 · flyP 精读与批判 · 每天 3 次
• 目标条目：LongHorizon-Harness（arXiv:2608.01964）· long-horizon / agent harness 主分类
• 避撞：今日 09:43 multimodal-e1prep + 09:50 DataSpace 精读棒已落地，本次只做 1 篇 + 1 条 Substack
• 选篇理由：HF Trending 8-10 前 5（与 RST 218→223 立标信号锚同日高位）· 与 8-8 上午 HORIZON long-horizon 诊断棒（v2）形成同主线连续性 · 是当前"harness engineering > 模型升级"主张最完整的实证样本

1. 元信息

• 链接：https://arxiv.org/abs/2608.01964 · HF paper card https://huggingface.co/papers/2608.01964
• 机构 / 作者：DreamX Team · Alibaba Group · 8 位作者 · 等贡献 + 项目 lead 标注
• 提交：2026-08-03 v1 · cs.AI / cs.CL · HTML 全文可读
• 代码：https://github.com/AMAP-ML/LongHorizon-Harness · MIT License · 6 commits · 含 src/lh_harness / eval / assets / .github/workflows / pyproject.toml / README.zh-CN.md · 含 HF trajectory 数据集
• HF Daily 8-10 信号：Trending 头条候选（仅次于 JoyAI-Video-Edit / Kimi K3 / Unlimited OCR 等），立标信号中等偏强 · paper_cards 待建

2. 核心贡献（短摘）

1. 问题重构：把 long-horizon agent 执行重新表述为 task-state management 问题，而不是"更长轨迹的 prompt"。指出当前 harness 把三件事耦合在同一增长上下文里——task execution / task-state / completion self-assessment——这是"context rot + goal drift + 虚假自评传染"的根因。
2. MEA 循环（Manage-Execute-Audit）：三角色分工—— - Manager：单一可信源（SoT），无环境接口，仅依赖审计历史 Vᵢ 决定下一子任务契约 cᵢ（目标 / 验收标准 / 边界）。 - Executor：每轮 fresh-context，执行 cᵢ，丢弃上一轮交互历史。 - Auditor：read-only，独立从环境验证 Sᵢ₊₁，只允许 verified facts 进入 Sᵢ₊₁。 - 跨轮只保留 compact verified state + 审计日志。
3. AgentAdapter：轻量适配层，保留各原生 agent loop（react 等），不侵入内部。论文明确支持 Codex CLI / Claude Code / OpenClaw / Hermes Agent 等多 harness 后端。
4. 三基准一致提升： - WeaveBench（114 个 GUI+CLI 混合任务 · 8 个领域）：Qwen 3.7-Plus + Claude Code 51.8% → 80.7%（+28.9 ppt）；Design 域 +60.0 ppt，Spatial/3D +50.0 ppt；mean score 0.702 → 0.835。 - Terminal-Bench 2.1：69.7% → 77.2%（+7.5 ppt）。 - OSWorld 2.0：2.8% → 8.3%（+5.5 ppt，仍低基数）；Claude Opus 4.7 子集 20.0% → 34.3%（+14.3 ppt）。
5. 核心主张：long-horizon 任务上 harness engineering 的边际收益远大于模型升级——同一个 Qwen 3.7-Plus 仅靠 harness 改造就 +28.9 ppt，超过同期多数模型升级的提升幅度。

3. 主要方法风险与可质疑点

3.1 "verified state ≠ ground truth" 的隐性假设

• Auditor 只验证 "state transition 前后差异"，但 不验证子任务目标 cᵢ 本身的正确性。如果 Manager 在第 3 轮就生成了一条错误契约 c₃，后续 7 轮即使全 verify 通过也只能"忠实执行错误"。论文未披露 Manager 契约错误率的统计。待补查 supplementary。
• 风险：MEA 在 子任务粒度可观测 的任务（GUI / CLI / 文件系统）上效果显著，但对子任务目标不可观测 的任务（创意写作 / 谈判 / 多轮检索综合）会怎样？论文没在长上下文检索 / 综合类基准上验证。

3.2 "fresh-context executor" 的成本与延迟问题

• 每轮丢弃上下文 → 重新读取 verified state + 契约 → 重新调用 executor。token 消耗与 wall-clock 都显著上升，但论文没给出 cost / latency 折线。OSWorld 2.0 上 Qwen 3.7-Plus 仍只有 8.3%，意味着长任务被切成更多轮 → 成本放大倍数未披露。
• 对比 DataSpace 的"deterministic evaluator"思路，LongHorizon-Harness 走的是"重 inference 换可靠性"，两者在算力预算上是替代关系而非互补。待补查：cost-per-task 表。

3.3 AgentAdapter 的"非侵入"声称需要实证

• 论文声明 AgentAdapter 不修改 native agent loop，但实测中 harness 与 executor 的 prompt 注入、tool schema 注入、环境状态读写都可能隐式影响 react loop 内部行为。"Claude Opus 4.7 子集 +14.3 ppt" 暗示改造对闭源模型也有大幅收益——但闭源模型的 native loop 并不公开，无法独立验证"非侵入"。
• 对比 8-8 上午 HORIZON long-horizon 诊断棒的"上下文膨胀导致状态漂移"机制，MEA 是工程层 patch，不是底层修复。

3.4 WeaveBench 的"设计域" +60 ppt 是不是 benchmark 偏差？

• Design 域 +60.0 ppt · Spatial/3D +50.0 ppt——这类域的 native baseline 偏低（51.8% 中大部分失败可能就集中在 Design / 3D），MEA 把"环境状态被显式管理"的边际收益集中放大在了最难域。
• "全 8 域都提升"是真结论，但提升幅度本身高度依赖域分布。如果换一组分布不同的基准（如 WebArena / AppWorld），提升幅度会重排。待补查 ablation on domain split。

3.5 与 Kimi K3 同日登榜的"对立叙事"

• 8-10 HF Trending 第 3 条 Kimi K3: Open Frontier Intelligence（2.8T MoE · 104B 激活 · 1M context · 16/896 experts · million-token agentic RL）的核心叙事是"模型 + 训练系统升级"；而 LongHorizon-Harness 的核心叙事是"harness 升级 ≈ 模型升级"。两者同期登榜 = 业界对"agent 进步来自哪里"出现叙事分裂。
• Anan 知识库 v44 multimodal 主线已经把 Kimi K3 列入待观察；MEA 主张如果成立，会削弱"必须堆参数才能提升 agent"的论据，反过来强化"harness engineering 优先"的工程路径。这条对 v45 续立棒有立基础延展价值。

3.6 命名混淆风险（次要但必须标）

• AgentAdapter 列出的 openclaw 后端是 Alibaba DreamX 论文里命名的代码后端（与 react / codex CLI 同级），与 Anan 当前用的 OpenClaw 平台同名但不是同一回事。任何在 v45 引用 LongHorizon-Harness 时如果提到 "openclaw" 必须显式加注 "Alibaba DreamX 论文中的 harness 后端名"，否则会误导后续读者。

4. Substack 思想补充（唯一一条）

• 来源：Cameron R. Wolfe · https://cameronrwolfe.substack.com/p/agentic-rl · "Agentic Reinforcement Learning: 框架与最佳实践"
• 与 LongHorizon-Harness 的对位：
• Wolfe 主张 agentic RL 的核心是把"长视野信用分配 + 工具使用策略"端到端训练进模型，是模型侧的解。
• LongHorizon-Harness 主张 把状态管理与验证放到 harness 外，是工程侧的解。
• 两者互补不冲突——MEA 是推理期的脚手架，agentic RL 是训练期的脚手架；生产部署应该两层都上。
• 可信度：Cameron Wolfe 在 agentic RL 综述类内容一贯中规中矩，无强偏见，作为思想线索可信，但本条不作为独立审稿目标。
• 是否需要进一步核验：Wolfe 文章是否引用 LongHorizon-Harness？本次未读全文；待补查——如果 Wolfe 8 月文尚未覆盖 MEA，可作为未来 v45 主题页"harness engineering 综述"的一条引子。

5. 可信度判断

6. 复现难度评估

• 代码可得性：MIT · GitHub 仓库已公开 · 6 commits 不算多但 README + 中文 README 双版齐全 · HF trajectory 数据集可下载
• 数据 / 基准：WeaveBench（114 任务）· Terminal-Bench 2.1（开源）· OSWorld 2.0（开源）三套都可拉
• 算力门槛：必须能跑 Qwen 3.7-Plus / Claude Opus 4.7 至少其中一个的 API + 三个 benchmark 的完整环境（OSWorld 2.0 需要桌面 VM）
• 预计复现时间：单卡 + 三基准全跑 3-5 天（不含 VM 准备）；只跑 WeaveBench 一条 0.5-1 天
• 风险点：Auditor 的"独立验证"在不同 harness 下可能需要重新适配；Manager 的契约 prompt 未公开全文

7. 是否入库 + 后续验证动作

• 建议入库：是
• reviews/：作为 v45 续立棒候选延展条目（立基础延展档 · 与 8-8 HORIZON 立基础锚同主线）
• notes/：在 notes/long-horizon-agents.md（若不存在则新建）加一段 "MEA loop · task-state management" 摘要 + 与 agentic RL 的对位
• notes/agent-harness-engineering.md（建议新建）：把 LongHorizon-Harness + 8-8 HORIZON 诊断 + DataSpace evaluator 收成一条横切主题"harness engineering vs 模型升级"
• 后续验证动作（按优先级）： 1. 必做：补查 supplementary 中 Manager 契约错误率与 cost-per-task 表 2. 必做：核验 AgentAdapter 是否真的"非侵入"——读 src/lh_harness/ 源码 30 分钟 3. 可选：跑 WeaveBench 一条做 sanity check（0.5-1 天） 4. 可选：核 Cameron Wolfe 8 月 agentic RL 文是否引用 MEA
• 不需要入库：Substack Wolfe 那条只做思想补充，不单独成稿

8. 边界遵守

• 仅写 1 个文件：/shared/research-kb/inbox/flyp/2026-08-10-1550-LongHorizon-Harness-arxiv-2608-01964-critical-read.md
• 未触碰他人 inbox（jay / tom / spark / stephen ✓）
• 未写 review / published / digests ✓
• 未执行 git / gh ✓
• 未输出任何密钥 / Token ✓
• Substack 仅 1 条（Cameron Wolfe agentic RL），未做多轮扩展搜索 ✓