大模型工具调用怎么接？从参数定义到执行结果回传的入门指南

大模型工具调用常被称为 Function Calling，但它不等于模型可以直接访问数据库、订单系统或服务器。更准确的流程是：模型根据对话和工具说明生成一个调用请求，应用程序收到请求后进行校验，由服务端实际执行工具，再把执行结果按所用接口的规定交回模型，最后由模型生成面向用户的回答。

一、先定义工具，而不是把权限交给模型

工具定义至少应包含名称、用途和参数结构。名称要能表达动作，例如 get_order_status；用途要说明它只能查询订单状态，不能修改订单；参数则应明确类型、是否必填和允许的格式。描述越具体，模型越容易选择正确工具，但工具说明本身不能替代服务端安全控制。

不同供应商的请求字段、消息角色、工具声明方式和结果回传格式可能不同。下面的示例是一个自定义接口的概念示意，不是任何特定平台的通用请求格式。接入实际模型服务时，应以对应接口文档为准，逐项映射工具名称、参数和调用标识。

二、用只读订单查询走完一次闭环

1. 应用向模型提供工具说明：声明订单状态查询工具需要一个字符串类型的 order_id，并说明只能查询当前用户可访问的订单。
2. 模型生成调用请求：当用户问“订单 A10086 到哪一步了”，模型可能返回工具名和参数，例如工具名为 get_order_status，参数为 {"order_id":"A10086"}。这里是模型提出的请求，不是执行结果。
3. 服务端接收并校验：应用先验证调用名是否在允许列表中，再校验参数是否为合法订单编号，检查当前登录用户的身份以及该用户是否有权查看订单 A10086。参数不合格或无权限时，应拒绝执行并返回受控错误，不应把未经处理的输入直接拼接到数据库查询中。
4. 应用执行工具：通过后端已有的订单服务或数据库访问层执行只读查询，并设置合理的超时。工具不应自行扩大权限，也不应因为模型要求而跳过身份校验。
5. 回传结果并继续生成：应用按照实际接口要求，把原调用标识、工具名称和执行结果回传给模型。例如结果可以包含状态“配送中”、更新时间和必要的说明。模型随后根据该结果组织自然语言回答。若查询失败，应回传明确但不泄露敏感信息的错误状态。

在这个闭环中，模型负责理解意图和提出结构化请求；应用负责调度；服务端负责鉴权、校验和执行。三者职责分开，才能避免把“模型生成了参数”误认为“参数已经可信”。

三、上线前要设置安全边界

• 限制调用次数：为单次请求、单个会话和单个用户设置上限，避免模型反复调用工具形成循环。
• 设置超时和费用上限：工具调用、模型续答和整体请求都应有超时；涉及计费资源时，还应设置预算或额度控制。
• 执行最小权限：只读查询使用只读凭据，工具只暴露完成任务所需的数据，不要提供笼统的“执行任意数据库语句”能力。
• 保护敏感信息：回传给模型的结果应经过字段筛选和脱敏，避免把密码、令牌或不必要的个人信息放入上下文。
• 对写入和删除增加确认：退款、发货、改价、删除数据等不可逆或有业务影响的操作，应要求用户明确确认，必要时交由人工审批。

四、如何排查调用失败

调试时可记录请求链路中的调用标识、工具名、校验结果、执行耗时和错误类型，但日志中不要直接保存完整令牌或敏感业务数据。若模型选择了错误工具，先检查工具描述是否含糊；若参数格式错误，检查服务端校验和接口映射；若结果回传后模型无法继续回答，则核对所用供应商规定的消息顺序、调用标识和结果字段。

因此，接入工具调用的最小可靠方案不是“让模型连接系统”，而是建立一个受控的执行闭环：清晰定义工具，严格校验输入，使用用户权限执行，按接口文档回传结果，并为每次调用设置可追踪的安全边界。