面试官问 Function Calling、MCP、A2A 的区别与联系表面上是考概念实际上是在考你头脑里有没有一套完整的 AI Agent 技术栈视图。很多同学能背出三者的英文全称但一被追问“你的 Agent 项目到底用了哪一层为什么用”就卡壳。这篇文章不绕弯子直接用“是什么、解决什么、怎么协作、面试怎么说”四个维度拆开讲。看完你不仅能答区别还能画出它们之间的关系图应付技术面和项目深挖都够用。1. 三个概念一句话定位先给结论后面展开。概念一句话定位解决的核心问题Function Calling让大模型输出结构化调用指令把“对话”转成“函数调用”模型如何触发外部工具MCP统一工具接入协议类似“AI 工具的 USB-C 接口”工具如何标准化接入不同 AgentA2A智能体与智能体之间的通信协议类似“Agent 界的 HTTP”Agent 之间如何发现、协作、传递任务三者的层次是递进的Function Calling 是模型能力层面的东西。MCP 是工具接入层面的东西。A2A 是智能体协作层面的东西。你可以这样理解Function Calling 让模型伸出手去够工具MCP 让工具变得“即插即用”A2A 让不同的 Agent 之间能互相说话、互相派活。2. Function Calling让大模型学会“调用工具”2.1 为什么需要 Function Calling早期大模型只能做文本生成遇到“帮我查一下北京的天气”这种问题模型会一本正经地编一个天气出来因为它没有实时数据访问能力。解决办法就是让模型输出一个结构化的“调用意图”由程序去执行真实的 API再把结果返回给模型让模型基于结果组织回答。Function Calling 不是一种网络协议也不是一种服务框架而是模型训练和推理层面的一种能力封装。OpenAI 在 2023 年 6 月的更新中首次把这个能力作为 API 参数暴露出来之后几乎所有主流模型都跟进了。2.2 工作原理拆解一次典型的 Function Calling 流程分四步开发者定义工具函数并把函数的 JSON Schema 描述传给模型。模型根据用户输入判断该调用哪个函数并生成结构化的参数。程序接收模型的调用结果真实执行函数。把执行结果拼接给模型模型组织自然语言回复。这四步就是你跟模型 API 交互时完整的“回合”流程。关键在于第 1 步和第 2 步函数描述写得越清楚模型选函数、填参数就越准。2.3 一个最小示例假设我们要给模型加一个“查询订单”的能力函数的 JSON Schema 大概是这样的{ name: get_order_status, description: 根据订单 ID 查询订单当前状态, parameters: { type: object, properties: { order_id: { type: string, description: 订单编号 } }, required: [order_id] } }调用 API 时把这段描述放到 tools 参数里from openai import OpenAI client OpenAI() response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 帮我查一下订单 20241001 的状态}], tools[ { type: function, function: { name: get_order_status, description: 根据订单 ID 查询订单当前状态, parameters: { type: object, properties: { order_id: { type: string, description: 订单编号 } }, required: [order_id] } } } ] ) # 模型不会直接回答而是返回 tool_calls 指令 print(response.choices[0].message.tool_calls)模型返回的 tool_calls 里包含函数名和参数 JSON开发者的程序拿到后执行真实的get_order_status函数再把结果以role: tool的消息送回模型模型生成最终回复。2.4 Function Calling 的痛点Function Calling 本身没问题问题出在“工具接入”这件事上。假设你的 Agent 需要调用 20 个工具查天气、查订单、发邮件、操作数据库、调用内部 CRM……你就要为每个工具写一遍 Schema 描述然后在代码里写一遍工具分发逻辑。换一个 Agent 框架又要重写一遍。工具越多接入和维护成本越高。这就是 MCP 出现的背景。3. MCP把工具接入变成“即插即用”3.1 MCP 是什么MCPModel Context Protocol是 Anthropic 在 2024 年 11 月开源的一套开放协议核心目标是把“工具接入”标准化。你写一个 MCP Server把工具能力暴露出来任何支持 MCP 的 AgentClaude Desktop、Cursor、Codex、Cherry Studio 等都可以直接连接使用。关于 MCP 有一个很形象的类比如果说 Function Calling 是让你为每个设备单独配一根充电线那 MCP 就是通用的 USB-C 口。设备厂商只需要把接口做成 USB-C你就不用关心设备底层的协议差异。这也解释了为什么前段时间搜索热词里全是“Cursor 配置 MySQL 的 MCP”“Codex 如何接入 MCP”“VSCode Copilot 连接 Figma MCP”——因为这些工具都在快速支持 MCP用户只需要写一个配置文件就能把外部数据源、设计稿、数据库全部接到自己的 AI 编程助手里面。当前主流的 AI 编程 IDE 和各类 Agent 框架基本都已把 MCP 作为标准配置能力开放给用户。3.2 MCP 架构三件套MCP 的架构中有三个角色角色作用类比MCP Host运行 Agent 的主程序如 Claude Desktop、Cursor电脑操作系统MCP ClientHost 内部与 Server 建立连接的通信组件负责协商协议和收发消息操作系统里的驱动MCP Server暴露工具、Prompt、Resource 的独立服务可以理解为“工具能力的提供方”即插即用的外设三者关系是Host 启动后内部会创建 ClientClient 再去连接 ServerServer 把工具列表和调用方法广播给 HostHost 里的模型就可以通过 Function Calling 触发这些工具。这里有一个很容易混淆的点MCP 和 Function Calling 不是二选一的关系。MCP 是组织工具的“接入标准”而模型真正触发工具时底层依然依赖 Function Calling 能力。打个比方MCP 负责把工具的插头做成统一规格模型的手伸出来抓工具时抓到的依然是一个具体的函数调用。3.3 MCP Server 配置示例以 Cursor 这类支持 MCP 的 IDE 为例接入一个 MCP Server 通常只需要在配置文件里声明{ mcpServers: { mysql: { command: npx, args: [ -y, modelcontextprotocol/server-mysql ], env: { MYSQL_HOST: 127.0.0.1, MYSQL_PORT: 3306, MYSQL_USER: root, MYSQL_PASSWORD: yourpassword } } } }配置完成后AI 编程助手就拥有了直接查询数据库的能力。同样的配置方式也适用于其他各类 MCP Server。如果你要自己实现一个 MCP ServerSDK 已经非常成熟Python 和 TypeScript 都有官方支持。核心工作就是定义工具名、参数 Schema、处理函数然后把 Server 跑起来。from mcp.server.fastmcp import FastMCP mcp FastMCP(demo-server) mcp.tool() def query_order_status(order_id: str) - str: 查询订单状态 # 这里写真实的业务查询逻辑 return f订单 {order_id} 状态已发货 if __name__ __main__: mcp.run()这里需要说明一下MCP SDK 的 API 迭代比较快不同版本下 FastMCP 的写法略有差异实际使用时建议直接参照你安装版本对应的官方 README。关键是要理解 MCP 的模型——定义工具、暴露服务、让 Client 消费——至于具体装饰器和启动函数查文档即可。3.4 MCP 解决的工程问题MCP 解决的是“接入方式碎片化”的问题。在没有 MCP 之前每接一个工具就要写一遍工具描述、鉴权逻辑和参数校验换一个 Agent 框架又要重写。有了 MCP 之后开发者只需要把工具封装成标准 Server就能被任何 MCP 客户端复用。用工程化的话说MCP 把工具的发现、描述、调用、鉴权四项标准化了。工具提供方只写一次 Server消费方只做一次配置。4. A2A智能体与智能体之间的“语言”协议4.1 A2A 是什么A2AAgent2Agent是 Google 于 2025 年 4 月发布的智能体互操作协议目标是解决“不同厂商、不同框架的 Agent 之间如何协作”的问题。MCP 解决的是 Agent 与工具之间的连接而 A2A 解决的是 Agent 与 Agent 之间的连接。如果你的系统里有多个 Agent比如一个 Agent 负责订单处理另一个 Agent 负责物流查询还有一个 Agent 负责客户回访A2A 能让它们以标准化的方式互相发现、互相调用。A2A 协议的核心设计可以拆成三块能力Agent Card每个 Agent 通过一个 JSON 文件宣告自己的能力、接口地址和认证方式相当于“Agent 的自我介绍”。任务生命周期管理Agent 之间通过创建任务、查询状态、取消任务来完成工作流转。消息与工件传输Agent 之间传递的不仅是文本消息还有结构化数据和文件引用。4.2 A2A 的通信模型A2A 采用客户端-服务器的通信模型一个 Agent 可以是另一个 Agent 的客户端。基本流程是Agent A 读取 Agent B 的 Agent Card。Agent A 根据能力描述决定是否把任务交给 Agent B。Agent A 向 Agent B 发送任务请求。Agent B 执行任务并返回状态和结果。Agent Card 的结构大致长这样{ name: order-service-agent, description: 负责订单查询、订单状态更新与订单异常处理, url: https://api.example.com/agent, capabilities: { skills: [ { id: query_order, name: 查询订单, description: 根据订单号查询订单详细信息 } ] }, authentication: { scheme: bearer } }上面这个例子只是一个概念示意具体字段名以 A2A 协议规范文档为准。核心思路是Agent 通过标准化的 JSON 暴露能力其他 Agent 不需要知道对方内部实现只要按协议发请求就能完成协作。4.3 A2A 与 MCP 的本质区别有人在网上问“A2A 会不会取代 MCP”这个问题本身就问错了。两者的定位完全不同维度MCPA2A解决对象Agent 与工具之间的连接Agent 与 Agent 之间的连接协议角色Host/Client/ServerClient/Server传输内容工具调用、资源读取、提示词任务创建、状态同步、消息传递核心价值工具接入标准化Agent 协作标准化类比USB-C 接口HTTP 协议MCP 和 A2A 在真实系统中是协作关系一个 Agent 通过 MCP 连接大量工具再通过 A2A 连接其他 Agent。A2A 协议里 A2A 的官方文档也给出过 Agent、A2A 和 MCP 的分层架构示意——MCP 层负责工具供给A2A 层负责 Agent 间的互操作两者各司其职。从目前的生态趋势来看A2A 的标准化进程还在早期但已有多个 Agent 框架开始跟进。比如 AgentScope 2.0 这类多智能体协作框架在设计上就考虑了 A2A 模式的智能体协作谷歌也在快速推动云产品对 A2A 的支持。未来 Agent 之间的互操作会越来越依赖这一层协议。5. 三者对比速查表把这些知识点整理成一张表方便面试前快速过一遍。对比维度Function CallingMCPA2A本质模型能力协议标准协议标准核心目标让模型输出可执行的函数调用指令统一 Agent 接入外部工具的路径统一 Agent 之间的通信方式引入方OpenAI 推动各模型厂商跟进Anthropic 开源推动Google 推动作用层级模型层工具层Agent 协作层主要角色模型、函数定义、工具结果Host、Client、ServerClient、Server、Agent Card传输内容函数名 参数 JSON工具调用、资源、提示词任务、消息、工件生命周期单轮请求-响应连接-发现-调用发现-建任务-跟踪-完成是否可独立使用可以这是模型基础能力可以但底层配合 FC可以通常也配合 FC 与 MCP常见应用各类大模型 API 工具调用Cursor、Codex、Claude Desktop 等接入外部工具多 Agent 协作系统目前成熟度很成熟几乎所有模型都支持生态快速增长已被主流 AI 工具采用协议刚发布不久标准化过程中6. 三者的协同一个完整场景理解三者关系最好的方式是看它们在真实业务里如何配合。假设你在做一个“智能客服助手”系统里有三个 Agent订单 Agent负责查询订单、处理售后。物流 Agent负责查询快递轨迹。话术 Agent负责生成客服回复。用户发来一句话“我上周买的手机怎么还没到”.第 1 层Function Calling客服助手的 LLM 接收用户消息判断需要调用“查询订单”工具于是输出一个结构化的调用指令{ name: query_order, arguments: {\keyword\: \手机\, \time_range\: \last_week\} }这是模型层的 Function Calling 能力。第 2 层MCP客服助手要查询订单但它不需要关心订单数据在 MySQL 还是 CRM 系统也不需要在代码里硬编码数据库连接。订单查询能力已经封装成一个 MCP Server客服助手的 Host 通过 MCP 协议连接这个 Server调用query_order工具拿订单号。第 3 层A2A拿到的订单号需要传给物流 Agent 去查轨迹。这里不需要客服助手自己去实现物流系统的接口而是通过 A2A 协议读取物流 Agent 的 Agent Card发送一个“查询物流轨迹”的任务请求物流 Agent 执行后返回结果。最终客服助手把订单信息和物流轨迹汇总生成自然语言回复给用户“您的手机已于昨天从上海发出当前运送中预计明天送达。”这个例子里的三层协作分别对应了 Function Calling模型决定调工具、MCP标准化接入数据源、A2AAgent 之间派单和协作。三者各管一段互为补充。7. 面试官想听到的答案结构面试官问这个问题时他最想验证的是你有没有“分层意识”。最好的回答不是背定义而是按“能力层、接入层、协作层”的结构讲。参考回答模板Function Calling 是大模型本身具备的一种能力它让模型把自然语言输入转为结构化的工具调用指令解决的是“模型如何触发外部工具”的问题。MCP 和 A2A 都是协议标准但解决的问题不同MCP 解决的是 Agent 和工具之间的标准化接入问题让开发者写一次工具接入就能在所有支持 MCP 的 Agent 中复用A2A 解决的是 Agent 与 Agent 之间的互操作问题让不同框架的智能体能够互相发现能力、创建任务、同步进度。在实际系统中三者是叠加关系模型通过 Function Calling 感知到需要调用工具工具通过 MCP 标准化接入复杂任务再由 Agent 之间通过 A2A 协作完成。这段话不长但涵盖了定义、差异、联系、实际应用四个维度面试官听完就知道你理解的是整个体系而不是背了几个名词。7.1 面试官可能会追问的问题追问 1“MCP 和 Function Calling 有冲突吗” 答不冲突。Function Calling 是模型的组织能力MCP 是工具组织方式。MCP Server 暴露的工具最终还是要靠模型输出来触发。你可以理解为 MCP 把工具的“插头”做成标准化接口模型把手伸出去拿工具时依然要动用自己的调用能力。追问 2“什么时候用 MCP什么时候自己写工具接入” 答当工具需要被多个 Agent 或多个客户端复用时优先用 MCP因为标准化后一次接入处处复用如果只是单个项目内部的一个私有函数直接写 Function Calling 的成本更低。追问 3“A2A 会替代 MCP 吗” 答不会。MCP 是 Agent 连外设A2A 是 Agent 连 Agent。两者在架构上是互补的。甚至在一个系统中A2A 的某个 Agent 内部也会通过 MCP 来接入工具。追问 4“你项目中实际用过哪些” 答如果用过就如实说比如在 Cursor 里配置了 MySQL 的 MCP Server、用 Function Calling 给模型接了内部订单查询接口。如果没用过 A2A就说“目前项目里还没到多 Agent 协作的复杂度但我关注到谷歌已经发布协议规范后续会做技术预研”。追问 5“本地模型支不支持 Function Calling” 答现在很多开源本地模型也支持 Function Calling或者通过微调获得类似能力。但本地模型在复杂工具选择、参数填充的准确率上通常不如商业模型这也是低显存场景下做 Agent 的一个瓶颈。7.2 技术深度加分项如果你想让面试官觉得你不只是“懂概念”可以主动补充一些横向对比的话题比如MCP 的兴起和 Anthropic 的生态布局。可以聊一聊为什么 MCP 快成为事实标准并把它和历史上各类“标准化协议”的演进做类比。为什么 A2A 出现以后很多人会把它和早期 SOAP/REST 的对比联系起来。Agent 需要标准化通信但通信粒度定多粗、任务状态怎么同步每一个细节都对最终效果影响巨大。MCP 和传统的 API 网关、函数计算有什么重叠和不同。这类话题会显得你视野比较广。8. 实践建议从本地项目开始验证如果你不想只停留在“会答面试题”的层面建议直接动手把一个最小的“三件套”跑起来。8.1 本地模型 Function Calling在有限显存的环境下推荐优先测试 Qwen 系列如 Qwen2.5-7B-Instruct这类对工具调用支持较好的开源模型使用 Ollama 等框架快速启动参考 API 文档中关于tools参数的说明测试模型能否稳定选对工具、填对参数。这里有个容易踩的坑本地小参数模型的 Function Calling 能力不稳定经常出现“知道该调函数但参数传错”的情况。建议提升参数描述质量多加示例甚至对关键参数做一次校验。8.2 自己写一个 MCP Server用 Python 或 TypeScript 写一个最简单的 MCP Server 暴露两个工具然后在支持 MCP 的客户端里配置连接。第一次跑通“配置 Server — 发现工具 — 通过自然语言触发”这个链路后你会对 MCP 的定位有非常直观的感受。示例流程# 创建一个新的 Python 项目目录并安装 MCP SDK mkdir mcp-demo cd mcp-demo pip install mcp# server.py from mcp.server.fastmcp import FastMCP mcp FastMCP(demo) mcp.tool() def get_stock_price(code: str) - str: 查询股票价格 return f{code} 的最新价为 100.00 元 mcp.run()运行后在支持 MCP 的客户端中配置command为pythonargs为server.py的绝对路径连接成功后即可在对话中触发get_stock_price。8.3 结合 A2A 规划多 Agent 架构关于 A2A如果公司没有复杂的多 Agent 协作需求不急着上线但可以保持关注跟进主流 Agent 框架对其的支持情况。一旦需要在两个独立部署的智能体之间传递任务A2A 可能是比“自己写一套 HTTP 回调”更省力的标准答案。9. 总结与下一步这次梳理的三个概念本质上是 AI Agent 技术栈里三个不同层次的标准答案。Function Calling 已经是很成熟的基础能力做 Agent 开发基本绕不开MCP 正在快速变成工具接入的事实标准主流 AI 编程工具几乎都支持了A2A 虽然刚刚起步但已经给出了 Agent 互联互通的标准化方向。建议先跑通一遍最小闭环本地模型或云端模型 API Function Calling 触发工具 MCP Server 暴露工具 两个 Agent 之间模拟 A2A 任务传递。这套链路走完你不仅面试能答好做实际项目选型时也更有底。如果你只想记住一句话那就记这句Function Calling 让模型会用工具MCP 让工具好接入A2A 让 Agent 好协作。三个概念讲得再深最后都要落到“用什么、怎么用、为什么在这层用”的工程判断上。