PydanticAI vs LangGraph：类型化 Agent 与状态图怎么选？

PydanticAI 与 LangGraph 都能构建 Python Agent，但解决问题的起点不同。PydanticAI 从模型、工具和类型化输出开始；LangGraph 从显式状态、节点与检查点开始。一个偏单次运行的业务契约，一个偏长流程的状态编排，实际项目也可以组合使用。

先选任务，再选抽象

如果需求是“读一段客户消息，调用一次查询工具，返回经过 Pydantic 校验的工单”，PydanticAI 的 Agent 和 output_type 路径更短。若需求是“分类、检索、生成草稿、等人工批准、发送回复，几天后还能恢复”，LangGraph 的状态图和检查点更贴近问题。后者也能返回结构化数据，前者也提供持久化和 durable execution；差别在默认思考和配置成本，不是绝对能力有无。

输出可靠性

PydanticAI 使用 Pydantic schema 与验证器约束输出。模型若返回不合规范的结果，框架可以把验证错误反馈给模型重试。字段通过验证只代表满足代码规则，不保证信息来源可靠。LangGraph 把状态存在节点之间，输出约束通常需要你在节点或模型调用层定义；其优势是能看见每一步如何改变状态。两者都应对金额、身份和外部引用做独立核验。

持久化和审批

LangGraph 官方示例说明：节点边界可以产生检查点，interrupt() 配合 checkpointer 暂停等待人工输入，然后用同一 thread ID 恢复。节点设计过大，失败时可能重复更多工作；写外部系统时仍需幂等键。PydanticAI 的延迟工具可以在工具执行前返回待批准的调用及参数，再用 DeferredToolResults 接续对话；其官方文档明确警告，前端传入的批准不能代替服务端授权。若要跨进程恢复，需另外选择持久化和 durable execution 路线。LangGraph 示例；PydanticAI 审批。

运行与费用

两个核心库都可免费使用，GitHub 项目文件均标注 MIT 许可。实际成本来自模型 token、数据库/检查点、应用部署、日志和可选托管服务。不要把 LangSmith 或 Logfire 的订阅价格当作核心框架许可费。对需要多次重试和长时间等待的任务，统计每个成功任务的模型次数、检查点存储和人工工时，才能比较。

怎么选

• 优先 PydanticAI：Python 服务以类型化结果、工具函数和明确的业务校验为主，流程长度可控。
• 优先 LangGraph：复杂分支、跨天等待、可恢复状态和每个节点的检查点是主要需求。
• 同时使用：让 LangGraph 管理状态和等待，在某个节点里用 PydanticAI 生成并验证结构化输出。这样会多一层配置和追踪，只有在两种需求都真实存在时才值得组合。

试点中的三个失败测试

分别制造模型输出字段缺失、审批后服务重启、外部写入成功但回执丢失。记录谁阻断错误、谁负责恢复、是否重复副作用，以及日志能否解释全过程。这比只跑一条成功演示更能决定框架是否适合生产。

资料：PydanticAI 输出、持久化、LangGraph 仓库、LangGraph 状态设计。