两种"让模型输出结构化数据"的路线
- 路线 A：让模型填表（给它 schema，让它产出 JSON）；
- 路线 B：让模型调用工具（用函数调用/工具调用，参数就是 schema）。
两者都能拿到结构化结果，但适用场景与风险不同。选错的代价通常体现在稳定性和可控性上。
什么时候该"填表"
- 任务是抽取/分类（从这段文本里取出字段），没有副作用；
- 一次要给多个字段（模型能一次看全上下文再决定）；
- 结果要整体校验（字段之间有关联，如起止日期）；
- 希望批处理（一次处理很多条，填表更省往返）。
什么时候该"调工具"
- 需要执行动作（查库、下单、发信），而不只是产出数据；
- 参数之间有先后依赖（先查 ID 再更新）；
- 需要幂等与审计（每次调用是一条可追踪的记录）；
- 需要在执行前做权限校验（工具层能拦住越权）。
一个务实的组合
"填表"负责意图，工具负责落地：
- 让模型填一张"意图表"（动作 + 参数 + 理由）；
- 程序校验意图表（字段、范围、业务规则、权限）；
- 校验通过后，由代码按意图表去调用工具（而不是让模型直接调）。
好处：模型犯错时不会直接产生副作用；校验与审计都在一条链上；重试也更容易做。
三个常见错误
- 让模型直接执行写操作：一旦幻觉出参数，代价是真实的；
- 只校验 JSON 合法性：合法 JSON 也可能是错的业务值（金额为负、ID 不存在）；
- 把工具返回塞回模型再让它填表：容易形成"模型改数据"的链路，越改越偏 —— 数据变换应交给代码。
选型检查清单
- 这个任务是"取数据"还是"做事"？（取→填表；做→工具）
- 参数有没有依赖与幂等要求？
- 出错时的后果可控吗？（不可控 → 加人工确认）
- 有没有更简单的做法？（能用规则/正则解决的，不要上模型）