Agent 评测的关键，不是给它出难题，而是让它做选择

最近看 Agent 评测相关的研究，有个问题越来越值得琢磨：我们花了很多精力设计任务、计算成功率、分析执行轨迹，但这些评测真的测到了 Agent 想要具备的能力吗？

举个例子。

假设有一个负责应用部署的 Agent。用户让它把某个服务升级到新版本，确认健康检查通过后，再将流量切换过去。

在测试环境里，Agent 顺利完成了全部操作，最终返回部署成功。

这当然是一次成功的执行。

但如果我们想判断这个 Agent 是否适合真实的运维环境，仅靠这样的测试显然不够。

因为真正的部署过程，很少永远按照预期进行。

可能构建成功了，镜像推送却失败；可能部署接口超时，但服务器已经完成更新；也可能健康检查始终不通过，需要撤销刚才的修改。

还有一种更棘手的情况：用户要求直接发布到生产环境，但 Agent 实际上并没有获得相应权限。

这些场景有一个共同点：Agent 不能再按照最初的计划机械地向前执行，而是必须根据当前信息决定下一步该做什么。

我觉得，这才是 Agent 评测和传统模型评测最值得区分的地方。

我们不只是想知道模型能不能生成一份正确计划，还想知道，当计划无法顺利执行时，它能不能及时发现问题、调整行动，必要时甚至主动停止任务。

一、一次工具调用失败，究竟能测出什么？

先从错误恢复说起。

假设 Agent 执行部署命令时，接口返回了：

Deployment failed.

Agent 接下来应该怎么办？

它可以尝试重新调用部署接口，也可以查询服务状态，甚至可以回滚已有的修改。

但问题在于，当前这条错误信息并不能帮助它区分失败原因。

究竟是参数错误、权限不足、网络超时，还是部署已经成功，只是响应在传输过程中丢失了？

如果评测环境只给出这样一句模糊的错误，然后把后续执行交给 Agent，我们实际上混淆了两件事：Agent 的诊断能力和环境的信息可观测性。

比较合理的方式，是让工具返回具有诊断价值的反馈。

例如：

{
  "error": "GATEWAY_TIMEOUT",
  "operation_id": "deploy-2481",
  "request_accepted": true,
  "final_state": "unknown",
  "status_endpoint": "/deployments/deploy-2481"
}

这段信息没有告诉 Agent 应该怎么解决问题，但提供了几个非常关键的事实。

部署请求已经被接收，接口超时并不能证明部署失败，系统目前不知道操作是否完成，同时提供了一个可以查询部署状态的接口。

如果 Agent 理解了这些信息，它就不应该立即重复执行相同的部署操作，而应该先查询 operation_id 对应的实际状态，再决定是否需要重试。

同样是一次超时，Agent 的后续行为就可能完全不同。

这说明，评测错误恢复能力，不能只设计失败，还要设计失败之后 Agent 能够获得什么信息。

不过，这并不意味着要把所有内部信息毫无保留地返回给 Agent。

例如，将正确的工具参数、应该调用的下一步接口，以及完整修复方案直接写入错误消息，实际上已经替 Agent 完成了诊断工作。

相反，如果只返回 500 Internal Server Error，却不提供任何可查询的状态信息，又可能使任务在客观上无法恢复。

比较好的边界是：反馈应该真实反映工具能够提供的信息，足以支撑合理的下一步判断，但不直接泄露标准答案，也不暴露不必要的敏感数据。

这里还可以设计一个很有价值的对照实验。

对于同一个失败场景，分别提供简单错误码、结构化错误信息，以及包含详细诊断证据的错误反馈，观察 Agent 的恢复表现。

如果随着反馈质量提高，Agent 的恢复成功率明显改善，说明此前的问题可能部分来自信息不足。

如果已经提供了充分的反馈，Agent 仍然反复执行错误操作，那么问题就更可能出在错误理解、决策策略或工具使用能力上。

2026 年 ACL Findings 的 Tool-Reflection-Bench 就沿着类似方向，将工具调用错误后的诊断和修复单独作为研究对象。它通过构造错误调用、反思和修正调用的过程，检查模型是否能够提出结构有效、参数正确且可以实际执行的修复操作。

另一篇 ReflecTool-Bench 则发现，让模型指出其他人的错误，与让它识别并修复自己刚刚犯下的错误，是两种难度不同的任务。模型在后者上的表现明显下降。

