什么是 tool use(function calling)?LLM 怎么伸出手做事

Tool use(又称 function calling)是把 LLM 从「会聊天的 bot」变成「会做事的 bot」的机制。你描述一个函数 — 名字、参数、返回什么 — 模型决定何时调用它。Provider 的 API 负责协调:模型挑工具、你执行、返回结果、模型继续。2026 年几乎所有 agent 都是「tool-use 循环 + 加料」。

基本机制

你用 JSON schema 定义一个工具:

{
  "name": "get_weather",
  "description": "取得某城市的目前天气",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "例如 Taipei" }
    },
    "required": ["city"]
  }
}

你把这份工具清单跟 prompt 一起送进去。模型看到就可能决定要调用。它调用时,不是回纯文字,而是回一个结构化 tool-use block:「调用 get_weather,参数 {city: "Taipei"}」。你的 code:

接到 tool-use request。
实际调用 getWeather("Taipei") — 打真的天气 API。
把结果送回给模型。
模型带着天气数据继续对话。

这个循环能跑很多轮。新版 Claude、GPT-5、Gemini 都支持 parallel tool use(一次调用多个工具)跟 multi-turn tool use(调用 → 响应 → 再调用)。

什么样才是好工具设计

工具质量就是 agent 质量的大部分。三个原则:

清楚、窄的名字。search_web 赢 do_research。模型挑名字 + 描述跟情境匹配的工具,模糊名字导致挑错。

**详细的描述。**描述是 prompt 的一部分。要具体:「返回 Google 搜索结果前 10 条。当 user 问时事或训练数据以外的事实时用。Code 查询不要用这个 — 用 search_docs。」

**紧凑、可验证的输入 schema。**指定类型,可以的话用 enum(status: 'open' | 'closed')、required vs optional。进来时就验证 — 模型传垃圾就回一个 guide 它下一轮修正的错误消息。

**模型实际能用的输出。**模型要拿来推理的,回结构化数据(JSON)。要被读出来的,回短文字片段。不要 dump 5 万 tokens 的 HTML。

LLM 实际会调用什么

真实 agent 会出现的工具类别:

信息获取 — search_web、fetch_url、query_database、vector_search。
计算 — run_python_code、calculate、parse_csv。Sandboxed code 执行对数学/数据任务很关键。
对外动作 — send_email、create_calendar_event、post_message。写入动作要特别小心。
系统交互 — read_file、write_file、run_shell_command。写 code 的 agent 的基础。
领域 API — lookup_customer、create_invoice、update_ticket。你的 business logic。

Anthropic 的 computer use 模式加上 take_screenshot、move_mouse、click、type — 把整个 OS 变成工具。

Tool use 怎么改变 prompt

有工具可用之后,prompt 从「回答这个」变成「想办法用这些工具回答这个」。给模型对的工具,它明显变得更有用,因为它不再幻觉出本来可以查的东西。

强力 pattern:always-on retrieval。给模型一个 search_knowledge_base 工具。Prompt 它「user 问跟我们领域有关的东西时就用这个工具」。模型自己决定何时要 retrieve — 不必硬编 pipeline。

另一个 pattern:特化 sub-agent 包成工具。把另一个 LLM 调用(不同模型、不同 prompt、不同工具)包成单一「工具」给父 agent 调用。便宜模型做窄任务、前沿模型做编排。

什么时候不要加工具

**One-shot 任务。**单次 LLM 调用就能解 user 的问题(「总结这段」),工具只是多延迟。
**执行不可靠的工具。**模型会调用坏掉的工具、拿到错、重试、失败。UX 很差。先修工具。
**模型分不清的工具。**三个近似工具配模糊描述,模型一定挑错。整合。
**隐藏副作用。**会删东西、发消息、移动钱的工具,不能没有循环内明确确认就暴露给模型。包一层权限步骤。

要注意的失败模式

Production 三个常见:

**Tool-call 无穷循环。**模型反复调用同一个工具,因为结果不满意或不知道还能试什么。解:步数上限、最近调用去重、给模型一条明确「放弃」路径。

**幻觉工具调用。**模型发明一个不存在的工具。新版 API 会验证并拒绝,旧 code 可能默默乱跑。Server-side 验证工具名。

**参数错。**模型传类型正确但内容错的数据:city: "用户选的城市"。严格描述跟验证能抓到,把错误消息送回模型,通常下一轮就修。

跟 MCP 的关系

MCP(Model Context Protocol)是「跨 AI client 暴露工具」的标准方式。MCP server 定义工具的方式跟你在自家 app 定义一样,但用标准协议让任何支持 MCP 的 client 都能用。Tool use 是底层能力,MCP 是上面的互通层。