结果未知与对账

工具调用超时后，外部动作可能已发生但尚未确认。

结果未知是一种需要独立处理的状态。超时或断网只能说明应用没有拿到确定回应，不能证明目标系统没有执行。对于写操作，把unknown直接改成failed并重试，可能造成重复发送、重复下单或相反方向的补偿。

操作账本先保存意图与稳定业务ID，调用后记录receipt。发生不确定性时，查询目标系统的操作状态、唯一业务标识或最终记录；必要时人工对账。查询也可能延迟可见，因此要明确等待、重查和截止规则，而不是立即认定不存在。平台应向用户说明正在确认效果，避免误导其手工再做一次。

只读操作通常可以在预算内重试，但仍需留意计费、资源消耗和查询时间边界。写操作需要更严格分类：未发送、已发送未确认、已确认成功、已确认失败。只有能证明未执行或具备幂等保障时，才允许自动重新提交。补偿是新的业务动作，可能失败，也不能伪装成真正回滚。

测试可以让目标系统完成工作后故意丢弃响应，再观察Agent是否先read-back。还要测试目标查询暂时空、回执延迟、重复回调和人工已介入等情况。完成标准是业务最终状态与本地记录能够对齐，不是所有Attempt都必须得到即时成功。此状态设计直接决定恢复和取消是否可信。

面向用户的恢复按钮也要基于状态。unknown时不直接提供“再发送”作为默认选择，而应先展示查询结果或需要确认的风险。若用户明确决定再次执行，记录新的授权及其与原操作的关联。这样既不阻止合法工作，也避免界面把不确定性转化成无意识重复。

对账过程也需要deadline和owner，长期unknown不能无人处理。达到查询上限后进入人工队列，保留已知事实和每次查询结果。

实践重点：进入unknown并读回业务状态或人工对账；禁止直接标失败重放。

验证抓手：模拟响应丢失，检验read-back和人工接管。

常见误区：以HTTP断连推断外部操作没发生。

Temporal：执行状态与外部副作用；OpenCode：流、工具和取消源码。