HALO：利用RLM构建自我改进的智能体

AI智能体由两个关键要素组成：模型（model）和框架（harness）。模型决定做什么，框架负责执行。当你将模型放入框架并启动循环时，就得到了一个AI智能体。过去投入了数十亿美元用于改进模型，但对框架的关注却少得多——直到最近。

来自@a1zhang的“被错配的天才假设“认为，大语言模型确实拥有超人类智能，但或许我们人类并不擅长管理这些将模型转化为智能体的框架，而可能存在一条路径——让模型自行决定框架应有的形态，从而创建更好的智能体。

为了探索这一想法，我们构建了HALO（分层智能体循环优化器）。

原文链接：https://x.com/samhogan/status/2049619541727302040?s=20 GitHub仓库：https://github.com/context-labs/halo

过去几周，我们将HALO应用于主流基准测试，以验证我们的策略是否确实有效。我们发现，HALO能够在多种评估中持续提升基准分数，包括在AppWorld、TerminalBench、Finance Bench等任务上实现10%以上的改进。这些结果表明，框架正成为一个可优化的服务层：其重要性可与模型本身媲美，并且越来越可以作为独立的工程对象进行度量。

今天，我们发布这项研究的发现。

HALO基准测试结果

HALO基准测试结果

什么是HALO？

HALO是一个智能体（模型+框架），它通过分解其他智能体（同样是模型+框架）的执行轨迹，来理解框架的表现以及如何改进。它由一个RLM驱动，配备特定工具，使其能够一次性对数十万次智能体执行进行深入分析，识别跨执行中的共性问题，并建议对框架进行更改，从而提升智能体的整体性能。

HALO的核心循环出奇地简单：

• 收集智能体的执行轨迹。
• 将这些轨迹输入HALO。
• HALO分析轨迹，识别重复出现的故障模式。
• HALO生成一份报告，描述可能的框架级修复方案。
• 这些修复由编码智能体应用于智能体框架。
• 重新运行智能体，收集新的轨迹，循环重复。

这不同于人工检查少量失败案例。许多框架问题在单个轨迹中并不明显。每次失败运行在局部看起来可能合理——只有当跨多次执行分析智能体行为时，模式才会显现。HALO旨在揭示这些聚合模式，并将其转化为具体的框架变更。

HALO循环

HALO循环

Terminal-Bench：Gemini Flash迈向前沿编码框架性能

我们近期实验中最强的结果来自将HALO应用于Terminal-Bench。

Terminal-Bench是一个“有意义的混乱“基准。智能体被放入一个带有文件系统的真实shell中，必须完成以最终状态评分的任务。成功取决于框架如何管理探索、shell命令、文件检查和任务执行。

基线使用terminus-2框架搭配gemini-3-flash-preview，得分为46%。应用HALO生成的框架变更后，通过率提升至57.14%。作为参考，Claude Code on Opus 4.6在同一基准上得分为58%。

HALO在轨迹中发现了一个重复模式：智能体的第一个命令往往过于通用。收到任务后，它经常以宽泛的方向性命令开始，如目录列表或大范围文件搜索。虽然在单个轨迹中看似无害，但HALO发现这种模式会降低完成率，因为它消耗了智能体有限的回合预算，却没有产生有价值的信息。

修复方案是让智能体更早地以任务为导向。HALO建议对提示和配置进行更改，鼓励智能体在默认进行宽泛的文件系统探索之前，先形成具体的任务假设。经过这些更改后，智能体花在通用方向定位上的时间减少，更多地执行与任务相关的操作。

这是一个很好的框架型故障例子。模型本身有足够能力解决许多任务，但框架允许了太多低价值的探索。

Finance-Agent：当基线存在答案质量余量时获得更大提升

我们还在Vals AI的Finance-Agent基准上对四个模型运行了HALO。

最大的改进来自claude-opus-4-7。基线得分为56%综合。应用HALO后，得分提升至72%综合。同样，这仅仅是通过改进框架实现的。

