如果说上一篇考的是“认知”，这一篇考的就是“架构”。

Agent、工具调用、以及 MCP / A2A 两大协议，构成了当下 Agent 工程师绕不开的知识网络。面试官在这一环节的意图很明确：他想确认的不仅仅是你“知不知道这些名词”，而是你是否理解这套生态为什么会长成今天这个样子，以及每一层抽象到底解决了什么工程痛点。

很多候选人能画出 Agent 的架构图，但说不清为什么要引入 MCP；知道 A2A 的存在，却讲不明白它和 MCP 的边界在哪里。下面我们把这四个核心概念串起来，帮你建立起一张完整的“Agent 架构进化图谱”。

---

一、Agent：自治性 + 多步推理，才是分水岭

高频问法：​ "Agent 和传统对话式 AI 的区别是什么？"

不要停留在"Agent 更智能"这种空话。面试官想听的是行为模式上的本质差异。

核心差异对比

维度	传统对话式 AI	Agent
交互模式	被动响应，一问一答	主动决策，目标驱动
任务复杂度	单轮或少量多轮，依赖用户明确引导	复杂任务自主拆解、规划、执行
外部交互	通常无或仅有简单插件	广泛调用 API、数据库、代码执行器等工具
容错机制	答不上就道歉或转移话题	结果不达标时自动重试、调整策略
典型场景	客服问答、闲聊陪伴	自动化工作流、复杂决策辅助

Agent 的五个核心特征

这五点值得逐条记牢，因为它们构成了几乎所有 Agent 框架的设计基石：

1. 自治性（Autonomy）：无需人工逐步干预，能独立完成任务闭环；

2. 工具调用（Tool Use）：连接外部 API、数据库、代码解释器、搜索引擎等；

3. 多步推理（Multi-step Reasoning）：将复杂任务拆解为子目标，逐步推进（ReAct、Plan-and-Execute 等范式）；

4. 记忆能力（Memory）：短期维持对话上下文，长期积累用户偏好和经验；

5. 适应性（Adaptability）：遇到错误或结果不满意时，能自我修正、换策略重试。

⚠️ 面试官的潜台词

他真正在筛选的，是你能不能分清"什么任务值得上 Agent"。

一个 IF-ELSE 就能跑通的流程，硬套自主规划，那叫"为了用 AI 而用 AI"——不仅增加了延迟和成本，还引入了 LLM 的不确定性风险。

成熟的工程判断应该是：

• 哪些环节交给 LLM 做模糊推理（自然语言理解、开放域决策、非结构化数据处理）；

• 哪些环节用硬编码锁死逻辑（关键业务校验、金额计算、权限控制、不可逆操作）。

Agent 不是万能的，知道什么时候不用 Agent，本身就是一种高阶能力。

---

二、Function Calling：给大模型装上"手"

高频问法：​ "Function Calling 是什么？它为什么重要？"

一句话定义

Function Calling 是一种让 LLM 在生成过程中按需调用外部工具 / API​ 的机制。它打破了模型"只能靠预训练知识作答"的天花板，让模型从"会说"变成"会做"。

核心价值

1. 扩展能力边界：访问实时数据（天气、股价、新闻）、执行复杂计算、操作外部系统；

2. 提高准确性：不再依赖参数化记忆中的过时或错误信息，而是拿到真实数据后再回答；

3. 动态交互：与外部系统实时联动，实现真正的"行动"而不仅仅是"生成文本"。

工作原理（三步闭环）

┌─────────────────────────────────────────────┐
│  1. 定义工具                                  │
│     开发者提供 JSON Schema 描述工具名称、       │
│     参数类型、功能说明                          │
│                                              │
│  2. 模型决策调用                               │
│     LLM 根据用户意图判断是否调用、选择哪个工具、  │
│     填充参数（模型输出结构化 JSON）              │
│                                              │
│  3. 执行与整合                                │
│     外部系统执行函数 → 返回结果 →               │
│     LLM 将结果整合为自然语言回答                │
└─────────────────────────────────────────────┘

面试加分点

能指出 Function Calling 的局限性：

• 每个工具都需要手动编写 JSON Schema 和对应的执行函数，工具多了之后维护成本高；

• 不同模型厂商的 Function Calling 格式不统一（OpenAI 的格式 ≠ Anthropic 的格式 ≠ 开源模型的格式）；

• 工具之间的组合逻辑仍需开发者自行编排。

这些痛点，正是 MCP 诞生的原因。

---

三、MCP：把 Function Calling "车同轨、书同文"

高频问法：​ "MCP 解决了什么问题？和 Function Calling 是什么关系？"

先给背景

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 于 2024 年 11 月推出的开放标准。它被称为 "AI 领域的 USB-C"——为模型连接各种数据源和工具提供统一接口。

它到底解决了什么痛点？

在没有 MCP 之前，每接入一个新工具，开发者要做的事包括：

1. 编写工具的 JSON Schema 定义；

