论文链接：LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks 发表时间：2026年8月 机构：Ziyu Ma、Hailang Huang、Yong Wang、XiangXiang Chu 等 领域标签：Agent 系统架构 / Long-Horizon Tasks / Harness Engineering
一、论文背景：长程任务为什么这么难
要理解这篇论文，先把几个关键概念讲清楚。
什么是 Agent（智能体）？ 简单说，Agent 是一个能"自己想、自己做"的 AI 系统——它不只是回答问题，而是能连续地观察环境、调用工具、修改文件、然后根据结果决定下一步。你让它"帮我修这个 bug"或"把这份数据整理成报表"，它会像一个人坐在电脑前一样，一步步操作。
什么是 Harness（运行时框架）？ Harness 是 Agent 的"操作系统"——它负责把模型接到环境里：构建上下文（给模型看什么）、中介工具（让模型能执行命令、点鼠标、读文件）、验证动作、从失败中恢复。同一个模型配上不同的 Harness，表现可以天差地别。最近 OpenAI 的技术博客就揭示，GPT-5.6 Sol 登顶 ARC-AGI-3 SOTA 靠的不是模型能力飞跃，而是两项 Harness 设置调整。换句话说，Harness 工程正在变得和模型本身一样重要。
什么是长程（long-horizon）任务？ 长程任务是那些需要"几十上百步相互依赖的操作"才能完成的任务，比如"把这台机器配置成一个能跑深度学习的服务器"、“把这个游戏的画面 bug 找出来并修好”。METR 的报告指出，高级 Agent 的任务完成时间跨度大约每七个月翻倍，近期模型甚至加速到每四个月翻倍——Agent 正在被推向越来越长的任务。
长程任务为什么难？论文给出了三个系统性挑战：
- 复合错误和目标漂移：早期一个动作或决策错了，会沿着轨迹累积，逐渐让 Agent 偏离原始目标。
- 上下文腐化（Context Rot）：随着交互历史越来越长，相关信息越来越难被检索和使用；一旦上下文利用率超过某个临界点，Agent 性能会断崖式下跌。
- 任务状态丢失：长程任务需要准确、最新的"任务状态"——哪些需求已满足、哪些动作已完成、产出了什么、从环境发现了什么。Agent 经常无法在整个执行过程中维持这个状态。
现有 Harness 的两个结构性缺陷（这是论文的核心洞察）：
- 缺陷一：任务执行和任务状态管理共享同一个不断增长的上下文。 Agent 用同一个上下文既执行任务又维护任务状态，执行历史越长，任务状态越难追踪。
- 缺陷二：任务执行和完成评估耦合。 Agent 既执行子任务，又判断子任务是否完成；错误的自我评估会被记进任务状态，并成为后续决策的前提——错误就这样"自我授权"地传播下去。
这就是 LongHorizon-Harness 要解决的根本问题。
二、论文定位和关联工作
长程 Agent 的研究大致分几条路线：
路线一：扩大上下文窗口 / 更长记忆。 这条路线的思路是"上下文腐化了，那就装更多"。问题是上下文窗口再大也有上限，且长上下文里检索相关信息的难度随长度增长。
路线二：更强的模型（Scaling）。 这条路线赌"模型够强就不会犯错"。但论文的实验显示，即便 Claude Opus 4.7、GPT-5.5 这样的前沿模型，在 OSWorld 2.0 上也只有 18-20% 的 Binary 成功率——模型再强，也架不住错误在长轨迹里累积。
路线三：Harness / Scaffolding 工程。 代表性的有 Claude Code、Codex CLI、OpenClaw 等工业级 Harness。它们把模型接到真实环境，但仍然让执行和状态管理挤在同一个上下文里，没有从根本上解决两个结构性缺陷。
LongHorizon-Harness 的定位：它属于路线三，但做了一个范式级改变——把"任务状态管理"从执行上下文中剥离出来，并用一个独立的只读角色来验证完成情况。这相当于在 Agent 系统里引入了"权力分立"：执行权、状态控制权、验证权分属三个不同角色。
| 维度 | 现有 Harness | LongHorizon-Harness |
|---|---|---|
| 状态管理位置 | 与执行共享上下文 | 执行之外的显式状态 |
| 状态更新依据 | Agent 自我声明 | 环境独立验证的证据 |
| 完成评估 | Agent 自己判断 | 独立只读 Auditor |
| 执行上下文 | 不断累积 | 每轮新鲜（轨迹用后即弃） |
三、问题定义：长程执行本质上是"任务状态管理"问题
论文的核心抽象是：把长程执行从"一个不断增长的会话"重新表述为"一个任务状态管理问题"。
形式化地说：给定任务 $\mathcal{T}$，系统通过一系列动态确定的轮次来处理它。每轮开始时有任务状态 $S_i$（结构化记录集合）和当前环境状态 $e_{i-1}$。目标是经过若干轮，让任务状态的所有需求被标记为 completed，且这个标记必须基于环境事实而非 Agent 自我声明。
这个抽象的精妙之处在于：它把"长程"这个模糊的概念，转化成了"状态如何被准确维护和更新"这个可工程化的问题。一旦状态是可信的，长程执行就退化成了一系列短程的、有界的问题——每一轮只是一个新鲜的短任务。
四、问题解法：Manage-Execute-Audit（MEA）循环
MEA 循环有三个角色，权力严格分离：
4.1 Manager（管理者）——只管状态，不碰环境
Manager 的能力边界是这套架构的关键设计：
- 有权访问：原始任务、当前任务状态、所有累积审计报告。
- 无权访问：计算机环境的任何直接接口——不能看应用状态、不能检查工作区、不能点鼠标敲键盘、不能改环境。
它的工作是构建"子任务契约" $c_i$：即时目标、验收标准、边界约束，以及相关的状态记录和审计报告。决策有四种：execute（继续执行）、done（任务完成）、blocked（受阻）、ask（需要用户输入）。
任务状态是结构化记录，分三种类型：Requirement（需求）、Artifact（制品）、Fact（事实），每条标记为 completed/pending/blocked/untrusted。铁律是：执行器的声明不能直接改变持久状态；一条记录只有在有"清洁审计证据"支持时才能标记为 completed。
4.2 Executor（执行器）——新鲜上下文，用后即弃
每轮执行是一个新鲜的、有预算限制的片段：
- 输入：原始任务、当前状态、契约、契约引用的审计报告。
- 不接收：早期轮次的原始交互轨迹。
- 在片段内可以多轮规划、交互、修订。
- 片段结束时，原始轨迹和内部推理全部被丢弃，只转发执行报告 $o_i$ 给审计。
执行器分 GUI（鼠标键盘、应用界面）和 CLI（shell、文件、代码）两种，能力集严格分离——GUI 执行器碰不到工作区文件，CLI 执行器碰不到应用界面。通过统一的 AgentAdapter 接口，可以接入 Claude Code、Codex CLI、OpenClaw 等现有后端，保留它们原生的规划和工具使用循环——Harness 不替换后端内部过程，只控制上下文、工具、权限、预算和返回报告。
4.3 Auditor（审计员）——只读，独立验证
Auditor 是这套架构的"信任锚点"：
- 输入：原始任务、状态、契约、执行报告——但不接收执行器的原始轨迹或内部推理。
- 从排除执行器轨迹的新鲜上下文开始，通过独立比较环境与契约中的目标和验收标准来判断完成。
- 严格只读：可以改变观察视图，但不能修改任何任务相关环境状态；不能创建、编辑、覆盖、移动、删除受保护制品；不能执行状态变更命令。任何变异被记录为"完整性违规"，由此产生的报告不能支持
completed。
审计报告包含三个维度：完成状态（complete/incomplete/blocked）、完整性状态（clean/suspect/violation）、任务状态更新（验证的事实、证据、剩余差距）。注意权责分离：Auditor 可以"提议"对状态记录的更改，但由 Manager 决定如何纳入 $S_{i+1}$。
4.4 全景对比
| 维度 | 传统 Harness | MEA 循环 |
|---|---|---|
| 上下文增长 | 单调累积 | 每轮重置 |
| 状态更新 | 自我声明 | 环境验证 |
| 错误传播 | 沿轨迹累积 | 被审计切断 |
| 角色分离 | 无 | 执行/状态/验证三分 |
五、评估指标与实验证据
5.1 三个基准，三种交互域
| 基准 | 任务数 | 特点 | 指标 |
|---|---|---|---|
| WeaveBench | 114 | 需协调 GUI+CLI 的桌面工作流，8 领域 | PassRate（分数≥0.8）、Overall |
| OSWorld 2.0 | 108 | 桌面工作流，人类中位 1.6 小时 | Binary（满分才算成功）、Partial |
| Terminal-Bench 2.1 | 多任务 | 命令行任务，每任务 3 次，超时 5h | 成功率 |
5.2 核心结果（Qwen 3.7-Plus + Claude Code 后端）
| 基准 | 基线 | LongHorizon-Harness | 提升 |
|---|---|---|---|
| WeaveBench PassRate | 51.8% | 80.7% | +28.9pp（1.56×） |
| Terminal-Bench 2.1 | 69.7% | 77.2% | +7.5pp |
| OSWorld 2.0 Binary | 2.8% | 8.3% | +5.5pp（2.96×） |
| OSWorld 2.0 Partial | 21.5% | 35.2% | +13.7pp |
| OSWorld 2.0 Opus 4.7 子集 Binary | 20.0% | 34.3% | +14.3pp |
这个实验设计为什么有证明力？ 关键在于 WeaveBench 的官方参考结果——Claude Opus 4.7 + Claude Code 只有 41.2%，而 LongHorizon-Harness 用更弱的 Qwen 3.7-Plus 拿到了 80.7%，几乎是官方最强结果的两倍。这说明提升来自架构而非模型本身。
5.3 难任务收益更大（Terminal-Bench 2.1 按难度分解）
| 难度 | 基线 | LH-Harness | Δ |
|---|---|---|---|
| easy | 0.833 | 1.000 | +0.167 |
| medium | 0.776 | 0.818 | +0.042 |
| hard | 0.533 | 0.656 | +0.122 |
难任务收益是 medium 的近 3 倍——这正是"任务越长、中间失败点越多、显式状态管理越重要"的直接证据。如果是模型变强，easy/medium/hard 的提升应该相对均匀；只有架构性改变才能让 hard 任务 disproportionately 受益。
5.4 能力作为"系统属性"的反直觉发现
| 模型 | 配置 | WeaveBench Games 均分 | Token/任务 |
|---|---|---|---|
| Claude Opus 4.7 | Claude Code 基线 | 0.680 | 16.5M |
| Claude Opus 4.7 | LongHorizon-Harness | 0.809 | 11.1M |
| Qwen 3.7-Plus | Claude Code 基线 | 0.524 | 10.7M |
| Qwen 3.7-Plus | LongHorizon-Harness | 0.733 | 34.3M |
两个发现：(1) Qwen + LH-Harness（0.733）超过了 Opus + 基线（0.680）——架构可以弥补模型差距；(2) 对于更强的模型（Opus），LH-Harness 让 token 从 16.5M 降到 11.1M；对于更弱的模型（Qwen），token 从 10.7M 升到 34.3M。原因是强模型能用更少的审计-重规划轮次满足契约，弱模型要在重复执行和恢复上花更多推理。
六、效果优势的根源解释
baseline 的根本局限是什么？ 传统 Harness 的核心问题是**“信任假设”——它假设 Agent 的自我评估是可信的**。在短任务里这个假设勉强成立，但在长程任务里，错误自我评估会沿轨迹累积传播。这不是"它没做状态管理"，而是"它的状态管理与执行耦合在同一上下文里，导致状态被执行噪声污染"。
LongHorizon-Harness 的根本性改变：它在信息流和约束上做了三个本质改变：
新鲜上下文执行 → 切断上下文腐化。每轮执行从干净上下文开始，早期轮次的噪声不会进入当前决策。反事实：如果不丢弃轨迹（即用累积上下文），上下文越长性能越差——这正是 baseline 的退化模式。
只读独立审计 → 切断"自我授权"错误传播。Auditor 不接收执行器的轨迹和推理，只看环境真实状态，且不能修改环境。这从机制上杜绝了"Agent 声称完成 → 错误进入状态 → 后续基于错误决策"的循环。反事实：如果 Auditor 能写环境，它就可能"帮"Agent 伪造完成证据。
权责分离 → 状态更新只基于可验证的环境事实。Manager 无环境接口，所以它的状态更新只能来自 Auditor 的清洁证据，不能被"我刚刚执行得很好"的主观判断污染。
因果链：方法差异（MEA 分立 + 新鲜上下文 + 只读审计）→ 机制变化（上下文不腐化 + 错误不自我授权传播 + 状态只基于环境事实）→ 指标提升（难任务 +0.122、WeaveBench 近乎翻倍）。
Manager 开销很小（WeaveBench 2.8%、OSWorld 2.0%、Terminal-Bench 8.1%）——说明显式状态维护引入的计算开销很少，主要额外投资在 Auditor（19-38%），而这笔投资直接换来了"状态可信"。
七、必要知识反推
要做出这套工作，作者至少必须掌握：
领域知识层：
- 真实世界 Agent 部署的失败模式（上下文腐化、目标漂移、状态丢失）——这只能来自大量真实轨迹分析，不是理论推演。
- 工业级 Harness（Claude Code、Codex CLI、OpenClaw）的内部架构和局限。
方法论知识层：
- 权力分立思想——从政治学/软件工程（如只读副本、事务隔离）借鉴"执行/状态/验证"分立的原则。这是最关键的创造性节点。
- 部分可观测决策过程的形式化——任务状态、环境状态、观测的区分。
工程知识层：
- GUI 与 CLI 能力边界的严格分离实现。
- AgentAdapter 抽象——如何让任意后端保留原生循环的同时受 Harness 控制。
- 只读监控与完整性违规检测的工程实现。
知识融合的关键节点：把"政治学的权力分立"迁移到"Agent 系统架构"——意识到长程失败的本质是"信任自我评估"，而解法是让验证权独立于执行权。这个跨域类比是整篇论文的灵魂。
八、论文中可以提取的通用性灵感
灵感一：用权力分立根治"自我评估信任假设"
- 核心思想：任何需要"判断自己做得对不对"的系统，都会面临自我评估的信任问题；解法是让"验证权"独立于"执行权"且只读。
- 论文证据：只读 Auditor 把 WeaveBench 从 51.8% 拉到 80.7%；移除审计完整性检查会让错误传播。
- 推广场景：(1) 自动驾驶的安全监督模块（只读传感器，独立判断是否安全）；(2) 自动化交易系统的风控（独立于策略执行）；(3) RAG 系统的答案审计（独立验证检索证据是否支持答案）；(4) CI/CD 的独立测试阶段；(5) 自动化科研 Agent 的实验复现验证。
灵感二：新鲜上下文执行切断历史噪声
- 核心思想：长程任务不必用一个不断增长的上下文；可以把任务拆成一系列"有界短任务"，每轮用新鲜上下文，只保留结构化状态。
- 论文证据：每轮丢弃执行轨迹，只保留任务状态和审计报告；Terminal-Bench hard 任务收益最大。
- 推广场景：(1) 多步推理（每步重新载入关键事实而非全部历史）；(2) 长对话系统（用结构化记忆替代原始历史）；(3) 代码重构（每次只处理一个有界变更）。
灵感三：架构可以弥补模型差距
- 核心思想：更弱的模型配上更好的架构，可以超过更强的模型配上更差的架构；架构投资有杠杆效应。
- 论文证据：Qwen 3.7-Plus + LH-Harness（0.733）> Opus 4.7 + 基线（0.680）。
- 推广场景：(1) 中小团队用架构工程弥补模型代差；(2) 端侧 Agent 用受限模型+强架构达到云端效果；(3) 开源模型生态的竞争力来自配套架构而非参数量。
灵感四：强模型+好架构反而更省 token
- 核心思想：当架构减少了无效的重试和恢复，更强模型能用更少 token 完成任务——能力越强，架构的"省 token"效应越明显。
- 论文证据：Opus 4.7 的 token 从 16.5M 降到 11.1M。
- 推广场景：(1) Agent 服务的成本优化应同时投资模型和架构；(2) 评估 Agent 不能只看成功率，要看"成功率/token"的效率前沿。
本精读基于 LongHorizon-Harness 论文全文撰写，覆盖 Abstract、Introduction、Method（MEA 循环全部公式与设计）、Experiments（三个基准全部结果表与消融）、Analysis。