跳转至

Deep Research: [31] Tool Use / Function Calling：让模型能做事的标准接口

  • Source: https://platform.openai.com/docs/
  • Note: ../notes/ref-031-openai-tool-use.md
  • Snapshot: ../sources/md/platform-openai-com-docs-00a8ca075d5c.md

TL;DR

Tool Use（工具调用/函数调用）是将大模型从聊天机器人转变为智能体的关键机制：模型不直接执行操作，而是输出结构化的意图与参数，由宿主系统进行验证、执行并反馈结果，从而实现与外部数据和系统的安全交互。

核心观点

  1. 意图与执行分离：模型只负责规划——决定调用什么工具以及参数是什么；系统负责执行——真正的 API 请求、数据库查询发生在模型外部。
  2. 结构化是基石：相比自然语言指令，Function Calling 强制模型输出符合 Schema（如 JSON Schema）的数据，极大降低了系统解析的错误率。
  3. 安全边界前置：由于执行权在代码侧，开发者必须在执行前进行参数校验、权限控制和二次确认，绝不能盲目信任模型的输出。
  4. 状态机的闭环：工具调用是一个 Model -> Tool Call -> System Execute -> Submit Tool Output -> Model 的完整闭环，中间状态必须维护在 Context 中。
  5. API 即提示词：提供给模型的工具定义（名称、描述、参数说明）实际上是提示词的一部分，函数名和参数描述的清晰度直接决定调用的准确性。
  6. 审计与回溯：每一次工具调用（Call ID）、参数（Arguments）和返回结果（Tool Output）都应被记录，用于调试、计费和安全审计。
  7. 模型能力分级：并非所有模型都能通过 Function Calling 精准遵循复杂指令，在此场景下应优先选择经过特定微调（Fine-tuned for function calling）的模型版本。

可落地做法

1. 接口定义（产品/工程）

  • 步骤：
    1. 梳理业务中需要向 AI 开放的能力（如查询订单、重置密码）。
    2. 使用 OpenAPI (Swagger) 规范或 Pydantic 模型定义函数签名。
    3. 关键点：在 description 字段中用自然语言清晰描述该工具做什么、何时用以及参数的格式要求，这直接作为 Prompt 喂给模型。

2. 系统集成（工程）

  • 步骤：
    1. 配置大模型客户端（如 OpenAI SDK），传入 tools 定义。
    2. 检测模型响应：若 finish_reason 为 tool_calls，则暂停对话，提取参数。
    3. 安全拦截：在执行前校验参数类型、范围，并检查当前用户是否有权执行该操作。
    4. 执行代码，获取结果（注意截断过长的返回值）。
    5. 将结果封装为 tool 角色的消息追加到对话历史，再次请求模型以生成最终回答。

3. 效果评测（测试/QA）

  • 步骤：
    1. 构建黄金数据集：包含用户 Query 和预期的正确 Function Name 及 Arguments。
    2. 使用参数匹配度而非文本相似度作为评测指标。
    3. 测试边界情况：提供无关 Query，测试模型是否能克制地不乱调用工具（幻觉测试）。

检查清单：工具调用安全与规范

  • [ ] Schema 完整性：所有参数是否有明确类型、描述和是否必填的标记？
  • [ ] 最小权限原则：该工具是否仅暴露了完成任务所需的最小数据和操作权限？
  • [ ] 参数校验：执行代码前，是否对模型生成的参数进行了正则、范围或逻辑校验？
  • [ ] 超时与重试：工具执行（特别是网络请求）是否有明确的超时设置？
  • [ ] 异常处理：工具执行失败时，是否返回了模型能看懂的错误提示，而不是一大堆 Stack Trace？
  • [ ] 上下文保护：工具返回的大量 JSON 数据是否经过了精简/截断，防止撑爆 Context Window？
  • [ ] 敏感操作确认：对于写操作（增删改），是否引入了 Human-in-the-loop (HITL) 二次确认机制？

常见坑与对策

  • 坑 1：模型陷入调用死循环
    • 现象：模型不断尝试调用同一个工具，参数微调但总是不对，或者反复查询。
    • 对策：设置最大递归深度（如最多 5 轮）；在 System Prompt 中加入如果连续失败请请求人类帮助的指令。
  • 坑 2：工具返回值过大
    • 现象：类似 SELECT * 的操作返回数万字 JSON，导致 Token 耗尽或模型注意力分散。
    • 对策：在工具层做分页或摘要；只返回 ID 和关键状态，详细信息按需二次查询。
  • 坑 3：多工具混淆
    • 现象：定义了两个功能相似的工具，模型随机乱用。
    • 对策：优化函数命名和描述，明确彼此的互斥边界；或者合并为一个工具，通过参数区分模式。

可用于丰富《AI 辅助软件产品》的写作点

  • 第 5 章（后端契约）：从 API 到 Tool Spec
    • 强调OpenAPI 不仅是给人看的文档，更是给 AI 看的说明书。
    • 建议后端工程师在写 Docstring 时，考虑到受众包含非生物智能体，需解释业务逻辑而非仅仅是代码逻辑。
  • 第 7 章（Agent）：构建可靠的行动回路
    • 引用状态机的闭环观点，绘制一张详细的时序图：User -> LLM (Think) -> Tool Def -> System (Guard) -> Execution -> LLM (Synthesize) -> User。
    • 重点论述安全边界：将 Tool Use 视为一种特殊的依赖注入，所有输入都应被视为不可信的外部输入（Untrusted Input）。
  • 第 18 章（评估）：针对 Agent 的单元测试
    • 介绍如何编写针对 Function Calling 的测试用例：不仅测回答得好不好，更要测动作对不对和参数准不准。