LangGraph与Semantic Kernel深度对比：状态图vs插件路线

多数关于 LangGraph 和 Semantic Kernel 的比较文章已经过时了。这话可能有点直，但过去六个月里，两个框架各自经历了重大更新，那些旧文里的判断早就跟不上现实。所以，这篇不讲空话，只梳理实际发生的变化、当前真实的代码形态，以及到底该怎么选。

2026 年构建 Python AI Agent，现实状况是这样的：两个框架都足够成熟，可它们的流行对比文章大多发布在关键更新之前——

• LangGraph 在 2025 年 10 月发布了 v1.0。
• LangChain 1.0 的 create_agent 底层已经运行在 LangGraph 运行时之上，LangGraph 事实上成了 LangChain 生态的执行引擎。
• Semantic Kernel 在 v1.28.1 中为 Python 加入了一等 MCP 支持，SDK 内原生兼任 MCP 客户端和服务端。

如果你现在读到一篇比较文章还在说 LangGraph“不稳定”或 Semantic Kernel“和 .NET 绑定太深”，那它描述的已经不是今天的现实了。

本文基于 LangGraph 官方文档、Semantic Kernel 官方文档以及两个框架的变更日志写成，不含过时信息。

一句话决策规则

有状态、持久、可恢复的 Agent 工作流，需要显式控制 → 选 LangGraph。
协议优先、插件组合、可互操作的 Agent 平台 → 选 Semantic Kernel。

两种架构从根本上就有着截然不同的思维模型，往下看就明白了。

LangGraph：图运行时

LangGraph 把 Agent 系统建模成一张有状态图。开发者需要显式定义状态、节点与边。节点是 Python 可调用对象或子图，边是状态转换，状态本身是个类型化对象，在图的每一步流转并更新。这不是内部实现细节——这就是你日常编程直接面对的核心抽象。

LangGraph v1 的官方文档围绕三个核心概念组织整个框架的叙述：持久执行、可控性、人机协作。崩溃后从最近检查点恢复工作流、在流程中插入人工审查步骤、将执行分支到并行子 Agent——这些都是一等操作，不是需要绕路才能实现的变通方案。

自 v1 起，LangChain 的 create_agent 运行在 LangGraph 运行时之上，技术栈有了明确的分层：用 create_agent 处理标准工具调用循环；当需要自定义工作流拓扑时，下沉到原始 LangGraph。

Semantic Kernel：内核-插件中间件

Semantic Kernel 的起点是 Kernel 抽象：一个容纳 AI 服务、插件和函数的容器。插件是暴露给模型和 Agent 的函数组，来源可以是原生 Python 代码、提示模板或外部导入的 schema。

SK 官方 agent-functions 文档的原话是：

“Any Plugin a vailable to an Agent is managed within its respective Kernel instance — this enables each Agent to access distinct functionalities based on its specific role.”

编排逻辑来自 Agent 自行选择函数、Planner 排列能力调用的顺序，而非开发者预先画好的图拓扑。

这种设计让 Semantic Kernel 更接近 AI 中间件的定位：开发者定义 Agent 的能力边界，具体的调用编排交给函数调用机制和 Agent 框架。

架构差异

同一个 Agent 在两个框架中实现的代码示例

把架构差异落到代码层面最直观。下面用同一个场景——带记忆和系统提示的多轮天气助手——分别在两个框架中实现。

LangGraph——带检查点的天气 Agent

pip install -U langgraph "langchain[openai]"

from langgraph.prebuilt import create_react_agent
from langgraph.checkpoint.memory import InMemorySa ver
from langchain.chat_models import init_chat_model

# --- 工具：纯Python函数 ---
def get_weather(city: str) -> str:
    """Get the current weather for a given city."""
    # 在生产环境中替换为真实的API调用
    return f"It's sunny and 28°C in {city}."

# --- LLM ---
model = init_chat_model("openai:gpt-4o-mini", temperature=0)

# --- 检查点器启用持久的多轮记忆 ---
# 在生产环境中将InMemorySa ver替换为SqliteSa ver或PostgresSa ver
checkpointer = InMemorySa ver()

# --- 编译图Agent ---
agent = create_react_agent(
    model=model,
    tools=[get_weather],
    prompt="You are a helpful weather assistant.",
    checkpointer=checkpointer,
)

# --- thread_id将此对话绑定到持久检查点 ---
config = {"configurable": {"thread_id": "user-session-1"}}

# Turn 1
response = agent.invoke(
    {"messages": [{"role": "user", "content": "What is the weather in Mumbai?"}]},
    config=config,
)
print(response["messages"][-1].content)

# Turn 2 — Agent通过检查点器自动记住上下文
followup = agent.invoke(
    {"messages": [{"role": "user", "content": "How about Delhi?"}]},
    config=config,
)
print(followup["messages"][-1].content)

create_react_agent 在底层编译出一个包含模型-工具循环的 StateGraph。checkpointer 在每一步持久化状态，相同的 thread_id 会自动从上次保存的位置恢复。如果进程在运行中崩溃，用同一个 thread_id 重启即可从最后的检查点继续。持久性由运行时负责，不需要业务代码操心。

Semantic Kernel——带 Plugin 的天气 Agent

pip install semantic-kernel

import asyncio
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 FunctionChoiceBeha vior
from semantic_kernel.functions import kernel_function
from semantic_kernel.contents import ChatHistory

