按钮确实点中了，为什么任务还不算完成？
上一节把目标映射到了当前界面上的按钮。我们现在沿原课蓝色杯子的购物过程继续：点到商品，会打开详情；点“加入购物车”，可能改变购物车；但用户要的也许是购买，也许只是加入购物车。本课区分动作执行、页面变化和任务完成，先不展开完整支付系统。
同一次点击，可以对应三种结果
执行器返回“click 已发送”，只说明输入事件发出。页面可能尚未处理，也可能由于缺货拒绝加入，还可能加入成功却没有跳转。若模型把执行器成功当成业务成功，就会在缺少结果证据时宣布完成。
教学任务先限定为“把一只蓝色单杯加入购物车，数量为 1”。我们把完成条件写成三个可核对的字段：商品是蓝色单杯、数量是 1、购物车状态中存在该条目。截图上出现蓝色杯详情，只满足识别商品；购买按钮的点击日志满足的是过程记录，均不等价于上述最终状态。
原课初始目标写的是 buy，后面的购物车截图也仍有 Checkout。读图时不要把停在购物车解释成已经支付成功；讲义用这组画面说明策略的输入如何累计，并没有在该页给出完整支付验收。
状态变化要怎样读回来
行动前记录当前状态，例如购物车空；行动是点击一次加入；行动后读取新状态。若购物车出现蓝杯数量 1，就支持“加入一只”的结论。若状态仍为空，下一步应区分加载中、错误提示、页面未更新，而不是立刻再点一次。
为什么不直接重试？因为第一次请求可能已到服务器，只是界面反馈延迟。重复点击后，最终数量可能变成 2。我们的教学记录中，两次加入每次增加 1，起始数量 0，最终就是 0+1+1=2。两次动作都执行成功，任务却失败。它与代码任务里“补丁应用了两次”相似：工具执行成功不保证组合后的业务状态正确。
为什么多点一次反而错了
比较动作已发生、页面已显示、任务已完成这三个时刻。
教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。
初始数量 0；第一次加入已成功，界面尚未刷新
- 1. 第一步
点击一次，服务端数量变为 1。
- 2. 第二步
看到旧界面仍是 0，立刻再点，数量变为 2。
- 3. 第三步
刷新读回数量 2，与目标数量 1 不符。
点击一次，服务端数量变为 1。
先预测，再核对结果与原因
两次点击成功，任务失败。延迟不等于请求未执行。
先预测第二次点击会不会更保险，再逐步揭示服务器状态与界面状态。这里只改变是否在未知结果时重复提交，第一次请求都已经成功，数字是固定状态转移计算。
历史不是动作清单，而是判断依据
下一轮输入保留旧观察、动作和新观察，模型才能知道“我刚刚点过一次，现在看到的数量可能是延迟结果”。如果只留下最新截图，它仍能读到数量，却不知道是否还有一个在途请求；如果只留下动作，它又不知道页面是否真的接受了请求。
这不要求无限保存每张截图。可以保留可靠的状态摘要、关键变化与尚未确认的动作；摘要必须区分“已发送”和“已确认”，不能把推测压缩成事实。比如“加入请求已发，数量尚未确认”比“已加入购物车”更准确地保留不确定性。
改变目标，停止位置也会改变
如果用户只要求“找到符合条件的商品”，详情页上名称、价格、颜色足以形成候选证据，没必要加入购物车。如果要求“加入一只”，购物车字段是验收对象；如果要求“完成购买”，还要订单状态等后续证据，以及对应的行动权限。停止规则必须从任务语义推导，而不能固定成“见到绿色提示就停”。
错误提示也有不同含义。“请求处理中”表示暂时未知，“库存不足”表明当前操作失败，“已存在同商品”可能提示不该重复新增。把这三种都变成重试，会使环境更难判断。
需要拍板的是：每个关键动作之后读哪个信号、等待多久、什么时候重试，以及重试是否会重复产生效果。验收至少设置成功、明确失败、反馈延迟三种状态，检查 Agent 是否给出不同的下一步。超时后应报告未确认，不能把没观察到失败当成成功。
点击是改变状态的尝试，完成是对目标状态的确认。 先停在这里，你已经能审查一个界面 Agent 的停止条件；再深一层，可以追踪同一请求在浏览器、服务端和数据库中的不同确认时刻。
理解题 1：执行器返回成功，购物车仍为空，可以宣布加入成功吗？
不可以。执行器成功只证明输入事件发送。应检查页面是否加载、是否报错，以及购物车的实际状态，未确认时保留不确定性。
理解题 2：第一次加入成功但反馈延迟，立即再点一次一定更安全吗？
不是。如果每次都增加一件，会得到两件。应先确认状态或使用能识别重复请求的机制，再决定重试。
理解题 3：同一个购物车画面，可以对一个任务成功、对另一个任务未完成吗？
可以。对“加入一只”可能成功，对“完成购买”还缺订单完成证据。验收取决于目标，不只取决于画面。
我们知道怎样判断一次操作。接下来若要训练或公平比较几千次操作，怎样让每次从同样的环境开始？