Pydantic AI 是 Pydantic 团队(pydantic / pydantic-core 的原班人马)推出的 Python Agent 框架,核心思路是用 Pydantic 的类型系统约束 LLM 的输入与输出。它解决的是 LLM 应用里最常见的痛点:模型返回自由文本,JSON 解析靠字符串匹配、字段校验靠手写代码、格式错了难以自动恢复。Pydantic AI 把「定义期望结构」提升为一等公民——你声明一个 Pydantic Model 作为 result_type,框架负责引导模型按该结构作答、用校验器逐字段验证、出错后自动回传错误并重试,全程类型提示可被 IDE 与静态检查工具识别。 与 LangChain、LlamaIndex 这类一站式编排平台不同,Pydantic AI 刻意保持 API 小巧,核心概念只有 Agent、工具、依赖注入和 Graph,没有中间层抽象,生产环境易读好维护。它内置主流模型 Provider(OpenAI、Anthropic、Gemini、Ollama、Groq 等)与 MCP 协议(模型上下文协议,一种标准化工具调用协议)支持,并可无缝对接同团队的 Logfire 观测平台。本篇攻略按「速览 → 安装 → 上手 → 能力详解 → 生产部署 → 选型对比 → 避坑 → 面试」组织,全部内容基于 ai.pydantic.dev 官方文档整理,读完可在 10 分钟内写出第一个类型安全的 Agent。

岗位关联

掌握 Pydantic AI 等于拿到一套「结构化输出 + 类型校验 + 工具调用」的开箱即用方案,在 RAG、Agent 化 API 服务等场景能显著减少解析与兜底代码,是 Python 生态 LLM 工程师的稀缺加分项。

目录
  1. 为什么需要 Pydantic AI:LLM 输出不可信,用类型系统兜底
  2. 安装与环境配置:4 步就绪
  3. 快速上手:10 分钟跑通第一个 Agent
  4. 核心能力详解:5 大支柱
  5. 生产部署与监控:从上线到运维
  6. 版本迭代
  7. AI 应用场景
  8. 常见误区
  9. 面试题
工具类型
AI Agent 框架(开源 Python 库,类型安全优先)
开发商
Pydantic Services Inc.(Pydantic 团队)
开源协议
MIT(可商用)
GitHub Stars
无
主要语言
Python 3.9+
当前版本
0.2.9(2025-09 正式版)
安装方式
pip install pydantic-ai
官方文档
上手难度
★★☆☆☆(低)
适合人群
Python 后端工程师、LLM/RAG/Agent 应用开发者
同类工具
LangChain · LlamaIndex · CrewAI
托管服务
无

速览卡是工具类内容的固定首屏模块:30 秒判断「这工具是什么、能不能商用、适不适合我」。

为什么需要 Pydantic AI:LLM 输出不可信,用类型系统兜底

传统 LLM 应用中,让模型输出 JSON 主要靠提示词里的「请以 JSON 格式返回」,拿到字符串后要自己 json.loads、手动判空、类型转换;一旦模型多吐一个字段、把数字写成字符串或对不上 key,程序直接抛异常。工具调用(function calling,模型按声明好的函数签名生成参数并触发执行的机制)参数也没有编译期检查,模型传错参数名只在运行时暴露。这些问题在长上下文、多轮复杂任务中出现频率很高,成为线上事故的主要来源之一。

Pydantic AI 把 Pydantic v2 的校验引擎(Rust 核心 pydantic-core)直接用作 Agent 的边界守卫:声明 result_type 后,框架会引导模型生成符合结构的输出,并用完整 Pydantic 校验;校验失败时自动把错误信息回传给模型重试(重试次数可配置),而不是直接抛异常。工具函数的参数同样经过 Pydantic 校验,框架动态生成与模型能力对齐的 schema,保证「定义即约束」。

与 LangChain 的「框架大全」路线不同,Pydantic AI 只有 Agent、RunContext、Depends、Graph 这几个核心概念,没有 prompt 模板层、没有 memory 抽象,一切以类型为中心。对已经习惯 Python 类型体系的团队,心智负担和学习成本明显更低。

安装与环境配置:4 步就绪

步骤一·安装。Pydantic AI 提供两个安装入口:pydantic-ai 全量包含所有内置模型 Provider 的依赖;pydantic-ai-slim 只装核心运行时,再按需补充 extras(如 [openai]、[anthropic]、[ollama])。生产环境推荐后者以控制依赖体积。

步骤二·配置。设置模型 API Key 环境变量。Linux/macOS 写入 shell 配置文件,Windows 用 setx;框架也支持项目根目录的 .env 文件自动加载。

