结构化输出在工程中有两类常见落点：

1.响应结构化输出：模型的最终回答就是一份符合Schema的JSON，比如工单分类、信息抽取、情感打分。后端直接反序列化消费。

2.工具参数结构化输出：模型输出的是工具名和arguments，arguments需要符合工具参数Schema。模型只负责“要调什么、参数是什么”，真正执行工具、操作外部系统的是业务侧。

---

一个常见的prompt：

请判断下面用户反馈属于哪类工单，返回 JSON。

用户反馈：我付款成功了，但是订单一直显示待支付。

模型可能返回

{
  "category": "payment",
  "priority": "high",
  "reason": "用户付款成功但订单状态未更新"
}

看起来没问题，但是自然语言prompt很难长期守住。常见错误点如下：

1.格式漂移：要求模型返回JSON，它大部分时候会返回JSON，但不代表每次都只返回JSON。输出给人看没问题，程序解析直接失败。尤其在流式输出、长上下文、多轮对话里，模型很容易把之前学到的“解释型回答习惯”带着。

2.字段缺失

3.类型错误（JSON语法合法但业务类型不合法）

4.额外解释文本：模型喜欢添加一些解释文本，适合给人看，不适合给程序解析。

5.边界条件崩溃：用户输入越规整，模型越稳定；用户输入一旦模糊、矛盾或带攻击性，结构就容易崩。

---

生成阶段的三层约束对比

对比维度	JSON Mode	JSON Schema	Structured Outputs
本质	输出格式开关	数据结构描述规范	模型API的结构化生产能力
主要约束	JSON语法合法	字段、类型、枚举、必填、额外属性等	输出尽量或严格匹配Schema
是否保证业务字段完整	不保证	只描述，不执行生成	取决于供应商能力和Schema支持范围
是否负责工具执行	不负责	不负责	不负责，只产出结构化结果
典型用途	简单JSON输出	定义数据契约和校验规则	分类、抽取、函数参数生成、Agent中间结果
仍需服务端校验	需要	需要	需要

JSON Mode管语法，JSON Schema 管契约，Structured Outputs 把契约前移到模型生成阶段；但无论模型侧约束多强，服务端校验都不能省。

---

Function Calling（函数调用） 是指：
大语言模型在理解用户意图后，不是只生成自然语言回答，而是根据预先定义好的函数/工具说明，判断是否需要调用某个外部函数，并生成符合该函数参数格式的调用请求。外部系统执行函数后，把结果返回给模型，模型再根据结果生成最终回答。

简单说就是：让模型从“会聊天”变成“会决定调用工具并使用工具结果回答问题”。

Function Calling的价值就是让模型完成“自然语言意图”->“结构化参数”的映射。但它只负责映射，不负责替你绕过权限、查数据库、扣库存、发短信。

能力	本质定位	解决的问题	谁来执行	典型边界
JSON Mode	输出格式开关	让模型输出合法JSON	模型侧生成	不保证字段和业务语义
JSON Schema	结构描述规范	定义字段、类型、枚举、必填等契约	本身不参与生成，只描述结构	不负责生成和外部调用
Structured Outputs	模型API结构化生成能力	把Schema接入生成，让输出贴合结构	模型侧生成+服务端校验	不负责外部系统调用
Function Calling	模型到工具的调用意图生成机制	自然语言转工具名和参数	通常由业务侧或供应商执行	不等于API本身
MCP	工具和上下文接入协议	标准化工具发现、调用、资源访问	MCP Client/Server协作	不替代模型推理能力
普通HTTP API	业务服务接口	确定性业务读写	后端服务	不理解自然语言
Agent Skill	可复用任务说明和执行SOP	复杂任务的流程编排和上下文注入	Agent按说明执行	不一定包含工具调用

Function Calling 解决模型如何表达“我要调用哪个工具、参数是什么”。

MCP 解决工具如何被标准化发现、描述、调用和返回结果。

