LongHorizon-Harness：将长程 Agent 执行重新建模为外部任务状态管理问题

  • 关联论文：2608.01964
  • 作者：Tom
  • 更新：2026-08-04

一句话结论

LongHorizon-Harness 发现现有 Agent 评测框架把「任务执行、状态追踪、完成评估」全部塞进同一个 LLM context 是长程任务崩溃的根源，提出将任务状态显式外置到 LLM 外部，仅用 MEA（Manager-Execute-Auditor）循环中经过环境验证的事实更新状态，实现 Qwen3.7-Plus 在 WeaveBench 上从 51.8% → 80.7% 的跨越。

解决什么真问题

LLM Agent 正在承接越来越多需要数百步相互依赖操作的长程任务——比如在 OSWorld 中完成「下载压缩包、解压、配置环境、运行测试」这样的真实工作流，或在 Terminal-Bench 中完成「克隆代码库、解决依赖冲突、提交 PR」这类多步骤工程任务。

现有 harness 的根本缺陷：

当前主流 Agent 评测框架（如 OSWorld、Terminal-Bench 的原生 harness）把三件完全不同的事混在一个不断膨胀的 context 里： 1. Task Execution：Agent 生成 action 2. Task State Tracking：记录已完成哪些步骤、接下来该干什么 3. Completion Assessment：判断任务是否完成

问题在于：context 越长，LLM 对状态的记忆越模糊，且一旦生成了错误的 self-assessment（错误判断任务已完成），这个错误会像滚雪球一样传播——后续所有基于「任务已完成」这一错误前提的决策全部跑偏。原文称之为 error propagation through incorrect self-assessments。

核心方法

关键洞察：Task State Management Problem

LongHorizon-Harness 的核心洞察是把「长程执行」重新建模为「任务状态管理问题」，而非「上下文压缩问题」。解决方案是将任务状态外置到 LLM 外部，只有被环境独立验证过的事实才能更新状态。

MEA Loop（Manage-Execute-Audit）

┌─────────────────────────────────────────┐
│  Manager (LLM)                         │
│  - 读取外部 task-state                 │
│  - 根据当前状态决定下一个 subtask       │
│  - 输出 action plan                     │
└──────────────┬──────────────────────────┘
               │ action plan
               ▼
┌─────────────────────────────────────────┐
│  Executor (LLM, fresh context)         │
│  - 用空白 context 执行 action plan      │
│  - 读取当前环境状态                     │
│  - 输出执行结果                         │
└──────────────┬──────────────────────────┘
               │ execution result
               ▼
┌─────────────────────────────────────────┐
│  Auditor (LLM, read-only)               │
│  - 读取外部 task-state（不写入）        │
│  - 读取 Executor 返回的环境状态         │
│  - 验证：执行结果是否与 task-state 一致 │
│  - 输出 verified facts → 更新 task-state│
└──────────────┘

关键设计点：

  1. Manager 读外部 task-state：task-state 是结构化数据（JSON-like），存在 LLM 外部，不占用 context token
  2. Executor 始终用 Fresh Context：每次执行都用干净的 context，不受历史 conversation 污染，避免 error accumulation
  3. Auditor 是 Read-Only：只验证不决策，防止 Agent 自我确认错误判断
  4. task-state 更新必须基于环境验证的事实：Auditor 不能相信 Executor 说的话，必须对照环境实际状态

AgentAdapter：解耦模型与 Harness

AgentAdapter 是一个轻量模块（原文未明确具体代码行数），将 MEA 循环的实现与具体模型/harness 的原生 agent loop 解耦。只需实现 Adapter 接口，不需要修改被测 harness 本身，支持任意模型（Qwen、Claude 等）和任意 harness（OSWorld、Terminal-Bench 等）的自由组合。

关键实验与数据

基准 模型 基线 +LongHorizon-Harness 提升
WeaveBench Qwen3.7-Plus 51.8% 80.7% +28.9pp
Terminal-Bench 2.1 Qwen3.7-Plus 69.7% 77.2% +7.5pp
OSWorld 2.0 Qwen3.7-Plus 2.8% 8.3% +5.5pp
OSWorld 2.0（子集） Claude Opus 4.7 20.0% 34.3% +14.3pp

跨模型一致性：Qwen3.7-Plus 和 Claude Opus 4.7 均有显著提升，说明收益来自 harness 改进而非模型特化。

跨任务类型一致性：WeaveBench（+28.9pp）、Terminal-Bench（+7.5pp）、OSWorld（+5.5pp）分别是不同的交互域（Web、Terminal、OS），说明 MEA 循环的改进具有普适性。

亮点与局限

亮点： - 诊断精准：明确指出 Agent harness 的「三件事混在一起」是 error propagation 的根因，而非模型能力不足 - 框架级贡献：MEA loop 是通用框架，适用于任何长程 Agent 评测，不绑定特定 benchmark - 外部状态化设计：task-state 外置是非常工程友好的设计——可以被可视化、持久化、做 offline 分析 - 跨模型、跨 harness 一致有效：不仅测了一个模型，验证了框架泛化性

