告诉模型输出 JSON，就一定能得到正确的 JSON 吗？

PS：关于Agent应用渲染的问题，A2UI 协议就是一个不错的落地的实现。感兴趣阅读完这篇文章和Agent应用的渲染问题后，可以去了解一下。

讨论 Agent应用的渲染问题时，我一开始关心的是：模型怎么知道有哪些组件，又怎么生成组件描述？如果 function calling 能让模型输出函数名和参数，界面描述是否也通过类似的方式生成？

当答案落到"把组件规范和示例告诉模型，让它生成 JSON"时，我又有了一个疑问：

把组件规范告诉模型，模型就一定能吐出符合规范的 JSON 吗？这种可靠性也是模型训练带来的吗？

这里需要拆开两个问题：模型有没有能力按规范生成，以及系统有没有机制限制它偏离规范。

提示词中的"必须"，怎样才能成为程序约束？

设想我们希望显示一个人的姓名，给模型这样的要求：

text 复制代码

使用 Text 组件显示"张三"。
component 必须是 Text，text 必须是字符串。
只输出 JSON，不要解释。

期望大模型输出的结果很简单：

json 复制代码

{"component": "Text", "text": "张三"}

通用模型已有理解指令、组织 JSON 和参考示例的能力，训练为这些行为提供了基础。提示词则补充这次任务的规则；模型不必事先训练过我们的组件库，就可以理解提示词吐出这个 Text。

但如果只是普通文本生成，模型仍然根据上下文预测后续 token。尽管在提示词中约束了text"必须是字符串"，但如果没有后续程序里的类型检查，它仍可能漏掉 text，或者把值写成数字。Claude 的官方文档也明确列出了单靠提示词时可能出现的语法、必填字段和类型错误。结构化输出说明

因此，训练和提示词能提高遵守规范的成功率；要回答"一定符合吗"，还得看模型的能力是否支持，也就是模型对输出JSON Schema是否支持。

同一份规则，放进提示词和交给解码器有什么区别？

我们可以用 JSON Schema 表达刚才的规则。Schema 是描述数据形状的规则，下面要求两个字段都存在，且不接受额外字段：

json 复制代码

{
  "type": "object",
  "properties": {
    "component": {"type": "string", "const": "Text"},
    "text": {"type": "string"}
  },
  "required": ["component", "text"],
  "additionalProperties": false
}

把它作为文字贴进提示词，作用仍是让模型阅读和遵守。把它交给支持严格结构化输出（Structured Outputs）的 API，才可能进入另一条处理路径。

以 Claude 官方描述的机制为例，服务会把 Schema 编译成语法，在采样时限制输出；这种做法称为约束解码（Constrained Decoding） 。可以把它理解为：生成每一步时，根据已经生成的内容，排除无法继续满足语法规则的 token。模型仍负责从允许的选项中选择内容，解码器负责缩小选择范围。机制说明

这样，"会按规则写"和"生成时受到规则限制"就有了明确区别。约束解码发生在推理阶段，不能把它的作用全部归功于训练。

不过，具体保证要按供应商的实现判断：API 支持哪些 Schema 特性、有没有已声明的例外、响应是否完整结束，都影响最终结果。拒绝响应或 token 用尽造成的截断仍需单独处理。看到"支持 function calling"，也应继续核对工具参数是否启用了严格约束。限制与异常说明

我列了一些国内支持程度情况：

模型	是否支持	文档	备注
DeepSeek	✅	api-docs.deepseek.com/zh-cn/guide...
Qwen	✅	platform.qianwenai.com/docs/develo...	Qwen3.7-Plus 系列、Qwen3.7-Flash 系列、Qwen3.7-Max 系列、Qwen3.8-Max 系列、Qwen3.8-Flash 系列
火山引擎	✅	console.volcengine.com/ark/region:...
智谱 GLM	✅	docs.bigmodel.cn/cn/guide/ca...
月之暗面 Kimi	✅	platform.kimi.com/docs/guide/...	K3、K2.7 Code 支持较完善

格式正确以后，还有什么可能错？

即使收到的对象完全符合上面的 Schema，也可能是：

json 复制代码

{"component": "Text", "text": "李四"}

两个字段都存在，类型正确，组件名称也正确。但用户要求的是"张三"。Schema 能限定 text 是字符串，却不能凭这个类型要求判断姓名是否符合用户需求。 如果把已知姓名也写成 const，当然能进一步限制；保证范围随我们实际写入、且 API 支持的规则而变化。

界面生成中的"正确"至少有四种不同含义：

检查	一个失败例子	谁来判断
JSON 语法	引号或括号没闭合	JSON 解析器
Schema	`text` 是数字，或缺少必填字段	Schema 校验器；支持的规则也可用于约束解码
组件关系	`Column.children` 指向不存在的组件 ID	结合界面状态的应用校验
用户需求	用户要"张三"，界面显示"李四"	业务数据核对与任务评估

例如，children 的每一项都是字符串，只说明 ID 的类型符合要求；这个 ID 对应的组件是否已存在，还得查询界面状态。Gemini 的官方文档同样提醒：结构化输出之后，应用仍应校验值，并处理符合 Schema 但语义错误的结果。值校验与语义边界

回到 A2UI：协议把责任放在哪里？

A2UI^1^ 定义了用 JSON 消息描述和更新界面的方式。协议给出了数据应当长什么样，模型是否每次都能生成合格消息，则取决于接入方式和校验流程。

这里的版本差异很有启发性：A2UI v0.8.1 偏向结构化输出，v0.9 转向 Prompt First ，把规范和示例放进提示词。官方解释，这样可以采用更丰富、较少受结构化输出 Schema 子集限制的表达方式。版本演进说明

这项选择也把生成后校验放到了显眼的位置。v0.9 规范明确给出"提示 → 生成 → 校验"的循环：生成结果通过校验后交给客户端；失败时，把具体错误反馈给模型修正。官方生成流程

在这个场景里，我会先把渲染入口收紧：只接受通过结构和应用规则校验的消息。遇到 children 引用了不存在的 ID，就返回具体字段路径和错误原因，限定修正次数；仍然失败时显示预设界面。通过拒收记录，可以验证错误消息有没有进入渲染器；仅凭一次重试成功，不能证明之后每次都会成功。

重新看最初的问题，我现在会追问：这份规范究竟只是模型读到的一段文字，还是已参与生成时的限制？输出之后，又有哪些错误能被程序检查出来？ 回答清楚这两个问题，才能知道系统的可靠性具体来自哪里。

Footnotes

A2UI v0.9 规范定义服务端向客户端发送的界面描述消息，客户端据此构建和更新界面。本文用该版本讨论提示优先与校验机制；官方站点在资料核对日 2026-10-10 已将 v0.9.1 列为当前版本。 ↩