这次我们来看一个和 Claude Platform 强相关但又能独立拆出来讲透的能力Tools也就是 AI 工具调用。你可以把它理解成大模型对外部世界的控制出口。普通的聊天对话模型只会输出文本一旦打开工具调用模型可以在回答里夹带一个结构化请求告诉你的代码“我需要调用get_weather这个函数参数是city北京”然后由代码真正去执行这个函数再把执行结果返回给模型由模型给出最终答案。这就是“模型负责决策代码负责执行”的基本形态。如果你之前只把大模型当成一个高级问答框tools 会改变你对模型能力的认知。天气查询、库存查询、订单状态查询、工单创建、脚本执行、第三方接口调用这些实际业务操作都能通过工具调用让模型按需发起。那为什么需要工具调用因为模型本身是离线的它不掌握你系统里的订单表也没有权限去发送真实邮件。Tools 就是在大模型和实际系统之间搭一座受控的桥模型只提出意图和参数是否执行、怎么执行由你的代码决定。这篇文章不绑定某个特定 SDK先讲清楚工具调用的完整流程再给一套可以直接改的 Python 模板代码然后讲批量任务怎么设计、资源消耗怎么看、常见问题怎么排查。它不需要本地 GPU也不需要自己部署模型前提是你有可用的模型 API 密钥并且网络环境可以正常访问对应的 API 服务。如果你正准备做 AI Agent、智能客服、自动化流程或者想把大模型接进现有业务系统这篇文章建议收藏。1. Claude Platform tools 核心能力速览先给一张速览表后面所有内容都围绕这些能力展开。能力项说明主题定位Claude Platform 系列toolsAI 工具调用 / Tool Use核心作用让大模型输出结构化工具调用请求由外部代码执行后回传结果是否本地 GPU通常不需要走云端模型 API关键前置条件可用的模型 API 密钥、可访问 API 的网络环境、开发环境交互方式tools工具声明 模型返回tool_use结构化块API 能力通过 HTTP 接口完成“请求-工具执行-结果回传-最终成答”闭环批量任务可在代码层封装任务队列做并发控制和失败重试典型成本主要消耗是 token 费用和外部工具执行时间适合读者AI Agent 开发者、大模型应用工程师、自动化流程设计者上面这张表里没有写显存占用原因是这类云端 API 的工具调用模式并不在本地跑推理所以显卡基本不属于硬门槛。你要评估的资源是 API 成本、请求延迟和工具执行稳定性。如果你的目标是私有化部署那才需要考虑本地模型和显存但那是另一套技术路线不在本文范围内。对于先验证 AI Agent 思路的开发者来说用云端模型 API 跑通闭环是成本最低的方式。2. Claude Platform tools 适用场景与使用边界工具调用最典型的场景有四类。第一是信息查询类比如天气、汇率、股票、商品信息模型自己没有实时数据需要通过工具去拉取。第二是业务系统类比如查订单状态、创建工单、发送通知、修改配置这些都是模型没有权限直接操作的系统能力。第三是数据处理类比如读取表格、调用脚本、做格式转换把本地业务逻辑包装成工具函数。第四是研发辅助类比如生成测试数据、执行代码片段、检查接口返回降低开发人员的重复劳动。为什么需要工具调用因为模型本身是“离线”的。它不知道你这套系统里的订单表长什么样也不应该直接拿到你数据库的写入权限。工具调用提供的是一个受控出口模型只负责给出意图和参数真正执行的是你写的、经过鉴权的函数。从这个角度看工具调用不是削弱模型能力而是让模型在受限范围内安全地发挥作用。哪些场景不适合工具调用低延迟的实时交互要谨慎因为每多一次工具调用就多一次网络往返。比如毫秒级响应的在线操作、需要极低延迟的交互场景工具调用就不合适。另外工具调用不适合承载“没有边界”的系统管理操作。如果一个工具能删库、能批量发消息就不能让模型在无人复核的情况下直接调用。工具的作用范围越大失控风险越高。使用边界上必须强调三条。第一模型输出只是建议工具执行必须有权限控制不能因为模型说“可以执行”就直接放行。第二涉及人脸、声音、个人信息、企业敏感数据时必须确认数据流转和授权是否合规不能把未脱敏数据直接丢给外部 API。第三所有工具执行过程要留日志能回溯是谁、在什么时间、执行了什么操作出了问题才能定位。3. AI 工具调用环境准备与前置条件先明确一点Tools 工具调用是 API 侧的能力不是本地模型能力。虽然部分开源模型也支持 function calling但如果你要做大规模生产系统用云模型 API 通常是更稳的选择重点在于工程实现而不是模型部署。环境准备清单如下可访问的大模型 API 服务只要服务商提供 tool use / function calling 能力即可API 密钥放在环境变量或仅限本人可读的配置文件中不要提交进代码仓库Python 3.10 以上示例代码使用 Python 3 语法requests库用来发 HTTP 请求建议先建一个干净的虚拟环境避免依赖污染。python -m venv .venv # Windows 激活 .venv\Scripts\activate # macOS / Linux 激活 source .venv/bin/activate pip install requests python-dotenv密钥建议写到.env文件通过python-dotenv读取不硬编码在代码里。# .env API_KEYsk-your-api-key-here API_URLhttps://api.example.com/v1/messages MODEL_NAMEyour-model-name这里没有把具体模型写死。不同服务商支持的模型名、请求字段、鉴权方式都不一样落地时把.env里的三个变量替换成实际能用的值即可。4. 工具调用完整流程模型决策代码执行工具调用的本质是一个“两轮甚至多轮”的请求循环而不是单次请求。理解这个循环是理解所有 AI Agent 框架的前提。第一步把用户问题和工具定义一起发给模型。工具定义也叫工具声明是一段 JSON Schema描述“这个工具叫什么、用来干什么、需要哪几个参数”。模型不是靠读你函数源码来理解工具的它只靠这段声明。第二步模型分析用户问题。如果它认为需要调工具就返回一个类似“我准备调用get_weather参数city北京”的结构化消息而不是直接给答案。注意此时模型没有真正执行任何函数它只是在“提出调用意图”。第三步你的代码收到这个结构化消息去真实执行对应函数。执行结果可以是字符串、JSON、文件路径全部收集起来。第四步把所有工具执行结果拼成一条消息发给模型。模型结合结果生成最终回答。如果结果不够或者后续又需要调用别的工具就重复第三步和第四步直到模型认为可以收尾。这个四步循环就是最简形态的 AI Agent。很多框架做的事情本质上就是维护这个循环判断是否需要调用工具、调用哪个、怎么校验参数、怎么处理失败、最多允许循环几轮。理解了这个 loop再去看各种 Agent SDK 和工具连接标准都会清晰很多。5. Python 实现最小工具调用闭环下面是一段通用模板把上面的四步流程串起来。你需要替换的是 API 地址、密钥、模型名以及工具函数里的真实逻辑。import json import requests # ---------- 占位配置实际请替换 ---------- API_URL https://api.example.com/v1/messages API_KEY sk-your-api-key MODEL_NAME your-model-name # ------------------------------------------ # 1. 定义工具声明 TOOLS [ { name: get_weather, description: 查询指定城市的实时天气, input_schema: { type: object, properties: { city: {type: string, description: 城市名例如 北京} }, required: [city] } } ] def call_model(messages): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } body { model: MODEL_NAME, max_tokens: 1024, messages: messages, tools: TOOLS } resp requests.post(API_URL, headersheaders, jsonbody, timeout60) resp.raise_for_status() return resp.json() def execute_tool(name, arguments): 实际执行工具这里用模拟数据返回 if name get_weather: city arguments.get(city, ) return json.dumps({ city: city,