面试官：大模型连外部工具，为什么要用 MCP 协议而不是直接写 Function Calling？

面试官大模型连外部工具为什么要用 MCP 协议而不是直接写 Function Calling最近面了好几个做 AI Agent 的同学简历上清一色写着“基于大模型搭建 Agent实现外部工具调用”。但我顺口问一句“既然你做工具调用那你们接入新工具是手写 Function Calling 还是用了 MCP 协议为什么”结果一半人懵了甚至有人反问“MCP 是什么能吃吗”今天咱们不搞玄乎的概念直接从平时写代码的痛点出发扒一扒为什么 Anthropic 要大力推 MCPModel Context Protocol协议它到底在解决什么实际问题。以前手写 Function Calling 痛在哪大模型刚火的时候我们要让 AI 能查天气或者查数据库标准做法就是 Function Calling。整个流程大概是这样你在代码里写个查天气的函数然后写一堆 JSON Schema 告诉大模型这个函数叫什么名字、有几个参数、分别是什么类型。大模型推理完返回一个包含函数名和参数的 JSON你的代码解析这个 JSON去调真实的天气 API最后把结果塞回 Prompt 里再发给大模型。如果是写个简单的 Demo这套流程没啥毛病。但如果你在公司里真要落地一个生产级 Agent问题马上就来了接口爆炸假设你的 Agent 需要连公司的 Jira 查 bug、连 GitLab 看代码、连 Confluence 搜文档。你需要自己写对接 Jira、GitLab、Confluence 的三套代码还要把这几十个 API 全转成 JSON Schema。耦合太重Jira 的接口改了或者你想加个新参数不仅要改业务逻辑还要改给大模型看的 JSON Schema。AI 客户端和底层工具链死死绑在一起。没法复用你写好的这套 Jira 对接逻辑隔壁组想用在他们的 Agent 里不好意思叫他们把你的代码拷过去再改改吧。发现没有Function Calling 只规定了大模型和你的代码怎么交流但根本没规定你的代码和外部工具怎么交流。MCP 是怎么破局的MCP 并不是用来替代 Function Calling 的它解决的是工程架构问题。它在 AI 客户端比如你用的 Claude Desktop 或者自研 Agent和外部工具之间硬生生插了一层标准化的 Client-Server 架构。有了 MCP上面的流程变成了这样外部工具比如 Jira、GitHub、本地文件系统都被封装成独立的MCP Server。你的 Agent 是MCP Client。自动发现Agent 启动时连上 GitHub MCP Server第一件事就是问“你能干啥”Server 会自动把手里的工具比如search_repositories、get_issue和格式发给 Client。你再也不用在 Agent 代码里手动维护长篇大论的 JSON Schema 了。安全与隔离GitHub 的 Token 配置、分页逻辑、报错处理全在 MCP Server 里。Agent 只负责说“我要用search_repositories工具参数是这个。”Server 去调完 GitHub直接把结果吐回来。即插即用今天你想让 Agent 连公司的内部知识库只需要有人用 Python 或 TypeScript 写个简单的知识库 MCP Server 跑起来。任何支持 MCP 协议的 Agent无论是你自己写的还是各种开源端连上这个 Server 就能直接具备查知识库的能力。举个具体的例子。如果你现在要在本地装一个能看你电脑文件的 AI。以前的做法是这个 AI 软件必须自己拿到读取你硬盘的系统权限然后自己实现文件读取代码。而用 MCP你只需要在本地跑一个官方开源的filesystemMCP Server。AI 客户端通过标准协议请求这个 Server 读文件。Server 代码是开源的你能清楚看到它到底能读哪些目录安全性完全捏在你自己手里。总结什么时候用谁很多同学搞混这两者其实它们根本不在一个层面上。Function Calling 是底层机制MCP 是上层基建。如果你只是写个几十行的 Python 脚本用大模型处理一下爬虫抓下来的网页直接写 Function Calling 最快。但如果你在做的是一个正儿八经的 Agent 平台或者你的 AI 助手需要同时连接本地 IDE、公司内网 API、各种 SaaS 服务那就尽早引入 MCP 协议。别把成百上千个工具链的维护成本全砸在写 AI 客户端的工程师头上。下次面试官再问起别光说你会写 JSON Schema 了。讲清楚工具解耦和协议标准化的价值这才是工程经验。