Agent 能不能稳定输出结构化内容已经是 AI 大模型面试里绕不开的高频题也是 Agent 开发中最容易翻车的环节。所谓结构化内容就是让模型输出程序能直接消费的 JSON、固定字段、枚举值或标准格式而不是带解释、带铺垫、甚至带 Markdown 代码块的自由文本。这道题表面在考 Prompt 怎么写实际考你有没有被模型输出坑过懂不懂围绕输出格式做一层完整的工程化约束。我的判断很明确只改 Prompt 永远不够真正稳的是四层约束一起上——Prompt 强制、正反示例、原生参数、代码校验。下面按面试回答习惯和实际落地顺序拆一遍。1. 面试官问这个问题其实是在考工程化思维1.1 结构化输出是 Agent 生产化的地基2026 年前后面试 AI 大模型岗位问 Agent 几乎成了标配。但同样问 Agent问题的深度差很多。初级面试会问“你知道什么 Agent 框架”中级会问“你怎么设计工具调用”再往上就问“你的 Agent 遇到格式不稳定的输出怎么办”。结构化输出这个点正好卡在理论知识和生产实践之间。普通聊天机器人的输出是给人看的格式乱一点不影响阅读。Agent 不一样。Agent 的核心链路是“大模型理解任务 - 生成中间结果 - 程序解析 - 调用工具或继续推理”。中间结果一旦不是预期结构后面的程序就断了。你让模型抽订单信息它给你一段“好的根据您提供的文本我为您抽取了以下订单信息{...}”前端 json.loads 直接报错。你让它生成工具参数它把数组写成了字符串工具调用就会拿到错误输入。这类问题在单条对话里不明显一旦进入批量任务或对外接口失败率会被放大得非常难看。面试官问“怎么让 Agent 稳定输出结构化内容”本质是想确认三件事第一你有没有自己写过 Agent 的真实链路第二你遇到问题时是改 Prompt 碰运气还是有一套系统的排查和约束方法第三你能不能把“模型输出”当作数据去处理而不是当作“最终答案”去信任。这三件事都指向同一个能力工程化思维。1.2 四类最常见的翻车现场先把我实际见过的输出问题归个类后面每一层约束都是针对这些坑来的。失败类型典型表现直接影响代码块包裹输出为json {...}json.loads 直接解析失败附带解释文字“好的结果是{...}”需要额外清洗容易误判字段缺失或类型错误该返回 number 返回 string或直接缺字段下游逻辑拿到脏数据输出被截断max_tokens 不够JSON 只生成一半解析失败且难以自动恢复还有一个很隐蔽的坑字段名被模型“润色”。你要求返回 event_type模型可能自己改成 eventType 或 event_type_string。它觉得自己表达得更清楚但你的校验代码不认识这个字段。这类问题不是报错最明显的却是批量任务里最磨人的。所以四层约束里代码校验那层必须做字段级检查而不只是“解析成 JSON 就行了”。2. 第一层约束Prompt 强制把格式要求写进对话协议2.1 一份可以直接抄的格式协议第一层约束最基础也最好理解在建 Agent 时通过系统提示词或用户消息的开头明确告诉模型“你必须按什么格式输出”。我一般会把格式要求单独做成一段“格式协议”而不是混在任务描述里。下面这个示例是订单信息抽取场景你是订单信息抽取 Agent。 从用户输入中抽取订单信息只输出 JSON不要输出任何解释性文字、问候语或 Markdown 代码块。 JSON 必须严格满足以下结构 { order_id: string, amount: number, status: pending | paid | cancelled, items: [string] } 如果某字段无法确定使用 null不要编造值。这段提示词里有几个关键点。第一明确“只输出 JSON”并且点名禁止解释性文字和 Markdown 代码块因为这两者是最常见的解析失败来源。第二给出字段名、类型和枚举范围模型不需要猜测你的字段规则。第三允许 null避免模型在不确定时强行编造。第四独立的“格式协议”放在固定位置容易被模型识别为高优先级指令。这套写法很多教程里叫 Prompt Engineering但更准确地说它是在和模型约定一份“对话协议”。你把协议写清楚模型的默认表现会好很多这是实测下来最稳定的一层基础。2.2 为什么只靠 Prompt 永远不够但是如果你只听到这一层然后回去只改 Prompt很快会踩坑。原因很简单语言模型是概率输出不是规则引擎。即使你的 Prompt 写得很好它在 99% 的情况下都按格式走批量跑一万条也会出现一百条异常。放在生产环境里一百条异常就是一百次解析失败可能直接影响业务。任务越复杂格式要求越容易失效。比如 Agent 中间要调用多个工具、处理长文档、阅读多轮对话历史格式指令会被大量上下文稀释。模型可能到第三轮就忘了“只能输出 JSON”又开始用自然语言回答。另外不同模型对“只输出 JSON”的理解也不一样有些模型即使看到这句还是习惯性地把结果包在代码块里。所以我的结论是Prompt 强制是地基但不是保险。它的价值是降低异常率而不是消灭异常。真正要消灭异常必须继续往上加后面三层。3. 第二层约束正反示例让模型少猜你的隐含规则3.1 正例给标准答案反例给边界第二层约束是用示例说话。只写“按照上面的 JSON 输出”模型还是可能对“上面”理解不到位。给一两个正反例情况会明显不同。正例就是标准答案的完整展示。比如用户输入帮我查一下订单 1024 的金额和状态。 正确输出 {order_id: 1024, amount: 299.00, status: paid, items: [蓝牙耳机]}反例则是把常见的错误输出摆出来并说明为什么错。比如错误输出不要模仿 好的订单 1024 的金额是 299 元状态是已支付包含一件商品。 原因这不是纯 JSON且 status 使用了中文描述无法被程序解析。加反例的目的是让模型知道“不能做什么”。抽象地说“不要输出解释文字”模型不一定能建立足够强的印象但看到一个具体反例它的学习成本低很多也更容易记住边界。正例负责定义正确形态反例负责砍掉错误路径两者配合才完整。3.2 放示例的三个细节示例不是随便放的有几个细节容易踩。第一个细节示例字段必须和格式协议完全一致。模型非常擅长模仿示例里的字段名。如果协议里写 event_type示例里却写了 eventType模型大概率会按示例输出然后被你的校验代码判错。我见过不少项目Prompt 和示例各写各的最后两头打架。第二个细节示例数量控制在 1 到 3 组。太少覆盖不了边界情况太多会消耗上下文窗口还可能引入噪声。实际开发中我通常只放一组正确示例加一两组针对特殊场景的错误示例比如枚举值写错、多输出了解释文字。第三个细节正确示例放在最后面。模型对最近看到的上下文更敏感把标准形态放在消息末尾能让它在生成时更贴近正确示范。反例可以放在前面起到“先划掉错误路径再摆出正确路径”的作用。4. 第三层约束原生参数能开的开关不要自己硬扛4.1 JSON 模式、Structured Output 和函数调用第三层约束是很多人容易忽略的不要只靠 Prompt 去“说服”模型很多模型 API 本身就提供了格式化输出的能力能用就用。常见的能力包括几类。第一类是 JSON 模式在很多主流 API 里都有类似实现让模型保证输出合法 JSON。第二类是结构化输出或 JSON Schema你可以预先定义字段和类型让模型按 Schema 生成。第三类是函数调用模型把工具参数作为结构化对象返回Agent 框架直接解析不需要你再去字符串里抠 JSON。不同厂商、不同模型版本的接口命名和支持程度不一样具体参数要以官方文档为准。我在项目里的习惯是如果当前模型支持 JSON 模式或 Schema就优先开启不再把宝全押在 Prompt 上。因为这些能力是在解码和生成层面做的约束比“请按 JSON 输出”这句话可靠得多。函数调用尤其适合 Agent 场景。Agent 每一轮要决定调用哪个工具、传什么参数如果这个参数本身就是结构化对象框架可以直接解析。这比让模型先输出一段自然语言、再用正则去匹配参数要稳定一个数量级。4.2 温度和长度参数同样影响稳定性除了格式相关的原生能力采样参数也会直接影响结构化输出的稳定性。温度控制随机性。结构化抽取任务我一般会把 temperature 调到接近 0让模型尽量走确定性路径。写作文、想创意可以调高温度但输出 JSON 给程序消费随机性越低越好。top_p 同理没有特殊需求就保持低值。max_tokens 也要盯住。很多解析失败不是模型不会输出正确结构而是生成到一半被截断了。如果任务可能输出较长内容max_tokens 设太小就会得到半截 JSON。判断方法很简单看输出末尾是不是突然断掉是的话先加长 max_tokens再考虑其他原因。4.3 原生参数也不是保险柜要特别强调一点JSON 模式只能保证“输出是合法 JSON”不保证“内容符合你要的 Schema”。模型完全可能输出一段合法 JSON但少了必填字段或者 status 写成了枚举值之外的内容。Structured Output 支持的模型和接口也有限制不能默认所有模型都有。所以第三层解决的是格式层问题内容层问题仍然要交给第四层。这也是为什么我会把代码校验放在最后——它是整个体系里唯一能百分百拦截不合格输出的环节。5. 第四层约束代码校验把模型输出当成“待验收数据”5.1 校验四步解析、检查、反馈、兜底第四层是所有工程化思路的核心不要信任模型输出把它的输出当作“待验收数据”用程序做最终裁决。流程可以拆成四步。第一步解析用 json.loads 或等价方式把文本变成对象如果外层有代码块或解释文字先做兼容清洗。第二步检查验证必填字段、字段类型、枚举值和取值范围。第三步反馈校验失败时把具体错误信息回传给模型让它重新输出一版修正结果。第四步兜底重试到一定次数仍然失败就返回默认值、进入人工队列或记录日志而不是让整个任务直接崩掉。反馈这一步非常关键。模型看到“amount 字段期望是 number实际得到的是 string”这样的具体错误通常能自行修正。但要注意重试不能无限执行否则单条任务可能在死循环里消耗大量时间和费用。我一般限制在 2 到 3 次。5.2 一个可以直接改着用的校验框架下面是一段简化但可运行的参考代码核心顺序就是“解析 - 校验 - 抛出错误 - 反馈重试”。import json import re REQUIRED_FIELDS { order_id: str, amount: (int, float), status: {pending, paid, cancelled}, } def extract_json(raw): try: return json.loads(raw) except json.JSONDecodeError: pass match re.search(r(?:json)?\s*(\{.*?\})\s*, raw, re.S) if match: try: return json.loads(match.group(1)) except json.JSONDecodeError: return None return None def validate(data): if not isinstance(data, dict): raise ValueError(输出不是 JSON 对象) for field, rule in REQUIRED_FIELDS.items(): if field not in data: raise KeyError(f缺少字段: {field}) value data[field] if isinstance(rule, type): if not isinstance(value, rule): raise TypeError(f{field} 类型应为 {rule.__name__}) elif isinstance(rule, tuple): if not isinstance(value, rule): raise TypeError(f{field} 类型应为 {[r.__name__ for r in rule]}) elif isinstance(rule, set): if value not in rule: raise ValueError(f{field} 不在允许范围: {rule}) return data def call_with_fallback(generate, max_retries2): last_error None for _ in range(max_retries 1): raw generate() data extract_json(raw) if data is None: last_error ValueError(无法解析出 JSON) continue try: validate(data) return data except Exception as e: last_error e print(f校验失败: {e}) # 生产环境这里把 last_error 拼进下一次 generate 的 Prompt raise RuntimeError(f连续失败 {max_retries 1} 次: {last_error})这里把 extract_json 和 validate 分开是为了让重试逻辑更清晰。生产环境可以考虑用更完整的 Schema 校验库但顺序和思想是一样的。这段代码里的 generate 函数对应你实际调模型的函数需要把校验错误信息拼到下一次请求的 Prompt 里让模型看到哪里错了。这个思路其实跟前端工程里做代码自动校验和格式化很像。人写的代码要过 ESLint、Prettier模型生成的 JSON 当然也要过自己的校验规则。你越早把“模型输出”当成“待检查的代码”结构化问题就越可控。5.3 校验层的工程细节真正上线时校验层还要补几个工程细节。日志是必须的。每次校验失败都要记录原始输出、错误类型、重试次数和修正后的结果。没有日志你根本不知道失败原因是 Prompt 写得不好、模型版本换了还是业务字段变了。批量任务更要记录失败率我建议上线前先用几十到一百条样本跑一轮统计字段完整率、解析成功率和平均重试次数再决定要不要调参数。另一个容易被忽略的点是命名和一致性。Prompt 里的字段名、示例里的字段名、校验代码里的字段名三者必须一致。我在项目里经常发现报错看起来像模型输出不稳定实际是校验代码要求的字段和 Prompt 要求的不一样模型按 Prompt 输出了却过不了代码这关。这种低级错误排查起来最浪费时间。6. 面试怎么答一句话点题再给完整链路6.1 可以直接用的回答框架面试时如果被问到“怎么让 Agent 稳定输出结构化内容”不要上来就背“用 JSON 格式”。真正加分的回答是先把问题定性再给链路。第一句点题“Agent 的输出不是给人看的最终答案而是给程序消费的数据所以核心问题是格式稳定性和字段可校验性。”这个定性面试官一听就知道你有实战经验。然后按四层展开。第一层 Prompt 强制写明确格式协议禁止解释文字和 Markdown 代码块第二层正反示例用正确和错误输出减少歧义第三层原生参数优先开 JSON 模式、Structured Output 或函数调用并把温度调低、max_tokens 给够第四层代码校验解析、类型检查、失败反馈重试、兜底记录。最后补一句衡量指标不看“看起来像 JSON Agent稳定输出结构化内容的四层工程化约束
Agent 能不能稳定输出结构化内容已经是 AI 大模型面试里绕不开的高频题也是 Agent 开发中最容易翻车的环节。所谓结构化内容就是让模型输出程序能直接消费的 JSON、固定字段、枚举值或标准格式而不是带解释、带铺垫、甚至带 Markdown 代码块的自由文本。这道题表面在考 Prompt 怎么写实际考你有没有被模型输出坑过懂不懂围绕输出格式做一层完整的工程化约束。我的判断很明确只改 Prompt 永远不够真正稳的是四层约束一起上——Prompt 强制、正反示例、原生参数、代码校验。下面按面试回答习惯和实际落地顺序拆一遍。1. 面试官问这个问题其实是在考工程化思维1.1 结构化输出是 Agent 生产化的地基2026 年前后面试 AI 大模型岗位问 Agent 几乎成了标配。但同样问 Agent问题的深度差很多。初级面试会问“你知道什么 Agent 框架”中级会问“你怎么设计工具调用”再往上就问“你的 Agent 遇到格式不稳定的输出怎么办”。结构化输出这个点正好卡在理论知识和生产实践之间。普通聊天机器人的输出是给人看的格式乱一点不影响阅读。Agent 不一样。Agent 的核心链路是“大模型理解任务 - 生成中间结果 - 程序解析 - 调用工具或继续推理”。中间结果一旦不是预期结构后面的程序就断了。你让模型抽订单信息它给你一段“好的根据您提供的文本我为您抽取了以下订单信息{...}”前端 json.loads 直接报错。你让它生成工具参数它把数组写成了字符串工具调用就会拿到错误输入。这类问题在单条对话里不明显一旦进入批量任务或对外接口失败率会被放大得非常难看。面试官问“怎么让 Agent 稳定输出结构化内容”本质是想确认三件事第一你有没有自己写过 Agent 的真实链路第二你遇到问题时是改 Prompt 碰运气还是有一套系统的排查和约束方法第三你能不能把“模型输出”当作数据去处理而不是当作“最终答案”去信任。这三件事都指向同一个能力工程化思维。1.2 四类最常见的翻车现场先把我实际见过的输出问题归个类后面每一层约束都是针对这些坑来的。失败类型典型表现直接影响代码块包裹输出为json {...}json.loads 直接解析失败附带解释文字“好的结果是{...}”需要额外清洗容易误判字段缺失或类型错误该返回 number 返回 string或直接缺字段下游逻辑拿到脏数据输出被截断max_tokens 不够JSON 只生成一半解析失败且难以自动恢复还有一个很隐蔽的坑字段名被模型“润色”。你要求返回 event_type模型可能自己改成 eventType 或 event_type_string。它觉得自己表达得更清楚但你的校验代码不认识这个字段。这类问题不是报错最明显的却是批量任务里最磨人的。所以四层约束里代码校验那层必须做字段级检查而不只是“解析成 JSON 就行了”。2. 第一层约束Prompt 强制把格式要求写进对话协议2.1 一份可以直接抄的格式协议第一层约束最基础也最好理解在建 Agent 时通过系统提示词或用户消息的开头明确告诉模型“你必须按什么格式输出”。我一般会把格式要求单独做成一段“格式协议”而不是混在任务描述里。下面这个示例是订单信息抽取场景你是订单信息抽取 Agent。 从用户输入中抽取订单信息只输出 JSON不要输出任何解释性文字、问候语或 Markdown 代码块。 JSON 必须严格满足以下结构 { order_id: string, amount: number, status: pending | paid | cancelled, items: [string] } 如果某字段无法确定使用 null不要编造值。这段提示词里有几个关键点。第一明确“只输出 JSON”并且点名禁止解释性文字和 Markdown 代码块因为这两者是最常见的解析失败来源。第二给出字段名、类型和枚举范围模型不需要猜测你的字段规则。第三允许 null避免模型在不确定时强行编造。第四独立的“格式协议”放在固定位置容易被模型识别为高优先级指令。这套写法很多教程里叫 Prompt Engineering但更准确地说它是在和模型约定一份“对话协议”。你把协议写清楚模型的默认表现会好很多这是实测下来最稳定的一层基础。2.2 为什么只靠 Prompt 永远不够但是如果你只听到这一层然后回去只改 Prompt很快会踩坑。原因很简单语言模型是概率输出不是规则引擎。即使你的 Prompt 写得很好它在 99% 的情况下都按格式走批量跑一万条也会出现一百条异常。放在生产环境里一百条异常就是一百次解析失败可能直接影响业务。任务越复杂格式要求越容易失效。比如 Agent 中间要调用多个工具、处理长文档、阅读多轮对话历史格式指令会被大量上下文稀释。模型可能到第三轮就忘了“只能输出 JSON”又开始用自然语言回答。另外不同模型对“只输出 JSON”的理解也不一样有些模型即使看到这句还是习惯性地把结果包在代码块里。所以我的结论是Prompt 强制是地基但不是保险。它的价值是降低异常率而不是消灭异常。真正要消灭异常必须继续往上加后面三层。3. 第二层约束正反示例让模型少猜你的隐含规则3.1 正例给标准答案反例给边界第二层约束是用示例说话。只写“按照上面的 JSON 输出”模型还是可能对“上面”理解不到位。给一两个正反例情况会明显不同。正例就是标准答案的完整展示。比如用户输入帮我查一下订单 1024 的金额和状态。 正确输出 {order_id: 1024, amount: 299.00, status: paid, items: [蓝牙耳机]}反例则是把常见的错误输出摆出来并说明为什么错。比如错误输出不要模仿 好的订单 1024 的金额是 299 元状态是已支付包含一件商品。 原因这不是纯 JSON且 status 使用了中文描述无法被程序解析。加反例的目的是让模型知道“不能做什么”。抽象地说“不要输出解释文字”模型不一定能建立足够强的印象但看到一个具体反例它的学习成本低很多也更容易记住边界。正例负责定义正确形态反例负责砍掉错误路径两者配合才完整。3.2 放示例的三个细节示例不是随便放的有几个细节容易踩。第一个细节示例字段必须和格式协议完全一致。模型非常擅长模仿示例里的字段名。如果协议里写 event_type示例里却写了 eventType模型大概率会按示例输出然后被你的校验代码判错。我见过不少项目Prompt 和示例各写各的最后两头打架。第二个细节示例数量控制在 1 到 3 组。太少覆盖不了边界情况太多会消耗上下文窗口还可能引入噪声。实际开发中我通常只放一组正确示例加一两组针对特殊场景的错误示例比如枚举值写错、多输出了解释文字。第三个细节正确示例放在最后面。模型对最近看到的上下文更敏感把标准形态放在消息末尾能让它在生成时更贴近正确示范。反例可以放在前面起到“先划掉错误路径再摆出正确路径”的作用。4. 第三层约束原生参数能开的开关不要自己硬扛4.1 JSON 模式、Structured Output 和函数调用第三层约束是很多人容易忽略的不要只靠 Prompt 去“说服”模型很多模型 API 本身就提供了格式化输出的能力能用就用。常见的能力包括几类。第一类是 JSON 模式在很多主流 API 里都有类似实现让模型保证输出合法 JSON。第二类是结构化输出或 JSON Schema你可以预先定义字段和类型让模型按 Schema 生成。第三类是函数调用模型把工具参数作为结构化对象返回Agent 框架直接解析不需要你再去字符串里抠 JSON。不同厂商、不同模型版本的接口命名和支持程度不一样具体参数要以官方文档为准。我在项目里的习惯是如果当前模型支持 JSON 模式或 Schema就优先开启不再把宝全押在 Prompt 上。因为这些能力是在解码和生成层面做的约束比“请按 JSON 输出”这句话可靠得多。函数调用尤其适合 Agent 场景。Agent 每一轮要决定调用哪个工具、传什么参数如果这个参数本身就是结构化对象框架可以直接解析。这比让模型先输出一段自然语言、再用正则去匹配参数要稳定一个数量级。4.2 温度和长度参数同样影响稳定性除了格式相关的原生能力采样参数也会直接影响结构化输出的稳定性。温度控制随机性。结构化抽取任务我一般会把 temperature 调到接近 0让模型尽量走确定性路径。写作文、想创意可以调高温度但输出 JSON 给程序消费随机性越低越好。top_p 同理没有特殊需求就保持低值。max_tokens 也要盯住。很多解析失败不是模型不会输出正确结构而是生成到一半被截断了。如果任务可能输出较长内容max_tokens 设太小就会得到半截 JSON。判断方法很简单看输出末尾是不是突然断掉是的话先加长 max_tokens再考虑其他原因。4.3 原生参数也不是保险柜要特别强调一点JSON 模式只能保证“输出是合法 JSON”不保证“内容符合你要的 Schema”。模型完全可能输出一段合法 JSON但少了必填字段或者 status 写成了枚举值之外的内容。Structured Output 支持的模型和接口也有限制不能默认所有模型都有。所以第三层解决的是格式层问题内容层问题仍然要交给第四层。这也是为什么我会把代码校验放在最后——它是整个体系里唯一能百分百拦截不合格输出的环节。5. 第四层约束代码校验把模型输出当成“待验收数据”5.1 校验四步解析、检查、反馈、兜底第四层是所有工程化思路的核心不要信任模型输出把它的输出当作“待验收数据”用程序做最终裁决。流程可以拆成四步。第一步解析用 json.loads 或等价方式把文本变成对象如果外层有代码块或解释文字先做兼容清洗。第二步检查验证必填字段、字段类型、枚举值和取值范围。第三步反馈校验失败时把具体错误信息回传给模型让它重新输出一版修正结果。第四步兜底重试到一定次数仍然失败就返回默认值、进入人工队列或记录日志而不是让整个任务直接崩掉。反馈这一步非常关键。模型看到“amount 字段期望是 number实际得到的是 string”这样的具体错误通常能自行修正。但要注意重试不能无限执行否则单条任务可能在死循环里消耗大量时间和费用。我一般限制在 2 到 3 次。5.2 一个可以直接改着用的校验框架下面是一段简化但可运行的参考代码核心顺序就是“解析 - 校验 - 抛出错误 - 反馈重试”。import json import re REQUIRED_FIELDS { order_id: str, amount: (int, float), status: {pending, paid, cancelled}, } def extract_json(raw): try: return json.loads(raw) except json.JSONDecodeError: pass match re.search(r(?:json)?\s*(\{.*?\})\s*, raw, re.S) if match: try: return json.loads(match.group(1)) except json.JSONDecodeError: return None return None def validate(data): if not isinstance(data, dict): raise ValueError(输出不是 JSON 对象) for field, rule in REQUIRED_FIELDS.items(): if field not in data: raise KeyError(f缺少字段: {field}) value data[field] if isinstance(rule, type): if not isinstance(value, rule): raise TypeError(f{field} 类型应为 {rule.__name__}) elif isinstance(rule, tuple): if not isinstance(value, rule): raise TypeError(f{field} 类型应为 {[r.__name__ for r in rule]}) elif isinstance(rule, set): if value not in rule: raise ValueError(f{field} 不在允许范围: {rule}) return data def call_with_fallback(generate, max_retries2): last_error None for _ in range(max_retries 1): raw generate() data extract_json(raw) if data is None: last_error ValueError(无法解析出 JSON) continue try: validate(data) return data except Exception as e: last_error e print(f校验失败: {e}) # 生产环境这里把 last_error 拼进下一次 generate 的 Prompt raise RuntimeError(f连续失败 {max_retries 1} 次: {last_error})这里把 extract_json 和 validate 分开是为了让重试逻辑更清晰。生产环境可以考虑用更完整的 Schema 校验库但顺序和思想是一样的。这段代码里的 generate 函数对应你实际调模型的函数需要把校验错误信息拼到下一次请求的 Prompt 里让模型看到哪里错了。这个思路其实跟前端工程里做代码自动校验和格式化很像。人写的代码要过 ESLint、Prettier模型生成的 JSON 当然也要过自己的校验规则。你越早把“模型输出”当成“待检查的代码”结构化问题就越可控。5.3 校验层的工程细节真正上线时校验层还要补几个工程细节。日志是必须的。每次校验失败都要记录原始输出、错误类型、重试次数和修正后的结果。没有日志你根本不知道失败原因是 Prompt 写得不好、模型版本换了还是业务字段变了。批量任务更要记录失败率我建议上线前先用几十到一百条样本跑一轮统计字段完整率、解析成功率和平均重试次数再决定要不要调参数。另一个容易被忽略的点是命名和一致性。Prompt 里的字段名、示例里的字段名、校验代码里的字段名三者必须一致。我在项目里经常发现报错看起来像模型输出不稳定实际是校验代码要求的字段和 Prompt 要求的不一样模型按 Prompt 输出了却过不了代码这关。这种低级错误排查起来最浪费时间。6. 面试怎么答一句话点题再给完整链路6.1 可以直接用的回答框架面试时如果被问到“怎么让 Agent 稳定输出结构化内容”不要上来就背“用 JSON 格式”。真正加分的回答是先把问题定性再给链路。第一句点题“Agent 的输出不是给人看的最终答案而是给程序消费的数据所以核心问题是格式稳定性和字段可校验性。”这个定性面试官一听就知道你有实战经验。然后按四层展开。第一层 Prompt 强制写明确格式协议禁止解释文字和 Markdown 代码块第二层正反示例用正确和错误输出减少歧义第三层原生参数优先开 JSON 模式、Structured Output 或函数调用并把温度调低、max_tokens 给够第四层代码校验解析、类型检查、失败反馈重试、兜底记录。最后补一句衡量指标不看“看起来像 JSON