从 @Tool 装饰器到 MCP，浅析大模型工具生态与 Function Calling 的底层逻辑

从 Tool 装饰器到 MCP浅析大模型工具生态与 Function Calling 的底层逻辑在开发 LLM Agent大模型智能体时我们经常会遇到各种层出不穷的技术名词Function Calling函数调用、JSON Schema、LangGraph 中的tool 装饰器以及最近大热的MCPModel Context Protocol模型上下文协议。初学者很容易陷入迷茫“既然我用几行 Python 代码加个 tool 就能让大模型调用本地函数为什么行业还在大费周章地推崇 MCP 协议它们之间到底是什么关系”本文将以一个通俗易懂的视角为你彻底拆解大模型工具生态的底层逻辑、演进过程以及它们在实际生产中的真实协作方式。一、 核心概念分清“点菜”与“做菜”要理清这套生态首先必须纠正一个常见的误区tool 或 MCP 并不等于 Function Calling。它们处于整个交互流程的不同阶段。我们可以用一个“在餐馆点餐”的经典场景来做类比菜单工具定义 / JSON Schema告诉客人店里有什么菜需要什么配料。点菜Function Calling客人大模型看完菜单后做出决策并喊出具体菜名和要求。后厨做菜工具执行服务员把订单传给厨房厨房真正开火把菜做出来。有了这个心智模型我们再来看技术层面的具体定义1. 什么是 Function Calling大模型的“意图表达”大模型LLM本身是不能直接运行 Python 代码、也不能直接读写数据库的。当用户输入“帮我查一下明天北京的天气”时大模型自己无能为力。Function Calling 的本质是大模型的思考决策过程。当它发现靠自身无法解决问题时就会决定“召唤”外部工具。此时它不执行任何代码而是输出一段结构化的数据通常是 JSON告诉你的外围代码“我选好工具了请帮我用这些参数执行它”。大模型吐出的 Function Calling 结果通常长这样JSON{ name: get_weather, arguments: { location: 北京, date: 明天 } }2. JSON Schema大模型看得懂的“说明书”大模型既然要“做选择题”选工具和“填空”填参数它总得事先知道有哪些工具可选。JSON Schema 就是大模型唯一能读懂的“工具说明书”。无论是 LangGraph 的 tool 还是 MCP 工具它们在底层都必须被翻译成标准化的 JSON Schema包含工具名、功能描述、参数类型等发送给大模型。大模型正是通过阅读说明书里的 description 来判断何时该用这个工具。二、 本地 tool vs 跨平台 MCP单机开发与分布式生态既然大模型对所有工具的调用最终都表现为 Function Calling那么 tool 和 MCP 的区别到底在哪里区别在于“工具的包装、发布与运行方式”。1. LangGraph 的 tool快捷的本地 App当你写下如下代码时Pythontool def get_weather(city: str) - str: 查询指定城市的天气预报。 # 具体的查询逻辑 return f{city}明天晴天LangGraph 框架会在后台自动提取这个函数的名称、文档注释Docstring和参数类型将其自动转化为 JSON Schema 发送给大模型。优势极简。心智负担极低非常适合单机开发或快速写个 Demo。劣势强绑定。这个工具被死死地绑在了当前的 Python 环境和 LangGraph 生态里。如果你明天想用 TypeScript 写一个新项目或者想在另一个框架如 AutoGen或 Cursor 等 IDE 里复用这个工具你就必须用对应的语言和框架把这段逻辑重写一遍。2. MCP万维网的 HTTP 协议MCPModel Context Protocol由 Anthropic 提出它的核心思想是将工具的“定义与运行”从 Agent 框架中完全剥离。MCP 引入了标准的客户端-服务器Client-Server架构。你用任何语言Python、Go、TypeScript 等写一个 MCP 服务器把它发布在网络上通过 Stdio 或 SSE 传输。任何支持 MCP 协议的客户端无论是 LangGraph、LlamaIndex、Cursor 还是 Claude 官方客户端都能直接插上使用根本不需要重写代码。3. 维度对比表为了让你更直观地看出两者的适用场景我们可以进行如下对比维度LangGraph toolMCP (Model Context Protocol)开发体验极简。直接写本地函数加个装饰器即可。稍显繁琐。需要启动并维护一个集成了 MCP 协议的微服务。跨语言/跨框架强绑定。通常绑定在特定的语言和生态内。完全通用。只要客户端和服务器都支持 MCP技术栈完全无所谓。安全性与架构本地运行。工具代码和 Agent 逻辑混在一起容易互相影响。隔离运行。工具作为独立微服务运行可具备独立的沙箱与权限控制。生态复用零散。很难直接拿别人写好的代码来用通常需要复制粘贴。开箱即用。社区有大量现成的 MCP 服务器如 GitHub、Postgres配置一下即可。三、 工具爆炸的终极挑战大模型如何动态发现工具在简单的 Demo 中你只有 3 个工具框架每次都会把这 3 个工具的 JSON Schema 全量塞进系统提示词System Prompt里。但在实际的企业级生产中你可能会面对成百上千个工具例如公司内部的所有 API 接口、各种数据库连接器。如果每次都全量注入将带来两个灾难性的后果Token 成本爆炸光是工具说明书就会吃掉几万个 Token每次对话都在无谓地烧钱。注意力分散Context Rot工具太多大模型会“挑花眼”导致工具调用的准确率急剧下降。为了解决这个问题现代高级 Agent 系统绝不是把说明书一次性拍在大模型脸上而是采用了“动态工具发现”的架构策略方案 1工具检索器Tool RAG—— 当下的主流将工具的“找寻”变成一个搜索过程。开发人员将成百上千个工具的名称和描述转化为向量嵌入Vector Embeddings存入向量数据库。用户输入“帮我查一下昨天财务报表里的利润率。”外围的传统代码无需大模型先去向量数据库里检索找出与“财务、报表、利润”最相关的 3-5 个工具。框架只把这几个被选中的工具的 JSON Schema 动态注入到当前的提示词中再交由大模型做最后的 Function Calling 决策。方案 2分层/多 Agent 架构Hierarchical Delegation不让一个大模型管所有的事而是采用“总管 专家”的模式。Router Agent总管只给它注入高层级的工具分类如[财务工具箱]、[日常办公工具箱]。Specialist Agent专家当总管判断当前任务属于财务时将任务指派给财务专家子 Agent。此时财务专家的提示词里只会注入具体财务相关的 5 个工具。四、 总结未来的主流架构回到最初的问题有了 tool我们还需要 MCP 吗答案是它们在未来是共存且融合的。你不需要在 LangGraph 和 MCP 之间二选一。在未来的复杂企业级 Agent 系统中你的架构大概率是这样的本地特异性工具对于那些只跟当前项目状态State紧密关联、逻辑简单的本地操作继续用 tool 定义图个方便快捷。企业基础设施与第三方生态比如公司内部的数据库查询、GitHub 企业版对接、或者复杂的文档解析器将它们做成MCP 外部服务。然后让你的 LangGraph 作为 MCP 客户端通过网络把这些外部工具动态拉进来。通过将Function Calling 作为核心大脑决策JSON Schema 作为沟通语言tool 解决本地敏捷开发MCP 解决跨平台分布式生态我们才真正拥有了一个可扩展、高可用的生产级 AI Agent 架构。