长程智能体agent harnessMEA 循环

LongHorizon-Harness：用管理-执行-审计循环推进长程智能体

AMAP-ML提出LongHorizon-Harness：MEA循环把长程任务变为独立审计的状态转移。同一模型下WeaveBench通过率51.8→80.7，OSWorld 2.0完成率3倍提升。

Ziyu Ma 等（AMAP-ML / DreamX）2026年8月23日5 分钟阅读

引言

长程任务最终都要被拆解成一连串子任务来解决，但正确的分解方式无法事先固定：下一个子任务取决于环境到目前为止实际发生了什么。然而，大多数现有的智能体运行框架（harness）仍然把整个长程任务放在一个持续增长的会话里——步骤级执行与长期协调相互争夺同一个上下文，而进度评估恰恰发生在产生这些进度的会话内部。

AMAP-ML（DreamX 团队）发布的 LongHorizon-Harness 采取了相反的立场：它把任务状态保存为执行之外的显式记录，只允许独立验证过的事实写入该记录，并基于记录推导下一个子任务。这就形成了一个管理–执行–审计（Manage–Execute–Audit，MEA）循环，由一系列独立审计的状态转移构成——并且在完全相同的底座模型与执行后端下，所有基准测试都取得了大幅提升：WeaveBench 通过率（PassRate）从 51.8% 跃升至 80.7%，OSWorld 2.0 二元完成率提升 3.0 倍（2.8% → 8.3%），Terminal-Bench 2.1 成功率从 69.7% 提升至 77.2%。

左右两个面板：左侧，单一增长的会话自我缠绕、自我评估进度并逐渐漂移；右侧，管理者基于审计事实重新规划下一个子任务，全新上下文的执行者执行它，只读审计者认证环境实际发生的变化。 — **被审计的状态转移。**不同于让一个持续增长的会话自我评判进度（左），*管理者（manager）*基于审计过的事实重新规划下一个子任务，全新上下文的*执行者（executor）*执行它，只读的*审计者（auditor）*认证环境中实际发生的变化（右）。审计报告是唯一的跨轮记忆。

单会话执行为什么会失败

作者指出了三种失败模式，它们都可以追溯到同一个架构选择——把执行、状态和自我评估耦合在一个不断增长的上下文里：

误差复利（Compounding errors）

早期的一个错误会扭曲此后做出的每一个选择，智能体逐渐偏离它最初的目标。

上下文腐化（Context rot）

随着历史不断增长，真正重要的信息越来越难以被检索出来；一旦上下文使用量越过某个阈值，性能会急剧下降。

任务状态丢失（Task-state loss）

没有一份准确的记录说明什么已完成、产出了什么、环境里实际有什么，因此进度无法被恢复和续接。

一旦未经验证的前提进入记录，之后的每一个决策都会继承它。现有的运行框架从未把进度评估与执行分开：子智能体汇报自己工作的摘要，而审查只是一个可选动作，不是强制关卡。未经验证的前提不断累积，导致反复尝试、目标漂移或过早终止。审计关卡从根源上消除了这一失败。

核心思想：目标固定，每一次分解都建立在审计过的事实之上

因此，LongHorizon-Harness 用三个彼此隔离角色的循环取代了单一增长的会话，让任务被动态分解，让每一个决策都建立在独立验证过的事实之上，而不是自我汇报之上。整个设计建立在四个支柱上：

P1 · 动态分解，目标固定。每一轮，管理者读取哪些事项已被验证为完成、哪些约束仍然有效、还缺什么，然后推导下一个子任务的目标、依赖、边界与验收标准。
P2 · 以审计为准的进度。只有只读审计者能更新记录。它在每轮之后检查真实环境，且永远看不到执行者的推理或自我评估——只有当一份审计报告引用了某个事实，它才算完成。
P3 · 轮内局部执行。全新上下文的执行者只完成当前这一个子任务，之后丢弃上下文。只有紧凑的审计报告跨轮传递，密集的步级观察永远不会进入长期协调层。
P4 · 重置而不失忆。执行错误要么被下一次审计暴露，要么根本不进入记录，因此它被限制在自己那一轮内。审计报告把仍然可信的部分与必须修复的部分区分开来。

