本节要解决的事：把一次成功写成流程很容易；证明它值得在下一次使用，需要反例和独立验证。
重试三次成功，能总结为“失败就重试”吗
某次库存查询第一次超时、第二次超时、第三次返回 5。Agent 写下一条技能：“工具报错时重试三次。”下一次工具返回权限拒绝，照着重试三次仍然失败。第三次任务是创建订单，第一次返回超时但订单实际上已经创建，盲目再试甚至可能重复创建。
原经验只能支持“在某些可安全重复的临时故障下，有限重试可能有用”，不能支持“所有错误都重试”。成功轨迹里还可能有偶然因素：服务刚好恢复、人工修好了权限、缓存恰好更新。时间上的先后不自动构成因果关系。
从经历到技能，中间至少有四道问题
先判定经历是否真的成功，使用第一单元的环境验收，而非最后一句自评。再提炼候选，写清适用条件：只读、可重复、错误属于临时故障、次数和等待有上限。随后拿不同案例练习，观察它是否选择正确行动。最后决定加入、修改或拒绝，而不是每完成一次任务就自动往技能库追加规则。
给候选技能一组能暴露问题的样本
样本 A：只读查询临时超时，稍后恢复。样本 B：同样查询明确权限不足。样本 C：有副作用的创建订单返回超时，执行结果未知。A 可以在有界策略下重试；B 应修正权限或报告阻塞；C 应先用请求标识查询是否已创建，再决定恢复方式。三个例子保留“出现错误”共同表象，却改变真正决定动作的条件。
重试技能的准入测试
先做预测，再逐步展开。这里是固定规则的教学回放，不是真实模型测评。
教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。
动作 get_stock，错误 timeout；最多允许两次额外尝试。
- 1. 识别动作
只读、重复不会额外创建对象。
- 2. 识别错误
临时超时，符合候选适用条件。
- 3. 执行有界策略
等待后重试一次，收到库存 5，记录结果。
只读、重复不会额外创建对象。
先预测，再核对结果与原因
本例适用成功依赖错误类型与动作可重复性，不只依赖“失败”二字。
可执行技能更容易检查，也仍会犯错
代码形式可以运行静态检查和测试，例如参数存在但从未使用，就能从实现中发现。然而测试通过只覆盖测试情景，不保证所有网站、权限状态和数据格式都成立。自然语言技能也需要验收标准，不能只凭步骤读起来专业就准入。
另一个对照是同站点与新站点。A 站排序入口是下拉框，B 站可能是侧栏；“按价格排序”的意图可迁移，点击某个坐标的操作未必可迁移。技能需要把稳定目标和环境绑定步骤分开，并让失败反馈能触发修订。
版本记录至少包含候选来源、适用条件、通过和失败的样本以及变更原因。评价样本最好不全是归纳时看过的轨迹，否则可能只是背下了原题。上线使用后还要记录误用、成本和失败类型：新版本成功率提高，却增加大量无效重试，也值得检查。
理解检查
问题一：三次尝试后成功，能否证明第三次重试是必要步骤？ 不能。服务可能第二次后已恢复，次数只是一次轨迹的观察。应比较不同等待与重试条件，并设置上限，而不是把偶然次数写成规律。
问题二：代码技能通过单元测试，是否就可以忽略新站点？ 不可以。测试覆盖的选择器和交互前提可能只在原站成立，迁移需要独立验证和明确适用范围。
问题三：旧技能失败一次，是否立即永久删除？ 不一定。先定位是环境变化、调用不适用、实现错误还是评价误判，再决定修复、收窄范围或退役。维护应有证据，而不是仅凭一次情绪化判断。
下一问
技能解决局部方法，完整任务还需要安排先后顺序。下一节从三家供应商开始：计划怎样指导行动，又怎样被真实的缺货反馈改变？