Agent 说“完成了”，怎样确认业务记录真的改对了？

开始执行前，怎样写清楚完成标准？

先选一项容易检查的小任务，例如在测试材料中修改一条待办的负责人。写清要改的是哪条记录、负责人应该变成谁、哪些信息需要保留，再保存执行前的状态。这样结束时可以逐项对照，避免把回复中的完成描述直接当成交付结果。

一次成功以后，重复试用该怎么做？

可以准备初始状态相同的测试副本，重复执行同一项工作，记录每次最终状态和需要人工介入的位置。随后再加入常见变化，例如名称相近的记录、信息缺失或一段补充说明，观察代理能否继续按目标完成任务。各轮测试都保留材料与配置，方便比较。

记录没改对时，怎样找到问题所在？

可以把过程分成读到目标、理解要求、执行修改和读取结果几个阶段，保留每一阶段的必要状态。发现结果不符时，先判断是找错了记录、理解错了要求，还是修改没有落下去，再处理对应环节。记录重点放在定位问题所需的信息，避免保留与任务无关的业务内容。

若一次执行只完成部分动作，应明确列出已完成项与未完成项，并由负责人决定下一步。重新尝试前先读取当前状态，确认哪些动作还需要继续，减少重复操作。这里提出的是失败处理方法，不能据此认定 ThinkingBox 已经提供了恢复执行或业务回滚能力。

哪些条件满足后，可以扩大使用范围？

当常见输入下的结果符合预期，失败可以被识别并交给负责人，团队也能找到每次执行的关键记录时，可以增加下一类任务。扩大过程中继续检查最终结果，特别关注新任务带来的条件变化，并保留原有人工处理入口，便于发现问题后接手。

先用一组固定输入检查结果

例如任务只允许把指定订单的收货地址改成 A。检查时先比对订单记录，再确认其他订单、付款和通知没有被意外改动；重复执行还要检查是否新增了重复通知。只有聊天回答“已经改好”不能通过验收。本文未连接零售系统或运行 ThinkingBox，这个样例说明要检查哪些状态。