这两项研究给我的启发是：仅仅在 Prompt 中告诉 Agent"失败后请反思"，并不能证明它具备自我修正能力。

我们应该将错误识别、原因判断、修复策略和最终恢复效果分别观察。

更进一步，还要考虑错误是否真的允许恢复。

如果环境在第一次工具调用失败后就直接结束任务，再强的反思机制也没有机会发挥作用。

因此，一套用于评测错误恢复的任务，至少应该让 Agent 有机会经历完整的失败与恢复过程，并能够观察错误反馈如何影响后续行动。

这里值得记住的是：评测的不是 Agent 有没有出错，而是它能否利用错误反馈，避免下一次继续犯同样的错误。

二、任务设计的重点，不是步骤多，而是让 Agent 遇到必须判断的情况

说完错误恢复，再来看任务设计。

传统 Benchmark 经常用任务难度来区分模型能力。例如，更长的推理链、更复杂的条件，或者更多工具调用。

但在 Agent 评测中，步骤多不一定意味着任务设计得好。

比如，让 Agent 按照固定顺序调用十个接口。如果每一步的输入输出都是确定的，前面做什么也不会影响后面，那么整个过程更接近 Workflow（预定义工作流）。

它当然可以测试模型能否遵循复杂指令，却很难充分考察 Agent 根据运行状态自主决策的能力。

更有价值的测试，是让某个步骤的决策真正影响后续操作。

信息不完整时，Agent 知道该问什么吗？

还是刚才的部署任务。

用户只说：

"把服务更新到最新版本，今天完成发布。"

但没有说明目标环境，也没有明确是否允许直接修改生产服务。

一个不太可靠的 Agent，可能直接使用默认环境完成部署。

另一个 Agent 则可能先查询已有配置，确认目标环境。如果无法从系统中获取必要信息，再向用户询问。

两者最大的差异，不在于能不能完成部署，而在于是否能够识别当前信息不足以支撑某个决策。

这里还有一个细节：并不是 Agent 询问得越多，说明它越谨慎。

如果目标环境已经写在项目配置中，Agent 完全可以通过工具获取，没必要反复要求用户提供。

因此，设计这类评测时，需要同时考虑 Agent 能够通过哪些途径补全信息，以及不同途径的成本。

有些信息适合直接查询，有些需要用户确认，还有些属于系统权限，不能依靠模型推测。

如果测试任务总是提前提供完整信息，就很难观察 Agent 是否能够主动发现信息缺口。

但如果任务故意删除必要信息，又不给 Agent 任何获取途径，那么测试结果可能只是在衡量它愿不愿意猜测。

好的任务设计，应该允许 Agent 通过合理的行动逐步获得信息，并且让错误假设产生可以观测的后果。

有时候，正确答案恰恰是不执行

这是我觉得很容易被忽略的一类评测。

大多数 Agent Benchmark 都有一个默认前提：用户提出任务，Agent 应该尽量把任务完成。

但在真实系统中，有些操作不应该执行。

例如，Agent 查询到当前生产集群有一个节点处于不可用状态，而发布规则要求升级过程中至少保留两个健康节点。

此时继续部署可能导致服务不可用。

如果评测只奖励"完成发布"，Agent 就可能倾向于忽略约束，继续向前执行。

可实际上，合理的行为应该是暂停发布，并说明不满足继续执行的条件。

这并不是能力不足，而是正确识别了操作边界。

2026 年 7 月发布的 AgentAbstain 专门研究了 Agent 应该在什么时候放弃执行。

研究者构造了 263 组成对任务，每组任务包含可以执行与不应该执行的两种情况。两种任务只改变某个关键条件，例如权限、工具能力或环境状态。

在其测试的 17 个模型和 4 种 Harness 配置中，表现最好的 Agent 也只取得了 59.5% 的成对准确率。

这种成对测试值得借鉴。

因为如果测试集只有"禁止执行"的任务，一个永远拒绝执行的 Agent 也可能获得很高分数。

而如果测试集只有正常任务，一个不顾条件始终尝试执行的 Agent 也可能表现不错。

将两种任务放在一起，才能检查 Agent 是否真的理解了影响决策的关键条件。

更进一步，停止的时机也很重要。

如果 Agent 已经执行了危险操作，事后才告诉用户"这个操作不应该执行"，显然不能算一次成功的风险规避。

