三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

Claude工具调用：从代码解释器到安全高效的任务执行范式

发布时间：2026/8/13 4:45:28 三亩地 编程学习日记
Claude工具调用：从代码解释器到安全高效的任务执行范式

1. 从“代码解释器”到“工具调用”：Claude Code的范式演进

最近在跟几个做AI应用开发的朋友聊天，发现大家讨论的焦点已经从“哪个模型写代码强”悄悄转向了“哪个模型能稳定、准确地调用外部工具”。这背后反映的，其实是AI从“代码生成者”向“任务执行者”角色的深刻转变。Claude Code，或者说Claude模型系列的工具调用能力，正是这一转变的核心体现。它不再是简单地给你一段Python代码让你自己去跑，而是能理解你的意图，选择合适的工具（比如计算器、API、文件系统），执行操作，并把结果以人类可读的方式反馈给你。这个过程，我们称之为“工具调用”（Tool Calling）。

如果你用过早期的“代码解释器”类功能，可能会觉得这没什么新鲜——不就是让AI写段代码然后执行吗？但Claude Code的机制远不止于此。传统的代码解释器模式存在几个明显的痛点：第一，安全性。让AI生成并执行任意代码，无异于在沙箱里开了一个不可控的后门。第二，上下文割裂。AI生成代码是一回事，执行结果是另一回事，用户需要来回切换理解。第三，效率低下。为了一个简单的计算（比如算个复利），AI可能需要生成十几行Python代码，启动一个完整的运行时，这完全是杀鸡用牛刀。

Claude Code的工具调用机制，本质上是在模型推理层和应用执行层之间，构建了一套标准化的、安全的、声明式的接口协议。模型不再输出代码字符串，而是输出结构化的“工具调用请求”，这个请求包含了“调用哪个工具”、“传入什么参数”。然后，由宿主应用（比如Claude桌面端、API服务器）来安全地执行这个请求，并将结构化的结果返回给模型，由模型整合成最终的自然语言回复给用户。这套机制，让AI从“码农”升级成了“调度员”，它更懂你要什么，也更知道怎么安全、高效地要到你想要的东西。

2. 工具调用的核心架构：请求、执行与响应的闭环

要理解Claude Code的工具调用，我们必须拆解其核心的工作流程。这个过程是一个典型的“感知-决策-执行-反馈”闭环，但完全发生在AI的“思维”层面。我们可以把它想象成一个经验丰富的技术主管：他不需要亲自拧螺丝，但他知道哪个螺丝该拧，该让谁去拧，以及拧完之后的结果意味着什么。

2.1 工具的定义与注册：给AI一张“技能清单”

首先，宿主应用需要告诉Claude：“我这里有哪些工具你可以用。” 这不是通过自然语言描述的，而是通过一套严格定义的工具模式（Tool Schema）。这个模式通常是一个JSON对象，它明确规定了：

  • 工具名称（name）：一个唯一的标识符，比如calculator、web_search。
  • 工具描述（description）：用自然语言简要说明这个工具是干什么的。这部分描述至关重要，因为Claude主要靠它来理解工具的用途和适用场景。例如，“一个用于执行基本算术和科学计算的工具”。
  • 参数模式（parameters）：一个遵循JSON Schema格式的定义，详细说明了调用这个工具需要哪些参数，每个参数的类型（string, number, boolean等）、是否必需、以及可能的描述。例如，一个计算器工具的参数可能包括operation（操作符，如“add”）和numbers（一个数字数组）。

在实际的API调用中，这些工具定义会作为消息历史的一部分，或者在一个专门的“系统提示”中提供给Claude。例如，当你使用Anthropic的Messages API时，你可以在请求的tools参数中传入一个工具定义数组。这就好比在项目开始前，你把团队里所有专家的简历和能力清单交给了这位“技术主管”。

2.2 模型的决策与请求生成：从意图到结构化指令

当用户提出一个请求，比如“请帮我计算一下从2020年1月1日到今天总共过了多少天”，Claude会结合对话历史、工具定义以及自身的知识进行推理。

关键的一步来了：Claude不会直接说“我来写段Python代码算一下”。相反，它会在其推理过程的某个节点，决定需要调用一个工具。此时，它会在回复流中生成一个特殊类型的消息块：tool_use。这个块是结构化的，包含了：

  • id: 一个本次调用的唯一标识符，用于后续匹配执行结果。
  • name: 要调用的工具名称，必须与之前注册的工具列表中的某一个完全匹配。
  • input: 一个JSON对象，包含了调用该工具所需的所有参数，其结构必须严格符合工具定义中的parametersschema。对于上面的日期计算例子，它可能会调用一个名为date_calculator的工具，并传入{“start_date”: “2020-01-01”, “end_date”: “2024-10-27”}。

