接到一个要让模型自己查数据、下单、发邮件的活，你大概会卡在第一步：是走函数调用（tools/function call），还是干脆在提示词里写好格式让模型吐 JSON 自己解析？两条路都能跑通，但出错率、调试难度和后期维护完全不一样。这篇不重复协议和客户端怎么配，只讲工程上怎么选、怎么兜底、怎么测。
接到一个要让模型自己查数据、下单、发邮件的活，第一步通常会卡在工具怎么调。走函数调用（tools / function call），把工具名、用途、参数结构交给接口，由模型输出结构化的调用意图，你的代码负责真正执行；走提示词驱动，在系统提示里约定好格式，让模型吐一段 JSON，你自己切分解析再执行。两条路都能跑通，但出错率、调试难度和后期维护完全不是一回事。
这篇不重复协议怎么配、客户端怎么接，只讲工程上怎么选、怎么兜底、怎么测。下面的对照表和排查顺序可以直接拿去当评审清单用，但所有阈值和指标都得按你自己项目的实际数据来定，不要照抄别人的结论。
两条路各是什么样，先分清边界
函数调用的本质是把工具的参数结构提前交给模型，模型不返回自然语言，而是返回一个结构化意图，执行权始终在你手里，所以参数可以逐字段校验。提示词驱动是把格式约束写在提示里，模型返回一段文本，你得先做字符串处理再执行，灵活性高但可控性全靠约束写法。
判断只看一件事：这套工具的参数是固定结构还是花样百出。参数字段稳定、值域明确的，优先函数调用；参数是自由文本、规则天天变的，比如让模型从一段投诉里自己抽字段，提示词那条路反而更省事。如果模型或中转通道不支持标准工具字段，硬套函数调用会一直解析失败，这时候先回退到提示词方案，别跟接口死磕。
- 参数固定、类型明确的工具，走函数调用，参数校验能直接拦住大部分低级错误
- 参数是自由文本、字段随业务变形的工具，先用提示词跑通，别急着抽象成 schema
- 工具数量多的时候，函数调用要先裁剪工具清单，别一次把几十个工具全塞进上下文
- 关键链路工具走函数调用，边角工具用提示词兜底，两条路并存是常态不是妥协
选型对照：四个维度挨个过一遍
| 维度 | 更适合函数调用 | 更适合提示词驱动 |
|---|---|---|
| 参数复杂度 | 字段少、类型明确、值域固定 | 嵌套深、随业务变形、需要模型自己归纳 |
| 稳定性要求 | 长期无人值守、需要参数级校验 | 一次性脚本、内部小工具、人工盯着跑 |
| 模型与通道能力 | 通道完整保留工具相关字段 | 通道会吃掉或改写工具字段 |
| 调试成本 | 报错能定位到具体字段 | 报错要翻整段输出，定位靠人工 |
通道能力这一项最容易被忽略。不同中转对工具字段的保留程度不一样，接之前到 /openai-format-endpoints 核对该端点保不保留工具相关字段，别等联调当天才发现调用意图被吃掉了。调试成本则要落到人头上：想清楚团队里谁去接这个锅，是写工具代码的人还是调提示词的人。
一句话结论：核心链路选函数调用，实验性工具先用提示词跑通再决定要不要转。不适用的情况是团队里没人能维护 schema，那还不如先把提示词方案写扎实，等工具边界稳定了再迁移。
踩坑后的排查顺序
工具调用出问题，最忌讳一上来就怀疑自己的解析代码。先把原始返回整段打进日志，确认模型到底有没有输出工具调用意图，再往下查。
- 确认意图是否产生日志里看原始返回有没有工具调用结构；没有就说明是提示或通道的问题，有才继续往下查参数。
- 参数报错分类查按类型不符、多包一层、必填缺失三类看。外层包裹问题通常是把整段参数又塞进了一个字段，把结构还原即可。
- 提示词方案查解析看返回里有没有多余说明文字、代码块标记，再决定是用截取还是换更严格的约束写法，别硬写正则去博傻。
- 查上下文挤压长对话里工具说明被挤掉也会导致不调用，这种情况要缩减工具数量或精简描述，而不是改执行代码。
排查顺序反了会很浪费时间：先查代码，结果问题根本在提示或通道，改了半天没用。不适用的情况是模型本身在灰度或异常期，这时候任何排查都可能白做，先换通道验证一轮。
超时、并发、降级、日志：上线前必须定好的四件事
工具调用上线后最容易出事的地方不在模型，而在运行时的兜底。下面四件事建议在评审时逐条确认，缺一条都可能变成线上事故。
- 超时
- 工具执行超时和模型请求超时分开设，工具卡住不要拖死整轮对话，超时后给模型一条可读的失败信息
- 并发
- 同一轮里模型可能要求调多个工具，并发上限、失败重投和退避节奏提前定，别让限流把整条链路打挂
- 降级
- 函数调用通道不可用时切提示词方案或返回预设文案，切换阈值写进配置，别硬编码在代码里
- 日志
- 至少记工具名、入参、返回摘要、耗时、是否命中降级，事后复盘靠的就是这几个字段
日志字段别贪多，记多了没人看。真正排障时高频用的就是上面这几个，尤其是「是否命中降级」这一项，能帮你快速区分是模型问题还是通道问题。如果要做成本相关的监控，具体口径到 /price-watch 核对当时的数字，别凭记忆估。
怎么验证改动没把工具调用改坏
改完提示词或工具描述，不能凭一次对话感受就上线。准备一组固定用例，覆盖正常调用、参数缺失、工具执行失败三种情况，改完就跑一遍，看调用成功率和参数正确率这两个指标。
- 用例要覆盖正常调用、参数缺失、工具执行失败三类，缺一类都可能漏掉回归
- 对比看的是调用成功率和参数正确率，不是回答好不好听，两者别混在一个指标里
- 同一组用例至少跑几轮再看趋势，单次结果波动大，下结论太早
- 工具描述大改后先把用例同步更新，用例没更新时别拿这组分数下判断
指标的具体检测口径可以去 /tools/quality-check 看当时的说明，各家统计方式不一样，口径不统一就横向比较没有意义。不适用的场景是工具描述刚大改、用例还没同步，这时候先修用例再谈分数。
下一步如果你正在挑中转通道，建议先到 /sites 看真实可用的站点清单，再到 /tools/speed-test 实测工具字段的保留情况，最后用 /openai-format-endpoints 核对端点的字段兼容性，避免选型选了却跑不通。→常见问题
函数调用和提示词驱动，哪个更省钱？
两者单次请求的输入输出长度差不多，成本差别主要在失败重试上。函数调用解析失败重试率通常更低，变相省钱；提示词方案偶发解析失败时，你可能要整段重发。具体单价到 /official-api 和 /tools/model-cost-calculator 按当时数字算。
模型不老实按格式调工具，该怎么改？
先别改代码，按顺序看三件事：工具描述是不是含混、参数说明有没有写清取值范围、同一轮给的工具是不是太多。把工具数量压下来、描述写具体，通常比调温度更管用。确认模型和通道保留工具字段，可以到 /openai-format-endpoints 核对。
中转站会不会把工具调用字段吃掉？
有这个可能，不同通道对工具字段的保留程度不一样。接之前拿一个最简单的工具跑一次冒烟测试，看返回里有没有结构化的调用意图；测速和连通性可以用 /tools/verify 和 /tools/speed-test 先量一遍。
