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