这个tool_use块的生成，是模型“思考”过程的外化。它意味着模型已经完成了问题解析、工具选择、参数提取等一系列认知步骤，并将结果封装成了机器可读的指令。这个过程是自动的、内嵌在模型推理中的，不需要用户显式地命令“请使用工具”。

2.3 宿主应用的执行与结果返回：安全沙箱中的实际运作

宿主应用（客户端或服务器）收到包含tool_use块的响应后，会将其拦截下来，不会直接展示给用户。然后，应用会根据tool_use块中的name和input，在自己的安全环境中定位并执行对应的工具函数。

这里的安全性设计是核心。工具的执行环境是宿主应用严格控制的。例如：

  • 一个计算器工具，可能只是调用一个受信任的数学库函数。
  • 一个网络搜索工具，可能会调用一个配置了速率限制和内容过滤的搜索API。
  • 一个文件读取工具，可能只允许访问用户事先指定的某个沙箱目录。

工具执行完成后，宿主应用会生成一个tool_result块。这个块同样包含：

  • tool_use_id: 与之前tool_use块中的id对应，确保结果能准确关联到请求。
  • content: 工具执行的结果，通常是字符串或JSON。对于日期计算，结果可能是{“days”: 1731}。
  • （可选）is_error: 布尔值，指示执行是否出错。

这个tool_result块会被作为新一轮对话的“用户消息”部分，发送回给Claude模型。注意，此时用户并没有真正参与，是应用自动完成了“执行-返回”的循环。

2.4 模型的最终整合与回复：从数据到洞察

Claude收到tool_result后，会将其纳入上下文，并结合最初的用户问题，生成最终面向用户的自然语言回复。它会解释它做了什么、结果是什么、以及这个结果意味着什么。

继续上面的例子，Claude的最终回复可能是：“从2020年1月1日到2024年10月27日，总共经过了1731天。这大约是4年零9个月的时间。”

至此，一个完整的工具调用闭环结束。用户感受到的是一个无缝的、智能的问答体验，而背后则是模型与宿主应用之间精密的结构化数据交换。

3. 与“代码解释器”模式的深度对比：为何工具调用是更优解

理解了工具调用的流程，我们再回头对比传统的“代码解释器”模式，就能清晰地看到前者的优势所在。这种对比不仅仅是技术实现的不同，更是产品哲学和安全范式的差异。

1. 安全性与可控性：从“任意代码执行”到“声明式接口”这是最根本的区别。代码解释器模式下，AI生成的是任意的、图灵完备的代码（通常是Python）。即使运行在沙箱中，也存在逃逸风险、资源耗尽风险（如无限循环）、以及依赖包安全风险。宿主应用需要对整个语言运行时进行极其严格的隔离和监控，成本高且难以做到万无一失。 而工具调用模式下，AI生成的只是一个结构化的调用请求。宿主应用只需要根据预先定义好的、有限的工具列表来执行对应的安全函数。每个工具的功能和权限都是预先审查和限定的。这大大缩小了攻击面，将安全边界从“整个编程语言”收缩到了“几个API函数”。

2. 性能与资源开销：按需启动与轻量执行启动一个完整的Python解释器、加载基础库、执行代码，即使对于简单的计算，也有不小的开销（可能几百毫秒到几秒）。在并发请求场景下，这对服务器资源是巨大的消耗。 工具调用则通常是轻量级的。一个计算器工具可能就是直接调用宿主语言（如JavaScript、Go）的一个数学函数，开销极低。工具的实现和优化完全由宿主应用掌控，可以针对高频场景做深度优化。

3. 用户体验的连贯性在代码解释器模式中，用户常常看到这样的对话：

  • 用户：“算一下复利。”
  • AI：“我将使用Python为您计算。以下是代码：principal = 1000; rate = 0.05; years = 10; ...计算结果为1628.89。” 用户需要从一堆代码中识别出结果数字，体验是割裂的。 在工具调用模式下，对话是流畅的：
  • 用户：“算一下复利。”
  • AI：“假设本金1000元，年化利率5%，投资10年，复利计算结果约为1628.89元。” 背后的工具调用（calculator工具）对用户是完全透明的，AI直接给出了整合后的、人性化的答案。

