Python Agent 框架选型对比：2026 主流方案

为什么 2026 年还要重新盘点一次

Python 的 Agent 框架这两年换过一轮血。如果你手上的选型文档写于 2024 年底或 2025 年初，里面大概率还在讨论 AutoGen 0.4 和「LangChain 会不会被淘汰」——这两条今天都已经不是有效议题了。

有两件事决定了当前格局：

• AutoGen 进入维护模式。官方仓库 README 现在明确写着 AutoGen is now in maintenance mode，不再接收新功能和增强，转为社区维护。PyPI 上 autogen-agentchat 最后一个版本停在 0.7.5（2025-09-30），主仓库的活动也基本停止。微软把 AutoGen 的 Agent 抽象和 Semantic Kernel 的企业级能力合并，另起炉灶做了 Microsoft Agent Framework。
• 两个 1.0 先后落地。LangChain 1.0 与 LangGraph 1.0 在 2025 年 10 月 22 日同步 GA，并承诺在 2.0 之前不引入破坏性变更；Microsoft Agent Framework 在 2026 年 4 月同时面向 .NET 和 Python 发布 1.0，官方口径是 stable APIs 加长期支持承诺。

结论很直接：今天真正需要比较的对象已经不是「LangGraph vs AutoGen」，而是「LangGraph vs Microsoft Agent Framework」，再叠加几个定位完全不同的库。网上大量对比文章至少落后其中一个里程碑，直接拿来用会得出错误结论。

主流框架速览

下表数据取自 PyPI 与 GitHub 官方接口，采集时间 2026-09-18。版本号和发布日期是判断一个项目是否活跃的第一手依据，建议选型时自己也拉一遍，不要只看二手博客。

一个容易被忽略的观察：AutoGen 的 star 数（约 61k）仍然是表里第二高，但它的版本号停在一整年前。用 star 数做选型依据会在这里直接翻车——版本发布节奏比 star 数更能反映项目状态。

LangGraph：把 Agent 当成带状态的图来跑

LangGraph 的定位是低层编排框架加持久化运行时，核心模型很朴素：把工作流写成有向图，节点是计算步骤，边是条件跳转，状态在每一步被 checkpoint 保存。

它最有辨识度的能力是持久化执行。用 checkpointer 编译图之后，每次执行到 super-step 都会落下一次状态快照，按 thread 组织。这意味着进程崩溃、重新部署或者一次临时的基础设施抖动，都不会把已经跑完的推理过程清空——恢复时从最近的 checkpoint 继续。

基于这套持久化，人机协同（HITL）才有意义。LangGraph 提供 interrupt()，它和静态断点不同，可以写在条件分支里，甚至可以放在工具函数内部；触发时把审批载荷抛给调用方，线程状态被持久化，之后用 Command(resume=...) 恢复。对于「某些工具调用前必须人工确认」的场景，这是第一方 API，不用自己搭。

from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.postgres import PostgresSaver
from typing import TypedDict

class State(TypedDict):
    messages: list

def plan(state: State):
    return {"messages": state["messages"] + ["planned"]}

def execute(state: State):
    return {"messages": state["messages"] + ["executed"]}

builder = StateGraph(State)
builder.add_node("plan", plan)
builder.add_node("execute", execute)
builder.add_edge(START, "plan")
builder.add_edge("plan", "execute")
builder.add_edge("execute", END)

with PostgresSaver.from_conn_string(DB_URI) as saver:
    saver.setup()
    graph = builder.compile(checkpointer=saver)
    graph.invoke({"messages": []}, config={"configurable": {"thread_id": "t-1"}})

工程上要提前想清楚代价：每一步都落盘是用延迟换可靠性。默认的 InMemorySaver 重启即失效，官方只建议用于实验；生产环境应当配 Postgres 或等价的托管存储，SQLite 适合本地开发。另外嵌套子图之间共享 checkpointer 的行为，在上生产前值得单独压测一遍。

LangChain 1.4 与 LangGraph 的分工

现在两者的关系比早期清楚得多：LangChain 提供 create_agent 这类高层封装和庞大的集成生态（模型、检索器、工具），而 Agent 的循环本身跑在 LangGraph 上。所以「用 LangChain 还是用 LangGraph」这个提法本身就不成立——绝大多数生产项目是两个都用，LangChain 负责写业务，需要精细控制流时下沉到 LangGraph。

一个实际注意点：@tool 装饰器要求必须有类型注解，因为注解会被直接转成输入 schema；函数名默认就是工具名，config 和 runtime 是保留参数名，自己命名这两个参数会在运行时出错。这些细节看着琐碎，但都属于「不踩一次不知道」的类型。

CrewAI：角色分工的高级封装

CrewAI 走的是完全不同的路线，把多 Agent 协作抽象成组织架构：你定义若干带 role、goal、backstory 的 Agent，组成一个 Crew，再用 Task 描述各自要交付什么。

