为什么「够得着资源」不等于「会用资源」
2026 年 11 月 5 日，Haibo Jin 等 14 位作者向 arXiv 提交《The Last Mile to the Real World: Agent-Native Primitives as Reusable Building Blocks for Solving Real-World Tasks》（arXiv:2611.07461，102 页、21 图、54 表）。论文开篇给了一个不常被单独讨论的失败位置：模型与工具都已就位，任务仍跑不完，问题出在从「拿到资源」到「把资源用对」这一段，作者称之为通向真实世界的最后一公里（来源：arXiv 摘要页全文）。
论文用 Terminal-Bench 4.0 的两个公开读数作锚：GPT-5.6 Sol 配 Codex 解决 37.3% 的任务，Claude Opus 5 配 Claude Code 解决 51.8%。作者没有把这 14.5 个百分点的差距归因于模型权重，而是指出现有做法把资源放到模型手边，却把「怎么用」留给调用方，于是每个 harness 都要重建一遍同样的使用能力。一次文件读取、一次数据库查询、一次网页表单提交，能力描述写在工具 schema 里，但真正决定成败的是在当下上下文里选择参数、检查返回、处理失败的那段经验（来源：arXiv HTML 全文 2611.07461v1 引言）。
| 环节 | 现有做法 | 论文指出的缺口 | HEELO 的替代 |
|---|---|---|---|
| 资源暴露 | 工具描述、API schema、MCP tool 列表 | 只说明动作能做什么，不说明此刻怎么用 | 原语自带常驻 LLM 与接口 |
| 使用能力 | 由调用方 harness 逐任务重写 | 每个 harness 重复建设，难以复用 | 沉淀为可组合、可准入的库单元 |
| 失败定位 | 看最终答案或模型自评 | 难以判断是哪一环该改 | 环境证据牵连到具体原语集合 |
| 改进沉淀 | 改提示词、换模型 | 改动随任务结束而消失 | 经 VALIDATE 后才写入库 |
本站此前解构的 AWS Deep Insight 四层上下文工程（R-TECH-60）处理的是进入窗口的 token 与离开窗口的结论；HEELO 处理的是谁负责把资源用起来。两者不在同一层：前者压缩信息量，后者重新分配能力归属。把两者都记成「省 token」会抹掉这个区别。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是该框架在非代码类企业流程上的迁移成本、以及八类原语之外的任务如何扩展。
八类原语族：把能力挂在资源上
论文把 agent-native primitive 定义为给某项资源配一个常驻 LLM，由它在当前上下文里使用该资源，并与其他原语通信的可复用单元。实例化时共给出八个族，每族对应一类任务（来源：arXiv HTML 全文 2611.07461v1 中原句列举）。
| 原语族 | 对应任务类型 | 论文中出现的量化读数 |
|---|---|---|
| Tool Primitives | LLM 工具调用 | ToolBench 通过率 55.8% → 75.1% |
| Code Primitives | 仓库构建 | 归入二十余个基准，未单列头条数字 |
| Math Primitives | 形式化定理证明 | 归入二十余个基准，未单列头条数字 |
| Knowledge Primitives | 知识密集型任务 | 归入二十余个基准，未单列头条数字 |
| Agent Primitives | 多智能体系统 | 归入二十余个基准，未单列头条数字 |
| Dev-Primitives | 软件工程 | Terminal-Bench 4.0 解决率 37.3% → 55.5% |
| Navigation Primitives | 大型信息空间导航 | GAIA-Text-103 准确率 45.6% → 58.3% |
| Harness Primitives | 智能体 harness 构建 | Terminal-Bench 2.0 Pass@1 60.0% → 72.2% |
八族里只有四族在摘要里给出可核对的头条数字。这本身是一条读法提示：二十余个基准与八族的覆盖关系并不是每族一条成绩，公开摘要无法还原各族的完整分项。按最少口径折算，每族平均对应约 2.5 个基准，但这只是把「二十余」当二十的下界做的除法，不是论文报告的实验分配（原创换算）。
工具描述是被动文本，由调用方解释；原语自带模型，能接收局部请求、读取前驱结果、在轮次结束前给其他原语发消息。因此组合成本随本轮被激活的原语数增长，而不是随整个库规模增长——论文在 COMPOSE 的定义里明确写了这一点。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是各族内部的具体原语数量、常驻 LLM 的规格与调用成本，以及库规模增大后的检索退化情况。
compose / verify / revise / admit：三步在任务内，一步在任务间
HEELO 的全称是 Harness Engineering around Evolving Agent-Native Primitives for the Last Mile to Real-WOrld Tasks。其循环常被简写成四步，但论文正文把前三步与第四步放在了不同的时间尺度上（来源：arXiv HTML 全文 2611.07461v1 方法章节）。
| 步骤 | 发生位置 | 输入与动作 | 输出与终止 |
|---|---|---|---|
| COMPOSE | 任务内每轮 | 按任务、当前上下文与原语接口选出激活集，组成任务特定图 | 激活原语、局部请求、依赖边；无原语覆盖的需求留给 harness 自身 |
| VERIFY | 任务内每轮 | 运行可运行环境，采信构建状态、测试结果、编译器消息与轨迹 | 通过或失败判定，附观察失败、被牵连原语集合与修订指引 |
| REVISE | 任务内失败后 | 把反馈并入上下文重新组合，只改被证据牵连的部分 | 判定通过即结束，或达到 B 轮修订上限后返回当前结果 |
| ADMIT | 任务之间 | 从已有产物、已验证运行或失败轨迹里挖出候选原语 | 仅 VALIDATE 通过者加入或替换库内原语 |
最容易读错的是 VERIFY 的权限边界。论文写明：构建或测试失败即判 fail，任何模型判断都不能覆写它。这条把环境证据放在模型自评之上，也解释了为什么后面 REVISE 能定位到「被牵连的原语集合」——失败来自具体证据，而非一句「我觉得没做好」。
另一个容易读错的是 ADMIT。任务内产生的适配组件不会自动进库，必须走单独的验证与发布通道，VALIDATE 用领域能提供的证据：测试、编译器、源码或开发任务上的匹配运行。换句话说，「这次跑通了」不等于「以后可以复用」。这与本站解构过的 Harness²（R-TECH-43）形成对照：后者在任务内反复改写脚手架文件，HEELO 把改动沉淀到库里之前多了一道验证闸门。
循环终止条件里有修订轮次上限 B，但公开摘要与可见方法章节没有给出 B 的取值、不同任务上 B 的分布，也没有给出「达到上限仍失败」的任务占比。缺少这个数，就无法判断 REVISE 的开销是常数级还是随任务难度放大。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是 B 的取值策略、VALIDATE 的误准入率，以及冲突原语的替换规则。
四组同骨干增益：分母与口径核对
论文摘要给出四组可核对的读数，且都强调在同一 backbone 上对比，也就是说被改动的不是模型权重。四组的基准、指标与起点都不同，先把它们并排放好（来源：arXiv:2611.07461 摘要页）。
| 基准与指标 | 基线 | 接 HEELO 后 | 百分点提升 | 相对提升 | 基线口径 |
|---|---|---|---|---|---|
| Terminal-Bench 4.0 解决率 | 37.3% | 55.5% | +18.2pp | 约 +48.8% | 同骨干下 Codex 结果 |
| Terminal-Bench 2.0 Pass@1 | 60.0% | 72.2% | +12.2pp | 约 +20.3% | seed harness |
| ToolBench 通过率 | 55.8% | 75.1% | +19.3pp | 约 +34.6% | 未注明具体产品 harness |
| GAIA-Text-103 准确率 | 45.6% | 58.3% | +12.7pp | 约 +27.9% | 未注明具体产品 harness |
右侧两列是本文按公开数字做的原创换算，论文摘要只报前后两个百分数。四组的相对提升落在 20.3% 至 48.8% 的区间，跨度约 28.5 个百分点；把四个相对值平均成「整体提升约三分之一」没有依据，因为分母分别来自四个不同基准。
还有一处需要并列保留：摘要同时给出 Claude Opus 5 配 Claude Code 在 Terminal-Bench 4.0 上是 51.8%，而 Dev-Primitives 在同骨干下做到 55.5%。数字上后者高出 3.7 个百分点，但两组使用了不同模型与不同 harness，论文并未把它设计成跨模型对照实验，不宜据此排产品名次（原创口径辨析）。同类误读在本站 R-BENCH-28 的 Terminal-Bench 4.0 读法里已经专门讨论过。
解决率、Pass@1、通过率、准确率并不是同一种计分口径；即使都写成百分数，也不能相加或连乘。可迁移的结论只有一条：在冻结骨干模型的条件下，重做执行层能带来两位数量级的百分点增益，增益大小取决于任务类型。
46 个真实任务：9→39 与 9→35 怎么读
论文在 heelo.dev 平台上放了 46 个真实任务，覆盖四个端到端闭环的 26 项能力，每项的通过标准在首次运行之前固定；任务示例包括发布页面、发送外联、读取发票、抓取来源，以及航班、日历、邮件与浏览器自动化（来源：arXiv HTML 全文 2611.07461v1 与 heelo.dev 项目页）。
| 组合 | 独立完成 | 经 MCP 接 HEELO | 折算完成率 | 时间与成本 |
|---|---|---|---|---|
| Claude Opus 5.5 配 Claude Code | 9 / 46 | 39 / 46 | 19.6% → 84.8% | 时间少 1.9×，单完成任务成本低 1.55× |
| GPT-6.1 Sol 配 Codex | 9 / 46 | 35 / 46 | 19.6% → 76.1% | 时间少 2.3×，成本低 1.55× |
完成率、倍数与差值均为本文按 46 这一共同分母做的原创换算。9→39 是约 4.33 倍，9→35 是约 3.89 倍；时间少 1.9× 与 2.3× 折算成剩余时间约 52.6% 与 43.5%，成本低 1.55× 折算成剩余成本约 64.5%。这些倍数分别对应两款模型与两组运行，不是同一个实验的两个指标。
按最小口径还能反推任务密度：46 个任务分摊到 26 项能力约每项 1.77 个，26 项能力分摊到四个闭环约每个 6.5 项。图注另说明时间与成本按「一项能力的任务」取平均，因此不是按 46 个任务逐个计量的明细账；若某项能力下任务数不同，均值会被任务数加权（原创换算与口径辨析）。
heelo.dev 由论文作者团队运营，46 个任务、通过标准与接入方式均由同一方设定。它证明的是「该平台上的这些动作被包装成原语后可被调用」，尚不能外推到企业内网的异构系统。论文也没有公布独立第三方的复现结果。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是四个闭环与 26 项能力的完整清单、失败案例分布，以及 1.55× 成本倍数的计费口径。
MCP 接入与可迁移边界
HEELO 不是要求用户换掉现有编码智能体。官方描述的连接链路是：Claude Code、Codex、Cursor 等外部智能体或 harness，通过 heelo.dev 的 MCP server 接入，把真实世界动作当作 agent-native primitives 来调用（来源：arXiv HTML 全文 2611.07461v1 与 heelo.dev 项目页）。
| 层 | 由谁持有 | 公开材料给出的内容 | 公开材料未给出 |
|---|---|---|---|
| 外部智能体 | Claude Code / Codex / Cursor | 发起 46 个任务，独立完成 9 个 | 版本、系统提示与工具白名单 |
| MCP server | heelo.dev | 把真实世界动作暴露为原语 | 认证方式、工具 schema、协议细节 |
| 原语库与组合器 | HEELO | 八族、COMPOSE 与 VALIDATE | 库规模、检索召回率、并发上限 |
| 环境证据 | 任务运行环境 | 构建状态、测试、编译器消息、轨迹 | 无可执行环境时的替代证据强度 |
可迁移的部分是机制，不是平台：把「会用某个系统」做成带验证的独立单元、让失败证据指向具体单元、只把验证通过的改动写回库。这三条在多数企业 harness 里都能先小规模试。不可直接迁移的是读数——平台的 46 个任务、MCP 暴露的动作集与通过标准都由一方定义。
同周还有两条相邻路线值得并列：HarnessFlow（arXiv:2611.06254）用蒙特卡洛树搜索改写整套执行程序，在固定 GPT-5.4-mini 骨干下把六项基准宏平均从 58.59% 提到 69.48%；Agent Harness Awareness（arXiv:2611.05391）在动作派发前注入经过验证的遥测快照。三者改的都是执行层，但改动对象分别是库单元、流程代码与输入状态，不能叠加成一份总收益（本轮能力评测篇 R-BENCH-58 另做量化横评）。
失败表现为「工具拿得到、参数总填错」，优先看把使用能力绑到资源上；表现为「流程顺序或停止规则不对」，优先看流程搜索；表现为「工具当时已经不健康」，优先看遥测注入。先定位失败落在哪一段，再决定改造哪一层。
六组原创换算与它们各自的分母
以下六组数字均由本文依据公开读数推算，论文摘要未直接给出。每组都标明分母，避免把不同口径的量拼在一起。
| 换算 | 依据 | 结果 | 分母与边界 |
|---|---|---|---|
| 四组增益的相对幅度 | 18.2/37.3、12.2/60.0、19.3/55.8、12.7/45.6 | 约 48.8% / 20.3% / 34.6% / 27.9% | 各自基准基线，跨行不可平均 |
| 每族平均基准数下界 | 二十余个基准 ÷ 八族 | 至少约 2.5 个 | 把「二十余」按下界二十处理 |
| 库内密度 | 102 页 ÷ 54 表；54 表 ÷ 21 图 | 约 1.89 页一表、每图约 2.57 表 | 篇幅结构，非实验密度 |
| 46 任务完成率 | 9、39、35 同除以 46 | 19.6% → 84.8% / 76.1% | 同一批任务，不同模型与 harness |
| 时间成本折算 | 1.9×、2.3×、1.55× | 剩余时间约 52.6% / 43.5%，剩余成本约 64.5% | 按「少 N 倍」口径折算，非直接测得 |
| 能力与任务密度 | 46 ÷ 26；26 ÷ 4 | 每能力约 1.77 任务、每闭环约 6.5 能力 | 均摊，实际分布未公开 |
把 84.8% 与 76.1% 相减得到 8.7 个百分点是有意义的，因为分母同为 46；但把 55.5% 与 84.8% 相减没有意义，前者是 Terminal-Bench 4.0 的任务解决率，后者是 heelo.dev 自建任务集的完成率。这条界线是本文对读榜顺序的主要增量。
可证伪边界与未披露项
把这篇材料当作工程清单时，以下几处应保留怀疑：
- 平台自报：46 个任务、26 项能力、四个闭环与通过标准均由作者团队设定，未见第三方复现或外部任务集验证。
- 缺成本明细：摘要只给「每个已完成任务成本低 1.55×」，未给单任务美元成本、原语常驻 LLM 的调用开销与搜索修订轮次的额外账单。
- 缺误准入率：ADMIT 设有 VALIDATE 闸门，但公开材料没有给出候选原语被拒绝的比例、误准入后的回滚机制与库污染的检测方式。
- 八族覆盖未知：二十余个基准与八族的对应关系未完整披露，八族之外的任务如何扩展、由谁写新原语没有说明。
- 修订上限 B 未取值：REVISE 的终止依赖 B 轮上限，缺少取值与分布就无法估算最坏情况下的延迟与费用。
- 同骨干不等于同成本：冻结模型权重只保证能力对照更干净，激活原语、常驻 LLM 与验证运行都会增加调用次数，增益与开销不在同一张表上。
一条可证伪的检验路径是：固定原语库不再 admit 新单元，只保留 COMPOSE 与 VERIFY，若四组增益大体不变，则「库演化」不是增益来源；反过来若增益明显回落，才说明 ADMIT 起了作用。论文目前没有给出这组消融，本文把它列为待验证项而非结论。
可迁移的做法其实不依赖 heelo.dev：为每个高频系统写一份带验证的使用单元、让失败证据指向具体单元、把改动经独立验证后再写回共用库。这三步在多数智能体框架里都能先做小规模 A/B，再决定是否引入完整原语库。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是四个端到端闭环与 26 项能力的完整清单、第三方复现数据、ADMIT 的误准入率与八族之外的扩展规范。