本节要解决的事：从“回答很像成功”走到“环境中确实出现了要求的结果”。例子延续库存任务，但这次用户明确要求修改教学文件。
一句话很有把握，可能四条轨迹都一样
用户说：“把 /demo/stock.json 中红笔库存从 5 改为 2，其他商品保持原样。”四个 Agent 最后都说“已完成”。第一个没有调用写文件工具；第二个调用了，但工具返回权限错误；第三个成功写入 /demo/stock-copy.json；第四个写入指定文件并重新读取。只读最后一句话，你无法区分它们。
目标不是“说出数字 2”，也不只是“出现一次成功工具调用”。目标包含对象、字段、新值和不变条件：指定路径的红笔库存等于 2，蓝笔等其他字段没有被意外改动。把这句话变成验收条件，成功才有共同含义。如果用户只是问库存，本节的写入当然不在任务范围内；验收必须从实际请求出发。
把成功拆成三层证据
第一层是模型声明。它方便向人汇报，却仍是模型生成的文本。第二层是工具报告，例如写入工具返回成功。这说明某个操作接口认为自己完成了工作，但路径可能错误，成功也可能只代表任务已排队。第三层是目标状态的检查：读回指定文件，解析内容，对照目标与原始快照。对于异步服务，还要区分“接受请求”和“业务最终完成”。
这三个层次不是互相排斥。声明负责交流，工具状态帮助定位故障，环境验证负责支持完成结论。问题出在拿前一层直接代替后一层。比如工具返回“已保存 120 字节”，它不能单独证明保存的是正确 JSON，更不能证明保留了所有其他商品。
沿着最短证据链走一遍
先读取原文件，保存红笔 5、蓝笔 1 的事实与路径。生成只修改红笔库存的操作，让工具返回实际目标路径与结果。随后重新读取同一路径，将 JSON 解析为对象，检查红笔是否等于 2，再检查蓝笔仍为 1。最后汇报这两项检查，而不是根据工具名字猜测成功。
如果写入失败，失败结果应该回到下一轮输入。模型可以分析权限、路径或格式，选择修正，也可以在缺乏授权时停止。不能把失败字符串删掉后让它继续宣布完成。循环的终止规则应允许“成功”“失败且无法继续”“预算耗尽”等不同结局，避免把所有结束都叫成功。
同一句完成，分别检查实际状态
先做预测，再逐步展开。这里是固定规则的教学回放，不是真实模型测评。
教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。
目标 /demo/stock.json：红笔 5，蓝笔 1。工具写入 stock-copy.json。
- 1. 操作报告
工具表示成功写入副本。
- 2. 读回目标
原路径仍是红笔 5、蓝笔 1。
- 3. 对照条件
红笔应该是 2；实际为 5。
工具表示成功写入副本。
先预测，再核对结果与原因
任务失败操作成功与目标成功分离，不能用副本代替指定文件。
两组条件变化，会改变检查方式
第一组比较同步文件与异步订单。文件写入返回后可以立刻读回；订单接口返回任务号时，订单可能还在处理中。后一种情况应查询任务状态或订单记录，而不能把 HTTP 请求成功视为订单已成立。等待需要有超时和停止条件，不能无期限轮询。
第二组比较独占修改与多人并发。如果另一个人同时合法修改蓝笔，简单拿整个文件字节与旧副本比较会把合理变化也算成我们的错误。此时需要版本号、事务或更精确的变更归属证据。教学例子假定没有并发写入；真实系统要把这个前提写进验证设计。
验证也有成本。只读库存问答无需构造大型测试框架；关键是验证风险最大的未知部分。检查一条输出样式不能证明没有其他副作用，读回一个字段也不能证明所有字段都安全。我们应明确“本次检查支持什么”，避免把有限证据扩张成全系统可靠性。
理解检查：先回答，再看解释
问题一：工具显示成功，为什么第三条轨迹仍失败？ 因为成功对应副本路径，而用户目标对应原路径。请求对象和验证对象必须一致；增加更多“成功”日志不能弥补对象错位。
问题二：读回红笔为 2，是否足够？ 对本任务还不足够。用户还要求其他商品不变，至少需要检查有关字段或审查准确差异。如果红笔变对了、蓝笔被删除，目标只完成了一部分。
问题三：写入权限错误后，正确最终回答一定是失败吗？ 不一定立即结束。若可在授权范围内修正路径等问题，可以继续；但没有新证据前不能说已完成。最终应该区分已尝试、已执行、已验证，并报告未解决项。
回到整条循环
至此，工具调用不仅能跑起来，还能配对、校验、选择并行并判断结束。下一问是：如果每一步都要带着这些请求、返回和证据继续，历史越来越长，模型究竟反复读了多少内容？