#工具输出稳定性专题总览

很多 AI 应用最早看起来都只是“让模型回答一段话”。但一旦进入产品，输出很快会被下游系统消费：前端要渲染卡片，后端要写数据库，工作流要调用工具，客服系统要创建工单，数据助手要生成查询参数。

这时问题不再只是“模型说得对不对”，而是：

• 输出是不是合法 JSON？
• 必填字段有没有缺失？
• 字段类型是否稳定？
• 枚举值是否在允许范围内？
• 能不能被解析、校验、入库和审计？
• 解析失败后系统如何降级？

工具输出稳定性不是为了追求形式漂亮，而是为了让模型输出进入工程系统时可控。它不能保证事实一定正确，但能减少格式漂移、字段缺失、类型错误和解析失败带来的线上事故。

#场景

先看一个具体场景。

在 B2B SaaS 客服后台，用户提交一段自然语言工单：

我昨天买的企业版发票还没开出来，财务催得很急，能不能帮我查一下？订单号好像是 E20260509018。

系统希望 AI 输出结构化结果，供后端创建工单、推荐处理流程并决定是否调用订单工具：

{
  "intent": "invoice_issue",
  "urgency": "high",
  "orderId": "E20260509018",
  "requiresTool": true,
  "toolName": "get_invoice_status",
  "customerMessageSummary": "用户询问企业版发票开具状态，财务催促较急。"
}

这个输出不是给人随便读一读，而是会被程序消费：

• intent 决定工单队列。
• urgency 决定 SLA。
• orderId 作为工具参数。
• requiresTool 决定是否调用后端 API。
• customerMessageSummary 展示给人工客服。

如果模型少了 orderId，工具无法调用；如果 urgency 输出成 "非常急"，枚举解析失败；如果 requiresTool 输出成字符串 "yes"，布尔判断可能出错；如果 JSON 末尾多了一段解释，解析器可能直接报错。

这类失败在 demo 里容易被忽略，因为人可以读懂。但在生产系统里，下游程序不会“体谅”模型。

#问题类型

工具输出稳定性主要处理的是“输出能不能被程序可靠消费”。它和幻觉问题相关，但不是同一件事。

模型可能输出格式完全正确、字段齐全，但事实是错的；也可能事实大体正确，却因为 JSON 不合法导致整个流程失败。工程上需要把这些问题拆开。

这些问题里，有些适合交给模型，有些不应该交给模型。

适合交给模型的部分包括：从自然语言里识别意图、抽取候选字段、给出摘要、判断是否需要工具、生成面向人的解释。

应该由程序处理的部分包括：JSON 解析、schema 校验、枚举映射、默认值填充、权限校验、工具参数合法性、写库事务和错误分流。

必须保留人工确认的部分包括：高金额退款、对外承诺、敏感权限变更、合规判断和不可逆操作。

#风险/收益

结构化输出的收益很明确：让 AI 能接入真实系统，而不是停留在聊天窗口。

主要收益包括：

• 前端可以稳定渲染 UI。
• 后端可以校验、入库、审计。
• 工具调用参数更可控。
• 工作流可以根据字段分支执行。
• 失败样本可以归因到具体字段。
• 线上质量可以用解析成功率、schema 通过率和字段错误率衡量。

但它也有成本：

• 需要设计 schema。
• 需要维护 prompt、schema 和业务规则的一致性。
• 需要处理解析失败、修复、重试和降级。
• 需要记录错误样本并持续评估。
• 复杂 schema 会增加模型理解成本和输出失败概率。

所以不是所有场景都需要一开始就上完整工程方案。

如果输出只是给人看、用户会编辑、字段不进入下游系统，简单 prompt 往往足够。例如让模型把会议纪要整理成“背景、决策、待办”的 Markdown，人类会阅读和修改，偶尔格式不一致也不构成事故。

如果输出要进入数据库、触发工具、驱动 UI、影响权限或进入自动化流程，就不能只靠“请输出 JSON”。这时需要结构化输出能力、schema 校验、错误处理和可观测性。

#方案阶梯