在Finance-Agent中，智能体经常收集到相关信息，但未能生成完整的最终答案。令人惊讶的是，这里的主要失败是答案构建，而非搜索相关。

HALO识别出，基线框架通常能够得出正确答案，但未能以要求的格式提交。HALO推荐了一个更明确的覆盖范围评估标准，促使智能体检查最终答案是否涵盖了问题的所有必要维度。对于claude-opus-4-7，这一简单更改使性能比基线提升了18%。

同样的格式更改并非对每个模型都有同等帮助。

GPT-5.5从更高的基线72%起步，因此同样类型的改进只带来了微小的额外提升。Kimi-K2.6则走向了相反方向：帮助Opus的更重覆盖评估标准反而降低了其性能。在下一轮循环中，HALO识别到这一点，推荐了更轻量、更注重具体事实的指令，将Kimi-K2.6从56%提升至64%。

这是轨迹驱动的框架优化的另一个有用特性：最好的框架并非通用。不同模型有不同的故障模式，相同的提示更改可能帮助一个模型却损害另一个。HALO之所以有用，正是因为它搜索适合特定模型和执行环境的框架形状。

AppWorld：改进有状态工具使用和长周期执行

AppWorld测试智能体是否能在类似应用的环境中操作，使用有状态API、工具调用和多步骤用户目标。这些任务接近生产智能体中出现的长期执行问题。智能体必须理解用户目标，选择正确的工具，维护状态，并避免那些会在多步中累积的小错误。

AppWorld结果

AppWorld结果

在我们的AppWorld评估中，HALO在Sonnet 4.6和Gemini 3 Flash上都产生了巨大提升。在Sonnet 4.6上，性能从73.7%提升至89.5%。在Gemini 3 Flash上，性能从36.8%提升至52.6%。

第一个主要故障模式是工具可用性。在几个轨迹中，模型似乎理解需要做什么，但框架没有暴露出正确的后备工具。例如，当一笔Venmo交易因账户余额不足失败时，智能体尝试通过支付卡路径恢复。相关API存在，但由于API预测器将其遗漏，智能体无法使用。表面上看，这像是模型幻觉，但轨迹级诊断显示，智能体的工具表面过于狭窄，无法实现现实的恢复行为。

HALO通过修改框架，使其更好地暴露合理智能体可能需要的工具，从而改进了API预测层。预测器被推向更高的召回率，特别是针对登录、搜索、显示、列表、获取、主管、时间、人员搜索和后备API。在Sonnet运行中，最大预测API预算也被增加，以便真正的恢复API不太可能在到达智能体之前被截断。

AppWorld的结果是框架优化在多个层面推进的有用例子。首先，HALO使正确的工具可用。然后，它减少了浪费或不可恢复的工具行为。接着，它改进了最终答案和批量操作验证。这些提升来自于使循环更可靠，而非改变底层模型。

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

SWE-Bench考验智能体框架的不同部分。智能体必须检查仓库，理解问题，进行代码更改，并生成能通过测试的补丁。

SWE-Bench结果

SWE-Bench结果

在我们使用terminus-2搭配Gemini 3 Flash的SWE-Bench Verified运行中，基线已经很强，达到65.0%。应用HALO生成的框架变更后，最高得分提升至74.0%。

最可靠的改进来自一个简单的提示更改。HALO建议智能体在编辑后运行相关的失败测试，执行快速lint或语法检查，重新阅读问题，确认根本原因已被处理，并在进行风险编辑前检查邻近调用者。这促使智能体在补丁生成和验证之间形成闭环。

HALO还揭示了剩余失败中的一个重复调试模式：智能体有时在深入实际失败之前，先从浅层的仓库方向定位开始。像宽泛的列表、通用搜索或文件系统探测等命令，在单个轨迹中看似合理，但跨多个轨迹来看，它们延迟了智能体复现bug或检查失败断言的时机。这类似于我们在Terminal Bench中看到的失败。

