核心 GUIDE
RISKINTERMEDIATE6 分钟阅读
Timeout 歧义
Timeout 只能证明没有及时观察到 Response，并不能证明远端 Operation 已经失败。
核心心智模型
Timeout 是 Communication Observation，而不是对 Remote Side Effect 的结论。
为什么重要
Distributed System 可能在成功工作后丢失 Response，也可能在 Caller 放弃之后继续处理，甚至可能在到达 Server 之前就失败。如果 Agent 把这些情况全部压成 FAILED，看似合理的 Retry 就可能重复触发付款、消息或其他不可逆 Side Effect。
01
一个 Timeout 背后的三种状态
Request 可能在执行前失败、已经成功但 Response 丢失，或者仍在运行。因此安全处理需要 Stable Operation Identity、可用时的 Idempotency，以及能够在再次触发 Side Effect 前查询 Authoritative Remote State 的 Reconciliation Path。
02
例子：重复退款
Refund Call 发生 Timeout。Agent 把它标记为 Failed，并使用新的 Operation Identity 重试。最终两次请求都结算成功，造成重复退款。如果第一步先建模为 UNKNOWN，再使用原 Operation ID Reconcile，就可以避免第二次 Side Effect。
常见失败模式
- 把所有 Timeout 直接映射为 FAILED。
- 每一次 Retry 都生成新的 Operation Identity。
- 在能够 Reconcile 之前就向用户报告确定失败。
工程启发
- 把模糊 Outcome 显式建模为 UNKNOWN 或 PENDING。
- 同一个 Intent 的 Retry 始终复用同一 Idempotency Key。
- 高成本 Side Effect 必须拥有 Authoritative Reconciliation Path。
关键结论
- 01缺少 Response 不等于确认远端失败。
- 02一个 Intent 拥有一个稳定 Identity 时，Retry 才更安全。
- 03Unknown 是合法 Runtime State，应该被明确建模。
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。
重复 Intent 的 Idempotency BoundaryPREREQUISITEGuide →
Retry Policy 与 Retry AmplificationPREREQUISITE