长程智能体的真正瓶颈：坚持、纠错与被监督（深度版）

导读

过去一年，智能体演示里的任务从"订一张机票"变成了"把一套科研代码复现出来""把一份尽调材料整理成报告"。任务时长从几分钟变成了几小时，工具调用从几十次变成了几百次。OSWorld 2.0 的统计很直观：其 108 个真实工作流平均需要 318 次工具调用，而上一代基准约为 30 次；在 500 步预算下，表现靠前的配置也只完成了 20.6% 的任务 [1]。

时长一拉长，失败的样子就变了。短任务里，智能体通常是"不会做"；长任务里，更常见的是另外几种失败：

• 过早停手：明明没做完，却宣布"已完成"。
• 看不见自己的错：几十步之前埋下的错误一路传导到现在，却浑然不觉。
• 一起错：多次独立运行得出同一个答案，答案本身却是错的。
• 看不懂：做了几百步，人却说不清它中途改了什么、为什么这样改。
• 记不准：跨会话的状态没记住，或者记住了却没在需要时取出来。

2026 年 10 月，一批论文集中把这几类失败变成了可测量、可训练的对象。本文选取其中 10 篇（另有 2 篇背景文献），按"坚持、纠错、验证、监督、记忆与协作"五根支柱展开：每项工作讲清问题、机制、实验与局限，穿插 5 个算法拆解，最后给出我们的判断、未来展望，以及对金融风控场景的落地启示。

一、背景：为什么"能完成"不等于"可靠"

先厘清两个容易混淆的概念。

能力指的是"给足时间和提示，能不能做出来"；可靠性指的是"在没人盯着的几个小时里，能不能持续推进、发现偏差、及时纠正，并给人留下看得懂的记录"。前者靠模型本身，后者更多取决于评估方式、训练数据与外部框架（harness）。

长程任务对可靠性的要求有三个特殊之处：

1. 误差会复利。单步 99% 的正确率，连乘 300 步后只剩约 5%。更麻烦的是，早期的小错误往往不会立刻暴露，而是在几十步之后才以"结果不对"的形式出现。
2. 评估信号稀疏。"过 / 不过"的二元判分对短任务够用，对三小时任务则过于粗糙：一个做到 90% 的智能体和一个原地打转的智能体，可能拿到同样的 0 分。
3. 人的注意力有限。用户把工作委托出去以后，角色从"做决定"变成"监督执行"，但几百步的轨迹远超人能逐条审阅的范围 [5]。

这也解释了为什么 10 月的研究重心不在"更强的模型"，而在"更好的尺子"和"更好的纠错数据"。

二、坚持：用三小时的尺子量"持续推进"

2.1 LHTB 2.0：把评估时长拉到三小时

问题。第一代 Long-Horizon-Terminal-Bench 的任务靠人工逐个设计，扩展成本高，评估时长也只有 90 分钟。更关键的是，二元判分看不到"做到了哪一步"。

机制。 LHTB 2.0 [2] 保留原有 46 个任务，修复缺陷后新增 31 个，共 77 个任务，覆盖 13 个领域、8 类任务，其中重建类 30 个、审计修复类 23 个。新增的核心技术是"重建任务流水线"，流程如下：

• 从一个能跑通的科研或工程制品出发（例如激光雷达点云配准、化学反应模板、声学波束形成）；
• 用参数化的参考实现扫出多个场景，公开 6 个作为行为证据，保留 3 个用于隐藏评分；
• 智能体要写出一个终端程序，在没见过的场景上复现参考行为；
• 用稠密进度阶梯给部分进展打分，同时用防记忆机制挡住"照抄公开输出"。

此外，评估时长从 90 分钟延长到 3 小时，每 30 分钟记录一次验证检查点，而且检查点评分与运行中的智能体相互隔离。

实验。研究者用 Harbor 框架与 Terminus-2 智能体框架，对 15 个模型做了 1,145 次评分运行，主要发现有四条。

• 头部成绩。 1,145 次运行中整体只有 192 次（16.8%）通过。GPT-6-astra 的稠密平均得分为 0.69，在 37 个任务（48.1%）上达到 R≥0.95；GPT-5.6-sol 为 0.67，对应 32 个任务。
• 判分方式。在 30 个重建类任务上，二元判分平均只有 0.221，稠密阶梯平均为 0.653。只看结果，会丢掉大量中间进展。
• 虚假完成。 92% 的"已完成"声明出现在最终从未通过验证的运行中。头部模型中位数在第 7—8 分钟就首次声称完成；在没解出的运行里，GPT-6-astra 平均声称完成 24 次，MiniMax M3 达到 58 次。
• 花费结构。平均每个任务花费 48.41 美元、262.5 次调用、94.3 分钟。三个小时的花费占比依次为 18%、31%、51%，解出占比却是 58%、21%、21%。第三小时找到的解，成本约为第一小时的 8 倍（708 美元对 90 美元，未计提示缓存折扣，为上限估计）。各模型 83%—99% 的花费流向了最终没解出的任务。

