FDE W2D1 学习手册 · Tool Calling 工具调用

W2 Week2 Day1 · A 级（必须掌握，面试核心）· 5h · 学完能讲透"模型如何决定调工具、执行、回填、再决策"的完整闭环

一、Tool Calling 的本质与定位

Tool Calling（函数调用 / 工具调用）让 LLM 从"只会生成文本"变成"能驱动外部系统"。模型本身不直接执行任何工具，它只负责输出"我要调哪个工具、传什么参数"，真正的执行由你的后端代码完成，再把结果回填给模型。

1.1 为什么需要工具

• 补知识：模型不知道实时特药价格、用户保单余额 → 调数据库工具查。
• 补能力：模型不会算风控金额、不会解析发票 → 调规则工具 / OCR 工具。
• 补动作：模型不能真提交理赔 → 调业务 API（需严格权限）。

二、Tool Schema 设计（函数描述 + 参数 JSON Schema）

2.1 一个工具由什么组成

每个工具通常包含三部分：name（函数名）、description（给模型看的自然语言说明）、parameters（参数 JSON Schema）。

{
  "name": "query_policy",
  "description": "根据保单号查询医疗保险保单的基本信息，包括投保人、有效期、特药保障额度。",
  "parameters": {
    "type": "object",
    "properties": {
      "policy_no": {
        "type": "string",
        "description": "保单号，格式如 PA-2024-123456"
      },
      "fields": {
        "type": "array",
        "items": { "type": "string", "enum": ["holder", "valid_until", "special_drug_limit"] },
        "description": "需要返回的字段，不传则返回全部"
      }
    },
    "required": ["policy_no"]
  }
}

2.2 参数 JSON Schema 的要点

三、工具注册与路由

3.1 工具注册

"注册"就是把工具定义（Schema）放进请求里传给模型，模型在生成时可以选择调用。后端维护一个 name → 可执行函数 的映射表。

tools = {
  "query_policy": query_policy_impl,      # 查保单
  "ocr_invoice": ocr_invoice_impl,        # 识别发票
  "calc_claim": calc_claim_impl,          # 算理赔金额
  "query_drug_db": query_drug_db_impl,    # 查药品库
}

3.2 工具路由（模型决定 vs 你决定）

• 模型路由：把多个工具都交给模型，由模型根据语义选一个（或并行选多个）。最灵活，依赖模型判断。
• 你路由：先让模型做"意图分类"，你根据分类显式调用对应工具。更可控，适合强约束业务（如理赔必须先校验保单再算金额）。

四、单轮工具调用流程

最基础的"一问一调"：用户问 → 模型决定调工具 → 你执行 → 结果回填 → 模型生成最终回答。

1. 请求：把用户消息 + tools 列表发给模型，temperature 设低（0~0.2），保证参数稳定。
2. 解析：模型返回含 tool_calls 的响应，取出 name 和 arguments（JSON）。
3. 执行：在你的映射表里找到函数，传参执行，拿到原始结果。
4. 回填：把结果以 role: "tool" 消息（带 tool_call_id）追加进对话历史。
5. 再请求：带着完整历史再调一次模型，模型据此生成最终自然语言回答。

五、多轮工具调用循环（核心）

真实任务往往要调好几次工具、甚至连续决策：查保单 → 查特药目录 → 算金额 → 校验规则 → 输出结论。这就是多轮（multi-turn / agentic）工具调用。

messages = [{"role":"user","content":"帮我看下PA-2024-123456的特药理赔能报多少，药是奥希替尼"}]
while True:
    resp = call_llm(messages, tools=TOOLS, temperature=0.1)
    if not resp.tool_calls:          # 模型不再调工具 → 结束
        print(resp.content)
        break
    for tc in resp.tool_calls:       # 可能一次并行多个
        fn = tools[tc.function.name]
        result = fn(**json.loads(tc.function.arguments))
        messages.append(resp.message)                       # 先把模型回复存进去
        messages.append({                                   # 再回填工具结果
            "role": "tool",
            "tool_call_id": tc.id,
            "content": json.dumps(result, ensure_ascii=False)
        })

六、多工具路由与并行调用

6.1 一次决策调多个工具

模型一次响应里可以包含多个 tool_calls（如同时查"保单额度"和"药品目录"），它们之间无依赖时应并行执行以省时延。

6.2 依赖关系判断