4. 开发与集成的便捷性对于开发者而言，集成代码解释器意味着要维护一个安全、稳定、支持多语言的代码沙箱环境，复杂度极高。 集成工具调用则简单得多。开发者只需要用自己熟悉的编程语言，实现几个符合schema的函数，并将其注册给AI即可。这降低了开发门槛，也让工具的能力可以更紧密地与开发者自己的业务逻辑和数据相结合。

注意：这并不意味着代码解释器模式会被完全取代。对于需要高度灵活性、探索性数据分析和复杂算法原型的场景，直接生成和执行代码仍有其不可替代的价值。工具调用更适合于那些功能明确、需要安全高效集成的标准化任务。

4. 实战解析：从零构建一个简单的Claude工具调用应用

理论讲得再多，不如亲手实现一遍。下面我将以一个极简的Node.js应用为例，演示如何为Claude API集成两个自定义工具：一个单位转换器和一个天气查询工具（模拟）。我们将使用Anthropic官方的JavaScript SDK。

4.1 环境准备与项目初始化

首先，确保你已安装Node.js（版本16+），并准备好你的Anthropic API密钥。

mkdir claude-tools-demo cd claude-tools-demo npm init -y npm install @anthropic-ai/sdk dotenv

创建一个.env文件来存储你的API密钥：

ANTHROPIC_API_KEY=你的API密钥

4.2 定义我们的工具Schema

工具的定义是整个系统的契约。我们创建两个工具：

  1. unit_converter: 用于在公制和英制之间转换长度或重量。
  2. get_weather（模拟）: 查询指定城市的（模拟）天气。

在代码中，我们以JSON Schema的形式定义它们：

// tools.js export const tools = [ { name: "unit_converter", description: "在不同度量单位之间进行转换，例如英里到公里，磅到公斤。", input_schema: { type: "object", properties: { value: { type: "number", description: "需要转换的数值" }, from_unit: { type: "string", description: "原始单位，例如 'miles', 'pounds', 'kilometers', 'kilograms'", enum: ["miles", "kilometers", "pounds", "kilograms", "feet", "meters"] }, to_unit: { type: "string", description: "目标单位", enum: ["miles", "kilometers", "pounds", "kilograms", "feet", "meters"] } }, required: ["value", "from_unit", "to_unit"] } }, { name: "get_weather", description: "获取指定城市的当前天气信息（模拟数据，用于演示）。", input_schema: { type: "object", properties: { city: { type: "string", description: "城市名称，例如 'Beijing', 'New York'" } }, required: ["city"] } } ];

注意看description字段，这是Claude理解工具用途的主要依据。描述要准确、简洁，涵盖主要功能和限制。input_schema定义了参数的“形状”，enum限制了输入的可选值，这能有效减少模型传参错误。

4.3 实现工具的执行函数

定义好了契约，接下来就要实现履行契约的函数。这些函数将在宿主应用（我们的Node.js服务器）中安全执行。

// toolExecutor.js export function executeTool(toolName, input) { switch (toolName) { case 'unit_converter': return executeUnitConverter(input); case 'get_weather': return executeGetWeather(input); default: return `错误：未知的工具 '${toolName}'`; } } function executeUnitConverter({ value, from_unit, to_unit }) { // 定义转换系数 const conversionRates = { 'miles_to_kilometers': 1.60934, 'kilometers_to_miles': 0.621371, 'pounds_to_kilograms': 0.453592, 'kilograms_to_pounds': 2.20462, 'feet_to_meters': 0.3048, 'meters_to_feet': 3.28084 }; const key = `${from_unit}_to_${to_unit}`; const rate = conversionRates[key]; if (!rate) { return `错误：不支持从 '${from_unit}' 到 '${to_unit}' 的转换。请检查单位是否在支持列表中。`; } const result = value * rate; // 返回结构化的结果，方便模型解读 return JSON.stringify({ original_value: value, original_unit: from_unit, converted_value: parseFloat(result.toFixed(4)), // 保留4位小数 converted_unit: to_unit, conversion_rate: rate }); } function executeGetWeather({ city }) { // 这是一个模拟函数，真实场景中你会调用如OpenWeatherMap的API const mockWeatherData = { 'Beijing': { temp: 22, condition: 'Sunny', humidity: 40 }, 'New York': { temp: 18, condition: 'Cloudy', humidity: 65 }, 'London': { temp: 15, condition: 'Rainy', humidity: 80 } }; const data = mockWeatherData[city]; if (!data) { return `错误：未找到城市 '${city}' 的模拟天气数据。`; } return JSON.stringify({ city: city, temperature: data.temp, condition: data.condition, humidity: data.humidity, note: '此为模拟数据，仅用于演示工具调用。' }); }

