本文深入探讨了如何将大模型的非结构化输出转化为工程可靠的契约，核心围绕结构化输出（数据契约）和Function Calling（工具调用意图）两大主题展开。

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

• 本质问题：自然语言指令无法替代工程契约，模型输出具有概率性，容易出现：
  • 格式漂移：输出包含额外解释文本，导致JSON解析失败。
  • 字段缺失：模型可能省略非必填或把握不大的字段。
  • 类型错误：如字符串"false"代替布尔值false。
  • 边界条件崩溃：输入模糊、矛盾时，模型可能放弃指定格式。
• 核心结论：Prompt表达意图，但不能替代Schema、校验器和重试机制。

2. 将JSON从格式变为契约

关键概念分层：

• JSON Mode：约束输出为合法JSON（管语法），不保证字段和业务语义。
• JSON Schema：一种结构描述规范（管契约），定义字段、类型、枚举、必填等。
• Structured Outputs：模型API的结构化生成能力，将Schema传入生成链路，使输出尽量或严格贴合结构（管生成约束）。

对比总结：

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

3. Function Calling：模型生成的是调用意图

• 误解澄清：模型不直接执行函数。它只根据用户问题和工具描述，生成结构化的工具调用意图（工具名+参数）。
• 完整链路：
  1. 服务端注册工具定义（名称、描述、参数Schema）。
  2. 模型根据用户请求选择工具并生成参数。
  3. 业务侧校验参数（类型、权限、业务规则）。
  4. 业务侧执行真实工具（查数据库、调API）。
  5. 工具结果回填模型。
  6. 模型基于事实生成最终回答。
• 价值：完成“自然语言意图 → 结构化参数”的可靠映射。

下面是 Function Calling 的完整调用链路：

4. Function Calling、MCP、HTTP API、Agent Skill分层

关系：Function Calling是“神经信号”，MCP是“接口标准”，HTTP API是“业务能力”，Skill是“执行说明书”。

下面是四层能力的层次关系图：

5. 结构化输出工程化落地要点

• Schema设计：
  • 字段原子化（一个字段只表达一件事）。
  • 优先使用enum 约束分类、状态，避免自由文本。
  • 字段描述写明“何时用、何时不用”，边界清晰。
  • 包含schemaVersion字段支持版本兼容。
• 校验与重试：
  • 服务端必须做结构校验、业务校验（如订单归属）和权限校验。
  • 校验失败时，将具体错误反馈给模型进行有限重试（1-2次），让模型修正结构。
• 降级策略：失败时进入人工队列、使用规则兜底或返回明确错误，禁止模型编造事实。
• 安全治理：
  • 高风险操作（退款、删数据）需二次确认。
  • 写操作必须设计幂等（如使用idempotencyKey）。
  • 记录全链路审计日志（用户输入、模型参数、校验结果、真实执行结果）。

下面是结构化输出的工程化落地流程：

6. 工具调用安全与Java后端示例

• 安全三层校验：结构校验 → 业务校验（归属、状态）→ 权限校验（身份、角色）。
• Java示例要点：
  • 使用JSON Schema Validator进行结构校验。
  • 按工具名分发，未知工具直接拒绝。
  • 权限校验通过后才调用业务服务（如OrderService）。
  • 工具返回结构化结果，供模型生成最终回答。

下面是工具调用的安全三层校验流程：

7. 常见误区与面试核心问题

• 误区：
  • Temperature=0不能完全保证稳定，不能替代Schema。
  • 用了Structured Outputs仍需服务端校验。
  • Schema非越复杂越好，工具非越多越好。
  • Function Calling不能绕过业务权限。
• 面试要点：
  • 结构化输出是将模型输出收敛为程序可消费的数据契约。
  • Function Calling的链路重点是意图生成与业务执行分离。
  • MCP解决工具接入标准化，与Function Calling是不同层次。

总结

• 结构化输出的本质是把自然语言承诺升级为可校验、可版本化、可降级的工程契约。
• Function Calling的核心是意图与执行解耦，模型负责生成调用意图，业务侧负责安全的、确定的执行。
• 生产落地的底线是：服务端校验、权限控制、幂等设计和审计日志一个都不能少。