结构化输出这事，我现在的态度很明确：能在解码层约束，就别指望 prompt 里那句「请返回 JSON」。厂商的 JSON schema 模式比 prompt 写法稳得多，它把格式错误从概率问题变成了工程问题。但这周翻了些东西，加上业务里踩过的坑，想拆开说——约束解码不是万能药，嵌套一深质量会反向崩，最后拼的是结构设计。
prompt 里写「请返回 JSON」，靠的是模型心情
LLM 采样是概率的。prompt 里写清格式要求，对模型只是软约束——上下文一长、中间推理偏一步，花括号就少了，字段名就拼错了。json.loads 直接抛异常，下游啥也干不了。这不是模型笨，是 prompt 这个通道本来就不是为精确格式设计的。
约束解码原理不一样：解码时把所有不符合 grammar 的 token 概率置零，格式层根本不可能出错。这周看到一个 Serve Markdown to AI Agents with Accept Headers 的做法，用 HTTP Accept 头跟 agent 协商返回格式，把格式问题从正文挪到传输层定死——跟 JSON schema 同一思路：结构化是通道的事，不该让模型临场发挥。顺带一提，agent.md 那套给 agent 写说明文件的路子，也是在补软约束的洞，但格式可靠性上它替代不了解码层约束。
但别迷信约束解码，嵌套深了照样翻车
约束解码本质是剪搜索空间。扁平 JSON 没问题，剪完剩的都是合法路径。但 schema 一旦嵌套三层，模型要在受限的解码路径里把深层字段的语义想清楚——我业务里真实发生过：外层结构完美，深层字段开始胡编，该填字符串的填了对象，该是枚举的给出自由文本。json.loads 不报错，下游逻辑拿到脏数据还跑得挺欢。这比格式错误更阴，因为它不显式崩给你看。
所以「拿业务 schema 试一版再决定」不是套话，是真得压一遍。挑线上最复杂的那个嵌套 schema，跑一轮，看深层字段的语义正确率掉到哪。这里推荐 Domain-Driven Agents 的角度：agent 的边界按业务领域画，别按模型的输出能力画。schema 是给业务写的，不是给模型写的；模型在某 schema 上表现差，先改 schema，别怪模型。这跟 Agent Is Not the Model 说的是一回事：运行时和模型解耦，约束解码是运行时的事，别让它替模型扛思考。
拆两次调用，比一次三层嵌套稳得多
这是我现在最认可的做法：三层嵌套拆成两次扁平调用。第一次返回实体 ID 和枚举值，第二次拿着 ID 去填明细。两次各返回一层扁平结构，中间就一个字符串 ID 串着，没有嵌套、没有深层字段——约束解码在扁平结构上的可靠性本来就高。
代价是延迟。两次调用至少多一个网络来回，多少取决于厂商和服务位置。这笔账得自己算：批处理任务闭眼拆；用户直接面对的产品，得测一下 P95。我不确定的部分是：延迟敏感场景能不能用「降到两层嵌套 + prompt 兜底」的混合方案撑住体验。
也许 The Rise and Fall of Agent Civilizations 那个话题能解释我为什么这么想——复杂 agent 项目死掉的原因之一就是过度设计：一层结构能表达的东西，偏要摆进三层 schema。输出结构应该由消费方决定，不是由模型的能力上限决定。
下周我拿新 schema 再压一遍，压完回来改这判断。也许 6 个月后回头看觉得写得保守了——那正好，说明这层工具还在往前走。