方法：三个结构隔离的角色，一台被审计的状态机

LongHorizon-Harness 保留了现有系统原生的智能体循环。一个轻量的 AgentAdapter 让 Claude Code、Codex CLI、OpenClaw 和 Hermes Agent 都能成为三个角色的可互换后端，横跨 Claude Opus、GPT、Qwen 等模型——每个角色可以使用不同的模型，仅靠配置指定。每个角色有独立预算：执行者每轮 1800 秒，管理者与审计者各 300 秒，每个任务最多 25 轮 MEA。

LongHorizon-Harness 总览：管理者发出子任务契约，执行者在全新上下文中执行改变状态的动作，审计者向链条追加只读报告。 — **MEA 流水线。**管理者发出子任务契约，执行者在全新上下文中执行改变状态的动作，审计者向审计状态转移链追加只读报告。

管理者（Manager，M）

维护任务状态：每一条需求、产物与环境事实，分别标记为已完成、待处理、受阻或不可信，并附上该状态背后的审计证据。一条记录只有在审计报告支撑时才会变为已完成。每一轮，管理者读取该状态，决定是继续执行下一个子任务、结束任务、宣布任务受阻，还是向用户提问。

执行者（Executor，E）

唯一被允许改变环境的模块。它接收一个子任务以及该子任务所依赖的证据，每次都从全新上下文启动；其原始轨迹与推理随后被丢弃。它走 GUI 还是命令行，取决于要做的改变本身，而不是它恰好持有什么工具。

审计者（Auditor，A）

从一个永远看不到执行者轨迹与推理的上下文出发，独立检查结果。它可以循着执行者的报告去找产出物，但完成与否由它自己对照验收标准检查环境来决定，并记录它验证了什么、什么仍未解决，以及每个结论的证据。

只读完整性（Read-only integrity）

审计被限制为只读交互，因此验证过程无法改变被检查的结果。审计进行期间，框架会监控任务相关产物与工作区内容；如果审计者修改了受保护的状态，其报告会被标记为完整性违规，不再能支撑任何"已完成"记录。

MEA 循环的一轮

每一轮依次施加三个算子：状态转移（管理）、改变状态的动作（执行）和状态捕获（审计）。第 i 轮审计者的报告进入第 i+1 轮管理者的决策，进而决定该轮执行者的上下文。具体而言，一轮包含六个步骤：

管理者读取记录。它接收原始任务、当前任务状态以及到目前为止收集的所有审计报告。
应用已验证的发现。被确认的变化会新增或更新需求、产物与事实记录；未解决的事项保持待处理、受阻或不可信。没有审计证据，任何事项都不能标记为完成。
发出一份契约。管理者从当前状态可达的未解决目标中挑选一个，并为其划定边界：目标、验收标准、边界约束，以及与执行和检查相关的先前审计证据。
执行者行动，然后遗忘。它以只包含本轮输入的全新上下文启动，改变环境，并汇报自己做了什么。随后其原始轨迹被丢弃。
审计者捕获状态。它通过只读工具、对照契约标准检查环境。执行者的报告可以提示去哪里看，但不能作为完成的依据。
继续，或停止。当审计过的状态满足任务时管理者返回 done；当没有任何可行的推进时返回 blocked；需要用户输入时返回 ask；否则带着下一份契约返回 execute——最多 25 轮。

基准测试：长程难度的三个维度

