Pydantic AI vs LangGraph vs Agno：Python 智能体框架怎么选（2026）

🇺🇸
Read in English: Pydantic AI vs LangGraph vs Agno: How to Choose a Python Agent Framework

设想一个四个人的小团队，接了个活，要把一套客服问答脚本升级。原来的脚本很简单，用户问什么，它从知识库里捞三段文字拼起来返回。上线半年，毛病攒了一堆。有人问“我上周买的那个包什么时候到”，脚本把退货政策一字不差地念了一遍。老板提了两个要求：能查订单，能发起退款。

接两个内部接口，技术上不算难。难的是决定用什么写。团队里三个人意见不统一。一个说直接用官方 SDK 加几个判断就完了，一个说既然要做智能体就该上框架，第三个翻了几天 GitHub，扔回来三个名字：Pydantic AI、LangGraph、Agno。那天下午他们一行代码没写，全在争这三个东西到底差在哪。

这样的争论，很多团队都经历过，而且并不冤枉。三个项目对“智能体”这个词的理解根本不同，选错不只是慢一点，代码会长成另一个形状，等到发现不合适，返工的成本已经很高了。

一个客服脚本撑不住的那天

先把需求摊开，因为框架选型比的从来不是功能列表，是谁能接住你手里的麻烦。

这个客服机器人要干的事，其实有四层。最浅一层是理解问题，用户说的话经常缺主语，“那个包”指的是哪一单，得从上下文里捞。第二层是决定动作，什么时候该查订单，什么时候该直接回答，什么时候该把人转到人工。第三层是执行，调接口拿数据，把结果组织成一句人话。第四层最麻烦，退款这种动作不能模型一拍脑袋就执行，得有人确认，确认之前流程要停住，第二天上班的人回来还能接着走。

这四层里，第一层和第三层是模型和数据的事，第二层和第四层是流程的事。大部分框架的差别，就落在它们把重心放在哪一层。

最初的写法往往是把所有逻辑塞进一个函数，读上下文、拼提示词、解析返回、判断要不要调工具，全在一个两百行的文件里。跑通了，但没人敢改。加一个工具要动五处，改一次提示词要重新测全部分支，出了错只能翻日志猜是哪一步歪的。这种代码能上线，但撑不过三个月。

于是问题变成：谁来替团队管住这个函数的内部结构。

三个项目，三种对“智能体”的理解

Pydantic AI 的理解最窄，也最直接：智能体就是一个带工具的函数，输入有类型，输出也有类型。它来自 Pydantic 团队，那个做数据校验库的团队，所以整个项目的重心落在“模型返回的东西能不能被信任”这件事上。你把期望的输出结构写成一个数据模型，模型返回的内容必须过这道校验，不合格就把错误信息喂回去让它重来。工具的参数同样有类型约束，写错了在运行前就能发现，不用等到线上。

拿它试的第一个任务，通常是订单信息抽取。用户一段话里可能混着订单号、商品名、期望的送达时间，还可能有错别字。用 Pydantic AI 写，返回的不是一段文本，是一个对象，字段类型不对直接报错，重试逻辑框架自己处理。那种感觉很踏实，像给模型的胡言乱语套了个笼子。它的代价是，它不太管流程。多步骤、带分支、要人确认的长流程，它没有现成的编排工具，你得用 Python 自己的控制流去写。对它来说这是克制，对你来说这可能是不够。

LangGraph 的理解正相反，它认为智能体是一张图。节点是动作，边是动作之间的走向，整张图有一个显式的状态对象在流动。这个模型一开始让人觉得绕，你得先想清楚状态里放什么，再想每个节点读什么写什么。想清楚之后，好处立刻显现：每个节点可以单独测试，流程可以画出来给不写代码的人看，某一步出错能定位到具体节点，流程走到一半可以停下来，等人处理完再继续。

这个退款流程就是它擅长的场景。用户申请退款，先判断订单状态，符合条件的走自动审批，金额大的转到人工，人工确认后再执行。中间可能卡在等人的环节过夜。用图来描述，这些分支和暂停点都是流程的一部分，不是散落在代码里的 if。LangGraph 属于 LangChain 那边，配套的工具和文档比较多，代价是概念也多，第一次接触要花时间分清哪些是必须的、哪些只是可选项。

Agno 的理解最宽，它想做的不是一个库，是一个能构建、运行、管理智能体的地方。项目本身不新，前身是 Phidata，2022 年就有了，后来改名转型。它的写法以智能体为单位，一个智能体带自己的模型、工具、知识库和记忆，多个智能体可以组成团队协作。运行记录、会话管理这些琐事，平台层给了现成的做法，你不用自己从零搭。

这个定位对某些团队是解药。比如一个做电商运营的小组，想同时跑选品、写文案、盯客服三个智能体，手里没有基础设施的人，也不想自己写调度和存储，这时用平台层现成的做法，能省下不少搭建工作。代价是抽象层更厚，出问题时你要往下挖几层才能看到模型到底收到了什么。它给你的东西多，你要让渡的控制权也多。

一张表能说清的部分

把三个项目放在一张表里，只能比那些确定的东西：谁授权的，怎么编排，类型管到哪一步，状态怎么存，学起来多难，适合谁。这几列不是随手挑的。协议决定一家公司能不能用，法务那一关过不了，后面都白谈。编排方式决定你的代码长什么样，是函数调用还是状态机，写完就改不动了。类型校验决定错误在哪一层暴露，是编译前、运行前，还是用户投诉时。状态与持久化决定流程能不能中断再续。学习曲线决定团队第一周能不能拿出东西给人看。

