考察点
这道题出自腾讯大模型应用岗二面，是这组技术栈题目的收口题。面试官前面大概率已经分别问过 FC、MCP、Skill，这道题看你能不能把散装知识点收拢成分层架构，并给出可执行的选型逻辑而不是「都用」。追问会往「推理模型接入哪层先断」「举一个四者共存的实例」走。
参考答案
四层定位：从模型能力到组织协作
这四个概念经常被混着讲，其实它们处在完全不同的抽象层：
| 层 | 技术 | 回答的问题 | 本质 |
|---|---|---|---|
| 模型能力层 | Function Calling | 模型怎么表达「我要调工具」 | 模型的结构化输出能力 |
| 工具集成层 | MCP | 工具怎么标准化地接进来 | Agent↔工具的连接协议 |
| 知识流程层 | Skill | Agent 怎么知道「该怎么做」 | 按需加载的领域流程包 |
| 协作层 | A2A | Agent 之间怎么互相委托 | Agent↔Agent 的协作协议 |
关键洞察是下层支撑上层：MCP 暴露的工具最终要靠 FC 让模型发起调用；Skill 里的操作手册引用的工具来自 MCP；A2A 委托出去的 Agent，内部还是用 MCP+FC 干活。上层断了下层还在，下层塌了上层全完。
选型框架：别问「用哪个」，问「问题在哪层」
我给团队用的决策顺序：
- 模型不会表达调用意图 → 这是 FC 层问题，换模型或补训练，跟协议无关。
- 接工具的方式五花八门、每个项目重写一遍 → MCP 层问题，标准化连接。
- Agent 能力够但老做错、流程不规范 → Skill 层问题，沉淀领域 know-how。
- 要和别的团队/公司的 Agent 协作 → A2A 层问题，定义协作边界。
真实项目里 90% 的问题出在前两层。Skill 和 A2A 是规模化之后的需求，小团队一上来就铺四层是过度设计。
生产级共存的一个实例
以一个电商售后中台为例，四层是这样落的：
- FC：底层模型（自研或商用 API）必须具备稳定的 tool calling 能力，这是整个系统的地基，配套做参数校验和逃逸工具。
- MCP：订单查询、库存、退款、物流这些内部 API 统一封装成 MCP Server，多个 Agent 应用复用，工具改动不用动 Agent 代码。
- Skill：「退换货处理流程」「大促应急预案」这类业务 SOP 做成 Skill，新人 Agent 加载即用，运营可以不动代码更新流程。
- A2A：售后 Agent 需要物流 Agent（物流团队维护）查异常件、需要风控 Agent（风控团队维护）审核大额退款，跨团队委托走 A2A，各自内部实现互不感知。
四层各司其职，没有一层是多余的，也没有一层能替代另一层。
推理模型接入时哪层先断
这是常见的配套追问。答案是 FC 层先断：推理模型（o1、早期 R1）倾向一条思维链直达答案，不习惯中途发起工具调用，或 tool_calls 参数质量明显低于非推理模型。上面三层本身与模型无关——MCP、Skill、A2A 都是协议和文本，模型一换照样转。这也印证了分层的价值：能力层的波动被隔离在最底层，不向上传导。
可能的追问
1. Skill 和 MCP 能不能合并成一层？
不能，关注点不同：MCP 管「能做什么」的连接，Skill 管「该怎么做」的知识。合并后工具协议里塞流程知识，跨工具复用和独立演进都会变糟。
2. 四层都上会不会延迟太高？
FC 是模型内能力无额外开销；MCP 本地 stdio 毫秒级、远程一次网络往返；Skill 是文本注入只增 token；A2A 跨组织本来就有业务延迟。真正的成本在 token 和运维复杂度，不在协议开销。
3. 只有单层 Agent 的小项目怎么留演进空间？
FC 直接写但工具实现收拢在独立 service 层；需要标准化时给 service 套 MCP 壳；流程知识先用 prompt 写、多了再抽 Skill；A2A 等有真实跨团队需求再接。