HEELO将智能体工具能力封装为可验证原语，攻克真实任务最后一公里

摘要：论文提出Agent-Native Primitives与HEELO框架：把工具、终端、开发、导航等资源封装为携带常驻LLM、可互相通信的执行单元，再按任务动态组合为执行图。系统依据环境证据验证结果，并仅在失败暴露缺陷后修订或新增原语。实验覆盖20余个基准：同骨干下Terminal-Bench 4.0完成率由37.3%升至55.5%，ToolBench通过率由55.8%升至75.1%；在46项平台任务中，HEELO还显著提高完成数量并降低单任务时间与成本。不过，结果主要来自论文实验，跨模型、跨环境稳定性以及原语库持续演化的治理成本仍待独立验证。

---

核心思路：把“如何正确使用资源”变成可复用资产

传统智能体框架通常负责把终端、代码执行器、浏览器或业务API交给模型，再依赖提示词告诉模型何时调用、如何组合参数、如何处理异常。结果是，同一种操作能力会在不同 Harness 中反复实现，模型即使知道工具存在，也经常卡在“拿到资源之后”的执行环节。

HEELO提出的 Agent-Native Primitives 将这项能力下沉到资源内部。每个原语包含三层职责：

1. 资源适配层封装具体接口、环境状态和副作用；
2. 常驻LLM根据当前任务上下文理解并执行该资源，而不是只输出通用调用建议；
3. 原语间通信协议负责传递中间状态、依赖关系与失败信息。

因此，模型面对的不再是裸露工具，而是一个已经携带局部执行语义的“可操作能力单元”。

HEELO如何构建任务专用执行图

HEELO（Harness Engineering around Evolving Agent-Native Primitives）不是一套固定工作流模板，而是面向具体任务动态组织原语的 Harness 工程框架。其基本循环可拆为四步：

• 识别任务需求：根据目标选择开发、工具、Harness、导航等原语家族；
• 组合执行图：将原语连接成任务专用DAG，明确输入输出、调用顺序与失败传播关系；
• 环境验证：不只检查模型最终回答，而是使用终端状态、文件差异、业务返回值等环境证据核验结果；
• 定向演进：若失败可归因于某个原语，就修订该原语；候选新原语通过验证后才能进入原语库。

这种设计与“每次失败就重写整套提示词”的方式不同。优化对象从一次会话中的轨迹，上升为可积累、可审查的执行能力。

基准结果：收益来自执行框架，而非更换基础模型

论文在20余个基准上评估八类原语。几个关键结果体现了框架与基础模型能力的正交性：

| 评测 | 基线 | HEELO相关原语 | 变化 | |---|---:|---:|---:| | Terminal-Bench 4.0完成率 | 37.3%（Codex） | 55.5%（同一骨干） | +18.2个百分点 | | Terminal-Bench 2.0 Pass@1 | 60.0%（种子Harness） | 72.2% | +12.2个百分点 | | ToolBench通过率 | 55.8% | 75.1% | +19.3个百分点 | | GAIA-Text-103准确率 | 45.6% | 58.3% | +12.7个百分点 |

其中，Terminal-Bench 4.0保持相同基础骨干，是较有说服力的对照：提升主要来自原语与Harness组织，而不是简单更换模型。

在46项真实平台任务上，Claude Opus 5.5配合Claude Code、GPT-6.1 Sol配合Codex单独运行时均完成9项；接入HEELO的MCP Server后分别完成39项和35项。按成功任务归一化，论文报告耗时降低1.9倍和2.3倍，单个完成任务成本降低1.55倍。

工程权衡：可复用性并不等于零成本

HEELO的收益伴随至少四项成本。

上下文与Token开销

每个原语内部都有常驻LLM。任务图包含多个原语时，局部推理、状态同步和证据汇总会增加Token消耗。论文中的“单任务成本下降”依赖完成任务数量显著增加；若只运行简单任务，框架本身可能比裸Harness更贵。

延迟会随图深度累积

任务专用DAG可并行执行独立分支，但存在依赖关系的原语必须顺序运行。每次环境调用、验证和失败重规划都会增加关键路径延迟，因此“总吞吐提升”与“单请求尾延迟”可能给出不同结论。

原语库可能积累脆弱组合

被修订过的原语可能适配某类任务，却在另一环境中误触发。系统以环境证据验证结果，降低了盲目演化风险，但论文摘要没有展示跨版本回归、权限隔离和失败原子性等生产指标。

原语共享会引入权限风险

把代码执行、文件修改和外部API封装为常驻能力后，调用链更紧凑，也更容易把一个原语的错误权限扩散到下游。生产部署仍需为每个原语设置最小权限、沙箱、超时、预算与审计日志。

评测可信度：增益明显，但外部有效性仍待建立

论文覆盖多个基准，且关键结果包含同骨干对照，这是其主要优点。不过，完整评估仍面临几个问题：

• 不同原语家族分别对应不同任务，跨基准数字不能直接相加；
• Terminal-Bench等成绩容易受Harness配置、提示模板、工具版本和重试预算影响；
• 论文若未统一计算“完成一项任务”的模型调用量，耗时与成本比较可能偏向特定执行方式； +- 原语库经过任务反馈后持续演化，存在针对评测集过拟合的可能。

+因此，HEELO更可信的结论是“可验证原语能显著减少执行框架的重复建设”，而不是其提升幅度已能无条件外推到生产环境。 + +## 开发者落地建议 + +对于希望采用HEELO思路的团队，可按以下顺序推进： + +1. 先选择高频且边界清晰的任务，如代码修改、终端诊断或网页检索，不要直接覆盖开放域长程任务； +2. 将执行能力封装为原语，为每个原语提供结构化输入输出、证据接口与明确失败类型； +3. 使用任务图运行时并行调度，并记录每个原语的延迟、Token、费用和副作用； +4. 采用环境证据验收，对代码执行检查测试结果，对业务任务检查状态或返回记录； +5. 建立原语版本库与回归测试，避免一次失败修订破坏其他任务； +6. 最后再开放自动新增原语，对代码执行、外发数据和凭据访问设置人工或策略门控。 + +HEELO揭示的核心趋势不是再增加一种Agent框架，而是把智能体工程的重心从“写更长提示词”转向“建设可组合、可验证、可演化的执行能力库”。这套思路尤其适合终端、研发工具链和多服务协作场景。

---

消息来源：Hugging Face Daily Papers (2026-11-05)

—— 完 ——

主题标签： #HEELO 关注 #Agent-Native Primitives 关注 #Agentic Workflow 关注 #Harness Engineering 关注 #MCP 关注