[78] HTTP Semantics（RFC 9110）：把请求/重试/状态码写成可推理的契约

• 原始来源：https://www.rfc-editor.org/rfc/rfc9110
• 对应章节：第 7 章（工程化）、第 9 章（后端架构）

一句话摘要

HTTP 的语义决定了你能不能安全地重试、能不能正确缓存、以及客户端/代理会不会误解你的意图；在 AI 产品里，这会直接影响幂等、计费、工具调用与可观测性。

你应该从这里带走什么（面向产品）

• 错误语义也是体验：用户看到的不是 500/502，而是我现在能不能自救、会不会重复扣费、要不要重试。
• 可解释的失败：当你的产品需要可回滚、可对账、可追责，错误语义必须稳定且可推理。

工程落地要点（可执行）

• 先定义可重试边界：哪些操作是幂等的，哪些不是；重试会不会引发重复副作用（重复扣费、重复写入、重复执行工具）。
• 统一状态码策略：让客户端/SDK/Agent 可以根据状态码做正确决策（重试/降级/提示/停机）。
• 把错误与请求关联：让每个失败都能回放到 request_id/trace_id，否则你无法治理与对账。

常见误用提醒

• 把 500 当万能兜底：短期省事，长期会让重试策略、告警与用户恢复全部失效。