Agent 输出不符合规范的标准解决方案 —— Agent系列第一篇本文系统梳理了工业界应对大模型输出格式不稳定的四大成

Agent 经常在输出标准 JSON 的同时，自作聪明地加上一句“好的，以下是您需要的 JSON 数据：”，导致后续代码的 JSON.parse() 直接崩溃。

在工业界，大模型的输出具有概率性，单纯依赖提示词（Prompt）“严禁输出多余废话”是不可靠的。为了保证系统的高可用性，业界已经沉淀了几套成熟的防范和兜底方案。

按控制层级从上到下，通常有以下四种成熟方案：

这是目前商业化大模型（如 Gemini, OpenAI, Anthropic）主推的最强力方案。不再需要靠提示词去“求”模型，而是直接在 API 请求体中定下死规矩。

JSON Mode (JSON 模式)：在 API 参数中设置 response_format: { "type": "json_object" }。这会强制模型输出合法的 JSON 字符串，极大减少了输出前后的废话。
Structured Outputs (严格结构化输出)：比 JSON Mode 更进一步。可以直接把一个 JSON Schema 传给大模型 API，底层推理引擎会保证输出的 JSON 100% 符合你提供的字段名和数据类型，连多一个字段或少一个字段都不行。
Function Calling 变相使用：把你想让模型输出的格式定义成一个 Function 的参数。模型为了调用这个 Function，必须严格按照参数结构返回 JSON。这在工业界被广泛用作强制格式化的巧妙手段。

即使模型尽力了，也可能出错。工业界绝对不会直接信任模型的输出，而是会引入一层工程化的“拦截器”。目前主流框架（如 LangChain, LlamaIndex, Spring AI）都内置了这种机制。

Pydantic / Zod 数据验证：在 Python 端使用 Pydantic，或在 Node.js 端使用 Zod 定义数据模型。拿到 LLM 的输出后，立刻扔进验证器。
自动纠错循环 (Retry Mechanism)：如果验证失败（比如缺少某个必填字段，或者格式不合法），代码拦截这个报错信息，并将报错信息作为新的上下文再次发给大模型，对它说：“你的输出不合法，报错信息是 xxx，请修复它并重新输出。” 通常重试 1-3 次，成功率能达到 99% 以上。

如果在无法使用特殊 API 参数的场景下（比如使用较老或较弱的模型），提示词工程依然是第一道防线。

提供 Few-Shot 示例：不要只说“请输出 JSON”，直接给它 2 到 3 个输入输出的完整对照例子。大模型是极佳的“模仿者”，看到例子后，偏离格式的概率会骤降。
使用 XML 标签包裹：不要指望模型完全不说废话。你可以要求模型把关键数据放在特定的标签里。例如：“请将你的分析过程写在 <think></think> 标签内，然后将最终的 JSON 结果严格放在 <result></result> 标签内。”
- 在代码端，不要用原生的 JSON 解析，而是先用正则表达式（Regex）提取 <result> 标签中间的内容，再进行解析。这种方法非常鲁棒，是 Anthropic (Claude) 极其推荐的最佳实践。

这是开源模型/私有化部署场景下的终极必杀技。如果你自己部署模型（比如 Llama 3, Qwen 等），可以通过控制底层的生成逻辑，从物理上杜绝格式错误。

工作原理：大模型生成文本时，是在词表中计算每个词的概率（Logits）。约束解码工具（如 Outlines, Guidance, 或 Llama.cpp 的 Grammar 机制）会在模型预测下一个词时，强制把不符合语法规则的词的概率强行降为 0。
效果：如果你要求它生成 JSON，当它生成了 { "name": " 之后，引擎会强制下一个字符只能是合法的内容，它在物理层面上根本“发不出”除了 JSON 结构之外的任何声音。

通常我们不会只用一种，而是组合拳： 模型原生的 Structured Outputs / Function Calling + 代码层的 Pydantic 校验与重试兜底。