关键点：执行函数是安全边界。在这里，unit_converter只是做数学运算，get_weather访问的是我们预设的模拟数据。在真实生产环境中，你可以在这里接入任何受控的内部或外部API，同时实施认证、限流、日志记录等安全措施。

4.4 构建主循环：与Claude API的交互

现在，我们将工具定义和执行函数串联起来，创建一个能与Claude对话并处理工具调用的主程序。

// index.js import Anthropic from '@anthropic-ai/sdk'; import { tools } from './tools.js'; import { executeTool } from './toolExecutor.js'; import dotenv from 'dotenv'; dotenv.config(); const anthropic = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); async function chatWithClaude(userMessage, conversationHistory = []) { // 1. 构建消息数组，包含历史对话 const messages = [ ...conversationHistory, { role: 'user', content: userMessage } ]; // 2. 调用Claude API，传入工具定义 const response = await anthropic.messages.create({ model: 'claude-3-5-sonnet-20241022', // 使用支持工具调用的最新模型 max_tokens: 1024, tools: tools, // 关键：告诉Claude有哪些工具可用 messages: messages, }); // 3. 处理响应，检查是否有工具调用 const finalMessages = [...messages]; // 用于记录完整对话 let lastResponse = response; // 循环处理可能的工具调用链（Claude可能连续调用多个工具） while (true) { const toolUseBlock = lastResponse.content.find(block => block.type === 'tool_use'); if (!toolUseBlock) { // 没有工具调用，对话结束 finalMessages.push({ role: 'assistant', content: lastResponse.content }); break; } // 4. 执行工具 console.log(`[工具调用] ${toolUseBlock.name}`, toolUseBlock.input); const toolResult = executeTool(toolUseBlock.name, toolUseBlock.input); console.log(`[工具结果]`, toolResult); // 5. 将工具执行结果作为新的“用户消息”发送回给Claude const toolResultMessage = { role: 'user', content: [ { type: 'tool_result', tool_use_id: toolUseBlock.id, content: toolResult } ] }; finalMessages.push( { role: 'assistant', content: [toolUseBlock] }, // 记录Claude的调用请求 toolResultMessage // 记录工具执行结果 ); // 6. 带着新的上下文（包含工具结果）再次调用Claude const nextResponse = await anthropic.messages.create({ model: 'claude-3-5-sonnet-20241022', max_tokens: 1024, tools: tools, messages: finalMessages, // 包含完整历史的上下文 }); lastResponse = nextResponse; } // 7. 提取最终面向用户的文本回复 const finalTextBlocks = lastResponse.content.filter(block => block.type === 'text'); const finalReply = finalTextBlocks.map(block => block.text).join('\n'); return { reply: finalReply, fullHistory: finalMessages // 返回完整历史供后续使用 }; } // 示例对话 async function main() { let history = []; const query1 = "10英里相当于多少公里？"; console.log(`用户: ${query1}`); const result1 = await chatWithClaude(query1, history); console.log(`Claude: ${result1.reply}\n`); history = result1.fullHistory; const query2 = "那北京和伦敦的天气怎么样？"; console.log(`用户: ${query2}`); const result2 = await chatWithClaude(query2, history); console.log(`Claude: ${result2.reply}\n`); } main().catch(console.error);

运行这个程序，你会看到类似以下的输出：

用户: 10英里相当于多少公里？ [工具调用] unit_converter { value: 10, from_unit: 'miles', to_unit: 'kilometers' } [工具结果] {"original_value":10,"original_unit":"miles","converted_value":16.0934,"converted_unit":"kilometers","conversion_rate":1.60934} Claude: 10英里大约等于16.0934公里。 用户: 那北京和伦敦的天气怎么样？ [工具调用] get_weather { city: 'Beijing' } [工具结果] {"city":"Beijing","temperature":22,"condition":"Sunny","humidity":40,"note":"此为模拟数据，仅用于演示工具调用。"} [工具调用] get_weather { city: 'London' } [工具结果] {"city":"London","temperature":15,"condition":"Rainy","humidity":80,"note":"此为模拟数据，仅用于演示工具调用。"} Claude: 根据模拟数据： - 北京：天气晴朗，气温22°C，湿度40%。 - 伦敦：天气下雨，气温15°C，湿度80%。 请注意，以上为演示用的模拟数据。