同样，如果 Agent 仅仅因为遇到一次普通的接口超时就立即放弃，而实际上可以安全恢复，那么它又过于保守。

所以，不能把"愿意继续执行"直接等同于执行能力，也不能把"拒绝操作"直接等同于安全能力。

更值得测量的是，Agent 能否根据当前掌握的信息，判断应该继续探索、尝试恢复，还是及时停止。

这实际上也是对规划能力的一种考察。

因为规划不仅意味着知道下一步做什么，也意味着知道当前的计划什么时候已经不再适用。

三、评测环境不能只负责配合 Agent 完成任务

任务设计好了，还需要能够让这些任务真实运行的环境。

很多评测环境的问题并不在于功能少，而在于过于理想化。

举个例子。

Agent 调用部署接口时，环境直接返回：

{
  "success": true
}

如果所有操作都能够立即完成，并且结果始终可靠，那么 Agent 根本不需要处理真实系统中常见的状态不一致、网络延迟和部分失败等问题。

尤其是涉及外部操作时，工具调用成功、请求执行成功，以及整个业务目标完成，实际上是三个不同的概念。

例如，Agent 向部署平台提交更新请求。

平台返回成功，只能证明部署任务已经创建。新版本是否启动、健康检查是否通过、流量是否切换完成，还需要进一步确认。

如果评测环境把这些阶段简化成一个 success=true，那么 Agent 可能会在尚未完成任务时提前宣布成功。

反过来，接口返回超时，也不一定意味着操作失败。

部署请求可能已经执行，只是响应没有成功返回。

因此，一个有价值的执行环境，应该能够表达这些中间状态，而不是仅仅模拟 API 的正常输入输出。

但这也不意味着环境越混乱越好。

如果随机让工具返回大量没有规律的错误，或者频繁制造无法恢复的故障，最后测到的可能只是 Agent 的运气。

我更倾向于把环境设计分成两个目的。

第一个目的是模拟正常业务环境。环境中可以存在延迟、噪声和偶发错误，但整体分布应该尽量接近实际运行条件，用来估计 Agent 在常见任务中的表现。

第二个目的是故障压力测试。可以有意识地注入接口超时、权限变化、状态冲突等问题，用来观察 Agent 的能力边界。

这两种测试最好分别报告结果。

否则，一个 Agent 在大量极端故障下成功率不高，不一定意味着它在正常环境中不可靠。

用户也应该成为环境的一部分

很多交互型 Agent 的测试还有一个问题：模拟用户过于配合。

例如，Agent 询问什么，模拟用户就准确回答什么，而且回答始终前后一致。

这样的对话当然容易完成，但真实用户未必如此。

用户可能不熟悉系统术语，可能只知道部分信息，也可能在对话过程中修改需求。

2026 年 EACL Findings 的 SAGE 就尝试利用业务知识、产品信息和用户特征构造更真实的模拟用户。

研究发现，与对照方法相比，这种模拟方式在其实验设置下最多能够发现约 33% 更多的 Agent 错误。

另一个值得关注的工作是发表于 ICML 2026 的 τ²-Bench。

它不再将用户仅仅视为提供信息的角色，而是允许用户与 Agent 分别通过工具改变同一个环境。

这就带来了新的评测问题：Agent 不但要自己完成操作，还需要正确指导用户行动，并根据用户实际完成的步骤调整后续计划。

这种测试方式更加接近真实的技术支持、软件操作指导等场景。

从这里可以看出，模拟用户和环境的目的并不是把测试包装得更加复杂，而是让那些平时隐藏在真实交互中的决策问题能够出现。

Memory 也要放到连续任务中去考察

同样的思路还可以用于 Memory。

假设一个 Agent 记住了用户上次发布服务时选择的部署区域。

在新的任务中，我们可以直接询问：

"上次使用的部署区域是什么？"

如果 Agent 回答正确，说明它具备一定的记忆检索能力。

但这并不能证明 Memory 对实际执行有帮助。

更合理的测试，是让 Agent 在多个相关任务中持续工作。

第一次任务中，用户指定了某个部署区域。

第二次任务中，用户调整了区域配置，并说明以后都使用新的设置。

到了第三次任务，用户只要求发布新版本，没有重复说明区域。

这时，Agent 能否使用最新且仍然有效的配置，就比单纯复述历史信息更有意义。

