2026 年被反复复述的一句判断是：所有主流 Agent 框架都"模型无关"了。结论本身没错——OpenAI Agents SDK 从 v0.0.12 起接入 LiteLLM、AutoGen 0.4 把模型封装成 ChatCompletionClient 协议、LangGraph 的 with_structured_output 号称跨厂商一致、CrewAI 底层直接吃 LiteLLM。任何框架都能"调用"任何模型。但这恰恰掩盖了真正的成本："可调用"不等于"不掉能力"。当 Agent 从一等模型（OpenAI Responses API、Claude 原生 Messages API）切换到通用通道时，它会静默丢失一批对 Agent 成败攸关的能力——推理项（reasoning items）、原生并行工具调用、结构化输出确定性、流式部分 JSON、计算机使用、实时语音。本文把这种"接线通了、语义没通"的差，称为模型无关税（Model-Agnostic Tax），并横评 OpenAI Agents SDK、LangGraph、CrewAI、AutoGen 0.4、Claude Agent SDK，外加作为"逃生舱"的 LiteLLM 网关。
判断模型无关性，不能只看框架"支不支持别的厂商"，要看它在哪一层做抽象。这是整套横评的度量尺：
flowchart LR
subgraph L1["Native 原生级"]
A1["直调厂商专属API"] --> A2["推理项/实时/原生工具全保留"]
A2 -.换模型即失效.-> A3["能力丢失: 断崖"]
end
subgraph L2["Adapter 适配级"]
B1["自有统一接口"] --> B2["结构化输出/工具调用后端不一"]
B2 -.语义漂移.-> B3["能力丢失: 缝隙"]
end
subgraph L3["Gateway 网关级"]
C1["统一OpenAI兼容端点"] --> C2["只解决接线不解决语义"]
C2 -.隐藏耦合.-> C3["能力丢失: 不可见"]
end
L1 --> L2 --> L3
ChatModel、AutoGen 的 ChatCompletionClient），各厂商写适配器。换模型是一行代码，但不同后端的结构化输出与工具调用实现机制不同，存在 feature parity 缝隙。关键洞察：等级越高越"模型无关"，也越远离厂商最锋利的能力。这就是税的来源——你用"可移植性"换取了"能力天花板"。
| 框架 / 版本 | 模型无关等级 | 一等模型 | 结构化输出机制 | 换模型后丢失/降级的能力 |
|---|---|---|---|---|
| OpenAI Agents SDK | Native | OpenAI（Responses API） | Responses API 原生 + guardrails | 推理项、原生并行工具、realtime 语音、computer use |
| Claude Agent SDK | Native | Claude（Messages API） | 工具调用强制 schema | 思考 token、原生工具、MCP 深度集成 |
| LangGraph | Adapter | OpenAI（默认） | with_structured_output（3 后端） |
厂商特有能力需手动 bind_tools |
| CrewAI | Gateway→Adapter | LiteLLM 任选 | LiteLLM JSON 模式 | 锁死在 chat completions 语义 |
| AutoGen 0.4 | Adapter | OpenAI / Azure | reflect_on_llm_messages |
厂商推理协议支持参差 |
| LiteLLM | Gateway | 100+ 厂商 | OpenAI 兼容 response_format |
仅接线层，语义问题透传 |
OpenAI Agents SDK 默认走 Responses API，并以 Chat Completions 作为备选后端。它的官方模型文档明确给出两条路：推荐的 OpenAIResponsesModel（享推理项、原生并行工具调用、gpt-realtime 实时语音、computer use）与 OpenAIChatCompletionsModel。当你要接非 OpenAI 模型时，要么自建 model_providers，要么经 LiteLLM 注入——但两者最终都回退到 Chat Completions 语义。
from agents import Agent, Runner
# 原生一等路径: 享推理项/原生并行工具/realtime
agent = Agent(name="R", model="gpt-4o-mini")
# 切到 LiteLLM 注入的 Claude/Ollama: 回退 ChatCompletionsModel
# -> 推理项(reasoning items)静默丢失
# -> 原生 computer use 不可用
# -> 流式 reasoning delta 消失
问题在于，Responses API 上那些最"Agent 友好"的能力恰恰绑死在专属协议上。一旦离开，reasoning 字段不再返回、previous_response_id 上下文管理失效、原生工具的确定性下降。这就是 Native 级框架的典型账单：你用最高的人效换来了最深的厂商锁定。叠加 OpenAI 已宣布 2026 年 8 月 26 日下线 Assistants API、全量迁往 Responses API，意味着锁定还在加深而非松绑。
Claude Agent SDK 走 Anthropic Messages API，一等公民是 Claude。它的工具调用天然用 JSON schema 强约束（这是它结构化输出的主力机制），思考（thinking）token、MCP 工具、prompt caching 都是原生集成。换到非 Claude 模型时同样回退到兼容层。它的模型无关税形态与 OpenAI 对称：原生能力越强，越没有第二个厂商能复现。值得一提的是它的 MCP 一等支持——这在多智能体工具生态里是稀缺资产，但同样是绑定源。
LangGraph（与 LangChain）是 Adapter 级的标杆，ChatModel 抽象覆盖几十家厂商，换模型常常真是一行代码。但 with_structured_output 在不同后端用的是三种不同实现机制：OpenAI 走 response_format（JSON Schema / 函数），Anthropic 走工具调用强制 schema，部分模型只能靠 JSON 模式提示词。同样一行 .with_structured_output(Schema)，确定性、是否校验、失败重试行为都不一样。
LangChain 仓库至今仍挂着 issue #33743"Unified Structured Output and Tool-Calling Interface"——这本身证明 parity 缝隙是官方都承认的工程债。代码层看不出差异：
from langchain_openai import ChatOpenAI
s = llm.with_structured_output(Schema) # OpenAI: response_format 原生约束
# 同代码换 llm=ChatAnthropic(): 走 tool-calling schema, 校验/重试语义微差
# 换某开源模型: 可能仅提示词 JSON, 无强约束
LangGraph 的代价不是"能不能换"，而是"换了之后你必须为每个后端单独验证工具调用与结构化输出的确定性"。这层隐藏成本在跨厂商灰度、A/B 模型时尤其咬人。
CrewAI 把模型无关问题直接外包给 LiteLLM：每个 Agent 一个 llm 参数，底层统一走 LiteLLM 的 OpenAI 兼容通道。这让"装好就跑"的体验在六栈里最好，新人半小时能起一个多角色协作 Agent。但代价是它整层锁死在 chat completions 语义——既拿不到 Responses API 的推理项，也用不好 Claude 的思考 token，更别说 realtime/computer use。CrewAI 的模型无关税不是"丢能力"，而是"压根没接触到那些能力"。对快速原型和单团队验证，这完全可接受；对要榨干模型上限的生产系统，它是天花板。
AutoGen 0.4 把模型抽象成 ChatCompletionClient 协议，官方文档列出 OpenAI、Azure OpenAI、Anthropic、Ollama、Azure AI Foundry、GitHub Models、Semantic Kernel 一长串客户端。它的协议化是六栈里最规整的——自定义厂商只要实现协议即可接入，社区已有 LocalOpenAIChatCompletionClient 接 Ollama 的范例。
但协议只保证"消息进消息出"，不保证"高级能力对齐"。各家推理模型（reasoning）协议差异巨大，AutoGen 的 reflect_on_llm_messages 在不同厂商上行为不一；并行工具调用、流式部分 JSON 的支持取决于客户端实现质量。AutoGen 的税体现在协议正确但能力薄：你能插任何模型，却不能保证它们在多智能体辩论、代码执行回环里表现一致。
LiteLLM 已成为事实上的统一 LLM 网关（约 45.9K star，覆盖 100+ 厂商），是 CrewAI、OpenAI Agents SDK LiteLLM 集成、众多企业逃逸厂商锁定的共同底座。它把"接线"问题解决得近乎完美：一个端点、虚拟密钥、预算限流、故障转移、缓存。但它有两个不被提及的税。
第一是安全税：2026 年 6 月 8 日，CISA 将 CVE-2026-42271 加入 KEV 目录——一个在链式利用下可导致未认证 RCE 的漏洞，修复需升到 1.83.7 并把 Starlette 升到 1.0.1。任何把 LiteLLM 当控制平面的团队都得立刻打补丁，因为网关一旦沦陷，所有下游 Agent 的密钥与流量全部暴露。
第二是语义税：LiteLLM 只把请求统一成 OpenAI 兼容格式，不翻译语义。当你经 LiteLLM 让一个为 Claude 设计的 Agent 调用某开源模型时，工具调用 schema、response_format、思考字段会按 OpenAI 语义被"翻译"，框架却以为自己在跟原生厂商对话——隐藏耦合由此而生。接线越顺，这类失败越难定位。
下表是"换模型后保留程度"的能力矩阵，依据各框架官方文档对能力支持项的陈述归纳（非实时压测，旨在呈现语义级差异）：
flowchart TD
subgraph CAP["换非一等模型后能力保留度"]
direction LR
R1["推理项 reasoning"]:::low
R2["原生并行工具"]:::mid
R3["结构化输出确定性"]:::mid
R4["流式部分JSON"]:::low
R5["计算机使用/realtime"]:::none
R6["基础对话+单工具"]:::high
end
classDef high fill:#c8e6c9
classDef mid fill:#fff9c4
classDef low fill:#ffccbc
classDef none fill:#ef9a9a
| 能力点 | OpenAI Agents SDK | Claude SDK | LangGraph | CrewAI | AutoGen 0.4 | LiteLLM 网关 |
|---|---|---|---|---|---|---|
| 基础对话+单工具 | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
| 结构化输出 | ⚠️降级 | ⚠️降级 | ⚠️后端差异 | ⚠️仅JSON | ⚠️协议差异 | ⚠️透传 |
| 原生并行工具 | ❌ | ❌ | ⚠️需bind | ❌ | ⚠️客户端实现 | ❌ |
| 推理项/思考 | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| 流式部分JSON | ❌ | ❌ | ⚠️ | ❌ | ⚠️ | ❌ |
| computer use/realtime | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
读法：✅稳定保留 / ⚠️行为漂移需验证 / ❌基本丢失。结论很硬——基础对话谁都能换，但凡涉及"Agent 区别于聊天机器人"的能力（推理、原生并行工具、实时、结构化确定性），换非一等模型就要付费。LiteLLM 网关列全是⚠️/❌，正印证它只通接线不通语义。
按场景给选型，把"模型无关税"摆到台面上权衡：
ChatCompletionClient 协议化最规整，自定义厂商接入最顺，注意推理协议参差。一句话收口：2026 年"能不能换模型"已不是问题，"换了之后还剩多少能力"才是。选框架前先列你的 Agent 必须保住的能力点，再对照能力保留矩阵——凡是矩阵里标❌的能力对你的 Agent 是刚需，就别相信"模型无关"这四个字。
ChatCompletionClient 协议与支持的厂商客户端清单with_structured_output 跨厂商机制差异[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。