我们说过，模型负责「想」，工具负责「做」。这一篇往下挖一层：模型是怎么「点名」要调用哪个工具的？为什么同样的工具，有的智能体用得溜，有的用得一塌糊涂？以及最近被反复提起的 MCP，到底改变了什么。
01一、模型并不会真的动手，它只是「提出请求」
先纠正一个常见误解：模型从来不执行任何代码。它做的事情，是输出一段结构化的调用请求——我要调用天气接口，参数是「北京」「明天」。
真正去执行的是外面那个程序：它拿到请求、调用接口、把结果回传给模型，模型再据此决定下一步。一轮轮下来，一件事就这么办成了。
所以智能体其实是两部分的合体：会思考的模型，加会办事的程序。缺了后者，模型再强也只能干瞪眼——它能告诉你该查天气，却没法替你查。
这套机制有个名字，叫函数调用（Function Calling）。它是今天几乎所有智能体能「动手」的地基。
02二、工具好不好用，八成取决于「说明书」
有意思的地方来了：工具在模型眼里，就是一段文字描述——这个工具叫什么、能干什么、需要哪些参数、返回什么。模型完全是靠读这段话来决定用不用、怎么用的。
于是问题就变成了：说明书写得含糊，模型就会乱用。该调用的时候不调用，不该调用的时候乱调用，参数填错单位，返回格式理解反了——这些都不是模型笨，而是它读到的信息不够明确。
工程上有三条被反复验证的经验：名称和用途要写到具体场景，别写「通用查询工具」这种话；参数要说清单位和格式，「时间」是时间戳还是自然语言，差别很大；工具别一股脑全塞进去，几十个工具堆在一起，挑错的概率会明显上升。
所以「接工具」现在已经被当作一门专门的工程来做，业内甚至给了它一个名字，叫上下文工程——研究的就是怎么把信息组织好喂给模型，让它少犯错。
03三、MCP：把接工具从手工作坊变成插头标准
如果说函数调用解决了「能不能用工具」，那接下来要解决的是「接工具太麻烦」。
以前，每个工具都要为每个应用单独写一遍适配代码。N 个应用乘以 M 个工具，就是 N×M 份重复劳动，谁接谁知道有多痛。
MCP（Model Context Protocol）做的事，是给「模型与外部系统之间的连接」定一个通用接口：工具方按标准做一次，应用方按标准接一次，两边就此解耦。
它很像 USB-C——不是它发明了充电，而是它让「谁都能插上」。带来的实际变化是，工具生态可以独立生长：今天接个数据库，明天换个内部系统，不用每次推倒重来。
04四、工具越多，未必越强：三个真实的坑
接上工具只是开始，用得好是另一回事。实践中常见的三个坑是：
▪︎ 选择困难：工具列表越长，模型挑错的几率越高。与其给五十把工具，不如给它三五把趁手的；
▪︎ 错误会传导：工具返回了错数据，模型往往照单全收，还会把错误「合理化」成一个看起来很合理的结论；
▪︎ 权限被放大：每接一个工具，就多一条通往现实世界的通路。能读就能写，能写就有风险，这是护栏设计必须前置考虑的事。
所以工具的价值不在「多」，而在「准」——准到它知道什么时候该用，也知道什么时候不该用。
05五、怎么判断一个智能体的「手脚」灵不灵
作为使用者，你可以用三个问题快速判断一个智能体到底有没有在用工具，还是在演：
▪︎ 遇到没有工具能办的事，它是老实说办不到，还是硬编一个答案给你？——前者才是在真用工具；
▪︎ 参数不全时，它是停下来问你，还是自己瞎猜一个？——会追问的智能体，通常更可靠；
▪︎ 它说查过数据库，有没有给出可追溯的来源？——给不出来源的结论，多半是生成出来的，不是查出来的。
三条加起来，其实是在问同一件事：这个智能体是真在调用真实世界，还是只是说得像。
06结语
模型决定了智能体能想到什么，工具决定了它能做到什么。当「连接」这件事的成本被 MCP 这样的标准摊薄之后，竞争的重心会回到一个很朴素的问题上：你手里，到底有多少值得被调用的能力。
