技能介绍

它解决什么问题

把 LLM 塞进生产代码时，你很快会遇到两类摩擦：一是输出不可控，模型返回的 JSON 经常字段缺失、类型漂移，response.choices[0].message.content 解析完还得再做一轮校验；二是胶水代码越写越多，prompt 管理、模型切换、重试、日志散落在不同文件里，改一个依赖就要连带改一片。PydanticAI 的目标是让 GenAI 应用像写 FastAPI 一样自然：把 prompt 和类型约束写在一起，让框架在调用模型前后自动完成校验与转换。

核心能力与工作方式

类型安全的 Agent 构建：Agent 的定义直接绑定 Pydantic 模型，输入和输出都用 Python 类型标注，运行前生成、运行后校验，减少手工 json.loads 和字段判断。
模型无关：底层模型可替换，业务代码不绑死某一家 SDK，便于在本地模型和云端 API 之间切换。
结构化输出：指定返回类型后，框架负责把模型输出转成符合模型的实例，而不是返回一段需要二次解析的字符串。
依赖注入：可以把数据库连接、外部服务客户端等作为依赖注入到 Agent 里，测试时替换成 mock，逻辑和 IO 分离。
可观测性：与 Pydantic Logfire 打通，能追踪一次 Agent 运行中的请求、校验、工具调用等环节。

使用时，先定义输入输出模型，再创建 Agent 并传入模型与 prompt；框架负责组装请求、调用模型、校验结果，失败时可以按配置重试或报错。需要更复杂的动态指令时，可以在运行时根据上下文生成 prompt 片段，而不是把所有逻辑硬编码进字符串。

适用边界与注意点

它适合需要长期维护、强类型约束的 Python 后端服务，尤其是已经用 Pydantic 做数据校验的项目。对于一次性脚本、原型验证，或者需要精细控制模型推理参数的场景，直接调用对应 SDK 可能更直接。此外，框架的抽象会带来少量额外层，调试时需要理解它的校验与执行流程；模型输出仍然不是百分百可靠，结构化输出只能降低风险，不能替代业务层的边界检查。