大模型结构化输出怎么验收？JSON Schema、重试与脏数据处理

大模型结构化输出可以显著减少缺字段、错类型和无效枚举，但不能证明字段事实正确，也不能替代权限、业务规则和下游幂等。可靠链路至少包含五道门：受约束生成、严格解析、JSON Schema 校验、语义与来源核验、带幂等键的提交和权威读回。失败后先分类，再决定有限重试、隔离、人工处理或直接阻断；不要静默强转类型、补默认值或让同一错误无限消耗 Token。团队真正要验收的不是“模型能否吐出 JSON”，而是错误能否在副作用发生前被发现、解释、留证并安全恢复，且结论可以复核。

先分清 JSON mode、结构化输出和函数调用

大模型返回一段看起来像 JSON 的文字，并不等于系统已经得到可用的数据合同。提示词里写“只返回 JSON”，主要依赖模型服从；JSON mode 关注语法能否解析；结构化输出用提供商支持的 Schema 子集约束形状；函数调用则用于模型提出工具名称和参数，由应用决定是否执行。选型时先问下游要什么：如果只是把最终答案渲染到界面，可用结构化文本；如果要查询数据库、发送消息或修改对象，应把模型输出当成候选参数，通过权限、业务规则和人工批准后再调用工具。无论哪种模式，JSON Schema 都不能证明字段内容真实，也不能替代服务端授权。

实施方法

OpenAI 当前 Structured Outputs 文档要求严格模式下对象设置 additionalProperties:false，并说明字段需要列入 required；需要表达可选值时通常把类型与 null 组成联合。文档也列出嵌套、属性数量、枚举总量和部分关键字支持限制。Google Gemini 文档同样明确其结构化输出只支持 JSON Schema 的子集，并把“格式化最终响应”与“调用函数执行动作”区分开。工程上不能拿完整 Draft 2020-12 Schema 直接假设所有厂商都接受，也不能因一个 SDK 帮助器能生成类型就认为远端端点、具体模型和当前版本都支持同一关键字。

验收边界

最稳妥的做法是维护一份应用侧规范 Schema，再为每个提供商生成兼容投影，并在 CI 中对投影做能力测试。规范 Schema 写业务需要；提供商 Schema 只写该端点支持的约束；应用验证器仍使用确定版本的完整规则。这样既避免把厂商限制扩散到数据模型，也避免提示、类型定义、远端 Schema 和数据库字段各自演化。每次修改字段、枚举、说明、模型或 SDK，都让同一组正反样本同时跑过 Schema 自检、提供商请求和应用验证。

怎样设计既严格又能表达缺失的 Schema

Schema 应从下游决策反推，而不是从模型容易生成什么反推。先列出每个字段由谁提供、为空时是什么意思、谁会消费、错误会造成什么后果。标识符保持字符串，避免前导零或超出语言整数精度；金额用最小货币单位整数或十进制定点字符串，并另带币种；时间使用带时区的 RFC 3339 字符串并在应用层解析；分类用有限枚举且保留明确的 unknown 或需要人工选项；自由文本限制用途，不把一段说明同时承担 ID、状态和理由。对象默认拒绝额外字段，数组设置业务上合理的上限，并为每个对象指定 required。

实施方法

缺失、未知、空字符串、零和不适用是五种不同状态。若字段确实可缺，不要通过从 required 中删除来制造含糊，而要明确选择 null、状态枚举或带 reason 的联合对象。比如证据日期未知时，date:null 与 date_status:"not_in_source" 比空字符串更可审计；价格为零可能是免费，不能当缺失；列表为空可能表示已检查但没有结果，也可能表示模型根本没处理。Schema 描述应写出来源、单位和允许的缺失原因，但描述只是给模型的指导通道，不能取代代码验证。

验收边界

复杂关系通常超出提供商支持的 Schema 子集，例如结束时间必须晚于开始时间、currency 与 amount 必须同时出现、某状态下另一个字段必须为空、ID 必须存在于当前租户。不要为了塞进 Schema 构造过深的 oneOf 或条件组合；把表面结构留给结构化输出，把跨字段规则、数据库存在性和权限放到应用验证层。需要多个候选时，要求每项带来源片段或 source_id，再用原文和权威系统核对；不要让模型自己给 confidence 小数并把它误当校准概率。

