CCA-F 练习题库· Tool Design & MCP Integration
你的 submit_payment 工具执行的是非幂等写入。在 agent 循环中，它可能会在一次结果不确定的瞬时超时之后被重试（该请求可能成功了，也可能没成功）。要避免重复写入，最稳妥的设计是什么？
- A让该工具接受一个由客户端提供的 idempotency key，使携带相同 key 的重试请求在写入边界处被去重，并返回能区分瞬时/状态不确定失败与确定性失败的结构化错误。
- B依赖 Claude 记住自己已经调用过该工具——把先前的 tool_use 与 tool_result 块保留在对话历史中，并指示它在再次发出 submit_payment 之前重新读一遍那段记录。
- C总是在工具内部不带 key 地立即重试写入，把该调用包在带 jitter、最多尝试五次后放弃的有界指数退避循环里，好让瞬时故障有时间恢复，因为该请求的 at-least-once 投递保证了正确性。
- D把所有重试逻辑推给模型：把原始超时以纯文本返回，并在 system prompt 中指示它对任何超时的 submit_payment 调用反复重发，直到最终看到一次成功响应为止。
- E把该工具做成 fire-and-forget：把付款交给后台 worker 并立即返回成功，从不向模型暴露错误，这样就压根不会出现看起来值得重试的失败。
正确答案：A
解析
对非幂等操作来说，重复写入的安全性必须在持久化写入边界上强制保证，而不是靠模型的记忆。
- A正确：由客户端提供的 idempotency key 让携带相同 key 的重试请求在服务端被去重，因此在状态不确定的超时之后重试也不会重复扣款；再配上把瞬时/状态不确定的失败与确定性失败区分开的结构化错误，调用方就能有意识地判断重试是否安全。每一个干扰项都无法保证 exactly-once 的副作用。
- B依赖 Claude 记住，没有任何持久的事务记录。
- CD是盲目重试或由模型驱动的重试，把 at-least-once 投递当成了正确性，恰恰会在超时这种情形下重复写入。
- E的 fire-and-forget 在隐藏错误的同时照样发出重复写入。
延伸阅读
本题为本站自有原创练习题，非任何官方考试内容；解析对照 Anthropic 公开文档撰写， 如与最新文档不符请以官方为准。想在限时环境下检验水平，可参加 模拟考（题目与本页题库不重叠）。