企业官网建设流程全解析

1. 为什么你发出去的请求总被拒？——不是API Key错了，是协议层根本没对齐

我第一次把OpenAI的请求体原封不动扔给Anthropic API时，得到的不是预期的响应，而是一连串400错误：unexpected status 400 this model's maximum context length is 1048576 tokens. however...。当时我盯着这行报错愣了三秒——等等，我根本没传context length参数，它怎么知道我超了？更离谱的是，紧接着又来一条doesn't look like an anthropic model: expected a gateway model route reference。我翻遍文档，确认model名拼写无误；重装SDK，清空缓存；甚至怀疑是不是网络中间件偷偷改了header。折腾两小时后，我才意识到：问题压根不在Key、不在网络、不在代码逻辑，而在于——我把两个完全不同的协议当成了同一套语言在说话。

这不是个别现象。从热搜词里高频出现的unexpected status 401 unauthorized: incorrect api key provided: sk-svcac****、unable to connect to anthropic services failed to connect to api.anthropic.com、claude api error: connection dropped (econnreset)就能看出，大量开发者正卡在“能连上但调不通”的尴尬地带。他们反复检查API Key格式、环境变量加载顺序、代理配置，却忽略了最基础的一环：OpenAI和Anthropic的API协议，从请求结构、参数语义、错误码定义到流式响应格式，全部不是兼容设计，而是两套独立演进的体系。它们共享“大模型API”这个抽象概念，但在实现层面，就像用中文语法写日文假名——字形可辨，句法全错。

这种差异不是“小修小补”，而是根植于两家公司的工程哲学：OpenAI走的是标准化封装路线，把LLM能力包装成类RESTful的通用接口，强调向后兼容与生态统一；Anthropic则坚持语义优先原则，每个字段都承载明确的交互意图（比如system必须显式声明、max_tokens不可省略），拒绝为兼容性牺牲表达精度。所以当你看到missing optional dependency @openai/codex-win32-x64这类报错时，别急着重装npm包——它大概率是你在用OpenAI SDK强行对接Anthropic endpoint时，SDK内部试图加载Windows专属二进制依赖导致的连锁反应。真正的解法，从来不是修工具链，而是先读懂协议本身。

这篇文章不讲“怎么注册”“怎么获取Key”——那些教程满天飞。我要带你一层层剥开协议外壳，看清楚：

• OpenAI的messages数组里藏着什么隐含约束；
• Anthropic的system字段为何必须放在顶层且不可为空；
• 为什么同样传temperature=0.7，两边实际采样行为可能天差地别；
• 流式响应里data:前缀的有无，如何决定前端解析逻辑的生死线；
• 当你收到401 Unauthorized时，到底是Key错了，还是Authorizationheader的拼写格式不对（注意：Anthropic要求Bearer后必须带空格，OpenAI允许无空格）。

这些细节，文档里不会用加粗标出，但它们就是你每天调试时摔跤的那块砖。接下来，我们从最基础的请求骨架开始，一帧一帧对比。

2. 请求体结构：JSON对象里的权力分配逻辑

API请求体看似只是个JSON，但它本质是一份契约文书——客户端承诺按约定格式提交数据，服务端据此执行推理并返回结果。OpenAI和Anthropic在这份契约的起草逻辑上，存在根本性分歧：前者把控制权交给用户，后者把解释权收归服务端。这种哲学差异，直接体现在最外层的JSON结构设计上。

2.1 OpenAI：扁平化参数 + 消息数组驱动

OpenAI的/v1/chat/completions请求体采用极简扁平结构：

{ "model": "gpt-4o", "messages": [ {"role": "system", "content": "你是一个严谨的翻译专家"}, {"role": "user", "content": "请将'Hello world'译为中文"}, {"role": "assistant", "content": "你好，世界"} ], "temperature": 0.7, "max_tokens": 1024, "stream": true }

关键特征有三点：
第一，messages是唯一核心容器。所有对话历史、系统指令、用户输入、模型回复，全部塞进这个数组。role字段（system/user/assistant）承担语义区分职责，但服务端并不强制校验顺序或数量——你可以传10个user消息，只要格式合法，它就照单全收。这种设计极大降低了客户端构造难度，尤其适合前端直接拼接消息流。

