Pydantic AI：把AI代理当软件写，不是包层提示词

Pydantic AI不是又一个给提示词套壳的漂亮封装。它的价值在于逼你把一个代理当成软件来对待：输出契约、显式依赖、经过验证的工具、使用限制、追踪和评估。 这是一个Python框架，用来构建AI应用和代理，思维方式和FastAPI一脉相承：类型、验证、依赖注入、声明式工具、结构化输出、可观测性和评估。 什么时候该用它 我的立场很明确：当代理要接触真实数据或真实决策时，Pydantic AI才有意义。如果你只想要一个聊天演示，随便哪个封装都行。如果你需要输出可验证、可测试、可观测，这里才开始划算。 大多数代理演示失败的原因都一样：把大语言模型当成一个返回文本的魔法盒子。生产环境里这不够。你需要知道响应应该是什么形状，它能调用哪些工具，调用多少次，用什么数据，在什么限制之下。 Pydantic AI从一个非常务实的角度切入：如果你已经在用Pydantic验证API的输入输出，那就用同一套肌肉去验证模型生成的决策。 一个严肃代理的最小架构 一个合理的Pydantic AI代理有五块拼图： 一个带指令和模型的Agent 一个用BaseModel定义的output_type，规定它必须返回什么 显式依赖，用来传递服务、租户、用户或连接 带验证参数的工具 使用限制和可观测性，免得月底在账单上才发现成本 优势不在于模型变得更聪明。优势在于模型周围的契约收得更紧。更少的自由文本，更少的隐式状态，更少的藏在提示词里的魔法。 健康的边界是：大语言模型负责推理，但你的应用定义契约、依赖、允许的工具、使用限制和可审查的追踪。 第一个可运行示例：类型化输出 这个示例不追求花哨。重点是展示模式：一个BaseModel定义输出，代理验证它，你的代码把result.output当作Python对象来消费，而不是用胶带粘起来的JSON。 代码里，Review类继承BaseModel，用Field定义字段，Agent绑定这个输出类型。模型返回的内容会被校验成Review实例，后续代码直接访问属性，不需要手动解析字典。 特别