Reasoning Parser、多轮工具回路与结果回填#

这章解决什么问题#

仅仅理解 schema、regex 和 parser 还不够，因为真实系统里常见的不是“一次结构化输出就结束”，而是多轮工具回路：模型先给 reasoning 或 tool call，外部系统执行工具，再把结果回填，模型最后继续输出。这一层如果不补，结构化生成章节仍然会偏静态。

这一章要解决的，就是“结构化结果怎样进入多轮回路”。这是很多好技术书都会继续补的一层：不只讲一次调用，而讲真实工作流。

为什么 reasoning parser 和 tool parser 值得一起讲#

从官方文档和 basic usage 看，tool parser、reasoning parser、OpenAI-compatible function calling 并不是完全分裂的能力线。它们在工程上经常一起出现，因为模型输出一旦既包含中间推理、又包含工具调用，再加上多轮工具结果回填，系统就必须同时处理“怎么解释输出”和“怎么让后续轮次继续成立”。

也就是说，这一章的重点不是多列几个 parser 名字，而是让读者理解：结构化生成在真实系统里常常不是单轮结束，而是多轮往返。

一个最小回路#

用户请求
  -> 模型输出 reasoning / tool call
    -> parser 解释工具调用
      -> 外部系统执行工具
        -> tool result 回填
          -> 模型继续生成最终答案

这个回路看起来简单，但它已经说明一件关键事实：结构化生成一旦进入多轮交互，系统就不再只是在“约束一次输出”，而是在维护一条可持续推进的工具对话链。

为什么这层很容易出问题#

这类回路最脆弱的地方，往往不是某个单点函数，而是轮次之间的契约。如果 parser 对输出的解释和下游工具接口不一致，或者 tool result 回填方式与模型预期不匹配，系统就会出现“第一轮看起来正常、第二轮就不对”的问题。

这也是为什么好技术书需要把它单独写出来。因为如果只讲一次结构化结果，读者很容易低估“多轮保持一致”这件事的复杂度。

本章对应哪些代码路径#

这一章最重要的锚点包括 docs/advanced_features/tool_parser.ipynb、与 reasoning parser 相关的 basic usage 文档、python/sglang/srt/function_call/function_call_parser.py、python/sglang/srt/function_call/base_format_detector.py 以及 OpenAI-compatible function calling 的测试路径。

小结#

结构化生成在真实系统里往往不是单轮能力，而是多轮结果回路。把这一层补进来之后，这一整个 section 才更接近一本完整技术书会给出的能力全貌。