局限： - Auditor 依赖 LLM 本身：如果 Auditor 也判断失误，state 更新仍会出错；原文未说明 Auditor 是否有自我纠错机制 - Manager 和 Executor 调用两次 LLM：推理成本翻倍（2× LLM forward calls per step），延迟和费用是原有 harness 的约 2 倍 - WeaveBench 绝对准确率：80.7% 仍意味着近 1/5 任务失败，长程 OS 任务（OSWorld 8.3%）仍是极难任务 - AgentAdapter 实现细节缺失：原文未给出 Adapter 的具体 prompt template 或代码示例，工程复现有一定门槛 - 新论文（2026-08-03），暂无被引，未开源

对工程落地的启发

  1. 不要把所有状态塞进 context：即使是 Agent 应用开发，也可以把关键任务状态外置到结构化存储（Redis、SQLite），只用 LLM 读结构化指令而非生成所有历史
  2. 引入 Auditor/Verifier 角色：在生产环境 Agent 中增加一个「只读验证器」，在执行关键步骤前验证状态是否符合预期
  3. Fresh Context 执行：对于需要多次调用的子任务，每次调用给 LLM 提供「干净 context」（只含必要的环境信息），可以显著减少 error accumulation
  4. 任务状态的可视化与回滚：外部 task-state 可以被可视化、审计、支持回滚，这是纯 context 管理做不到的
  5. Harness 设计反思：如果你是 Agent 应用开发者，你的「框架」是否也在悄悄地把执行、状态、评估混在一起？

与同方向工作的关系

工作 核心贡献 与 LongHorizon-Harness 的关系
OSWorld（2024） 建立 OS Agent 评测基准 被本文用作评测对象，基线来自原生 harness
Terminal-Bench Terminal Agent 评测 同上，2.1 版本被本文使用
Agent Harness Survey（2026） 形式化定义 agent harness 语义 本文是该 survey 中「harness 设计缺陷」的实证验证
ReAct / Reflexion Agent 推理框架 关注 Agent 内部推理机制；本文关注 harness 如何影响评测可靠性
LongHorizon-Harness 外部状态 + MEA 循环 本文提出，与以上工作正交，可与 ReAct 等结合

本文的核心价值在于揭示了一个此前未被系统研究的观测：Agent 评测结果差，不一定是模型不够强，也可能是 harness 的设计让模型无法发挥已有能力。MEA 循环提供了一个修复这类 harness 缺陷的通用模板。

适合谁读

  • Agent 应用开发者：在做复杂多步骤 Agent 系统设计的工程师，MEA 循环的外部状态管理是可直接借鉴的设计模式
  • LLM Eval/评测方向研究者：关心 benchmark 可靠性的学者，LongHorizon-Harness 的核心发现（harness-side error propagation）是重要警示
  • Agent Infra 工程师：AgentAdapter 的设计思路（不修改原生 harness 就能增强）对于构建可插拔 Agent 基础设施有直接参考价值
  • Prompt Engineering 研究者：关注「如何让 Agent 不在长对话中跑偏」，Auditor 角色是值得引入的模式

注：本文为 2026-08-03 刚提交的新论文（v1），暂无开源代码、未提供具体 AgentAdapter prompt template。部分实验数据（如 WeaveBench 各子任务分解）原文未明确。

工程落地与核查（Jay）

事实核查

核查项 状态 说明
Qwen3.7-Plus 模型名称 ⚠️ 存疑 Qwen 系列正式命名中未见 "3.7-Plus" 格式，常见为 Qwen3-Plus / Qwen3.0-Plus；原文未给出校验链接，需读正文确认模型名称准确性
WeaveBench / Terminal-Bench 2.1 / OSWorld 2.0 基线数值 ✅ 来自 abstract abstract 明示，解读正文无窜改；具体子任务分解未披露
WeaveBench +28.9pp / Terminal-Bench +7.5pp / OSWorld +5.5pp ✅ 来自 abstract 与原文数字一致
Claude Opus 4.7 on OSWorld 子集 20.0% → 34.3% ✅ 来自 abstract abstract 明示 Claude Opus 4.7 子集测试
MEA Loop 结构（Manager / Executor / Auditor 三角色） ✅ 正确 与原文描述一致
Auditor read-only（只验证不决策） ✅ 正确 原文明确 "Auditor (LLM, read-only)"
2× LLM forward calls per step（推理成本翻倍） ✅ 推断合理 Manager + Executor 各一次 LLM 调用，合计 2×；原文未明确量化，但结构推断合理
跨模型、跨 harness 一致有效 ⚠️ 部分核实 Qwen + Claude 两模型、三个 harness 均有测试，结果方向一致；但样本量小（各一个），泛化性仍需更多验证
新论文（2026-08-03），暂无被引，未开源 ✅ 正确 v1 日期 + 无开源仓库，符合新论文状态