这个简单的例子清晰地展示了整个闭环：用户提问 -> Claude决定调用工具并生成结构化请求 -> 我们的应用执行工具 -> 结果返回给Claude -> Claude整合结果生成最终回复。整个过程对用户而言是无感的，他们只得到了一个直接、准确的答案。

5. 高级技巧与避坑指南：让工具调用更稳定、更智能

在实际项目中集成Claude Code工具调用，你会遇到一些在官方文档里不会细说的“坑”。下面是我从多个项目实践中总结出的关键经验。

5.1 工具描述的“艺术”：如何让Claude更懂你

工具的描述（description）是模型选择工具的唯一自然语言依据。写得好坏，直接决定了工具调用的准确率。

反面教材：

  • “一个转换工具。”（太模糊，Claude不知道能转换什么）
  • “进行各种计算和查询。”（过于宽泛，Claude可能滥用）

最佳实践：

  1. 明确功能边界：开头用一句话概括核心功能。例如：“在不同度量单位之间进行转换，例如英里到公里，磅到公斤。”
  2. 列举关键用例：在描述中隐含或明示典型使用场景。例如：“适用于将烹饪配方中的杯、汤匙转换为毫升或克，或将旅行距离从英里转换为公里。”
  3. 说明限制和前提：如果工具有限制，最好在描述中提前说明。例如：“仅支持长度和重量单位的转换，不支持温度或货币。” 或者“需要提供完整的城市名称，不支持缩写。”
  4. 使用模型能理解的词汇：避免使用内部代号或生僻术语。使用常见的、在训练数据中可能高频出现的词汇。

一个优秀的描述，就像一份清晰的岗位说明书，能让Claude这个“调度员”快速做出正确决策。

5.2 参数Schema设计的陷阱与规避

参数Schema定义了工具输入的“形状”，设计不当会导致调用失败或结果错误。

常见陷阱1：类型过于宽松

// 不佳 properties: { city: { type: "string" } // 任何字符串都可能被传入 } // 更佳 properties: { city: { type: "string", enum: ["Beijing", "Shanghai", "Guangzhou", "Shenzhen", "New York", "London"] // 或从动态列表加载 } }

如果城市列表是固定的，使用enum可以极大减少Claude传错值的可能。如果列表动态，至少应在description中说明格式要求，如“请使用完整的城市英文名称”。

常见陷阱2：复杂嵌套结构尽量避免过深的JSON嵌套。Claude在理解多层嵌套对象并准确填充字段时，出错率会上升。如果参数确实复杂，考虑将其扁平化，或拆分成多个更简单的工具。

常见陷阱3：缺失参数描述每个参数的description字段至关重要。对于date参数，写“日期，格式为YYYY-MM-DD”比只写“日期”要好得多。清晰的描述是模型正确解析用户意图并填充参数的关键。

5.3 错误处理与鲁棒性：应对模型的“不完美”调用