局限。重建类任务偏科研与工程场景，与办公、金融类流程的结构不同；成本数字依赖当时的 API 定价，且未计缓存折扣。检查点数据整体上支持"坚持有用"：平均得分从 30 分钟时的 0.29 升到结束时的 0.43，693 次运行中有 267 次在 30 分钟后又提升了 0.05 以上。但也有 65 条轨迹的最终得分比 30 或 60 分钟检查点低 0.05 以上，主要集中在游戏和谜题类任务，后续动作破坏了状态或覆盖了有用的产出。坚持本身不是目的，"越做越糟"同样存在。

算法拆解 1：稠密进度阶梯 + 定时检查点

• 一句话直觉：不只问"做完没有"，而是每隔一段时间问一次"做到哪了"。
• 生活类比：装修验收不是只看最后能否入住，而是水电、防水、瓷砖各验一次。最后没完工的项目，也能看出卡在哪一步。
• 步骤：1. 把任务的隐藏评测拆成若干逐级变难的检查项（阶梯的"台阶"）；2. 运行期间每隔 Δ 分钟，在与智能体隔离的环境中运行一次全部检查项；3. 记录每个检查点的得分 R(t)，得到一条"进度曲线"；4. 汇总时同时报告二元结果（R=1 才算过）与稠密得分。
• 公式（示意，论文未给出统一公式）：

R(t) = Σ_k  w_k · pass_k(t)        其中 Σ_k w_k = 1

• t：检查点时刻（LHTB 2.0 中为 30、60、…、180 分钟）
• k：第 k 个检查项（例如某个隐藏场景、某个精度阈值）
• w_k：该检查项的权重
• pass_k(t)：t 时刻该检查项是否通过（0 或 1，也可以是 0—1 之间的部分分）
• 示例：一个重建任务有 3 个隐藏场景、每个场景 2 级精度阈值，共 6 个检查项，每项权重 1/6。60 分钟时通过 4 项，R=0.67；180 分钟时通过 5 项，R=0.83。二元判分两次都是 0，稠密阶梯却显示出持续进展。
• 为什么有效：把一个长期稀疏的信号拆成多个可观测的中间信号，既能区分"接近完成"和"毫无进展"，也能看到进度随时间的变化，比如停滞或回退。
• 何时失效：台阶设计不当时，智能体可能刷低阶检查项而不攻克核心难点；检查项若泄露给智能体，就会变成"照着考卷答题"。LHTB 2.0 用隐藏场景和隔离评分来应对这两个问题。

三、纠错：从自己的失败里学会"回头"

3.1 CUA-Recovery：继承一个有错误的现场

问题。已有的电脑操作智能体基准几乎都从干净的初始状态开始。真实的长流程里，智能体经常要在一个已经出错的现场继续工作：可能是自己 20 步前的操作，也可能是上一个会话留下的问题。它能不能发现，能不能修好？

机制。 CUA-Recovery [3] 提出 ReRail 流水线，分四步：

1. 把 MyPCBench 的桌面任务组合成跨应用的长流程，并附带可执行的标准答案；
2. 让 6 个智能体运行，收集验证器确认的失败；
3. 对每次失败定位"根因步" t_r：最早的、未被撤销的、去掉它任务仍可完成的那一步；
4. 由专家修复其他无关错误，只保留这一个根因，再把状态回放到根因之后 d 步（d ∈ {0, 5, 10, 15, 20, 25}），作为"接手状态"交给智能体。

最终得到 100 个任务上的 2,250 个人工核验的测试状态，以及 377 个任务上的 8.6K 条训练轨迹。

实验。 6 个智能体在 6 个接手深度上，错误意识率（EAR）最高 44.0%，Pass@3 最高 25.5%。意识到错误的运行通过率为 15.6%，没意识到的为 12.2%：意识到只是第一步，大多数运行即使发现了问题，也没能修好全部后果。

一个耐人寻味的发现是：d 从 20 到 25 时，根因截图移出了 20 张截图的上下文窗口。GPT 5.5 的 EAR 从 16.2% 升到 21.0%，Pass@3 却从 25.5% 降到 18.9%；Claude Opus 4.8 的 Pass@3 从 7.7% 降到 0。错误的后果越来越显眼，所以更容易"注意到"；但源头已不在视野内，只能从下游症状倒推，所以更难修。

