1. 选型现场LangGraph 与 Semantic Kernel 到底差在哪如果你正在用 Python 搭 AI 智能体大概率会在 LangGraph 和 Semantic Kernel 之间反复横跳。我最近帮两个团队做技术选型评审发现大家卡住的点高度一致不是不知道两个框架能做什么而是不知道自己的业务形态该匹配哪一种抽象。LangGraph 把 Agent 系统建模成一张有状态图节点是 Python 可调用对象或子图边是状态转换状态本身是一个类型化对象在图的每一步流转并更新。Semantic Kernel 的起点是 Kernel 抽象一个容纳 AI 服务、插件和函数的容器插件是暴露给模型和 Agent 的函数组来源可以是原生 Python 代码、提示模板或外部导入的 schema。这两种思维模型带来的直接差异是LangGraph 里持久性是运行时的职责checkpointer 在每一步持久化状态相同的 thread_id 会自动从上次保存的位置恢复Semantic Kernel 里状态管理是开发者的职责记忆存放在 ChatHistory 对象中由调用方自行维护并在每次调用时传入运行时不负责持久化。我实测下来这个差异在单轮问答里几乎无感但一旦涉及崩溃恢复、人工审查、并行子 Agent代码复杂度会迅速拉开。选型时还有一个容易被忽略的维度是 MCP 工具接入。Semantic Kernel 从 v1.28.1 开始为 Python 加入了一等 MCP 支持SDK 原生兼任 MCP 客户端和服务端支持 stdio、SSE、WebSocket 多种传输方式可以把多个 MCP server 链在一起也能把 SK 函数或 Agent 暴露为 MCP server。LangGraph 的 MCP 思路侧重部署层面部署到 LangGraph Platform 后每个 Agent 会自动在 /mcp 端点暴露为 MCP 可访问的服务自托管场景下则通过 langchain-mcp-adapters 包集成。如果你需要在 Python 进程内部使用 MCP 语义SK 更合适如果 Agent 的定位是被其他客户端通过 MCP 消费的已部署服务LangGraph 更契合。这篇内容面向的是正在做真实决策的 Python 技术团队。我会先给出两套可复制的环境配置与最小可运行示例再演示如何通过 TaoToken 统一 Key/API 通道完成模型调用验证最后用同一场景在两个框架中的实现差异做横向对照。你跟着做能在本地跑通选型基准测试而不是停留在文档对比。2. TaoToken 前置统一 Key 与 API 通道准备在跑通两个框架之前先把模型调用通道统一掉。LangGraph 和 Semantic Kernel 都支持 OpenAI 兼容接口这意味着你可以用同一套 Base URL 和 Key 驱动两个框架避免在选型阶段因为模型接入方式不同而引入额外变量。TaoToken 提供的就是这样一个统一入口官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 端点是 https://taotoken.net/api 。你需要准备三样东西Base URL、API Key、Model ID。Base URL 填 https://taotoken.net/api API Key 在控制台的 API Keys 页面创建Model ID 根据你实际要验证的模型填写。这三个值在两个框架里的配置方式不同但底层都是 OpenAI 兼容协议所以只要通道通了框架层的差异就能被隔离出来。先创建 Key。打开 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 进入 API Keys 管理页新建一个 Key 并复制保存。注意 Key 只在创建时完整显示一次后续无法再次查看明文。如果你需要先确认模型列表和可用性可以到模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 直接测试确认通道正常后再写进代码。环境变量建议统一命名两个框架共用export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api export TAOTOKEN_MODEL_IDgpt-4o-mini这里有个坑我踩过LangGraph 的 init_chat_model 对 base_url 的读取依赖 langchain-openai 的版本旧版本可能不识别环境变量需要显式传参。Semantic Kernel 的 OpenAIChatCompletion 则要求 base_url 不带尾部斜杠否则拼接路径时会出现双斜杠导致 404。下面两节的配置片段里我会把这两个细节都处理掉。如果你后续要做长期编码或 Agent 项目可以了解 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它面向的是持续性的编码场景和本文的一次性选型验证是不同用途。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到参数不确定时优先查文档。3. 可复制配置两套环境与最小示例这一节给出两个框架的完整配置和最小可运行代码。你可以把两段代码放在同一个项目里用不同的虚拟环境隔离依赖避免版本冲突。3.1 LangGraph 环境与带检查点的天气 Agent先建虚拟环境并安装依赖python -m venv venv-langgraph source venv-langgraph/bin/activate pip install -U langgraph langchain[openai]然后是完整示例。注意 init_chat_model 的 base_url 通过 model_kwargs 传入这是 langchain-openai 较新版本的写法import os from langgraph.prebuilt import create_react_agent from langgraph.checkpoint.memory import InMemorySaver from langchain.chat_models import init_chat_model def get_weather(city: str) - str: Get the current weather for a given city. return fIts sunny and 28C in {city}. model init_chat_model( openai:gpt-4o-mini, temperature0, base_urlos.environ[TAOTOKEN_BASE_URL], api_keyos.environ[TAOTOKEN_API_KEY], ) checkpointer InMemorySaver() agent create_react_agent( modelmodel, tools[get_weather], promptYou are a helpful weather assistant., checkpointercheckpointer, ) config {configurable: {thread_id: user-session-1}} response agent.invoke( {messages: [{role: user, content: What is the weather in Mumbai?}]}, configconfig, ) print(response[messages][-1].content) followup agent.invoke( {messages: [{role: user, content: How about Delhi?}]}, configconfig, ) print(followup[messages][-1].content)create_react_agent 在底层编译出一个包含模型-工具循环的 StateGraph。checkpointer 在每一步持久化状态相同的 thread_id 会自动从上次保存的位置恢复。如果你把 InMemorySaver 换成 SqliteSaver 或 PostgresSaver进程崩溃后用同一个 thread_id 重启即可从最后的检查点继续持久性由运行时负责业务代码不需要操心。3.2 Semantic Kernel 环境与带 Plugin 的天气 Agent另开一个虚拟环境python -m venv venv-sk source venv-sk/bin/activate pip install semantic-kernel完整示例import asyncio import os from semantic_kernel import Kernel from semantic_kernel.agents import ChatCompletionAgent from semantic_kernel.connectors.ai.open_ai import ( OpenAIChatCompletion, OpenAIChatPromptExecutionSettings, ) from semantic_kernel.connectors.ai import FunctionChoiceBehavior from semantic_kernel.functions import kernel_function from semantic_kernel.contents import ChatHistory class WeatherPlugin: kernel_function(nameget_weather, descriptionGet the weather for a city.) def get_weather(self, city: str) - str: return fIts sunny and 28C in {city}. kernel Kernel() kernel.add_service( OpenAIChatCompletion( ai_model_idos.environ[TAOTOKEN_MODEL_ID], api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL].rstrip(/), ) ) settings OpenAIChatPromptExecutionSettings() settings.function_choice_behavior FunctionChoiceBehavior.Auto() kernel.add_plugin(WeatherPlugin(), plugin_nameWeatherPlugin) agent ChatCompletionAgent( kernelkernel, nameWeatherAssistant, instructionsYou are a helpful weather assistant., ) async def run_agent(): history ChatHistory() history.add_user_message(What is the weather in Mumbai?) async for message in agent.invoke(history): print(fAgent: {message.content}) history.add_message(message) history.add_user_message(How about Delhi?) async for message in agent.invoke(history): print(fAgent: {message.content}) history.add_message(message) asyncio.run(run_agent())Kernel 充当依赖容器集中管理 AI 服务与插件。kernel_function 装饰器让 Python 方法可被模型自动发现和调用FunctionChoiceBehavior.Auto() 指示模型按需触发函数。记忆存放在 ChatHistory 对象中由调用方自行维护并在每次调用时传入运行时不负责持久化。3.3 配置对照表配置项LangGraphSemantic KernelBase URL 传参init_chat_model 的 base_urlOpenAIChatCompletion 的 base_url尾部斜杠无要求必须 rstrip(/)Key 读取api_key 参数api_key 参数Model IDopenai:gpt-4o-mini 前缀格式ai_model_id 纯模型名状态持久化checkpointer thread_idChatHistory 手动维护工具注册tools 列表传函数kernel_function add_plugin这张表是我实际调试后整理的尤其是 Model ID 的格式差异LangGraph 需要 provider 前缀SK 只要模型名写错会直接报模型不存在。4. 验证请求跑通基准测试与成功结果配置写完后先做一次最小验证确认 TaoToken 通道在两个框架里都能正常返回。建议按顺序执行这样出错时能快速定位是通道问题还是框架问题。第一步用 curl 直接验证通道curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: $TAOTOKEN_MODEL_ID, messages: [{role: user, content: reply with ok}] }如果返回包含 choices 数组且 content 为 ok说明 Key 和 Base URL 都正确。这一步能排除掉大部分接入问题。第二步运行 LangGraph 示例。预期输出类似Its sunny and 28C in Mumbai. Its sunny and 28C in Delhi.第二轮能正确回答 Delhi说明 checkpointer 通过 thread_id 恢复了上下文模型知道how about指的是天气查询。如果你把 thread_id 换成另一个值第二轮会丢失上下文这是验证持久化是否生效的最直接方法。第三步运行 Semantic Kernel 示例。预期输出Agent: Its sunny and 28C in Mumbai. Agent: Its sunny and 28C in Delhi.SK 的第二轮依赖你手动把上一轮的 message 加回 history如果漏掉 history.add_message(message)第二轮就会丢失上下文。这个对比很能说明两个框架的设计哲学差异。第四步做一次并发基准。把两个示例各跑 10 次记录首 token 延迟和总耗时。我实测下来在相同模型和相同网络条件下两个框架的端到端延迟差异主要来自框架自身的编排开销LangGraph 在简单 ReAct 循环里开销略低SK 在插件调用链较长时因为 Kernel 的依赖解析会有额外开销。这个数据对你的选型有直接参考价值。验证通过后如果你要长期跑编码类 Agent可以到 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 了解持续性方案如果只是验证模型能力模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 更快。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节按真实报错整理都是我或身边团队实际遇到过的。401 Unauthorized。最常见的原因是 Key 没读到或读错。检查环境变量是否在当前 shell 生效Python 里用 os.environ 读取时确认变量名拼写一致。另一个原因是 Key 被复制时带了空格或换行建议用 echo $TAOTOKEN_API_KEY | wc -c 确认长度。如果 Key 本身失效到 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 重新创建。local proxy failed。这个报错通常出现在请求根本没发出去的时候检查 Base URL 是否写成了 https://taotoken.net/api 而不是其他地址。如果你本地有网络层配置确认它没有拦截对 taotoken.net 的请求。注意不要在任何配置里引入非官方的中转地址统一用官方端点。reading choices 报错。典型信息是 KeyError: choices 或 reading choices of undefined。这说明返回体里没有 choices 字段通常是请求体格式不对或模型名错误。检查 Model ID 是否和 TaoToken 支持的模型列表一致LangGraph 里是否误把纯模型名当成了带前缀的格式。用第 4 节的 curl 命令先确认通道返回结构再对比框架发出的请求体。OAuth 相关报错。如果你用的是 Claude Code 或 Codex 这类工具可能会遇到 OAuth 认证失败。这类工具通常需要配置 Base URL、Key、Model ID 三件套。以 Codex 的 auth.json 为例配置结构大致如下{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: gpt-4o-mini }Claude Code 的配置在 settings 文件里同样需要 Base URL、Key、Model ID 三个值。如果你用 CC Switch 或 Cline MCP 做工具切换确保每个工具的配置里这三个值都完整缺一个就会触发 OAuth 或认证类报错。接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里有各工具的配置示例遇到不确定的参数优先查文档。模型不存在报错。LangGraph 报 model not found 时检查 init_chat_model 的第一个参数格式必须是 provider:model 形式。SK 报同样错误时检查 ai_model_id 是否只填了模型名不要带 provider 前缀。连接超时。如果 curl 能通但框架超时检查框架是否走了系统代理。Python 的 requests 和 httpx 会读取 HTTP_PROXY 环境变量如果你本地有代理配置可能把请求导向了错误地址。临时 unset HTTP_PROXY HTTPS_PROXY 再试。6. 选型决策与后续接入路径回到最初的问题什么时候选 LangGraph什么时候选 Semantic Kernel。我的判断标准是看你的 Agent 是否需要表现得像一台持久状态机。如果 Agent 逻辑涉及非简单的分支、重试、人工审查或审批步骤这些场景受益于显式的图拓扑LangGraph 更合适。工作流需要持久执行在崩溃中存活、从检查点恢复并保留可审计的步骤序列这也是 LangGraph 的强项。团队已深入 LangChain 生态希望沿着 create_agent 到 LangGraph 的技术栈获得清晰的升级路径同样选 LangGraph。如果 Agent 需要表现得像一个协议感知的平台组件Semantic Kernel 更合适。正在构建平台或 SDK能力以插件形式组合不同 Agent 各自消费不同的工具集合MCP 或 A2A 互操作性是核心需求且希望在 Python SDK 中原生支持而非依赖外部适配器团队已采用 DI 或面向服务的架构kernel-plugin 模型与既有设计天然契合倾向轻量部署不想引入专用的编排运行时状态交由外部系统管理。这些场景下 SK 的抽象更贴合。两个框架目前都处于稳定性优先的阶段。LangGraph v1 官方确认核心图 API 和执行模型未发生破坏性变化主要迁移事项是将 langgraph.prebuilt 中的 create_react_agent 标记为弃用转向 LangChain 的 create_agent并承诺 2.0 之前不引入破坏性变更。Semantic Kernel 1.x 的大部分结构层面断裂集中在 1.0 版本2025 年上半年的路线图及后续版本呈现出增量式、累加式的演进模式以定向修复为主不再出现结构性断裂。所谓LangGraph 每个版本都会破坏兼容性的旧说法已不再成立。如果你决定两个都试建议用同一套 TaoToken Key 和 Base URL 驱动这样模型层的变量被消除你比较的就是纯粹的框架差异。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite API Keys 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 需要长期跑编码 Agent 的话 Coding Plan 在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。先把第 3 节的两段代码跑通再根据第 4 节的基准数据做决定比看十篇对比文章都管用。