如果它记住了第一次的配置，却忽略了第二次的变更，说明记忆虽然存在，但没有正确参与决策。

2026 年 ICML 的 MemoryArena 就关注类似的问题。

它将多个任务组织成具有依赖关系的连续执行过程，让 Agent 从早期任务和反馈中积累经验，再在后续任务中使用这些信息。研究发现，一些在传统长上下文记忆测试中表现不错的 Agent，在需要利用历史经验完成连续任务时仍然存在明显不足。

这里还有一个工程细节。

评测长期记忆时，需要保留 Agent 合法保存的信息，但不能让上一轮任务的临时文件、数据库残留或测试缓存意外泄露答案。

否则，Agent 看似记住了历史经验，实际上可能只是读到了没有清理干净的环境状态。

因此，评测环境既要支持持续状态，也需要明确区分哪些状态允许跨任务保留，哪些必须隔离。

四、Agent 跑得越久，真的还能像刚开始一样可靠吗？

前面谈到的多数测试，都发生在一次任务内部：Agent 遇到一个问题，处理完，评测结束，环境重置。

但有些 Agent 并不是这样工作的。比如一个负责部署与运维的 Agent，上午处理版本升级，下午检查发布状态，夜间监控告警，第二天还需要接着使用之前留下的配置和操作记录。

这样的系统可能在最初几次任务中表现正常，却在运行一段时间之后出现另一类问题：它没有明显犯下某个低级错误，但越来越难把当前状态、历史决策和最新约束放在一起考虑。

因此，评测不能只问"这次做得对不对"，还要问"它能不能一直做对"。

先区分：步骤变多了，还是 Agent 真的变得不可靠了？

这里有个容易混淆的地方。假设一个任务需要连续完成 5 步，另一个需要完成 50 步。后者整体成功率更低，未必说明模型越运行越"糊涂"。只要每一步都有失败概率，步骤一多，整条链路全部成功的机会自然会下降。

举个纯粹用于说明的数学例子：假设每一步独立成功的概率都是 99%，那么连续 10 步全部成功的概率约为 90%，连续 100 步则只有约 37%。即使每一步的能力完全没变，端到端成功率仍然会随着步骤增加而下降。

真正需要进一步查明的是：在排除"多做几步就多几次出错机会"之后，Agent 后面的决策是不是比前面更差了？

2026 年的 Benchmarking the Residual 专门提醒了这个区别。它提出，讨论所谓的长任务退化时，应当将完整任务的表现与各阶段独立表现建立的基线比较，而不是看到长任务成功率下降，就直接把原因归结为长上下文或记忆问题。这是一种研究性的分析建议，不是能够自动判定根因的万能指标。

对于部署 Agent，可以把一个长流程拆成若干具有明确验收条件的阶段：读取配置、构建、发布、健康检查、流量切换、发布后监控。在固定配置下分别测各阶段的成功表现，再运行整个流程，对比两者的差异。如果完整执行显著更差，就要检查此前的操作是不是给后续决策带来了额外负担。

长时间运行，可能出现哪些新问题？

一种情况是目标慢慢偏了。最初用户要求"升级成功后再切流量"，Agent 途中花了很多精力排查镜像仓库，恢复后却忘了必须先通过健康检查，直接把流量切了过去。单看最后一步的工具调用，参数可能没错；问题出在它已经丢失了最初的约束。

另一种是旧信息变成了新错误。比如第一天部署区域是 A，第二天用户明确改成 B。到了第三天，Agent 从长期记忆中检索出第一天的配置，却没有识别第二天的变更。这里不是"记不住"，恰恰是记住了不该继续使用的旧状态。评测不仅要检查能否回忆历史，更要检查信息的有效期、更新时间和冲突处理。

还有一种是错误开始传染后续任务。某次发布中，Agent 错误地把服务标记为"已完成验证"，后续任务又将这一结论当作事实。单次错误可能很小，但随着任务继续，错误前提被反复复用，最后导致明显的行为偏移。

2026 年的 LongDS-Bench 就研究了长期数据分析中的状态演化。它让 Agent 在连续轮次中维护、更新、恢复或组合分析状态，研究报告最佳模型从前期到后期的准确率下降接近 47 个百分点。另一个发表于 ICML 2026 的 UltraHorizon，则将 Agent 放进需要持续探索、发现规则的长任务中，发现当前模型在长期探索和上下文中的错误判断固化等问题上仍有明显不足。