训练效果。用训练集微调 Qwen3.5-35B-A3B 得到 ReRail-35B-A3B，各深度平均 EAR 从 19.9% 升至 35.2%，评分细则得分从 5.0% 升至 16.1%。更有意思的是，从干净状态开始的任务也变好了：MyPCBench 上 Pass@3 从 9.2% 升至 24.5%，未见过的 Odysseys 上从 24.1% 升至 34.9%。消融实验用同一批流程、token 数对齐的成功轨迹微调，EAR 只到 23.6%，MyPCBench 只到 13.8%。

局限。场景集中在桌面环境；根因定位依赖可执行的标准答案，开放式任务难以复制；每个测试状态只保留一个根因，而真实现场往往多个错误交织。

算法拆解 2：ReRail 的"根因接手 + 渐进提示"数据合成

• 一句话直觉：与其只给智能体看"标准答案怎么做"，不如给它看"做错之后怎么救回来"。
• 生活类比：驾校只练"正常行驶"不够，还要练"车打滑了怎么修正"。打滑的场景要从真实事故里复刻，而不是凭空想象。
• 步骤：1. 收集真实失败轨迹，对照标准答案找到根因步 t_r；2. 计算错误潜伏期 h_e = t_e − t_r（t_e 为错误暴露的时刻），用于刻画"错误埋了多久"；3. 从根因后 d 步的状态开始，让模型续写恢复过程；4. 若续写失败，逐级加提示：先指出出错的步骤，再给出相互矛盾的证据，最后指出受影响的数据；5. 首个被验证器接受的续写作为训练目标，全部失败时由教师模型兜底；6. 关键一步：把提示从训练输入中删掉。模型在训练时只看到"有错的现场 → 正确的恢复动作"，必须自己学会发现问题。
• 训练目标：标准的监督微调。给定任务指令 l、带错误的历史 H_c 与验证通过的恢复轨迹 r，最大化 log p(r | l, H_c)。
• 示例（示意，非论文案例）：报销表格任务中，智能体在第 12 步把"部门"列筛选错了，到第 30 步汇总金额时才发现总数对不上。接手状态从第 22 步开始（d=10）；首轮续写没发现问题；加上一级提示（"第 12 步可能有误"）后，续写回到筛选条件、改正并重新汇总，通过验证。这条轨迹去掉提示后进入训练集。
• 为什么有效：恢复数据覆盖了成功轨迹里根本不会出现的状态分布，也就是"现场已经出错"的分布。消融实验说明，增益来自"学会恢复"，而不是更多领域数据。
• 何时失效：依赖可执行的验证器来判定"恢复成功"；如果验证器本身有漏洞（见第四节 VerifierBench），合成的恢复轨迹也会带着漏洞进入训练。

四、验证：当没有标准答案时，谁来判断对错

4.1 VeriHarness：分歧要裁决，共识要挑战

问题。长程任务的产物（一份报告、一个表格、一组代码改动）通常没有现成的标准答案。常见做法是多跑几次、取多数票，但 VeriHarness [6] 用数据说明了多数票的两种失败。研究者在 APEX-Agents 上让 Claude Opus 4.8 每题跑 10 次，做条目级统计：

• 10 次"全体一致"的数值中，34% 是错的；
• 有分歧的条目中，74% 至少有一个候选是对的；
• 但有分歧时，多数票答案只有 47% 是对的。

也就是说，多数票既会埋没正确的少数，也会掩盖一致的错误。

机制。验证者 = 同一个模型 M + 一个验证框架 H_V（工作区、证据工具、验证协议、可复用技能）。它不接触评分器、参考答案或评分细则。系统有三个角色：

• 分歧裁决者：针对候选答案不一致的条目，挑选区分度高的检查（读原文、重算、查元数据），排除与证据矛盾的候选；
• 共识挑战者：在独立上下文中，对"大家都同意"的条目主动设想可能的错法并检验，覆盖数值、解读与遗漏；
• 新上下文裁定：汇总两份证据记录，输出（基础版本，修订计划，未决事项），再生成修订后的交付物与验证记录。

实验。相对单次运行，平均提升 6.2 分（Gemini 3.5 Flash）和 6.4 分（Claude Opus 4.8）。作者公开了约 26,000 条运行记录，验证技能可以从失败反馈中自我改进。

局限。需要先有 10 次运行的候选池，成本与延迟都会成倍增加；不提供每次运行的单独评分；只研究了同一模型自我验证的设定，跨模型验证的效果尚不清楚。

算法拆解 3：用"答案熵"分流，再用证据定案

