前几天一个学习 Agent 的朋友在群里问了我一个问题：

实际来说，这个问题问得特别好。不过，因为它直接触及了 Agent 能跑起来的底层前提——模型输出的 JSON 必须是合法的。

你想想。一个 Agent 跑一个任务，可能要调用几十次工具。说起来，每次调用都是一段 JSON。如果有 10% 的概率格式出错，跑 10 轮就几乎必崩一次。说起来，这种东西要是不靠谱，整个 Agent 环境确实不可能存在。

那大模型到底是怎么保证 JSON 输出的正确性的？这个问题其实涉及到模型最底层的生成机制。今天就来好好聊聊，

先搞清楚一件事：模型是一个 token 一个 token 蹦出来的

很多人对大模型有个误解，觉得它是“想好了整段话再说出来的”。说起来，

不是的。大模型生成文本的过程，是一个 token 一个 token 往外蹦的。它先生成第 1 个 token，接下来基于第 1 个 token 再生成第 2 个。再基于前 2 个生成第 3 个…，一直到输出结束标记。

这个过程叫。

动画特效，这就是模型真实的生成过程。

当模型要输出一段 Function Call 的 JSON 时它也是一步步蹦出字符：

{"na ← 第一批 token
至于"me"，"get ← 第二批
_wear"。← 第三批
"input": { ← 第四批
"city"的观点是，"北京"} ← 最终一批，JSON 才完整

只有等最终一个 } 蹦出来后才能解析这段 JSON 并执行工具。

每次蹦一个 token，本质上是在“抽签”

模型每生成一个 token。内部实际发生的是：

1. 打分: 对词汇表里每个候选 token 给出出现概率分数；话说回来，
2. Sofmax 归一化: 把分数转成概率分布。总和为 1，说起来，
3. 抽签: 按概率随机挑选下一个 token。按理说，

概率高的更容易被选中。但并非百分之百确定，这也是同一道题会出现不同答案的原因。

光靠训练，JSON 正确率只有个位数 %

训练阶段：

• 模型见过海量 JSON 示例；
• 也学过 “给定 JSON Schema，输出符合 Schema 的 JSON”。它掌握了基本语法规则，

%5~10. 换算下来每100 次工具调用，就会有 5~10 次格式错误。老实说，

痛点：在实际业务中。一次格式错误往往导致整个 Agent 流程崩溃，影响使用者体验和程序可靠性。话说回来，

说到约束解码，把不合法选项提前排除掉

The key:

• The model still generates token by token.
• The decoder can filter out tokens that would break schema before sampling step.

约束解码工作流概览

1. Scheam 编译：
2. L​ook‑ahead 检查：
3. P​robability Masking：
4. L​ayer‑wise Softmax：

从示例来看。强制字符串引号

{"city":| // 已经输出到冒号后
// 合法下一字符只能是 "
"

If model tries to output a digit or a boolean here,its probability is forced to zero.

效果对比

• No constraint: 仅凭训练 ~%5 错误率；
• C​onstrained decoding: 训练 + 强制语法 → 错误率降至 ~%0.1 以下。

痛点缓解：在生产环境中几乎消除了因 JSON 格式错误导致的崩溃风险。

约束解码只管格式，不管语义 —— 仍需业务层校验

The decoder guarantees that:

• The output is syntactically valid JSON;
• The field types match schema.

不能确保字段值本身合理。例如的观点是，

• `city` 字段可以是任何字符串。即使是不存在的城市 “哥谭市”。
• `id` 可以是看似合法却不存在的 UUID。
• `file_path` 可以是根本不存在的方法。

痛点：语义错误会在调用实际工具时才暴露，需要额外参数校验、业务规则检查还有友好的错误反馈机制。

System Prompt 约束真的靠谱吗？

The friend furr asked: “如果用 OpenSpec 那种基于 system prompt 的 CLI 程序，约束相对 Tool Call 会弱很多吧？”

• P​rompt‑level guidance：
• C​onstraint‑level ：`

"告诉司机走右边车道" vs "路中间立起隔离带"

痛点：仅靠 Prompt 很难做到零错误率，而硬性约束可以让程序几乎不出现格式异常。

更广阔的使用场景 —— 不止 Function Calling

• S​tructured Output： 把前几个 Token 写死。让模型只能沿着你设定好的方法继续生成，这样就能实现另一种“硬性”控制。

  json {"name":"browser_ 这里模型只能补全以 browser_ 开头且符合 schema 的工具名。话说回来，

  ---

  结论 & 行动教程

  1. M​odel generates tokens one‑by‑one via probabilistic sampling.
  2. C​onstrained decoding eliminates illegal tokens before sampling.
  3. T​raining + constrained decoding ⇒>99.9% format correctness.

  This isn’t about a “smart” model;it’s about a mechanism design that forces correctness at generation time.

  "我在生产环境里频繁遭遇 Tool Call 格式崩溃——怎么才能根治？"

---