2. 实现一个中介函数来处理调用逻辑；

3. 在 Prompt 中编写工具使用说明，确保模型理解何时调用；

4. 处理返回结果的解析和格式化；

5. 如果换了模型厂商，可能还要适配不同的 Function Calling 格式。

工具数量 × 模型数量 = N × M 的集成成本。​ 这是典型的"重复造轮子"问题。

MCP 做了什么？

MCP 通过两层标准化来终结这种混乱：

标准化层级	解决的问题
工具定义与调用规范	统一了 Function Calling 的运行规范，不同模型用同一套协议调用工具
客户端-服务器通信规范	统一了 Host ↔ Client ↔ Server 的运行架构，工具服务可独立部署和复用

架构示意

┌──────────────────────────────────────────┐
│         MCP Host（Claude Desktop / IDE）  │
│  ┌───────────┐                            │
│  │ MCP Client │◄────┐                     │
│  └───────────┘     │                     │
│        │           │                     │
│   ┌────▼────┐ ┌───▼─────┐               │
│   │ MCP     │ │ MCP     │  （轻量服务）   │
│   │ Server A │ │ Server B │               │
│   │ (文件系统)│ │ (数据库) │               │
│   └────┬────┘ └───┬─────┘               │
│        │           │                     │
│  本地文件/DB    远程 API                   │
└──────────────────────────────────────────┘

实际意义

• 通用工具一次开发，处处复用：查天气、读文件、爬网页、查数据库等通用能力，一个人写好 MCP Server，所有兼容 MCP 的 Host 都能直接用；

• 解耦：工具服务和模型推理解耦，可以独立升级、扩展；

• 安全性：MCP Server 作为隔离层，控制模型对敏感资源的访问权限。

⚠️ 面试官可能的追问

• "MCP 能完全替代自己写 Function Calling 吗？"

  • 答：不能。MCP 擅长通用工具的标准化接入，但复杂的定制业务逻辑（如公司内部特有的审批流程、多系统联动的事务操作）仍然需要自定义实现。MCP 是基础设施层的抽象，不是业务层的替代品。

---

四、A2A：让 Agent 之间"开会协作"

高频问法：​ "A2A 和 MCP 会竞争吗？"

标准答案

谷歌官方的定调非常明确：互补，而非竞争。

两者的分工可以用一句话概括：

MCP 管"Agent 调用工具"，A2A 管"Agent 之间协作"。

维度	MCP	A2A
通信对象	Agent ↔ 工具/数据源	Agent ↔ Agent
信息形态	结构化（API 参数、返回值）	半结构化 / 非结构化（自然语言、任务描述）
交互模式	请求-响应，单次调用为主	多轮对话、协商、任务委派
技术基础	JSON-RPC（自定义传输）	HTTP + SSE + JSON-RPC（Web 原生）
典型场景	查数据库、调 API、读文件	跨部门协作、多 Agent 任务分配

"汽车修理厂"比喻（面试神器）

这个比喻几乎适用于所有 A2A vs MCP 的解释场景：

汽修工 Agent 修车时，使用千斤顶、扳手、诊断仪这些工具，走的是 MCP；

但它需要跟客户沟通故障情况、跟零件供应商 Agent 询价订货、跟质检 Agent 确认维修标准——这些Agent 之间的多轮沟通和任务协调，走的是 A2A。

一个成熟的 Agent 应用，通常两者都需要：MCP 负责连接工具和数据的"最后一公里"，A2A 负责组织和协调多个 Agent 的"社会化协作"。

A2A 的关键设计亮点

• Agent Card：每个 A2A Agent 发布一个元数据卡片（JSON 格式），描述自己的能力、端点、认证方式。其他 Agent 可以通过这个卡片发现和调用它——类似于微服务的"服务注册与发现"；

• 统一发现机制：谷歌甚至建议将 A2A Agent（通过 Agent Card）建模为 MCP 的一种资源类型，从而在协议层面实现统一发现——这意味着 MCP 和 A2A 在未来可能进一步融合；

• 企业级安全：默认支持身份认证、加密传输，适合跨组织、跨信任域的 Agent 协作；

• 长任务支持：不只是即时请求-响应，还支持长时间运行的异步任务（如"帮我调研竞品并生成报告"，可能需要几十分钟）。

---

▎一句话收束：画出这张进化图谱

Function Calling → MCP → A2A，这条路径本质上是 Agent 能力的三次抽象升级：

层次	解决的核心问题	关键词
Function Calling	让模型"能用工具"	手——执行能力
MCP	让工具"标准化接入"	插座——基础设施
A2A	让 Agent "能互相协作"	社交网络——组织能力

Function Calling 负责"能干活"，MCP 负责"方便地接工具"，A2A 负责"和别人协作干活"。

能画出这张进化图谱，讲清每一层"解决了上一层的什么不足"，你对 Agent 生态的理解就已经超过了大多数候选人。