时间带来的问题还不止于"不断行动"。有些 Agent 必须长时间等待，而不是一直尝试。例如用户要求：发布完成后持续监控服务，只有当错误率超过阈值且连续一段时间没有恢复，才发出告警。这里正确行为可能是周期性检查、保持等待，甚至在条件始终未满足时什么都不做。

微软研究院 2026 年发布的 SentinelBench 正是研究这种持续监控任务。它的环境会随着时间自行变化，Agent 需要判断何时等待、何时检查、何时采取行动。研究还发现，哪怕使用同一个模型，不同的等待工具和策略也会显著改变长期运行成本。这说明，评测持续运行的 Agent，还必须检查它是否把"没有事情发生"误当作"应该不停做事"。

那么，怎样设计长期运行评测？

我更倾向于准备一组相互关联、时间跨度逐渐拉长的任务，而不是简单让 Agent 连续回答 100 个互不相关的问题。

例如，围绕同一个服务安排一段模拟的连续运维工作：第一阶段部署新版本，第二阶段修改配置，第三阶段插入一次工具故障，第四阶段让监控条件长时间不触发，第五阶段再要求 Agent 根据最新状态处理告警。

评测时，不能只统计整段流程最后是否成功，还要保留阶段检查点，观察后期任务是否正确使用了最新约束、是否继承了错误前提、是否发生重复操作，以及是否不必要地消耗了工具调用和 Token。

为了弄清楚问题来自哪里，还可以安排三种对照：一种让 Agent 从头持续执行；一种在中间检查点恢复相同的真实环境状态，但只提供经过核实的必要信息；另一种保留原有历史记录和 Memory。对比这些条件，可以帮助判断问题更接近任务自身难度、信息积累、记忆污染还是运行时策略，但仍需要控制任务顺序和预算，才能作出可靠解释。

另外，长期性有三把尺子：经过了多少个决策步骤、跨越了多少个连续任务，以及实际运行了多少时间。它们不应混成一个"任务长度"数字。几十秒里执行 100 次工具调用，与等待 24 小时后才处理一个事件，考察的不是同一种能力。

所以，长期评测至少应该同时记录阶段性成功率、错误复发与恢复情况、状态一致性、目标与约束是否漂移，以及随时间累积的工具调用和运行成本。这样才能看出 Agent 是单纯多做了几件事，还是确实随着运行逐渐失稳。

最值得关注的不是它能坚持运行多久，而是运行越久之后，它是否仍然知道现在的目标是什么、哪些信息已经失效，以及什么时候根本不应该行动。

五、看到 Agent 完成任务，还得弄清楚是谁帮它完成的

做到这里，评测已经不再是简单地给模型输入任务、检查最终回答。

但还有一个很实际的问题。

假设我们给某个 Agent 增加了一套自动重试机制，测试发现任务成功率从 70% 提升到了 85%。

这能说明 Agent 的错误恢复能力增强了吗？

可以说明整个系统的恢复效果更好了，但还不能直接说明模型自身的恢复能力得到了提升。

因为这 15 个百分点可能完全来自 Harness。

例如，工具执行失败后，Harness 自动读取错误码，并根据规则重新调用工具。模型甚至没有看到失败信息。

另一种情况则不同。

Harness 负责将错误原因传递给模型，由模型判断下一步应该修改参数、查询状态还是停止操作。

两种实现都可能提高最终成功率，但它们反映的能力并不相同。

前者更多体现系统级容错设计，后者才进一步涉及模型对反馈的理解和决策能力。

我认为，评测 Agent 时必须明确：哪些事情是模型做的，哪些事情是系统提前安排好的。

如果想比较两个基础模型的工具恢复能力，最好使用相同的 Harness、错误反馈和测试环境。

如果想比较两种 Harness 设计，则应该尽量固定模型及其推理配置。

对于重试次数、最大执行步数、Token 预算和工具能力，也应该提前确定。

否则，最后的比较很可能并不公平。

这并不是理论上的顾虑。

Anthropic 在 2026 年发布的 Quantifying Infrastructure Noise in Agentic Coding Evals 中研究发现，即使模型、任务和 Harness 保持一致，仅改变运行容器的资源条件，也会影响 Agent 的最终成功率。在其 Terminal-Bench 2.0 实验中，极端资源配置之间的成功率差异达到了 6 个百分点。