解析、结构、语义与策略要分四层验收

第一层是传输和解析：HTTP 是否成功，响应是否完整，字符编码是否正确，JSON 是否只有一个根值，是否出现截断、拒绝或工具调用分支。第二层是结构：类型、必填、枚举、数组长度、额外字段和提供商限制是否满足。第三层是语义：日期能否真实存在，金额与币种是否一致，标识符是否属于当前数据集，摘要是否被来源支持，多个字段之间是否符合业务不变量。第四层是策略：调用者是否有权处理这类数据，字段是否含敏感信息，动作是否需要批准，结果是否允许进入生产。四层错误使用不同代码和负责人，才能知道该改提示、Schema、源数据、授权还是流程。

实施方法

应用接收模型结果时，先保存脱敏的原始响应或哈希，再解析到普通数据结构，随后执行固定版本验证器。不要在验证前自动把字符串转数字、把未知枚举映射到最接近项、丢弃额外字段或静默补默认值，因为这些“修复”会掩盖真实失败。允许的确定性规范化应单独列白名单，例如去除明确允许的外围空格、把 Unicode 正规化为约定形式、按已知格式把日期转换为内部表示；每次转换记录前后值与规则版本。无法无歧义修复时隔离原记录。

验收边界

语义验证要靠权威数据与来源关系。做信息抽取时保存字段对应的原文跨度、文档 ID、版本和页码；做分类时验证输入是否属于定义的任务域；做业务对象时查询租户、状态、唯一性和引用完整性；做安全决策时验证责任主体和批准。即使模型在 strict 模式下总能返回 Schema，有可能在不相关输入中编造一个看似合理的对象。提示应允许明确表达无法完成，应用则把无证据、来源冲突和任务外输入作为正常失败类别，不要强迫每次都产出业务值。

重试、修复与降级怎样避免扩大错误

是否重试取决于错误有没有可能通过再次生成解决。网络抖动、临时限流、截断和偶发结构近失配可以有限重试；不支持的 Schema 关键字、请求超出限制、权限拒绝、来源缺失和业务冲突不会因为重复调用自动变好。每次重试都带相同任务 ID、Schema 版本和样本版本，反馈最小且具体的错误路径，例如 $.items[2].amount 应为整数，而不是把整个内部堆栈、秘密或数据库结构回传给模型。重试设置次数、总时长和费用上限，并使用退避和抖动；相同错误连续出现时立即熔断。

实施方法

自动修复只适合可以确定无歧义的语法包装。若旧接口偶尔返回 Markdown 围栏，可以在兼容层识别并剥离，但要把该事件计入质量指标；若字段类型、枚举、金额或身份不对，不应靠正则猜测。让第二次模型调用“修复”也属于新的生成，必须重新走全部四层验证，并保留原始失败、修复提示、修复结果和费用。对于含个人信息或商业秘密的数据，错误反馈只发送必要字段与脱敏片段，不能为了修复把整份文档再次扩散。

验收边界

降级路线要事先定义：结构化输出不可用时，是切换同一厂商的兼容模型、改走函数调用、进入只读人工队列，还是直接失败。切换模型会改变质量、延迟、价格、地区与数据处理边界，不能视为透明重试；改变 Schema 或放宽 required 更不能在运行时悄悄发生。面向写库、发布、支付和权限操作的结果，宁可返回 blocked，也不要用一个更宽松的解析器把不确定数据送入下游。对纯展示场景可以降级为自然语言，但界面必须标明没有形成可执行结构。

脏数据怎样隔离、回放和清理

脏数据队列不是失败垃圾桶，而是可恢复边界。记录任务 ID、输入来源哈希、模型与快照、提示和 Schema 版本、提供商请求 ID、原始响应哈希、错误层级、JSON Path、重试次数、费用、租户、敏感级别和下一动作；原文或完整响应按最小必要原则加密保存，并设置访问、保留和删除策略。队列项使用不可变事件记录状态变化：new、triaged、retriable、needs_source、needs_human、resolved 或 discarded。不要覆盖第一次失败，否则无法判断后来是模型改善、Schema 放宽还是人工改值。