# --- Plugin：带有@kernel_function装饰器的类 ---
class WeatherPlugin:
    @kernel_function(name="get_weather", description="Get the weather for a city.")
    def get_weather(self, city: str) -> str:
        # 在生产环境中替换为真实的API调用
        return f"It's sunny and 28°C in {city}."

# --- Kernel：持有服务和插件 ---
kernel = Kernel()
kernel.add_service(OpenAIChatCompletion(ai_model_id="gpt-4o-mini"))

# --- 执行设置：启用自动函数调用 ---
settings = OpenAIChatPromptExecutionSettings()
settings.function_choice_beha vior = FunctionChoiceBeha vior.Auto()

# --- 注册插件 ---
kernel.add_plugin(WeatherPlugin(), plugin_name="WeatherPlugin")

# --- Agent：kernel + 指令 ---
agent = ChatCompletionAgent(
    kernel=kernel,
    name="WeatherAssistant",
    instructions="You are a helpful weather assistant.",
)

async def run_agent():
    # ChatHistory需要在多轮之间自行维护
    history = ChatHistory()

    # Turn 1
    history.add_user_message("What is the weather in Mumbai?")
    async for message in agent.invoke(history):
        print(f"Agent: {message.content}")
        history.add_message(message)

    # Turn 2
    history.add_user_message("How about Delhi?")
    async for message in agent.invoke(history):
        print(f"Agent: {message.content}")
        history.add_message(message)

asyncio.run(run_agent())

Kernel 充当依赖容器，集中管理 AI 服务与插件。@kernel_function 装饰器让 Python 方法可被模型自动发现和调用。FunctionChoiceBeha vior.Auto() 指示模型按需触发函数。记忆存放在 ChatHistory 对象中，由调用方自行维护并在每次调用时传入，运行时不负责持久化。

最能揭示差异的 6 行代码

# LangGraph — 运行时拥有持久性
checkpointer = InMemorySa ver()
config = {"configurable": {"thread_id": "session-1"}}
agent.invoke(messages, config)  # 自动从最后一个检查点恢复

# Semantic Kernel — 开发者拥有状态
history = ChatHistory()
history.add_user_message("...")
agent.invoke(history)  # 显式地传递和维护状态

在 LangGraph 中，持久性是运行时的职责；在 Semantic Kernel 中，状态管理是开发者的职责。两种取向无所谓对错，它们对应的是不同的应用模型。

协议支持：MCP 和 A2A

协议层面是 Semantic Kernel 近期变化最大的方向。

Semantic Kernel——Python SDK 中的原生 MCP

SK 官方 MCP 公告的原话：

“Python support for MCP has arrived… SK Python can act as both an MCP Host and an MCP Server, support multiple transport methods (stdio, SSE, WebSocket), chain multiple MCP servers together, and expose SK functions or agents as MCP servers.”

不是适配器，也不是社区插件，v1.28.1 开始已经是一等 SDK 支持。对于需要通过标准协议跨服务边界编排工具和 Agent 的团队来说，这是一次实质性的架构升级。

LangGraph——部署边缘的 MCP

LangGraph 的 MCP 思路侧重部署层面而非进程内集成。部署到 LangGraph Platform 后，每个 Agent 会自动在 /mcp 端点暴露为 MCP 可访问的服务，无需额外代码。自托管场景下则通过 langchain-mcp-adapters 包集成。

如果需要在 Python 进程内部使用 MCP 语义，SK 更合适；如果 Agent 的定位是被其他客户端通过 MCP 消费的已部署服务，LangGraph 更契合。

稳定性

看一下官方文档当前的说法。

LangGraph v1（2025 年 10 月）：官方 v1 发布说明确认核心图 API 和执行模型未发生变化，主要的迁移事项是将 langgraph.prebuilt 中的 create_react_agent 标记为弃用，转向 LangChain 的 create_agent。LangGraph 1.0 公告明确承诺 2.0 之前不引入破坏性变更。

Semantic Kernel 1.x：大部分架构层面的断裂集中在 1.0 版本：命名空间重组、API 重命名、上下文变量变更。2025 年上半年 SK 路线图及后续版本呈现出增量式、累加式的演进模式，以定向修复为主，不再出现结构性断裂。

“LangGraph 每个版本都会破坏兼容性”的旧说法已不再成立。两个框架目前都处于稳定性优先的阶段。

何时选择哪个

✅ 选择 LangGraph 当：

• Agent 逻辑涉及非简单的分支、重试、人工审查或审批步骤，这些场景受益于显式的图拓扑。
• 工作流需要持久执行——在崩溃中存活、从检查点恢复，并保留可审计的步骤历史。
• 团队已深入 LangChain 生态，希望沿着 create_agent → LangGraph 的技术栈获得清晰的升级路径。
• 需要在节点级别观测执行流如何穿过工作流，要求细粒度的可观测性。

✅ 选择 Semantic Kernel 当：

• 正在构建平台或 SDK，能力以插件形式组合，不同 Agent 各自消费不同的工具集合。
• MCP 或 A2A 互操作性是核心需求，且希望在 Python SDK 中原生支持，而非依赖外部适配器。
• 团队已采用 DI / 面向服务的架构，kernel-plugin 模型与既有设计天然契合。
• 倾向于轻量部署，不想引入专用的编排运行时，状态交由外部系统管理。

总结

如果 Agent 需要表现得像一台持久状态机，用 LangGraph。
如果 Agent 需要表现得像一个协议感知的平台组件，用 Semantic Kernel。

希望这篇能帮到你。