企业官网建设流程全解析

Agent 任务失败后，可以先把失败写成具体未达标项，核对任务标准与验收结果，再沿输入、工具调用和交付物寻找偏差。把原因猜测改写成可验证的假设，优先处理影响大、有证据支撑的问题；调整后同时复测原失败任务和相关任务，判断是否值得采用。

“这次没做好，换个模型再试试。”这个办法有时能得到更好的结果，却未必能告诉你下一次应该改哪里。

对开发者更有用的产出，是一条能落实的改进记录：什么要求没有满足，现有证据指向哪里，准备改什么，怎样判断改动有效。

下面用一个订单汇总任务说明。这是方法示例，所有输入、失败表现和排查分支均为构造，不对应 EvalDock 或任何产品的实测结果。

1. 把“任务失败”写成能核对的差异

假设要求 Agent 读取订单文件，只汇总已付款订单的金额，交付结果文件，并保持原始输入不变。

本例正确汇总金额为 150。如果交付文件写了 350，可以把失败记录为：

在这份三条订单的输入中，要求汇总已付款金额；实际交付为 350，参考结果为 150。金额验收未通过。输入文件是否保持不变，另行核对。

“350 恰好等于全部订单之和”是一条排查线索。它还不能直接证明 Agent 忘记了筛选：读取了错误文件、工具执行错误、最终写入错误，都可能产生同样的结果。

每项要求分别记录。文件已生成、金额错误、输入未被修改，可以同时成立；总分或一句“失败”会把这些差异藏起来。

2. 先确认失败判定成立

在调整 Agent 前，先检查这次验收是否准确：

• 参考结果是否按同一份输入计算？付款状态、时间范围、金额单位是否约定清楚？
• 验收程序读到的是本次交付，还是上一次运行留下的文件？
• 检查规则是否拒绝了符合要求的表达？例如任务允许数值 150 和 150.00，字符串比较却只接受其中一种。
• 运行时是否具备任务需要的文件、权限和依赖？工具错误与超时记录是否保存？

Anthropic 的 Agent 评测方法文章建议结合执行记录与评分检查失败，确认是否误判了有效解法。具体到自己的产品，要能说明哪一项交付要求没有满足，以及判定依据是什么。

如果任务标准本身有歧义，先澄清标准；如果验收程序有错误，修正后重新检查受影响结果，保留修订记录。不能只为让某个输出通过而临时放宽要求。

环境问题也值得单列。权限不足可能来自测试配置，也可能来自产品安装或运行流程。即使故障发生在外部服务，Agent 如何提示、恢复或交还任务，仍可按原先约定的要求检查。记录故障来源与任务完成情况，有助于找到实际负责人。

3. 从交付结果往前查，找到最早可见的偏差

订单示例中，可以先读回结果文件，再关联该次任务实际发生的操作：Agent 收到了什么输入，工具被传入了什么条件，工具返回了什么，返回内容怎样进入最终交付。

下表列出几种构造的排查分支，不是已发生的测试记录。实际分析时，应按每次运行取得的证据确定检查方向。

这些位置是排查入口。最早观察到的偏差，不一定就是根本原因。漏传筛选条件，可能与工具描述不清、要求未传到当前步骤或参数构造有关；一份执行记录可以缩小范围，但不能自动在这些解释中作出选择。

尽量把任务、调用及其输入返回、交付文件关联到同一次运行。排查需要的是这些可核对的操作记录，不需要猜测模型未公开的内部推理。Agent 在事后写出的“我可能忽略了筛选条件”，可以作为线索，不能代替实际调用证据。

没有可核验的执行记录时，先报告输入、输出和交付物支持的判断。缺少哪一步，就把下一步检查安排在能够区分原因的位置。

4. 把原因猜测改写成一次验证

“模型不够强”“提示词不够好”很难直接形成改进任务。可以把假设写得更具体：

在包含待付款订单的任务中，汇总工具的筛选参数说明不清，可能导致调用漏传条件。下一步只修改该参数说明，保留模型、任务要求和其他工具配置，检查漏传现象与最终金额是否改善。

这仍是假设。验证前，先确认工具支持预期筛选，并且参数说明确实送达 Agent。否则修改一段没有被使用的说明，无法检验这个解释。

