模块 10 — 架构师问答题（生产架构）
开放式问答题，模拟架构评审 / 面试深挖。每题附「答题要点」——先自己答，再对照要点补漏。引用均访问于 2026-08-30。
Q1. 你的 CEO 问：「我们的 Claude 应用能不能承诺 99.9% 可用性？」请从架构角度拆解这个问题。
🎯 学习重点：区分用户可感知可用与满质量可用，并从依赖链、降级和人工兜底解释 SLA。
答题要点：
- 先澄清可用性的分母与测量点（用户视角成功率，不是「API 通了」）；SLA 由你的编排层兑现，不是模型单点
- 拆解依赖链：网关 → 编排器 → Claude API（多个模型档位可选）→ 检索/工具 → 人工升级；每段有自己的失败模式与预算
- 兑现手段分层：重试（瞬时错误）→ 熔断（防雪崩）→ 降级（次级模型/无检索/模板）→ 升级（人工）；配合超时预算保证「快速失败快过挂着」
- 明确不可消除的风险：全平台 529、spend cap 触顶（无 retry-after，重试无效）——这两类只能靠预算冗余（多 tier/多 workspace）与降级吸收
- 结论模式：「99.9% 的用户可感知可用性可以设计，代价是降级期间质量分档 + 人工兜底成本；99.9% 的『满质量』不可承诺」
- 引用：https://platform.claude.com/docs/en/api/errors（529/spend cap 语义）
Q2. 设计日志方案时，你如何决定「prompt 原文」记不记？给出决策框架。
🎯 学习重点：默认元数据、内容独立开关，并以用途、加密限权和保留期限作为全文门槛。
答题要点：
- 默认不记原文，记元数据（request_id、trace_id、模型、usage、stop_reason、错误类型、耗时）
- 记原文的三个门槛：用途正当（调试/评估/合规取证）→ 存储合规（加密 + 保留期限 + 访问控制，独立于通用日志管道）→ 主动决策（内容级日志独立开关，默认关闭——官方 OTel 导出即此设计：prompt 正文/工具实参/工具输出各有开关）
- PII 处理：管道入口集中式 redaction（正则 + 类型识别），宁可记「一段疑似邮箱已脱敏」不记原文
- 折衷方案：采样留存（0.1% 全文样本供质量分析）、哈希留指纹（可比对不留内容）、结构化摘要（长度/语言/工具名单）
- 引用：https://code.claude.com/docs/en/agent-sdk/observability（内容级日志独立开关）
Q3. 解释 timeout budget 如何从顶层分配到一次多轮 agent 调用，并说明为什么每层独立设 30s 超时是反模式。
🎯 学习重点：展示预算逐层传递与剩余检查，并指出独立超时和嵌套重试的乘法放大。
答题要点：
- 顶层预算（如 8s）= 首次尝试 + 重试次数 ×（单次耗时 + 退避等待）+ 降级链耗时 + 余量
- 向下分配：编排器把剩余预算切给本轮 Claude 调用（streaming 首字节后可放宽）、工具调用（各自更小的子预算）、降级尝试
- 每层独立 30s 的反模式：L1 编排 30s + L2 调用 30s + L3 工具 30s，最坏叠加 90s 挂起；且重试会在各层独立发生，次数相乘
- 实现要点：预算对象随调用链传递、每步前检查剩余、耗尽即走降级（不再「再试最后一次」）
- 与 504 的关系：官方建议长请求改用 streaming 降低超时概率（来源: https://platform.claude.com/docs/en/api/errors）
Q4. 什么时候用 circuit breaker，什么时候只用 retry？两者的保护对象有什么不同？
🎯 学习重点：retry 保护单次请求，circuit breaker 保护系统与上游恢复空间。
答题要点：
- retry 保护单次请求的瞬时抖动（429 限流/500/529/连接错误），期望「再试一次就好」
- circuit breaker 保护系统对：连续失败说明上游系统性异常，继续打请求是火上浇油（529 全平台过载时全量重试 = thundering herd）；open 态快速失败 → 降级路径，把上游恢复的空间让出来
- 何时只要 retry：失败率低且独立（偶发 500）、无降级路径可用、离线任务
- 何时加熔断：上游故障有相关性（过载、区域故障）、有可用的 fallback、用户在线等待（挂着不如降级）
- 调参要点：阈值（失败次数/失败率）、冷却时长、half-open 探测流量；太敏感会在正常抖动时误开
- 引用：https://platform.claude.com/docs/en/api/rate-limits（平缓爬坡、避免加速度限制）
Q5. 给出「模型分层路由 (model tiering)」的完整决策依据——为什么不能只按价格选模型？
🎯 学习重点：用任务难度、质量、延迟、单价、限额和 evals 成功率构成完整决策函数。
答题要点：
- 决策函数 = 任务难度 × 质量要求 × 延迟要求 × 单价 × 吞吐限额，而不是单价单变量
- 分层实操：意图分类/格式化/路由 → Haiku 档；主回答 → Sonnet 档；复杂推理/长程 agent → Opus/Fable 档（官方对四档的定位与价格，截至 2026-08-30，来源: https://platform.claude.com/docs/en/models/overview）
- 必须用 evals 校准：同一 golden dataset 在各档的通过率 × 每千次请求成本，才能算出「便宜但多轮纠错」是否真的便宜
- 路由器本身可以是小模型（分类成本要计入总账）
- 灰度与回退：档位切换是配置变更，走灰度 + 回归评估（10.5）
- 隐藏成本：档位越多，评估矩阵与监控标签越多——过度分层是新的复杂度
Q6. 公司要把 50 万条历史工单「全部重新打标签」，预算审批只过了半价方案。你怎么设计？
🎯 学习重点：选择 Batches、按双上限拆批、叠加共享前缀缓存并只重提失败子请求。
答题要点：
- 这是 Batches API 的教科书场景：异步、不需要实时、大批量（单批上限 100,000 请求或 256MB，可分批）、全量 50% 计价（来源: https://platform.claude.com/docs/en/build-with-claude/batch-processing）
- 叠加优化：工单共享的指令前缀开 1h TTL prompt caching（官方对共享上下文批的明确建议），写入 ×2 但批内大量请求命中读取 ×0.1
- 注意 batch 硬约束：不能带
stream、fast mode、Threads、max_tokens: 0；多数批 1 小时内完成，24h 未完成过期，结果保留 29 天——流程要处理「部分请求 expired」
- 可靠性：批内每个请求独立处理、可混不同类型；失败的子请求单独重提，不必重跑全批
- 验收：抽样人工复核 + 与旧标签对比的一致率，而不是全量盲信
Q7. 模型被 deprecated 了，但你的 prompt 在新模型上行为漂移。给出迁移工作流。
🎯 学习重点：从 golden dataset 到 staging、稳定哈希灰度、回滚和旧模型用量审计形成迁移闭环。
答题要点：
- 时间线：官方至少 60 天通知（来源: https://platform.claude.com/docs/en/about-claude/model-deprecations）——把回归评估排在退役日远早前
- 工作流：① 冻结 golden dataset（覆盖线上真实分布 + 边角案例）→ ② 新模型跑全集，对比通过率/格式合规/工具调用正确率/成本 → ③ 行为漂移处先调 prompt（版本化），调不过的用「路由补丁」（该类请求暂时留旧档/升高档）→ ④ staging 全链路验证 → ⑤ 灰度 1%→5%→25%→100%（稳定哈希），新旧分标签对比 → ⑥ 异常一键回滚（旧模型退役前仍可用）
- 组织面：Usage Export CSV 审计还有哪些负载在旧模型上（官方推荐动作）；与安全/合规同步（模型变更可能触发评审）
Q8. 画出并解释你的生产参考架构中「Escalation Queue」的进出协议。
🎯 学习重点：输入要带结构化失败上下文，输出要回写状态与审计，并监控升级率。
答题要点：
- 进（触发条件四类）：低置信（校验失败/groundedness 不过）、不可逆操作、降级链打穿、合规复核点
- 进（消息结构）：原始请求（脱敏后）、已尝试路径与结果、失败原因、trace_id/request_id、用户上下文、优先级、SLA 时钟
- 出（人工处置）：处置动作（放行/修改/拒绝/退款等）→ 回写状态层 → 审计日志；处置结论可回流为 evals 用例（升级是质量信号富矿）
- 容量设计：升级率是核心监控指标——异常升高 = 系统性退化（模型漂移/检索变差/prompt 回归），要告警而不是只加人
- 与模块 9 呼应：Claude Code 的 deny/审批体系是同一思想在开发工具侧的产品化
Q9. 「我们直接把 Claude API 的响应存进数据库当审计记录。」指出这个方案至少三个问题。
🎯 学习重点：从决策上下文、敏感数据、关联 ID、版本和防篡改五个维度反驳。
答题要点：
- ① 混淆「数据留存」与「审计记录」：审计需要的是决策上下文（为什么走这条路径、当时配置/模型版本），不只是最终响应
- ② PII/密钥风险：响应可能包含用户原文、检索回来的敏感内容；审计库访问面广，原文入库扩大泄露面——需要 redaction + 加密 + 期限策略
- ③ 缺少对账锚点：没有 request_id/trace_id 的裸响应无法与 Anthropic 侧（报障）或内部指标对账
- ④ 版本缺失：不记模型/prompt 版本，三个月后无法回答「当时用的什么行为」
- ⑤ 完整性：审计记录需要防篡改与不可抵赖属性（哈希链/写一次存储），普通业务库不提供
Q10. 成本上涨 300% 告警响了。给出你的排查顺序（从最快确认到最深入）。
🎯 学习重点：按用量结构、缓存、路由、重试、发布变更顺序缩小范围，并保留预算兜底。
答题要点：
- 用量结构：Usage & Cost Admin API / Console 按模型、key、feature 拆分——定位是「量涨了」还是「单价结构变了」（来源: https://platform.claude.com/docs/en/manage-claude/usage-cost-api）
- 缓存命中率：是否缓存断点被改动/前缀里混入动态内容（时间戳/随机 ID）导致命中崩塌——回看
usage 里 cache_read_input_tokens 占比
- 路由漂移：分层路由是否把大量低价值请求送到了高档模型（路由器 prompt 回归/配置错误）
- 重试风暴：错误率上升导致重试放大（重试也在烧 token）；检查 429/529 趋势与熔断器状态
- 回归/事故：某次发布改了 max_tokens、把长文档全量塞上下文、或 agent 循环失去停止条件
- 兜底：spend limit（自设 400 / tier 429）是否需要临时调整 + 与变更记录（配置版本）交叉定位
📚 目录