如何保证模型提供正确参数并可靠地调用工具？

核心回答

可靠的工具调用需要把工具定义、参数校验、受控执行和结果反馈连成闭环。模型根据上下文提出调用，应用负责验证、执行，并把真实结果交回模型；不能只靠提示词要求模型“调用正确”。

1. 定义清楚：说明工具用途、适用条件、输入字段和返回内容，让模型知道何时该用、需要提供什么。固定参数由程序绑定，减少模型需要推断的内容。
2. 校验参数：生成时使用接口支持的结构约束，执行前再核对类型、必填项、对象、时间和参数来源。凭证、用户身份和权限范围由应用提供与检查。
3. 受控执行：只调用允许的工具，设置超时与调用上限。参数错误要修正或补问；瞬时故障只有在可以安全重试且预算允许时才重试。下单等写操作超时后，先确认状态，或使用服务端支持的幂等机制，避免重复操作。
4. 反馈并确认结果：成功返回真实数据，失败返回具体原因和可采取的下一步，再检查结果是否满足任务。参数生成成功、HTTP 返回成功，都不等于任务完成。

例如用户问“这里明天会下雨吗”，系统却只有即时天气工具，就要先澄清城市，并说明当前工具不提供明天预报；即使生成了合法的北京参数，也还没有回答用户的问题。

用一个天气请求走完四道关

用户问：“这里明天会下雨吗？”假设系统只有 get_weather(loc)，且它只能查询即时天气。

第一道关：工具是否适合这件事。 工具描述应明确写成“查询指定城市的当前天气，不提供未来预报；loc 为城市名，如 Beijing”。模型主要依靠名称、描述和参数定义选择工具，并不会自动读懂函数实现。工具很多时，可以先按当前任务筛选候选，让模型在相关能力里选择。

这个请求既缺城市，又要求明天的预报：即使模型填出 {"loc":"Beijing"}，格式完全合法，调用仍然不符合用户意图。正确做法是先澄清地点，同时说明当前工具不提供明天预报；若系统另有预报工具，再按其要求调用。

第二道关：参数是否有依据。 用户改成“查北京现在的天气”后，城市才有明确来源。参数 Schema 应写清字段类型、必填项和含义；有限选项用枚举表达，按契约限制多余字段。若模型接口支持严格工具参数生成，就在其支持的 Schema 范围内启用约束，减少格式错误；执行端仍要核对业务含义。必填只意味着不能漏字段，不意味着可以猜值：缺少城市时，应补问，而不是随便填一个合法字符串。

在 LangChain 中，可通过工具的 args_schema 绑定 Pydantic 参数模型，在执行前做校验。它与模型提供方的严格生成约束是两层机制，不能因为配置了 args_schema 就假定模型一定输出合规参数。Pydantic 默认可能做类型转换，需要严格类型时应显式设置。城市名通过字符串校验后，同名城市仍可能需要消歧；对位置精度要求较高时，可以先地理编码、确认候选，再用经纬度查询。

同时缩小模型需要决定的范围：天气工具里的摄氏度单位、中文语言和环境中的 API 凭证由代码设置。它们可以不出现在模型可填写的参数里，而不是暴露后再靠提示词禁止修改。业务工具里的登录用户、租户、可操作范围也应来自可信上下文，而不是让模型填写后直接相信。

第三道关：执行是否受控。 应用从允许的工具中分派调用，校验通过后再访问外部服务，并设置单次超时、尝试次数与任务总耗时。关键是区分“请模型改参数”和“由程序重试同一次调用”：

得到的反馈	接下来怎么处理	原因
缺少字段或参数类型错误	回传具体字段和约束，有限次修正；缺信息则补问	原样重试不会让错误参数变正确
城市有多个候选	向用户确认地区	猜一个候选可能查到真实但错误对象的数据
临时超时或限流	只有调用可安全重放且预算允许时才退避重试；尊重服务端等待建议	故障可能恢复，但重试仍有成本和副作用条件
API 凭证无效或权限不足	停止当前调用，由应用处理认证或拒绝越权	让模型换城市不能修复身份问题
返回成功但没有任务需要的温度字段	按不完整结果处理	HTTP 成功不等于满足业务所需

网络重试通常由了解接口语义的执行层负责；模型收到参数校验错误后，可以修正参数再提出调用。两条路径都受预算限制，不能让模型和执行层各自无限重试；同一错误反复出现且没有新信息时，应补问或结束。

第四道关：让反馈真正影响回答。 工具适配层先检查响应是否可用，再回传稳定的结果：成功时包含实际地点、数据时间、单位和天气字段，失败时包含错误类别、具体字段和下一步。比如返回“城市有多个候选，请补充省份”，比一句“调用失败”更能让模型正确补问。没有取得天气数据，就不能生成相应的天气结论；即时天气也不能被转述成明天预报。

在 LangChain 的通用工具调用消息流中，应保留模型发出的调用消息，再用 ToolMessage.tool_call_id 把执行结果关联回原请求。如果同一轮并行查询北京和上海，上海先返回，不能把第一个结果直接配给第一个请求。应用要按调用 ID 关联结果，保留对应的工具名和参数；成功与失败也分别反馈。否则两个请求的参数都正确，模型最后仍可能把上海的天气当成北京的天气。

运行时还应记录工具名、脱敏后的参数、校验结论、耗时和错误类别。这样才能分清是选错工具、参数推断错误，还是外部服务故障，并分别改工具说明、校验逻辑或执行策略。

追问

用了严格结构输出，为什么还需要校验？

严格工具参数生成与“提示词要求返回合法 JSON”不同：在接口支持的 Schema 范围内，前者能约束生成的字段、类型和枚举，后者只是自然语言要求。但 loc="Shanghai" 完全可能通过 Schema，却与用户要求的北京不一致。结构合规不证明对象、时间和业务前置条件正确，更不证明调用者有权限；这些仍由执行端结合请求和当前状态判断。

如果把天气查询换成下单，超时后还能直接重试吗？

不能照搬。查询通常不改变业务状态，下单超时却可能是“订单已经创建，只是响应没回来”，此时应视为结果未知。需要先查执行状态，或在服务端支持的幂等范围内，用同一业务请求的幂等键与相同业务参数重试；查不清又没有可靠去重机制时，不应盲目再下单。

幂等键应由应用管理，并在第一次执行前确定，不能每次让模型另生成一个。调用 ID 和幂等键的职责也不同：tool_call_id 用于把消息结果对应回调用，业务幂等键用于防止重复创建订单；模型再次提出调用时有了新的调用 ID，并不意味着应该再创建一单。

怎么证明改动让调用更可靠？

用一组具体请求分别检查工具选择、参数含义和最终结果。除了正常查北京，还要放入“这里天气”“明天天气”、无权限、超时、结果缺字段，以及北京上海并行结果乱序等样例。应补问时没有乱调、服务失败时没有编结果，同样属于正确表现；只统计 JSON 解析成功率会漏掉这些问题。对下单等写操作，还应模拟“已执行但响应丢失”，检查重试是否产生重复业务结果。

对应教程

参考资料