该框架在 WeaveBench、OSWorld 2.0 和 Terminal-Bench 2.1 上评测，分别覆盖跨界面协调、真实专业复杂度下的长程状态管理，以及纯 CLI 能力。实验以 Qwen 3.7-Plus 为主要底座模型，并用 Claude Opus 4.7 做底座泛化性研究。

	WeaveBench	OSWorld 2.0	Terminal-Bench 2.1
规模	8 个领域共 114 个任务	108 个任务，人类完成中位时长 1.6 小时	高难度 CLI 任务，每个跑 3 次
界面	同一条轨迹中同时使用 GUI 和 CLI	桌面 GUI，1920×1080	纯 CLI——无视觉感知
评分	感知轨迹的 agentic 评审；PassRate 统计得分 ≥ 0.8 的任务	原生 `env.evaluate()`；二元分与部分分	按任务通过/失败，对多次运行取平均
环境	容器化虚拟机，冻结快照，受限网络	官方 `osworld-v2-2026.06.24` Docker 虚拟机	Docker 后端的 Harbor
考察点	一个界面中收集的证据能否存活到另一个界面	任务状态能否在长达一小时的专业工作流中存活	剥离 GUI 路由后，仅考察状态管理层

结果：跨基准、跨底座的一致提升

在相同底座模型和相同执行后端下，LongHorizon-Harness 把 WeaveBench PassRate 从 51.8% 提升到 80.7%，OSWorld 2.0 二元完成率提升 3.0 倍，Terminal-Bench 2.1 成功率从 69.7% 提升到 77.2%。这些增益从 Qwen 3.7-Plus 延续到了 Claude Opus 4.7。

表 1 · WeaveBench 结果（114 个任务）。PR 表示通过率（%），Overall 为任务平均得分；DSK/DOC/GAM/WEB/DAV/OPS/SPA/DES 是八个领域。

智能体	Harness	PR ↑	Overall ↑	DSK	DOC	GAM	WEB	DAV	OPS	SPA	DES
Claude Opus 4.7	Claude Code	41.2	0.532	55.6	47.1	23.5	53.3	23.1	50.0	33.3	40.0
Claude Opus 4.7	OpenClaw	35.1	0.482	55.6	29.4	23.5	66.7	15.4	41.7	16.7	20.0
Claude Opus 4.7	Hermes Agent	28.1	0.516	33.3	47.1	11.8	26.7	30.8	50.0	8.3	10.0
Claude Opus 4.7	Codex CLI	13.2	0.378	16.7	11.8	11.8	6.7	7.7	25.0	16.7	10.0
GPT-5.5	Codex CLI	35.1	0.499	38.9	29.4	23.5	53.3	15.4	50.0	58.3	10.0
GPT-5.5	OpenClaw	33.3	0.466	38.9	35.3	35.3	21.4	23.1	38.5	33.3	40.0
GPT-5.5	Hermes Agent	31.6	0.466	55.6	29.4	35.3	40.0	7.7	25.0	25.0	20.0
GPT-5.5	Claude Code	14.9	0.299	33.3	11.8	11.8	0.0	15.4	16.7	25.0	0.0
GPT-5.4	OpenClaw	22.8	0.465	55.6	35.3	5.9	0.0	23.1	23.1	8.3	20.0
GPT-5.3-codex	OpenClaw	18.4	0.456	33.3	23.5	29.4	0.0	7.7	16.7	8.3	20.0
GPT-5.2-codex	OpenClaw	6.1	0.321	5.6	11.8	0.0	0.0	15.4	16.7	0.0	0.0
GPT-5.1-codex	OpenClaw	1.8	0.226	0.0	5.9	0.0	0.0	7.7	0.0	0.0	0.0
Gemini 3.1 pro	OpenClaw	1.8	0.223	0.0	0.0	0.0	0.0	0.0	8.3	8.3	0.0
Qwen3.5-397B-A17B	OpenClaw	0.9	0.318	0.0	0.0	0.0	0.0	0.0	8.3	0.0	0.0
Qwen3-VL-8B-Think	OpenClaw	0.9	0.092	0.0	0.0	0.0	0.0	8.3	0.0	0.0	0.0
GUI-Owl-1.5-32B	OpenClaw	0.0	0.065	0.0	0.0	0.0	0.0	0.0	0.0	0.0	0.0
Qwen 3.7-Plus	Claude Code（基线）	51.8	0.702	83.3	76.5	29.4	46.7	53.8	66.7	16.7	20.0
Qwen 3.7-Plus	LongHorizon-Harness（本文）	80.7	0.835	88.9	100.0	58.8	73.3	84.6	91.7	66.7	80.0
相对同底座裸 Claude Code 的变化		+28.9	+0.133	+5.6	+23.5	+29.4	+26.6	+30.8	+25.0	+50.0	+60.0