一张改进卡可以包含四项：

• 证据：哪些运行漏传了哪个参数，对应哪个错误结果。
• 假设：参数说明的歧义影响了调用构造。
• 调整：明确该参数的含义和允许值；其他可控制条件保持一致。
• 判据：在需要筛选的任务中正确传参，交付金额正确；无需筛选的任务仍按原要求完成。

先验证一个有清晰边界的变化，更容易解释结果。如果必须同时调整接口与调用方式，就把两者记为一组改动，结论限定到这组变化。

修复后一次成功，只能说明这次通过了检查。它可能来自运行波动，也可能是工具更容易使用了；还需要重复执行和新的输入，才能判断改动是否稳定有帮助。即使结果改善，也不宜立即宣称找到了唯一原因。

图 1｜构造示例，非实测：同样交付 350，可能对应输入选择、筛选参数、工具执行或结果写入的不同问题；需结合运行记录排查并复测验证。EvalDock 团队绘制。

5. 怎样挑出最值得改的问题？

可以综合看四件事：影响、出现范围、证据和验证成本。

影响看任务后果：只是说明文字不清楚，还是金额错误、交付缺失，或者破坏了必须保留的输入。出现范围看是否集中在一类材料，以及是否在不同任务中反复发生。证据看现有记录能否支持一个具体假设。验证成本看能否通过小范围调整或补充记录，较快确认方向。

例如，订单汇总经常出现漏筛选，且调用记录能定位到参数缺失，就值得优先验证。只收到一次“答案不太对”的反馈，既没有原输入也没有结果文件，下一步更适合先补齐材料。

这里要区分“值得立即解决”与“已知道怎样修”。影响很大的问题即使原因不明，也可能需要先限制相关功能或增加人工确认，再继续排查；证据不足不等于影响小。

汇总失败时，写清统计单位和范围。“20 次运行中有 5 次失败，其中 3 次可确认漏筛选”与“60% 的任务都有筛选问题”含义不同。前一句是构造统计示例：3/5 只描述已观察失败中的占比；20 次运行也未必对应 20 个不同任务。只有失败反馈、没有总运行记录时，更不能据此推算整体失败率。

对同一问题造成的多个后续错误，可以关联记录，避免将一次漏筛选产生的金额错误、摘要错误和图表错误当成三个独立原因。原因未确认的记录保持待查，不强行分组。

6. 复测既看修好了什么，也看影响了什么

订单示例的复测至少应考虑三组材料：

1. 原失败任务：检查已发现的问题是否改善。
2. 同类新输入：更换订单数量、排列和金额，检查是否只适应了已见过的例子；这些输入不要提前用于调试。
3. 相关原有任务：例如明确要求汇总全部订单的任务，检查新说明是否让 Agent 过度筛选。

对旧配置和新配置使用相同的输入、初始状态、验收标准与资源上限，预先约定重复次数、重试规则和人工协助方式。每次从干净状态开始，保留全部计划运行；中途修改配置则另记一组。若旧配置无法重跑，注明比较依据与条件差异。

除了最终交付，也核对假设对应的中间变化。本例中，金额正确但没有调用证据，可以报告结果改善，暂时无法确认漏传参数的问题是否消失。模型评分适合提供补充线索，金额校验等可直接检查的结果仍应单独列出。

耗时、调用费用与人工介入也一起记录。新方案靠人工补条件才完成，和能够独立完成是两种结果；验证脚本新增了一次检查，也不等于 Agent 本身已经学会修正。

复测后，可以作出具体决定：在已测范围内采用改动；限定在某类任务中继续试用；发现关键退步后调整方案；证据还不足则补测。不要把一批材料上的改善写成所有任务都已解决。

把排查结论交给下一位开发者

一次失败分析，最后应留下别人能够继续验证的记录：

任务、输入与配置： 未满足的要求、实际结果和参考结果： 验收规则与环境检查结果： 已确认的操作证据、缺失记录： 原因假设与其他可能解释： 优先级依据、拟做的改动： 复测任务、重复与重试规则： 结果变化、退步、耗时费用和人工介入： 采用决定、适用范围与待查问题：

本文由 EvalDock 团队撰写。