• 一句话直觉：大家意见不一，就去查证据定胜负；大家意见一致，也要派人专门挑刺。
• 生活类比：审计不是"多数会计说对就对"。账目有分歧时查原始凭证；所有人都认可的数字，也要抽样复核，因为大家可能用的是同一张错的底稿。
• 步骤：1. 同一模型独立运行 N 次（论文中 N=10），把产物拆成条目级的声明（claim）；2. 对每个条目 p，统计 N 个答案的分布 π_p，计算熵；3. H(π_p) = 0 的条目交给共识挑战者，H(π_p) > 0 的交给分歧裁决者；4. 两个角色各自执行检查，产出证据记录；5. 在新上下文中裁定，输出最终版本与修订计划。
• 公式：

H(π_p) = − Σ_a  π_p(a) · log π_p(a)

• p：一个条目，例如"FY2025 收入"
• a：该条目的某个候选答案
• π_p(a)：N 次运行中给出答案 a 的比例
• H = 0 表示所有运行答案相同（共识），H 越大分歧越大
• 示例（改写自论文图 3）：任务要求从终版财报中取 FY2025 收入。两次运行引用草稿得出 1 亿，一次引用终版得出 1.2 亿，三者都标为美元。"金额"条目：π = (2/3, 1/3)，取自然对数时 H ≈ 0.64 > 0，交给裁决者。裁决者查看版本历史，确认终版取代草稿，选定 1.2 亿。"币种"条目：三者都是美元，H = 0，交给挑战者。挑战者查看来源元数据，发现应为欧元。最终交付"1.2 亿欧元"。注意多数票会给出"1 亿美元"，金额和币种都错。
• 为什么有效：把有限的验证预算按"哪里可能错"来分配，并且用环境中的证据而不是模型的再次判断来定案。同一个模型在生成时没发现的错误，换成"带着工具专门找错"的角色后有机会发现。
• 何时失效：所有运行都没接触到正确的信息源时，裁决者无从选择；挑战者设想不到的错误类型仍会漏掉；条目拆分的粒度太粗，也会掩盖分歧。

4.2 VerifierBench：验证器本身也需要被验证

上面的方法都依赖"验证"。VerifierBench [7] 追问了一个更底层的问题：让智能体自己写可执行的验证器，靠得住吗？研究者从 6 个智能体基准中整理出 222 个任务、4,993 个隐藏测试用例（包括多种合法解法和攻击样例），并用六项检查（V4V）审核源验证器与测试集。在统一框架下评测 19 个模型，归一化平衡准确率在 10.6 到 62.1 之间。

一个关键发现是：生成的验证器"拒绝错误解"普遍比"接受正确解"做得好。这看上去像是"严格"，实际上多是"过度严格"。在分析的记录中，大部分误拒来自那些不接受任何一个被测解法的验证器：它们对输出格式、工具调用方式或代码改动做了任务没有要求的假设。这些错误还能通过自测，因为智能体用来自测的解法与验证器共享同样的错误假设。

对实践的启发：检查验证器时，不仅要看它能否拒绝错误解，还要看它是否接受任务允许的其他正确解法。

五、监督：让人看懂智能体到底做了什么

5.1 AgentMonBench 与 EBG：证据锚定的行为图

问题。用户委托了任务，责任并不随之转移。智能体中途可能"合理但需要用户拍板"地改变了一些东西，比如更换了评估标准、丢弃了不完整的记录。这类决定的证据散落在消息、工具输出和中间文件里，人很难从几百步轨迹中找出来 [5]。

基准。 AgentMonBench 设计了三个子集：

• SpecGAP：任务文档中故意省略的条件，标注一致率 92.4%（447/484）；
• SilentSwap：在代码仓库里做 5 类语义替换，例如把"精确匹配"静默换成"语义相似度"；
• FeedbackTrace：来自真实 SWE-chat 记录的用户反驳事件。

方法。 EBG（Evidence-Grounded Behavior Graph）无需训练，分三层：

1. 构图：确定性地把轨迹和仓库解析成图 G = (证据, 行为, 范围, 关系)，不调用 LLM。仓库行为按"条件—操作—结果"表示，轨迹行为按"需求—动作—响应"表示；
2. 呈现：选文件 → 从种子节点做一跳扩展 → 选组件与根节点 → 生成证据视图；
3. 监控：由监控模型基于问题与证据视图输出发现。

实验。在 8 个模型上，EBG 在大多数设置中提升了决策识别与证据定位，优于直接阅读原始上下文。作者也坦承一个反直觉的现象：证据检索变好时，模型对决策的解读能力有时反而变弱。