实施方法

人工处理界面应并排显示来源片段、候选字段、验证错误和建议动作，但不默认接受模型值。操作员可以选择修正、请求新来源、标记不适用或丢弃，并为关键字段填写理由。人工修正形成新的派生记录，包含操作者、时间、变更字段和来源；原始模型输出保持只读。多人批量处理时按租户和敏感级别隔离，禁止搜索或导出其他客户数据。修复完成后重新运行同一版本或批准的新版本验证器，而不是仅把状态手工改成成功。

验收边界

回放用于验证修复是否普遍有效。选择脱敏且有代表性的失败集，固定输入和期望业务不变量，在候选模型、提示、Schema 或代码上离线运行；比较解析通过率、结构通过率、语义正确率、人工返工、延迟和费用。不能只看 Schema 通过率，因为一个始终返回默认值的系统可能结构完美但业务完全错误。回放通过后先灰度低风险流量，监控错误类别迁移，再逐步放量。达到保留期后删除原文、响应和派生缓存，同时保留不含敏感内容的统计与删除回执。

写库、调用工具和发布前怎样控制副作用

模型输出永远不能直接拼接 SQL、命令、URL 或模板执行。应用把已验证字段映射到参数化接口，服务端重新检查主体、租户、对象状态、字段白名单和业务不变量。对于工具调用，模型选择工具和参数只是建议；调度层确认工具是否在任务合同内，调用者是否有权限，数据是否允许流向该工具，参数是否需要人工批准。读取操作也可能泄露信息，因此不要只给写操作设权限。每次调用带任务 ID、策略版本和最小范围凭据，结果返回后再次验证。

实施方法

产生副作用的请求使用幂等键，键应绑定业务操作而不是某一次网络连接。超时或断线后先用幂等键、对象 ID 或业务查询读回结果，确认旧请求是否已经成功；未知状态不能直接重放。数据库写入保存输入版本、Schema 版本、验证回执和创建者，并用乐观锁防止基于旧对象覆盖新状态。批量任务设置数量、金额、文件和时间上限，超出批准范围的单项转人工，不让一条自然语言授权覆盖未来未知动作。

验收边界

发布、发送、付款、删除、修改权限或对外承诺属于高影响动作。最终确认界面展示真实目标、字段、金额、收件人、文件哈希、公开范围和不可逆影响，确认令牌绑定这些参数并短时有效。模型在确认后若改动任一字段，旧令牌失效。动作完成后通过权威系统读回业务对象，而不是只相信模型文字、页面绿色提示或 HTTP 202。读回不一致时进入 unknown，暂停自动化并由人工决定补偿、撤销或继续。

四十八项测试怎样证明这条链路可上线

验收固定提供商端点、模型快照、SDK、提示、Schema、应用验证器、业务规则、测试数据、账户权限和网络条件。每个用例记录输入哈希、预期、实际、错误层、重试、费用、人工动作、下游状态和清理结果。passed 必须有解析、结构、语义、策略和业务读回中适用层的证据；failed 表示行为与预期不符；blocked 表示缺少账号、权限、来源或可逆环境；not-applicable 要写理由。不能把模型自述“格式正确”作为通过，也不能用所有请求都被阻断来制造虚假安全。

实施方法

样本集至少分为正常、边界、恶意、历史失败和真实分布抽样五组。正常样本证明系统在合同内能完成任务；边界样本覆盖空值、极值、长文本、深层数组、Unicode、时区和精度；恶意样本尝试注入额外字段、跨租户标识、命令片段、敏感信息和合同外工具；历史失败从脏数据队列脱敏抽取，防止修复只针对演示；真实分布抽样按来源、语言、文档类型和业务状态分层。每组分别统计解析通过、结构通过、语义正确、策略阻断、人工返工、未知结果、延迟和费用，不把这些维度压成一个看不出原因的总分。对高影响字段设置逐字段准确性和零容忍规则，例如租户、收件人、金额、币种、权限和公开状态不能因总体平均值好看而放宽。

