API 客户端:与 Anthropic API 的深度集成
深入 Claude Code 的 API 客户端——流式响应处理、模型选择与降级、Beta API、Token 计数与成本追踪、重试逻辑
问题引入
当你在 Claude Code 中输入一个问题,按下回车的那一刻,一连串精密的操作开始执行:系统构建消息数组,选择合适的模型,添加 Beta 头,通过 SSE 流接收响应,实时解析 token 使用量,计算费用,处理可能的 429/529 错误,必要时降级到备选模型。这一切在 1-2 秒内完成,用户只看到文本开始流出。
Claude Code 的 API 客户端不是简单的 HTTP 封装——它是一个包含重试、降级、缓存、成本追踪、多 Provider 适配的复杂系统。本文深入分析这个系统的每一层。
API 客户端层次结构
多 Provider 客户端
Claude Code 支持四种 API Provider,每种有不同的认证和配置方式:
客户端初始化考虑了调试需求——当标准错误输出为调试模式时,SDK 日志会重定向到 stderr:
Beta Headers 管理
Claude Code 使用了大量 Beta API 功能,通过 anthropic-beta header 声明:
这些 Beta 功能包括:
| Beta Header | 功能 |
|---|---|
CONTEXT_1M_BETA_HEADER | 1M token 上下文窗口 |
CONTEXT_MANAGEMENT_BETA_HEADER | API 端上下文管理 |
FAST_MODE_BETA_HEADER | 快速模式(降低延迟) |
EFFORT_BETA_HEADER | Effort 控制(调整推理深度) |
PROMPT_CACHING_SCOPE_BETA_HEADER | Prompt 缓存作用域 |
REDACT_THINKING_BETA_HEADER | Thinking 内容脱敏 |
STRUCTURED_OUTPUTS_BETA_HEADER | 结构化输出 |
TASK_BUDGETS_BETA_HEADER | 任务预算控制 |
AFK_MODE_BETA_HEADER | 离开模式(后台运行优化) |
Extra Body 参数
用户可以通过 CLAUDE_CODE_EXTRA_BODY 环境变量注入额外的 API 参数:
注意 shallow clone——safeParseJSON 使用 LRU 缓存,直接修改返回值会污染缓存,导致后续调用看到被修改的值。
Prompt 缓存控制
Prompt 缓存可以按模型粒度控制:
这种按模型禁用的设计源于实际需求——某些模型的缓存创建成本可能不划算(比如 Haiku 本身就很便宜,缓存的创建费用反而更高)。
重试系统
重试逻辑是 API 客户端最复杂的部分,定义在 withRetry.ts 中。
重试配置
前台 vs 后台查询源
不是所有查询都应该重试。后台查询(摘要、标题生成、分类器)在 529 错误时立即放弃——它们不是用户在等待的结果,重试只会放大容量级联:
重试状态机
Fast Mode 降级
Fast Mode 是一种低延迟模式。当遇到限流时,系统需要决定是等待(保持缓存命中)还是降级(切换到标准速度):
决策逻辑:
- retry-after < 阈值 → 短等待,保持 fast mode(保护 prompt cache 不失效)
- retry-after >= 阈值或未知 → 进入冷却期,切换标准速度
- Overage 限制 → 永久禁用 fast mode
认证错误恢复
认证恢复涵盖了所有 Provider 的特殊情况:
- Anthropic 1P — 401 时刷新 OAuth token
- AWS Bedrock — 403 或 CredentialsProviderError
- GCP Vertex — 凭证刷新失败
- 连接重置 — ECONNRESET/EPIPE 时禁用 keep-alive 并重连
529 连续错误与模型降级
连续 3 次 529 后触发模型降级(如 Opus → Sonnet)。FallbackTriggeredError 被 query.ts 捕获并处理——清除已有的 assistant 消息,切换模型,重试整个请求。
持久化重试(无人值守模式)
对于自动化场景(CI/CD、cron 任务),系统支持无限重试:
持久化重试通过 SystemAPIErrorMessage 发送心跳,防止宿主环境(如容器编排系统)将会话标记为空闲。
成本追踪
每次 API 响应都会更新成本状态:
成本计算通过 calculateUSDCost 函数基于每个模型的价格表:
成本状态不仅用于显示——它在会话切换时保存到项目配置,恢复时读回:
Bootstrap API
启动时,系统通过 Bootstrap API 获取服务端配置:
Bootstrap 返回的数据包括:
client_data— 客户端配置additional_model_options— 额外可用模型列表
5 秒超时确保启动不会因为网络问题而卡住。
流式响应处理
query.ts 中的主循环通过 for await...of 消费流式响应。关键的处理逻辑包括:
Fallback 处理
当流式传输过程中触发模型降级时,已收到的部分消息需要被丢弃:
Tombstone 消息告诉 UI 和 transcript 移除这些部分消息——特别重要的是移除不完整的 thinking blocks,因为它们带有模型特定的签名,在降级到不同模型后会导致 API 错误。
错误抑制与恢复
某些 API 错误是可恢复的——系统在流式循环中抑制这些错误,在流结束后尝试恢复:
被抑制的消息仍然加入 assistantMessages 数组——恢复逻辑需要检查它们。但不会发送给 SDK 消费者,因为这些消费者(如桌面应用)可能在看到错误后终止会话。
请求构建细节
Tool Schema 转换
每个工具的定义需要转换为 API 兼容的格式,包含 deferred tools 的处理:
Advisor 模式
当启用 Advisor 时,额外的模型(如 Opus 作为 Sonnet 的顾问)会参与决策:
Session Activity 追踪
API 请求期间会标记 session 为活跃状态,用于远程环境的资源管理:
小结
Claude Code 的 API 客户端是一个多层防御系统:
- 多 Provider 抽象 — Anthropic/Bedrock/Vertex/Foundry 统一接口,环境变量配置
- 分层重试 — 按错误类型(认证/限流/过载/连接重置)采取不同策略
- 智能降级 — Fast Mode → 标准速度 → 备选模型,每一步都有合理的决策逻辑
- 流式错误抑制 — 可恢复错误不立即暴露给消费者,给系统恢复的机会
- 成本全链路追踪 — 从 API 响应到项目配置持久化,支持会话恢复
- 运维旋钮 — Prompt 缓存、Fast Mode、重试策略等都可通过环境变量和 Feature Flag 控制
这个系统的复杂性不是偶然的——它反映了生产环境 AI 应用面临的现实:网络不可靠、服务会过载、认证会过期、用户需要不间断的体验。每一层防护都对应着一个真实的故障模式。