前 16 行是 WeaveBench 官方报告的结果（每个底座取最佳思考模式）。所有八个领域都有提升，DOC 达到 100.0。需要注意的是，作者的运行在任务虚拟机内以 root 权限执行智能体，而官方基线在普通用户账户下运行，因此灰色行是参考点而非严格对齐的对比。

Terminal-Bench 2.1 排行榜：LongHorizon-Harness 搭配 Codex 和 GPT-5.6 Luna 达到 83.1%，搭配 Claude Code 和 Qwen 3.7-Plus 达到 77.2%，基线为 69.7%。 — **Terminal-Bench 2.1 官方排行榜。**LongHorizon-Harness 保留 Claude Code 作为执行后端，成功率从 69.7% 提升至 77.2%；搭配 Codex 与 GPT-5.6 Luna 时达到 83.1%。标 * 的数值为外部报告的指标。

表 2 · OSWorld 2.0（108 个桌面工作流）。Binary 为最终基准得分等于 1 的任务占比；Partial 为全部 108 个任务的平均基准得分。

智能体	Harness / 模式	Binary ↑	Partial ↑
Claude Opus 4.8	批量动作（Batched actions）	20.6	54.8
Claude Opus 4.7	批量动作（Batched actions）	18.2	48.9
GPT-5.5	批量动作（Batched actions）	13.0	49.5
Claude Opus 4.8	单步动作（Single action）	18.5	49.3
Claude Opus 4.7	单步动作（Single action）	13.9	49.1
Claude Sonnet 4.6	单步动作（Single action）	8.3	41.5
MiniMax M3	单步动作（Single action）	4.6	22.3
Kimi 2.6	单步动作（Single action）	4.6	22.1
Qwen 3.7-Plus	单步动作（基线）	2.8	21.5
Qwen 3.7-Plus	LongHorizon-Harness	8.3	35.2

表 3 · OSWorld 2.0，Opus 4.7 子集（34 个任务）。

智能体	Harness / 模式	Binary ↑	Partial ↑
Claude Opus 4.7	单步动作（Single action）	20.6	55.8
Claude Opus 4.7	LongHorizon-Harness	35.3	66.9

仅仅替换运行框架，就把二元完成率提升了 +14.7 个百分点、部分分提升 +11.1——增益是框架的属性，而不是某一个底座模型的属性。底座模型仍然决定每一轮动作的质量，而运行框架决定经过验证的成果能多可靠地在轮与轮之间存活。正因如此，二者是相互复合，而不是相互替代。

OSWorld 2.0 二元完成率与部分分相对每任务输出 token 数的两个散点面板。蓝色星号标记 LongHorizon-Harness 搭配 Qwen 3.7-Plus，虚线箭头从单步动作基线指向它。 — **OSWorld 2.0 上的成本–性能前沿。**二元完成率（左）与部分分（右）相对每任务平均输出 token 数。彩色曲线是不同推理强度（reasoning effort）设置下的官方结果，标记大小表示推理强度。蓝色星号表示 LongHorizon-Harness 搭配 Qwen 3.7-Plus，虚线箭头显示它相对官方单步动作基线的提升。

