Google 升级 Gemini API 结构化输出：原生支持 Pydantic，保留字段顺序

如果你用大模型做过后端开发，多半经历过这种抓狂时刻：你千叮咛万嘱咐让它输出纯 JSON，它偏偏在前后给你包几句客套话，或者字段名拼错、数据类型对不上，直接把下游的解析服务干崩。

为了彻底解决这个问题，Google 宣布对 Gemini API 的结构化输出能力进行了一次重要升级。这次升级不仅扩大了对标准 JSON Schema 的支持，还让输出的字段严格遵循 Schema 中定义的顺序。

告别胶水代码，Pydantic 和 Zod 终于开箱即用

对开发者来说，这次最大的利好是生态对齐。所有处于活跃支持状态的 Gemini 模型，现在都能直接配合 Python 的 Pydantic 和 JavaScript/TypeScript 的 Zod 使用，省去了中间那层繁琐的数据转换胶水代码。

Google 还在这个版本里补齐了一批呼声很高的 JSON Schema 核心关键字。比如用来处理条件联合类型的 anyOf、支持递归嵌套模式的 $ref，以及针对数值限制的 minimum 和 maximum。

除此之外，新规范还加上了针对元组式数组的 prefixItems、额外属性控制字段 additionalProperties，以及对 null 类型的显式声明。基本上把平时写严谨数据验证时能踩到的坑，都从协议层面堵上了。

让键值按顺序吐出来，连兼容接口也管用

另一个看似微小、实际影响巨大的改进是字段输出顺序。

从 Gemini 2.5 系列模型开始，API 能够严格按照你在 Schema 里定义的键名顺序依次返回字段。这项能力同样覆盖了 Google 提供的 OpenAI 兼容接口。

这在实际工程里意义不小。比如在内容审核场景中，模型可以先按顺序返回分类原因，最后再给出结论；开发者在做流式解析时，不需要等整个 JSON 对象吐完，就能按固定顺序提前拿到前置字段进行处理。

根据早期合作伙伴的数据，这种强约束机制能带来真金白银的收益。一些团队在生产环境中彻底消除了因为 JSON 格式残缺导致的重试，不仅避免了服务报错，还将特定场景下的 API 调用次数减少了最多 6 倍。

为什么重要

我们认为，Google 这次补丁看起来只是修修补补，实际上踩中了 AI 应用落地最核心的一根软肋：工程可靠性。

对于做 Multi-Agent 多智能体协作和复杂数据管道的团队来说，模型聪明不聪明其实只是一方面，输出稳不稳定才是决定系统能不能上线的生死线。前一个 Agent 的输出如果不能百分之百作为后一个 Agent 的安全输入，系统就得靠一堆重试和清洗逻辑吊着命。

Google 聪明的地方在于，它没有自己造一套新的数据验证轮子，而是老老实实向社区标准看齐。直接把 Pydantic 和 Zod 扶正，同时连 OpenAI 兼容层都照顾到了，这摆明了是要大幅降低开发者从竞品迁移过来的摩擦力。

现在的 Gemini 2.5 已经完全值得拿来重构你的数据提取和结构化业务。虽然对于只把大模型当聊天机器人用的普通人来说感知不强，但只要你打算把大模型插进现有的业务数据库或后端服务里，这次更新就是那种能让你少熬几个夜的扎实改进。