失败归因只认第一个致偏错误

归因对象是轨迹中首个导致任务偏离的错误，后续报错往往只是连锁反应。定位落在哪一层，决定这单该修 Harness、改流程还是补训练数据——归因错位会指向昂贵的错误方向。

端到端评估只告诉你成功或失败，不回答「为什么失败、从哪一步开始失败」。要让评估结果真正驱动修复，每条失败轨迹都得做归因：标出主要错误类别、首次出现不可接受行为的步骤、对应的工具调用或模型输出，并附可复核的证据。归因对象是首个导致任务偏离的错误——后续错误往往只是连锁反应，不能把最后一个报错当成根因 ai-agent-book-7。

三类信号，一个原则

生产侧的问题案例来自三类信号：用户明确纠正、点踩或负面反馈、事后状态检查与验证器发现的问题。它们汇进同一套错误分类——类别可以细分到数百种，但选主因的原则只有一条：取最早且能解释后续失败的那个，其余保留为次因 ai-agent-book-7。九类常见错误（需求理解、流程规范、工具调用、hack 验证环境、修改不完整、信息反馈、非功能性回归、执行异常、过早停止）各自的「首错定位方式」不同，但都是同一句话：从第一处偏离回溯，而不是从最后一个异常往前看。归因记录本身怎么结构化、怎么转成重放用例，从失败到工程资产 已经讲过；本篇关心的是定位本身。

做对了但说错了

一类最容易被整体成功率掩盖的失败：环境状态全对，告诉用户的信息却错了。τ²-bench 的公开基线里，带信息告知要求的 704 次运行共失败 240 次，其中 162 次是信息告知出错——有 80 次（占全部失败的三分之一）环境状态正确、话说错了 ai-agent-book-7。AndroidWorld T3A 运行记录里有个典型样本：任务是把 expenses.jpg 里的开销录入记账应用，Agent 用 32 步完成授权、搜索、打开图片、逐条填写和保存，没有任何一步返回错误，最后宣告完成——验收却报告记录不存在，日志给出的那条与写入的四条毫无关系。逐步回看：第 8 步思考里写着「我看不到图片内容」，它既没停下也没报告；第 11 步，四条开销数据凭空出现在它的记录里；此后每一步都基于这四条幻觉 ai-agent-book-7。首个错误落在第 8 步——而那一步既没有报错，也不是一次工具调用。更值得抄的是根因判断：T3A 是纯文本 Agent，观察空间里只有元素树、根本没有图像像素，所以根因不是「模型不会 OCR」，而是 Harness 的观察通道缺失。记成模型能力问题，接下来就是换模型或做 OCR 训练；真正该做的只是补通道。归因错位直接决定修复预算的流向。

逐层定位：从字节到 token

「模型抄错了」也不配当根因，除非排除了前面每一层。old_string 匹配失败的标准动作：对同一字符串保存原始字节哈希、Unicode code point 序列和 tokenizer token ID 序列，沿「文件字节 → 工具返回 → Harness 序列化 → 模型上下文 → token 输出 → 解码字符串 → JSON 解析 → 工具匹配」的链路找首个差异 ai-agent-book-7。最小化探针覆盖直接复述、长上下文抽取、放入工具参数、相似串选择，以及空格、换行、反斜杠、Unicode 组合字符与低频 token；指标用 byte-exact、code-point-exact、token-exact 和首次分歧位置。分流规则一句话：直接探针输出正确而工具调用失败，修 tokenizer、序列化或工具协议；只有首个差异出现在模型输出时，这个案例才转成训练数据——判错的代价是给模型喂了本该由 Harness 修的脏活。

首错也是训练标签

同一份归因记录在参数侧继续上班：首个错误步骤与错误类别是过程监督负标签（PRM）的直接来源；「准备宣称完成」的决策边界可以截成偏好对——被拒绝的是过早结束，被选中的是先跑测试再下结论 ai-agent-book-8。过早结束的案例里，归因把首错定在「缺乏证据时下结论」那一步：在此之前读代码、改代码都没错，前缀不同、结论相反 ai-agent-book-8。这也是 四层评测：结果、过程、效率、风险 里 Outcome 与 Transcript 之分能成立的工程基础：没有首错定位，你只有分数；有了它，分数才能拆成可执行的修复。