结构化输出：约束解码保证语法，保证不了语义

1. 约束解码和「在提示词里要求返回 JSON」有什么本质区别？
2. 有了结构化输出，还需要写校验吗？为什么？
3. schema 能表达什么、不能表达什么？表达不了的那部分该放哪儿？

一个订单改期与退款的 Agent，模型返回 JSON 驱动下游 API。它的事故史刚好分成三个阶段，正好是这一篇的主线。

第一阶段：模型偶尔在 JSON 前面加一句「好的，这是你要的结果：」，json.loads 直接抛异常。团队上了约束解码，这类问题清零。所有人都松了口气。

第二阶段：两周后出现更棘手的——JSON 完全合法、字段齐全、类型正确，但 new_date 是 "2026-02-30"。语法无懈可击，日期不存在。

第三阶段：refund_amount: 99999。schema 里没写上限，模型「合理地」填了一个数，下游照单执行，钱打出去了。

第一类问题约束解码解决了；后两类，它在结构上不可能解决。搞不清这条边界的团队，会在上了结构化输出之后放松警惕，然后在更贵的地方摔一跤。

Structured outputs（结构化输出）。让模型的输出严格符合你给定的 JSON Schema。

Constrained decoding（约束解码）。它的实现机制：把你的 schema 编译成一份语法，在采样阶段就把所有会违反结构的候选 token 屏蔽掉。

比喻：不是叮嘱司机「尽量别开出这条路」，而是把所有岔路口都用护栏封死。模型不是「更听话了」，是物理上吐不出违反结构的 token。

两个不同的东西，别混：

JSON mode（旧的、弱的那一档）。只保证输出是合法 JSON，不保证符合你的 schema——字段可以缺、类型可以错。看到有人把这两个混为一谈时要能分辨。

# 约束解码在做什么（示意）
for step in range(max_tokens):
    logits = model.next_token_logits(state)
    allowed = grammar.allowed_tokens(parse_state)   # 语法告诉你此刻哪些 token 合法
    logits[~allowed] = -inf                          # 其余全部封死
    tok = sample(logits)
    parse_state = grammar.advance(parse_state, tok)

关键限制（这是本篇最值钱的一段）

既然 schema 要被编译成语法，那语法表达不了的约束，就一定管不住。截至 2026-08，官方文档明确列出的不支持项包括：递归 schema、外部 $ref、minimum / maximum、minLength / maxLength、其他数组长度约束；additionalProperties 只能是 false。此外还有整体复杂度上限——所有严格 schema 合起来算，超了会直接报编译错误，官方给的修法顺序是：只给关键工具加 strict → 把可选参数改成必填 → 拍平嵌套 → 拆到多个请求。（每个可选参数都会显著放大语法的状态空间，是复杂度大户。）编译产物会缓存 24 小时，所以首次调用有额外延迟，高频调用可以忽略。

把这些串起来就是本篇的结论：

数值范围、字符串长度、日期是否真实存在、金额是否在权限内、引用是否与来源一致——这些全部属于语义，语法层根本表达不了。它们必须活在你的代码里。

回头看开头的故障："2026-02-30" 是合法字符串；99999 是合法整数。约束解码从来没打算管这两件事，是团队误以为它管。

表 1：四条路线选型

表 2：三层校验（可复用骨架）

一句话：能用 schema 表达的交给 schema，不能表达的必须写代码，绝不写进提示词指望模型自觉。

这条和 Agent 章的判断顺序是同一个逻辑：能代码判的用代码判 → 能变可逆的变可逆 → 剩下的才人工确认（Q3-19）。退款金额是否合理，属于第一类，根本轮不到模型来判断。

避坑清单

1. 别把 schema 当校验器。 它是格式契约，不是业务规则引擎。
2. 可选字段要克制。 每个可选参数都在放大语法状态空间；能必填就必填，用一个显式的「未知」枚举值代替「字段缺失」。
3. 枚举优先于自由文本。 这是唯一一类「语法层能顺便管住语义」的字段——能枚举就绝不让模型自由发挥。
4. 别设计一个模型填不满的 schema。 强行要求一堆它无从得知的必填字段，会诱导它编造，因为语法不允许它空着。
5. 结构化输出不降低幻觉率，只是把幻觉变成格式合法的幻觉。副作用是：parse 不再报错，你反而失去了一道天然告警，第 2、3 层校验因此更重要，不是更不重要。
6. 注意档位交互：过高的 effort 在结构化输出这类任务上可能过度思考，收益递减（T0-5）。

面试官怎么问。 Q1-10 在工程向一二面几乎必问，平台组尤其爱问。它的第一层很浅（怎么让它返回 JSON），第二层就见功力：「有了这个还要不要校验」。

答题结构建议

1. 先讲机制差异（请求 vs 封路），把「约束解码」这个词说准；
2. 明确它保证的是语法；
3. 主动给出表达不了的清单（数值范围、长度、日期真实性）；
4. 给出三层校验骨架，并把高危字段的判断权收回代码。

分水岭信号

• 只读过：以为「开了结构化输出就不用校验了」；分不清 JSON mode 和 schema 约束；还在推荐预填 { 这个技巧；用 maximum 写在 schema 里就以为管住了金额。
• 真做过：知道 schema 只支持子集，说得出至少两条不支持项；能主动指出「结构化输出让幻觉变得格式合法，反而更难发现」；schema 复杂到编译报错时知道该先改可选参数而不是先拆模型；把高危动作的判断彻底移出模型输出链路。

一句话收口：约束解码把「模型愿不愿意听话」变成了「模型能不能违规」，但它管的只有形状；值对不对、能不能做，永远是你代码的责任。

• 关联题目：Q1-10
• 延伸：T1-1（few-shot 与格式约束的分工）、T3-2（工具 schema 设计）、Q3-19（分级自治与高危操作）、Q2-24（引用溯源）