话说回来，

先说说我最开始的离谱误解

我最开始写 Demo 的时候。想法特别天真：不就是传个 tools 配置进去吗，大模型拿到问题，自己调用函数，直接把答案返回给我不就完了。结果第一次跑完接口，我打印返回的 message 对象，当场就懵了。content 字段是空的，反而多了个从没见过的 tool_calls 数组。里面有 id、有函数名、还有一串 JSON 格式的参数。我心想这啥啊，我要的苹果 价格呢？怎么给我返回了段看不懂的结构？

后来我翻了文档。又对着输出琢磨了半天才突然反应过来一件事 —— 我们天天挂在嘴边的大模型，本质上就是个困在服务器里的「缸中大脑」。它除了坐在那预测下一个词的概率，啥都干不了。它看不见外面的世界，摸不到数据库，也发不了真实的 HTTP 请求。你问它今天上海多少度，问它苹果 卖多少钱。它训练数据里的信息早就过时了硬答就是一本正经地胡说八道。其实，那它是怎么实现「调用工具」的吗？说穿了全是演的，是我们开发者和大模型联手，给使用者造的一种精致错觉。

再看第一步先。把工具翻译成大模型听得懂的话

要让一个只会接话的模型学会用工具，第一步先不是给它权限，而是给它写说明书。就像你教一个从没见过微波炉的人用微波炉，你不能甩给他一本电路原理图。你得用大白话讲：「这东西叫微波炉，你告诉它要加热什么、加热几分钟，它就能帮你把饭弄热。」

落到代码上，就是我们写那段 tools 配置。

const tools =,}
},},{
type的观点是，'function',function: {
至于name，'get_wear',description: '获取指定城市的实时天气情况',parameters: {
至于type，'object'。properties: {
从city来看，{
说到type，'string',description: '城市名称',},},required:,}
},},]

这段 JSON Schema 根本不是给运行时代码看的，而是写给大模型读「使用说明书」。我们把一个复杂业务函数降维成纯文本描述：有什么工具、叫什么名字、能干什么、要传什么参数、参数类型与必填项。这叫认知植入——在对话开始前，把工具存在与用法悄塞进上下文里让模型能“读懂”而非真正理解 API。话说回来，

说到接下来。大模型自言自语——意图识别

当使用者问「苹果手机价格是多少？」时大模型内部会：

• 意识到自己的知识库无法回答。
• 找到刚才塞进来的工具说明书。
• 匹配合适功能并生成对应指令。

于是它不会继续跟使用者对话。而是中断输出并返回一段结构化 tool_calls. 它不是实际调用，只是在生成指令等待外部执行。

*使用者痛点*：误认为“调用”即执行导致错误反馈

：真正干活的是 Runtime

指令生成后由我们的代码去执行。再看例如，

async function sendMessage{
const completion = await client.chat.completions.create({
model这方面。,messages:,tools:,tool_choice:'auto'
});老实说，return completion;}

A 常见坑：将工具执行结果随便塞回消息。却忘记设置 ,而且缺少对应 . 大模型会因 ID 不匹配而无法识别结果。

*使用者痛点*：遗漏 tool_call_id 导致回复失败*

*能直接跑的小 Demo*

import OpenAI from 'openai';import dotenv from 'dotenv';dotenv.config;话说回来，const client = new OpenAI({
apiKey : process.env.DEEPSEEK_API_KEY。baseURL : process.env.DEEPSEEK_API_BASE_URL
});const tools =;// 如上定义
function get_closing_price{
if) return '';if) return '';return '商品不存在';老实说，}
async function main{
let messages=;// 第一次交互
const res1=await sendMessage;const msg1=res1.choices.message;messages.push;if{
const call=msg1.tool_calls;if{
const args=JSON.parse;const price=get_closing_price;messages.push({
再看role，'tool'。content : price,tool_call_id : call.id
});// 第二次交互得到最终回答
const res2=await sendMessage;console.log，}
}
}
main;

*踩过两个坑。你们别再踩*

• PITFALL-1： tool 消息角色和 id 必须匹配，否则无法关联；“你说的是啥由常被忽略导致？” 的困惑，
• PITFALL-2： tool 描述太含糊导致误触。例如仅写 “获取商品价格”，会被错误触发于非相关查询；精确描述可避免无谓调用，

*使用者痛点*：描述模糊导致频繁错误调用*

*最终两句实在的话*

Diligently 理解流程后我意识到“AI 工具调用”是一种新旧编程范式拼接。话说回来，一侧是擅长自然语言理解但不可控的大模型。一侧是稳定精准却需人工接口定义传统代码。我们通过结构化协议将两者连结，让大模型做决策，小程序完成执行。本质还是“大模型拍板+代码干活”。：

1. 不要神化 Tool Call： 大模型只是按说明书生成指令；若出错责任仍归代码实现方，需要加入校验与兜底逻辑。
2. Simplicity & Clarity is Key： 像接口文档一样。把工具描述和参数约束写清楚，可显著减少误触与错误。