上一篇介绍了 Function Calling：让大模型能够根据用户目标选择工具、生成参数，并调用数据库、业务 API 或其他程序能力。

但 Agent 真正接入业务系统后，还存在另一个同样重要的问题：模型产生的结果，怎样可靠地交给程序处理？

例如用户告诉 Agent：

请创建一个任务：8 月 14 日前完成华东区客户回访方案，优先级高，负责人张晨，预算不超过 5000 元，并拆成整理客户名单、执行回访和汇总结果三个子任务。

模型很容易生成一段自然语言：

“任务名称为华东区客户回访方案，优先级较高，负责人张晨，截止时间为 8 月 14 日……”

人能够轻松理解，但程序却需要继续判断：

“较高”究竟对应 HIGH 还是 URGENT？“8 月 14 日”是哪一年？5000 的货币单位是什么？子任务如何映射到数据库？如果用户没有明确负责人，模型应该填空、猜测，还是要求用户补充？

这就是 Structured Output（结构化输出） 要解决的问题。

它的核心并不是“让模型返回 JSON”，而是：

让模型按照程序预先定义的数据契约返回结果，使数据能够被解析、验证并安全地进入后续业务流程。

一、为什么 Agent 不能只依赖自然语言输出

普通聊天应用的最终消费者是人，因此输出一段自然语言通常没有问题。

但 Agent 的结果经常需要继续进入：

这时，自然语言就会成为系统自动化的障碍。

例如模型返回：

程序必须再次理解“比较高”和“下周”。

如果模型改成：

处理显然容易很多。

因此，Agent 系统中经常需要完成一次转换：

这就是 Structured Output 最基本的价值。

二、让模型“返回 JSON”还不够

最简单的方法是在 Prompt 中写：

模型可能返回：

它确实是 JSON，但业务程序真正需要的可能是：

两份内容从人类视角看差异不大，对程序而言却完全不同。

因此需要区分三个层次：

方式能解决的问题仍然存在的问题Prompt 要求 JSON尽量让模型返回 JSON可能夹杂文本、字段漂移JSON Output / JSON Mode保证结果是合法 JSON不一定符合指定业务结构Structured Output + Schema同时约束字段、类型和结构仍需业务规则校验","rows":4,"cols":3,"id":"G5jr0"}">

这一区别非常重要。

拿当前的 OpenAI API 来说，官方文档其实把 JSON Mode 和 Structured Outputs 分得很清楚。

JSON Mode 解决的是“输出必须是合法 JSON”这个问题。

而 Structured Outputs 更进一步，能把结果约束到指定的 JSON Schema 上。

也正因为如此，OpenAI 给出的建议很明确：只要模型支持，优先用 Structured Outputs。

DeepSeek 当前公开 API 提供的则主要是 JSON Output，通过：

保证模型生成合法 JSON。

同时，仍需要在 Prompt 中明确要求 JSON，并描述希望得到的数据格式。

这两种实现恰好可以帮助我们理解：

三、Structured Output 本质上是一份数据契约

传统后端开发对此其实并不陌生。

例如 Spring Boot API：

DTO 就是在定义系统之间的数据契约。

但很多早期大模型应用却是：

Structured Output 的作用，就是把传统软件工程中的“数据契约”重新引入模型调用。

因此可以这样理解：

Prompt 描述模型应该完成什么任务，Schema 描述程序能够接受什么结果。

两者解决的是不同问题。

四、案例：把自然语言转换成任务单

继续前面的案例。

用户输入：

Agent 最终希望得到：

这才是一份真正适合程序继续处理的数据。

例如：

而不是让任务服务继续解析一段自然语言。

五、用 JSON Schema 定义模型可以返回什么

为了避免模型随意生成字段，可以进一步定义 JSON Schema：

这样，“优先级”就不能随意变成：

而只能从：

中选择。

这就是 Schema 相比“请返回 JSON”更重要的地方。

六、OpenAI：从 JSON Mode 到真正的 Structured Outputs

OpenAI API 可以很好地说明 Structured Output 的演进。

早期 JSON Mode：

主要解决：

保证模型输出合法 JSON。

Structured Outputs 则进一步通过 JSON Schema 定义结构，并能够要求严格匹配 Schema。

OpenAI 当前文档明确建议，在支持的模型上优先使用 Structured Outputs，而不是旧的 JSON Mode。