步骤三·使用本地模型(可选)。没有云厂商 Key 时,安装 [ollama] extra 并在本机启动 Ollama,即可用 ollama:模型名 标识,无需任何 Key。

步骤四·验证。执行导入命令,不报错即安装成功。

bash12 行
# 方案一:全量安装(含所有模型 provider)pip install pydantic-ai # 方案二:精简安装,按需补充pip install "pydantic-ai-slim[openai]"pip install "pydantic-ai-slim[ollama]" # 配置 API Key(写入 ~/.bashrc 或项目 .env)export OPENAI_API_KEY="sk-你的密钥" # 验证安装python -c "from pydantic_ai import Agent; print('pydantic-ai 安装成功')"

快速上手:10 分钟跑通第一个 Agent

最小可用流程只有四步:定义输出结构(Pydantic Model)→ 实例化 Agent 并声明 result_type → 用 run_sync 同步调用 → 读取 result.data。三步代码即可完成一次结构化问答。

1. 新建项目目录并完成上节安装,创建 quickstart.py。

2. 定义一个 CityLocation 模型,字段为 city 和 country(均为 str)。

3. 创建 Agent,第一参数传入模型标识 'openai:gpt-4o',第二参数 result_type 传入 CityLocation。

4. 调用 agent.run_sync('太阳从哪个城市升起?'),运行 python quickstart.py。

5. 观察输出:result.data 是已通过校验的 CityLocation 实例,可直接类型安全地访问 .city 和 .country,而非手写 JSON 解析。

6. 进阶:把模型标识替换为 'anthropic:claude-sonnet-4-20250514'、'gemini-1.5-pro' 或 'ollama:llama3.1',其余代码无需改动——这是模型无关抽象的直接收益。

python18 行
# quickstart.py:类型安全的城市信息问答from pydantic import BaseModelfrom pydantic_ai import Agent # 1. 定义期望的输出结构class CityLocation(BaseModel):    city: str    country: str # 2. 创建 Agent,声明输出类型agent = Agent('openai:gpt-4o', result_type=CityLocation) # 3. 同步运行一次result = agent.run_sync('太阳从哪个城市升起?') # 4. result.data 是校验通过的模型实例print(result.data)print(f"城市:{result.data.city},国家:{result.data.country}")

核心能力详解:5 大支柱

支柱一·类型安全的结果校验。result_type 支持 Pydantic Model、TypedDict、基础类型等多种声明方式。模型返回后框架执行完整校验,失败时把错误明细注入对话并自动重试,直到结构合法或达到 max_retries 上限。这让「结构不合规」从运行时崩溃变成框架内部的自动修复循环。

支柱二·工具调用与参数校验。用 @agent.tool 装饰器注册工具,函数签名自动生成 JSON Schema 供模型调用;每次调用前参数都会经过 Pydantic 校验,类型错误会被拦截并反馈给模型修正。支持 async 工具、动态工具(通过 prepare 钩子按需启停),也支持给工具函数注入 RunContext 访问依赖。

支柱三·依赖注入。通过 deps_type 声明依赖类型,工具和系统提示词中用 RunContext[T] 访问外部对象(数据库连接、用户信息、内部 API client),运行时的 deps 参数传入实际值。这让 Agent 逻辑与基础设施解耦,测试时注入 mock 依赖即可,不必为每个用例起真实服务。

支柱四·多模型 Provider 与 MCP。模型标识统一为「provider:model」格式,内置 OpenAI、Anthropic、Gemini、Groq、Mistral、Ollama 等 Provider,切换模型只改字符串。0.2.0 起支持 MCP 协议,可把外部 MCP 服务器暴露的工具集直接接入 Agent,也可将自身作为 MCP Server 暴露给其他应用。

支柱五·Agent Graph 与 Evals。0.2.0 引入的 Graph API 把复杂流程建模为节点与边的有向图,支持条件跳转、并行节点、失败回退,替代外部编排库。内置 Evals 评测体系支持结构化断言与评分器,可把「输出结构是否正确」「是否调用了指定工具」固化为可重复执行的回归测试。

生产部署与监控:从上线到运维

部署方式一·FastAPI 集成。Agent 默认无状态,实例可安全复用。在 FastAPI 中直接用 await agent.run(),响应体就是校验后的结构化数据,天然可作为 REST API 的返回 schema;开箱即用的类型安全性让接口契约由代码声明,省去一层 DTO 转换。

