MCP、Function Call 和 A2A 在 Agent 系统中分别解决什么边界，如何协同？｜腾讯后端开发面经解析

60 秒回答模板

我会把它们放在同一条调用链里解释。Function Call 是模型输出层的能力：模型根据上下文选择某个工具名，并生成符合 schema 的参数，它解决的是自然语言意图如何变成结构化调用请求，但它本身不负责发现工具、执行工具、鉴权或跨进程通信。MCP 更像 Agent 宿主连接工具和上下文资源的协议边界：宿主作为 client，连接一个或多个 MCP server，获取工具、资源或提示能力，并用标准协议完成调用、返回结果和上下文注入。它解决的是工具生态标准化、能力发现、资源访问和运行时隔离，而不等同于模型的 function calling。A2A 则是更高一层的 Agent-to-Agent 边界：当一个 Agent 不是调用一个确定性工具，而是把任务委托给另一个具备目标理解、规划、工具使用和状态管理能力的 Agent 时，需要协议来描述任务、消息、产物、状态、权限和完成条件。协同时可以是：主 Agent 通过 Function Call 决定需要某个能力；这个能力可能由 MCP server 暴露为工具；如果任务需要另一个专业 Agent 自主完成，就通过 A2A 发起任务委托，等待它返回中间状态或最终产物。设计时要明确谁负责规划、谁负责执行、状态归谁、权限在哪里校验、错误如何返回、trace 如何贯通。简单本地函数不必上 MCP，确定性 API 不必包装成 A2A，只有跨工具生态或跨 Agent 协作复杂到需要标准边界时才引入对应协议。

考点 Function Call

难度 真实面经题

回答目标 让候选人能清楚区分 Function Call、MCP 和 A2A 的层级、职责和协作方式，并能从权限、状态、错误和可观测性角度给出可落地的 Agent 系统边界设计。

深入解析

先按层级区分三者

Function Call、MCP 和 A2A 不是同一层的替代品。Function Call 面向模型输出和宿主调度，MCP 面向宿主和工具/资源服务连接，A2A 面向不同 Agent 之间的任务协作。把层级讲清楚，才能解释它们为什么可以协同而不是互相替代。

Function Call 是结构化意图表达

Function Call 的核心是让模型在生成文本之外，输出工具名和结构化参数。它依赖 schema、工具描述和宿主执行器。模型负责选择和填参，宿主负责校验、鉴权、执行、重试和把结果放回上下文。它不天然提供工具发现、网络协议、资源目录或跨服务生命周期管理。

MCP 是工具和上下文的连接协议

MCP 关注的是 Agent 宿主如何连接外部能力提供方。一个 MCP server 可以暴露 tools、resources、prompts 等能力，宿主通过 client 协议发现和调用。它的价值在于标准化工具接入、降低集成成本、把文件系统、数据库、浏览器、业务 API 等能力放在更清楚的边界后面。

A2A 是 Agent 之间的任务边界

A2A 面向的不是调用一个函数，而是把一个任务交给另一个 Agent。被调用方可能会自己规划、调用工具、维护状态、产生产物并汇报进度。因此 A2A 需要表达任务目标、输入上下文、能力描述、状态流转、产物引用、取消/超时、权限和责任归属。

协同链路要明确谁做决策

一个典型链路是：主 Agent 先用模型判断下一步；模型通过 Function Call 生成结构化调用；宿主发现这个工具来自某个 MCP server，于是执行 MCP 调用；如果需要专业 Agent 自主完成子任务，则宿主或主 Agent 通过 A2A 委托。每一层都要明确决策者、执行者和返回结果的格式。

权限和信任边界不能混放

Function Call 参数必须由宿主校验，不能因为模型输出合法 JSON 就直接执行。MCP server 需要权限范围、资源隔离、审计和超时。A2A 更要明确对方 Agent 的身份、可见上下文、可调用能力和产物可信度。越往外部协作，信任边界越大，越需要授权和可追踪。

状态归属和错误语义要设计清楚

Function Call 常见状态是一次调用成功或失败；MCP 还涉及连接、能力列表、资源读取和工具结果；A2A 往往有任务创建、进行中、等待输入、失败、取消和完成等生命周期。错误也要区分参数错误、权限不足、工具失败、Agent 拒绝、任务超时和结果不可验证。

不要为了概念先进而过度协议化

如果只是进程内确定性函数，直接 function calling 加本地 executor 就够了。如果只是接一个稳定业务 API，可以通过普通 tool 或 MCP server 暴露，不必包装成 Agent。只有当对方能力需要标准工具生态、跨运行时连接或自主任务协作时，MCP 或 A2A 才体现价值。

易错点

把 MCP 说成 Function Call 的另一个名字，混淆模型输出格式和工具连接协议。
认为 Function Call 会自动执行工具、自动鉴权和自动发现工具，忽略宿主 runtime 的责任。
把 A2A 当成远程函数调用，没有讲任务状态、对方 Agent 自主规划和产物生命周期。
只背概念，不说明三者在一条 Agent 调用链中如何协同。
忽略权限边界，默认模型生成的参数、MCP 返回的资源和外部 Agent 产物都可信。
任何工具都上 MCP、任何子任务都上 A2A，导致系统过度复杂而收益不明确。
没有设计错误语义和可观测性，调用失败后分不清是参数错、工具错、权限错还是 Agent 拒绝。
把协议边界和业务责任混在一起，导致状态归属、取消、重试和审计都无法落地。

面试官追问

MCP 和 Function Call 最大区别是什么？

Function Call 是模型输出工具调用意图的格式，重点在工具名和参数；MCP 是宿主连接外部工具和资源服务的协议，重点在能力发现、调用通道和运行时边界。模型可以通过 Function Call 选择一个由 MCP 暴露的工具，但两者不是一回事。

A2A 和调用一个工具函数有什么区别？

工具函数通常是确定性能力，输入参数后返回结果；A2A 的对方是 Agent，可能会自己理解目标、拆任务、调用工具、维护状态并返回阶段性产物。A2A 更像任务委托，而不是一次函数执行。

A2A 能不能也包装成 Function Call？

可以把发起 A2A 委托这个动作暴露成一个工具，让模型用 Function Call 触发。但被触发后的生命周期、状态流、权限和产物管理仍属于 A2A 边界，不能因为入口是 Function Call 就把它简化成普通函数。

什么时候不需要 MCP？

如果工具只在当前进程内使用，数量少、权限简单、没有跨客户端复用需求，直接本地 executor 更简单。MCP 更适合工具要被多个宿主复用、需要标准发现和资源访问边界、或工具运行在独立服务中的场景。

这些协议最容易出安全问题的地方在哪里？

常见风险是模型生成参数未经校验直接执行、MCP server 暴露过宽资源、A2A 委托泄露过多上下文、外部 Agent 返回结果未经验证，以及缺少 trace 导致越权和错误无法追溯。