结构化生成与 API#

这一部分最容易被写歪。因为它同时碰到两类看起来很像、其实职责完全不同的问题：一类是“模型输出怎样被约束和解释”，另一类是“调用方怎样把请求送进系统”。前者属于生成语义，后者属于接口表面。如果把两者混在一起，这一部分就很容易退化成“协议名词 + 功能点”列表，看起来很满，实际却缺少稳定边界。

因此，这一部分真正的写法，不是平铺十几章，而是沿着两条主线往里走：先讲约束怎样进入 generation path，再讲不同 surface 怎样把这些约束和请求语义送进 runtime，最后才讲工具回路、Responses API 和维护视角。

这一部分怎么读#

更稳的读法是把这里的章节压成四组。

第一组：先建立“约束怎样进入生成”的主线#

先读：

这组章节负责回答的是同一个问题：约束不是“生成之后的修补层”，而是从请求进入系统开始，就不断被编译、缓存、等待、推进并最终落到 SamplingParams 和 sampler 边界上的一条执行链。

第二组：再看工具回路怎样长出来#

然后读：

这组章节解释的是：tool workflow 不只是 parser，也不只是 OpenAI-compatible 的一个字段，而是一条包含 tool strategy、解释层、built-in tool、session 和结果回填的完整运行时回路。

第三组：最后再看接口表面#

接着读：

这组章节要回答的不是“有哪些 API”，而是“同一套 runtime 为什么会暴露出几种不同 surface，它们分别替谁解决问题，又在什么边界上复用同一套执行链”。

第四组：把能力重新翻成维护视角#

最后再读：

这组章节的作用，是把这一部分从“功能目录”重新拉回工程动作：怎样设计可消费输出，出了问题先从哪层排查，维护者如何沿着 parser、surface、约束和回填链继续追。

这一部分最该反复抓的对象#

这部分真正贯穿全文的不是章节标题，而是一批跨层对象：

response_format
tool_choice
grammar backend
tool parser
SamplingParams
ResponsesRequest

只要这几个对象的边界稳住了，这一部分就不会再像“接口兼容专题”，而会像全书对“输出语义怎样进入运行时”的一次系统性回扣。

这一部分和前后章节的关系#

这一部分放在 5. 执行模型之后，是因为如果你还没分清 ForwardBatch、sampler 和输出后半段，就很难真正理解“约束插在执行链的哪里”。它又放在 7. 代码导读之前，是因为读者最好先知道结构化生成和不同 surface 的运行时意义，再回源码去看 protocol.py、serving_chat.py、parser、tool server 和 grammar manager 这些树。

也就是说，这一部分的真正作用，是把“对外语义”重新接回“内部执行”。这正是一本系统书和纯产品文档的主要差别之一。