HALO：用 RLM 构建自改进 Agent

AI Agent 由两个关键元素组成：模型和 harness。模型决定做什么；harness 执行。把模型放进 harness 并启动循环，就得到了 AI Agent。

数十亿美元花在改进模型上。直到最近，harness 没有获得同样多的关注。

Mismanaged Genius Hypothesis 假设 LLM 确实拥有超人类智能，但人类可能不擅长管理把这些模型变成 Agent 的 harness。也许存在一条路径，让模型自己决定 harness 应该采取的形状。

为探索这个想法，团队构建了 HALO（Hierarchical Agent Loop Optimizer）。

核心结果

HALO 在多个 benchmark 上持续改进 Agent 表现：

作为参考，Claude Code on Opus 4.6 在 Terminal-Bench 上得分 58%。HALO 把 gemini-3-flash-preview 从 46% 提升到 57.14%——接近 Claude Code 水平，仅通过 harness 优化。

HALO 是什么

HALO 是一个 Agent（模型 + harness），通过分解执行轨迹来优化其他 Agent（同样是模型 + harness），理解 harness 表现如何以及如何改进。

它由具有特定工具的 RLM（Reasoning Language Model）驱动，允许它一次对数十万 Agent 执行进行深度分析，识别跨执行的常见问题，并建议能改善 Agent 整体表现的 harness 变更。

HALO 循环

核心循环出奇简单：

1. 收集 Agent 的执行轨迹
2. 把轨迹喂给 HALO
3. HALO 分析轨迹识别 recurring failure modes
4. HALO 产生描述 likely harness-level fixes 的报告
5. 由 coding agent 把这些 fixes 应用到 Agent harness
6. 重新运行 Agent，收集新轨迹，循环重复

这与手动检查几个失败不同。许多 harness 问题在单个轨迹中不明显。每次失败可能看起来 locally reasonable——只有当 Agent 行为跨大量执行分析时，模式才浮现。HALO 旨在 surface 这些 aggregate patterns 并把它们翻译成 concrete harness changes。

各 Benchmark 分析

Terminal-Bench：减少低价值探索

Terminal-Bench 是 messy 但 useful 的 benchmark。Agent 被丢进带文件系统的真实 shell，必须完成按最终 end state 评分的任务。成功取决于 harness 管理探索、shell 命令、文件检查和任务执行的能力。

HALO 识别出轨迹中的 recurring pattern：Agent 的第一个命令通常太 generic。接收任务后，它经常以 broad orientation 命令开始，如目录列表或广泛文件搜索。虽然在任何单个轨迹中看起来相当 benign，但 HALO 发现这个模式通过消耗 Agent 有限的 turn budget 在不会 yield 有价值信息的命令上，降低了完成率。

修复是让 Agent 在轨迹早期更 task-directed。HALO 推荐了 prompt 和配置变更，鼓励 Agent 在默认进行 broad filesystem 探索之前形成关于任务的 concrete hypothesis。变更后，Agent 花更少时间 generic orienting，更多时间采取 task-relevant actions。

这是 harness-shaped failure 的好例子。 模型有足够能力解决许多任务，但 harness 允许太多低价值探索。

Finance-Agent：答案构造而非搜索

在 Vals AI Finance-Agent benchmark 上，最大改进来自 claude-opus-4-7。基线 56%，HALO 后 72%。再次，仅通过 harness 改进实现。

Agent 经常收集相关信息但未能产生完整的最终答案。令人惊讶的是，主要失败是答案构造而非搜索相关。

HALO 识别出基线 harness 经常能到达正确答案，但未能以 required format 提交。HALO 推荐了更 explicit 的 coverage rubric，推动 Agent 检查最终答案是否涵盖了问题的 required dimensions。对 claude-opus-4-7，这个简单变更比基线提升 18%。

同一格式变更并非对每个模型都同样有效。GPT-5.5 从更强的 72% 基线开始，同样改进只产生 small additional lift。Kimi-K2.6 向相反方向移动：帮助 Opus 的 heavier coverage rubric 降低了性能。在下一轮中，HALO 识别出这一点并推荐了 lighter、更 concrete facts-oriented instruction，把 Kimi-K2.6 从 56% 提升到 64%。

这是 trace-driven harness optimization 的另一个有用属性——最佳 harness 不是通用的。 不同模型有不同 failure modes，同一 prompt 变更可能帮助一个模型而伤害另一个。HALO 有用正是因为它搜索适合特定模型和执行环境的 harness shape。

AppWorld：改进 stateful 工具使用

AppWorld 测试 Agent 能否跨类应用环境操作，使用 stateful API、工具调用和多步骤用户目标。这些任务接近生产中出现的 long-horizon 执行问题。

第一个主要 failure mode 是工具可用性。在几个轨迹中，模型似乎理解需要做什么，但 harness 没有暴露正确的 fallback 工具。例如，当 Venmo 交易因账户余额不足失败时，Agent 尝试通过 payment-card path 恢复。相关 API 存在，但 API predictor 把它排除在外，Agent 无法使用。表面看像模型幻觉，但 trace-level diagnosis 显示 Agent 的工具 surface 对 realistic recovery behavior 太窄。