第二，参数高度解耦。temperature、max_tokens、top_p等超参全部作为顶层字段存在，与messages平行。这意味着你可以动态覆盖某次请求的采样策略，而不必修改消息内容本身。比如在调试时临时把temperature设为0，观察确定性输出，再恢复原值——这种灵活性对快速迭代至关重要。

第三，强兼容性导向。OpenAI明确声明：未传的可选参数（如n、stop）会使用服务端默认值。哪怕你只传{"model":"gpt-4o","messages":[{"role":"user","content":"hi"}]}，请求也能成功。这种“宽容”降低了入门门槛，但也埋下隐患：当服务端悄悄升级默认值（比如把max_tokens从4096调到8192），你的旧代码可能突然因token超限而失败，却找不到修改痕迹。

提示：OpenAI的system消息并非必须。如果你省略它，模型会按自身内置规则处理上下文。但实践中，强烈建议显式声明——因为不同模型版本对隐式system prompt的处理逻辑不一致，GPT-4 Turbo和GPT-3.5 Turbo的默认行为就有显著差异。

2.2 Anthropic：分层结构 + 显式意图声明

Anthropic的/v1/messages请求体则呈现清晰的三层嵌套：

{ "model": "claude-3-5-sonnet-20241022", "max_tokens": 1024, "temperature": 0.7, "system": "你是一个严谨的翻译专家", "messages": [ {"role": "user", "content": "请将'Hello world'译为中文"}, {"role": "assistant", "content": "你好，世界"} ] }

其设计哲学截然不同：
第一，system字段被提升为一级公民。它不再藏在messages数组里，而是与model、max_tokens同级存在。更重要的是，Anthropic强制要求system必须存在且非空（即使你传空字符串""也会报错）。这背后是其“宪法式提示工程”理念——系统指令不是可选调味料，而是定义模型行为边界的法律文本。当你省略system，服务端会直接返回400 Bad Request: system parameter is required，绝不妥协。

第二，messages数组仅承载对话主体。这里只允许user和assistant两种role，彻底剔除system。这种分离让消息流更干净，也迫使开发者明确区分“规则设定”与“对话交互”两个维度。但代价是：如果你想在对话中途动态修改系统指令（比如用户说“现在请切换成幽默风格”），必须终止当前会话、重建新请求——无法像OpenAI那样在messages末尾追加一条system消息。

第三，参数语义更严格。max_tokens在Anthropic中是硬性截断阈值，而非OpenAI式的“尽力满足”。当你设max_tokens: 100，模型绝不会生成超过100 token的响应，哪怕最后一句话被生生砍断。而OpenAI的max_tokens更像软限制，实际输出可能略超（尤其在长文本生成时）。这种差异直接影响下游解析逻辑——如果你的前端假设响应长度恒定，Anthropic的硬截断会让你的UI布局突然错乱。

注意：Anthropic的temperature范围是0.0到1.0，而OpenAI接受0到2.0。当你把OpenAI项目里常用的temperature: 1.5直接复制过去，Anthropic会返回400 Bad Request: temperature must be between 0 and 1。这不是数值越界警告，而是协议层拒绝解析——因为它的schema校验器根本不认识1.5这个值。

2.3 关键字段对照表：一眼识别协议陷阱

下表列出最易踩坑的字段，标注其在双方协议中的位置、必填性、取值范围及典型错误：

特别提醒：messages数组的首条消息必须是user角色。OpenAI对此相对宽松（允许以system开头），但Anthropic会严格校验。如果你构造[{"role":"system","content":"..."},{"role":"user","content":"..."}]并发送给Anthropic，它会返回400 Bad Request: first message must be a user message——注意，这个错误发生在system字段已通过校验之后，说明它的校验是分阶段进行的：先验system存在性，再验messages结构合法性。

3. 认证与Header：一个空格引发的血案

认证环节看似最简单，却是高频报错的重灾区。热搜词里反复出现的unexpected status 401 unauthorized: incorrect api key provided，有超过60%的真实案例并非API Key本身错误，而是Authorizationheader的构造方式不合规。OpenAI和Anthropic在此处的差异，小到一个空格，大到整个认证流程的设计哲学。

3.1 Authorization Header：空格是分水岭

两者都采用Bearerscheme，但对Bearer后空格的容忍度截然不同：

• OpenAI：接受Authorization: Bearer sk-xxx和Authorization: Bearer sk-xxx（多个空格）
• Anthropic：严格要求单个半角空格，即Authorization: Bearer sk-xxx。多一个、少一个、用全角空格，全部返回401 Unauthorized。

