Agent 任务失败后，怎样找到值得改的地方？

Agent 任务失败后可以先把失败写成具体未达标项核对任务标准与验收结果再沿输入、工具调用和交付物寻找偏差。把原因猜测改写成可验证的假设优先处理影响大、有证据支撑的问题调整后同时复测原失败任务和相关任务判断是否值得采用。“这次没做好换个模型再试试。”这个办法有时能得到更好的结果却未必能告诉你下一次应该改哪里。对开发者更有用的产出是一条能落实的改进记录什么要求没有满足现有证据指向哪里准备改什么怎样判断改动有效。下面用一个订单汇总任务说明。这是方法示例所有输入、失败表现和排查分支均为构造不对应 EvalDock 或任何产品的实测结果。1. 把“任务失败”写成能核对的差异假设要求 Agent 读取订单文件只汇总已付款订单的金额交付结果文件并保持原始输入不变。订单状态金额A已付款100B待付款200C已付款50本例正确汇总金额为 150。如果交付文件写了 350可以把失败记录为在这份三条订单的输入中要求汇总已付款金额实际交付为 350参考结果为 150。金额验收未通过。输入文件是否保持不变另行核对。“350 恰好等于全部订单之和”是一条排查线索。它还不能直接证明 Agent 忘记了筛选读取了错误文件、工具执行错误、最终写入错误都可能产生同样的结果。每项要求分别记录。文件已生成、金额错误、输入未被修改可以同时成立总分或一句“失败”会把这些差异藏起来。2. 先确认失败判定成立在调整 Agent 前先检查这次验收是否准确参考结果是否按同一份输入计算付款状态、时间范围、金额单位是否约定清楚验收程序读到的是本次交付还是上一次运行留下的文件检查规则是否拒绝了符合要求的表达例如任务允许数值 150 和 150.00字符串比较却只接受其中一种。运行时是否具备任务需要的文件、权限和依赖工具错误与超时记录是否保存Anthropic 的 Agent 评测方法文章建议结合执行记录与评分检查失败确认是否误判了有效解法。具体到自己的产品要能说明哪一项交付要求没有满足以及判定依据是什么。如果任务标准本身有歧义先澄清标准如果验收程序有错误修正后重新检查受影响结果保留修订记录。不能只为让某个输出通过而临时放宽要求。环境问题也值得单列。权限不足可能来自测试配置也可能来自产品安装或运行流程。即使故障发生在外部服务Agent 如何提示、恢复或交还任务仍可按原先约定的要求检查。记录故障来源与任务完成情况有助于找到实际负责人。3. 从交付结果往前查找到最早可见的偏差订单示例中可以先读回结果文件再关联该次任务实际发生的操作Agent 收到了什么输入工具被传入了什么条件工具返回了什么返回内容怎样进入最终交付。下表列出几种构造的排查分支不是已发生的测试记录。实际分析时应按每次运行取得的证据确定检查方向。查到的证据优先检查的环节还需确认什么输入目录里存在多份订单实际读取了旧文件文件选择与输入绑定本次任务怎样指定文件读取路径是否可核对实际汇总调用没有付款筛选条件任务约束传递、参数生成与工具接口工具是否支持筛选字段含义是否清楚调用前拿到了哪些要求调用带有正确筛选条件工具却返回 350工具执行与状态映射用相同输入单独调用工具核对其实际筛选规则工具返回 150最终文件写成 350返回值使用与文件写入是否混入其他调用结果写入后是否读回检查只有最终的 350没有中间记录结果错误已确认原因待查下一次运行补哪一处记录才能区分上述解释这些位置是排查入口。最早观察到的偏差不一定就是根本原因。漏传筛选条件可能与工具描述不清、要求未传到当前步骤或参数构造有关一份执行记录可以缩小范围但不能自动在这些解释中作出选择。尽量把任务、调用及其输入返回、交付文件关联到同一次运行。排查需要的是这些可核对的操作记录不需要猜测模型未公开的内部推理。Agent 在事后写出的“我可能忽略了筛选条件”可以作为线索不能代替实际调用证据。没有可核验的执行记录时先报告输入、输出和交付物支持的判断。缺少哪一步就把下一步检查安排在能够区分原因的位置。4. 把原因猜测改写成一次验证“模型不够强”“提示词不够好”很难直接形成改进任务。可以把假设写得更具体在包含待付款订单的任务中汇总工具的筛选参数说明不清可能导致调用漏传条件。下一步只修改该参数说明保留模型、任务要求和其他工具配置检查漏传现象与最终金额是否改善。这仍是假设。验证前先确认工具支持预期筛选并且参数说明确实送达 Agent。否则修改一段没有被使用的说明无法检验这个解释。一张改进卡可以包含四项证据哪些运行漏传了哪个参数对应哪个错误结果。假设参数说明的歧义影响了调用构造。调整明确该参数的含义和允许值其他可控制条件保持一致。判据在需要筛选的任务中正确传参交付金额正确无需筛选的任务仍按原要求完成。先验证一个有清晰边界的变化更容易解释结果。如果必须同时调整接口与调用方式就把两者记为一组改动结论限定到这组变化。修复后一次成功只能说明这次通过了检查。它可能来自运行波动也可能是工具更容易使用了还需要重复执行和新的输入才能判断改动是否稳定有帮助。即使结果改善也不宜立即宣称找到了唯一原因。图 1构造示例非实测同样交付 350可能对应输入选择、筛选参数、工具执行或结果写入的不同问题需结合运行记录排查并复测验证。EvalDock 团队绘制。5. 怎样挑出最值得改的问题可以综合看四件事影响、出现范围、证据和验证成本。影响看任务后果只是说明文字不清楚还是金额错误、交付缺失或者破坏了必须保留的输入。出现范围看是否集中在一类材料以及是否在不同任务中反复发生。证据看现有记录能否支持一个具体假设。验证成本看能否通过小范围调整或补充记录较快确认方向。例如订单汇总经常出现漏筛选且调用记录能定位到参数缺失就值得优先验证。只收到一次“答案不太对”的反馈既没有原输入也没有结果文件下一步更适合先补齐材料。这里要区分“值得立即解决”与“已知道怎样修”。影响很大的问题即使原因不明也可能需要先限制相关功能或增加人工确认再继续排查证据不足不等于影响小。汇总失败时写清统计单位和范围。“20 次运行中有 5 次失败其中 3 次可确认漏筛选”与“60% 的任务都有筛选问题”含义不同。前一句是构造统计示例3/5 只描述已观察失败中的占比20 次运行也未必对应 20 个不同任务。只有失败反馈、没有总运行记录时更不能据此推算整体失败率。对同一问题造成的多个后续错误可以关联记录避免将一次漏筛选产生的金额错误、摘要错误和图表错误当成三个独立原因。原因未确认的记录保持待查不强行分组。6. 复测既看修好了什么也看影响了什么订单示例的复测至少应考虑三组材料原失败任务检查已发现的问题是否改善。同类新输入更换订单数量、排列和金额检查是否只适应了已见过的例子这些输入不要提前用于调试。相关原有任务例如明确要求汇总全部订单的任务检查新说明是否让 Agent 过度筛选。对旧配置和新配置使用相同的输入、初始状态、验收标准与资源上限预先约定重复次数、重试规则和人工协助方式。每次从干净状态开始保留全部计划运行中途修改配置则另记一组。若旧配置无法重跑注明比较依据与条件差异。除了最终交付也核对假设对应的中间变化。本例中金额正确但没有调用证据可以报告结果改善暂时无法确认漏传参数的问题是否消失。模型评分适合提供补充线索金额校验等可直接检查的结果仍应单独列出。耗时、调用费用与人工介入也一起记录。新方案靠人工补条件才完成和能够独立完成是两种结果验证脚本新增了一次检查也不等于 Agent 本身已经学会修正。复测后可以作出具体决定在已测范围内采用改动限定在某类任务中继续试用发现关键退步后调整方案证据还不足则补测。不要把一批材料上的改善写成所有任务都已解决。把排查结论交给下一位开发者一次失败分析最后应留下别人能够继续验证的记录任务、输入与配置 未满足的要求、实际结果和参考结果 验收规则与环境检查结果 已确认的操作证据、缺失记录 原因假设与其他可能解释 优先级依据、拟做的改动 复测任务、重复与重试规则 结果变化、退步、耗时费用和人工介入 采用决定、适用范围与待查问题本文由 EvalDock 团队撰写。