1.1 大模型结构化输出的现实需求
我第一次认真思考"结构化输出"这件事，是在一个挺尴尬的场景里。当时我负责一个自动化工单分类的小项目，模型本来输出得好好的，跑了两天突然开始返回一段带解释文字的 JSON——前面加了一句"好的，这是您需要的格式"，后面还多了一个感叹号。下游的解析器直接崩了，整条流水线停了快两个小时。那次之后我才意识到，大模型能写字，和它能稳定地写"某一种格式的字"，完全是两码事。
这两年大模型被塞进了越来越多的生产系统里。信息抽取、接口调用、数据标注、报表生成、Agent 的工具参数传递——这些场景有个共同点：下游系统不认识自然语言，它只认识结构。你给数据库一段散文，它没法用；你给调度器一段带客套话的 JSON，它也解析不了。我们真正需要的是让模型像一个可靠的 API，输入一段内容，输出一个能直接被程序消费的结构。
语言模型天生是自由生成的机器。它按概率一个个往外吐 token，只要句子读得通顺，它就觉得自己完成任务了。可工程世界要的不是通顺，是合规。这个落差就是结构化输出这件事所有麻烦的起点，也是我后来愿意花时间去研究 Outlines 这类工具的直接原因。
1.2 自由生成的主要风险：格式漂移、字段缺失与无效 JSON
用得越久，踩的坑越具体。我把这些坑归了三类，基本覆盖了大多数线上事故。
格式漂移是最常见的一种。你要求它输出 JSON，它前几次乖乖输出 JSON，跑到第一百次的时候突然给你包一层 markdown 代码块，或者把某个字段名从 user_id 写成 userId。模型没觉得自己在犯错，它只是在做概率采样。温度高一点、上下文长一点、上游 prompt 改动一点，漂移就会出现。这种事在 demo 里几乎看不到，在流量大起来之后天天见。
字段缺失和无效 JSON 属于另一类问题。特别是在字段多、嵌套深的时候，模型很容易漏掉一两个必填项，或者在字符串里放没转义的双引号，直接把 JSON 弄成非法格式。后处理校验能拦住它们，但拦不住的成本是重试。重试一次就多一次延迟，多一次 token 消耗，多一次让用户等待的机会。有些团队干脆写正则去"修补"模型的输出，修到最后代码比业务逻辑还长，维护起来非常痛苦。
还有一种容易被忽略的情况：模型输出了一个语法完全合法的 JSON，但里面的值完全跑偏。枚举字段给了个表外值，数值字段塞了字符串，日期格式七拼八凑。这时候解析器不报错，错误一路流到下游，等发现的时候已经很难追溯源头了。格式合规只是第一层，语义合规是第二层，两层都得管。
1.3 Outlines 的定位与核心价值
我最初以为 Outlines 是个提示词模板库，翻完文档才发现想错了。它做的事情比模板激进得多——它直接在模型解码的那一步动手，把不可能符合约束的 token 提前屏蔽掉。模型根本没机会生成非法内容，因为非法 token 在采样阶段概率就被清零了。
这个思路对我冲击挺大的。之前所有对抗格式漂移的办法，本质上都是"事后补救"：提示词写得再细、校验再严、重试再多次，模型该犯错还是会犯错，我们只是在错误发生后兜住它。Outlines 把战场前移到了生成过程中，属于"事前预防"。两种思路的工程成本完全不在一个量级上。
我更看重的是它把约束这件事变成了可编译的产物。JSON Schema、正则、语法，这些东西进去，出来是一个有限状态机或者索引结构，可以预先构建、可以缓存、可以跨请求复用。这意味着约束本身不是每次请求都要重新解释的负担，而是一个可以优化的工程对象。对于需要稳定输出结构的生产系统来说,这一点比"少写几句提示词"重要得多。
当然我也得说句实在话：Outlines 不是万能解药。它解决的是格式层面的确定性，不解决内容正确性。模型该胡诌还是会胡诌，只不过它胡诌的内容会被塞进一个合法漂亮的结构里。这一点在后面的章节我会反复强调，因为很多人的期待一开始就放错了位置。
1.4 全文路线图与阅读建议
接下来的内容我打算按"是什么—怎么做到—怎么用—怎么用好"的顺序展开，尽量少讲空概念，多讲能跑起来的东西。
前半部分偏原理。会先讲清楚受约束文本生成的基础概念，token、词表、前缀、有限状态机这些词在 Outlines 的语境里具体指什么，它和提示词约束、后处理校验、微调这些常见方案各自适合什么场景。然后是解码层面的实现细节——logits 怎么过滤、状态机怎么屏蔽非法 token、JSON Schema 怎么被转换成语法约束。这部分读起来会有点硬，但理解了之后，后面遇到各种奇怪的报错你会知道该往哪看。
后半部分偏实操和落地。会从装环境开始，一步步做 JSON Schema 的结构化输出教程，包括嵌套对象、数组、Pydantic 集成、常见错误排查，再到信息抽取、函数调用、多轮对话这些典型场景的扩展实践。最后一章聊评估指标、约束设计的最佳实践和落地风险。我建议如果你是急着上手的工程师，可以先把第 4 章的教程跑通，回头再补第 3 章的原理；如果你在做技术选型或者架构设计，第 2 章和最后一章值得先读。中间的原理部分什么时候读都行，但别跳过。 import outlines from pydantic import BaseModel
class User(BaseModel):
name: str
age: int
model = outlines.from_transformers("Qwen/Qwen2.5-1.5B-Instruct") result = model("提取用户信息：张三，28岁", User)
state = index.initial_state() outputids = [] for in range(max_tokens):
logits = model.next_token_logits(output_ids)
allowed = index.allowed_tokens(state)
logits[~allowed] = -float("inf")
token = sample(logits, temperature=0.0)
if token == eos_id:
break
output_ids.append(token)
state = index.transition(state, token)
text = tokenizer.decode(output_ids) result = schema.parse_raw(text)
python -m venv .venv source .venv/bin/activate pip install outlines
5.1 信息抽取与表单填写
信息抽取是我最早把 Outlines 用出感觉的场景。业务侧经常扔过来一堆非结构化的东西——工单描述、邮件正文、客服聊天记录——要求从里面抠出十几个字段落库。以前的做法是写正则，写规则，写提示词，写完之后再套一层校验，一层套一层，维护起来像在拆炸弹。用约束解码之后，schema 就是唯一的事实来源，模型怎么生成的不用操心，能解析出来就说明结构是对的。
我拿工单场景举过例子。工单文本里混杂着设备型号、故障现象、报修人、联系电话、期望上门时间，每个字段的格式都不一样。把这些字段定义成一个嵌套的 Pydantic 模型，枚举字段用 Literal 收死，时间字段用正则约束格式，然后直接给模型灌原文。这里有个细节：别指望模型从几百字的混乱文本里精准定位每个字段，prompt 里要把“哪些字段如果没有就留空”说清楚，否则模型会强答，给你编一个电话出来。我一般会在 schema 里把非必填字段设成可空类型，允许输出 null，同时在 prompt 里明确“找不到就填 null”。
表单填写是抽取的反向操作，输入是结构化的键值对，输出是一段填好的表单 JSON。这个场景看起来简单，实际上坑不少。比如地址字段，用户填的是“朝阳区望京SOHO”，但表单要求省市区三级拆分，模型得自己做归一化。我的做法是在 schema 里把三级字段都定义好，然后用一个前置的提示词加少量示例，让模型知道怎么拆。约束层保证拆出来的结构一定是三个字符串字段，至于拆得对不对，得靠示例质量和字段设计来兜。我试过在 schema 里给每个字段加 description 写格式要求，效果一般，后来发现把格式说明放进 prompt 正文比放进 schema 更有效，模型对自然语言指令的响应明显好于对 schema 注释的响应。
还有一个容易被低估的点是批量抽取时的稳定性。单条测试的时候十条里十条都对，一上量到几千条就开始冒出零星失败。排查下来多半是输入长度的问题——有的工单正文特别长，把关键信息挤到了模型注意力边缘。我现在的处理方式是在送进模型之前先用规则做一次截断或者分段，把明显无关的寒暄、签名、历史回复砍掉，保留核心段落。这个预处理不需要多精确，能砍掉一半噪音，抽取成功率就有肉眼可见的提升。
5.2 函数调用与工具参数生成
函数调用本质上就是受约束的结构化生成，只是输出的目标从“给人看的数据”变成了“给机器执行的指令”。工具的参数定义天然适合写成 JSON Schema，每个参数的类型、枚举、范围都是明确的，这跟 Outlines 的能力正好对上。我做过一个内部工具集，十几个函数，每个函数的参数模型单独定义，模型根据用户的话判断该调哪个函数、参数怎么填。
这里的关键设计不在生成环节，在 schema 设计上。函数参数里经常有“二选一”的情况，比如查询接口要么按 ID 查要么按名称查，不能两个都传。JSON Schema 的 oneOf 能表达这个约束，但编译出来状态数会涨，生成速度会掉。我后来改了个思路：把两个参数都设成可空，在函数执行入口做互斥校验，schema 层只管类型和格式。这样约束编译快，模型生成稳，互斥逻辑放在代码里反而更清晰。这个取舍我纠结过一阵，最后发现大多数工具的参数互斥关系都不复杂，放在业务层校验的成本远低于让约束系统去处理。
工具选择本身也是一个可以约束的点。如果工具集不大，十来个函数，可以把函数名做成一个枚举字段，先让模型输出函数名，再根据函数名切换到对应的参数 schema 做第二轮生成。两轮生成听起来慢，实际比一轮里塞一个大 anyOf 要快，因为每一轮的约束状态都简单很多。我拿两种方案对比过，两轮方案的总延迟反而低，而且出错的时候好排查——至少知道是选错了工具还是参数填错了。
参数里的自由文本字段是另一个需要注意的地方。比如“查询条件”这种字段，类型是 string，约束层只能保证它是个字符串，内容对不对管不了。我一般会把这类字段在 prompt 里给一两个示例，同时在下游执行前加一道轻量校验，比如长度限制、关键词黑名单。别小看这一步，模型有时候会把整句用户原话塞进查询条件里，带着“帮我查一下”这种前缀，直接拼到 SQL 或者 API 里就出问题了。约束解码解决的是格式问题，语义和安全性还是得靠应用层自己兜。
5.3 多轮对话中的状态化结构化输出
多轮对话里做结构化输出，难点不在单轮，在轮与轮之间的状态怎么保持。用户在第三轮说“改成明天下午”，模型得知道改的是第二轮里确认的那个预约时间字段，而不是随便生成一个新对象。我一开始的做法是每轮都把完整对话历史塞进去，让模型自己从历史里推断当前状态，跑一段时间发现不稳定，尤其是对话长了之后，模型会忘记前面确认过的字段。
后来改成状态化的做法：维护一个当前的结构化状态对象，每轮只让模型输出“变更部分”，然后应用层把这个变更合并到主状态里。schema 定义成一个 patch 结构，字段全部可选，模型只填这轮改动的字段。这个思路借鉴了增量更新的概念，实现起来不复杂，效果提升很明显。合并逻辑放在代码里，哪些字段允许改、改了之后要不要触发副作用，都是确定性代码在处理，比让模型全权决定靠谱得多。
状态对象本身也要设计好。我的习惯是把它拆成两层：一层是业务数据，比如预约时间、联系人、地址；另一层是对话控制信息，比如当前进行到哪一步、还缺哪些必填项。控制信息不进模型上下文，只在应用层用，用来决定下一轮该问什么。这样模型每轮看到的上下文是干净的，只有业务数据和最近几轮对话，不会因为控制字段变多而稀释注意力。这个拆分是我踩了几次“模型开始胡言乱语”的坑之后总结出来的，上下文里无关字段一多，生成质量就往下掉。
还有一个实践上的小技巧：每轮生成完之后做一个一致性检查，把新状态和旧状态对比，如果某个字段被改成了明显不合理的值（比如时间倒流、枚举值跳变），就回滚到上一轮状态并重新生成一次。这个检查不需要很复杂，几条规则就够用。我加了这个机制之后，多轮场景下的状态错乱率降了大半，用户感知到的就是“这个助手记得住事”。
5.4 代码生成与配置生成
代码生成用约束解码，思路跟 JSON 不一样，但收益类似。生成 SQL 是我用得最多的场景，业务人员用自然语言描述查询需求，模型输出 SQL，约束层保证语法结构合法。Outlines 支持正则和语法级别的约束，SQL 的语法可以用 EBNF 描述，编译成状态机之后模型只能在合法语法路径上走。这个做法比纯提示词稳得多，纯提示词生成的 SQL 经常在括号、引号、关键字大小写上出问题，一报错就得重来。
不过语法约束有个代价：状态数爆炸。完整的 SQL 语法太复杂，编译时间能到几十秒，生成速度也慢。我的做法是做一层语法裁剪，只支持 SELECT 语句，不支持子查询和窗口函数，把语法树砍到业务实际需要的子集。裁剪之后的语法编译只要几百毫秒，覆盖了八成以上的查询需求，剩下两成交给人写。这个取舍很现实，追求全覆盖的代价是系统变得又慢又难维护，不如把常见路径做扎实。
配置生成是另一个我常用的方向。比如生成 Nginx 配置、Docker Compose 文件、CI 流水线 YAML，这些东西格式严格，字段多，手写容易漏。用 YAML 的语法做约束，模型生成出来的东西直接能过 yaml.safe_load，省掉了来回改格式的时间。我做过一个内部工具，输入是“部署一个带 Redis 的 Python 服务”，输出是完整的 compose 文件，字段用 Pydantic 模型约束，生成完直接写盘，开发同学用了之后反馈说比自己手写快，还不容易忘配健康检查。
代码生成这块有个边界要清楚：约束保证的是语法合法，不是逻辑正确。生成的 SQL 可能语法没问题但查错了表，生成的配置可能格式对但端口冲突。我的习惯是生成之后跑一遍轻量验证，SQL 用 EXPLAIN 过一下，配置文件用对应的 linter 检查，过不了的打回重生成或者转人工。这套流程跑下来，真正需要人工介入的比例能压到很低，大部分生成结果一次就能用。
5.5 与 RAG、Agent、工作流引擎结合
Outlines 跟 RAG 结合，最直接的用法是约束检索结果的输出格式。RAG 的生成环节经常要输出“答案 + 引用来源”这种结构，引用来源是一个列表，每条包含文档 ID、片段、相关度。这个结构用 schema 约束住，下游做引用高亮、溯源展示的时候就不用做容错解析了。我做过一个知识库问答，以前引用格式经常飘，有的带 ID 有的不带，前端得写一堆兼容逻辑，换成约束生成之后前端代码直接删了一半。
更深一层的结合是在检索环节。让模型输出检索 query 的时候用约束，把 query 拆成“关键词列表 + 过滤条件”的结构，过滤条件里时间范围、文档类型都是枚举，这样检索层拿到的是结构化参数，不用再解析自然语言。这个改动让检索的召回率提了不少，因为过滤条件终于能精确生效了，以前模型在 query 里写“最近三个月的文档”，检索层只能当关键词处理，现在能转成真正的时间过滤。
Agent 场景里，Outlines 最适合管的是“决策输出”这个环节。Agent 每一步要做的事无非是选工具、填参数、判断是否结束，这三件事都可以定义成 schema。我搭过一个小的任务型 Agent，每一步的输出结构固定为 {action, tool_name, tool_args, reasoning}，action 是枚举（调用工具 / 继续思考 / 结束），tool_args 根据 tool_name 动态切换 schema。跑起来之后整个流程的可预测性好了很多，不会出现模型输出一段自由文本然后解析器崩溃的情况。
工作流引擎那边的结合点在于节点之间的数据传递。工作流里每个节点有明确的输入输出契约，把契约写成 schema，节点内部用约束生成，节点之间的数据就永远是合法的。我用过一套基于状态机的工作流框架，每个状态的输出都要过 schema 校验，以前校验失败得回退重跑，接入约束生成之后失败率降到了几乎为零。这个收益在长流程里特别明显，一个十步的流程，每步失败率哪怕只有 2%，整体成功率也会掉到八成出头，把每步的失败率压到零，整体就稳了。
5.6 多模型与本地模型部署实践
多模型支持这件事，用起来比想象中简单，但配起来有几个细节要盯。Outlines 对不同后端的适配程度不一样，transformers 和 vLLM 的支持最完整，llama.cpp 和一些 OpenAI 兼容接口的支持要看版本。我现在的项目里同时跑着三种后端：本地 7B 模型走 vLLM 做常驻服务，处理高并发的抽取任务；一个小参数的模型走 transformers 做快速实验；线上主链路调的是 OpenAI 兼容接口，走远程推理。三套后端共用同一份 schema 定义，切换后端只改初始化那几行代码。
本地模型部署这块，我的经验是别在模型选择上过度纠结，先跑通再优化。7B 级别的模型配上约束解码，在结构化输出任务上的表现已经够用了，格式合法性基本是 100%，内容质量取决于模型本身和 prompt 质量。我试过 3B 的模型，简单 schema 没问题，嵌套深一点就开始出空值、出重复字段，这种时候换模型比调 schema 更省事。选模型的判断标准很朴素：拿二十条真实数据测一遍，看字段完整率和语义正确率，哪个模型在这两个指标上稳就用哪个。
vLLM 部署有几个实操细节值得记一下。启动参数里 --max-model-len 要跟 schema 的理论最大输出长度匹配，设小了会在生成中途截断。约束相关的索引是在 CPU 内存里建的，模型加载完之后内存占用会往上跳一截，机器上要留够余量。批量推理的时候，不同 schema 的请求最好分开批，混在一起会因为约束状态切换导致吞吐下降。我一开始把所有请求混在一个批次里跑，吞吐只有理论值的三成，按 schema 分组之后回到了八成以上。
还有一个部署层面的建议：把约束编译结果做缓存。schema 不变的情况下，编译出来的状态机是固定的，没必要每次请求都重新编译。我的做法是在服务启动时把所有用到的 schema 预编译一遍，缓存在内存里，请求进来直接取。这个优化让首 token 延迟从几百毫秒降到了几十毫秒，对于延迟敏感的场景效果立竿见影。缓存 key 用 schema 的哈希加 tokenizer 的版本号，模型或者 tokenizer 升级的时候缓存自动失效，避免出现“换了模型但用的还是旧索引”这种隐蔽 bug。
6.1 评估指标：合法率、字段完整率、语义正确率、延迟与吞吐
评估受约束生成的效果，我踩过一个坑：一开始只盯着“合法率”这一个数看，跑出来 100%，当场就觉得大功告成。上线之后业务方跑过来问，为什么抽取出来的工单里一半的联系电话是空的。我才反应过来，合法率高只说明模型输出的 JSON 能被解析，它给你输出一个空对象也是“合法”的。这件事之后我把评估拆成了四个维度，每个都要单独看数。
合法率是最基础的一层，衡量的是输出能不能过 schema 校验。这个指标在约束解码下基本都接近 100%，除非出现 tokenizer 截断之类的工程问题。字段完整率看的是该填的字段有没有填，我一般按必填字段的填充比例来算，空对象、空字符串、null 都算没填。语义正确率是最难量化的，得靠人工抽样或者拿标注数据比对，我通常抽一百到两百条人工过一遍，看字段值跟原文是否一致。延迟和吞吐是生产视角的指标，P50、P95 的生成耗时加上每秒完成的请求数，这两个数决定这套方案扛不扛得住真实流量。
这几个指标之间经常打架。把 schema 收得紧一点，字段完整率上去了，语义正确率可能掉下来，因为模型被约束得太死，遇到复杂输入就直接给默认值。枚举收敛得狠一点，合法率稳了，覆盖的场景却变少了。我的做法是先定清楚业务能接受的下限，比如字段完整率不低于 95%，语义正确率不低于 90%，然后在这个约束下去调 schema 和 prompt，别追求单项最优。评估集也要固定下来，每次改动都跑同一批数据，不然数字没法横向对比。
延迟这块有个容易被忽略的点：首 token 延迟和总生成延迟要分开看。约束编译的开销主要体现在首 token 上，如果做了预编译和缓存，首 token 延迟能压下去很多。总生成延迟更多取决于输出长度和 schema 复杂度。我见过有人把全套指标混成一个“平均响应时间”，结果优化了半天不知道优化的是哪一段。分开测，分开优化，心里才有数。
6.2 约束设计最佳实践：Schema 最小化、枚举收敛与分层校验
schema 设计这件事，我的核心原则就一条：能少写就少写。很多人第一次用约束生成，恨不得把整个业务对象的所有字段所有约束都塞进一个 schema 里，结果编译出来状态机巨大，生成速度慢，模型还容易在复杂结构里迷路。我现在习惯把 schema 拆到“刚好够用”的程度，一次生成只解决一个问题，字段数量控制在十个以内，嵌套层级控制在三层以内。需要更多信息就在业务层做多次生成再合并。
枚举收敛是另一个见效快的做法。凡是取值范围有限的字段，全用枚举收死。工单状态、设备类型、优先级、地域编码，这些字段用自由文本生成，模型能给你编出十几种写法，下游根本对不上。枚举一收，模型只能在有限的选项里选，语义正确率肉眼可见地往上走。枚举值本身也有讲究，别用过于相似的选项，比如“高优先级”和“紧急”放一起，模型自己都分不清。尽量用含义清晰、区分度大的值。
分层校验是我在生产里被毒打之后养成的习惯。约束解码保证的是单次输出的结构合法性，它管不了跨字段的一致性，也管不了字段值跟业务规则是否冲突。我的做法是在约束层之上再叠两层：一层是 schema 级校验，用 Pydantic 的 validator 做字段间校验，比如开始时间不能晚于结束时间；另一层是业务级校验，比如订单金额不能为负、用户 ID 必须存在于数据库。三层校验各管一段，成本可控，出问题的时候也能快速定位是哪一层没兜住。
schema 的演进也要有纪律。我见过团队里每个人都往同一个 schema 里加字段，加了之后没人清理，半年之后 schema 膨胀到几百个字段，编译一次要好几秒。我的做法是 schema 也走版本管理，新增字段要说明用途，废弃字段定期清理，复杂场景另起一个新 schema 而不是往老 schema 上叠。这件事听起来像流程负担，实际省下来的维护时间远超过投入。
6.3 生产落地风险：模型差异、版本升级、失败回退与可观测性
把约束生成推进到生产环境，第一个绕不开的问题就是模型差异。同一个 schema，同一个 prompt，换一个模型，输出质量可能差一大截。有的模型对枚举字段理解得好，有的模型在嵌套结构上容易丢字段，有的模型对长输入的处理能力弱。我现在的做法是模型选型跑一个标准测试集，把几个候选模型在同一批数据上跑一遍，横向对比四个指标，选综合表现最稳的那个，别迷信参数规模。
版本升级是个潜伏期很长的风险。模型升级、tokenizer 升级、Outlines 库升级，任何一个环节变了，原来的约束编译结果可能就不对了。tokenizer 的变化最隐蔽，词表变了之后，之前缓存的 token 索引全部失效，生成出来的东西可能莫名其妙多一个字符或者少一个字符。我的做法是把模型版本、tokenizer 版本、schema 版本的哈希拼在一起做缓存 key，任何一项变了缓存自动失效。升级前一定要在预发环境跑一遍全量评估，别直接上生产。
失败回退机制是保命的。约束生成再稳，也有失败的时候，比如模型输出被截断、schema 编译超时、下游服务抖动。这些情况得有明确的处理路径。我的习惯是设计三级回退：第一级是重试一次，带上更严格的提示；第二级是降级到自由生成加后处理解析；第三级是转人工或者返回一个明确的错误码。每一级回退都要打点，记录触发次数和原因，这些数据是后续优化的依据。
可观测性这块，我重点关注三个维度。生成层面记录每次请求的 schema 名称、耗时、输出长度、是否命中缓存；质量层面记录校验失败的字段和失败类型；业务层面记录下游系统接收成功率和人工介入率。这些指标进监控大盘，设阈值告警。我吃过一次亏，线上某个 schema 的失败率悄悄从 1% 涨到了 8%，没人发现，直到业务方投诉数据缺字段才排查出来。加了告警之后这种事就能提前拦住。
6.4 与 JSON Mode、函数调用、语法约束方案的选型建议
现在市面上做结构化输出的方案不止一种，JSON Mode、各家模型的函数调用能力、语法约束，各有各的适用场景。我的选型逻辑比较朴素：看约束的复杂度。如果只是输出一个扁平对象，字段都是基本类型，JSON Mode 或者函数调用就够用了，接入成本低，不用引额外的库。如果结构复杂，有嵌套、有枚举、有格式要求，语法约束方案的优势就出来了，它能保证结构层面的绝对合法。
JSON Mode 的定位我一直理解为“提高输出 JSON 的概率”，它不保证输出符合你的 schema。模型可能给你一个合法 JSON 但字段名对不上，或者字段类型错了。函数调用比 JSON Mode 强一些，参数 schema 是显式定义的，但不同厂商的实现差异大，有的严格有的宽松。语法约束方案是这三者里最可控的，约束在解码层生效，理论上不可能输出非法结构，代价是多一层依赖，接入复杂度高一些。
选型的时候别只看技术指标，运维成本也要算进去。JSON Mode 和函数调用基本是托管服务，不用自己维护；语法约束方案要么自己部署推理服务，要么接本地模型，运维投入实打实存在。我一般建议团队从小场景开始试，先拿语法约束跑一两个核心场景，验证收益之后再铺开。一上来就全量迁移，出了问题回滚成本很高。
还有一个常被忽略的角度是团队能力。语法约束方案需要有人懂 schema 设计、懂约束编译、懂性能调优，如果团队里没人愿意钻这块，JSON Mode 加严格的后期校验反而是更务实的选择。我见过有团队硬上语法约束，schema 设计得一塌糊涂，编译慢、生成慢、维护难，最后又退回提示词方案。工具是好工具，得看用的人。
6.5 未来趋势：更通用语法约束、编译优化与标准化
往远了看，我觉得语法约束这块最大的趋势是通用化。现在主流方案还是围绕 JSON Schema、正则、上下文无关语法这几种表达能力，未来应该会往更广的格式覆盖走，比如 XML、YAML、Protobuf、甚至一些领域专有格式都能直接约束。这对做多格式输出的团队是好事，一套约束框架管所有格式，不用一个格式接一套工具链。
编译优化是另一个我关注的方向。现在的约束编译在复杂语法下还是偏慢，状态数容易爆炸。业界在往增量编译、按需编译、状态机压缩这些方向走，目标是让复杂语法的编译开销降到可以忽略的程度。如果编译能做到毫秒级，那很多以前因为性能问题不敢用的场景就能打开了，比如动态生成 schema、按请求实时编译。
标准化这件事我持谨慎乐观的态度。现在各家方案在约束的表达方式、编译结果、接口形态上都不统一，换一个库就得重写一遍集成代码。类似的痛点在别的领域也出现过，最后都是靠社区共识慢慢收敛出一套事实标准。我猜未来两三年会在 schema 描述语言和约束编译接口上出现一些通用规范，生态会跟着收敛。在那之前，我自己会尽量把 schema 定义和约束实现解耦，schema 用标准格式写，约束库换的时候改动面小一点。
模型层面的变化也值得一提。现在约束是在解码层做的，未来可能有模型原生支持结构化输出，约束直接内嵌到模型训练里。这种方案的好处是不需要外挂约束引擎，推理速度更快。坏处是灵活性差，schema 变更得重新训练或者微调。短期内我觉得两种方案会并存，外挂约束适合多变场景，原生约束适合固定场景。
6.6 总结与学习路径
把 Outlines 这套东西从看懂到用顺，我走了不少弯路。回头看，最有价值的经验其实是几条很朴素的东西：schema 要小、要收、要分层；评估要多维度、要固定测试集；生产要有回退、要有监控；选型要看场景、看团队。技术细节会变，库会升级，这些原则大概率能撑很久。
学习路径我一般给两个方向。偏应用的，从写一个简单的 Pydantic schema 开始，跑通生成、校验、集成这一条链路，然后逐步加复杂度，枚举、嵌套、联合类型、多轮状态。每一步都拿真实数据测，别用构造的玩具数据。偏底层的，去读约束编译的源码，搞懂状态机怎么从 schema 生成出来、logits 掩码怎么算、tokenizer 对齐怎么处理。这两条路不冲突，先走应用线跑通全流程，再回过头补底层知识，理解会更深。
如果要给一个具体的起步建议，我会说：找一个你手头正在用提示词加后处理解析的场景，把它改成约束生成，跑两周，对比前后两个版本的合法率、完整率、延迟和人工介入率。这个对比会让你对这套方案的价值有非常直观的判断。光看文档和示例感受不到的东西，跑一遍真实流量全明白了。
最后想说，结构化输出这件事没有银弹。约束解码解决的是结构合法性问题，语义正确性、业务合理性、系统稳定性，还是得靠 schema 设计、提示词工程、校验机制和监控体系一起兜。把这套组合拳打顺，受约束文本生成才真正算用到位了。
