本文信息来源于 Requesty，作者为 Thibault Jaigu，发布于 2026 年 6 月 23 日。原文是一篇第三方厂商撰写的 SDK 横向比较文章，不是 Anthropic 官方文档；其中关于排名、性能、成本、网关兼容性和商业收益的判断，均应理解为原作者和 Requesty 的观点。
原文认为，到 2026 年 6 月，生产 Agent 部署中主要有六类 SDK：LangGraph、CrewAI、OpenAI Agents SDK、Claude Agent SDK、Google ADK 和 Microsoft Semantic Kernel。它们都在解决同一个问题：如何构建能在生产环境稳定运行的 Agent，但架构侧重点不同。
这篇文章从架构、benchmark、token 效率和 AI gateway 兼容性几个角度比较这些 SDK，适合在选型新项目或评估迁移方案时参考。
六个 SDK 一览
| SDK | 架构 | 语言 | GitHub Stars | 最适合 | Gateway 支持 |
|---|---|---|---|---|---|
| LangGraph | 状态机图 | Python、TypeScript、Java | 14K+ | 生产级状态控制 | 任意 OpenAI-compatible URL |
| CrewAI | 基于角色的团队 | Python | 52K+ | 快速多 Agent 原型 | 任意 OpenAI-compatible URL |
| OpenAI Agents SDK | Agent loop + sandbox | Python、TypeScript | 27K+ | 沙箱执行、异步任务 | OpenAI 原生、自定义 endpoint |
| Claude Agent SDK | 工具丰富的 Agent loop | Python、TypeScript | 7.3K+ | 编码 Agent、文件和 shell 访问 | Anthropic 原生、自定义 base URL |
| Google ADK 2.0 | 图式工作流 | Python、TypeScript、Go、Java、Kotlin | 20K+ | 多 Agent 编排 | Gemini 原生、LiteLLM adapter |
| Semantic Kernel | Plugin / planner 架构 | C#、Python、Java | 24K+ | 企业 .NET 集成 | 任意 OpenAI-compatible URL |
LangGraph：生产级状态机
LangGraph 把 Agent 建模成有向图里的节点，并通过显式边定义控制流。开发者要明确写出步骤之间如何流转、错误如何路由、什么时候需要人工介入。这和“让 LLM 自己决定下一步”相反，LangGraph 更强调由代码控制执行路径。
为什么团队会选择 LangGraph
原文提到，Klarna 使用 LangGraph 运行客服 Agent，覆盖 8500 万用户，并声称平均问题解决时间下降 80%。LinkedIn、Uber 和 Replit 也被列为生产使用案例。
LangGraph 的关键优势是 interrupt() 原语。它可以在任意节点暂停执行，把完整状态持久化到 checkpoint store，并在人工审批或外部输入完成后恢复执行。对受监管工作流来说，这一点很重要：每个决策都可以审计，每次状态迁移都可以记录。
Token 效率
原文引用 AI Dev Day India 的 benchmark，称中等复杂度任务中，LangGraph 比 CrewAI 少用 30% 到 40% token。原因是 LangGraph 用代码逻辑在节点之间路由，而 CrewAI 更多依赖 LLM 调用来决定任务移交。
在一个“研究并总结”的标准流程里，原文称 CrewAI 在 100 次循环中仅编排 prompt token 就花费 4.10 美元，而 LangGraph 在路由决策上的开销接近 0。
延迟与可观测性
原文称，在负载测试下，LangGraph 每个节点增加约 120ms 编排开销，而 CrewAI 因为 LLM 驱动的任务委派，每次任务转换可能达到 450ms。
可观测性方面，LangGraph 与 LangSmith 原生集成，可以提供按节点拆解的完整状态迁移 trace。每个 checkpoint 都可以检查、重放和搜索。对需要审计链路的团队来说，这是原文认为最成熟的一套方案。
适用场景
当工作流存在条件路径、重试逻辑或人工审批 gate 时，LangGraph 更合适。如果需要能跨重启恢复的 checkpoint，或要在生产环境中使用监控、持久化、streaming，也可以优先考虑它。已经使用 LangChain 的团队，迁移成本也更低。
from langgraph.graph import StateGraph, END
graph = StateGraph(AgentState)
graph.add_node("research", research_agent)
graph.add_node("analyze", analysis_agent)
graph.add_node("human_review", human_review_node)
graph.add_edge("research", "analyze")
graph.add_conditional_edges("analyze", route_by_confidence)
graph.add_edge("human_review", END)
CrewAI：快速原型框架
CrewAI 把 Agent 建模成一个专家团队。每个 Agent 有 role、goal、backstory 和一组工具。Task 描述要做什么、由谁做；Crew 对象负责执行顺序。原文认为，一个能跑起来的双 Agent pipeline，大约 25 行代码就能写完。
为什么团队会选择 CrewAI
原文列举了 CrewAI 的 5.2 万 GitHub stars 和 10 万认证开发者等指标，并提到 NVIDIA 宣布过 “CrewAI Factory” 合作，用于 GPU 优化的 Agent 部署。CrewAI 还支持 Flows，这是一种较新的事件驱动 Agent pipeline 抽象，比默认的 sequential / hierarchical process mode 提供更多控制能力。
优势
如果任务可以自然映射成人类团队分工，比如 researcher、analyst、writer，CrewAI 的表达方式非常直观。它的学习曲线也较低，非工程人员阅读 Agent 定义后也能理解整体架构。
短板
CrewAI 的问题在于精确控制流。Sequential 和 hierarchical 模式能覆盖不少工作流，但如果要表达“第 3 步失败后，用不同参数重试第 1 步”这类逻辑，就需要额外绕路。
原文还认为 CrewAI 的 token 成本更高，并引用 benchmark 称，在 LangGraph 少于 2000 tokens 的任务上，CrewAI 可能需要约 4500 tokens。
适用场景
当你今天就需要一个能工作的 prototype、任务天然可以拆成专家角色、团队里有非工程人员需要理解 Agent 架构，或者你更重视代码可读性而不是细粒度控制时，CrewAI 是合适选择。
from crewai import Agent, Task, Crew
researcher = Agent(
role="Senior Research Analyst",
goal="Find the most relevant data",
tools=[search_tool, scrape_tool]
)
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, writing_task],
process=Process.sequential
)
result = crew.kickoff()
Claude Agent SDK：编码 Agent 专家
Claude Agent SDK 提供了驱动 Claude Code 的同一套工具、Agent loop 和上下文管理能力，并通过 Python 和 TypeScript 暴露给开发者。它内置了读取文件、运行 shell 命令、编辑代码、联网搜索、在代码库中匹配内容等工具，开发者不需要自己实现这些工具 handler。
内置工具目录
| Tool | 作用 |
|---|---|
| Read | 读取工作目录中的文件 |
| Write | 创建新文件 |
| Edit | 对已有文件做精确编辑 |
| Bash | 运行终端命令、脚本、git 操作 |
| Glob | 按 pattern 查找文件 |
| Grep | 用正则搜索文件内容 |
| WebSearch | 搜索当前信息 |
| WebFetch | 获取并解析网页内容 |
版本与 benchmark
原文写作时列出的版本是 2026 年 6 月 17 日的 v0.2.104。它还提到 TypeScript SDK 会捆绑一个原生 Claude Code binary，因此不需要单独安装 Claude Code。
Benchmark 方面，原文称 Claude Code 搭配 Opus 4.8 在 SWE-bench Verified 上达到 88.6%，在 SWE-bench Pro 上达到 69.2%；搭配 Fable 5 时分别达到 95.0% 和 80.3%。这些数字应视为原文引用的时点性说法，实际模型和 benchmark 结果需要重新核验。
Subagents 与 hooks
Claude Agent SDK 支持 subagent spawning，可用于并行执行任务；也支持 hook 系统，例如 PreToolUse、PostToolUse、Stop、SessionStart、UserPrompt。开发者可以在 Agent loop 的不同阶段注入自定义逻辑。
适用场景
如果你要构建编码 Agent，希望开箱即用地获得文件 I/O、shell 访问和代码编辑能力，同时不想自己实现工具 handler，那么 Claude Agent SDK 很合适。它尤其适合代码库理解、代码修改、自动化开发任务和命令行工作流。
如果团队主要模型供应方是 Anthropic，这条路径最自然；如果希望多模型调度，则需要通过 gateway 或自建适配层验证兼容性。
OpenAI Agents SDK：沙箱运行时
OpenAI Agents SDK 的思路和框架型 SDK 不完全一样。它不只是让多个工具在你的进程里编排，而是让 Agent 在沙箱环境中自主工作，并保留持久状态。
v0.14 和 v0.15 的关键能力
原文称 v0.14 引入了 Sandbox Agents，这是一组围绕 SandboxAgent、Manifest 和 SandboxRunConfig 设计的新接口。Agent 可以在持久隔离 workspace 中运行，支持文件、目录、Git repos、mounts、snapshots 和 resume。
沙箱后端包括本地 Unix、Docker 容器，以及 E2B、Modal、Cloudflare、Vercel、Daytona 等托管选项。
v0.15 则改进了模型拒答处理，把 refusal 显式暴露为 ModelRefusalError，而不是返回空文本或陷入 retry loop。
沙箱记忆
原文提到，Agent 可以通过 progressive disclosure 和多轮 memory grouping 复用之前运行中的经验，并配置隔离边界。持久化后端包括 S3、R2、GCS 和 Azure Blob Storage。
适用场景
如果你希望 Agent 在隔离沙箱里执行，尤其是代码执行或不可信 workload，OpenAI Agents SDK 更适合。如果你需要跨 Agent run 保留 workspace 状态，或者基础设施已经偏 OpenAI-native，并且希望和 GPT-5.5、Codex 紧密集成，也可以考虑这一路径。
Google ADK 2.0：图式编排器
Google ADK 在 2026 年 5 月 19 日发布 General Availability 的 v2.0。原文称，这个版本从层级 Agent executor 转向图式执行引擎。Agent、tools 和 functions 都会作为 workflow graph 中的节点被评估。这和 LangGraph 早前采用的架构方向类似，但它与 Gemini 生态有更深集成。
核心能力
Google ADK 支持用于确定性 Agent 执行的 graph-based workflows，也支持通过代码逻辑表达动态工作流、迭代循环和复杂分支。它还支持 coordinator agent 与多个 subagents 协作，并原生支持 Agent2Agent（A2A）协议，用于跨框架 Agent 通信。
语言与模型支持
Google ADK 支持 Python、TypeScript、Go、Java 和 Kotlin，是原文比较中语言覆盖面最广的 SDK。
模型方面，ADK 原生支持 Gemini，也可以通过 adapter 接入其他 provider。若要做多 provider 路由，原文建议通过 LiteLLM adapter 或 OpenAI-compatible endpoint 接入 AI gateway。
适用场景
如果团队需要最广泛的语言支持，Agent 运行在 Google Cloud 上，并且希望原生集成 Vertex AI，那么 Google ADK 更合适。如果你正在构建跨框架 Agent 系统，并想使用 A2A 协议，也可以考虑它。
Microsoft Semantic Kernel：企业连接器
Semantic Kernel 是 Microsoft 面向企业环境构建 AI Agent 的 SDK，尤其适合已经大量使用 .NET 和 Azure 的组织。它使用 plugin / planner 架构：AI 能力以 plugin 形式加入，kernel 负责规划执行步骤。
对企业的价值
原文认为，Semantic Kernel 的主要价值在于与 Azure OpenAI Service、Microsoft 365 和 Entra ID 的深度集成。如果组织的基础设施已经是 Microsoft stack，那么 Semantic Kernel 是一条自然的集成路径。
适用场景
当你使用 C# 或 Java 构建系统，基础设施以 Azure 为中心，并且需要企业身份管理和合规控制时，可以考虑 Semantic Kernel。
横向比较
| 维度 | LangGraph | CrewAI | Claude Agent SDK | OpenAI Agents SDK | Google ADK 2.0 | Semantic Kernel |
|---|---|---|---|---|---|---|
| 学习曲线 | 较陡 | 低 | 中 | 中 | 中 | 中 |
| Token 效率 | 最好，代码路由 | 最差，LLM 路由 | 好 | 好 | 好 | 好 |
| 编排开销 | 120ms | 450ms | N/A，原文称单 Agent | N/A，沙箱 | 接近 LangGraph | 接近 LangGraph |
| 多 Agent | 图边 | 角色型 crews | Subagents | Handoffs | Coordinator pattern | Plugin chaining |
| 状态持久化 | Checkpointing | 有限 | 基于 session | Snapshots + S3 | Session store | Azure storage |
| Human-in-the-loop | 原生 interrupt | Callback | AskUserQuestion tool | Human participant | Callback | Plugin |
| 可观测性 | LangSmith | LangFuse / AgentOps | Built-in tracing | Built-in tracing | Cloud Trace | Azure Monitor |
| Gateway 兼容 | 是 | 是 | 是 | 是 | 通过 adapter | 是 |
需要注意的是，表格里把 Claude Agent SDK 的编排开销写成 “N/A，单 Agent” 是一种简化说法。Claude Agent SDK 支持 subagents 和 delegation，只是它的编排模型不同于通用状态图框架。
AI gateway 如何连接不同 SDK
原文的核心商业主张是：每个 SDK 最终都会发起 LLM 调用，如果组织里同时使用多套 SDK，就会出现成本统计割裂、缺乏统一 failover、难以横向比较不同 Agent 类型模型效果等问题。
Requesty 作为 AI gateway 的方案是把所有 SDK 和模型 provider 之间的调用统一接入一个中间层。
统一成本追踪
所有 SDK 的 LLM 调用都走同一个 endpoint，因此可以在一个 dashboard 里按团队、SDK、模型查看成本拆分，减少多 provider 账单对账成本。
自动 failover
原文称，如果 Anthropic 在运行中不可用，Requesty 可以在 50ms 内切到 fallback chain 中的下一个模型，让 Agent loop 不至于直接崩溃。
这类能力在实际生产中需要谨慎验证，因为有状态 Agent loop 的 failover 不只是切换 endpoint，还可能涉及 replay、幂等性、上下文兼容、工具调用协议兼容和应用级恢复逻辑。
基于延迟和任务类型的路由
原文称，Requesty 的 latency routing 会按滚动窗口监测 provider 实时表现，并把请求发给最快的可用模型。对于一次任务包含上百次 LLM 调用的 Agent，累计节省的时间可能较明显。
它还提到，可以按任务类型做 smart routing，例如把代码生成发给更强模型，把简单分类发给更便宜的 flash 模型，以降低成本。
接入方式
原文声称，各 SDK 的集成方式相同：把 base URL 改成 router.requesty.ai/v1，再使用 Requesty API key。实际接入时，仍需逐项验证 SDK 的 tool contract、beta feature、认证方式、计费字段和模型行为是否兼容。
# LangGraph with Requesty
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
base_url="https://router.requesty.ai/v1",
api_key="your-requesty-key",
model="anthropic/claude-opus-4-8"
)
# CrewAI with Requesty
from crewai import LLM
llm = LLM(
model="openai/gpt-5.5",
base_url="https://router.requesty.ai/v1",
api_key="your-requesty-key"
)
决策矩阵：什么场景选什么 SDK
| 场景 | 推荐 SDK | 原因 |
|---|---|---|
| 带条件逻辑和人工审批的生产 Agent | LangGraph | Checkpointing、interrupt()、通过 LangSmith 审计 |
| 快速构建多 Agent 团队 prototype | CrewAI | 少量代码即可跑通，学习曲线最低 |
| 会编辑文件并运行命令的编码 Agent | Claude Agent SDK | 继承 Claude Code 的内置工具 |
| 带持久状态的沙箱代码执行 | OpenAI Agents SDK | SandboxAgent、snapshots、resume |
| Google Cloud 上的多语言团队 | Google ADK 2.0 | Python、TypeScript、Go、Java、Kotlin；原生 Vertex AI |
| Azure 上的企业 .NET 团队 | Semantic Kernel | C# 一等支持、Entra ID、Azure OpenAI |
| 任意上述场景，但需要多 provider 路由 | 任意 SDK + gateway | 通过统一 endpoint 接入多模型、failover 和成本统计 |
结论
原文认为，2026 年的 Agent SDK 生态已经不再是“只选一个框架”的阶段。很多生产团队会同时使用两三套 SDK：用 vendor SDK 获取原生工具能力，例如 Claude Agent SDK 做编码、OpenAI Agents SDK 做沙箱执行；再用 LangGraph 或 CrewAI 做多 Agent 编排。
对于我们自己的评测和框架建设，这篇文章最有参考价值的地方不在于它的商业结论，而在于它把 Agent SDK 的差异拆成了几个可评估维度：控制流、状态持久化、工具能力、human-in-the-loop、可观测性、成本、延迟和 gateway 兼容性。这些维度可以转化为后续 Claude Code / Agent SDK 层级评测框架里的能力层。
常见问题
2026 年最主要的 AI Agent SDK 有哪些？
原文列出的六个主流 AI Agent SDK 是 LangGraph、CrewAI、OpenAI Agents SDK、Claude Agent SDK、Google ADK 2.0 和 Microsoft Semantic Kernel。具体选择取决于部署需求：vendor SDK 适合使用原生工具能力，LangGraph 适合生产状态管理，CrewAI 适合快速多 Agent 原型。
哪个 Agent SDK 最适合生产部署？
原文认为 LangGraph 是最经过生产检验的选择。理由包括 Klarna 的大规模使用案例、显式边转移带来的 token 成本优势、内置 checkpoint、人机协同 interrupt()，以及通过 LangSmith 获得审计链路。
如何避免 Agent SDK 的 vendor lock-in？
原文建议把所有 Agent SDK 都接到统一 AI gateway，通过修改 base URL 和 API key 获得 provider failover、统一成本统计和模型切换能力。实际落地时，要验证每个 SDK 的工具协议、模型行为和状态恢复语义。
LangGraph 和 CrewAI 的区别是什么？
LangGraph 把 Agent 建模为状态图中的节点和显式边，因此更适合控制执行流、重试逻辑和人工审批 gate。CrewAI 把 Agent 建模为带角色和目标的团队成员，上手更快，但大规模和精细控制更难。原文称 LangGraph 在中等任务上可少用 30% 到 40% token，而 CrewAI 可以用更少代码快速做出 prototype。
编码 Agent 应该使用哪个 SDK？
原文认为 Claude Agent SDK 是编码 Agent 的强选择，因为它内置文件读写、bash 执行、代码编辑、WebSearch 和 grep 等能力，这些能力继承自 Claude Code runtime。若需要开源或多模型路线，也可以将 LangGraph 与 gateway 搭配使用。