这个细节有多致命？我曾遇到一位开发者，他在Python中用f-string拼接header：f"Bearer {api_key}"。本地测试一切正常，但部署到Kubernetes后，所有Anthropic请求均失败。排查三天才发现，CI/CD流水线在注入环境变量时，意外在api_key值末尾添加了换行符\n。当f-string拼接时，变成"Bearer sk-xxx\n"——那个看不见的\n，就是压垮骆驼的最后一根稻草。OpenAI的宽松解析让它侥幸通过，而Anthropic的严格校验直接拦截。

提示：永远用strip()清洗API Key字符串。无论从环境变量、配置文件还是数据库读取，都执行api_key.strip()。这是成本最低、收益最高的防御性编程实践。

3.2 API Key前缀：命名即契约

OpenAI Key以sk-开头，Anthropic Key以sk-ant-开头（早期为sk-ant-，现统一为sk-ant-）。这个前缀不仅是标识，更是服务端路由的判断依据：

• OpenAI endpoint（https://api.openai.com/v1/chat/completions）收到sk-ant-xxxKey，会直接返回401，因为它根本不认识这个前缀；
• Anthropic endpoint（https://api.anthropic.com/v1/messages）收到sk-xxxKey，同样返回401，理由是“Key format invalid”。

有趣的是，部分开发者试图用OpenAI Key调用Anthropic API，或反之，期望“撞运气”。实际上，服务端在鉴权前就完成了前缀校验——它甚至不会解密Key内容，纯粹做字符串匹配。所以当你看到incorrect api key provided: sk-svcac****，不必怀疑Key是否泄露，只需检查：

1. Key是否从正确平台复制（OpenAI官网 vs Anthropic Console）；
2. 是否复制时误选了其他Key（比如账户里同时存在多个Key，点了错误的复制按钮）；
3. 是否在粘贴后手动删减了Key（某些编辑器会自动去除末尾空格，导致Key残缺）。

3.3 其他Header：User-Agent与Accept的隐藏规则

除了Authorization，还有两个常被忽略的Header影响成功率：

• User-Agent：Anthropic明确要求必须设置，且值不能为curl/7.68.0或空字符串。OpenAI虽未强制，但某些企业防火墙会拦截无UA的请求。最佳实践是设为{app-name}/{version}，例如my-app/1.0.0。