验收边界

版本迁移要同时运行旧链路和候选链路，比较同一输入在字段值、拒绝、错误类别和下游动作上的差异。候选版本先影子运行，只生成与验证而不产生副作用；通过后进入低风险小流量灰度，并设置自动停机阈值。若 Schema 新增 required 字段，先确认所有生产者和消费者都已升级；若删除或重命名字段，准备双读、双写或明确转换窗口；若切换模型或提供商，重新核对支持关键字、地区、数据处理、拒绝表示、工具事件和费用。上线批准应列出可接受错误、阻断错误、回滚版本、恢复步骤和负责人。回滚后继续保存候选版本回执，避免下一次迁移重复踩同一问题；只有受影响测试全部有新证据，才能关闭变更记录。持续运营时按错误层建立趋势：解析错误突然增加可能是端点或流式处理变化，结构错误增加可能是提示、模型或 Schema 投影漂移，语义错误增加可能来自输入分布或来源质量，策略拒绝增加可能是权限或任务范围变化，未知结果增加则常指向下游幂等和读回薄弱。报警要带基线、样本量和版本切点，不把一次偶发失败包装成比例趋势。周度抽样复核通过记录，确认系统没有靠默认值、丢字段或人工提前修正获得虚高通过率；月度回放历史失败，验证已修问题没有复发。对每个指标写清能证明什么和不能证明什么：Schema 通过只能证明结构，来源映射只能证明可追溯，业务读回只能证明对象当时状态，人工批准只能证明特定参数得到同意，都不能单独推出整体正确、安全或合规。验收结束还要执行数据清理：撤销临时账号和令牌，删除测试对象与上传文件，清空隔离队列中的真实敏感内容，确认缓存、日志、截图和导出副本遵守保留范围。若某项清理无法验证，测试状态保持 blocked，即使核心请求曾成功。最终评审由内容负责人、应用开发、数据所有者和安全或合规责任人分别签署自己能够证明的部分，禁止由模型供应商的格式保证替代业务责任，也禁止把一次测试环境通过直接外推到所有地区、租户、输入和未来模型版本。评审回执还应写明未覆盖的输入类型、尚未获得的账号、没有运行的高风险动作和未能验证的地域条件，让读者能够区分已验证、未验证与不适用。任何新增数据源、消费者、自动修复规则或工具权限都视为合同变化，先进入影子测试而不是继承旧结论。

Schema 与解析

1. SCH-01｜最小有效对象：测试条件为提供完整且合法的标准样本。预期是一次通过并保留模型、Schema 与验证器版本。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
2. SCH-02｜缺少必填字段：测试条件为移除业务必需的 record_id。预期是结构层在明确 JSON Path 拒绝。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
3. SCH-03｜额外字段：测试条件为加入 Schema 未声明的 admin_note。预期是additionalProperties 门禁拒绝而非静默丢弃。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
4. SCH-04｜错误类型：测试条件为把整数金额改成字符串。预期是不自动强转；错误进入结构类别。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
5. SCH-05｜空值语义：测试条件为分别输入 null、空串、零和缺失。预期是四种状态按合同得到不同结论。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
6. SCH-06｜未知枚举：测试条件为返回不在清单内的状态。预期是拒绝并记录原值，不映射为最接近项。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
7. SCH-07｜数组上限：测试条件为生成超过批准数量的记录。预期是在进入下游前拒绝或转人工。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
8. SCH-08｜嵌套深度：测试条件为使用超过提供商支持深度的 Schema。预期是请求阶段失败并指向兼容性问题。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
9. SCH-09｜关键字子集：测试条件为加入当前端点不支持的条件关键字。预期是能力测试发现而非生产时放宽。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
10. SCH-10｜Schema 自检：测试条件为提交自身无效或引用错误的 Schema。预期是CI 和运行入口双重拒绝。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
11. PAR-01｜非 JSON 文本：测试条件为模型返回解释段落。预期是解析层失败且原始响应被安全留证。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
12. PAR-02｜Markdown 围栏：测试条件为JSON 被代码围栏包裹。预期是兼容修复被单独计数并重新完整验证。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
13. PAR-03｜截断对象：测试条件为在数组中途模拟输出截断。预期是不补括号猜值；按截断类别有限重试。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
14. PAR-04｜多个根值：测试条件为响应连续出现两个 JSON 对象。预期是严格解析器拒绝歧义结果。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
15. PAR-05｜编码异常：测试条件为插入非法字节或替换字符。预期是拒绝进入数据库并保存编码错误。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
16. PAR-06｜显式拒绝：测试条件为触发模型安全拒绝分支。预期是识别为 refusal 而非缺字段重试。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
17. PAR-07｜工具与文本混合：测试条件为同一响应同时出现工具候选和正文。预期是按 API 事件类型分流，不拼接成 JSON。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
18. PAR-08｜流式半成品：测试条件为连接在属性值中断开。预期是未完成事件不交给下游。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。

