## 概述 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 网关。 ## 模型无关的三个等级 判断模型无关性，不能只看框架"支不支持别的厂商"，要看它在哪一层做抽象。这是整套横评的度量尺： ```mermaid 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 ``` - **Native（原生级）**：框架直接调用某厂商专属 API（OpenAI Agents SDK 之于 Responses API、Claude Agent SDK 之于 Messages API），优先吃到厂商最新最强能力。代价是换模型即换语义，能力断崖式下跌。 - **Adapter（适配级）**：框架定义统一模型接口（LangChain 的 `ChatModel`、AutoGen 的 `ChatCompletionClient`），各厂商写适配器。换模型是一行代码，但不同后端的结构化输出与工具调用实现机制不同，存在 feature parity 缝隙。 - **Gateway（网关级）**：框架不动，用一个 OpenAI 兼容代理（LiteLLM）把所有厂商收编进一个端点。接线问题彻底解决，但语义问题原封不动甩给框架——而且网关本身是新的攻击面。 关键洞察：**等级越高越"模型无关"，也越远离厂商最锋利的能力**。这就是税的来源——你用"可移植性"换取了"能力天花板"。 ## 横评对比矩阵 | 框架 / 版本 | 模型无关等级 | 一等模型 | 结构化输出机制 | 换模型后丢失/降级的能力 | |---|---|---|---|---| | 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 的甜蜜陷阱 OpenAI Agents SDK 默认走 Responses API，并以 Chat Completions 作为备选后端。它的官方模型文档明确给出两条路：推荐的 `OpenAIResponsesModel`（享推理项、原生并行工具调用、`gpt-realtime` 实时语音、computer use）与 `OpenAIChatCompletionsModel`。当你要接非 OpenAI 模型时，要么自建 `model_providers`，要么经 LiteLLM 注入——但两者最终都回退到 Chat Completions 语义。 ```python 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：另一个原生锁定 Claude Agent SDK 走 Anthropic Messages API，一等公民是 Claude。它的工具调用天然用 JSON schema 强约束（这是它结构化输出的主力机制），思考（thinking）token、MCP 工具、prompt caching 都是原生集成。换到非 Claude 模型时同样回退到兼容层。它的模型无关税形态与 OpenAI 对称：**原生能力越强，越没有第二个厂商能复现**。值得一提的是它的 MCP 一等支持——这在多智能体工具生态里是稀缺资产，但同样是绑定源。 ### 三、LangGraph：抽象最厚，parity 缝隙最深 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 缝隙是官方都承认的工程债。代码层看不出差异： ```python from langchain_openai import ChatOpenAI s = llm.with_structured_output(Schema) # OpenAI: response_format 原生约束 # 同代码换 llm=ChatAnthropic(): 走 tool-calling schema, 校验/重试语义微差 # 换某开源模型: 可能仅提示词 JSON, 无强约束 ``` LangGraph 的代价不是"能不能换"，而是"换了之后你必须为每个后端单独验证工具调用与结构化输出的确定性"。这层隐藏成本在跨厂商灰度、A/B 模型时尤其咬人。 ### 四、CrewAI：最省心的代价是天花板最低 CrewAI 把模型无关问题直接外包给 LiteLLM：每个 Agent 一个 `llm` 参数，底层统一走 LiteLLM 的 OpenAI 兼容通道。这让"装好就跑"的体验在六栈里最好，新人半小时能起一个多角色协作 Agent。但代价是它**整层锁死在 chat completions 语义**——既拿不到 Responses API 的推理项，也用不好 Claude 的思考 token，更别说 realtime/computer use。CrewAI 的模型无关税不是"丢能力"，而是"压根没接触到那些能力"。对快速原型和单团队验证，这完全可接受；对要榨干模型上限的生产系统，它是天花板。 ### 五、AutoGen 0.4：协议化做得最干净，推理支持参差 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 网关：接线解了，安全与语义没解 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 语义被"翻译"，框架却以为自己在跟原生厂商对话——隐藏耦合由此而生。接线越顺，这类失败越难定位。 ## 能力保留矩阵（基于官方文档能力分析） 下表是"换模型后保留程度"的能力矩阵，依据各框架官方文档对能力支持项的陈述归纳（非实时压测，旨在呈现语义级差异）： ```mermaid 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 网关列全是⚠️/❌，正印证它只通接线不通语义。 ## 推荐方案 按场景给选型，把"模型无关税"摆到台面上权衡： - **要榨干单一厂商最强能力（推理/实时/原生工具）** → OpenAI Agents SDK 或 Claude Agent SDK。接受 Native 级锁定，因为你要的就是别人换不来的能力。 - **要生产级多模型灵活性、跨厂商灰度** → LangGraph + LiteLLM 网关。抽象最厚，parity 缝隙靠"每后端单独验证结构化输出/工具调用"来填。 - **快速原型/单团队验证、不在意天花板** → CrewAI。装好即跑，模型无关体验最佳，代价是接触不到高阶能力。 - **深度多智能体研究、要干净协议** → AutoGen 0.4。`ChatCompletionClient` 协议化最规整，自定义厂商接入最顺，注意推理协议参差。 - **统一逃逸锁定、做企业控制平面** → LiteLLM 网关（务必升到 1.83.7+ 打补丁 CVE-2026-42271），但它只解决接线，语义对齐仍要靠上层框架逐厂商验证。 一句话收口：2026 年"能不能换模型"已不是问题，**"换了之后还剩多少能力"才是**。选框架前先列你的 Agent 必须保住的能力点，再对照能力保留矩阵——凡是矩阵里标❌的能力对你的 Agent 是刚需，就别相信"模型无关"这四个字。 ## 参考来源 1. [Models — OpenAI Agents SDK 官方文档](https://openai.github.io/openai-agents-python/models/) — 说明 Responses API 与 Chat Completions 两种后端及非 OpenAI 模型接入路径 2. [Model Clients — AutoGen 官方文档](https://microsoft.github.io/autogen/stable/user-guide/core-user-guide/components/model-clients.html) — `ChatCompletionClient` 协议与支持的厂商客户端清单 3. [Structured output — LangChain 官方文档](https://docs.langchain.com/oss/python/langchain/structured-output) — `with_structured_output` 跨厂商机制差异 4. [BerriAI/litellm — GitHub 仓库](https://github.com/BerriAI/litellm) — 统一 100+ LLM 厂商的 OpenAI 兼容网关 5. [Amazon Bedrock now offers OpenAI models, Codex, and Managed Agents（AWS What's New, 2026-04）](https://aws.amazon.com/about-aws/whats-new/2026/04/bedrock-openai-models-codex-managed-agents/) — Bedrock 接入 OpenAI 模型与 Responses API 的厂商互通现状 6. [LiteLLM CVE-2026-42271 RCE 漏洞解读（2026-06）](https://andrew.ooo/answers/litellm-cve-2026-42271-rce-vulnerability-explained-june-2026/) — 网关安全面与 CISA KEV 收录、补丁版本说明 > [!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 等场景全覆盖。