即使你的工具描述和Schema再完美，Claude也可能产生非预期的调用。你的执行函数必须足够健壮。

  1. 参数验证（二次防御）：在执行函数内部，不要完全信任模型传来的参数。即使Schema定义了type: number，实际传值也可能是字符串"10"。在执行计算前，进行类型检查和转换。

    function executeUnitConverter(input) { const value = Number(input.value); if (isNaN(value)) { return `错误：'value'参数应为数字，但收到'${input.value}'。`; } // ... 其余逻辑 }

  2. 提供有信息量的错误信息：当工具执行失败时，返回的错误信息应该能帮助Claude（和后续调试）理解问题所在。不要只返回“错误”，而是返回如“错误：不支持从‘inch’到‘meter’的转换。支持的单位有：...”。Claude有时能根据清晰的错误信息进行自我修正，在下一轮调用中调整参数。

  3. 处理多工具调用与依赖：有时用户的一个问题可能需要按顺序调用多个工具。例如，“查询北京的天气，然后告诉我这个温度相当于多少华氏度”。这需要Claude先调用get_weather，从结果中提取温度值，再调用unit_converter进行温度转换。你的主循环（如我们示例中的while循环）需要能处理这种链式调用。确保工具结果以结构化的JSON返回，方便模型从中提取数据作为下一个工具的输入。

5.4 上下文管理：长对话中的工具调用挑战

在多轮对话中，工具调用会变得复杂。用户可能会说“用刚才那个数字再算一下”，或者“像之前那样转换一下”。

  • 历史消息包含工具调用：确保你将完整的对话历史（包括所有的tool_use和tool_result块）传递给下一次API调用。这为Claude提供了完整的上下文，让它知道“刚才那个数字”具体是多少。
  • 工具结果的持久化：对于计算密集型或耗时的工具调用，考虑缓存结果。如果用户稍后引用相同查询，可以直接提供缓存结果，避免重复调用外部API（如天气API有调用限制和延迟）。
  • 会话隔离：不同的用户会话应该有不同的对话历史记录，避免工具调用上下文串扰。

6. 超越基础：工具调用的进阶应用场景与模式

掌握了基础机制后，我们可以探索一些更强大的应用模式，这些模式能将Claude Code的能力与你的业务逻辑深度结合。

6.1 动态工具注册：根据上下文提供不同的“技能包”

不是所有工具在所有对话中都需要。你可以根据用户身份、对话阶段或当前任务，动态地向Claude注册不同的工具集。

场景示例：一个客服机器人

  • 用户刚进入时，只提供greeting（问候）和faq_search（常见问题搜索）工具。
  • 当用户表达购买意向后，动态添加product_query（产品查询）、inventory_check（库存检查）工具。
  • 当用户进入支付环节，再添加create_order（创建订单）、apply_coupon（应用优惠券）等敏感工具。

这样做的好处是：

  • 安全性：最小权限原则，只在需要时才暴露功能。
  • 准确性：减少了Claude在无关工具中的选择困惑，提高了调用准确率。
  • 性能：工具列表更短，可能轻微提升模型推理速度。

实现上，你可以在每次调用API的tools参数中传入当前会话适用的工具列表。

6.2 工具的组合与编排：实现复杂工作流

单个工具能力有限，但通过Claude的推理能力进行编排，可以实现复杂的工作流。

场景示例：旅行规划助手用户说：“我想下周末去杭州旅行，预算5000元，帮我规划一下。” 这个需求可以分解为：

  1. 调用search_flights（查询航班）工具，获取航班信息和价格。
  2. 调用search_hotels（查询酒店）工具，获取酒店信息和价格。
  3. 调用get_attractions（查询景点）工具，获取杭州景点列表和门票信息。
  4. Claude内部进行预算分配、时间安排的计算和推理。
  5. 调用generate_itinerary（生成行程单）工具，将最终规划格式化为一个漂亮的文档或日历事件。

Claude扮演了“工作流引擎”的角色，它理解最终目标，并智能地决定调用哪些工具、以什么顺序调用、如何将中间结果整合到下一步。你只需要提供一个个原子工具，复杂的逻辑交给模型。

6.3 工具的“反射”能力：让工具了解自身状态

一个更高级的模式是让工具具备“反射”能力，即Claude可以查询工具的状态或元信息。这可以通过设计一个特殊的“工具管理工具”来实现。

例如，你可以创建一个名为list_available_tools的工具，当被调用时，它返回当前已注册的所有工具的名称和简要描述。当用户问“你现在能帮我做什么？”时，Claude可以调用这个工具，然后根据返回的列表，生成一个面向用户的、自然的能力介绍。

更进一步，你可以创建get_tool_help工具，传入工具名称，返回该工具的详细使用说明和示例。这相当于为你的工具系统构建了一个内置的、模型可访问的“帮助文档”。

6.4 与函数调用（Function Calling）的生态融合

Claude Code的工具调用机制，在理念上与OpenAI的Function Calling、Google Gemini的Function Calling高度相似。它们都遵循“模型生成结构化调用请求 -> 宿主执行 -> 返回结果”的模式。这意味着，一旦你为Claude实现了一套工具调用框架，其核心思想可以相对容易地适配到其他主流模型。

许多开源的AI应用框架（如LangChain、LlamaIndex）已经提供了抽象层，允许你用一套接口定义工具，然后无缝切换底层的模型提供商。如果你的应用需要考虑多模型支持或避免供应商锁定，研究这些框架会很有帮助。不过，我的建议是，初期先基于一个模型（如Claude）把工具调用的核心逻辑跑通、跑稳，理解其中的所有细节和坑，然后再考虑引入抽象层。过早的抽象可能会掩盖不同模型在工具调用行为上的细微差异，导致调试困难。

工具调用正在成为大模型与真实世界交互的标准范式。Claude Code的机制以其清晰、安全、高效的特点，为我们提供了一个优秀的实现样板。从定义清晰的工具契约，到构建安全的执行环境，再到处理复杂的多轮交互和错误情况，每一步都需要精心设计。

编程学习 学习日记 实战经验
← 返回列表