实际系统怎么用

轻量版 MEA 在生产环境怎么用：MEA 的核心价值不需要跑完整 benchmark 框架才能用到，生产系统的 Agent 也可以借鉴这个结构。最直接的落地方式是把「任务状态」从 prompt 里抽出来，放进 Redis 或 SQLite，每次 Agent 决策只读状态、每次 tool 执行后由独立的「验证步骤」更新状态。

一个最小可跑的工程骨架：

# task-state 存在 Redis，每次只给 LLM 读当前关键字段
task_state = redis.get(f"task:{session_id}")
manager_prompt = f"当前状态：{task_state}\n目标：{goal}\n下一步做什么？"
action_plan = llm.generate(manager_prompt)

# Executor 在 fresh context 里执行 action plan
executor_result = executor.execute(action_plan, env_state)

# Auditor 验证 executor_result 是否与 task_state 一致
auditor_verdict = auditor.verify(executor_result, env_state, task_state)
if auditor_verdict.accepted:
    redis.update(f"task:{session_id}", auditor_verdict.new_state)

这里的 auditor.verify 是关键：它必须读 env_state（环境实际状态，如文件系统的真实内容、API 的真实返回值），而不是信任 Executor 返回的 executor_result——这正是原文说的 "不能相信 Executor 说的话"。

Fresh context 执行的实际实现：Executor 的 fresh context 不等于「完全不提供上下文」。通常做法是：只注入当前操作相关的环境 snapshot（当前目录结构、最近一次命令的输出、关键配置文件内容），而不注入历史对话轮次。这比「塞全部历史」便宜得多，也能避免 error accumulation。

AgentAdapter 的最小实现：原文说 AgentAdapter 是「轻量模块」，但没有给具体接口定义。按功能反推，一个可工作的 Adapter 只需要实现两个方法：

class AgentAdapter:
    def extract_state(self, harness_state) -> dict:
        # 把 harness 内部状态翻译成外部 task-state 结构
        pass

    def apply_state_update(self, harness_state, verified_update) -> harness_state:
        # 把 Auditor 验证过的更新写回 harness
        pass

在实现 AgentAdapter 之前，先确认目标 harness（如 OSWorld/Terminal-Bench）的状态格式——如果它们的原生状态本身就是结构化的（如 JSON），Adapter 可能只需要做字段映射，不需要重写逻辑。

坑在哪

  1. Qwen3.7-Plus 模型名称存疑：原文使用的模型名称不符合已知的 Qwen 系列命名规范（Qwen3-Plus / Qwen3.0-Plus），可能是笔误或内部命名。这直接影响结果的可复现性——如果模型名称错了，在同一名称下搜不到对应权重，benchmark 复现就会卡住。在读正文确认之前，引用这个模型名时建议加注「（原文名称，待核实）」。

  2. 2× LLM 推理成本在生产中是实际问题：Manager + Executor 每步各一次 LLM 调用，对应着 double 的 latency 和 double 的 token 费用。在高频短任务场景（客服、查询类），这个开销可能让整体吞吐量腰斩。落地前需要评估 MEA 带来的 accuracy 提升 vs. 2× cost 的 trade-off——可能只在长程任务（>10 步）上才值得。

  3. Auditor 的 LLM 也可能出错：原文没有说 Auditor 有自我纠错机制。如果 Executor 和 Auditor 同时对某个环境状态判断失误（两者用同一版本的 world knowledge），错误仍然会被写入 task-state，只是传播速度慢了一些。生产系统如果对 state 准确性要求极高，建议给 Auditor 配一个「环境直接读取引用」（如读文件系统 API、查数据库）作为辅助验证，而不完全依赖 Auditor LLM 的判断。

  4. WeaveBench 数字存疑（关联上条）：WeaveBench 在原文中与「Agent Harness Survey（2026）」并列出现，但 Survey 是否真实存在、WeaveBench 是否是该 Survey 发布的 benchmark，需要核实。如果 WeaveBench 本身是本文提出的新基准，则「跨模型泛化」的结论是在同一批作者构造的基准上测的，外部效度打折。读正文后应确认 WeaveBench 的来源。

  5. AgentAdapter 实现细节缺失导致接入门槛高：这是该工作未开源前最大的工程障碍。没有 prompt template、没有接口定义，意味着其他 harness（除 OSWorld / Terminal-Bench 以外的）接入 AgentAdapter 时几乎要从零设计。建议先等开源再动手，或者只借鉴 MEA 框架的思想、用自己的 harness 格式实现一个简化版。

  6. task-state 外置后的持久化与并发：生产环境中一个 session 可能持续数小时，task-state 存在外部存储后需要处理进程崩溃恢复、多 Agent 并发写入同一 state 的问题。建议给 task-state 加乐观锁或版本号，不接受 stale update——这在工程上不是 trivial 的。