工具调用JSON数据格式的可靠性保障机制解析

前几天，一位正在研究Agent的朋友在群里提了个问题，问得特别到位：

Tool Call似乎是Agent循环的灵魂，但如果JSON返回总是不对劲，那现在这么繁荣的Agent生态怎么可能存在呢？所以，这个问题是从什么时候开始被解决的？是在Function Calling时代就解决了吗？

这个问题确实问到了点子上。它直接触及了Agent能够稳定运行的一个底层前提——模型输出的JSON必须是合法的。

想象一下，一个Agent执行任务，可能需要调用几十次工具。每一次调用都是一段JSON。如果每次调用有哪怕5%的概率格式出错，那么运行20轮就几乎必然会崩溃一次。如果基础不牢靠，整个Agent生态的大厦确实无从谈起。

那么，大模型究竟是如何保证JSON输出的正确性的呢？这背后其实涉及到模型最底层的生成机制。今天，我们就来深入聊聊这个话题。

首先要明确：模型是一个字一个字“蹦”出来的

很多人对大模型有个误解，以为它是“想好了整段话再一口气说出来”。

事实并非如此。大模型生成文本的过程，是一个token接一个token“蹦”出来的。它先生成第一个token，然后基于第一个token生成第二个，再基于前两个生成第三个……如此循环，直到输出一个结束标记。

这个过程被称为自回归生成。

你在ChatGPT或Claude里看到的那个“打字机效果”——文字一个一个地出现，这并非动画特效，而是模型真实的生成过程。

问题来了：当模型需要输出一段Function Call的JSON时，它同样是一个token一个token地“蹦”出来的。先蹦出一个{，再蹦出一个"，接着是n、a、m、e……

你接收到的不是一个完整的、瞬间呈现的JSON，而是一系列碎片：

{"na        ← 第一批 token
me": "get   ← 第二批
_weather",  ← 第三批
"input":    ← 第四批
{"city":    ← 第五批
"北京"}}    ← 最后一批，JSON才完整

必须等到最后一个}“蹦”出来，你才能解析这段JSON，才能去执行工具。

好，请记住这个过程，接下来是关键。

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

模型每生成一个token，内部实际发生的是这样一件事：

模型的词汇表中包含数万甚至数十万个token。每当要生成下一个token时，模型会给词汇表里的每一个候选token打一个分（称为logits），这个分数代表了“根据已生成的上下文，这个token接下来出现的可能性有多大”。

然后，这些分数会经过一个叫做softmax的函数，转化为概率分布——所有候选token的概率之和为1，这个过程称为归一化。

最后，从这个概率分布中进行“抽签”，选出下一个token。

概率高的token更容易被选中，但这并非100%确定。这也解释了为什么你向模型提出同一个问题，有时会得到不同的回答。

这个“打分 → 概率 → 抽签”的过程，是理解后续所有机制的核心。

仅靠训练，JSON正确率只有93%

现在我们了解了模型生成token的方式，那么它输出JSON时，凭什么能保证格式正确呢？

第一层保障是训练。

模型在训练阶段接触过海量的JSON数据，也学习过大量“给定一个JSON Schema，输出符合该Schema的JSON”的样本。因此，它确实学会了JSON的语法规则——知道什么时候该输出引号，什么时候该输出逗号，什么时候该闭合花括号。

但仅靠训练就足够了吗？

OpenAI曾公布过一个数据：单纯依靠训练，模型输出符合JSON Schema的正确率大约只有93%。

93%听起来挺高？但换算一下：每100次工具调用中，就有7次格式可能出错。一个Agent执行一个稍微复杂的任务，进行10轮工具调用就很可能崩溃一次。

在生产环境中，93%的可靠度远远不够。

那该怎么办？

约束解码：提前排除非法选项

这时，约束解码（Constrained Decoding）就该登场了。

还记得刚才说的吗？模型每次生成token时，会给所有候选token打分，然后从概率分布中抽签。

约束解码所做的非常直观——在“抽签”之前，直接将不合法的选项排除掉。

具体流程如下：

1. 先将JSON Schema编译成一套语法规则。
2. 每生成一个token时，进行检查：根据已经生成的内容，判断接下来哪些token在语法上是合法的。
3. 将不合法的token的概率直接设置为0。
4. 对剩下的合法token重新进行归一化（Softmax），然后正常“抽签”。