拿 Responses API 来说，输出格式可以直接约束成 JSON Schema。

目前在 OpenAI 的 API 里，Responses API 的 Structured Outputs 配置已经归到 text.format 下面了。

而 Chat Completions 这边，依然可以通过对应的 response format 来实现结构化输出。

概念上可以简化成：

模型生成时就不只是被要求：

而是被明确约束：

因此系统链路从：

逐渐变为：

这是一个非常重要的变化。

Schema 开始成为模型 API 的一部分，而不仅仅是 Prompt 中的一段文字说明。

七、DeepSeek：JSON Output 应用侧 Schema 校验

DeepSeek 提供了一个很适合工程实践的另一种情况。

当前 DeepSeek API 可以通过：

启用 JSON Output。

官方文档同时要求在 system 或 user Prompt 中明确包含 JSON 输出要求，并建议提供目标 JSON 格式示例。

还需要合理控制最大生成 Token，避免 JSON 被截断。

例如：

这里需要特别注意：

• DeepSeek JSON Output 可以帮助我们保证：输出是 JSON

• 但应用层仍然应该继续做校验与转换

而不能认为：

这其实非常接近大量企业系统实际面对的情况。

因此，即使模型 API 本身没有提供和 OpenAI Structured Outputs 完全相同的 Schema 约束能力，也可以通过应用层建立完整的数据契约体系。

八、两种路线最后应该汇聚到同一个架构

无论使用 OpenAI 还是 DeepSeek，生产系统最终都不应该把模型输出直接交给业务 Service。

比较合理的架构是：

其中 OpenAI 可以更多依赖模型侧 Structured Outputs。

DeepSeek 可以更多依赖：

但后半段仍然应该保持一致。

九、Ja va 应用真正需要的是 DTO，而不是 JSON 字符串

Ja va 项目不应该让大量业务代码围绕：

不断手工读取字段。

更合理的是定义明确的数据类型：

assignees,n Budget budget,n List subtasks,n List clarificationQuestions) {n public enum Status {n READY,n NEEDS_CLARIFICATIONn }n public enum Priority {n LOW,n MEDIUM,n HIGH,n URGENTn }n public record Budget(n BigDecimal amount,n String currency) {n }n public record SubTask(n String title,n boolean required) {n }n}","id":"bNPY4"}">

最终形成：

如果使用支持 Schema 驱动 Structured Output 的模型，还可以进一步：

这样模型接口与 Ja va 类型系统之间就建立了更加稳定的映射关系。

十、TypeScript 中 Interface 为什么还不够

前端经常会定义：

但 TypeScript Interface 只存在于编译阶段。

下面的代码：

并不会因为定义了 TaskTicket 就自动验证模型返回的数据。

因此 AI 应用边界更适合增加运行时 Schema，例如：

再执行：

形成：

这也是 Structured Output 很重要的一点：

类型约束不能只存在于开发阶段，还应该存在于模型与程序的运行时边界。

十一、枚举、日期和金额是最容易出问题的字段

结构化输出并不只是定义几个 JSON Key。

真正进入业务系统时，很多基础类型都需要仔细设计。

1. 枚举

不要让模型自由生成：

应该限制成：

然后再由前端负责国际化显示。

2. 日期

不要让数据库接收：

应该转换为：

如果无法确定年份，不应该由模型偷偷猜测。

3. 金额

建议将金额与货币分开：

Ja va 中金额通常使用：

而不是：

4. 嵌套对象

例如地址不要定义成：

如果后续需要分别处理省、市、区，则应直接设计：

Structured Output 的数据结构最终仍然应该由业务模型决定，而不是由模型自由设计。

十二、Schema Valid 仍然不等于 Business Valid

这是 Structured Output 中最容易被忽略的问题。

假设模型生成：

它可能完全符合 JSON Schema。

但系统规定：

那么这个结果仍然不能执行。

因此生产系统至少需要三层校验：

还可以继续增加第四层：

最后才是：

因此完整链路应该是：

十三、模型输出错误时怎么办

即使使用 Structured Output，也不能删除异常处理。

错误大致可以分成三类。

第一类：格式错误

例如：

可以：

第二类：可以确定性修复的问题

例如：

这类问题优先使用程序代码修复。

第三类：业务语义不确定

例如用户说：