部署方式二·异步与流式。长响应场景用 run_stream() 边生成边返回,配合 SSE 协议(Server-Sent Events,服务器向客户端单向推送的事件流协议)实现打字机效果;多实例部署时不要依赖进程内状态,会话上下文显式通过 message_history 参数传递。

可观测性。安装并配置 Logfire 后,Agent 的每次运行会自动被插桩:记录输入输出、token 消耗、延迟与工具调用链路,无需业务代码埋点。接入方式是 logfire.configure() 一行初始化,配合环境变量 LOGFIRE_TOKEN。生产环境还应对用户输入做长度限制,防止超长上下文推高成本。

<p class="para-label">避坑清单:</p>

<ul class="dash-list"><li>result_type 定义过细(如十几层的嵌套模型)会让模型频繁重试、token 成本翻倍——先宽松后收紧,按需裁剪字段。</li><li>在 async 接口里调用 run_sync 会阻塞事件循环导致请求排队,一律用 await agent.run()。</li><li>用精简包部署时容易漏装 provider extras,运行时才报「unknown provider」——把 extras 写进 pyproject.toml 或 requirements.txt。</li><li>API Key 不要写进代码或提交仓库,走环境变量或密钥管理服务,.env 加入 .gitignore。</li><li>工具函数内做重 IO(查库、调外部 API)时,要给 LLM 并发调用留好限流与超时兜底,避免打爆下游。</li></ul>

python15 行
# app.py:将 Agent 暴露为 HTTP 接口from fastapi import FastAPIfrom pydantic import BaseModelfrom pydantic_ai import Agent app = FastAPI()agent = Agent('openai:gpt-4o', result_type=str) class AskRequest(BaseModel):    question: str @app.post('/ask')async def ask(req: AskRequest):    result = await agent.run(req.question)    return {'answer': result.data}
维度Pydantic AILangChainLlamaIndexCrewAI
定位类型安全 Agent 框架通用 LLM 应用编排框架数据与 RAG 框架多 Agent 协作框架
编排范式函数式 Agent + Graph 状态机Chain / LangGraphQuery Pipeline角色化 Crew 协同
类型约束强(Pydantic 全链路校验)弱(自由组合)中(偏数据结构)弱
学习曲线低(核心概念少,API 简洁)高(概念与抽象多)中中
生态集成主流模型 + MCP + Logfire数百种集成,覆盖面最广数据源、向量库丰富多 Agent 协作生态
生产部署轻量,易嵌入 FastAPI,类型即接口契约复杂编排能力强,配套齐全RAG 场景成熟任务分发与委派场景
LicenseMITMITMITMIT
适合谁Python 工程师、类型安全优先的团队需要生态广度与复杂编排的团队知识库/检索团队多角色分工的任务型团队

选型建议:团队 Python 原生、重视类型安全、可观测性与运维成本,选 Pydantic AI;需要打通数百个第三方集成、做极其复杂的编排,选 LangChain;核心诉求是文档解析、向量索引、混合检索等 RAG 能力,选 LlamaIndex;业务本身就是「多个角色分工协作」的任务流,CrewAI 的角色化模型更贴合。

版本迭代

Pydantic AI 于 2024 年 12 月发布 0.1.0,主打类型安全 Agent;2025 年 3 月 0.2.0 完成架构重构,引入 Graph API 并拆分精简包 pydantic-ai-slim;此后以约每月一版的节奏围绕 MCP、Evals、可观测性持续迭代。0.1.x 到 0.2.x 存在 breaking change,选型与升级需关注官方迁移说明(截至训练数据,可能已有更新版本)。

版本时间变化提升
0.1.02024-12首个公开版本Agent、工具调用、结构化输出、依赖注入核心 API 上线
0.2.02025-03架构重构引入 Graph API;拆分 pydantic-ai-slim;provider 体系统一
0.2.52025-06能力扩展MCP 支持增强;流式输出与多 Agent 协作完善
0.2.92025-09运维与评测Evals 框架完善;Logfire 观测集成;稳定性与性能优化
结论

Pydantic AI 是框架而非模型,不参与 MMLU、HumanEval 等模型基准榜单,故不设评测分数表。版本间的实测差异主要体现在 API 稳定性:0.1.x 与 0.2.x 之间有破坏性变更(包拆分、Graph 引入),而 0.2.x 系列内部保持向后兼容——新项目直接选择 0.2.x 最新版,存量 0.1.x 项目升级时先跑官方迁移指南。

AI 应用场景

客服工单结构化提取与自动路由

阶段:Agent 编排 + 结构化输出

