2026 年 5 款 LLM 结构化输出工具推荐：BAML、Instructor 与 PydanticAI 怎么选？

想把提示词与类型定义维护成函数，可以先看 BAML；已有 Pydantic 数据模型，想增加抽取、校验和重试，比较 Instructor；需要完整的 Python Agent 工作流，看 PydanticAI；希望控制支持后端的生成结构，比较 Outlines 与 Guidance。它们工作的层次不同，可以按需求组合。

资料核对日期为 2026 年 10 月 14 日。排序按使用场景组织，没有统一模型、硬件或样本集的准确率和延迟测试。

先区分三种成功

格式成功：返回内容能被解析为要求的数据结构。

规则成功：字段满足长度、范围、枚举或跨字段规则。

事实成功：字段确实来自正确资料，含义没有被误解。

例如一个合法的日期字符串可能引用了会议日期，却被填入上线日期。即使 schema 校验通过，业务仍可能失败。选择工具时，应同时检查错误如何被发现、记录和交给人工处理。

五款工具速览

工具	主要工作层次	优先考虑的场景	需要另外补齐
BAML	类型化函数、提示词与工具链	团队维护抽取函数和多语言调用接口	版本固定、事实核对、发布流程
Instructor	抽取调用与模型校验库	以现有 Pydantic schema 组织抽取	来源验证、重试预算、任务管理
PydanticAI	Python Agent 框架	工具调用、依赖、历史与类型输出	业务权限、效果评估、持久化设计
Outlines	结构化生成接口	使用支持的后端约束输出结构	后端兼容、语义检查、模型资源
Guidance	Python 生成控制与约束	组合程序逻辑、提示词与约束生成	后端选择、业务核验、部署管理

后两项的能力与所选后端有关。云 API、服务器推理与本地解码可能走不同路径，不应从一个演示推断所有 provider 都能提供相同约束。

1. BAML：适合把抽取能力维护成类型化函数

BAML 的 SDK 文档将工作流组织为 .baml 定义、客户端生成和应用调用，适合团队把输出类型与提示词一起审查。修改接口后，生成代码能够让调用方看到类型变化。官方介绍、客户端生成

推荐场景：抽取逻辑将被多个调用方复用，团队希望集中维护函数签名、提示词、测试样本和模型配置。

采用前检查：当前官网提示 BAML 1.0 即将 GA，旧 SDK 文档与新工具链的安装、命令和语法需要按版本区分。本文配套教程固定使用 v0 SDK 0.226.2，不把它描述为新的 1.0 示例。官网、SDK 版本信息

解析得到一个类型实例之后，仍应检查来源和事实。测试集应包含缺少字段、互相冲突、长文截断与来源中夹杂指令等情况。厂商的成功率宣传不等于你的文档分布下的效果。

费用与许可：开源软件免费，采用 Apache-2.0；模型与运行资源另计。当前价格页没有公开可采用的云套餐金额。价格、仓库

继续阅读：BAML 工具页。

2. Instructor：适合围绕已有 schema 做抽取

Instructor 提供结构化抽取、验证和重试路径。Python 入口围绕 Pydantic 模型组织字段与校验，适合已有 Python 数据模型的应用逐步接入。官方文档、验证说明

推荐场景：文档或文本抽取目标明确，希望保留现有 Python 校验规则，并减少自己编写响应解析的工作。

采用前检查：校验反馈可能触发再次调用，应为格式失败、业务失败和网络失败设置有区别的策略。反复请求同一个模型，不保证能找到正确事实，还可能增加费用和延迟。重试说明

把 schema 定义、来源检查与错误记录保留在应用层，方便观察真实失败。别让“无法抽取”被一个自动补全的默认值掩盖。

费用与许可：库采用 MIT；模型请求与部署按实际资源计费。官方仓库

继续阅读：BAML vs Instructor。

3. PydanticAI：适合抽取之外还有 Agent 工作流

PydanticAI 提供类型输出、工具调用和依赖等 Agent 能力。结构化输出是整体工作流中的一部分，适合模型还需要获取数据、调用工具或维护运行上下文的场景。官方概览、输出类型

推荐场景：Python 应用需要在同一个 Agent 流程中结合数据获取、工具执行和结果校验。

采用前检查：输出 schema 不等于工具权限。是否能读取某个客户文档、更新记录或发送通知，仍需应用根据当前用户身份判断。模型参数不能作为权限依据。

使用工具时，分别记录计划、审批、执行与结果。对外部写入，定义业务幂等键和可恢复状态；不要把模型重新生成相同参数视为安全重试的证明。

费用与许可：开源框架采用 MIT；模型 API、部署及可选托管服务另计。仓库

继续阅读：BAML vs PydanticAI。

4. Outlines：适合比较支持后端的结构化生成

Outlines 提供类型、JSON schema、枚举、正则与语法相关的结构化生成接口，并列出本地模型、推理服务与 API 的集成方式。具体实现能力应按后端检查。官方仓库与示例

推荐场景：团队希望研究生成时的输出约束，或已有支持的本地、服务端推理环境。

采用前检查：确认自己的后端支持所需约束，了解无法满足语法或输出长度不足时的结果。复杂 schema 可能增加集成与运行成本，应测量而不是假设它必然更快。

费用与许可：开源项目采用 Apache-2.0；本地设备、GPU 服务、模型 API 与企业产品费用分别核算。

5. Guidance：适合把程序逻辑与生成控制结合

Guidance 在 Python 中组合程序控制与模型生成，支持的后端可使用正则、语法或结构化约束。它更适合需要逐段控制生成流程的开发者。官方项目、文档入口

推荐场景：希望使用条件、循环和生成片段组织输出，并愿意验证相应模型后端的能力。

采用前检查：程序分支应基于可信业务条件，模型输出仍需验证。严格格式可以减少某些格式错误，但不能证明生成内容与原文一致。

费用与许可：项目采用 MIT；模型与推理资源另计。使用本地后端时，另外核对权重许可和设备要求。

如何做一个有意义的选型实验

先固定一个任务，例如从项目记录中抽取名称、负责人和日期。准备人工确认的样本，覆盖：字段缺失、相似字段、多个日期、冲突记录和超长文本。

用相同来源与相同字段规则比较候选工具。记录每份文档的模型、版本、提示词、schema、重试次数、耗时和资源费用。至少统计：

1. 类型与格式通过率。
2. 字段与来源证据匹配率。
3. 经过人工核对的事实正确率。
4. 缺失与冲突信息的处理情况。
5. 每份通过验收的文档成本。
6. 故障是否能回放与交接。

失败请求也计入分母。如果只统计解析成功的样本，结果会忽略最需要解决的失败部分。

成本、隐私与上线边界

除了模型 token，还要记录重试、OCR、日志、存储和人工复核成本。切换 fallback provider 可能改变数据去向、输出规则与价格，应由配置和审批流程控制。

文档中可能包含个人信息或业务机密。检查模型供应商、调试日志、编辑器代理和观测服务的输入范围与保存期限。公开样本集只应包含允许分享的数据。

上线前设定错误处理与回滚方式。流式显示的部分对象适合预览，写入业务系统前应取得最终结果并完成规则与来源检查。

推荐的起步顺序

先按团队已有的代码栈挑选入口，再用小样本验证具体任务。需要函数与类型工作流，看 BAML；希望沿用 Pydantic 抽取模型，看 Instructor；需要 Agent 工具与上下文，看 PydanticAI；已有推理后端并想控制生成约束，比较 Outlines 与 Guidance。配套 文档抽取与事实校验教程 可以帮助建立独立于工具的来源验收步骤。