依赖判断通常由模型自己完成（它发现需要 A 的结果才能决定 B）。但你也可以在代码层做"依赖图"编排，把确定的串行关系写死，只把不确定的交给模型。

七、参数校验与类型转换

7.1 为什么要校验模型给的参数

模型生成的 arguments 是字符串 JSON，可能：字段名拼错、类型错（把数字写成字符串）、必填缺失、枚举值非法、甚至 JSON 不合法。

7.2 校验手段

• JSON.parse / json.loads：先确保能解析，失败则反馈重试。
• Pydantic / JSON Schema：按 schema 校验类型、必填、枚举、范围。
• 业务校验：保单号格式正则、金额非负、日期合法等 schema 管不到的。

try:
    args = ClaimArgs.model_validate_json(tc.function.arguments)
except ValidationError as e:
    # 把错误反馈给模型，让它修正后重发
    messages.append(error_feedback(str(e)))

八、工具超时与失败重试

8.1 超时控制

每个工具调用都要有超时（如 3s / 10s），避免下游慢查询拖垮整个对话。超时后视为失败，进入重试/降级逻辑。

8.2 重试策略

九、工具返回结果标准化

9.1 统一返回结构

不同工具返回格式各异（DB 是行、OCR 是坐标、规则是结论）。建议统一成结构化对象再回填，方便模型消费，也方便你做日志/评测。

{
  "ok": true,
  "data": { "policy_no": "PA-2024-123456", "special_drug_limit": 300000 },
  "error": null,
  "trace_id": "tr_8f3a"
}

9.2 错误处理要"对模型友好"

• 成功：返回干净的业务数据。
• 失败：返回 ok:false + 简洁错误原因（如 "policy_not_found"），不要返回堆栈。
• 降级：返回"工具暂不可用，请转人工"之类模型能理解的话。

十、不把异常泄露给模型（异常隔离）

10.1 为什么要隔离

把原始异常（SQL 报错、内部 IP、堆栈、密钥线索）回填给模型有两大风险：

• 安全风险：堆栈可能暴露内部架构、凭证、PII。
• 噪声风险：模型被无关技术细节干扰，可能胡乱决策。

10.2 隔离做法

1. 工具代码内部 try/except，把异常转成业务层错误码。
2. 只把"模型能用的信息"回填：错误类型、建议动作（重试 / 换参数 / 转人工）。
3. 敏感字段（身份证、手机号）在回填前脱敏。

十一、各家实现（Qwen / DeepSeek / Claude）

11.1 通用模式

三家本质相同：请求带 tools 定义 → 响应带回 tool_calls（含 name + arguments）→ 你执行 → 用对应格式（OpenAI 的 role:"tool" / Claude 的 tool_result）回填 → 再请求。

十二、工程落地与可观测性

12.1 必须记录的 Trace

• 每轮：模型选了哪个工具、传了什么参数、参数校验结果。
• 工具执行：耗时、是否超时、返回摘要（脱敏）。
• 回填内容、最终轮数、总 token、是否降级/转人工。

12.2 防护清单

• 最大轮数上限（防循环）。
• 每个工具超时 + 重试上限。
• 工具白名单（模型只能调注册过的）。
• 危险操作（如真正提交理赔）需二次确认 / 人工审批。
• PII 脱敏与权限校验（谁能查谁的保单）。

十三、面试达标线①：讲清一次多轮工具调用循环

1. 模型输出 tool_call（函数名 + JSON 参数），temperature 设低保证参数稳定。
2. 代码执行：用 name 在注册表找到函数，解析并校验参数后执行。
3. 结果回填：以 role:"tool" + tool_call_id 追加进 messages，带上完整历史。
4. 再请求模型：模型结合结果继续——要么再发 tool_call，要么直接给最终自然语言答案。
5. 终止条件：响应里没有 tool_calls → 循环结束。必须加最大轮数上限防死循环。

十四、面试达标线②：工具失败怎么处理

• 网络/超时：指数退避重试 2~3 次，仍失败降级。
• 参数错误（模型填错）：把校验错误反馈给模型，让它改参数重新调——不是无脑重试（重试 N 次参数还是错）。
• 永久故障：停止重试，降级返回"工具暂不可用/转人工"，不能让流程卡死。
• 异常隔离：工具内部 try/except，只回填业务错误码，绝不泄露堆栈、内部 IP、密钥、PII。
• 降级兜底：返回模型能理解的话（如"保单查询暂不可用，已为您转人工"）。

十五、W2D1 自测清单

十六、高频面试题速记卡