考察点
这道题出自百度大模型岗二面，是 Agent Skill 与 MCP 的关系辨析题。两个概念都是 2025 年 Agent 生态的热词，简历上写了就会被拿来对撞。面试官想确认你理解两者的正交关系——一个管连接、一个管知识，而不是把它们当成同层竞品；后两问（只用 Skill 行不行、一个 Skill 能否跨多个 MCP server）考的是对组合形态的实际推演。追问常往 Skill 与 subagent 的区别、工具过多时的选择问题走。
参考答案
区别：一个管「能做什么」，一个管「该怎么做」
MCP 解决连接问题。它标准化 Agent 与外部工具、数据源之间的接口：工具怎么描述、怎么发现、怎么调用、结果怎么返回。MCP 回答的是「这个 Agent 能做什么」——接了数据库 server 就能查库，接了 GitLab server 就能操作仓库。它给的是能力。
Skill 解决知识问题。它把领域 know-how 打包成可加载的指令包：处理某类任务该按什么流程、注意什么规范、参考什么资料。Skill 回答的是「这件事该怎么做」——不是给你新能力，而是教模型把已有能力用对、用好。
用一个比喻收口：MCP 是电源插座，Skill 是操作手册。插座让电器通上电，手册告诉你这台机器的正确操作顺序。光有插座没有手册，能力在但不会用；光有手册没有插座，知道步骤但没工具执行。两者是正交的，不存在替代关系。
两者怎么配合
生产系统里典型的配合方式是 Skill 编排 MCP 工具。举个例子：团队接入了 orders-mcp（查订单）、payment-mcp（操作退款）、ticket-mcp（建工单）三个 server，然后写一个「售后退款处理」Skill，正文里规定流程——先用 orders-mcp 核对订单状态，金额超过 500 元需要走审批工单，确认无误后再调 payment-mcp 退款，全程要记录操作日志。模型处理退款请求时先加载这个 Skill，再按 Skill 的指示依次调用各 MCP 工具。MCP 提供标准化、可审计的调用通道，Skill 提供流程约束和领域判断，模型的行为因此既灵活又守规矩。
这个组合对工程组织的意义：工具团队维护 server，业务团队沉淀 Skill，两边的迭代节奏和负责人完全解耦。
能只用 Skill 不用 MCP 吗
可以。Skill 不依赖 MCP 存在——正文里可以直接写「运行同目录下的 check.py 脚本」「调用内部的 /api/orders 接口」，用 CLI、脚本、HTTP 直连完成所有外部交互。工具少、全部自研、跑在本地环境里时，这套方案完全成立，还省了部署 server 的成本。
代价要认清：一是失去标准化的发现与鉴权，每个 Skill 内置的调用方式各自为政，凭证散落在各处；二是失去跨应用复用，别的 Agent 想用同一批能力，得复制脚本和环境依赖，而不是连一个 server；三是环境耦合，脚本对运行环境的要求跟着 Skill 走，分发和升级都麻烦。所以这不是对错问题，是规模问题——小规模自用，Skill 内嵌脚本够用；工具要跨团队、跨应用流通，就该走 MCP。
一个 Skill 能跨多个 MCP server 调工具吗
能，而且这正是 Skill 的核心价值场景。Skill 的指令不绑定任何单个 server，它可以编排任意多个 server 的工具完成端到端流程，上面退款例子里一个 Skill 就横跨了三个 server。工程上注意两点：不同 server 的工具名可能撞车，Host 侧要做好命名空间隔离（通常加 server 前缀）；Skill 里引用工具时建议写全限定名，避免模型在重名工具间选错。另外要克制——一个 Skill 编排五六个 server 的十几个工具，说明职责太宽，该拆了。
可能的追问
- Skill 和 subagent 有什么区别？ 答：Skill 是知识包，加载进当前 Agent 的上下文里使用，共享会话状态；subagent 是独立执行的 Agent 实例，有自己的上下文窗口，适合需要隔离或并行的大块任务。轻量流程用 Skill，重隔离任务用 subagent。
- MCP 工具太多，模型选错怎么办？ 答：两条路——Skill 在指令里明确「这类任务用哪几个工具」，把选择范围收窄；架构侧用 gateway 做工具检索，按任务动态下发相关 schema 而不是全量注入。
- Skill 会有安全问题吗？ 答：会，Skill 正文进入上下文就是指令，恶意 Skill 等于间接 prompt injection；来源要可信化，安装要用户确认，Skill 里引用的脚本执行要沙箱化。