准备技术选型思路：什么时候用 MCP？什么时候用 Skills
1️⃣ 考察意图
面试官想考察你在 Agent 架构中的系统设计能力，而非简单背诵 MCP 和 Skills 的定义。刁钻点在于：MCP 和 Skills 看似功能重叠（都是让 Agent 执行动作），但本质是协议层 vs 逻辑层的差异。答好了能展示你对工具调用、动态编排、可维护性的深度理解，以及面对复杂业务场景时的工程取舍能力。这是 P1 级别区分“会用框架”和“能设计架构”的关键题。
2️⃣ 标准答
核心原则：MCP 解决“如何发现和调用外部工具”，Skills 解决“如何编排内部业务逻辑”。选型取决于工具集成复杂度和业务逻辑复杂度两个维度。
一、MCP（Model Context Protocol）适用场景
- 动态工具发现：当工具集频繁变化（如接入新 API、第三方服务），MCP 的
tools/list和tools/call端点让 Agent 运行时动态获取工具列表和参数 schema，无需硬编码。例如：电商 Agent 需要调用天气、物流、支付等 20+ 个外部 API，每个 API 的入参和返回格式不同，用 MCP 可统一管理。 - 跨语言/跨平台集成：MCP 基于 JSON-RPC，天然支持异构系统。例如：用 Python 写 Agent，但核心工具是 Java 写的风控服务，MCP 作为中间层解耦。
- 安全隔离：MCP 服务可独立部署，通过 OAuth 或 API Key 控制访问。例如：金融 Agent 调用银行内部数据，MCP 服务可做鉴权和审计日志。
- 坑：MCP 的
tools/call是同步阻塞的，如果工具响应慢（如调用大模型 API），会阻塞 Agent 主流程。解法：对慢工具加超时和重试机制，或用异步 MCP 实现（如 FastMCP 的async模式）。
二、Skills 适用场景
- 固定业务逻辑：当流程稳定、步骤明确时，Skills 作为 Agent 内部函数直接调用。例如：客服 Agent 的“退款流程”Skill，包含验证订单、检查库存、发起退款、发送通知 4 个步骤，每个步骤逻辑固定，用 Python 函数实现即可。
- 高并发低延迟：Skills 运行在 Agent 进程内，无网络开销。例如：实时风控 Agent 需要毫秒级判断交易是否异常，用 Skills 直接调用本地规则引擎。
- 复杂状态管理：Skills 可以维护内部状态（如对话历史、用户偏好），而 MCP 是无状态的。例如：教育 Agent 的“自适应学习”Skill，需要根据学生历史答题记录动态调整题目难度。
- 坑：Skills 硬编码后难以复用。解法：用“技能注册表”模式，将 Skills 定义为可配置的 YAML/JSON 文件，Agent 启动时动态加载，避免改代码。
三、混合使用：分层架构
- MCP 层：负责工具发现和调用，提供“原子能力”（如查询天气、发送邮件）。
- Skills 层：负责任务编排，将多个 MCP 工具组合成业务流程（如“出差申请”Skill 调用 MCP 的日历、审批、订票工具）。
- 决策矩阵：
- 工具集成复杂度高 + 业务逻辑复杂度低 → 纯 MCP（如数据采集 Agent）
- 工具集成复杂度低 + 业务逻辑复杂度高 → 纯 Skills（如内部审批 Agent）
- 两者都高 → 分层架构（如智能投顾 Agent）
- 示例：智能投顾 Agent 中，MCP 调用行情 API（动态数据源），Skills 实现风险评估流程（固定逻辑：收集用户信息 → 计算风险评分 → 生成投资建议）。评估指标：数据获取成功率 > 99%，策略执行准确率 > 95%，系统响应时间 < 2s。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从工具集成复杂度、业务逻辑复杂度、混合架构三个层面回答。第一，MCP 适合动态工具发现和跨平台集成，比如接入第三方 API；第二，Skills 适合固定业务逻辑和高并发场景，比如内部流程编排；第三，两者都高时用分层架构，MCP 提供原子能力，Skills 做任务编排。总结一句：MCP 是协议层，Skills 是逻辑层，选型看工具和逻辑的复杂度对比。”
4️⃣ 高频追问 & 应对
追问 1：如果 MCP 工具返回结果不稳定（如 API 超时），你怎么保证 Skills 的可靠性？
在 Skills 层加“重试+降级”策略。例如：Skills 调用 MCP 的天气工具时，设置 3 次重试，每次间隔 1s；若仍失败，降级为调用本地缓存数据（如果业务允许）。具体实现：Skills 函数内用
tenacity库装饰器，或自定义重试逻辑。注意：重试次数和超时时间需根据业务容忍度调整，金融场景可能直接报错而非降级。
追问 2：MCP 和 Skills 都支持工具调用，为什么不用一个统一方案？
因为关注点不同。MCP 关注“如何发现和调用”，Skills 关注“如何编排和复用”。统一方案会导致耦合：如果 MCP 工具变更（如 API 版本升级），Skills 逻辑可能受影响。分层架构让 MCP 团队专注工具稳定性，Skills 团队专注业务流程，符合单一职责原则。例如：字节的 Coze 平台中，MCP 插件和 Workflow（类似 Skills）是独立管理的。
追问 3：在低延迟场景（如毫秒级响应），MCP 的网络开销不可接受，你怎么选型？
纯 Skills 方案。例如：实时风控 Agent 中，所有规则引擎和模型推理都在本地进程内，用 Skills 直接调用。如果必须用外部工具，考虑“预加载+本地缓存”模式：MCP 服务提前拉取数据到本地内存，Skills 直接读缓存。或者用 gRPC 替代 JSON-RPC 减少序列化开销。但核心原则：低延迟场景优先避免网络调用。
5️⃣ 避坑 · 常见错误答法
- ❌ “MCP 是 Skills 的升级版，以后都用 MCP。” → ✅ “MCP 和 Skills 是互补关系，MCP 解决动态工具发现，Skills 解决固定逻辑编排，选型看场景，没有谁替代谁。”
- ❌ “Skills 就是写几个 Python 函数，没什么技术含量。” → ✅ “Skills 需要设计可配置、可复用的业务逻辑，比如用策略模式实现不同场景的 Skills，避免硬编码。”
- ❌ “MCP 只适合大厂，小项目用 Skills 就够了。” → ✅ “MCP 是协议标准，小项目也可以用，比如用 FastMCP 快速封装一个本地工具，成本很低。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“工具调用 vs 知识检索”角度切入，对比 MCP 的
tools/list和 RAG 的retrieve端点，说明 MCP 适合动态工具，RAG 适合静态知识。 - 如果你只做过传统 NLP：用“微服务 vs 单体应用”类比，MCP 是微服务（独立部署、动态发现），Skills 是单体（进程内调用、高内聚）。
- 如果你是校招无项目：聚焦论文复现，如 OpenAI 的 Function Calling 论文（2023）和 MCP 规范（2024），对比两者设计思路，展示对 Agent 架构的理解。
- MCP 官方规范（Anthropic, 2024）：Model Context Protocol Specification
- OpenAI Function Calling 论文（2023）：Function Calling in Large Language Models
- Coze 平台架构文档：Workflow vs Plugin 设计思路
- 字节跳动 Agent 实践：MCP 在抖音电商中的应用
- 论文：Toolformer（2023）——语言模型学会使用工具