Tool Parser、Function Calling 与结构化结果回路#

这章解决什么问题#

如果只讲 json_schema、regex 和 API 表面，结构化生成这一节仍然会缺一块很重要的内容：当模型输出不只是“结构化文本”，而是“可执行工具调用”时，系统怎样把它解释、拼接、校验并送回调用方。这一层正是 tool parser 和 function calling 的职责。

这一章要解决的问题就是：为什么 tool parser 既不像纯 grammar backend，也不像纯 API 协议层。它更像一条把“模型输出”转成“可执行结果结构”的中间回路。

parser 在这里到底扮演什么角色#

官方 docs/advanced_features/tool_parser.ipynb 列出了多个 parser，例如 deepseekv3、glm、qwen、pythonic 等。最值得抓住的不是模型名单，而是 parser 的存在本身说明：不同模型输出 function call 的方式并不天然统一，系统必须提供一层解释器把这些输出重新整理成调用方可消费的结构。

这意味着 parser 不是可有可无的附属物。它是结构化结果回路的一部分：模型先输出某种格式，parser 再把它还原成工具调用对象、参数片段或完整函数调用结构。没有这一层，很多“模型看起来已经输出了工具调用”的情况，在工程上其实还是不可用的。

为什么它不等于 grammar backend#

grammar backend 解决的是“输出空间怎样被限制”；tool parser 解决的是“输出结构怎样被解释”。这两件事经常一起出现，所以容易被混为一谈，但它们不应该写成同一个概念。一个简单判断是：只要问题在问“模型是否被限制在某种结构空间里”，那更接近 grammar backend；只要问题在问“这一段结果是不是已经能被当作工具调用消费”，那更接近 parser。

这也是为什么本章要单独立出来。否则，结构化生成一章会被迫同时讲“约束如何进入 generation path”和“结果如何被解释成工具调用”，读者会很难看清各自的边界。

function calling 的工程价值在哪里#

从工程视角看，function calling 并不只是“模型多了个花哨能力”。它真正有价值的地方，是把原本需要人类去猜的“模型到底想调用什么工具、传了什么参数”，变成一条更稳定的结构化路径。只要 parser 能可靠地把这些结果解释出来，调用方就更容易把大模型嵌入工具系统。

但这条路径也有明显代价：模型输出格式、chat template、parser 行为和下游工具接口之间都必须保持一致。也就是说，tool parser 把系统的可用性提高了，但同时也增加了“接口必须对齐”的复杂度。

一个最小的理解框架#

模型输出
  -> parser 解释
    -> 函数名 / 参数结构
      -> 调用方执行工具
        -> 工具结果回填
          -> 模型继续生成或收尾

这条链路的意义，是把 function calling 从“输出格式问题”推进成“结果回路问题”。一旦把它看成回路，你就会更自然地把它和 request lifecycle、runtime path、structured output 放到一起理解。

调试时最容易卡在哪#

最常见的两个问题是：模型已经输出了看似像工具调用的文本，但 parser 没法稳定解释；或者 parser 解释出来了，但工具结果回填后模型没有按预期继续生成。前者更像 parser / template / output-format 问题，后者更像整体回路问题。

这也是为什么这章值得保留在书里。它不只是帮读者“知道有 function calling”，而是帮读者判断：如果这条链断了，先去看输出格式、parser，还是去看回填后的后续生成。

本章对应哪些代码路径#

这一章最重要的锚点包括 docs/advanced_features/tool_parser.ipynb、python/sglang/srt/function_call/function_call_parser.py、python/sglang/srt/function_call/base_format_detector.py，以及 OpenAI-compatible function calling 相关测试路径，例如 test/registered/openai_server/function_call/ 下的测试集合。

小结#

tool parser 和 function calling 让结构化生成这一节从“约束输出格式”进一步走向“形成可执行结果回路”。只要把这一层补进去，整节就不再只是 grammar 或 API 两头，而会更像一本技术书该有的完整能力闭环。