这类问题不能只盯最终答案，因为行为漂移经常先发生在过程层，最终结果还没完全坏掉。
一个务实的反馈 loop，至少要同时覆盖四类信号：
- 结果信号：任务是否完成、字段是否齐全、答案是否命中硬约束。
- 过程信号：调用了哪些工具、顺序是否异常、重试次数是否上升、是否跳过了确认步骤。
- 成本信号：token、时长、外部调用次数、失败恢复次数。
- 漂移信号：同类任务在最近一段时间的路径分布是否变化、人工回退率是否上升。
为什么 trace 必须看？因为很多问题不是“输出错了”，而是“系统开始用一种以后会出事的方式完成任务”。例如今天只是多调用一次工具，明天就可能绕过审批。
第一版最小闭环我会这样做：
- 先选 10 到 20 个高频任务当基线样本
- 为每个任务定义必须经过的关键 gate
- 每次运行都记录 trace、成本和关键状态
- 对同类任务做简单 diff：路径、工具数、确认点、结果字段
- 一旦超阈值，就进入人工抽检
自动化适合抓“异常模式”，人工更适合判断“异常是否真的构成风险”。
所以 feedback loop 的目标不是替代复盘，而是尽早把“看起来还能用，但已经开始偏”的系统揪出来。