HALO 通过修改 harness 改进了 API prediction layer，更好地暴露 reasonable Agent 可能需要的工具。Predictor 被推向更高 recall，特别是 login、search、show、list、get、supervisor、temporal、people-search 和 fallback API。Sonnet 运行中，最大预测 API budget 也增加，使 real recovery API 在到达 Agent 前被切断的可能性降低。

AppWorld 结果是 harness optimization 跨层移动的有用例子。 首先，HALO 让正确工具可用。然后减少 wasteful 或 unrecoverable 工具行为。然后改进 final-answer 和 bulk-action verification。收益来自让循环更可靠，而非改变底层模型。

SWE-Bench：轻量验证胜过过度约束调试

SWE-Bench 给 Agent harness 的不同部分施压。Agent 必须检查仓库、理解 issue、做代码变更、产生通过测试的 patch。

最可靠的改进来自简单 prompt 变更。HALO 推荐 Agent 在编辑后运行相关 failing tests、运行 fast lint 或 syntax check、重新阅读 issue、确认 root cause 已解决、在做 risky edits 前检查附近 callers。这推动 Agent 关闭 patch generation 和 verification 之间的循环。

HALO 还在剩余失败中 surface 了一个 recurring debugging pattern：Agent 有时以 shallow repository orientation 开始，然后才 grounding 在实际失败中。Broad listings、generic searches 或 filesystem probes 在单个轨迹中可能看起来 reasonable，但跨许多轨迹时，它们延迟了 Agent reproduce bug 或检查 failing assertion 的时刻。这与 Terminal Bench 看到的失败非常相似。

SWE-Bench 结果展示了与 AppWorld 不同的教训。AppWorld 中，harness 需要更好的工具 recall 和执行纪律。SWE-Bench 中，harness 需要更好的 verification pressure，但不是 so much pressure 以至于 over-managed Agent。

tau3-Bench：HALO 不解决所有问题

tau3-Bench 是 Sierra Research 的 benchmark，375 个任务横跨 airline、retail、telecom 和 banking_knowledge 领域。基线 64.27%，HALO 后 67.47%。

这是真实改进，但比其他 benchmark 的收益小。四个领域中有三个的 pass rate HALO 能 nudge upward。第四个领域 banking_knowledge 是 hard bottleneck。Agent 反复失败在需要回忆和应用特定银行政策细节的政策问题上。这些情况下，问题主要不是 harness。模型自信地 paraphrase 政策而非检索或应用相关事实。

HALO 直接 surface 了这个 distinction。它发现 banking_knowledge 无论 Agent 如何 prompted 都卡在约 10% 准确率。团队尝试了多个 harness 变更，包括更深的 policy-lookup discipline、search cap、single-snippet compression。虽然每个都 slightly helped，但没有一个突破瓶颈。

这是重要的 negative result。 HALO 能找到 harness 中的 slack，但不能从模型本身 reinvent missing knowledge。

这个 distinction 对生产 Agent 很重要，因为不是每个失败都是 prompt 问题，也不是每个失败都是模型问题。HALO 的实用用途之一是分离两者。它既是判断是否需要更大模型能力的有用工具，也是发现 harness 是否 mismanaging 模型的工具。

核心洞察

跨 Terminal-Bench、Finance-Agent、AppWorld、SWE-Bench 和 tau3-Bench，同一模式反复出现：Agent 表现经常受 harness-level failure modes 限制，这些模式从单个轨迹中难以看到。

具体 failure modes 因 benchmark 而异：

• Terminal-Bench：Agent 花太多早期 budget 在 generic 探索上
• Finance-Agent：Agent 经常收集正确信息但未能产生完整答案
• AppWorld：Agent 经常需要更好的工具 recall、fallback behavior、completion discipline 和 long enumeration 的 careful verification
• SWE-Bench：Agent 从 lightweight verification 受益，但 heavier 或更 prescriptive 的调试指令可能 over-constrain 循环
• tau3-Bench：HALO 找到 harness-level 改进，也找到瓶颈似乎是模型能力而非 harness design 的领域

共同点是这些不是通过阅读一两个轨迹就能完全理解的失败，而是aggregate behavioral patterns。一旦 surfaced，许多可以通过 prompt、configuration 或 tool-definition 变更解决。

Agent loop optimization 正在成为自己的工程学科。 Harness 现在比以往任何时候都更重要，管理模型如何处理不确定性、如何从错误中恢复、如何决定何时完成。

强模型 + 坏 harness 可能仍能完成工作。强模型 + 好 harness 将解锁新层次的能力。

过去几年 AI 进步由模型改进主导。基础模型改进可能继续。这些实验结果表明，大量 Agent 表现现在在 harness 层可用。

HALO 是团队让该层可测量和可优化的尝试。它使用轨迹识别 recurring agent-loop 失败，区分 harness-shaped failures 和 model capability limits，并推荐 prompt configuration、loop behavior 和 tool definitions 的具体变更。