解决的问题:传统关键词规则提取工单字段(类型、优先级、客户等级)难以覆盖口语化表达,规则越写越多、维护成本高。Pydantic AI 用 result_type 声明工单模型,模型输出自动校验归类,结构不合规时框架自愈重试。

具体案例:某电商客服接入后,用 Agent 提取工单结构并路由到对应处理队列。典型效果是单张工单处理从分钟级降至秒级,字段提取准确率从规则引擎的约 78% 提升至约 93%(内部评测集口径)。

企业知识库 RAG 问答(带引用溯源)

阶段:RAG 管道构建 + 工具调用

解决的问题:通用 RAG 管线把检索和生成耦合在提示词里,召回结果格式不受控、引用无法结构化返回。Pydantic AI 把向量检索封装为工具函数,结果输出用 Pydantic 模型约束「答案 + 引用列表」,引用缺失直接触发重试。

具体案例:某制造企业将产品手册接入后,问答响应中引用格式合规率接近 100%,人工核对引用的工作量减少约 70%,答案平均生成时间在 3 秒内。

自然语言查询数据的 NL2SQL 助手

阶段:Agent 编排 + 工具参数校验

解决的问题:直接让模型生成 SQL 有语法错误、表名幻觉与注入风险。Pydantic AI 用工具函数声明 safe_query 接口,参数经 schema 校验后只允许白名单内的表名与字段,从机制上阻断非法查询。

具体案例:某数据分析平台接入后,业务人员用自然语言查询订单与库存数据,SQL 生成一次通过率约 85%,非法表名/字段访问全部被工具层拦截,未再发生过查询注入事件。

常见误区

误区以为它只是把 LLM 输出转成 Pydantic 模型的小工具,复杂 Agent 还得用 LangChain,所以犹豫要不要学。

正解它是完整的 Agent 框架:工具注册与参数校验、依赖注入、多模型 Provider、Graph 状态机、Evals 评测、MCP 协议、流式输出全部内置。类型安全是核心设计哲学,而不是它的全部能力边界。

为何常见:官方首页的 15 行 demo 太简洁,很容易让人误判为「玩具级」项目,低估了生产级能力。

误区声明了输出结构就高枕无忧,生产环境绝不会因输出格式崩溃。

正解框架做的是「校验 + 自动重试」双保险,但重试次数有上限(max_retries),超过上限仍会抛异常;超长输出被截断、嵌套结构过于复杂时,校验失败概率会明显上升,仍需业务兜底。

为何常见:官方示例几乎一次成功,让人误以为校验机制是万无一失的保险丝。

误区精简包装上后,调用任何 provider 都应该开箱即用。

正解slim 只包含核心运行时,OpenAI、Anthropic、Gemini、Ollama 等 provider 都要按需安装对应 extras,如 pip install "pydantic-ai-slim[ollama]"。装错或缺装时,运行时才会报 provider 相关错误。

为何常见:「slim」被直观理解为「功能略微缩减」,但没有强调 provider 必须单独附加这一机制。

误区对同一个 Agent 实例连续 run_sync 几次,它就像聊天机器人一样记得前面说过什么。

正解Agent 默认无状态,每次 run 都是独立会话。需要多轮记忆时要显式维护 message_history 并传回,或用自有存储记录会话;持久化方案需要自己实现,框架不内置数据库。

为何常见:日常使用的聊天产品都自带记忆,容易把产品体验投射到框架 API 上。

误区同步接口调用方式在任何地方都能用,只是「慢一点」。

正解run_sync 是阻塞式调用,在 async 事件循环里会卡住整个 worker,导致其他请求排队。async 环境中必须用 await agent.run();长输出用 run_stream 边生成边下发。

为何常见:快速原型阶段同步写法最顺手,带病代码一路复制进生产后才暴露并发问题。

面试题

Q1. Pydantic AI 是由哪个团队开发的?

单选题 · easy

  • A.微软研究院
  • B.谷歌 DeepMind
  • C.Pydantic 团队← 正确答案
  • D.Hugging Face

答案:C。Pydantic AI 由 Pydantic Services Inc. 开发,与 Python 生态最流行的数据校验库 Pydantic 同源,因此深度复用 Pydantic v2 的类型校验机制。其余选项均为其他知名 AI 机构。

Q2. 只安装核心运行时、按需补充模型依赖的安装命令是?

单选题 · easy

  • A.pip install pydantic-ai
  • B.pip install pydantic-ai-slim← 正确答案
  • C.pip install pydantic
  • D.pip install langchain

