考察点
百度二面考过这组问题，前提是你已经分别懂 Skill 和 MCP，面试官要看你能不能画出两者的协作关系图。高频追问：「能不能只用 Skill 不用 MCP」「一个 Skill 内能否跨多个 MCP Server 调工具」。
参考答案
一句话分工
Tool（通常经 MCP 接入）回答「Agent 能做什么」，Skill 回答「Agent 该怎么做这件事」。前者是手和脚，后者是经验手册。查数据库是一个 Tool；「拿到查询需求后先确认时间口径、用哪张表、结果怎么校验、报表按什么模板出」这一整套规程是 Skill。
为什么缺一个都不行
只有 Tool 没有 Skill：Agent 空有一堆能力，遇到复合任务就乱来。给它数据库查询和图表生成两个工具，让它「出一份周报」，它可能查错表、漏校验、图表风格每次都不一样——因为「怎么干」的知识不在任何地方，全靠模型现场发挥。
只有 Skill 没有 Tool：规程写得再细，落到「执行 SQL」「发邮件」这种动作时还是没手。Skill 正文里当然可以写代码片段让 Agent 现写现跑，但对企业系统来说这不可控——权限、审计、稳定性都管不住，正经动作还是要走受管的 Tool。
Skill 可以跨多个 MCP Server 调工具吗
可以，而且这正是设计意图。Skill 不绑定工具来源，它的正文里引用的是工具的名字和用法。一个「竞品分析 Skill」完全可以这么写：第一步调搜索 Server 的 web_search 抓竞品动态，第二步调数据库 Server 的 run_sql 拉自家销售数据，第三步调文档 Server 的 create_doc 生成报告——三个工具分属三个 MCP Server，Skill 负责把它们串成一条流水线。运行时由 Host 把 Skill 里提到的工具名路由到对应 Client 执行，Skill 本身不用关心传输细节。
「能不能只用 Skill 不用 MCP」怎么答
分场景。个人侧、轻量任务：可以。Skill 里直接写「运行这个 Python 脚本」，Claude Code 这类带执行环境的 Agent 就能干活，很多本地自动化场景这样最省事。但以下情况必须上 MCP/Tool：动作涉及企业系统（要权限和审计）、工具要跨应用复用、执行环境不允许跑任意代码。所以答案是「Skill 在轻场景可以自给自足，严肃生产场景里 Skill 编排 Tool 才是正解」。
和 Function Calling 放一起看的层级
三者协作一句话版：Function Calling 是模型表达调用意图的语法，MCP 是工具接入和供给的标准管道，Skill 是教模型在什么时候、按什么顺序、用什么姿势调用这些工具的知识层。生产 Agent 里三层共存：Skill 命中 → 模型按规程规划 → 经 FC 表达调用 → 经 MCP 路由执行。
可能的追问
- Skill 里写死的工具名，工具下线了怎么办？ 会调空。工程上把 Skill 当代码管理：工具清单变化时做依赖扫描，Skill 引用不存在的工具要在 CI 里报错。
- Skill 和子 Agent（sub-agent）怎么选？ Skill 是知识包，仍在主 Agent 上下文里跑；子 Agent 有独立上下文，适合隔离重污染的长任务。经验法则是「流程复用用 Skill，上下文隔离用子 Agent」。
- MCP Server 自带的 Prompts 原语和 Skill 冲突吗？ 不冲突但职责重叠，Server Prompts 是工具方附带的使用模板，Skill 是消费方沉淀的业务规程，后者优先级通常更高。