SWE-Bench的结果展示了与AppWorld不同的教训。在AppWorld中，框架需要更好的工具召回和执行纪律。在SWE-Bench中，框架需要更好的验证压力，但不能过度管理智能体。

tau3-Bench：识别框架故障与模型能力故障的边界

HALO并不会将每次失败都转化为框架修复。

这在tau3-Bench（Sierra Research的375个任务基准，涵盖航空、零售、电信和banking_knowledge领域）上最为明显。我们在gemini-3-flash-preview上的基线为64.27%。应用HALO生成的变更后，得分提升至67.47%。

这是真实的改进，但幅度小于我们在其他基准上看到的。四个领域中有三个，HALO能够推动通过率上升。第四个领域banking_knowledge则是一个硬瓶颈。智能体在需要回忆和应用特定银行政策细节的政策问题上反复失败。在这些情况下，问题主要不在于框架。模型自信地复述政策，而非检索或应用相关事实。

HALO直接揭示了这一区别。它发现banking_knowledge的准确率似乎被限制在约10%，无论智能体如何被提示。我们尝试了多种框架变更，包括更深层的政策查找纪律、搜索上限和单段压缩。虽然每种方法略有帮助，但都没有突破瓶颈。

这是一个重要的负面结果。HALO可以在框架中找到松弛空间，但它无法凭空创造模型本身缺失的知识。

这一区别对生产智能体很重要，因为并非每次失败都是提示问题，也并非每次失败都是模型问题。HALO的实际用途之一就是区分这两者。显然，它既是判断是否需要更强模型能力的工具，也是发现框架是否在错配模型的工具。

跨基准总结

在Terminal-Bench、Finance-Agent、AppWorld、SWE-Bench和tau3-Bench上，同样的模式反复出现：智能体性能往往受限于框架级的故障模式，而这些模式从单个轨迹中难以看出。

具体的故障模式因基准而异：

• 在Terminal-Bench上，智能体在早期将过多预算花在通用探索上。
• 在Finance-Agent上，智能体经常收集到正确信息但未能生成完整答案。
• 在AppWorld上，智能体常常需要更好的工具召回、更好的后备行为、更严格的完成纪律，以及更仔细的验证（针对长枚举或批量状态更改）。
• 在SWE-Bench上，智能体从编辑后的轻量级验证中受益，但更重或更指令式的调试指示可能会过度约束循环。
• 在tau3-Bench上，HALO既发现了框架级的改进，也发现了一个领域瓶颈似乎是模型能力而非框架设计。

共同点在于，这些失败并非通过阅读一两个轨迹就能完全理解，而是聚合的行为模式。一旦被揭示，其中许多可以通过提示、配置或工具定义变更来解决。

这也是我们认为智能体循环优化正在成为独立工程学科的原因。框架如今比以往任何时候都更重要，它管理着模型如何处理不确定性、如何从错误中恢复，以及如何决定何时完成。

强模型配上差框架，或许仍能完成任务。但强模型配上好框架，将解锁新的能力层次。

HALO的下一步

过去几年的人工智能进步主要由模型改进主导。基础模型的提升很可能会继续。我们这些实验的结果表明，智能体性能中有相当一部分现在可以从框架层获得。

HALO是我们尝试使该层可度量、可优化的努力。它利用轨迹识别重复的智能体循环失败，区分框架型故障与模型能力限制，并推荐对提示配置、循环行为和工具定义的具体变更。

我们正在将这些学习成果超越标准基准测试，应用于真实世界的智能体部署，与少数大规模运行智能体的团队合作，在大量流量环境中应用HALO技术。

如果你在生产环境中运行智能体，并且有兴趣让我们的团队将HALO应用于你的智能体，请通过(@samhogan)或@AmarSVS与我联系，获取更多信息。