如果你最近接了"给业务加点 AI"的活儿，大概率经历过这样的场面：让模型输出 JSON，它回你一坨用 ```json 代码块包起来的"JSON"；让它返回列表，它给你单个对象；让它给个 0 到 1 之间的预估点击率，它大大方方写了个 1.5。
这些输出全是合法 JSON，程序不报错，测试环境跑得好好的，一上生产就开始出"偶发问题"——排序乱了、脏数据入库了、下游渲染崩了。排查半天，最后发现是模型输出"看起来像对的"，悄悄穿过了你的接口。小红书
这正是 2026 年 AI 工程讨论区里出现频率最高的抱怨之一。知乎而社区里被反复提到的解法，是一个很多后端工程师早就熟悉的老朋友：Pydantic。只不过这一次，它的战场变了。
Pydantic 悄悄换了战场
过去几年你对 Pydantic 的印象，大概率来自 FastAPI：定义请求体和响应体，非法输入自动 422，API 文档自动生成。它干的是"替你把住用户输入"这件事。
但 2026 年，数据校验最大的增量场景，已经从"用户输入"变成了"模型输出"。几个信号放在一起看，趋势很清楚：
LangChain、LangGraph、instructor，乃至各家模型 SDK 的结构化输出能力，底座几乎都是 Pydantic 模型；
DeepLearning.AI（吴恩达团队）专门开了一门课，就叫《Pydantic for LLM Workflows》，从模型基础、响应验证讲到 API 调用和工具调用实战。B站这门课在 B 站的搬运版本播放量加起来超过 2.5 万、收藏 1600+，教程市场已经用脚投票；
Pydantic 官方自己推出的 Agent 框架 PydanticAI，2026 年 6 月 23 日发布 2.0，随后两周内连更到 2.5.1，官方状态标着 Production/Stable。知乎知乎上一篇八大 Agent 框架横评，直接把它放进了综合成熟度第一梯队。知乎
换句话说：模型越普及，"把模型输出变成可信数据"这门手艺就越值钱，而 Pydantic 恰好是这门手艺的事实标准。对已经在用 FastAPI 的你来说，这里有个很实在的成本账——BaseModel、Field、validator 这套心智模型完全复用，几乎零迁移成本。别人还在挑新库，你已经拿着现成工具进场了。
大模型的三种"合法垃圾"
先别急着写代码。模型输出的坑不是一种，是三种，对应的守法也不一样。分不清这三类，写再多 if-else 都是白搭。
第一类：格式层垃圾。模型把 JSON 包在 markdown 代码块里、尾部多个逗号、输出被 token 上限截断、该给列表给了单对象。这类数据连 json.loads 都过不去，崩得最响，反而最好处理。
第二类：契约层垃圾。JSON 合法，但和你约定的契约对不上：temperature 传回来是字符串 “0.7”，整数 256 变成字符串 “256”，前端多塞了一个你没声明的 admin 字段——默认配置下 Pydantic 会把它悄悄忽略，你连被注入了什么都不知道。这类问题最阴险，因为它们就是"schema 漂移"的起点。
第三类：语义层垃圾。这一层最容易被低估：字段都在、类型都对，但业务上是错的。比如模型自称"拒答"，同一个响应里却把答案给出来了；比如预估分数超出 [0,1] 区间但类型是 float，校验器没拦住就污染了排序逻辑。社区里有人总结得很到位：Schema 通过 ≠ 内容可信。
知乎上一个讲 Schema 驱动开发的实战帖（用自己做的自媒体 Agent 项目拆解）和小红书上昨天刚发的一篇"Pydantic 数据可靠性守门员"笔记，都把防线设计成了三层。知乎小红书下面的结构基本就是社区共识的整理。
三道关怎么设
第一道关：输入关，别浪费任何一次模型调用。
给接收用户请求的模型（比如 ChatRequest）上两个关键设置：`extra=“forbid”`，未声明字段直接拒绝，admin 这种字段混不进来；`strict=True`，字符串 “256” 不会悄悄变成整数 256，契约漂移在门口就被拦下。小红书再配合 Field 给消息限长、给参数限定取值范围——非法输入统一 422，一次无效的模型调用都不让它发生。调用大模型是按 token 收费的，守住入口就是在守钱。
第二道关：输出关，这是 AI 数据层的主战场。
这里有个很多人忽略的技巧：给 LLM 的 schema 和你内部用的模型，应该是两个。内部模型有 id、created_at、persona_id 这些系统字段，但 LLM 根本不需要知道它们——给模型的 schema 越简洁，输出越稳定。
拿到输出后，用 `model_validator(mode=“after”)` 做跨字段一致性检查：比如"已回答"分支必须有答案且无拒答原因，"已拒答"分支必须相反，两个条件互斥，分支不一致直接打回。小红书数值字段用 `Field(ge=0.0, le=1.0)` 卡住边界，1.5 这种值进不了下游。离散取值用 `str, Enum` 混写——既限定取值范围，又兼容字符串操作。
第三道关：落盘与配置关。
Agent 的状态要存盘再恢复，`model_dump(mode=“json”)` 一行序列化（datetime、Enum、嵌套模型全自动处理），`model_validate` 一行读回。读回的时候记得给每条数据单独 try/except——版本升级后旧数据可能校验失败，一条坏数据不该让整个加载崩掉。配置文件同理，用 Pydantic 模型接住，错误在启动时暴露，总好过在运行时的某个凌晨三点随机炸掉。
三层防线：Schema 只是第一层
社区实战里反复被验证的一句话是：Schema 不是银弹，Schema + 修复 + 降级，才是完整方案。知乎
修复层：模型输出的三种"任性"形态（代码块包裹、裸列表、混入解释性文字），写一个统一的提取函数兜住；模型返回裸列表时，自动包进 schema 里那个唯一的 list 字段。
降级层：每一次结构化输出调用，都要有 fallback。解析彻底失败时返回什么默认值、要不要重试、重试几次，提前想好，别让异常直接冒到用户面前。
还有一个值得抄的机制，来自结构化输出库 instructor 的 re-ask 设计：校验失败时，不是原样重发请求（那只会得到同样的错答案），而是把 Pydantic 生成的完整错误报告追加进对话，让模型看着自己的错误改。知乎这个思路哪怕你不用 instructor，也完全可以手写实现。
顺带几个坑，都是社区踩出来的。可变默认值用 `default_factory=list` 而不是 `default=[]`，后者是 Python 的经典陷阱——所有实例会共享同一个列表。知乎在 after 验证器里赋值用 `object.setattr` 绕过二次校验。模型字段的 description 也要认真写——在结构化输出场景里，这些描述会被原样拼进发给模型的 prompt。<#&!53#&!>知乎描述越清楚，抽取越准。
也得说清楚边界
有一类期待要提前打消：Pydantic 是边界守门员，不是事实裁判。格式正确 ≠ 用户真实存在 ≠ 请求有权限 ≠ 内容事实正确。小红书事实核查、权限校验、幻觉检测，仍然需要别的层来做。
另外几种情况也不值得硬上：一次性的实验脚本，直接调 API 更轻；团队已经深度绑定某个全栈 Agent 平台的，没必要为了"政治正确"迁移。还有一点提醒：如果你还停在 Pydantic v1，2026 年的整个生态（包括 Rust 写的 v2 校验核心）都已经往前走了，这不再是可选项。JS/TS 阵营的同学也不用急，这个生态位上你们有 Zod，思路是完全相通的。
最后给个版本提醒：PydanticAI 2.x 迭代非常快（6 月底到 7 月中就发了六个版本），生产项目务必锁定版本，把升级当成一次需要回归测试的变更来对待。知乎
谁值得现在认真看这篇
FastAPI 后端、刚接 AI 任务的工程师：性价比最高的一群人，复用已有知识就能把最痛的输出问题接住；
正在写 Agent 的开发者：把开发顺序改成"先定 Schema，再写逻辑"，数据结构就是模块间的契约，这套纪律比任何框架选型都保值；
只跑一次性实验的算法同学：可以轻装，但建议至少知道 `model_validate` 怎么用，迟早用得上。
值得持续关注的信号：PydanticAI 2.x 的 API 什么时候真正稳定下来、官方可观测产品 Logfire 的计费模式、以及那个为 Agent 重写 Python 运行时的 Monty 项目——后者如果成了，"模型执行代码"这件事的安全边界会被重新定义。
一句话收尾：模型负责生成，Pydantic 负责让你敢用。
