结构化输出兜底：四层架构（工程 / 接口 / 解码 / 训练）（口播版）
面试高频问题：怎么保证 Agent 稳定输出结构化数据（JSON）？在 prompt 里写"请输出 JSON"够吗？ 一句话答案：不够，那只是软约束。生产环境必须有四层兜底：工程流程层（强类型校验 + 修复重试 + 降级）、原生接口层（function calling / structured output）、底层解码层（受限解码，语法级保证）、模型训练层（SFT 让格式成本能）。越往内越强也越贵；工程层是必选项而不是可选项——因为 schema 合法 ≠ 业务合法。 适用面次：二面深度 / 三面综合 本版定位：口语应答脚本 —— 这题区分度极高：只会 prompt 的是入门，答出四层纵深 + 两层校验 + 降级链的才是工程级。
【30 秒极简版】（面试官随口一问时用）
prompt 里写"请输出 JSON"是软约束，长任务和高并发下必然有失败率，所以必须有工程兜底。 我做四层纵深，从外到内：工程流程层——JSON Schema 强类型校验，失败把错误信息回喂给模型修复，再不行多次采样投票，最后降级人工；原生接口层——用 function calling 或 structured output，让厂商在模型侧保证 schema 合法；底层解码层——自部署时用受限解码，按 JSON 文法屏蔽非法 token，语法层面接近百分之百合法；模型训练层——量大的自研格式做 SFT，让格式成本能。 选哪层看条件：能调原生接口就先调（性价比最高），自部署且格式严就加受限解码，自研格式量大才上训练层。但无论用了哪一层，工程校验层都不能省——因为schema 合法不等于业务合法，字段值域、跨字段一致性这些还得自己验。
【2 分钟完整口播】（正式被问到时的主干回答）
先说为什么 prompt 不够。在提示词里写"请严格输出 JSON"，本质上是软约束——它依赖模型自觉，短输出、简单 schema 时成功率还行，但 schema 一复杂、字段一多、嵌套一深，或者上下文一长，失败率就上来了。生产环境要的是可预期的成功率，不能靠模型心情。
我的方案是四层纵深，从外往内，越往内越强，也越贵、越绑定。
第一层，工程流程层，这是最常用、也最该先做的一层。做法是：定义 JSON Schema，拿到输出先做强类型校验；不过就把校验错误回喂给模型让它修（repair loop，通常一两次就修好了）；还不行就多次采样投票或者取最稳的一次；最后兜底——用模板填空或者降级人工。这一层的优点是零模型改造、可插拔、任何模型都能用；代价是有重试成本，极端情况仍可能失败。
第二层，原生接口层，就是各家提供的 function calling、tool use、structured output——比如指定 response_format 为 json_schema。厂商在模型侧用约束解码帮你保证 schema 合法。优点是稳定且便宜，基本不用自己做修复循环；缺点是绑厂商，而且复杂嵌套 schema、特殊类型（比如联合类型、递归结构）各家支持程度不一，得实测。
第三层，底层解码层，也就是受限解码。原理是在采样的时候，按 JSON 文法或你给的语法，把会导致非法的 token 直接屏蔽掉，让模型根本没机会输出非法字符。像 Outlines、Guidance、XGrammar 这类库做的就是这个。优点是语法层面几乎百分之百合法，这是最强的保证；缺点是需要自部署、能控制推理引擎——你调 API 是用不了的。另外要注意，约束过严可能损害语义质量，模型为了合规可能写出奇怪的内容，所以要留适度宽松度。
第四层，模型训练层，就是 SFT——用大量符合目标 schema 的样本微调，让这个格式变成模型的"本能"。优点是对复杂自定义格式最稳，而且零额外 token 开销（不用在 prompt 里写一大段 schema 说明）；缺点是训练成本高，而且格式一改就要重训，迭代不灵活。
怎么选？我的顺序是：能调原生接口先调（性价比最高）；自部署且格式严格就叠上受限解码；自研格式、调用量极大才考虑训练层；而工程校验层不管用哪层都要有——这点很关键，因为 schema 合法不等于业务合法。举个例子：JSON 语法没问题，但金额是负数、日期格式对但时间在未来、状态枚举值合法但和另一个字段自相矛盾——这些只有业务校验能发现。
所以完整的校验是两层纵深：先语法层（schema 合法），再语义层（字段值域、枚举、跨字段一致性、业务规则）。失败的话走降级链：重试修复 → 换模型 → 缩小 schema（拆成多次小输出，别让它一次吐一个巨大 JSON）→ 上报人工，而且上报算合规交付，不逼系统硬凑一个错的。
一句话收尾：prompt 决定它想不想守规矩，工程层决定它能不能不守规矩——生产环境要的是后者。
一、先立判断：软约束 vs 硬约束
开口说：
提示词是软约束，依赖模型自觉；四层架构是硬约束，不过就走不下去。
| 软约束（prompt） | 硬约束（四层架构） | |
|---|---|---|
| 靠什么 | 模型自觉 | 校验 / 接口 / 解码 / 训练 |
| 失败率 | 随 schema 复杂度、上下文长度上升 | 可预期、可收敛 |
| 适用 | demo、低频内部工具 | 生产环境 |
得分句："软约束决定它想不想守规矩，硬约束决定它能不能不守规矩。"
二、四层架构（核心，必背）
速记：外挂校验 → 原生接口 → 受限解码 → 训练本能（越往内越强越贵）
| 层 | 手段 | 优点 | 代价 / 限制 |
|---|---|---|---|
| ① 工程流程层 | JSON Schema 强类型校验 + 修复重试 + 多次采样投票 + 降级模板/人工 | 零改造、可插拔、任何模型通用 | 有重试成本；极端情况仍可能失败 |
| ② 原生接口层 | function calling / tool use / structured output（response_format=json_schema） | 稳定、便宜 | 绑厂商；复杂嵌套/联合类型支持不一，需实测 |
| ③ 底层解码层 | 受限解码（按语法屏蔽非法 token，Outlines / Guidance / XGrammar） | 语法层面近乎 100% 合法，最强 | 需自部署、能控推理引擎（API 模式用不了）；约束过严可能伤语义 |
| ④ 模型训练层 | SFT 让格式成本能 | 复杂自定义格式最稳、零 prompt 开销 | 训练成本高；改 schema 要重训，不灵活 |
选型顺序（加分）
能用原生接口先用（性价比最高）→ 自部署且格式严 → 叠受限解码 → 自研格式、量极大 → 上训练层 ⚠️ 但工程校验层永远不能省。
三、两层校验纵深（最容易漏的得分点）
开口说：
schema 合法 ≠ 业务合法，所以校验必须做两层。
| 层 | 验什么 | 例子 |
|---|---|---|
| 语法层 | schema 合法（类型、必填、结构） | 字段缺失、类型错误、JSON 解析失败 |
| 语义层 | 业务合法（值域、枚举、跨字段一致性、业务规则） | 金额为负、日期在未来、状态与另一字段自相矛盾 |
只有语法层校验就上线，是这题最常见的露馅点。
四、失败降级链
速记：修复 → 换模型 → 拆小 → 上报
强类型校验失败
→ ① 回喂错误信息让模型自修（repair loop，1~2 次）
→ ② 多次采样投票 / 换模型重试
→ ③ 缩小 schema：拆成多次小输出（别一次吐一个巨大 JSON）
→ ④ 上报人工（上报算合规交付，不硬凑一个错的）呼应 20 号：上报算合规交付——不给系统"硬凑"的动机。
五、避坑提醒
- ❌ "我在 prompt 里写了请输出 JSON" → ✅ 那是软约束，必须补四层硬兜底
- ❌ 只做 schema 校验 → ✅ 补语义层业务校验（值域 / 枚举 / 跨字段一致性）
- ❌ 说"用受限解码就 100% 没问题" → ✅ 只保证语法合法，内容质量仍要校验；且约束过严可能伤语义
- ❌ 不分场景就上 SFT → ✅ 先算账：训练成本 vs 调用量 × 失败率 × 重试成本
- ❌ 编成功率数字 → ✅ 说"以线上 trace 实测为准，具体值暂未带"
六、面试官在考什么
| 维度 | 你的证据 |
|---|---|
| 工程纵深 | 四层架构从外到内，能说清每层适用条件与代价（不是只报名字） |
| 认知深度 | 主动指出 schema 合法 ≠ 业务合法，补语义层校验 |
| 成本意识 | 选型有顺序（性价比优先），不是一律上最重的方案 |
| 可靠性 | 有完整降级链，且知道"上报算合规"而不是硬凑 |
| 部署经验 | 知道受限解码只在自部署可用，API 模式用不了（这条能区分真做过和背过） |
七、追问预案（Q&A 演练）
Q1：修复重试会不会让成本翻倍？
会，但要比另一种成本：一次失败的线上事故成本远高于一两次重试。控制手段是——限制重试次数（通常 2 次）、只回喂关键错误信息（别把整个输出原样回喂）、对高频失败 schema 做拆分或上更强的层。
Q2：受限解码和 structured output 是什么关系？
structured output 是厂商帮你实现的受限解码。厂商在服务端按你的 schema 做约束采样，所以你调 API 也能享受；而自己用 Outlines/XGrammar 是在自部署时自己控。前者方便，后者可控性更强（自定义语法、非 JSON 格式也行）。
Q3：复杂嵌套 schema 总是失败怎么办？
不要硬扛，拆：一是横向拆——拆成多次调用，每次只吐一层；二是纵向拆——把深层结构拍平成扁平字段 + 引用 ID。经验上，输出越扁平成功率越高，复杂嵌套是失败率的主要来源。
Q4：怎么量化结构化输出的健康度？
上监控：首次通过率、修复后通过率、平均重试次数、降级率、各 schema 的失败分布。按 schema 分别看——通常失败集中在少数几个复杂 schema 上，针对它们优化收益最大（呼应 24 号 工具调用维度）。
Q5：模型训练层值得吗？
算账：训练成本 vs 调用量 × 失败率 × 重试成本。只有调用量极大、格式稳定、且前三层都不够时才值得。格式常变的业务千万别上——改一次 schema 重训一次，迭代会被拖死。
全篇串联（考前 10 秒扫这个）
先立判断：prompt 是软约束，生产要硬约束
→ 四层纵深：工程校验（必选）· 原生接口（首选）· 受限解码（自部署最强）· SFT（量大最稳）
→ 两层校验：语法（schema 合法）→ 语义（值域/枚举/跨字段）
→ 降级链：修复 → 换模型 → 拆小 → 上报（上报算合规）
→ 收尾：schema 合法 ≠ 业务合法关联笔记：25Agent协作机制-服务发现能力对齐状态交接三层（Agent 间交接包靠 schema 化契约对齐，本篇是其格式保障）、20Agent长任务不跑偏也不摆烂-目标铰链与反敷衍机制（"上报算合规交付"立场同源）、24Agent性能量化评估-五维指标体系（结构化输出的首次通过率/重试次数属于工具调用维度指标）、10Agent长任务失控治理-任务管控三层体系与执行闭环（失败降级与工具治理同源）