维度	JSON Mode	JSON Schema	Structured Outputs	Function Calling	MCP
所在层次	模型输出格式层	结构描述规范层	模型结构化生成层	模型工具意图层	应用协议层
输入给模型的内容	“输出JSON的模型开关”	不直接参与生成	Schema或响应格式定义	工具名、工具描述、参数Schema	通常由Host转换后给模型，协议本身在Client和Server间通信
模型输出	JSON文本	-	符合schema的结构化对象	工具名+参数，或最终回答	不直接规定模型输出，规定MCP消息
是否调用外部系统	x	x	x	生成调用意图，执行在外部	是，MCP Client调MCP S erver
是否跨模型标准化	各厂商实现不同	规范通用，可跨模型复用	Schema支持子集各厂商不同	各厂商格式不同	目标是标准化工具和上下文接入
适合场景	简单结构化文本	定义数据契约和校验规则	数据抽取、分类、参数生成	订单查询、发邮件、查库存等工具任务	多工具、多客户端、团队共享工具生态
主要风险	合法JSON但字段不对	只描述不执行，容易被高估	schema太复杂或支持不一致	工具误调用、参数越权	Server权限、安全边界、协议兼容

---

结构化输出过程化落地

1.schema设计：一个字段只表达一件事

2.字段说明要写“何时用”和“何时不用”

3.枚举优先于自由文本

4.必填字段要谨慎：用 null 明确表达未知，例如 "refundId": null；用状态字段表达缺信息，例如 "status": "NEED_MORE_INFO"

5.版本兼容：新增字段尽量只做可选扩展，避免破坏旧消费者。删除字段要先灰度，确认下游没有依赖。枚举新增要谨慎，因为旧系统可能不认识新枚举。Prompt、Schema、解析代码、看板指标要一起版本化。

6.校验失败重试：让模型修正具体错误

7.降级策略，不能让模型编造业务事实

---

常见面试问题

1.为什么只写“请返回JSON”不可靠

因为这只是自然语言约束，不是工程契约。模型可能输出额外解释文本、漏字段、类型错误、生成未知枚举，或者在复杂上下文里忘记格式要求。生产环境要结合JSON Schema、原生Structrured Outputs、服务端校验、失败重试和降级策略。

2.JSON Mode和Structured Outputs区别

前者主要保证输出是合法JSON，不保证符合业务Schema。StructruredOutputs会把Schema接入生成链路，让输出按供应商支持范围贴合字段、类型、枚举、必填等约束。即使用了Structured Outputs，服务端仍要校验。

3.JSON Schema 在大模型应用里解决什么问题

它把“输出应该长什么样”变成可校验的数据契约。常用能力包括 properties、required、enum、additionalProperties、pattern、minimum、maximum 等。它既能给模型提供结构化约束，也能给服务端做兜底校验。

4.Function Calling 的完整链路是什么

服务端先注册工具定义，模型根据用户请求生成工具名和参数，业务侧校验参数并执行真实工具，再把工具结果回填给模型，模型基于结果生成最终回答。模型不直接执行函数，执行权在业务侧或供应商托管工具侧。

 5.Function Calling 和 MCP 有什么区别

Function Calling 是模型侧的工具调用意图生成机制，重点是“自然语言如何变成工具名和参数”。MCP 是应用层协议，重点是“工具如何被标准化发现、描述、调用和返回结果”。MCP 可以承载工具生态，Function Calling 可以作为模型选择 MCP 工具时的底层能力之一。

6.MCP Tool 和普通 HTTP API 有什么关系

HTTP API 是业务服务接口，通常面向程序调用；MCP Tool 是暴露给 AI Host 的标准化工具能力，可以在内部再调用 HTTP API、数据库或本地脚本。MCP 解决接入标准化，HTTP API 解决具体业务能力。

7.Agent Skill 和 Function Calling 是一回事吗

不是。Skill 是可复用的任务说明和执行 SOP，核心是上下文注入和流程编排。Function Calling 是底层工具调用机制。一个 Skill 可以指导 Agent 调用多个 Function Calling 工具或 MCP 工具，也可以完全不调用工具。

8.结构化输出失败后怎么处理

先用服务端校验器拿到具体错误，再把错误反馈给模型做有限重试。重试仍失败时进入降级：人工队列、规则引擎兜底、追问用户补信息或返回明确失败。不要让模型在没有事实依据时继续编答案。

9.工具调用为什么必须做安全治理

因为工具调用会操作真实系统。参数合法不代表业务合法，模型生成的 orderId 也不代表当前用户有权访问。必须做参数校验、权限控制、敏感操作二次确认、幂等、审计日志、超时和重试控制。

10.面试里怎么一句话概括结构化输出

结构化输出的本质，是把大模型从“生成给人看的文本”收敛成“生成给程序消费的数据契约”；Function Calling 则是在这个契约之上，把自然语言意图转换成可校验、可执行、可审计的工具调用