项目	授权协议	编排方式	类型与校验	状态与持久化	学习曲线	适合场景
Pydantic AI	MIT	以单个智能体为中心，流程靠 Python 控制流	端到端类型，输出结构强校验，不合格可回喂重试	偏轻，持久化通常需要自行接入，细节以官方文档为准	熟悉 Pydantic 的团队上手很快	输出必须可靠、要嵌进已有 Python 业务代码、把模型当函数用
LangGraph	MIT	图结构，节点与边描述有状态的工作流	状态结构显式声明，类型检查偏流程层	重心所在，支持中断、恢复与逐步回放	偏陡，先要设计清楚状态	多轮、有分支、有人工审批、需要断点续跑的长流程
Agno	Apache-2.0	以智能体与团队为单位组装，带运行与管理层	使用 Python 类型提示，校验深度以官方文档为准	平台层提供会话与运行管理，具体能力随版本变化，落地前需对照官方文档	中等，基础用法简单，深入平台概念要时间	想少搭基础设施、多个智能体一起运行、需要现成运行与观察界面

表格里最容易误读的是最后两列。学习曲线不是绝对值，它跟团队已经会什么强相关。一个写过大量 Pydantic 模型的人，看 Pydantic AI 的文档可能一个下午就够，同样的时间去啃 LangGraph 的状态设计，会觉得处处别扭。适合场景那一列也不是排他性的，三个项目都能做客服机器人，差别在于哪个更顺着你的需求长。

还有 star 数，很多人第一眼看这个。截至 2026 年 10 月下旬，LangGraph 大约 4.37 万，Agno 大约 4.29 万，Pydantic AI 大约 2.08 万。这个排序跟项目质量关系不大，跟项目年龄关系更大。LangGraph 2023 年 8 月创建，Agno 的前身 2022 年 5 月就有了，Pydantic AI 是 2024 年 6 月才开的头。一个晚两年起步的项目能攒到两万星，说明它解决的问题足够痛。把 star 当热度参考可以，当选型依据会吃亏。

真正拉开差距的是出错以后

功能都跑通之后，三个项目的差别才真正显现，而且都出现在出错的时候。

先看 Pydantic AI。假设模型把一个金额字段返回成了带货币符号的字符串，校验会直接拦下，错误信息回到模型，让它再来一次。整个过程不需要自己写解析代码，也不用在日志里翻半天。它的好处不在于让模型变聪明，在于让模型的错误停在门口。

LangGraph 的场景更典型。退款流程走到人工审批，审批人下班了，任务停在那个节点。第二天他回来点确认，流程可以从原地继续，前面查过的订单状态不必重新查一遍，因为状态是存下来的。如果没有这一层，就得自己写一张任务表，记录走到哪一步、上下文是什么，写起来不难，维护起来是无底洞。它真正解决的是把“暂停”变成流程的正常状态，而不是异常。

Agno 又是另一种体验。多个智能体同时跑，它的运行与管理层负责记录会话和运行情况，对没有专职运维的团队有价值，出问题不需要先去搭一套日志。代价是抽象层把细节盖住了，输出不对劲时，排查要从上往下一层层剥。具体能看到哪些信息，以官方文档为准。

这三种情形背后是同一个判断：选框架其实是在选你愿意在哪种错误上花时间。Pydantic AI 把错误挡在数据边界，你要花时间设计模型。LangGraph 把错误显式化成流程里的一个状态，你要花时间设计图。Agno 把错误收进平台，你要花时间学会在哪一层看它。

回到开头那个客服机器人

回到开头那个客服机器人，一个合理的选择是 Pydantic AI 加一小段自己写的状态机。理由很朴素：这个机器人的流程只有四步，退款那一步的人工确认用一个待办表就够了，为它引入一整张图，团队得先花不少时间学概念。而输出不可靠是每天都会遇到的痛，那部分交给 Pydantic AI 最省事。如果退款流程有七八个分支、还要支持撤销和补发，选择会倒过来。

所以给建议的时候，我不太愿意说哪个更好，只说哪种需求和哪个项目更匹配。

如果你的核心困扰是模型返回的东西不能用，字段时有时无、格式时对时错，而业务流程本身不复杂，选 Pydantic AI。它把类型和校验放在最前面，接进已有的 Python 代码几乎不需要改变原来的写法。团队里有人熟悉 Pydantic 的话，上手成本接近于零。

如果你的困扰是流程本身，步骤多、有分支、中间要人参与、跑一半可能停几天、出了问题要能回看每一步，选 LangGraph。它逼你先把状态想清楚，这个前期投入会在后面反复兑现。要接受它的概念密度，也要接受它跟 LangChain 那套东西的关联，用不用得上得自己判断。

如果你不想在运行层花力气，手上同时有好几个智能体要管，需要现成的会话记录和观察界面，团队里又没有专门做基础设施的人，选 Agno 更划算。它的前身做了好几年，平台该有的东西比较齐。要留意的是它盖住的细节多，遇到诡异问题时要愿意往下挖。

还有一种做法值得考虑：用 Pydantic AI 管每个节点内部的输入输出，用 LangGraph 管节点之间怎么走。两者不冲突，一个管数据可信，一个管流程可控。

如果团队还没定，最省时间的办法不是继续读文档，是用同一个最小任务各写一遍。任务就选查一次订单再回答一句，半天时间够了。看哪一家让你最快跑通，看它报错时说的是不是人话，看改一个需求要动几个文件。这三个问题的答案，比任何对比表都准。

项目地址在这里，事实以仓库为准：

https://github.com/pydantic/pydantic-ai

https://github.com/langchain-ai/langgraph

https://github.com/agno-agi/agno