SUN 合法 JSON、符合 Schema 和业务语义正确是三个不同层次；结构化输出必须同时处理协议、校验、截断、重试和业务约束。
来源拆分自：高德 Agent 研发面，记忆和评测问很细；以下保留原整理中的工程补充与校正。
如何让大模型稳定输出标准 JSON？
视频归纳的失效原因
- LLM 按 Next Token 概率生成，本身不是严格的语法状态机。
- 对话对齐让模型倾向于先说“好的，下面是结果”，给解析器增加额外文本。
- 长输出可能撞上 Token 上限，造成括号缺失或数组在中途截断。
常见生产事故包括：
- JSON 外包着 Markdown 代码块。
- 长数组在中途截断，结构未闭合。
- Key 漂移，例如
user_id变为userid或“用户ID”。 - 类型边界错误，例如要求
int却返回"18"或null。
四层纵深防御
| 层级 | 手段 | 作用 |
|---|---|---|
| 1. 提示工程约束 | JSON Schema、明确字段说明、Few-shot | 让模型理解目标结构，解决基础格式问题 |
| 2. 原生协议控制 | API 的 JSON Mode、Function Calling 或 Tool Calling | 优先使用模型服务原生结构化接口 |
| 3. 解码约束 | Token Masking、FSM、Outlines 等 | 在生成阶段屏蔽不符合语法或 Schema 的 Token |
| 4. 解析、自愈与重试 | 严格校验、json-repair、Pydantic、携带错误信息重试 |
处理截断、类型错误和边界异常 |
伪代码：
for attempt in range(2):
raw = call_model(schema=OutputModel.model_json_schema())
try:
return OutputModel.model_validate_json(raw)
except ValidationError as error:
if attempt == 0:
add_feedback(error.errors())
else:
raise StructuredOutputError(raw) from error
补充与校正
- 合法 JSON、符合 Schema、业务语义正确是三件事。 约束解码可以提高前两者的确定性，但不能保证字段事实正确，也不能替代业务校验。JSON Schema 2020-12 Core
- 普通 Logit Bias 只适合粗粒度鼓励或抑制 Token，不能独自保证任意 JSON Schema；真正的约束解码需要按当前语法状态动态屏蔽非法 Token。Outlines 的官方架构说明采用的正是这种生成时约束。Outlines 架构
- “自动修复”必须有限次，并保留原始输出和校验错误；无限 repair/retry 会隐藏模型能力问题并放大成本。