🧑💻 面试官：你给 Agent 配了一个写周报的 Skill，还需要接 MCP 吗？
🙋♂️ 我：要看周报资料从哪里来。Skill 可以告诉它怎么整理，读取项目系统里的进展，仍然需要相应能力。
🧑💻 面试官：Skill 目录里就有一个读取数据的脚本呢？
🙋♂️ 我：那也需要运行环境去执行脚本，还得有访问数据的权限。
🧑💻 面试官：MCP 也能提供提示词。这样看，它和 Skill 是不是同一件事，只是包装不同？
这两个概念有重叠，但关注点不同：一份任务做法怎样交给 Agent，和应用怎样连接外部能力，不是同一个问题。
面试速答（60 秒版）
Agent Skill 通常是一份可复用的任务说明包，里面有适用场景、处理步骤，也可以附带脚本、模板和参考资料。例如，告诉 Agent 写周报时先检查哪些进展，再按什么格式整理。
MCP 是 AI 应用连接外部能力的协议。应用可以通过 MCP Client 访问 Server 提供的工具、资源和提示词，比如读取项目记录、查询任务状态。
所以，两者不是二选一。Skill 可以指导任务怎么做，执行过程中再使用通过 MCP 接入的能力，也可以调用普通本地工具。
还要注意，Skill 里写了某个命令，或者附带了脚本，不代表它自动拥有执行权限。真正的运行、鉴权和风险控制仍然由应用及执行环境负责；具体怎样发现和加载 Skill，也取决于客户端支持。
知识点详解：会写周报，和拿得到项目进展，是两件事
Skill 交给 Agent 的是什么？
假设咱们在做一个项目周报助手，希望每次都按照同样的要求处理：
先查看本周完成的任务，再找延期事项；没有更新记录的任务不要猜进展；最后整理成“已完成、风险、下周安排”三个部分，并保留来源。
这些要求如果每次都手动粘贴，很容易漏掉。可以把它们整理成一个 Skill。
按照 Agent Skills 规范，一个技能目录以 SKILL.md 为核心，文件前面的元数据说明名称和用途，正文写具体指引。旁边还可以放脚本、参考资料或模板。
例如，周报 Skill 的目录里可以有一份周报模板，也可以有处理导出记录的脚本。它不只是一个好听的名称，而是把这项任务需要的做法和材料放在一起，方便 Agent 在需要时读取。
不过，这仍然不等于 Agent 已经拿到了公司的任务数据。说明里写着“读取项目系统”，系统究竟在哪里、用什么身份读，还没有解决。
MCP 接入的又是什么？
假设公司已经有一个项目管理服务，对外提供“查询本周完成事项”和“查询延期任务”的接口。
可以在这些接口外面提供 MCP Server，让支持 MCP 的应用通过客户端连接它。应用发现可用工具以后，再把适合当前任务的工具交给模型选择；模型提出调用请求，应用继续发起调用，服务端检查权限并返回结果。
这里省掉的是不同应用连接同类能力时，各自约定一套接入方式的重复工作，不是把业务权限交给了协议。
而且 MCP 架构文档列出的能力不只有 Tools，还包括 Resources 和 Prompts。因此，把它简单记成“MCP 就是工具列表”，也不完整。
在周报场景里，Skill 写的是如何整理周报；MCP 可以让应用连接项目服务。数据拿回来之后，Agent 再按照 Skill 的要求整理，两者就接在同一次任务里了。
为什么不能把全部 Skill 一次性塞进模型？
如果只有一个很短的 Skill，直接提供全文未必有问题。
但 Skill 多了以后，每次都带上所有步骤、模板和参考资料，会让输入越来越长，很多内容却和当前任务没关系。用户只想写周报，没必要同时看到“如何生成测试报告”的整套说明。
Agent Skills 采用了按需逐步加载的思路：先让客户端提供技能的名称和描述，用于发现；任务匹配时，再读取主要说明，需要某份模板或脚本时继续取用。官方概览把这个过程称为渐进式披露。
这是一种组织方式，不代表所有 Agent 产品已经按完全相同的步骤实现。项目中要检查实际发给模型的上下文和加载记录，不能因为磁盘里存在 Skill 文件，就当模型一定读到了它。
同样，描述写得太含糊，模型可能根本不知道什么时候用这个 Skill。只写“帮助处理工作”，不如直接说明它适合哪些输入、要产出什么。
带脚本的 Skill，为什么仍然需要工具？
因为文件里有代码，和代码已经执行，是两回事。
假设 Skill 带了一个脚本，用来把项目系统导出的 CSV 汇总成周报数据。Agent 阅读说明后，可以请求一个代码执行工具来运行它。工具执行器准备输入、启动程序，再把输出返回给 Agent。
如果运行环境不允许联网，脚本就不能凭一句“请连接项目服务”自己获得网络权限。如果需要访问密钥，也应该由受控的执行环境按授权提供，不能让 Skill 文档随意扩大权限。
因此，不需要争论“Skill 里有脚本，它是不是就变成 Tool 了”。从使用过程看，Skill 可以携带可执行材料；从执行过程看，仍然需要一个实际运行它的入口。
这也说明，安装外部 Skill 不能只看说明写得漂亮。脚本来源、会读写哪些目录、需要哪些凭据，都应该检查。周报写得对不对，是任务效果；有没有越权拿资料，是另一项必须单独通过的检查。
面试官继续追问
不用 MCP，也可以使用 Skill 吗？
可以。Skill 可以指导 Agent 调用应用已有的普通工具、本地命令或文件能力。
反过来，没有 Skill 的应用也可以通过 MCP 使用外部能力。两者并不存在谁必须依赖谁的关系，是否组合取决于任务和应用设计。
MCP 也有 Prompts，和 Skill 会不会重复？
在提供任务提示方面可能有重叠，不能为了好记强行划成完全不相交的两类。
区别在于组织和分发方式：Skill 通常围绕一个任务组织说明与配套文件；MCP 定义应用和服务端如何发现、获取和调用能力。一个系统可以选择合适的组织方式，没必要为了同时使用两个名词而重复维护同一套规则。
有了 Skill，就能保证每次按步骤完成吗？
不能。模型可能没选中技能，也可能读了以后漏做，工具还可能失败。
可以准备固定的周报任务，检查它是否获取了必要资料、缺少进展时有没有说明、输出是否保留来源。高风险动作则直接由程序设置门禁，不靠 Skill 中的一句“务必遵守”兜底。
面试速记卡
- Skill：组织任务说明，以及可选脚本、模板和参考资料。
- MCP：约定 AI 应用如何连接工具、资源和提示词等外部能力。
- 组合方式：按 Skill 处理任务，通过 MCP 或普通工具获取所需能力。
- 加载方式：可以按需读取，不等于所有内容始终在模型上下文里。
- 执行边界：有说明、有脚本，都不等于已经获得权限或执行成功。
