Provider 抽象 产品与架构

它是什么

Provider 抽象把不同厂商（OpenAI / Anthropic / 兼容服务）在端点、鉴权头、消息结构、响应解析、用量字段上的差异收进一个薄层，让业务代码只面对统一的形状。没有抽象会怎样：同一段「发消息拿回答」的逻辑要为每家写一遍、换厂商要改穿所有调用点、脑子里同时记着两套字段名。第 04 章用 OpenAI 与 Anthropic 的对照表展示了差异集中在「请求怎么构造、响应怎么解析」两端，而中间的业务语义相同——抽象要做的正是这两件事的翻译。

统一什么、保留什么

最小接口是 chat(messages) → {text, stopReason, usage: {inputTokens, outputTokens}}。统一的是形状，不是语义：finish_reason 与 stop_reason 的枚举值不强行一一映射（'stop' 和 'end_turn' 都是「正常说完」，但 'tool_calls' 与 'tool_use' 是不一样的存在）。消息形状见 normalized-message，每家一层的翻译见 adapter，两家协议差异见 openai-compat 与 anthropic-messages-api。

在本教程的位置

第 04 章手写最小 Provider（刻意不带重试、超时、流式——那些是第 02、03 章讲过的独立关注点）；第 06 章在骨架上扩展「带工具的 chat」；fetchImpl 注入让抽象可测试——判题时注入脚本化 mock fetch，不联网、不用 API key 就能验证翻译对不对。

小结

一句话：Provider 抽象把「厂商各自叫法不同」收进一层翻译官，上层只面对 { chat }，换厂商只改一行。