考察点
腾讯二面考过这道综合选型题，是工具协议板块的收口题。面试官想看你能不能把四个热点概念放进一张分层图里，并给出「什么情况引入哪一层」的可操作判断，而不是罗列定义。追问方向：只有一个工具要不要 MCP、推理模型接入哪层先出问题。
参考答案
四层各管一段
| 层 | 概念 | 回答的问题 |
|---|---|---|
| 语法层 | Function Calling | 模型怎么表达「我要调工具」 |
| 接入层 | MCP | 工具能力怎么标准化地被发现和调用 |
| 知识层 | Agent Skill | 模型怎么知道「这件事该按什么流程做」 |
| 协作层 | A2A | 多个 Agent 之间怎么互相委托任务 |
四层是叠加关系不是替代关系：Skill 命中的规程，可能指导模型经 FC 发起调用，调用经 MCP 路由到某个 Server，而这个 Server 背后可能又是个通过 A2A 协作的远程 Agent。
逐层的引入判断
FC：默认就有，不用选。 现在主流模型都原生支持，这是你建 Agent 的地基。唯一要决策的是工具 schema 怎么设计。
MCP：看工具数量和复用范围。 判断公式：工具数 × 消费方数。一两个工具、只服务自己一个应用，直接代码里写 FC，上 MCP 是过度设计。工具超过五六个、或者同一批工具要给多个应用/团队用，MCP 的「一处维护多处接入」开始回本。工具提供方和消费方是不同团队时，协议就是契约，强烈建议。
Skill：看「怎么做」的知识复杂度。 如果工具摆在那模型自己就能用对，不需要 Skill。当任务有稳定的多步流程、有行业或公司特有的规矩（报表格式、合规检查清单、发布流程），且这些知识在多会话间复用，就该沉淀成 Skill。判断信号：你发现自己在不同会话里反复粘贴同一段操作说明。
A2A：看协作边界。 系统内部的模块拆分用普通服务调用就够。当对面是一个独立演进、有自己智能的 Agent——跨团队、跨厂商、跨技术栈——需要能力发现、长任务、多轮反问这些语义时，才轮到 A2A。预判不准就先不用，它的抽象成本在四个里最高。
一个生产系统的典型共存形态
以企业数据分析 Agent 为例：模型经 FC 输出调用意图；内部五六个数据工具（SQL 查询、指标平台、报表生成）走 MCP，因为是数据团队统一维护的 Server；「周报生成流程」「异动归因分析规程」沉淀成两三个 Skill 挂在 Agent 上；需要法务审合同这类跨团队能力时，经 A2A 委托给法务团队的 Agent。四层各占其位，没有一层是多余的，也没有一层是硬上的。
选型时的现实约束
技术之外要算三笔账：协议层多一层，延迟和排障链路就长一截；团队要有维护 Server/Skill 的人力，没人维护的协议层比没有更糟；协议都还年轻，版本演进快，锁定版本并留好升级窗口。
可能的追问
- 推理模型（o1/R1 类）接入这套体系哪层先出问题？ 语法层。早期推理模型对工具调用的支持不稳定——思考链和 tool_calls 的交错处理容易断，工具结果回填后推理连续性差。接入时先验证 FC 稳定性再谈上层。
- 小团队起步推荐什么组合？ FC + 少量精心设计的工具起步，流程知识先写进系统提示；提示膨胀到难维护了再抽 Skill；工具复用需求出现了再上 MCP。按需生长，别一步到位。
- 怎么向不懂技术的老板解释这四层？ FC 是员工会说「我需要用某个系统」，MCP 是公司统一的系统接入规范，Skill 是岗位操作手册，A2A 是公司和外部供应商的合作协议。