算法拆解 4：把轨迹压成"行为图"再交给监督者

• 一句话直觉：别让人读几百页流水账，先把"谁在什么条件下做了什么、产生了什么结果"整理成图，再按需展开。
• 生活类比：查一起事故，不是从头听完所有通话录音，而是先画时间线和因果图，再调出关键节点的原始录音核对。
• 步骤：1. 解析器 F_τ 把原始材料 X（消息、工具调用、文件差异）转成图 G；2. 每个行为节点都挂着指向原始证据的链接，保证可追溯；3. 监督问题 Q 进来后，先定位相关文件与种子节点，再做一跳扩展，得到子图；4. 把子图渲染成证据视图 V，监控模型输出 M(Q, V)。
• 形式化：

G = F_τ(X) = (E, B, S, R)
V = Present(G, Q)
Findings = M(Q, V)

• E：证据节点（原始片段）；B：行为节点；S：作用范围；R：节点间关系
• F_τ：确定性解析器，不调用 LLM，因此可复现、成本低
• Present：按问题挑选子图的呈现器；M：监控模型
• 示例（示意，非论文案例）：数据分析任务中，智能体为了让脚本跑通，删掉了含缺失值的 1,200 行记录。原始轨迹里，这只是第 87 步的一行 dropna()。在行为图中，它变成一个"条件：存在缺失值 → 操作：删除行 → 结果：样本从 N 降到 N−1200"的节点，并通过"影响范围"关联到最终报告的统计口径。监督者询问"有没有改变样本口径"时，这个节点会被直接定位出来。
• 为什么有效：确定性构图把"找证据"和"做判断"分开，减轻了监控模型在长上下文里大海捞针的负担。
• 何时失效：解析器只能识别预先定义的行为模式，新型操作可能漏掉；检索到证据之后，判断"这算不算需要用户确认的决策"依然依赖模型能力，论文观察到的"检索变好、解读变弱"就是提醒。

六、记忆与协作：记得准、改得对、配合得好

6.1 Hy-Memory：用归因强化学习训练"记忆写入者"

问题。长期运行的智能体依赖外部记忆库。写什么、改什么、删什么，决定了未来能不能答对。但"写入"的效果要很久之后才体现，奖励极其稀疏，而且一个最终分数很难分配回具体某次写入。

机制。 Hy-Memory-30B-A3B [8] 把记忆写入建模为一个马尔可夫决策过程：状态 s_t = (M_t, x_t, h)，即当前记忆库、当前输入片段与框架类型；动作作用后记忆库更新为 M_{t+1} = T_h(M_t, a_t)。训练中，策略模型（写入者）参与训练，答题模型与评判模型冻结，避免"读者变强"掩盖"写者的问题"。训练分两阶段：

• 在线策略蒸馏：教师模型对学生自己生成的轨迹打分，用 top-50 反向 KL 目标学习如何操作 Mem0、MemOS 等真实记忆框架；
• 记忆强化学习：每个窗口最多 5 个片段（每段约 10 轮对话），采样 8 条轨迹；每个片段都有局部探针问题（PRM），跨片段问题作为结果奖励（ORM）；另有陷阱题和记忆膨胀惩罚，用来堵住"什么都存"的捷径。

实验。在论文的 4 个记忆框架评测中，宏平均为 55.49%，对比 Claude Opus 5 的 54.62%。作者同时说明，主矩阵基于确定性的 20% 子样本，0.01—0.02 的差距不具统计显著性，多随机种子实验仍有待补充。

算法拆解 5：片段级奖励与片段级 GRPO

• 一句话直觉：不要用一个总分评价一整段记忆写入，而要把功劳和过错分配到每个片段的写入动作上。
• 生活类比：评价一位会议记录员，不能只看"季度末能否答出老板的问题"，而要每次会后抽查记录是否准确，季度末再看这些记录是否真派上了用场，同时扣掉"把废话也全记下来"的分。
• 公式（论文式 4—7）：

orm[t] = (1/|Q_t|) · Σ_{q∈Q_t} c_q[t]
x_t    = clip((g_t − ℓ_h) / (u_h − ℓ_h), 0, 1)
pen[t] = (e^{3·x_t} − 1) / (e^3 − 1)
s[t]   = w_prm · Σ_{k≥t} γ^{k−t} · prm[k] + w_orm · orm[t] − w_pen · pen[t]
A_{i,t} = (s_i[t] − μ_t) / (σ_t + ε)