语义与来源

1. SEM-01｜不存在日期：测试条件为输入 2026-02-30。预期是应用日期解析拒绝，Schema format 不被当作唯一证据。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
2. SEM-02｜时间顺序：测试条件为结束时间早于开始时间。预期是跨字段业务规则拒绝。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
3. SEM-03｜金额与币种：测试条件为金额存在但币种为空。预期是联合业务规则拒绝而非填默认币种。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
4. SEM-04｜对象归属：测试条件为引用另一个租户的合法 ID。预期是权限和租户层统一拒绝且不泄露对象。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
5. SEM-05｜来源缺失：测试条件为模型生成来源中没有的事实。预期是证据映射失败并进入 needs_source。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
6. SEM-06｜来源冲突：测试条件为两个权威来源给出不同版本。预期是不自动选新值；保留冲突和核验日期。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
7. SEM-07｜任务外输入：测试条件为输入与抽取任务完全无关。预期是返回明确不可处理状态，不编造完整对象。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
8. SEM-08｜重复实体：测试条件为同一对象以别名出现两次。预期是确定性去重或人工合并，保留来源。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
9. SEM-09｜精度边界：测试条件为超大整数和高精度小数。预期是避免语言精度丢失并按合同存储。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
10. SEM-10｜Unicode 变体：测试条件为名称含全角、组合字符与相似字符。预期是规范化规则可追溯且不误合并身份。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。

重试与降级

1. RET-01｜一次结构重试：测试条件为制造可修复的缺字段错误。预期是反馈精确路径并在上限内成功或失败。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
2. RET-02｜重复同错熔断：测试条件为连续返回相同枚举错误。预期是停止重试并进入人工队列。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
3. RET-03｜限流退避：测试条件为端点返回 429 和重试提示。预期是遵守退避、抖动和总时长预算。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
4. RET-04｜不支持 Schema：测试条件为端点返回 Schema 关键字错误。预期是不重复同请求，转兼容性处理。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
5. RET-05｜权限拒绝：测试条件为工具服务返回 403。预期是不通过更换提示或模型绕过。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
6. RET-06｜费用上限：测试条件为多次修复即将超过任务预算。预期是在阈值前 blocked 并展示已用成本。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
7. RET-07｜模型降级：测试条件为主模型不可用。预期是切换前重新核对能力、数据和质量边界。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
8. RET-08｜重试脱敏：测试条件为错误字段包含个人信息。预期是反馈只含必要路径和脱敏片段。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。

副作用与运营