举个例子。假设Schema要求有一个city字段，类型是字符串。当模型已经生成到"city":时，按照JSON语法，下一个token只能是"（字符串的开始引号）。此时，数字、布尔值、null等token的概率会被全部设为0。模型即使“想”选也选不了。

再比如，模型已经输出了{"name": "get_weather", "input": {"city": "北京"，这时下一个token只能是}（如果对象结束）或者,（如果还有其他字段）。它绝对不可能“蹦”出一个不合法的字符。

训练让模型“倾向于”输出正确的JSON，而约束解码则让模型“只能”输出正确的JSON。

两者结合，JSON格式的正确率就能达到100%。

这就是当今Agent生态得以繁荣的技术基石。Function Calling在底层应用了约束解码，从机制上保证了格式不会出错，而不是依赖“模型比较聪明，所以一般不会错”这种概率性的期望。

但约束解码只管格式，不管语义

这里需要补充一个非常重要的点。

约束解码能保证的是格式上的正确性——JSON语法一定是合法的，字段类型一定是对的。

但它不能保证语义上的正确性。

什么意思？比如你的工具有一个参数city，类型是字符串。约束解码能保证模型输出的确实是一个字符串，但它不能保证这个字符串是一个真实存在的城市名称。模型完全可能填入一个“哥谭市”——格式完全正确，JSON解析毫无问题，但工具执行必然失败。

再比如，模型可能编造一个看起来像UUID但实际上并不存在的ID，或者拼写一个语法正确但实际并不存在的文件路径。这些都是格式正确但语义错误的情况。

因此，在实际的Agent系统中，仅有约束解码是不够的。你还需要参数校验、执行前检查以及清晰的错误反馈机制。这些就是另一个话题了。

那么，用System Prompt约束JSON输出靠谱吗？

那位朋友还追问了一个问题：如果使用OpenSpec那种基于system prompt的命令行界面系统，其约束力相对于Tool Call是否会弱很多？

答案是肯定的，确实会弱很多。

在system prompt中写上“请用JSON格式输出”，这种约束本质上是自然语言层面的引导。模型会“尽力”按照你指示的格式输出，但它在生成过程中没有任何机制层面的保障。模型在每一步选择token时，所有token（包括那些会破坏JSON格式的token）都仍然是可选项。

而Function Calling / Tool Call所使用的约束解码，是机制层面的保障。在token“抽签”之前，不合法的选项已经被物理性地排除了。模型不是“尽力”不犯错，而是“不可能”犯错。

举个形象的比喻：前者好比告诉司机“请走右边车道”，靠的是自觉；后者则像是在路中间直接设立了隔离带，依靠的是物理约束，效果立竿见影。

所以，如果你在进行Agent开发，涉及到工具调用的场景，务必使用模型原生的Function Calling能力，而不是试图用system prompt来约束输出格式。这不仅仅是“好不好用”的问题，而是“能否在生产环境稳定运行”的问题。

再往深处思考一层

实际上，理解了约束解码，你会发现它的应用远不止于Function Calling。

例如结构化输出——如果你想让模型按照固定格式输出一个评分结果、一段摘要、一组提取的实体，都可以采用同样的技术。给定一个JSON Schema，模型的输出就被限制在这个Schema定义的语法范围内。

再比如Manus使用的response prefill技巧。既然模型是基于前面所有token来决定下一个token的，那么你可以提前替模型写好开头的几个token，模型就只能顺着你预设的开头继续生成。例如，你在assistant消息中预填{"name": "browser_，那么模型就只能在以browser_开头的工具名中进行选择了。这也是一种约束，只不过是另一种实现思路。

这些技巧背后的原理是一脉相承的：一旦理解了模型“一个token一个token抽签”的生成机制，你就能明白所有这些控制手段为何有效。

总结

回到最初的问题——Tool Call的JSON输出凭什么能保证正确？

答案可以概括为三句话：

1. 模型是一个token一个token生成的，每一步都在概率分布中“抽签”。
2. 约束解码在每次“抽签”前，提前排除了所有不合法的选项。
3. 训练让模型“学会”格式，约束解码让模型“必须”遵守格式，两者结合实现了100%的格式正确性。

这不是因为模型“聪明”，而是精心的机制设计。

这个问题之所以值得深入探讨，正是因为它触及了Agent开发中一个非常底层却又至关重要的知识点。开发Agent不仅仅是调用API或编写prompt那么简单，如果不理解这些底层机制，很多技术决策就会失去依据，令人困惑。相信这位朋友的疑惑并非个例，而是普遍存在的。