• t：第 t 个输入片段；i：第 i 条采样轨迹
• Q_t：引用了片段 t 中证据的跨片段问题集合
• c_q[t]：评判模型给出的、问题 q 的答案复原片段 t 中金标证据的程度（0—1）
• prm[t]：片段 t 的局部探针得分
• g_t：记忆库 token 增量除以输入片段 token 数；ℓ_h、u_h：各框架的免罚阈值和满罚阈值
• pen[t]：膨胀惩罚，用指数形式让"轻微增长"几乎不罚、"大量堆积"重罚
• 权重：w_prm = 1，w_orm = 2，w_pen = 0.3，γ = 0（金标归因已经处理跨片段延迟，不再把噪声大的未来得分往回传）
• μ_t、σ_t：8 条轨迹在同一片段位置上 s[t] 的均值与标准差
• 步骤：1. 对每个窗口采样 8 条写入轨迹，每条依次处理最多 5 个片段；2. 每处理完一个片段，用探针题考察当前记忆库，得到 prm[t]；3. 窗口结束后用跨片段问题评估，按金标证据来源把结果归因到各片段，得到 orm[t]；4. 计算 s[t]，再在"同一片段位置"的 8 个值之间做归一化，得到优势 A_{i,t}；5. 选出最终记忆库最好的一条，作为下一个窗口的起点。
• 示例（示意数值）：在第 3 个片段上，轨迹 1 记下了"用户下月起改用新账户"，s=1.8；轨迹 3 没记，s=0.9；轨迹 5 把整段对话原样存入，记忆库暴涨，惩罚很重，s=0.6。片段 3 这一列的均值约 1.1，轨迹 1 的写入获得正优势而被强化，轨迹 5 被抑制。到了第 4 个片段，表现最好的可能换成了轨迹 3，各列分别比较。
• 为什么有效：标准 GRPO [11] 对整条轨迹打一个分，再把同一优势"广播"给所有写入动作。但这里 8 条轨迹只在第 0 个片段共享同一记忆库，之后各自的状态都不同，一个总分无法区分是哪次写入做对了。片段级分组把比较放在正确的决策边界上。
• 与过程监督的关系：这种做法在思路上接近过程监督 [12]，但被监督的单位不是主观的推理步骤，而是可外部验证的"记忆库后果"（作者原话的大意）。
• 何时失效：作者明确指出，这种归因基于证据而非反事实，"复原了金标事实"并不证明是某次写入导致了正确答案；跨优化步的信用会被截断，早期记忆库里的错误得不到回溯梯度；评分细则式奖励还需要人工一致性与评判模型敏感性检验。

6.2 MemDerive 与 DyadMem：记忆评测从"答没答对"走向"错在哪"

两项新基准把记忆评测的粒度推进了一步。

MemDerive [9] 关注"派生状态"：例如"哪些事项已经完成、哪些条件仍然成立"，没有任何单条记录直接写明，必须按规则从多条演化的记录中推导出来。它用 Datalog 推导金标答案并记录推导 DAG，覆盖 10 个场景、4,692 个事件、1,503 个查询。结果相当警醒：在派生状态上，被测的 4 个记忆系统都不如简单的 BM25 检索；而同一个答题模型在拿到支撑事件时准确率达 96.01%。多数失败属于"没收集到"：系统明明存着所需的中间状态，却没在需要时取出来。

DyadMem [10] 则提出"用户条件下的关系型智能体记忆"：不仅要记住关于用户的事实，还要记住"这个智能体应该如何与这位用户协作"。它包含 3,065 个片段、50,961 个会话、61,210 个问答。在 20 个模型上，给定金标记忆时问答表现稳定，走完整流水线时则大幅下降，暴露出捕获召回低、检索不完整、不安全删除等问题。

6.3 RealCLI：任务做得好，不等于配合得好

RealCLI [4] 用成对设计比较两种模式：EXEC 模式一次性给出完整需求；COLLAB 模式由脚本化用户逐步提供信息、修正、改约束、给授权。评测覆盖 5 个维度、22 个子维度、51 种交互场景模板。表现最好的配置平均得分仅 49.2%，联合协作得分上限只有 37.6%，模型在可引导性、信任校准与安全边界管理上普遍吃力。对企业而言，这一点尤其重要：真实工作中需求一定会变，"中途听得进修改"本身就是可靠性的一部分。

七、横向对比与演进逻辑

把这些工作放在一起，可以看到三条清晰的演进线索：

1. 从结果到过程。 LHTB 的稠密阶梯、MemDerive 的推导 DAG、Hy-Memory 的片段级探针，都在把"最终对错"拆成可观测的中间状态。原因很朴素：长程任务里，只有看见过程，才能定位问题。
2. 从"成功示范"到"失败利用"。 CUA-Recovery 用自己的失败合成恢复数据，VeriHarness 的验证技能从失败反馈中改进，VerifierBench 系统整理验证器的失败模式。失败轨迹正在成为一种比成功轨迹更稀缺、更有价值的数据资产。
3. 从"模型自评"到"证据定案"。 VeriHarness 要求验证建立在环境证据上，EBG 让每个行为节点都能追溯到原始片段。信任的来源，正在从"模型说它做对了"转向"有证据表明它做对了"。

