如何让大语言模型调用外部工具？MCP技术解析与批判
想象一下，你问一个所谓“智能”的大语言模型（LLM）：“截止到今天，周杰伦有多少粉丝？”它会一脸茫然地盯着你，然后甩出一堆过时数据——毕竟，它不过是被一堆陈旧文本喂出来的“复读机”，连今天的日期都搞不清，更别提实时粉丝数了。可笑吗？有点。可悲吗？更有点。
但如果你读完这篇文章，至少能让这个“复读机”稍微聪明一点，甚至还能为你加个粉丝——前提是你愿意动手试试。
本文将拆解如何让LLM调用外部工具，解决它与现实世界脱节的尴尬。让我们从技术的角度出发，顺便带点批判的眼光，看看这背后的逻辑与陷阱。
1. 问题本质：LLM的先天缺陷
1.1 静态的“智商”
LLM的核心问题在于，它的“知识”是被冻结在训练数据里的。比如，你想知道某个实时数据，它只能给你抛出一个“对不起，我的知识截止到2023年”之类的废话。为什么？因为它本质上是个封闭系统，与外部世界没有实时连接。这就像一个自以为是的学者，书读得不少，却从不出门看看世界变了没有。
1.2 外部工具：救命稻草？
要让LLM回答实时问题，比如“轩辕有多少粉丝”，最直接的办法是给它接上外部工具——比如一个爬虫程序，实时抓取数据。但问题来了：LLM运行在云端，你的爬虫在本地，它俩隔着互联网的“长城”，怎么沟通？直接调用？做梦吧。
2. 技术解法一：Function Calling
2.1 中介程序的“翻译”角色
既然LLM没法直接访问本地工具，那就找个“中介”帮忙。这个中介程序通过API与LLM对话，充当桥梁。流程大致如下：
- 中介上线：告诉LLM，“我这儿有个爬虫工具，能干啥，怎么用，需要的话吱一声。”
- LLM分析：收到问题后，判断是否需要工具，生成调用指令。
- 中介执行：按指令调用爬虫，拿到结果，再扔回给LLM。
- LLM包装：把结果加工成自然语言，丢给你。
听起来不错吧？但这套流程的核心在于，如何让LLM和中介“对上话”。
2.2 OpenAI的标准化“说明书”
早期，大家直接把工具说明写在提示词里，简单粗暴。可惜，LLM的“智商”有限，你白纸黑字写清楚了，它还是可能满嘴跑火车，返回一堆乱码。于是，OpenAI推出了Function Calling技术，用JSON格式标准化工具描述，单独与用户输入分开。返回时，LLM用特定字段明确指出要调用啥工具、带啥参数。
优点显而易见：清晰、规范，LLM不容易“犯浑”。缺点呢？每个工具都要手写JSON“说明书”，费时费力。更别提，像Defi这样的平台，虽然能把HTTP接口转成Function Calling格式，但配置起来依旧繁琐——几十上百个工具，你愿意一个个敲吗？
2.3 安全隐患
还有个问题：工具直接暴露HTTP接口，等于把后门敞开给黑客。效率提高了，安全却打了折扣。这让我想起一句老话：“技术是把双刃剑，用得好是生产力，用不好是自杀器。”
3. 技术解法二：MCP（模型上下文协议）
3.1 封装一切的“壳”
Function Calling的麻烦和安全问题催生了MCP。它的思路很简单：既然每个工具都得费劲描述，那就封装一层“壳”，统一管理。外部工具不再直接暴露，而是被包装成MCP Server；中介程序里的MCP Client负责和Server通信。这套架构的核心组件是：
- MCP Server：工具的“外壳”，提供标准接口。
- MCP Client：中介的“触手”，与Server对接。
- MCP Host：中介的“大本营”，比如VS Code插件。
3.2 通信方式
MCP支持两种通信模式：
- 标准输入输出流：Client和Server在同一台机器上时，用进程间通信，效率高。
- HTTP SSE：跨机器时，用服务器推送事件（SSE），你看AI一个字一个字蹦出来那种效果，就是SSE的功劳。
协议基于JSON RPC 2.0，格式统一，扩展性强。
3.3 优势与代价
MCP的杀手锏是简单：用SDK加个装饰器，几行代码就搞定工具开发，不用写Web Server，也不用手敲API Schema。安全上，统一管理也减少了直接暴露的风险。但代价呢？我做了个实验，发现MCP Client与LLM通信时，直接把6万多字符的工具说明塞进提示词，烧Token烧得心疼。这效率，简直像用跑车拉煤。
4. 实验揭秘：MCP如何运转
4.1 实验设置
我写了个简单的MCP Server，内置两个工具：获取文章列表和视频列表。Client跑在VS Code插件里，连接本地8000端口，用抓包工具（Easy Teach Shark）记录通信。
4.2 通信过程
- Client发起：发JSON RPC请求，指定工具和参数。
- Server响应：通过SSE推送结果，干净利落。
但与LLM的通信让我傻眼：Client没用Function Calling，而是把工具说明一股脑塞进提示词，AI再根据约定格式返回调用指令。6万字符的提示词，堪称“Token杀手”。
5. 对比与反思
5.1 Function Calling vs. MCP
- Function Calling：标准化但繁琐，安全堪忧。
- MCP：开发简单、安全性高，但与LLM通信原始，效率低下。
5.2 技术与权力
从Function Calling到MCP，技术在封装和抽象中进步。但这背后还有个隐秘问题：谁控制这些工具？OpenAI的标准化像极了中心化的“技术霸权”，而MCP的灵活性则更偏向去中心化。可惜，当前实现还不够优雅，未来能否真正打破垄断，值得观察。
6. 结语
让LLM调用外部工具，看似技术问题，实则关乎信息自由。Function Calling和MCP各有千秋，但都不完美。技术的发展从来不是直线前进，而是充满妥协与试错。正如“编程随想”所言：“技术无罪，但用它的人有心。”在追逐效率时，别忘了问问自己：这工具，到底服务于谁？
读到这里，你是选择盲从厂商的方案，还是动手试试自己的爬虫？独立思考，从来比盲目的“三连”更有价值。