这是近几年 Agent 面试最高频的“送命题”如果你最近面过 Agent 相关岗位大概率遇到过这个问题Function Calling、MCP、A2A 到底有什么区别很多人的第一反应是把三个词并列在一起背定义“Function Calling 是大模型调用函数的机制MCP 是大模型连接外部工具的标准A2A 是智能体之间通信的协议。”背完之后面试官如果再追问一句“那它们在工程上分别解决了什么痛点”很多人就卡住了。这个问题的杀伤力在于它看起来是考概念背诵实际上是在考察你有没有完整经历过 Agent 工程的工具调用链路。只调用一个函数、接入一个外部 API、协调多个智能体协同这三件事的复杂度完全不同。对应到技术上它们分别指向 Function Calling、MCP 和 A2A。如果你只是见过 Demo、读过文档没有真正区分过它们的边界很容易把三个概念混成一团。本文就站在工程落地的角度把这层关系拆开讲清楚。1. 先说结论这三个东西根本不在同一个层次先把核心判断放在前面。Function Calling 是“模型按约束调用函数”的推理机制MCP 是“模型按标准协议调用工具”的接入规范A2A 是“智能体之间互相通信和协作”的交互协议。这三者不是同义词也不是前后替代关系而是 Agent 能力分层中的不同环节。打一个不算太精确的类比Function Calling 相当于“本地函数签名约定”解决的是模型如何把自己的意图映射成一次程序调用MCP 相当于“RESTful API 标准”解决的是不同工具如何被统一接入、发现、调用A2A 相当于“服务间的通信协议”解决的是一个 Agent 如何把任务委托给另一个 Agent。从演进关系看它们是一条链上逐渐外扩的过程模型先要学会调用单个函数再要对接多种外部工具最后还要和别的智能体协作。每一层解决的都是上一层做不了的事。理解了这一点面试官那个问题的答题框架就有了不是背定义而是讲清楚每一层解决什么问题、由什么机制承载、在实际工程里怎么落地。2. Function Calling把“模型想要做的事”翻译成“程序能执行的调用”2.1 它解决的最原始痛点先回到最早的场景。在没有 Function Calling 之前你想让大模型完成一个需要程序介入的任务比如查询天气、计算运费、写数据库流程非常别扭。模型只会生成文本它不会真的去调用你的代码。传统做法是你让模型输出一段 JSON再写一套正则或关键词匹配逻辑去解析这段 JSON最后手动拿着解析结果去调用对应函数。模型可能答非所问可能格式跑偏整个链路既脆弱又难维护。Function Calling也叫工具调用、函数调用、Tool Use的出现把“从自然语言到函数参数”这件事变成了模型原生支持的标准动作。你在请求里声明有哪些函数模型在生成回复时会先推理出应该调用哪个函数、参数填什么然后以结构化格式返回调用信息由你的程序真正执行。2.2 一个最小的 Function Calling 示例以 OpenAI 风格接口为例核心就是在请求里声明一个functions或tools列表{ model: gpt-4o-mini, messages: [ { role: user, content: 北京明天天气怎么样 } ], tools: [ { type: function, function: { name: get_weather, description: 查询指定城市和日期的天气, parameters: { type: object, properties: { city: { type: string, description: 城市名 }, date: { type: string, description: 日期格式 YYYY-MM-DD } }, required: [city, date] } } } ] }模型返回时不会直接说“北京明天晴”而是返回类似下面的结构{ tool_calls: [ { id: call_abc123, type: function, function: { name: get_weather, arguments: {\city\:\北京\,\date\:\2025-01-20\} } } ] }然后你的程序负责真正执行get_weather(北京, 2025-01-20)再把结果作为新的消息回传给模型让模型基于真实温度数据生成答案。你可以把 Function Calling 理解为“大模型参与了一次合同谈判”模型根据用户需求输出一份结构化的“调用合同”程序拿这份合同去执行执行结果就是“履约证据”模型再依据证据组织最终回复。2.3 Function Calling 的天花板在哪里Function Calling 很实用但它有一个明显局限它是面向单模型的编程接口。每个模型厂商都有自己的实现细节。OpenAI 有tools参数Anthropic 有tools和tool_use块国产模型有的叫functions、有的叫tools参数描述语法也各不相同。如果你针对 OpenAI 写了一套函数调用逻辑换一个模型再接入时通信格式基本要重写一遍。更麻烦的是工具本身也是“焊死”的。你声明了get_weather代码里就必须有对应的get_weather实现调用逻辑、参数校验、异常处理都写在你的业务代码里。工具多了以后你会在工程里看到大量散落的函数声明、参数校验和调用分发代码。这就像早期分布式系统里每个服务都自己定义 RPC 接口服务之间能通信但没法互操作。于是标准化的问题来了。3. MCP把“一堆零散工具”变成“一套标准接口”3.1 MCP 在解决什么MCPModel Context Protocol模型上下文协议最早由 Anthropic 提出现在已经成为 Agent 工具接入的事实标准之一。它的设计目标和 REST API 有点类似定义一套统一的客户端/服务端协议让模型能够通过同一套规范发现、连接和调用任意工具。在没有 MCP 之前你每接一个新工具都要为它写一套自定义封装。接数据库要写一个查询封装接 Git 要写一个命令封装接 Figma 要写一个设计稿读取封装。这些封装里的鉴权、格式转换、错误处理逻辑大量重复。有了 MCP 之后工具提供方只需要实现一个“MCP Server”把能力声明为工具Agent 应用作为“MCP Client”去连接这些 Server并通过统一协议调用工具。工具不需要知道模型是什么模型也不需要知道工具内部怎么实现。3.2 MCP 的三个核心角色MCP 体系里通常有三个角色角色作用类比MCP Host承载 Agent 运行的应用比如 Claude Desktop、Cursor、Codex浏览器MCP ClientHost 内部负责与 Server 建立连接的协议客户端HTTP ClientMCP Server暴露一个或多个工具的外部能力服务后端 API 服务整个调用链路大致是用户的自然语言请求进入 HostHost 里的 Agent 判断需要调用某个工具MCP Client 按协议找到对应 MCP ServerServer 执行真实逻辑把结果返回给模型。对模型来说MCP 工具和本地 Function Calling 在“函数调用”这个层面感受是一致的差别在于MCP 把工具的声明、发现、连接、鉴权、调用、返回都标准化了。3.3 一个 MCP Server 的轻量示例MCP 官方提供了 Python SDK用FastMCP可以很快写一个内置工具。下面是一个查询“城市温度”的最小 Server 示例文件命名weather_server.pyfrom mcp.server.fastmcp import FastMCP mcp FastMCP(weather-demo) # 内置一个模拟的温度查询工具 mcp.tool() def get_temperature(city: str) - str: 根据城市名返回模拟温度 data {北京: 5℃, 上海: 12℃, 广州: 20℃} return data.get(city, 暂不支持该城市) if __name__ __main__: mcp.run()运行pip install mcp python weather_server.py然后在支持 MCP 的客户端比如 Claude Desktop、Cursor、Codex里配置该 Server 的地址客户端就能自动发现get_temperature这个工具并在 Agent 推理需要时自动调用。完整配置方式取决于客户端这里只演示 MCP Server 侧的核心逻辑。如果你在 Cursor 或 Codex 里接入过 MCP你会发现流程基本一致安装 SDK、写 Server、暴露工具、客户端填入配置、授权后即可对话使用。3.4 MCP 的价值与边界MCP 真正的价值不是取代 Function Calling而是让工具接入从“点对点集成”变成了“一次接入、到处使用”。工具开发者只需要维护一个 MCP Server就能被多个支持 MCP 的 Agent 客户端复用Agent 开发者也不需要为每个外部系统写专属适配器。但它不是万能的。MCP 解决的只是“工具调用标准化”问题它不负责“多个智能体如何配合完成任务”。你可以把 MCP 理解成给 Agent 配了更多“手脚”但“多个 Agent 之间如何对话、如何分工、如何交付结果”是 MCP 管不到的上层问题。4. A2A从“一个人干活”到“一整个团队协作”4.1 为什么需要 Agent 和 Agent 之间通信当 Agent 的能力越来越强、场景越来越复杂时一种新的需求冒出来了一个 Agent 搞不定的任务能不能让多个专长不同的 Agent 协作完成比如一个前端 Agent 负责生成页面一个后端 Agent 负责生成接口一个测试 Agent 负责自动审查。每个 Agent 跑在各自环境里使用各自的工具链和模型。如果它们之间不能通信任务就只能由一个超大 Agent 全包或者靠外部流程编排硬串这两种方式在复杂任务下都会变得笨重。谷歌在 2025 年发布的 A2AAgent2Agent协议就是为了解决这个问题。它的定位是定义一套智能体之间互相发现、通信、协商和任务协作的开放协议。4.2 A2A 的核心设计思想A2A 在设计上借鉴了 HTTP、JSON-RPC 等成熟协议的经验。它有几个核心概念概念作用Agent Card智能体的“名片”描述能力、端点和认证方式Agent 间消息基于 JSON-RPC 的标准化消息用于任务分发和状态同步A2A Client/Server每个 Agent 既可以作为 Client 发起协作也可以作为 Server 接收任务两个 Agent 协作的基本流程是发起方通过 Agent Card 发现目标 Agent 的能力和入口然后发送任务请求接收方确认后异步执行通过消息不断同步进度最终返回结构化结果。因为通信协议是标准化的不同框架、不同模型底座训练的 Agent 理论上可以互相协作。从目前公开材料看A2A 强调的不是“让模型更聪明”而是“让不同团队开发的独立 Agent 能以开放方式见面、协商、分工”。它更像是在 Agent 之间建立了一层“外交渠道”。4.3 A2A 与 MCP 的关系A2A 和 MCP 不是替代关系而是互补关系。一个常用的比喻是MCP 是给 Agent 接“工具库”A2A 是给 Agent 找“合作伙伴”。一个 Agent 内部要用 Function Calling 调用本地方能用 MCP 接入外部工具当它发现自己搞不定整个任务时再通过 A2A 把子任务委托给其他 Agent。因此A2A 通常处于更上层。在实际工程中一个大型任务可能由 Agent A 通过 A2A 协议拆给 Agent B、Agent C每个 Agent 内部再用 MCP 调用各自的工具整个体系形成一种“协作层 工具层 函数层”的三级结构。5. 一张表看懂三者区别面试中如果能画出这张对比表基本就赢了一半维度Function CallingMCPA2A核心定位模型调用函数的推理机制模型调用工具的接入标准智能体之间的通信协议解决层次单模型内部单 Agent 对接外部工具多 Agent 协同主要提出方OpenAI 等模型厂商Anthropic谷歌通信方向模型 → 函数Agent 客户端 → MCP ServerAgent → Agent类比本地函数签名RPC / REST 标准服务间通信 / 外交协议主要承载格式模型 API 的 tools/tool_callsJSON-RPC 2.0 等通道的命令交互JSON-RPC 消息 Agent Card典型场景模型需要按结构调用一个函数接数据库、Git、Figma 等各种外部工具多 Agent 分工完成复杂任务从字面看三个词都有“调用”或“交互”的味道但抽象层级完全不同。Function Calling 是单点能力MCP 是点对面的接入标准A2A 是面对面Agent 对 Agent的协作协议。进一步说三者也不是互斥的工程上经常组合使用。比如一个 Agent 用 Function Calling 调用内部函数通过 MCP 连接外部工具再通过 A2A 把任务委托给另一个 Agent。这个组合关系也是面试官常爱追问的“联系”。6. 一次完整的工程调用链路从 Function Calling 到 MCP为了把“联系”讲清楚这里给一个相对完整的工程假设。假设你在写一个会议安排 Agent用户说“帮我查一下明天下午两点有没有空会议室有的话订一间并把会议邀请发给参会人”。如果不用任何协议你需要在代码里硬写查询会议室、预定会议室、发送邀请三个函数再写一堆判断逻辑让模型选择、调用。用了 Function Calling流程变成了# 伪代码Function Calling 的标准调用循环 tools [ {type: function, function: {name: query_meeting_rooms, ...}}, {type: function, function: {name: book_meeting_room, ...}}, {type: function, function: {name: send_invite, ...}}, ] while True: response model.chat(messages, toolstools) if response.tool_calls: for call in response.tool_calls: result execute_local_function(call.function.name, call.function.arguments) messages.append(tool_result_message(call.id, result)) else: return response.content这段代码展示了核心机制模型根据用户问题判断该调用哪个函数程序拿到函数名和参数后执行再把执行结果回填给模型。模型继续推理是否还需要调用更多函数直到没有新的工具调用请求才生成最终回复。如果进一步把查询会议室、预定会议室、发送邀请三个操作都做成 MCP Server那么上面的循环就变成了通用的 MCP 调用循环from mcp import ClientSession # 连接到 MCP Server自动发现可用工具 async with ClientSession(transport) as session: tools await session.list_tools() # 把 tools 映射给模型 response await model.chat(..., toolstools) for call in response.tool_calls: result await session.call_tool(call.function.name, call.function.arguments) messages.append(tool_result_message(call.id, result))区别非常明显前者需要你自己写execute_local_function并且每增加一个工具就要改一次分发逻辑后者通过 MCP Client 自动发现工具、统一调用业务代码里不再出现散落的函数映射。这就是 MCP 的工程价值。7. 面试回答参考这三层怎么组织语言回答这类问题时建议不要一上来就背定义而是先给判断框架“这三者不是同一维度的东西而是 Agent 技术栈不同层级的能力。”接着可以这样展开Function Calling 是模型侧的能力机制。它定义了模型如何在推理时选择函数、生成参数、返回结构化调用结果。属于单模型内部的行为约束。MCP 是工具接入侧的标准化协议。它解决的是 Agent 与外部工具之间的互通问题让工具实现一次、被多个 Agent 复用。属于单 Agent 向外扩展能力的通道。A2A 是智能体与智能体之间的通信协议。它解决的是多个独立 Agent 如何发现彼此、拆分任务、同步状态和返回结果。属于多 Agent 协作的编排层问题。然后再补一句连接点实际工程中它们是叠加关系一个 Agent 内部可以用 Function Calling 处理模型推理用 MCP 接入外部系统需要时再用 A2A 把子任务委托给其他 Agent。这样回答既有层次感又有工程视角比单纯背概念强很多。8. 常见误区与面试追问8.1 “MCP 是不是取代了 Function Calling”不是。MCP 是工具接入规范Function Calling 是模型推理机制。MCP 让工具更容易被模型调用但底层仍然需要模型按照调用约定输出函数名和参数。换句话说MCP 里的工具调用成功基础仍然落在了正确的函数参数生成上。如果模型不具备稳定的函数参数输出能力MCP 也帮不上忙。8.2 “A2A 出现后是不是不用学 MCP 了”不是。A2A 面向 Agent 与 Agent 协作不解决单个 Agent 如何连接数据库、读取文件、调用 Web API 的问题。即使所有 Agent 都能通过 A2A 互相通信每个 Agent 内部还是要有工具执行能力。MCP 仍然是单 Agent 工具接入的重要方案。8.3 “本地模型支持 Function Calling 吗支持 MCP 吗”越来越多的本地模型支持 Function Calling但表现差异较大。小参数模型在参数约束、工具选择准确率上明显弱于大模型。MCP 本质上是客户端与服务端之间的协议本地模型能不能用 MCP取决于承载模型的 Host 是否实现了 MCP Client。换句话说模型本身不直接“支持 MCP”MCP 是客户端侧的标准化能力。8.4 “MCP 和 Computer Use 有什么区别”Computer Use 是模型直接操作图形界面理解屏幕截图、点击按钮、键入文字相当于让模型“用鼠标键盘操作软件”。MCP 是让模型通过结构化协议调用工具接口不依赖图形界面。前者适合没有 API 的旧系统后者适合有明确接口的场景。二者可以互补但不是同一类技术。8.5 “需要自己实现 MCP Server 吗”看场景。如果是接一个已有 API并且社区已经有人写好了 MCP Server直接配置使用即可不用重复造轮子。如果是对接内部系统或者现有 Server 不满足需求再自己写。当前各大 Agent 产品都在支持 MCP社区生态里已经有不少常用系统的现成 Server搜索相关关键词即能找到。8.6 “A2A 落地了吗”A2A 是比较新的协议目前更多处于生态建设和框架适配阶段。部分 Agent 框架已开始引入 A2A 模式支持多智能体协作但大规模生产环境落地还需要时间。面试中谈到这一点时可以表达“关注其生态成熟度同时并行建设内部的多 Agent 应用基础设施”。9. 工程实践建议9.1 面向面试答题要有分层结构不要背三个孤立定义。核心是“分层”判断Function Calling 是模型侧推理机制MCP 是工具接入标准A2A 是 Agent 间协作协议。每一层给出一个类比、一个工程痛点、一个典型落地场景即可。9.2 面向项目优先从 Function Calling 起步如果你的项目刚起步不要一上来就引入 MCP 和 A2A。先在模型对话能力基础上把 Function Calling 跑通写清楚函数声明、参数校验、执行分发、错误处理这四个环节。等工具数量明显增加、每次接入新工具都产生重复劳动时再抽象出 MCP Server 层。过早引入协议会让小项目变得复杂。9.3 面向架构工具定义与实现分离无论用不用 MCP都建议把“工具声明”和“工具实现”分开。工具声明描述函数名、参数、用途是给模型看的工具实现是真实执行逻辑。两者分离后从 Function Calling 迁移到 MCP 时只需改造声明层的接入方式不用动业务实现重构成本会低很多。9.4 面向多 Agent先想清楚边界再上 A2A多 Agent 协作不是锦上添花而是复杂度放大器。如果你的任务可以被单一 Agent 完成不要为了“上 A2A”而上 A2A。只有当任务确实存在明确领域边界、多个 Agent 各自独立维护、且协作价值大于通信开销时再引入 A2A 层。先定义好 Agent Card 和能力边界再谈通信协议避免出现“协作五分钟通信两小时”。10. 总结与延伸思考把三个概念放在一张时间线上看其实是一条清晰的技术演进路径Function Calling 让模型有了“调用函数”的基础能力MCP 让工具的接入和复用不再各自为战A2A 则试图让智能体之间找到统一的“外交语言”。它们不是竞争关系而是不同层级的配套能力。对于开发者来说最重要的不是记住这三者的名词定义而是理解它们分别处在 Agent 技术栈的哪一层、各解决什么工程痛点。如果你能把“函数层、工具层、协作层”这个框架讲清楚再配合一两个自己实践过的调用链路或接入案例这个面试题基本就稳了。如果面试官继续追问“给你一个项目你会怎么选型”可以考虑这样回答先看项目是否需要大模型再看是否需要大模型主动调用外部工具然后评估工具数量与复杂度最后才考虑是否需要多 Agent 协作。这个决策顺序本身就是对概念边界最好的证明。