从 1.x 开始它补上了更重要的一块——Flows。Crews 负责「让一组 Agent 自主协作」，Flows 负责「用事件驱动的方式精确控制哪一步先跑、什么条件下跑」。官方的表述是：Crews 追求自主性与协作智能，Flows 提供精确的事件驱动控制。实际项目里常见的组合是外层用 Flow 管流程和分支，内层把需要发散思考的环节丢给 Crew。

它的优势是上手快、概念贴近人的组织直觉，几十行代码就能跑起一个可用的多 Agent 流程；代价是控制粒度粗，遇到需要精确回滚、细粒度状态管理的场景会顶到封装边界。如果你的任务本身就是「调研 → 分析 → 写报告」这类线性分工，CrewAI 的性价比很高；如果是有大量条件分支和重试语义的业务流程，图模型更合适。

AutoGen 的交接与 Microsoft Agent Framework

AutoGen 的历史地位不用多说，group chat、事件驱动运行时这些范式都是它先推出来的。但现状必须如实说：它已经不再接收新功能和增强。

接棒者是 Microsoft Agent Framework，开发团队就是原班人马。技术上是合并：AutoGen 简洁的 Agent 抽象 + Semantic Kernel 的企业级特性（会话状态管理、类型安全、过滤器、遥测、广泛的模型与嵌入支持），再新增了基于图的 Workflow，用来对多 Agent 执行路径做显式控制。

# pip install agent-framework
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential

client = FoundryChatClient(
    project_endpoint="https://your-resource.services.ai.azure.com/api/projects/your-project",
    model="gpt-5.4-mini",
    credential=AzureCliCredential(),
)
agent = client.as_agent(
    name="HelloAgent",
    instructions="You are a friendly assistant. Keep your answers brief.",
)
result = await agent.run("What is the largest city in France?")

几个值得记的判断点：

• 迁移成本不对称。单 Agent 的代码通常半天能迁完；多 Agent 团队不行，因为 AutoGen 的 Team 概念在 MAF 里变成了类型化的 Workflow，编排语义变了，需要重新设计。
• Provider 不限于 Azure。MAF 支持 OpenAI、Anthropic、Ollama 等多家，并不是只能绑 Azure OpenAI。它同时提供 .NET 和 Python 的 1.0，这是它相对多数 Python-only 框架的差异化优势。
• 它自己给了一条很实在的建议。官方文档在「什么时候用 agent、什么时候用 workflow」的对比表下面写了一句话：如果你能写个函数解决这个任务，那就写函数，别上 AI Agent。这句话值得贴在选型文档第一页。

OpenAI Agents SDK：原语少，心智负担也小

OpenAI Agents SDK 的设计哲学是「原语够用就好」，公开面基本收敛在 Agent、Runner、function_tool、handoff、Guardrail、Session 这几样上。和 LangChain 的重抽象、CrewAI 的角色扮演都不同，它更接近「把你自己手写的那个 while 循环正式化」。

版本策略上官方说得很坦白：采用稍作修改的语义化版本，首位固定为 0，表示 SDK 仍处在快速演进期，minor 版本可能包含破坏性变更；不想被破坏就锁 patch 版本。这不是免责声明式的敷衍，是真实约束——0.20.0 改过默认模型，0.21.0 要求 openai>=3.0.0,<4 并把 HTTP 层迁到 HTTPX2，自定义过 HTTP client 的项目需要跟着改。

工具能力是它更新最快的部分。SDK 把工具分成几类：OpenAI 托管的服务端工具（web search、file search、code interpreter、hosted MCP、图像生成），本地运行时工具（ComputerTool、ApplyPatchTool、ShellTool），包装任意 Python 函数的 FunctionTool，以及「把一个 Agent 当工具调用」的 agents-as-tools。

这里有一个值得专门关注的机制：工具按需加载。当你手上工具很多时，可以把一部分标成延迟加载，然后挂一个工具检索入口，让模型在运行时先加载需要的那个子集，而不是把全部 schema 塞进每一轮上下文。官方明确建议用命名空间组织工具，并给出了 tool_namespace() 这类封装。

from typing import Annotated
from agents import Agent, Runner, ToolSearchTool, tool_namespace
from agents.decorators import tool

@tool(defer_loading=True)
def get_customer_profile(
    customer_id: Annotated[str, "The customer ID to look up."],
) -> str:
    """Fetch a CRM customer profile."""
    return f"profile for {customer_id}"

crm_tools = tool_namespace(
    name="crm",
    description="CRM tools for customer lookups.",
    tools=[get_customer_profile],
)

agent = Agent(
    name="Operations assistant",
    instructions="Load the crm namespace before using CRM tools.",
    tools=[*crm_tools, ToolSearchTool()],
)

