从最终失败回到首次偏离
一句话收获：修复应从首次偏离开始，而不是在最终输出继续堆 Prompt。
这个场景在解决什么问题
Agent 最终失败了（答错、做错、验收不过），该怎么修？最常见的错误做法是：在最终输出那里继续堆 Prompt、加规则，结果越修越乱。正确的做法是：往回找"第一次开始出错的地方"，从那里修。
这个场景的目标（goal）是：将失败定位到事实、上下文、知识、工具、状态、模型或验收。观察点（observation）是：沿完整轨迹逆向寻找第一个错误转换——沿着完整的执行轨迹，从终点往回倒，找到"第一次从对变成错"的那个转换点。
它值得单独学，因为它纠正了"头痛医头"的修 bug 方式：修复要从首次偏离开始，而不是在最终输出继续堆 Prompt。
先理清这条判断链（文字版）
从"最终失败"到"最小修复"是一条逆向链，先记录失败、再往回定位、再提假设、最后做最小修改：
- 先看记录最终失败——外部验收指出对象错误、状态不符或证据缺失，先回看中间状态，别急着归因。
- 再看逐层比较输入输出——检查事实、Context、RAG、Tool、Loop 和模型候选，找到"上游还对、当前层首次偏离"的位置。
- 然后看形成可证伪假设——提出触发条件、目标机制、预期变化和保护指标，假设要能区分修改前后。
- 最后看Coding Agent 生成最小修改——改一个机制、补回归任务、其他条件冻结，单变量让收益可归因。
逐层详解
第 1 步：记录最终失败
原文：外部验收指出对象错误、状态不符或证据缺失。
白话：最终失败是"外部验收"指出的——可能是操作的对象错了、状态对不上、证据缺失。先把这个失败原样记录下来，搞清楚"到底哪没成"。
类比：像交通事故，先做现场记录——撞了哪、谁的责任、损失多大，先把"最终结果"完整记录，而不是一上来就猜原因。
举例：订单 Agent 最终失败，外部验收指出"订单状态不符"——应该改成"已处理"，实际还是"待处理"，且缺少处理证据。先把这条失败（对象、状态、证据）完整记录下来。
为什么重要：终局结果只告诉我们没有完成。最终失败这个结果，只能告诉我们"没做成"，它本身不能告诉我们"为什么没做成"——原因得继续往回挖。
怎么验证（证据点）：
- 失败义务：哪条成功义务失败了。
- 外部证据：支撑"失败"判断的外部证据是什么。
- 影响范围：这次失败影响了多大范围。
别踩的坑（边界）：终局错误不能直接确定根因。看到最终错了，不能直接断定"根因就是最后一步"——最后一步可能是被前面的错误连累的。
落地检查：继续回看中间状态。落地时记录完最终失败，下一步是往回看中间状态，而不是停在终点下结论。
第 2 步：逐层比较输入输出
原文：检查事实、Context、RAG、Tool、Loop 和模型候选。
白话：沿着执行轨迹，一层一层比较"这一层的输入对不对、输出对不对"，检查事实、Context（上下文）、RAG（检索）、Tool（工具调用）、Loop（循环）、模型候选这几层。
类比：像流水线出了次品，不盯最后一个工位，而是一个工位一个工位往回查，看哪个工位"进去的是好的、出来的是坏的"，那个工位就是问题源头。
举例：订单失败，逐层查：事实层（输入的事实对）→ Context 层（上下文完整）→ RAG 层（检索到的政策对）→ Tool 层（工具调用参数对）→ Loop 层（循环决策对）→ 模型候选（模型判断对），发现是 Tool 层第一次传错了订单 ID，下游全是跟着错。
为什么重要：首次从正确变为错误的位置最有解释力。错误往往是"某一步开始错，之后一路错下去"，所以"第一次从对变错"的那一步，最能解释整个失败——找到它，就找到了根因。
怎么验证（证据点）：
- 上游仍正确：出错那一步的上游还是对的。
- 当前层首次偏离：这一层是第一次出现偏离。
- 下游继续传播：这一层之后，下游跟着错下去。
别踩的坑（边界）：下游多处异常可能来自同一上游错误。下游好几个地方都异常，可能不是好几个独立 bug，而是同一个上游错误扩散下来的——别被下游一堆异常误导，以为要修一堆地方。
落地检查：不要同时修所有层。落地时定位到首次偏离点后，只修那一点，不要同时修所有层——同时修所有层，你就分不清是哪个改动起作用了。
第 3 步：形成可证伪假设
原文：提出触发条件、目标机制、预期变化和保护指标。
白话：定位到首次偏离点后，提出一个"可证伪的假设"（能被证明是错的假设），说清楚：什么条件触发它、它影响的是哪个机制、改了之后预期会有什么变化、以及要盯住哪些"保护指标"（不能退化的指标）。
类比：像医生诊断，不能只说"病人身体不好"，要说"我假设是 XX 细菌感染，用 XX 药，预期体温会降，同时要盯住肝肾功能别受损"——这样才可验证、可推翻。
举例：假设="订单失败是因为 Tool 层传了错误的订单 ID（触发条件），机制是 ID 映射错误（目标机制），预期改为从上下文正确取 ID 后订单状态能改对（预期变化），同时要盯住'不误改其他订单'这个保护指标"。
为什么重要：可证伪假设指导最小实验。一个好的假设能告诉你"做个什么最小实验来验证它"，如果假设模糊（"让 Agent 更稳定"），就根本没法设计实验。
怎么验证（证据点）：
- 原因明确：假设的原因（触发条件、机制）是明确的。
- 预期可测：预期变化是能测出来的。
- 拒绝条件：有明确的"如果出现什么，就推翻这个假设"的条件。
别踩的坑（边界）："让 Agent 更稳定"不是可验证假设。"让 Agent 更稳定"这种话，没有可测的标准、没有可推翻的条件，它是个愿望，不是假设。
落地检查：假设要能区分修改前后。落地时假设必须能区分"改之前"和"改之后"的差异，改完能看出有没有效果，否则这个假设不合格。
第 4 步：Coding Agent 生成最小修改
原文：AI 修改一个机制并补回归任务，其他条件保持不变。
白话：让 Coding Agent（AI）去生成"最小修改"——只改那一个机制，并补上对应的回归任务（防止旧问题复发的测试），其他所有条件保持不动。
类比：像调机器，只拧一个螺丝（改一个机制），其他螺丝全不动，再补一个"定期检查这个螺丝"的机制（回归），这样才能知道到底是哪个螺丝的作用。
举例：只让 Coding Agent 修改"订单 ID 的取法"这一个机制（从错误的映射改成从上下文正确取），并补一条"订单 ID 映射"的回归测试，其他（模型、数据、环境）全冻结不变。
为什么重要：单变量实验使收益可归因。只有一次只改一个变量，才能把"结果的改善"归因到"这个改动"上；如果一次改一堆，改善了也不知道是谁的功劳。
怎么验证（证据点）：
- 差异最小：改动尽量小，只碰那一个机制。
- 回归新增：补了对应的回归任务。
- 其他配置冻结：其他条件都没动。
别踩的坑（边界）：只看当前任务通过会造成过拟合。只让当前这个失败任务通过，可能只是"过拟合"了这个任务（改得只对这一个任务管用），要看它有没有破坏别的、有没有真正通用。
落地检查：进入完整回归与灰度。落地时最小修改做完、当前任务通过后，要进入完整的回归测试和灰度发布，不能只凭当前任务过了就上线。
落地可行性小结
本场景涉及的核心技术栈：外部验收、执行轨迹（trace）、分层诊断（事实/Context/RAG/Tool/Loop/模型）、可证伪假设（falsifiable hypothesis）、Coding Agent、回归任务、灰度发布。
真实落地要检查的事：
- 最终失败要完整记录（对象、状态、证据、影响范围），不急着归因。
- 逐层比较输入输出，找"上游还对、当前层首次偏离"的点，别被下游多处异常误导。
- 假设要可证伪：触发条件 + 目标机制 + 预期变化 + 保护指标 + 拒绝条件。
- 最小修改：一次只改一个机制、补回归、其他冻结，然后进完整回归与灰度。
常见坑：
- 在最终输出堆 Prompt、加规则，越修越乱，没找到首次偏离。
- 看到下游多处异常就以为要修一堆地方，其实都来自同一上游错误。
- 假设写成"让 Agent 更稳定"这种不可验证的愿望。
- 只看当前任务通过就上线，造成过拟合，没进完整回归和灰度。
回顾
- 修复从首次偏离开始，而不是在最终输出继续堆 Prompt。
- 终局错误不能确定根因，要沿轨迹逐层比较输入输出找"首次从对变错"的点。
- 下游多处异常常来自同一上游错误，不要同时修所有层。
- 可证伪假设要含触发条件、目标机制、预期变化和保护指标，能区分修改前后。
- 最小修改=单变量实验：改一个机制、补回归、其他冻结，再进完整回归与灰度。