三分钟看懂LongHorizon Harness（下）：别让 Agent 只靠记忆，用可审计状态走完长任务
上篇讲了 LongHorizon-Harness 的核心动作：Manager 规划、Executor 执行、Auditor 独立验证，只有验证通过的状态才能进入下一轮。
但工程上最该追问的一句是：多加两个角色、反复审计，难道不会让 Agent 更慢、更贵吗？
答案是：会增加额外成本，而且论文没有回避；但在那些“局部做对并不等于整体完成”的长任务里，这笔成本可能换来更高的端到端完成率，以及在卡住后继续推进的能力。
这篇把论文最关键的实验、代价与几个真实案例放在一起看。
先看最硬的数字：同一个执行后端，任务通过率多了 28.9 个点
论文在三个覆盖不同交互环境的长程基准上测试：
- WeaveBench：114 个需要 GUI 与 CLI 协同的工作流；
- OSWorld 2.0：108 个桌面工作流任务，中位人工完成时长约 1.6 小时；
- Terminal-Bench 2.1：高难度、现实感更强的纯命令行任务。
最值得先看的，是 WeaveBench 的匹配对照：骨干模型都使用 Qwen 3.7-Plus，执行后端都保留 Claude Code。基线完整任务 PassRate 为 51.8%；套上 LongHorizon-Harness 后为 80.7%，绝对提升 28.9 个百分点。平均任务得分也从 0.702 升至 0.835。
这组结果的重要性不在于“换了更强模型”，而在于它尽可能隔离出了任务状态管理层的贡献。论文还显示，八个任务域都出现改善，说明收益并不只集中在某一种 GUI 操作或某一个工具上。
图 1 OSWorld 2.0 的性能—token 前沿。蓝色星号是 LongHorizon-Harness，虚线箭头指向同一 Qwen 3.7-Plus 的基线
在 OSWorld 2.0 全量任务上，论文报告 Qwen 3.7-Plus 的二元完成率从 2.8% 提升至 8.3%，部分得分从 21.5 提升至 35.2。二元完成率要求最终分数恰好为 1，因此从 2.8% 到 8.3% 不只是“做得多一点”，而是完整收尾的任务约为原来的 3 倍。
不过这里要保持严谨：该表将官方 Qwen 3.7-Plus 单动作设置与 LongHorizon-Harness 的 hybrid 设置并列，不能把它简单当成所有执行细节完全相同的纯隔离实验；更稳妥的结论是，论文报告该框架在这套评测协议下显著提高了最终完成与部分完成质量。
在 Claude Opus 4.7 的 OSWorld 2.0 34 任务子集上，二元完成率也由 20.6% 升至 35.3%，部分得分由 55.8 升至 66.9。这支持了论文的另一层判断：模型决定每一轮能做出的局部决策质量，Harness 决定这些局部能力能否被可靠地积累为端到端交付；两者是互补的。
纯 CLI 环境也并非例外。Terminal-Bench 2.1 中，Qwen 3.7-Plus + Claude Code 从 69.7% 提升到 77.2%。因此，收益不应归因于 GUI/CLI 路由本身，而更可能来自显式状态、局部上下文与独立核验这组组合。
审计到底在检查什么？一个“看起来完成”的文档就足够说明问题
论文的案例比柱状图更能说明这套机制的价值。
在一个 WebRTC 模拟层审计任务中，Claude Code 基线已经意识到 Wireshark 的“Decode As”对话框无响应，却连续尝试同一个交互超过 400 步，最终得分 0.59。问题不只是点不动，而是这个失败只存在于不断膨胀的执行上下文里，没有被正式登记成一个“仍缺什么证据”的任务状态。
LongHorizon-Harness 则把未解决的证据缺口写入状态，后续回合转而收集图表和数据包级别的证据，最终得分达到 0.92。
图 2 同一任务中，基线卡在不可响应的对话框；MEA 体系将失败外化为待核验状态，再由后续回合补齐证据
另一个文档格式任务更有代表性：基线直接修改 XML 后，页面视觉上看起来像是正确的标题样式，于是结束任务；但任务要求的是通过指定 LibreOffice GUI 流程完成，最终得到 0 分。LongHorizon-Harness 先通过界面逐项应用样式，再由审计者解析文档 XML，确认 15 个标题的底层样式都正确，最终得分 0.89。
它说明了一件很容易被忽略的事：“屏幕看着对”与“交付物满足验收标准”是两件不同的事。 审计者的价值，不是再写一遍执行总结，而是主动换一种与要求相匹配的证据通道去验证。
代价也是真实的：省下的是无效漂移，不保证省 token
把审计放进闭环不可能免费。论文将每任务 token 拆分给三种角色后发现：管理者本身占比很低，在 WeaveBench、OSWorld 2.0、Terminal-Bench 2.1 分别约为 2.8%、2.0%、8.1%；真正主要的新增投入是审计者，占比分别约 19.4%、24.8%、38.1%。
图 3 三类角色的 token 构成。Manager 很轻，Auditor 才是主要新增开销
总成本也没有一个固定答案：
- WeaveBench 上，LongHorizon-Harness 消耗约为基线的 2.3 倍 token；
- OSWorld 2.0 上，平均输出 token 从 28.9K 增至 104K，约 3.6 倍；
- Terminal-Bench 2.1 上反而比基线少 24% token，同时成功率更高。
这组结果很有启发性：MEA 不等于“加三个 Agent 必然更贵”。当基线会在错误路径上反复打转、丢失已经获得的进展，明确状态和独立核验可能减少无效重试；但当任务本来就很短，或错误主要来自模型本身的单步能力，审计成本未必划算。
论文按任务类型的分析也印证了这一点：需要长期维护、多次检查和修复相互依赖环境状态的任务，提升通常更明显；某些由视觉、数学、编码或算法设计单点能力主导的短分析任务，增益较小，甚至可能回退。Harness 能提高“走稳长路”的概率，却不能替模型补上一项从未学会的基本技能。
它给真正要做 Agent 系统的人什么启发？
LongHorizon-Harness 最值得借走的，不是把三个角色照抄成三个提示词，而是下面四条系统设计原则：
- 把任务状态当成一等公民。 不要让“当前完成了什么”只存在于聊天记录里；至少将需求、产物、事实、状态与证据显式建模。
- 执行报告不是验收报告。 工具调用成功、文件生成、页面看起来正常，都应与满足验收标准分开。
- 只让能审计的结果跨轮传播。 上下文压缩不只是删 token，更是筛掉未经验证的自我叙述。
- 让失败成为状态，而不是噪声。 “弹窗不可点”“缺少用户授权”“证据尚未收集”应进入状态机，触发重规划、询问或阻塞，而不是困在同一轮里无限重试。
当然，论文的结论仍需要放在边界内理解。它的主要结果来自特定基准、模型与执行配置；额外审计会带来成本；它也没有证明所有长期任务、所有模型都能取得同等收益。特别是涉及高风险真实系统时，“只读审计”本身的权限划分、证据质量和对环境变更的监控，都需要工程上真正落地，不能只靠角色名称保证。
但它提出了一个非常值得记住的视角：长程 Agent 的能力，不只是模型参数的属性，也是“模型 + 执行框架 + 可验证记忆”的系统属性。 当任务从一次问答变成连续几小时的真实工作，谁来维护状态、谁能改环境、谁来确认结果，可能和模型本身一样重要。
论文与项目：