问「北京今天天气」，聊天机器人只能凭训练时的记忆猜，AI 智能体却会真的去查一下再回答。两者的差别就在工具调用机制上：模型本身只会生成文字，要查实时数据、做精确计算、操作外部软件，它必须把子任务交给专门的程序去执行。理解这条链路，就能看懂一个智能体产品的能力边界到底在哪。
模型只会生成文字，动作要外包
大模型的全部输出都是文本，这是它的工作方式决定的。它算不好多位数乘法，因为它是按概率生成数字序列；它答不了今天的天气，因为训练数据有截止日期；它发不出一封邮件，因为它没有手。工具调用的思路是分工：模型负责判断「需要什么」和「转述结果」，确定的动作交给外部程序。普通模型像一个只会动嘴的顾问，会调用工具的智能体等于配了助理团队——要数据找数据助理，要算账找财务，最后汇总给你。助理干的是确定的事，这正是可靠性提升的来源。
一次完整调用的五个环节
整条链路可以拆成五步：
- 模型输出意图：模型读到问题后，判断需要外部数据，于是它不急着作答，转而按约定格式输出一个结构化请求——工具名称加参数，比如查天气工具加「城市：北京，日期：今天」。
- 框架解析：应用侧的程序截住这段输出，解析出工具名和参数，并校验格式是否合法、参数是否齐全。
- 工具执行：框架拿着参数调用真实工具——天气接口、计算器、日历、数据库，拿到执行结果。
- 结果回填：框架把工具返回的结果作为新消息拼进对话历史，再次送给模型。
- 继续推理：模型读到结果，把它组织成一句人话回答你；如果结果不够用，它可以再发起下一次调用，循环往复。
注意一个关键分工：模型只参与第一环和第五环，中间的解析和执行都是普通程序代码。工具返回的是事实数据，模型只负责转述和整合，编造空间被压缩到环节两头。
环节之间靠什么对齐
模型怎么知道有哪些工具？接入方在每次请求里附一份工具清单，写明每个工具的名称、功能描述和参数格式。模型据此决定调不调、调哪个、传什么参数。清单写得越具体，选错工具的概率越低。参数解析失败是链路里常见的断点，应对办法是字段从简、给默认值，并让框架在校验失败时把错误信息回传给模型，让它重新生成参数。
| 链路环节 | 典型故障 | 应对方式 |
|---|---|---|
| 意图输出 | 该调工具时没调，直接凭记忆作答 | 工具描述里写清适用场景，系统提示词里明确边界 |
| 框架解析 | 参数缺失或格式不合约定 | 字段从简给默认值，校验失败回传让模型重试 |
| 工具执行 | 接口超时、返回错误 | 设超时和重试上限，错误信息如实回传而非吞掉 |
| 结果回填 | 返回内容过长，挤占上下文 | 先做摘要只留关键字段，再拼进历史 |
| 继续推理 | 拿到结果后偏离原问题 | 要求作答时引用工具返回的原始数据 |
什么活该外包给工具
判断标准只有一条：答案能不能从现成数据里算出来。算数交给计算器，比模型自己生成准得多；实时信息靠查询，绕开了知识截止的限制；发邮件、填表单、调接口，则是从「说」变成「做」的分界线。反过来说，开放式的判断、写作、总结，工具帮不上忙，仍然靠模型本身。
链路会断在哪
工具调用不等于可靠。模型可能选错工具、填错参数，工具报错时它也可能不承认失败、接着编。多轮调用还会放大延迟，每多一环，等待就多一截，速度机制在生成速度的解释里讲过。消耗同样会放大，调用轮数多意味着 token 开销大，成本对比见免费版和付费版的差异；小参数模型在工具调用上的稳定性明显弱于大模型，差别可参考参数量的影响。要紧的一条：涉及付款、删除、发送这类不可撤销的操作时，链路里必须保留人工确认这一步。
工具调用速查
- 五环节：输出意图、框架解析、执行、结果回填、继续推理
- 模型只管判断和转述，动作交给程序
- 答案能从数据算出来的，就别让模型猜
- 解析失败回传错误信息，让模型重试
- 不可撤销的操作必须留人工确认
三个常被问到的问题
- 工具调用和插件是什么关系？：插件是工具调用机制的产品化包装。底层都是同一套「结构化请求加外部执行」的流程，插件只是把工具清单、参数校验和授权做成了可直接安装的形态。
- 一次提问为什么有时答得快有时答得慢？：调用了几轮工具就有几次往返。需要串联三次查询的问题，链路要走三轮，耗时和消耗都按轮数累加。
- 怎么判断一个智能体产品接了哪些工具？：看它的工具说明或设置页里的清单，接了什么工具，能力边界就在哪。什么工具都不接的产品，查不了实时信息，也做不了实际操作。