工具输出稳定性可以从轻到重逐级升级。

第一层是简单 prompt。写清楚只输出 JSON、不要解释、字段含义、示例和未知时如何表示。适合低风险、字段少、人工可复核的场景。

第二层是 JSON mode。它主要解决 JSON 语法合法性，让输出更容易被解析。但 JSON mode 不等于业务字段正确，也不保证 schema 符合预期。

第三层是 schema 约束。把字段、类型、枚举、必填项、嵌套结构定义清楚，让模型按明确结构输出。

第四层是程序校验。无论模型声称自己遵守 schema，后端都要用 Zod、JSON Schema 或同类工具做真正校验。

第五层是修复和重试。解析或校验失败时，把错误信息和原始输出交给模型修复，或重新生成。重试要有次数、超时和成本上限。

第六层是降级和人工确认。高风险流程不能因为结构化输出失败就静默继续。系统要能转人工、进入待处理队列或要求用户补充信息。

第七层是 Eval 和监控。上线后持续记录解析成功率、schema 通过率、字段缺失率、工具参数错误率和重试成本。

#方案选型表

#反模式

第一种反模式：只在 prompt 里写“请输出严格 JSON”。

这能改善一部分问题，但不是工程方案。模型仍可能输出字段缺失、类型错误、枚举漂移或解释文本。只要下游流程依赖输出，就必须有解析和校验。

第二种反模式：用正则从自由文本里抠字段。

短期看很快，长期会变成脆弱的隐性协议。模型换一句话、换一个顺序、换一个标点，解析就可能失败。能定义 schema 的地方，优先定义 schema。

第三种反模式：schema 设计得过大。

一次让模型输出几十个嵌套字段，会增加缺字段和类型错误。很多场景应该拆成多个步骤：先分类，再抽取必要字段，再调用工具，再生成解释。

第四种反模式：校验失败后无限重试。

重试有价值，但必须有上限。否则线上会出现成本和延迟失控，用户还不知道系统卡在哪里。

第五种反模式：把 schema 校验当成事实校验。

schema 只能说明字段形状正确，不能说明 orderId 真的属于当前用户，也不能说明退款金额合理。业务校验、权限校验和工具校验仍然必须存在。

第六种反模式：解析失败后静默降级为默认值。

例如 urgency 解析失败就默认 low，可能让紧急工单被延误。默认值必须区分“业务默认”和“系统失败”，并进入可观测日志。

#工程清单

• 场景边界：输出是给人看，还是会进入数据库、工具、UI 或工作流。
• 输出契约：字段、类型、枚举、必填项、空值策略是否明确。
• Prompt 资产：是否包含字段说明、示例、拒绝解释文本和未知值规则。
• 解析策略：是否只接受合法 JSON，失败时是否记录原始输出。
• Schema 校验：是否用 Zod、JSON Schema 或同类工具做后端校验。
• 业务校验：字段是否还需要权限、归属、范围、时间和状态校验。
• 修复重试：是否有错误回填、次数上限、超时和成本上限。
• 降级路径：解析失败、校验失败、工具失败时用户和运营如何处理。
• 人工确认：高风险字段或动作是否需要确认界面和依据展示。
• 可观测性：是否记录模型、prompt 版本、schema 版本、错误类型和重试次数。
• 评估体系：是否有字段级样本集、回归测试和线上错误抽样。
• 版本管理：schema 变更是否兼容旧数据和旧 prompt。

#小结

工具输出稳定性的核心不是“让模型看起来更守规矩”，而是把模型输出变成一个可解析、可校验、可降级、可观测的工程接口。

低风险、给人看的输出，可以从简单 prompt 起步。只要输出要被程序消费，就应该引入 JSON mode、schema、程序校验和失败处理。只要输出会触发工具或影响真实权益，就还需要业务校验、权限控制、人工确认和审计。

这个专题的后两篇会继续展开：

• 如何从 prompt、JSON mode、schema、修复和重试逐级提高 JSON 输出稳定性。
• 如何用 Zod、JSON Schema 和错误 schema，把工具输出变成可控的系统契约。