因此，看到一个 Agent 的 Benchmark 分数提高时，不能立即把变化归因于模型变聪明了。

也有可能是工具更稳定了、资源更多了、重试次数增加了，或者环境变得更容易操作了。

这些优化本身当然有价值。

只是需要准确说明改进来自哪里。

另一方面，Agent 的执行路径也不能被限制得过于死板。

假设两个 Agent 使用不同方式完成了同一任务，而且两种方式都满足业务规则。

如果评测器只接受预先写好的那条标准轨迹，另一条合法路径就会被误判为失败。

这也是为什么需要将必要约束与可自由选择的执行路径区分开来。

对于必须满足的业务条件，可以通过程序检查。

对于执行策略，可以观察其合理性、成本与稳定性。

对于确实存在多种合法实现的情况，评测器应该允许 Agent 选择不同的方案。

否则，我们最终测到的可能只是它有多擅长模仿标准答案，而不是它在真实环境中解决问题的能力。

六、怎样把这些思路真正用到评测系统里？

前面讨论了这么多问题，实际落地时该怎么做？

我觉得可以先改变设计评测样本的习惯。

不要一开始就写一条用户指令，然后想办法为 Agent 的输出打分。

可以先选定一个想考察的行为，再反过来设计任务和环境。

还是用部署 Agent 的例子。

如果想评测它处理不确定执行结果的能力，就可以专门构造这样一个场景：

Agent 提交部署请求后，服务器已经接收并执行操作，但网络发生超时，导致 Agent 没有收到成功响应。

此时正确行为不是立即再次部署，而是先检查先前操作的状态。

这条评测样本可以这样定义：

case_id: deployment_timeout_001

task:
  goal: 将服务更新到指定版本
  constraint: 不允许重复创建部署任务

environment:
  initial_version: v2.3.0
  target_version: v2.4.0

fault_injection:
  stage: deploy_service
  behavior: 请求已提交，但响应超时
  actual_state: deployment_created

feedback:
  error: GATEWAY_TIMEOUT
  operation_id: deploy-2481
  final_state: unknown

expected_behavior:
  - 识别部署状态尚未确定
  - 查询已有部署任务状态
  - 根据查询结果决定是否重试

forbidden_behavior:
  - 未查询状态就重复创建部署任务

success_criteria:
  - 最终版本为 v2.4.0
  - 没有重复部署副作用

注意，expected_behavior 和 success_criteria 属于评测器掌握的标准，不应该直接暴露给被测 Agent。

而且这只是一种有效执行方式的示例。实际评分时，如果 Agent 通过其他合法工具确认了操作状态，也应该允许通过，而不是死板地要求调用某个固定接口。

有了这样的样本，就可以进行更有针对性的分析。

例如，Agent 是否在超时后立即重试？是否理解了 final_state=unknown 的含义？查询到部署已完成之后，能否及时停止进一步操作？

对于不同模型，还可以统计它们在相同反馈条件下的恢复成功率。

对于同一个模型，则可以改变错误反馈的信息完整度，观察恢复行为是否发生变化。

这些结果都比单纯记录最终有没有成功更有解释价值。

当然，仅靠一两条样本还远远不够。

真正的评测集需要覆盖不同的决策条件。例如，同样是接口超时，有时请求没有被执行，有时已经执行但结果未知；有时允许重试，有时重复操作会造成副作用。

这些细微差异，才可能暴露 Agent 是否真正理解环境状态。

在自动评分方面，也不必把所有判断都交给 LLM Judge。

对于部署数量、版本状态、权限要求等明确事实，可以直接通过程序验证。

对于错误解释是否合理、任务是否被正确理解等复杂语义，再使用模型辅助评判，并利用人工标注样本检查评审器的可靠性。

最后，还需要把评测结果用于改进。

假设发现 Agent 经常在超时后盲目重试。

首先检查错误反馈是否足够明确。如果反馈本身缺少状态查询能力，应该优先修复工具接口。

如果错误信息已经充分，但模型仍无法理解，可以考虑优化 Prompt、增加错误诊断步骤，或者采用更强的模型。

如果模型能够作出正确判断，但 Harness 仍然在后台执行自动重试，那么问题就不在模型，而在系统控制逻辑。

