模块 3 架构师问答题 — Claude API 实战

每题先自己答，再看参考要点。场景题格式：Scenario / Constraints / Options / Best choice / Why / Why others are weaker / Tradeoffs / What would change the answer。

Q1. 场景题：夜间评估管线的可靠性升级

Scenario：每晚 20,000 次评估调用，目前循环调同步 Messages API，偶发 429/529 导致部分任务丢失，团队用 while True 无脑重试。 Constraints：结果次日 9 点前要出；预算紧；无实时性要求。 Options：(a) 加大重试次数 (b) Message Batches + 结果按 custom_id 对账 (c) 换更快模型 (d) 自建多线程并发 + 客户端限速 Best choice：(b)。 Why：批处理 50% 折扣、独立限流域、结果含 succeeded/errored/canceled/expired 四态可对账（errored 项可重入新批）；24h 过期与 29 天取结果满足次日出报告的节奏；max_tokens: 0 与 stream 不可入批（来源: https://platform.claude.com/docs/en/build-with-claude/batch-processing（访问于 2026-08-30））。 Why others are weaker： 加剧流量放大还烧钱； 无助于丢失问题； 仍走同步限流域。 Tradeoffs：延迟小时级、需要轮询/取结果逻辑；共享前缀记得用 1h TTL 缓存。 What would change the answer：若要求分钟级出结果 → 客户端令牌桶 + 指数退避。

Q2. 缓存命中率从 95% 掉到 0，你按什么顺序排查？

参考要点：

1. 前缀是否被改（时间戳、A/B 测试开关、工具定义变动——断点前任何字节变化 → hash 变）
2. tool_choice 是否变化（作废 messages 缓存；tools/system 保留）
3. TTL 是否被吃光（从请求开始计时；长流式响应 + 低频访问 → 5m 窗口错过；换 1h）
4. 是否低于最小可缓存长度（静默不缓存；看 cache_creation 与 cache_read 双 0）
5. 并发竞态：缓存条目要等第一个响应开始才可读——并行首批必然 miss

（来源: https://platform.claude.com/docs/en/build-with-claude/prompt-caching（访问于 2026-08-30））

Q3. 为什么"用 SDK"本身就是一个架构决策？裸 HTTP 什么时候合理？

参考要点：

• SDK 内置：认证头、默认 2 次指数退避重试（尊重 retry-after）、类型化异常、流式处理、超时与 TCP keep-alive、非流式 10 分钟校验（来源: https://platform.claude.com/docs/en/api/errors 与 overview（访问于 2026-08-30））——这些自己写全是坑
• 版本纪律：Python SDK v1.0+ 移除 temperature/top_p/top_k（传了 TypeError）——SDK 帮你挡参数弃用
• 裸 HTTP 合理场景：受限运行时/语言无 SDK、严格供应链审计、简单一次性脚本；代价是自己实现上述全部

Q4. 你的应用要发 60 秒内完成的"中等长度"响应，但网络环境经常掐 10 分钟空闲连接。怎么设计？

参考要点：

• 首选 streaming（哪怕不逐字渲染）：SDK get_final_message() 内部走流式保持连接活跃（来源: errors "Long requests"，同上）
• TCP keep-alive（SDK 已设）
• 或 Batch 轮询（不需要持续连接）
• 反模式：调大 HTTP 超时硬扛

Q5. 认证架构：API key 直接给每个微服务实例，有什么风险？更好的方案？

参考要点：

• 风险：key 扩散面大、无法按 workspace 隔离与控费、泄露后全组织受影响、轮换痛苦
• 更好：集中网关持有 key（实例用短期凭据）；Anthropic 侧用 workspaces 按用途隔离 + 多工作区 key 配 anthropic-workspace-id；无状态工作负载可用 Workload Identity Federation 短期 token（POST /v1/oauth/token 换 Authorization: Bearer）（来源: https://platform.claude.com/docs/en/api/overview（访问于 2026-08-30））
• 审计面：request-id + workspace 头贯穿日志

Q6. 重试设计里"计费不幂等"是什么意思？对预算控制有什么影响？

参考要点：

• Messages 请求重试无服务端副作用（不重复下单），但每次重试都计费——500 后重试 2 次 = 最多 3 倍 token 账单
• 影响：重试预算也是预算控制的一部分；监控要把"重试产生的 token"单独归因；spend-cap 429 例外（重试直接无效）
• 5 折 Batch 天然摊薄重试成本

Q7. 什么时候用自动缓存，什么时候用显式断点？给出决策规则。

参考要点：

• 自动（顶层 cache_control）：多轮对话、消息尾部变化、"不想维护断点"——断点自动前移到最后可缓存块
• 显式（block 级）：前缀分稳定段（tools/system/大文档）+ 易变尾；避免"最后一块每次都变"的自动缓存陷阱；需要 1h TTL 时指定
• 混用合法（自动占 4 槽之一）；两个都开时若最后块已有不同 TTL 的显式断点会 400（来源: prompt-caching 文档，同上）

Q8. 错误处理策略与用户体验如何联动？举三个分派例子。

参考要点：

• 429 普通：静默退避对用户无感；预算内自动排队
• 529/500：一次退避重试后仍失败 → 展示"服务繁忙"并保留用户输入
• refusal（stop_reason）或 403：不要原文展示给用户——转人审/换 phrasing；区别于 HTTP 错误（stop_reason 是 200 响应内的"完成方式"）
• 一切路径都记 request-id，用户报障可查