tool_use 保证结构正确性：合法 JSON、必填字段存在、类型正确。它不保证语义正确性。一个通过 schema 验证的提取结果，可以有加不到总计的行项目、不含 @ 的邮箱、或者开始日期在结束日期之后。
差距在哪
在一条流水线中，tool_use 在生成时捕获了 0 个错误（它通过设计就预防了结构问题）。一个单独的语义验证层在 20% 的提取中发现了逻辑错误：
- 12% 跨字段不一致（加总错误、日期矛盾）
- 5% 值放错字段（author name 出现在 version 字段）
- 3% 编造数据
没有语义验证，这 20% 全部未被发现地流入了下游系统。
两层验证
| 层级 | 捕获什么 | 机制 |
|---|---|---|
| 结构层（tool_use） | 缺失字段、类型错误、JSON 格式错误 | 生成时的 JSON Schema |
| 语义层（应用代码） | 加总不匹配、日期顺序、值放错字段 | 生成后的业务逻辑 |
JSON Schema 表达不了”行项目必须加总等于 total”或”start_date 必须在 end_date 之前”。这些检查需要应用层的验证代码。
虚假的安全感
“schema 通过了，数据就没问题”是错的。通过 schema 的输出在结构上是正确的——在语义上可能完全不通。两层都不可少，它们处理的是根本不同的错误类别。
一句话总结： tool_use 保证的是结构而非含义——加上语义验证（加总检查、日期顺序、跨字段逻辑），因为 20% 通过 schema 验证的提取包含 schema 本身检测不了的逻辑错误。