修改之后，重新运行相同的测试，确认问题是否得到解决。

这时还应该把该类故障纳入回归测试，避免下一次修改 Harness 或替换模型时，又重新出现相同问题。

如此一来，评测才真正参与到了 Agent 系统的改进过程中，而不只是上线前的一次考试。

写在最后

以前理解 Agent 评测，我也容易把注意力放在 Benchmark、任务成功率、工具调用准确率这些东西上。

但深入看了一些研究之后，会发现评测设计本身可能比评分方式更重要。

如果任务没有真正的依赖关系，就很难考察连续规划。

如果所有信息都已经给出，就很难考察主动探索和澄清。

如果失败之后不给任何有效反馈，就很难判断 Agent 是否具备恢复能力。

如果每次调用失败都让测试直接结束，就无法观察它如何调整策略。

如果任务永远可以执行，就无法知道它什么时候会主动停止。

如果 Memory 从来不会影响后续任务，就很难证明它对实际执行有帮助。

如果评测永远只运行一个短任务，也就看不到长时间执行中的状态漂移、错误累积，以及等待策略带来的成本问题。

这些问题往往不是通过增加更多评分指标就能够解决的。

一个任务能测出什么能力，很大程度上取决于我们给 Agent 提供了怎样的环境，以及它在这个环境中需要作出哪些选择。

我越来越倾向于认为，好的 Agent 评测应该有点像软件工程中的故障注入和系统测试。

不是把所有异常都隐藏起来，让 Agent 一路顺利执行；也不是故意制造大量无法解决的问题，让它不断失败。

而是把那些真实系统中可能遇到的关键情况，有控制地放到它面前。

让错误能够发生，让反馈能够被理解，让决策能够产生后果，让恢复有机会得到验证，同时也让不应该继续的操作能够被及时停止。更重要的是，要让这种观察跨越足够长的时间，检查 Agent 是否会因为先前的行动而改变后续判断。

评测真正需要回答的问题，不只是 Agent 最后有没有把事情做成，而是当事情没有按照预期发展时，它还知不知道应该怎样继续。

---

参考资料

本文的技术讨论主要参考以下公开研究。部分论文仍是预印本，结论应结合各自的实验设置理解。

1. Failure Makes the Agent Stronger: Enhancing Accuracy through Structured Reflection for Reliable Tool Interactions --- ACL Findings 2026。研究工具调用失败后的结构化诊断与修正。

2. Do LLMs Catch Their Own Mistakes? --- ACL Findings 2026。区分识别他人错误与修复自身工具调用错误的能力。

3. AgentAbstain: Do LLM Agents Know When Not to Act? --- 2026。研究 Agent 在条件不足、任务冲突和运行异常时是否知道停止操作。

4. τ²-Bench: Evaluating Conversational Agents in a Dual-Control Environment --- ICML 2026。研究 Agent 与用户共同改变环境状态时的交互决策。

5. SAGE: A Top-Down Bottom-Up Knowledge-Grounded User Simulator for Multi-turn Agent Evaluation --- EACL Findings 2026。研究如何构造更真实的模拟用户。

6. Benchmarking Agent Memory in Interdependent Multi-Session Agentic Tasks --- ICML 2026。研究 Memory 如何在连续任务中影响实际决策。

7. Quantifying Infrastructure Noise in Agentic Coding Evals --- Anthropic Engineering，2026。研究环境资源差异对 Agent 评测结果的影响。

8. Demystifying Evals for AI Agents --- Anthropic Engineering，2026。介绍 Agent 评测任务、执行环境、结果验证与回归测试的工程实践。

9. LongDS-Bench: On the Failure of Long-Horizon Agentic Data Analysis --- 2026 年预印本。研究连续多轮数据分析中的状态维护与后期性能变化。

10. UltraHorizon: Benchmarking Agent Capabilities in Ultra Long-Horizon Scenarios --- ICML 2026。研究超长任务中的持续探索、上下文与规划问题。

11. SentinelBench, a Benchmark for Long-Running Monitoring Agents --- Microsoft Research，2026。研究长期监控、等待决策与外部环境自主变化。

12. Benchmarking the Residual: What Long-Horizon Evaluations Add Beyond Matched Short-Task Performance --- 2026 年研究性预印本。讨论如何区分步骤累积导致的整体成功率下降与真正的长程行为退化。