1. ACT-01｜参数化写入：测试条件为字段包含 SQL 和命令片段。预期是仅作为数据参数保存，不执行。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
2. ACT-02｜工具白名单：测试条件为模型提出合同外工具。预期是策略层在调用前拒绝。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
3. ACT-03｜字段权限：测试条件为普通角色尝试写管理员字段。预期是服务端授权拒绝。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
4. ACT-04｜幂等重放：测试条件为提交成功后客户端超时并重试。预期是同一业务键只产生一个对象。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
5. ACT-05｜未知结果：测试条件为下游超时且无法立即确认。预期是先读回；状态 unknown 时不自动重放。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
6. ACT-06｜确认后变更：测试条件为批准后金额或收件人改变。预期是旧确认令牌失效。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
7. ACT-07｜乐观锁：测试条件为验证后对象被其他用户更新。预期是写入因版本不符停止。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
8. ACT-08｜批量越界：测试条件为模型返回超过批准上限的动作。预期是超出部分不执行并转人工。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
9. OPS-01｜原始证据：测试条件为查询一次失败记录。预期是能关联输入、响应、规则、错误和处理结果。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
10. OPS-02｜人工修正：测试条件为操作员修改候选字段。预期是产生新派生记录并保留理由与来源。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
11. OPS-03｜跨租户隔离：测试条件为用户猜测其他租户任务 ID。预期是统一拒绝且不透露记录是否存在。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。
12. OPS-04｜保留到期：测试条件为记录超过定义保留期。预期是原文与派生缓存删除并形成回执。回执写明输入哈希、模型与提示版本、Schema 与验证器版本、错误层和 JSON Path、重试次数、费用、人工动作、下游读回及清理结果；缺少适用层证据时不得判为通过。

官方证据、实现样例与核验边界

OpenAI 当前文档说明 Structured Outputs 用开发者提供的 JSON Schema 约束文本响应，严格模式只支持 Schema 子集，并给出 required、additionalProperties:false、可空联合和规模限制；文档同时提醒，结构化输出仍可能在内容上出错，不相关输入也可能诱发符合形状但虚构的值。Google Gemini 文档也说明其结构化输出支持 JSON Schema 子集，并区分格式化最终响应与函数调用。JSON Schema 官方资料把它定义为描述和验证 JSON 结构、约束和类型的声明式语言，同时指出真正验证还需要具体实现。以上是官方声明；本文的四层验收、重试分流、脏数据队列和测试合同是本站工程整理，不表示相关厂商已通过本站生产评测。

• OpenAI Structured model outputs：严格模式、Schema 子集、错误与规模限制。
• OpenAI Responses API reference：json_schema 文本格式与 strict 参数。
• Google Gemini Structured Outputs：支持类型、关键字与函数调用边界。
• JSON Schema 官方文档：声明式结构与验证语言。
• JSON Schema 规范：当前 2020-12 Core 与 Validation 文档。
• JSON Schema 类型与 format 说明：format 在实现中的断言差异。

可下载验收资产怎样使用

随文的结构化输出验收合同 JSON 把四十八项用例、错误类别、预期结果和最小回执字段放在一个可版本化文件中；验证脚本只检查合同结构和配对覆盖，不声称真实调用了任何模型。团队应复制合同，替换为自己的模型、端点、Schema、业务对象、权限和清理动作，再在隔离环境运行。执行结果与合同分开保存，禁止把示例中的 expected 当成实测结果。只有真实输入、实际响应、验证日志和业务读回都齐全，才能对具体系统作通过判断。

与站内相邻任务怎样分工

模型 API 故障恢复覆盖请求 ID、退避、熔断和降级；Agent 身份与授权解释委托、短期凭据和逐工具权限；MCP Server 安全检查聚焦工具服务器的 OAuth 与提示注入；Embedding 与 RAG 验收处理检索证据和向量结果。本文只解决模型输出怎样成为可验证、可隔离、可提交的数据合同，不把 API 通用故障、工具授权或检索质量重复展开。

核验日期和不能推出的结论

资料核验日期为 2026 年 10 月 10 日。本站本轮没有使用真实业务数据调用 OpenAI、Gemini 或其他商业模型，没有对不同模型做性能、准确率、价格或地区可用性排名，也没有执行真实写库、付款、发布或权限变更。官方页面能证明当时公开的接口和约束，不能证明任一业务字段天然正确；官方证据图只证明页面必要局部，不是本站实测；原创图是解释模型，不是产品界面；验收合同只有在填入真实版本、输入、响应、权限、规则、读回和清理结果后才构成项目证据。模型、端点、SDK、Schema 子集、数据处理条款或下游业务规则变化后，应重新核验并重跑受影响用例。