一句话定义：tool_choice 是调用大模型 API 时的一个参数，用来规定模型这一轮“能不能调工具、必须调、还是不许调”。这里的“工具”（tool / function calling）指你事先用 JSON Schema 描述好、交给模型的那些外部函数，比如查天气、查订单、改数据库。
为什么需要它。模型每轮其实只有两条路：要么直接输出一段自然语言，要么输出一段结构化的“我要调用某个函数，参数是这些”。前者适合聊天，后者适合让程序接着干活。tool_choice 就是这两条路之间的红绿灯，常见三种取值：
| 取值 | 含义 | 典型场景 |
|---|---|---|
auto | 模型自己判断调不调、调哪个、调几个 | 通用助手、开放对话 |
required（部分厂商叫 any） | 本轮必须至少发起一次工具调用，不许只回文本 | 结构化抽取、意图路由、agent 中间步骤 |
none | 本轮禁止调用任何工具，只能出文本 | 收尾总结、工具维护降级 |
有些平台还支持直接指定某个具体函数名，等于“这一轮就调用它，别挑”。
打个比方：你进餐厅，服务员递上菜单（这就是 tools 参数，告诉你有哪些菜）。auto 是“您看着点，需要就叫我”；required 是“必须下单，不能空手走”；none 是“今天后厨歇了，只能陪聊”。菜单和“点不点”是两件事，tools 决定有什么可选，tool_choice 决定这一轮允不允许选。
和相邻概念的区别：temperature 管的是输出随机性，和调不调工具无关；parallel_tool_calls 管的是能不能一次调多个，而 tool_choice 管的是调不调。
什么时候该强制 required：最典型的是结构化抽取。让模型从简历或发票里抽字段，用 auto 时它有时会“好心”地直接用一段话总结，你的解析器就会崩溃；required 保证它一定吐出符合 schema 的参数。其次是意图分类：把“退款 / 查询 / 投诉”做成三个工具，强制选一个，比让它输出自由文本再正则匹配稳得多。再次是多步 agent 里那些“必须产出下一步动作”的环节。
代价也要知道：required 下模型可能为了满足约束硬凑一个不合适的工具，参数乱填。所以前提是任务里真的存在合理可调的工具，并且你要对参数做校验、准备好工具报错后的重试路径。反过来，none 常被忽略但很实用：在 agent 收尾阶段禁掉工具，能避免它再来一轮无谓的往返调用。
各厂商的取值命名和默认行为略有差异，具体以官方文档为准。