答案:B。pydantic-ai-slim 是精简版,只含核心 Agent 运行时,模型 provider 需要用 extras 单独附加;pydantic-ai 全量包含所有内置 provider;pydantic 只是数据校验库本身;langchain 是另一个编排框架。

Q3. 声明 Agent 结构化输出类型时使用哪个参数?

单选题 · mid

  • A.model=
  • B.tools=
  • C.result_type=← 正确答案
  • D.system_prompt=

答案:C。result_type 指定最终输出的结构(Pydantic Model、TypedDict 或基础类型),框架据此校验输出并自动重试。model 指定模型标识,工具通过 @agent.tool 注册,系统提示词通过 @agent.system_prompt 提供。

Q4. 在工具函数中访问依赖与对话状态,应使用哪种类型标注?

单选题 · mid

  • A.RunContext[T]← 正确答案
  • B.Depends[T]
  • C.RunResult[T]
  • D.Message[T]

答案:A。RunContext[T] 携带 deps(外部依赖,如数据库连接、用户信息)与内部消息状态,是依赖注入的载体。RunResult 是运行结果而非上下文,Message 是消息对象,Depends 的用法与 RunContext 不同。

Q5. 关于 @agent.tool 装饰器,下列说法正确的是?

多选题 · mid

  • A.工具函数参数会生成 JSON Schema 供模型调用← 正确答案
  • B.工具参数在运行时由 Pydantic 校验完成← 正确答案
  • C.只支持同步函数,不支持异步函数
  • D.工具默认名取函数名,可自定义修改← 正确答案

答案:ABD。@agent.tool 注册的工具会由框架生成函数 schema 供模型调用(A 对);参数在每次调用时经 Pydantic 校验(B 对);支持 async 工具函数(C 错);可通过 @agent.tool(name=……) 自定义工具名(D 对)。

Q6. 模型输出未通过 result_type 校验时,框架默认行为是?

单选题 · hard

  • A.直接抛出 ValidationError 异常
  • B.丢弃结果并返回 None
  • C.回传校验错误并自动重试← 正确答案
  • D.自动降级为字符串输出

答案:C。Pydantic AI 的核心机制是「校验失败 → 把错误信息注入对话 → 让模型重新生成」,默认有重试次数上限(max_retries 可配置)。超过上限仍失败才会抛异常,不会静默降级或返回空值。

Q7. 以下哪些是 Pydantic AI 内置支持的模型 provider 标识?

多选题 · mid

  • A."openai:gpt-4o"← 正确答案
  • B."anthropic:claude-sonnet-4"← 正确答案
  • C."ollama:llama3.1"← 正确答案
  • D."tensorflow:bert"

答案:ABC。内置 provider 覆盖 OpenAI、Anthropic、Gemini、Ollama、Groq、Mistral 等,标识格式统一为「provider:model」。tensorflow:bert 不是受支持的模型标识——TensorFlow 是训练框架,不是 LLM provider。

Q8. Pydantic AI 0.2.0 引入的、用于建模复杂 Agent 流程的 API 是?

单选题 · hard

  • A.LangGraph 外部编排框架
  • B.Graph API(节点与边构成)← 正确答案
  • C.Pipeline API 管道接口
  • D.内置时序数据库系统

答案:B。0.2.0 内置 Graph API,把 Agent 流程建模为有向图,支持条件跳转、并行节点与失败回退,省去外部编排依赖。LangGraph 是 LangChain 生态的类似方案但并非 Pydantic AI 内置能力。

Q9. 在 FastAPI 等 async 环境中运行 Agent 的正确方式是?

单选题 · easy

  • A.调用 agent.run_sync()
  • B.使用 await agent.run()← 正确答案
  • C.调用 agent.await_run()
  • D.用 asyncio 再包一层

答案:B。run_sync 是阻塞式同步调用,在 async 接口中会卡住事件循环;正确做法是 await agent.run(),长输出场景用 run_stream() 边生成边返回。await_run 方法不存在。

Q10. 生产环境部署 Pydantic AI 时,哪些做法正确?

多选题 · hard

  • A.API Key 走环境变量或密钥管理← 正确答案
  • B.用 Logfire 记录运行日志与 token← 正确答案
  • C.全局复用 Agent 实例提高性能← 正确答案
  • D.对用户输入不设任何长度限制

答案:ABC。密钥不进代码仓库、接入可观测性、复用无状态 Agent 实例(Agent 默认无状态,可安全复用)都是正确实践。用户输入应做长度与内容限制,否则超长上下文会推高成本并放大提示词注入风险。