tool schema、arguments、strict、tool_choice、parallel tool calls和tool output有什么区别？
直接答案
Tool schema是开发者提供给模型的工具定义；arguments是模型为某次函数调用生成的参数字符串；strict要求生成参数遵循受支持的JSON Schema子集；toolchoice控制模型是否可以、必须或只能调用指定工具；parallel tool calls决定一次
症状、差异与判断依据
直接答案
Tool schema是开发者提供给模型的工具定义；arguments是模型为某次函数调用生成的参数字符串；strict要求生成参数遵循受支持的JSON Schema子集；toolchoice控制模型是否可以、必须或只能调用指定工具；parallel tool calls决定一次响应能否产生多个并行调用；tool output则是应用执行工具后，以对应callid交还给模型的结果。 模型返回function call不代表函数已经执行。应用必须解析并验证arguments、做权限和业务检查、执行实际代码，再回传tool output。把模型生成的参数直接用于付款、删除或命令执行，是典型安全错误。
一、六个概念快速对比
概念 由谁提供 所处阶段 主要作用 ----------- Tool schema 开发者 请求前 告诉模型有哪些工具及参数 arguments 模型 响应中 提议某次调用的输入 strict 开发者 工具定义 约束参数结构 toolchoice 开发者 请求配置 控制是否及如何选工具 parallel tool calls 开发者与模型 调用规划 允许一次输出多个调用 Tool output 应用 执行后 把真实执行结果返回模型 故障排查应先判断失败发生在定义、生成、验证、执行还是结果回传阶段。
二、Tool schema是什么
函数工具定义通常包含名称、描述和parameters。参数使用JSON Schema描述对象、属性、类型、枚举和必填字段。模型根据名称与描述决定何时调用，并依据schema生成arguments。 Schema是生成约束和接口文档，不是应用服务器的授权策略。
三、工具描述为何影响选错函数
模型无法看到函数实现，只能依据名称、描述和参数说明推断用途。两个工具都叫“更新记录”却未说明适用对象，容易产生错误选择。 描述应写明使用时机、不能做什么、重要副作用和参数语义，但不要塞入大量与该工具无关的全局规则。
四、arguments是什么格式
Function call中的arguments通常是JSON字符串，不是已经可信的语言对象。应用需要先按JSON解析，再按schema和业务规则验证。 流式响应中arguments可能以多个delta分片到达。只有arguments done或对应调用完成事件之后，才能把完整字符串交给解析器。
五、JSON合法为何仍可能执行失败
{"amount":-1}可以是合法JSON，却违反金额必须为正的业务规则；一个存在的客户ID也可能属于其他租户。结构正确不代表语义正确或有权限。 服务器必须校验范围、资源归属、当前状态、并发版本和调用者权限。
六、strict做什么
在函数工具上启用strict: true，可让支持的模型按受支持JSON Schema子集生成参数，减少缺字段、类型不匹配和额外属性。 它改善结构可靠性，但不保证外部资源存在、数据最新、调用安全或业务结果成功。
七、strict为何会报schema错误
严格模式只支持JSON Schema的一部分，常见问题是使用不支持关键字、对象未正确声明必填字段，或没有按要求限制额外属性。 遇到请求阶段400时，先检查工具定义本身；若请求成功但本地验证失败，再检查实际arguments和模型支持情况。
八、strict与Structured Outputs相同吗
两者共享按schema约束输出的思想，但用途不同。函数工具的strict约束tool arguments；文本响应中的JSON Schema格式约束模型最终结构化回答。 需要调用内部订单系统时用函数工具；只需要生成一个结构化分析对象时，不必伪造无实际执行的函数。
九、tool_choice有哪些模式
none禁止工具调用并让模型生成普通消息；auto允许模型在回复与工具之间选择；required要求调用一个或多个工具；命名选择则强制具体函数。 不同API版本还可能支持allowed tools，把完整工具集中本轮允许的子集单独限制出来。
十、auto为什么没有调用工具
auto从不保证调用。模型可能认为已有上下文足够、工具描述不匹配，或用户请求不需要外部数据。 若业务流程必须查库，应使用required或指定工具，并在服务端检查响应确实包含预期调用。
十一、required为何可能调用了错误工具
required只保证至少使用工具，不必然指定哪一个。传入多个定义时，模型仍需选择。 若只允许某个动作，应使用命名选择或allowed tools，而不是在提示词里反复要求后仍保留全部高风险工具。
十二、parallel tool calls是什么
启用并行工具调用后，模型一次响应可以产生多个function call。例如同时查询三个城市天气，应用可并行执行后回传各自结果。 这不意味着所有调用都彼此独立，也不意味着应用必须无条件并发执行。
十三、哪些调用不能并行
第二步依赖第一步生成ID、多个操作修改同一资源、或调用顺序影响余额时，不应并行。模型未必知道后端锁和事务约束。 应用应按依赖图和副作用级别调度；必要时关闭并行，或一次只暴露当前可执行工具。
排障步骤与验证
十四、call_id有什么作用
每次function call都有用于关联的callid。应用返回工具结果时必须带对应ID，模型才能知道结果属于哪次调用。 并行场景不能只按数组顺序匹配，因为执行完成顺序可能与生成顺序不同。
十五、item id与call_id为何别混用
Item ID标识响应中的输出项目，callid标识一次工具调用协议关联。二者可能同时出现，但用途不同。 工具输出通常按callid回传。把item ID填入关联字段会导致找不到对应调用或上下文不完整。
十六、tool output是什么
Tool output是应用执行函数后的结果，可是成功数据、业务错误或安全裁剪后的诊断。它会作为后续输入交给模型，供模型生成回答或决定下一步。 结果应简洁、结构稳定，并明确成功与失败。不要把数据库堆栈、密钥或整份内部对象原样送回模型。
十七、工具异常应怎样回传
网络超时、资源不存在和权限拒绝应使用可区分的错误码与安全描述，例如{"ok":false,"code":"NOTFOUND"}。模型据此可向用户解释或选择安全重试。 不要伪造成功输出，也不要把异常吞掉后返回空字符串，否则模型可能误认为操作完成。
十八、为什么会出现缺少tool output错误
应用把含function call的响应继续加入上下文，却没有为每个调用提供匹配结果，API或模型状态机会认为调用链未完成。 检查是否漏处理多个并行调用、异常分支是否跳过回传，以及callid是否保存完整。
十九、重复执行怎样避免
网络重试、流重连或应用崩溃恢复可能再次看到同一调用。对付款、发信和创建订单等副作用，必须使用幂等键或执行账本。 可用会话、响应和callid组合建立唯一记录，并持久化输入哈希、状态与安全裁剪后的结果。
二十、模型能否直接拥有密钥
不应把API密钥放进提示词、schema、arguments或tool output。密钥保存在服务端环境或秘密管理系统，工具执行器根据授权上下文使用。 模型只需要业务参数，不需要知道数据库密码或云凭证。
二十一、参数注入如何防御
Tool arguments来自模型，而模型又可能受到用户文本或外部网页提示注入影响。因此所有参数都按不可信输入处理。 使用允许列表、路径规范化、参数化SQL、固定命令模板和最小权限账户；不要把arguments拼接进shell或查询字符串。
二十二、高风险操作为何需要确认
删除、转账、公开发布和发送外部消息具有不可逆影响。即使schema完全正确，也应在执行前展示对象、金额和接收方，并按产品策略要求用户确认。 工具调用能力不能绕过现有RBAC、审批、CSRF或审计机制。
二十三、流式函数调用怎样组装
按输出项和callid分别缓存arguments delta，保持原始顺序拼接，并在完成事件后只解析一次。不要把不同并行调用的分片写进同一缓冲区。 连接中断时，若没有收到完整完成信号，不应执行半截JSON。
二十四、调试日志应记录什么
记录模型、请求ID、响应ID、工具名、callid、schema版本、参数验证结果、执行耗时、幂等状态和业务错误码。敏感参数应脱敏或完全省略。 不要只记录最终自然语言回复，否则无法定位究竟是模型未调用、参数无效还是后端执行失败。
二十五、完整执行状态机
推荐状态为：调用已生成、arguments已完成、结构校验通过、授权通过、等待确认、执行中、成功或失败、结果已回传。每个状态持久化并允许安全恢复。 只有后端确认成功后，界面才能显示“已完成”；模型一句“操作成功”不是执行证据。
二十六、回归测试清单
测试可选与强制调用、错误工具选择、缺字段、额外字段、非法枚举、超范围数值、多租户越权、并行乱序、部分流中断、工具超时、重复call ID、结果缺失和幂等重试。 同时验证日志无秘密、用户取消不会执行、高风险动作需要确认，且错误信息不会诱导模型虚构成功。
结论
Schema定义接口，arguments承载模型提议，strict约束结构，toolchoice限制选择，parallel tool calls控制一次调用数量，tool output闭合真实执行回路。可靠函数调用必须把模型规划与受控执行分离，并用验证、授权、幂等、确认和审计守住副作用边界。
常见问题
1. strict为true后还需要本地校验吗？
需要。它主要保证结构符合schema，服务器仍要验证权限、资源归属、范围和当前业务状态。
2. 模型返回function call后函数是否已执行？
没有。模型只是提出调用，实际执行由应用完成。
3. tool_choice required能指定某一个函数吗？
它通常要求调用至少一个工具；要固定具体函数，应使用命名工具选择或限制允许工具集合。
4. 并行调用结果可以按返回顺序匹配吗？
不可以依赖顺序。应使用每次调用的`call_id`关联。
5. 工具失败后应返回普通文本还是结构化错误？
优先返回稳定、精简的结构化结果，包含成功标志和安全错误码，便于模型和程序一致处理。