八、我们的观点

观点一：长程智能体的核心问题，是"知道自己做到哪了"。 LHTB 中 92% 的完成声明出现在从未通过的运行里，CUA-Recovery 中错误意识率最高也不过 44%。这两个数字指向同一个缺陷：智能体对自身状态的估计严重偏乐观。在模型学会可靠的自我评估之前，外部检查点与独立验证是不可省略的工程环节，而不是可选的锦上添花。

观点二：多数投票不应再作为长程产物的默认验证方式。 34% 的一致错误说明，同一模型的多次运行之间存在强相关的系统性偏差，比如引用同一份错误底稿、沿用同一个错误假设。投票只能过滤随机噪声，过滤不了系统性偏差。真正有效的是"带着工具找证据"，并专门为"大家都同意"的结论设置挑战环节。

观点三：恢复数据可能是下一阶段智能体训练的关键增量。 CUA-Recovery 的消融实验很有说服力：同样的 token 预算，恢复轨迹带来的提升远大于成功轨迹，而且还改善了从零开始的任务表现。我们推测，原因在于恢复数据教会了模型"检查—怀疑—回溯"的习惯，这种习惯在顺利的任务中同样有用。

观点四：长程任务的成本结构，要求"止损"成为一项能力。第三小时的解贵 8 倍，83%—99% 的钱花在没解出的任务上。这意味着，判断"何时该停、何时该求助"的价值，可能不亚于"再多做一步"。目前的研究对此关注还不够，这是一个值得投入的空白。

观点五：可监督性将成为企业采纳智能体的门槛条件。 EBG 和 RealCLI 揭示的是同一件事：企业要的不仅是结果，还要知道中间做了哪些需要拍板的决定，并且在需求变化时能及时纠偏。在金融等强监管行业，这种要求会更早、更硬地落地。

九、未来展望

9.1 未来 6—12 个月

• 评估标准化：稠密进度、定时检查点、虚假完成率、错误意识率等指标，可能成为长程基准的标配。只报告"完成率"的论文，说服力会下降。
• 恢复数据工程化：类似 ReRail 的"失败收集—根因定位—恢复合成"流水线，预计会被更多团队复用到代码、浏览器、办公等场景。
• 验证框架产品化：裁决者 + 挑战者的模式门槛不高，很可能以"验证技能包"或独立验证智能体的形式出现在主流智能体框架中。
• 记忆评测细粒度化：从"答对率"转向"捕获、更新、检索、删除"分环节诊断，派生状态与关系记忆会成为新的评测热点。

9.2 未来 1—3 年

• 自我评估能力进入训练目标：模型对"我做到哪了、我是否可能出错"的估计，可能会像今天的推理能力一样被专门训练和评测。
• 从单智能体验证到跨模型制衡：同一模型自我验证的上限受限于共享的偏差，跨模型或跨框架的验证、以及人机混合验证，值得系统研究。
• 成本感知的长程规划：结合检查点得分曲线做动态预算分配，在"继续投入"和"止损求助"之间做出有依据的决策。
• 行为可审计成为合规要求：在金融、医疗等行业，"智能体做了哪些需要人工确认的决定"可能被写入内控与监管要求，类似行为图的结构化轨迹会成为基础设施。

9.3 对金融与风控的含义

金融风控的典型长程任务，包括贷前尽调材料整理、贷后预警排查、策略回测与模型迭代、监管报送核对等，恰好具备本文讨论的全部难点：链条长、中间状态多、错误潜伏期长、对可追溯性要求高。VeriHarness 论文本身选用的示例，就是"从终版财报中取收入并核对币种"，这正是信贷分析中的高频动作。可以预见，金融场景会是长程可靠性技术较早落地、也较早被严格检验的领域之一。

十、落地启示

结合我们在风控决策与智能建模上的实践，给正在引入智能体的金融团队五条建议：