模型不能擅自变成：

更合理的是：

也就是说：

程序可以修复格式，但不要擅自修复业务含义。

十四、为什么不能无限重试模型

一种常见的实现方式是：

这种做法很容易形成不可控循环。

生产系统应该设置：

超过次数后：

因为连续输出错误可能说明：

继续重复生成往往只是增加 Token 消耗。

这也为后面的 Agent Harness 埋下伏笔：

模型的不确定性必须由运行时系统进行约束，而不能期待模型自己永远正确。

十五、Structured Output 和 Function Calling 有什么关系

这是上一篇与本篇最重要的衔接。

Function Calling 主要解决：

Agent 要调用哪个程序，以及传什么参数。

Structured Output 主要解决：

Agent 最终应该按照什么格式把结果交给程序。

例如：

OpenAI 官方文档也明确区分了这两个场景：连接模型与系统工具时使用 Function Calling；需要约束模型最终响应的数据结构时，则使用 Structured Outputs。

可以进一步把二者理解为：

以及：

这两个方向共同构成 Agent 与软件系统之间的接口边界。

十六、OpenAI 与 DeepSeek 在工程上可以统一封装

企业系统很少应该把业务代码直接绑定某一家模型 API。

例如：

到处出现这种代码会让后续模型切换非常困难。

更合理的是增加统一的 Model Gateway：

业务层只定义：

Model Gateway 根据 Provider 能力选择实现。

例如：

或者：

最终统一输出：

这样业务 Service 不需要关心底层调用的是哪个模型。

十七、生产级 Structured Output 推荐架构

将前面的内容组合起来，可以得到一套比较完整的实现方式。

生产级 Structured Output 架构

这里有一个非常重要的设计原则：

模型 Provider 的差异应该被隔离在 Model Gateway，而不是扩散到业务层。

十八、生产环境中的几个建议

Structured Output 真正落地时，可以遵循以下原则。

1. 优先使用模型原生结构化能力

OpenAI 支持 Structured Outputs 时，优先使用 JSON Schema，而不是只依赖：

OpenAI 当前文档也明确推荐在支持的模型上优先使用 Structured Outputs，而不是旧 JSON Mode。

DeepSeek 则可以采用：

其官方文档还特别提醒，使用 JSON Output 时需要在 Prompt 中显式要求 JSON，并合理设置生成 Token，避免内容被截断。

2. 让业务类型驱动 Schema

推荐：

而不是：

避免三份数据结构逐渐不一致。

3. Schema 尽量简单

不要设计：

如果一个输出对象已经极其复杂，往往意味着任务本身也应该被拆分。

4. 为 Schema 增加版本

例如：

因为 Structured Output 本质上也是一种 API Contract。

5. 高风险操作采用 Fail Closed

如果模型返回结果无法确认：

而不是：

尤其是：

这类带副作用的操作。

十九、Structured Output 真正改变了什么

如果只是为了在页面上显示答案，Structured Output 的价值似乎并不突出。

但进入 Agentic AI 后，系统中的数据流正在变成：

模型已经不再只是最后一个“输出文字”的组件。

它开始位于整个业务执行链路中。

因此模型返回的数据必须越来越像传统 API：

这也是 Structured Output 真正重要的地方。

它不是一种让 JSON 更漂亮的技术，而是在：

概率性的模型系统与确定性的业务系统之间建立数据边界。

二十、本篇小结

从普通大模型应用进入 Agent 开发后，我们需要逐渐改变一个习惯：

不要再把模型输出仅仅看作“一段回答”。

很多情况下，它实际上已经成为：

Structured Output 的发展过程可以概括为：

真正需要记住的是：

• JSON Valid 只能说明程序能够解析

• Schema Valid 说明数据结构符合契约

• Business Valid 才说明这份数据真的可以进入业务流程

因此生产级 Agent 不应该是：

而应该是：

上一篇回顾

https://developer.aliyun.com/article/1753887spm=a2c6h.13148508.setting.15.5f284f0e3OGmOs

下一篇预告

下一篇将进一步介绍：RAG。

因为当 Agent 已经能够调用工具，也能够稳定输出程序可处理的数据后，接下来的问题就是：

模型如何获得自己训练数据之外、企业内部或者实时变化的知识？

这也将从模型与程序的连接，进一步进入模型与知识的连接。