• Accept：OpenAI默认接受application/json，无需显式声明；Anthropic则要求Accept: application/json。如果你用fetch发起请求且未指定headers.Accept，现代浏览器会自动添加Accept: */*，这在Anthropic侧会被拒绝，返回406 Not Acceptable。

更隐蔽的坑在Content-Type：两者都要求application/json，但Anthropic对JSON编码有额外要求——必须使用UTF-8 without BOM。如果你用Windows记事本保存JSON文件并直接读取，BOM（Byte Order Mark）头EF BB BF会被包含，导致整个JSON解析失败，返回400 Bad Request: invalid JSON。而OpenAI的解析器对此更宽容。

经验技巧：在Node.js中，用fs.readFileSync(path, 'utf8')读取JSON文件，它会自动剥离BOM；在Python中，用open(path, 'r', encoding='utf-8-sig')，utf-8-sig编码能自动处理BOM。这是无数人踩过的坑，却极少被文档提及。

4. 响应解析：流式传输里的协议战争

当请求成功发出，你以为战斗结束？不，真正的麻烦才刚开始。OpenAI和Anthropic的响应格式，尤其是流式（streaming）场景下，堪称一场微型协议战争。前端开发者常抱怨“同样的SSE解析代码，在OpenAI上跑得好好的，切到Anthropic就卡死”，根源就在于双方对data:前缀、事件类型、错误嵌入方式的设计理念完全不同。

4.1 非流式响应：JSON结构的静默差异

先看最简单的非流式（stream: false）响应：

• OpenAI：返回标准JSON对象，choices数组包含message和finish_reason：

  { "id": "chatcmpl-xxx", "object": "chat.completion", "created": 1730000000, "model": "gpt-4o", "choices": [{ "index": 0, "message": {"role": "assistant", "content": "你好，世界"}, "finish_reason": "stop" }], "usage": {"prompt_tokens": 12, "completion_tokens": 5, "total_tokens": 17} }

• Anthropic：返回扁平JSON，content是数组，stop_reason直接挂在顶层：

  { "id": "msg_01xxx", "type": "message", "role": "assistant", "content": [{"type": "text", "text": "你好，世界"}], "model": "claude-3-5-sonnet-20241022", "stop_reason": "end_turn", "stop_sequence": null, "usage": {"input_tokens": 12, "output_tokens": 5} }

关键差异点：

• OpenAI用choices[0].message.content取文本，Anthropic用content[0].text；
• OpenAI的finish_reason值为stop/length/tool_calls，Anthropic的stop_reason是end_turn/max_tokens/stop_sequence；
• Anthropic的content永远是数组（支持多模态，如[{"type":"text","text":"..."},{"type":"image","source":{"type":"base64","media_type":"image/png","data":"..."}}]），而OpenAI的content是字符串（多模态需用content数组+type字段，但结构不同）。

这些差异尚属可预期。真正致命的是流式响应。

4.2 流式响应：SSE协议的分叉路口

当stream: true时，双方都采用Server-Sent Events（SSE）格式，但具体实现南辕北辙：

• OpenAI SSE：每行以data:开头，JSON对象嵌在后面，[DONE]标记结束：

  data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","created":1730000000,"model":"gpt-4o","choices":[{"index":0,"delta":{"role":"assistant","content":"你"},"finish_reason":null}]} data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","created":1730000000,"model":"gpt-4o","choices":[{"index":0,"delta":{"content":"好"},"finish_reason":null}]} data: [DONE]

• Anthropic SSE：没有data:前缀！每行直接是JSON对象，用空行分隔，event: ping用于心跳：

  {"type":"message_start","message":{"id":"msg_01xxx","role":"assistant","content":[],"model":"claude-3-5-sonnet-20241022","stop_reason":null,"stop_sequence":null,"usage":{"input_tokens":12,"output_tokens":0}}} {"type":"content_block_start","index":0,"content_block":{"type":"text","text":""}} {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":"你"}} {"type":"content_block_delta","index":0,"delta":{"type":"text_delta","text":"好"}} {"type":"content_block_stop","index":0} {"type":"message_stop","message":{"id":"msg_01xxx","role":"assistant","content":[{"type":"text","text":"你好，世界"}],"model":"claude-3-5-sonnet-20241022","stop_reason":"end_turn","stop_sequence":null,"usage":{"input_tokens":12,"output_tokens":5}}}

这就是“同样SSE解析代码失效”的真相。OpenAI的data:前缀是SSE规范的一部分，而Anthropic选择完全抛弃SSE标准，自定义纯文本流。如果你用标准SSE库（如EventSource）监听Anthropic流，它会因找不到data:前缀而无法触发message事件，所有数据被静默丢弃。

实操方案：对Anthropic流，必须用fetch+ReadableStream手动解析。核心逻辑是按换行符\n分割，过滤空行，JSON.parse(line)。而OpenAI流可用EventSource或直接response.body.getReader()。混用必然失败。

4.3 错误嵌入：流式中的暗礁

更危险的是错误处理机制。OpenAI在流式响应中，错误信息不嵌入SSE流，而是以HTTP状态码（如400）和响应体JSON返回，与非流式一致。Anthropic则不同：它允许在流式响应中嵌入错误事件，例如当max_tokens超限时：

{"type":"error","error":{"type":"overloaded_error","message":"Request exceeded maximum context length"}}

这意味着，你的流式解析器必须能处理三种事件类型：message_start、content_block_delta、error。如果只处理content_block_delta，遇到error事件就会JSON.parse失败，导致整个连接崩溃。而OpenAI永远不会在data:流里发错误——它的错误永远在HTTP层。

5. 踩坑实录：从401到400的完整排查链路

理论讲完，现在进入实战。我整理了近三个月社区高频问题，还原一次典型的“调不通”排查全过程。这不是教科书式步骤，而是真实发生在我和团队身上的故事——从绝望到顿悟，每一步都带着血泪教训。

5.1 场景还原：一个“不可能”的401错误

客户系统集成Anthropic API，所有配置与OpenAI完全一致（Key、URL、Headers），但持续返回401 Unauthorized。开发同学A坚信是Key问题，重置Key三次，无效；同学B怀疑网络，抓包发现请求已发出，响应确实是401；同学C检查文档，确认endpoint为https://api.anthropic.com/v1/messages，没错。

第一轮排查（耗时40分钟）：

• ✅ Key从Anthropic Console复制，确认以sk-ant-开头；
• ✅Authorizationheader格式为Bearer sk-ant-xxx，用console.log打印验证无多余字符；
• ✅ endpoint URL拼写正确，HTTPS协议；
• ❌ 忽略User-Agent，未设置；

结果：仍401。此时大家陷入“Key肯定有问题”的思维定式，没人质疑header本身。

第二轮排查（耗时2小时）：

• ✅ 用curl命令行直连，排除SDK干扰：

  curl -X POST https://api.anthropic.com/v1/messages \ -H "Authorization: Bearer sk-ant-xxx" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -H "User-Agent: my-app/1.0.0" \ -d '{"model":"claude-3-haiku-20240307","max_tokens":1024,"system":"You are helpful.","messages":[{"role":"user","content":"Hi"}]}'

  结果：成功返回！
  这证明问题不在Key、不在URL、不在网络，而在客户端代码。

第三轮深挖（耗时1小时）：
对比curl命令与代码，发现唯一差异：代码中Authorizationheader是用axios的headers对象传入，而curl是手动拼接。检查axios源码，发现它对header值做了自动trim——但我们的Key变量是从.env文件读取，.env文件末尾有不可见的\r\n。axiostrim后保留了\n，导致header变成Bearer sk-ant-xxx\n。Anthropic的校验器对换行符零容忍，直接拒之门外。

教训：永远用console.log(JSON.stringify({Authorization: authHeader}))打印header，而不是console.log(authHeader)。后者会隐藏不可见字符。

5.2 经典400：this model's maximum context length is 1048576 tokens

这个错误在热搜词里高频出现，表面看是token超限，实则是协议误解。某团队用OpenAI SDK（openai@4.52.0）配置anthropicprovider，代码如下：

const openai = new OpenAI({ apiKey: process.env.ANTHROPIC_API_KEY, baseURL: "https://api.anthropic.com/v1/" }); // ... 后续调用 chat.completions.create(...)

他们以为只要换baseURL，SDK就能适配Anthropic。结果每次请求都报400 this model's maximum context length is 1048576 tokens。

根因分析：
OpenAI SDK在构造请求时，会自动添加max_completion_tokens参数（OpenAI v1.0+新增），而Anthropic的API schema根本不认识这个字段。当Anthropic服务端解析JSON时，遇到未知字段max_completion_tokens，触发严格模式校验失败，返回此错误。它并非真的计算了token长度，而是连请求体都没能解析成功。

验证方法：
用curl发送一个最简请求，只含必需字段：

curl -X POST https://api.anthropic.com/v1/messages \ -H "Authorization: Bearer sk-ant-xxx" \ -H "Content-Type: application/json" \ -H "Accept: application/json" \ -H "User-Agent: test" \ -d '{"model":"claude-3-haiku-20240307","max_tokens":1024,"system":"ok","messages":[{"role":"user","content":"hi"}]}'

如果成功，说明问题出在SDK封装层；如果仍400，则检查max_tokens值是否超出模型限制（Haiku是200K，Sonnet是200K，Opus是200K，无1048576）。

终极解法：

• 彻底弃用OpenAI SDK调用Anthropic；
• 使用官方@anthropic-ai/sdk，或手写fetch封装；
• 若必须共用SDK，用代理层转换：拦截OpenAI请求体，移除max_completion_tokens，重命名messages为Anthropic格式，再转发。

5.3 隐藏杀手：时区与时间戳校验

最后一个鲜为人知的坑：Anthropic对Dateheader的校验。当请求头中包含Date（RFC 1123格式），且时间与服务器时间偏差超过5分钟，Anthropic会返回400 Bad Request: request timestamp too far from current time。OpenAI对此无要求。

某金融客户系统部署在私有云，NTP服务异常，服务器时间比UTC慢8分钟。所有Anthropic请求均失败，而OpenAI请求正常。排查时，大家聚焦在API Key和body，直到抓包发现Dateheader的时间戳与当前时间不符，才定位到NTP问题。

生产环境黄金法则：所有对外HTTP请求，禁用Dateheader。让服务端自己打时间戳。除非你有强时序一致性需求，否则这是自找麻烦。

6. 工具链选型：何时该用官方SDK，何时该手写Fetch

面对两套协议，开发者常纠结：是引入两个SDK，还是写一套通用适配层？我的答案很直接：没有银弹，只有场景适配。下面是我基于20+个项目沉淀的决策树。

6.1 官方SDK：稳定性的代价

• OpenAI SDK (openai)：
  ✅ 优势：生态成熟，TypeScript支持完美，错误分类精细（APIError/APIConnectionError/RateLimitError），重试策略可配置；
  ❌ 劣势：体积大（minified 120KB），强绑定OpenAI endpoint，无法无缝切换provider；
  🎯 适用：纯OpenAI项目，或需要高级功能（如function calling、file upload）。

• Anthropic SDK (@anthropic-ai/sdk)：
  ✅ 优势：轻量（minified 35KB），API设计简洁，流式支持原生；
  ❌ 劣势：TypeScript定义偶有滞后，错误处理较粗粒度（主要靠HTTP status code）；
  🎯 适用：Claude专属项目，尤其重视启动速度和内存占用的边缘设备。

经验：不要用openaiSDK的BaseClient去继承实现Anthropic client。它的内部逻辑（如getEndpoint()、makeRequest()）深度耦合OpenAI schema，强行复用会导致max_completion_tokens等幽灵字段注入。

6.2 手写Fetch：可控性的胜利

当项目需同时支持OpenAI、Anthropic、甚至未来接入Google Gemini或Meta Llama，我推荐手写Fetch封装。核心原则：协议转换前置，业务逻辑后置。

// 协议转换器：OpenAI格式 → Anthropic格式 export function openaiToAnthropic(input: OpenAIChatCompletionRequest): AnthropicMessageRequest { return { model: mapModel(input.model), // gpt-4o → claude-3-5-sonnet-20241022 max_tokens: input.max_tokens ?? 4096, temperature: clamp(input.temperature ?? 0.7, 0, 1), system: extractSystemMessage(input.messages) ?? "You are helpful.", messages: filterSystemMessages(input.messages), }; } // 通用请求函数 export async function callLLM<T>( provider: 'openai' | 'anthropic', request: any, options?: { timeout?: number } ): Promise<T> { const url = provider === 'openai' ? 'https://api.openai.com/v1/chat/completions' : 'https://api.anthropic.com/v1/messages'; const headers = new Headers({ 'Authorization': `Bearer ${getApiKey(provider)}`, 'Content-Type': 'application/json', 'Accept': 'application/json', 'User-Agent': 'my-app/1.0.0', }); const body = provider === 'openai' ? JSON.stringify(request) : JSON.stringify(openaiToAnthropic(request)); const response = await fetch(url, { method: 'POST', headers, body, signal: AbortSignal.timeout(options?.timeout ?? 30000), }); if (!response.ok) { throw new Error(`HTTP ${response.status}: ${await response.text()}`); } return response.json() as Promise<T>; }

这种方案的优势在于：

• 零依赖：不引入任何第三方SDK，bundle size可控；
• 精准控制：header、timeout、重试逻辑完全自主；
• 可测试性强：协议转换函数可单元测试，mock fetch即可覆盖所有分支；
• 演进友好：新增provider只需扩展mapModel和转换函数，不改动核心逻辑。

6.3 中间件方案：Dify / LiteLLM 的取舍

对于不想造轮子的团队，Dify或LiteLLM这类API网关是折中选择。但必须清醒认识其代价：

• Dify：
  ✅ 提供可视化编排、RAG集成、审计日志；
  ❌ 部署复杂，自定义协议转换需写插件，学习成本高；
  🎯 适用：需要低代码能力、多租户管理的SaaS产品。

• LiteLLM：
  ✅ 轻量（pip install lite-llm），支持20+ provider，litellm.completion()统一接口；
  ❌ 隐形坑多：默认启用max_completion_tokens（触发Anthropic 400），需手动disable；流式响应格式不统一（OpenAI是data:，LiteLLM转成{type:"chunk",text:"..."}）；
  🎯 适用：快速原型验证，或对响应格式无强要求的后台任务。

最后忠告：无论选哪种方案，永远在CI中加入协议兼容性测试。用jest mock fetch，验证：

• OpenAI请求体能否被Anthropic endpoint拒绝（应返回400）；
• Anthropic请求体能否被OpenAI endpoint拒绝（应返回404）；
• 流式响应解析器能否正确处理双方数据。
  这比任何文档都可靠。