1. 先建尺子，再上智能体。为每类任务定义可分级的中间检查项（例如尽调报告中的"主体信息核对""财务数据取数""关联关系梳理"），并设置定时检查点。没有过程指标，就无法判断智能体是在推进还是在打转。
2. 对关键数字实施"分歧裁决 + 共识挑战"。涉及金额、币种、口径、日期的字段，不要依赖单次运行或多数票。对一致的结论也要抽查来源元数据与版本，草稿与终版之争、币种错标都是真实存在的风险。
3. 收集并利用自己的失败案例。把业务中智能体出错的轨迹沉淀下来，标注根因与恢复方式，作为后续微调或提示改进的素材。这比只积累成功案例更有价值。
4. 把"需要人确认的决定"显式化。删除样本、更换口径、放宽阈值这类操作，要求智能体在执行前后生成可追溯的记录，并在监控视图中单独标出，满足模型风险管理与审计的要求。
5. 设置止损规则。依据检查点得分曲线，为长任务设置"若 N 分钟内无进展则暂停并求助"的规则，避免把预算大量消耗在无解的尝试上。

弘犀智能在风控建模中一直强调"可解释、可验证、可回溯"。这三点在智能体时代并未过时，反而更加重要：智能体越能干，越需要一套让人信得过的过程证据。

结语

长程智能体的进步，正在从"会不会做"转向"靠不靠得住"。10 月的这批研究给出了一个共同答案：可靠性不能只靠模型变强来换取，而需要更细的尺子（稠密进度与检查点）、更好的数据（来自失败的恢复轨迹）、更扎实的验证（基于证据而非投票）、更透明的轨迹（行为图），以及更准确的记忆。对于金融这样容不得"差不多"的行业，这些能力决定了智能体能否从演示走向生产。

参考文献

1. [1] Yuan, M., Zhou, Z., Xiong, X., et al. OSWorld 2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks. arXiv:2606.29537, 2026-06-28（背景）. https://arxiv.org/abs/2606.29537
2. [2] Li, Z., Li, Z., Shi, Y., et al. (incl. Mi, H.). Long-Horizon-Terminal-Bench 2.0: Automating Diverse Task Construction and Measuring Sustained Agent Progress. arXiv:2610.14146, 2026-10-09. https://arxiv.org/abs/2610.14146
3. [3] Hu, X., Li, H., Wang, Y., et al. CUA-Recovery: Benchmarking Error Recovery in Long-Horizon Computer-Use Agents. arXiv:2610.27645, 2026-10-20. https://arxiv.org/abs/2610.27645
4. [4] Liu, Y., Wang, P., Wang, B., et al. RealCLI: Toward a Unified Evaluation of Human-Agent Collaboration for CLI Agents. arXiv:2610.22507, 2026-10-15（据摘要）. https://arxiv.org/abs/2610.22507
5. [5] Sun, Z., Yan, J., Zhao, H., et al. What Did the Agent Actually Do? Evidence-Grounded Oversight for Long-Horizon Agents. arXiv:2610.06406, 2026-10-05. https://arxiv.org/abs/2610.06406
6. [6] Zhang, C., Han, R., Wang, Z., CuiZhu, Z., Collier, N., Pfister, T., Lee, C.-Y. VeriHarness: Scaling Agentic Verification for Long-Horizon Tasks. arXiv:2610.00972, 2026-10-01. https://arxiv.org/abs/2610.00972
7. [7] Yin, J., Chen, Z., Wang, H., Sun, Y., Jin, Z., Song, D., Zhang, D. VerifierBench: Benchmarking the Generation of Executable Verifiers for LLM Agents. arXiv:2610.28679, 2026-10-19（据摘要）. https://arxiv.org/abs/2610.28679
8. [8] Fei, T., Kang, J., Zheng, M., He, X., Yu, X. Hy-Memory-30B-A3B: Attributed Reinforcement Learning for Long-Term Memory Writing. arXiv:2610.22196, 2026-10-15. https://arxiv.org/abs/2610.22196
9. [9] Gao, S., Li, Y., Chen, H., et al. MemDerive: A Diagnostic Benchmark for Agent Memory over Evolving Data. arXiv:2610.25373, 2026-10-18（据摘要）. https://arxiv.org/abs/2610.25373
10. [10] Tao, Y., Zhong, X., Zhao, H. H., et al. DyadMem: A Long-Term Memory Benchmark of How Agents Work with Users. arXiv:2610.03020, 2026-10-02（据摘要）. https://arxiv.org/abs/2610.03020
11. [11] Shao, Z., Wang, P., Zhu, Q., et al. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models（GRPO 出处）. arXiv:2402.03300, 2024-02-05（背景）. https://arxiv.org/abs/2402.03300
12. [12] Lightman, H., Kosaraju, V., Burda, Y., et al. Let's Verify Step by Step（过程监督）. arXiv:2305.20050, 2023-05-31（背景）. https://arxiv.org/abs/2305.20050

弘犀研究 · 前沿 AI 深度综述 · 弘犀智能