成本与归因：协调很便宜

管理者仅占总 token 的 2.8%（WeaveBench）、2.0%（OSWorld 2.0）和 8.1%（Terminal-Bench 2.1）。审计是更大的投入，分别为 19.4%、24.8% 和 38.1%。而且总成本并非一律更高：在 Terminal-Bench 2.1 上，该框架比基线少消耗 24% 的 token，同时提升了 7.5 个百分点。

WeaveBench、OSWorld 2.0 和 Terminal-Bench 2.1 上每任务 token 数的堆叠条形图，按管理者、执行者、审计者占比与基线智能体对比。 — **token 花在了哪里。**LongHorizon-Harness 中管理者、执行者、审计者平均每任务消耗的 token 与对应基线的对比。分段标签给出每个角色的消耗占比。LH-Harness 三个角色均使用 Qwen 3.7-Plus。WeaveBench 与 Terminal-Bench 2.1 报告总 token 数；OSWorld 2.0 报告输出 token，因为官方结果只提供输出 token 统计。

两个发现让归因更加清晰：

开销并非固有属性（−33%）。在 17 个 Games 任务上，同一个框架随底座不同而符号反转：Opus 4.7 得分更高的同时少花 33% 的 token（16.5M → 11.1M），而 Qwen 3.7-Plus 多花 3.2 倍（10.7M → 34.3M）。更强的底座能用更少的"审计–重规划"轮次满足一份契约。
能力是系统属性（0.733 对 0.680）。在同一批任务上，框架加持下的 Qwen 3.7-Plus 达到 0.733，高于裸 Claude Code 上 Opus 4.7 的 0.680。运行框架无法增加原始能力，但它决定这些能力有多少能存活到任务终点。

三个哑铃图面板，在 WeaveBench 领域、OSWorld 2.0 能力标签和 Terminal-Bench 2.1 类别上对比基线与 LongHorizon-Harness，每个面板右侧列出分值变化。 — **增益来自哪里。**LongHorizon-Harness（蓝）与同模型基线（灰）在 WeaveBench 领域（左）、OSWorld 2.0 能力标签（中）、Terminal-Bench 2.1 类别（右）上的对比。每个面板最右一列报告绝对分值变化（百分点）。蓝色连接线表示提升，红色连接线表示退步。括号内数值报告各类别中的 OSWorld 任务数或 Terminal-Bench 轨迹数。

洞察：配对轨迹中的四个反复出现的模式

作者对比了配对轨迹：Claude Code 基线与 LongHorizon-Harness 使用同一个 Qwen 3.7-Plus 模型执行同一个任务。这些案例考察的是在 MEA 循环下，什么东西能在轮与轮之间存活。

案例 1 · 从卡死的交互中恢复（0.59 → 0.92）

WEB_task_16 · WebRTC simulcast 层审计。基线确实注意到了失败的 GUI 交互，但这个观察被埋没在不断增长的执行历史里，于是它对同一个交互重试了 400 多步。框架把卡死本身和未解决的证据缺口写入任务状态，因此恢复从最新的审计状态重新开始，而不是从失败的轨迹重新开始。具体来说，Wireshark 的 "Decode As" 对话框停止响应；基线退化为 400 多步的重复点击，而审计者把同样的困难改写成具体的证据缺口，下一轮只针对未满足的条目。

WEB_task_16 故事板：基线在失去响应的 Wireshark 对话框上循环，而 LongHorizon-Harness 把失败改写为证据缺口。 — 案例 1：基线在失去响应的 Wireshark 对话框上循环；框架把卡死转化为证据缺口并围绕它们重新规划。

案例 2 · 审计"看似完成"（0.00 → 0.89）

