结果回路的维护者视角：从 response_format 到 tool result 回填#

这章解决什么问题#

这一整节前面已经分别讲了 schema、parser、API 表面、多轮工具回路和排障入口，但对维护者来说，还差最后一步：怎样把这些分散视角重新压成一条完整的排查路径。换句话说，当结构化结果真的出问题时，如何从 response_format 一路走到 parser，再走到 tool result 回填，而不是在不同 surface 之间来回跳。

一条完整的结果回路检查顺序#

1. 先确认请求表面：frontend / OpenAI-compatible / native / offline engine
2. 再确认约束输入：json_schema / regex / ebnf / response_format 是否正确进入
3. 再确认 parser：function_call / tool parser / reasoning parser 是否按预期解释
4. 再确认 tool roundtrip：工具结果是否按预期回填给模型
5. 最后确认最终答案：结果格式和业务语义是否都成立

这条顺序本身就是整节的总结。前面的章节分别把这些层讲开，而这一章负责把它们重新压成一条可以带去现场排障的工作流。

为什么这一步对“好书标准”很重要#

很多资料会在这里停在“有哪些参数 / 哪些 parser / 哪些 API”。但真正好的系统书会继续往前走一步：告诉读者当所有这些能力叠在一起时，怎样形成一条稳定的维护路径。这正是这一章存在的理由。

本章对应哪些代码路径#

这一章主要回指本节前面已经建立的锚点：python/sglang/srt/sampling/sampling_params.py、python/sglang/lang/api.py、python/sglang/srt/function_call/function_call_parser.py、python/sglang/srt/function_call/base_format_detector.py、docs/advanced_features/structured_outputs.ipynb、docs/advanced_features/tool_parser.ipynb 与相关 function calling 测试路径。

小结#

如果把 structured results 这一整节看作一条链，这一章就是把整条链真正封口的地方。它让前面的能力介绍不再只是“看过就懂一点”，而变成“出问题时知道怎样查”的维护者知识。