企业官网建设流程全解析

《AI 知识卡片》第 06 期 · 做 Agent，怎么拿到稳定可靠的格式输出

你可能遇到过，提示词里写了“只返回 JSON，别加多余的话”，它偏偏回一句“好的，这是结果：xxx”。做 Agent 时这尤其要命——Agent 一环扣一环，前一步吐了脏数据，后面整条链路都可能崩。所以大模型输出的格式必须稳。

为什么“求”不管用

你在系统提示词里写的格式要求，本质是软约束：它“倾向于”照做，但不保证。对要用程序处理的 Agent 来说，“大部分时候对”就是“不可靠”——你没法赌什么时候会翻车。

改变一下思路，不是把话说得更完美，而是**从机制上让它只能输出对的格式，并且假设它总会漏，层层设防。**下面这些手段，由简单到进阶。

第一层：先把简单的做到位

提示词说清楚 + 给例子。给例子比空口要求有效得多。但它是软约束，能把成功率从 70% 提到 95%，到不了 100%——是地基，不是保险。比如：

只返回 JSON，格式如下，不要解释： {"name": "string", "age": number}

Temperature参数调 0。结构化任务不需要创意，随机性越低格式越稳、越可复现。

第二层：上“机制级”的硬保证

用结构化输出 / 函数调用。这是关键升级。主流大模型 API 都支持结构化输出：你给一份JSON Schema（字段、类型、必填项），模型被从机制上限制只能吐出符合它的结果（OpenAI 的response_format等）。

原理不是“求模型配合”，而是在生成时只允许它挑符合格式的内容，从源头堵死“加句废话”。在 Agent 里，这通常以函数调用（Function Calling）的形式出现——你定义好工具的参数结构，模型产出的调用参数天然就是受约束的 JSON。

重试机制。拿到就校验，错了让它自己改，再硬也要校验（Pydantic、zod 这类）。不合法就把错误反馈回去、让它先自愈，比如：

上次输出不符合格式，错误：<校验报错> 请严格按 schema 重新输出。

一两次通常就修对了。但重试必须设上限（比如最多 2 次）——Agent 最忌“死循环”，一直重试既烧钱又拖垮服务。

能做到这几步，绝大多数场景已经很稳了。但真正上生产、跑大量请求时，还得再兜两层底。

第三层：错了也不能失控

（1）降级兜底：绝不把脏数据传给下游。重试到上限仍失败，不能直接崩、也不能把脏数据往下游塞，要有预案：

• 退回用正则做一次宽松解析，能捞多少捞多少；
• 用一个安全的默认值顶上；
• 或者明确报错、转人工；

（2）建立监控，别凭感觉靠数据。线上跑起来后，格式可靠性得能被“看见”：

• 盯几个关键指标：格式合法率、解析失败率、平均重试次数、降级触发率——任一个异常波动都是信号。
• 设告警：失败率突破阈值就自动报警。这样“今天换了模型版本、失败率突然涨了”你能第一时间知道，而不是等下游炸了才发现。
• 留失败样本、形成闭环：把每次解析失败的原始输出记下来，定期回看——是提示没写清？schema 太严？还是模型换版了？据此优化提示 / schema，甚至沉淀成测试用例，防止下次再犯。

原则一句话：宁可优雅地失败，也不能把错误静默地传下去。而监控的意义不只是“报警”，而是让格式可靠性可度量、可追溯、可持续改进。

一句话总结

光靠提示词来约束格式不可靠，需要一层层保障，先做简单的，再上硬保证（结构化输出）和兜底（校验重试、降级、监控）——每一层都假设上一层会漏，最后确保错了也不失控。