DOC_task_2 · 标题样式规范化。执行者停在了一个视觉上合理但不符合规范的结果上：基线直接编辑文档 XML，而任务要求走 LibreOffice 工作流，因此得 0.00 分。审计者则重新解析 XML，把一个貌似合理但不合规的声明挡在任务状态之外。基线通过直接编辑 ODT XML 推进了文档的外观，并把"看起来对"当成完成；重新解析 XML 把"完成"变成了一个可独立核查的声明。

DOC_task_2 故事板：基线直接编辑 ODT XML 并把'看起来对'当成完成，而审计者重新解析 XML。 — 案例 2：直接编辑 ODT XML 能通过目视检查，却过不了评审；审计者的重新解析抓住了这条不合规的捷径。

案例 3 · 保存修复前的证据（0.45 → 0.87）

DOC_task_4 · Calc VLOOKUP 修复。所需证据的一部分属于修复之前的状态。基线在这个序列完成之前就修改了电子表格，留下了前后不一致的记录。把该缺口记为待处理需求，改变了工作的先后顺序：必须先记录原始状态，修复才能动手。基线确实修好了表格，但其直接改 XML 的修复破坏了原始错误现场，导致它的"修复前"截图显示的是修复后的状态；框架则先锁定修复前的证据窗口，再审计全部九张截图的一致性。

DOC_task_4 故事板：基线的修复抹掉了修复前的取证上下文；框架先锁定证据窗口。 — 案例 3：框架在任何修复动手之前先锁定修复前的证据窗口。

案例 4 · 从已验证的进度继续（0.53 → 0.85）

WEB_task_10 · Lighthouse 性能演练。两套系统都能完成核心优化，差别在于能否保住其余部分。基线确实改进了页面，但同一个会话还要驱动 DevTools、追踪交付物并评判自己的进度，最终预算耗尽。把已完成的工作放在执行历史之外，让全新的执行者把上下文花在剩余事项上，而管理者则在整个工作流中维持连续性。

WEB_task_10 故事板：基线完成了核心优化但在 DevTools 上耗尽预算；框架把工作分阶段分配给不同角色。 — 案例 4：基线完成了核心优化却在 DevTools 上耗尽预算；框架把工作分阶段分配给不同角色。

结论

长程能力是整个"模型–框架"系统的属性，而不只是模型的属性。底座模型决定智能体在单轮之内能做什么；运行框架决定这些能力有多少能存活到任务终点。正因如此，同一个循环能把较弱的底座抬到裸跑的更强底座之上；而当任务的关键恰好落在模型不具备的能力上时，它也帮不上忙。

亲自上手

该框架以 Python 包形式发布（Python 3.10+），需要 PATH 上有至少一个智能体运行时：claude、codex 或 openclaw。

uv tool install lh-harness   # 或 pip install lh-harness

lh-harness run --task "Summarise the files in this directory." \
  --agent claude_code --model qwen3.7-plus --max-rounds 2

加 --dashboard 可以实时观看 MEA 循环，用 --task @task.md 可以从文件读取任务。每次运行都隔离在 runs/<run-id>/ 下，并附带完整审计记录。

引用

@article{longhorizonharness2026,
  title={LongHorizon-Harness: Advancing Long-Horizon Agents for Real-World Tasks},
  author={Ziyu Ma and Hailang Huang and Shun Zou and Yong Wang and Shidong Yang and Yiming Hu and Fei Wei and XiangXiang Chu},
  journal={arXiv preprint arXiv:2608.01964},
  year   = {2026},
  url    = {https://arxiv.org/abs/2608.01964}
}

来源：本文编译自 LongHorizon-Harness 项目主页 https://lh-harness.pages.dev/（AMAP-ML / DreamX 团队）。论文：arXiv:2608.01964 · 代码：github.com/AMAP-ML/LongHorizon-Harness

长程智能体 agent harness MEA 循环 WeaveBench OSWorld 2.0 Terminal-Bench AMAP-ML 状态审计

原文来源:AMAP-ML 项目主页https://lh-harness.pages.dev/