要留意它的边界：延迟加载和工具检索目前只在 OpenAI 的 Responses 模型上可用，且对底层 openai 包版本有要求。如果你的模型层是可替换的，这个能力就不是免费的。

PydanticAI：把类型安全放在第一位

PydanticAI 的背景很好理解——写 Pydantic 的那批人做 Agent 框架，而 Pydantic 已经躺在 FastAPI 和大量 Python AI 工具下面。它的卖点是：依赖用类型表达，输出用类型约束，校验由框架承担，而不是靠事后解析字符串。

版本节奏需要留意，因为它走的是双线：

• 2025 年 9 月发布 V1，并承诺在 V2 之前不做破坏性变更；
• V2 的稳定版 2.0.0 于 2026 年 6 月 23 日发布，用来收纳 V1 稳定性承诺期间攒下的破坏性与行为变更；
• 两条线在同时维护：截至 2026-09-18，PyPI 上是 2.45.0，而 1.x 线仍有 v1.107.6（2026-09-16）的更新。

这种双线维护对生产项目其实是好消息——升级不用一夜之间完成。V2 里有一类变更很典型，值得单独提：准备回调（prepare_tools）如果返回 None，V1 只是发个弃用警告然后静默清空所有工具，V2 直接抛 TypeError，要表达「这轮不给工具」必须显式返回空列表。从静默失败改成显式报错，是把坑挖到明面上，长期看是好事，但升级时这类地方要逐个排查。

如果你的项目本来就重度使用 Pydantic（FastAPI 服务、严格的数据模型），PydanticAI 的学习成本最低，模型边界清楚，类型检查器能帮你在运行前发现大部分问题。反过来说，如果你的团队还没形成用类型描述契约的习惯，它会带来额外的编写负担。

选型对比：把差异摊平看

怎么选：一套可执行的判断顺序

比起看功能表，下面这个顺序更省时间：

1. 先问要不要 Agent。这不是玩梗。MAF 官方那句「能写函数就写函数」适用于所有框架。任务路径固定、输入输出可枚举的场景，工作流引擎或者普通代码更便宜也更可靠。
2. 看有没有长周期状态。流程需要跨请求存活、中途等待人工审批、故障后要续跑，优先考虑图模型加持久化（LangGraph，或 MAF 的 Workflow）。这一层是后期最难补的，一开始就别省。
3. 看多语言是否是硬需求。团队里有 .NET 服务要复用同一套编排，MAF 的 1.0 双语言支持是实打实的优势，其他候选基本没有。
4. 看模型层要不要可替换。只在 OpenAI 上跑，Agents SDK 的开发体验最直接；需要自由切换供应商，选 provider 抽象更中立的方案，或者自己加一层适配。
5. 看团队的类型化程度。已经深度使用 Pydantic 与静态检查，PydanticAI 会顺手；否则先别引入额外的类型负担。
6. 最后看迁移成本，而不是功能清单。LangGraph 与 MAF 的能力重叠已经很大，决定因素往往是团队现有代码往哪边改得更少。

几个容易踩的坑

• 用 star 数判断项目健康度。AutoGen 就是反例：star 数量级最高之一，但版本停在一年前。看最近三个月的发版节奏、issue 响应和是否有明确的继任者，比看 star 有用得多。
• 把编排层和可观测层绑死。这两件事在评估时经常被当成一个决策，其实完全正交。先在当前原型的代码上接入 tracing，把一条真实生产链路从头到尾拉出来，看到实际发生了什么，再单独评估编排框架。绑死会让后续迁移成本被低估。
• 忽略 0.x 的版本语义。OpenAI Agents SDK 明确说了 minor 版本可能破坏兼容。生产项目应当锁死版本，并把依赖升级当成一次独立变更来做。
• 默认内存检查点就当持久化。LangGraph 的 InMemorySaver 进程重启即丢，SQLite 官方也只推荐用于实验；MAF 不会自动加载 .env，需要自己调 load_dotenv()。这类默认值都是「本地跑得通、上线才暴露」的类型。
• 照着过时的对比文章选型。选型前至少核对三个事实：目标框架的最新版本与发布日期、上一代框架是否已进入维护模式、官方是否发布了继任者。这三件事查一遍不超过十分钟，能避开大部分返工。

结语

2026 年的 Python Agent 生态已经过了「哪个框架最强」的阶段，进入了按场景分工的状态：LangGraph 和 MAF 争夺需要精细控制与持久化的主战场，CrewAI 守住角色分工的易用区，OpenAI Agents SDK 用最少的原语做最短路径，PydanticAI 把类型安全这条线单独拉出来做实。

选型没有唯一答案，但有一个通用的验证方法：拿你自己最复杂的那条业务流程，用两个候选框架各写一版原型，重点看状态怎么存、失败怎么恢复、人工审批怎么插进去。跑通这两版，比读二十篇对比文章都有用。