01问题引入：为什么大家突然拿 Skills 和 MCP 比？
这个视频的切入点很实际：随着 Claude Code、Claude Desktop 和各种本地编码 Agent 把 Skills 推到台前，很多开发者开始问一个听起来很诱人的问题：如果一个 skill 目录里可以放 Markdown 指令、参考资料和脚本，那我是不是不需要再写 MCP server 了？
讲者的答案不是简单的“是”或“不是”。更准确地说，Skills 确实吃掉了一部分早期 MCP 使用场景，尤其是本地开发者工作台上的小型自动化；但 MCP 仍然负责另一类更硬的基础设施问题：标准化工具接口、实时资源访问、认证，以及让自研 Agent 微服务也能可靠调用外部系统。
核心判断可以这样转述：Skills 和 MCP 有交叠，但它们的重心不同。Skills 更像把本地经验、脚本和静态知识打包给 Agent；MCP 更像把外部系统变成可发现、可调用、可治理的标准接口。
如果你正在搭 Claude Code 工作流，这支视频特别值得看，因为它没有陷入“新东西替代旧东西”的兴奋叙事，而是在帮你决定：哪些能力应该沉淀成 skill，哪些能力应该继续放进 MCP。
02核心概念：先把 MCP 和 Skills 摆正
MCP：给 Agent 一个标准化的外部世界接口
视频先复习 MCP 的基本设定：你有一个 Agent，它可能跑在开发者电脑上，也可能是云里的微服务。用户把 prompt 发给 Agent，Agent 再调用大模型判断下一步。问题在于，大模型默认不知道你的内部 wiki、客户工单、Google Docs、Kafka topic，也不能自己改变外部系统状态。
MCP server 就站在 Agent 和外部系统之间。它知道怎么访问这些资源，也知道怎么调用这些工具，并用标准接口把能力“广告”给 Agent。对 Agent 来说，这个接口是可插拔的；对系统团队来说，这是一层可以治理、授权、升级和复用的协议边界。
Skills：把本地工作经验变成 Agent 可读的目录树
Skills 的形态则轻得多。一个 skill 本质上是一个目录，里面通常有一个 SKILL.md，写着触发条件、操作步骤、注意事项和领域知识。目录下面还可以放脚本、模板、资源文件，供 Agent 在执行任务时读取或调用。
这让 Skills 很适合承载“流程知识”：比如怎么编辑 Excel、怎么生成某种报告、怎么用固定脚本跑一次检查、怎么在当前代码库里按团队习惯做代码审查。它像是把资深同事的操作手册和工具箱装进 Agent 的背包里。
真正的分界：本地上下文 vs 外部系统边界
视频最有价值的一点，是把两者的差别从“功能清单”拉回到“部署位置”和“数据新鲜度”。Skills 通常贴近本地文件系统，适合静态知识、操作流程、脚本包装和当前工作区里的任务。MCP 更常面对外部系统、实时数据、网络资源、鉴权流程和跨 Agent 的标准化接入。
03关键论点：Skills 没有杀死 MCP，只是改变了 MCP 的使用边界
论点一：MCP 的 resources 用得少，tools 反而成了主流
讲者观察到，过去 9 到 12 个月里，MCP 生态一个明显变化是：很多人没有大量使用 resources API，而是把资源查询也包装成 tool call。比如查询工单、读文档、拿实时状态，都可以设计成一个带参数的方法调用。这个现象不是 MCP 失败，而是 API 设计在真实社区里自然收敛的结果。
这也解释了为什么 Skills 看起来能替代一部分 MCP：如果你只是调用一个本地 CLI、读一批固定文件、跑一个可预测脚本，那 skill 里的脚本入口确实可以完成工作，不一定要为了这件事起一个 MCP server。
论点二：Streamable HTTP 和 OAuth 2.1 让 MCP 更像真实基础设施
视频也提醒，MCP 本身并没有停在早期形态。相比早期依赖 server-sent events 的体验，streamable HTTP 对云端部署和网络基础设施更友好。OAuth 2.1 支持也让“用户在本地 Agent 前授权 GitHub、Google 或其他服务”这种体验更自然。
不过讲者也指出，OAuth 对本地 Agent 很顺手，但对无人值守的 Agent 微服务仍然有边界。一个云端长期运行的 agentic microservice 不一定适合弹出一个用户授权窗口，它需要另一套服务端身份、授权委托和密钥治理方案。
论点三：本地 coding agent 场景里，Skills 的替代性最强
如果你讨论的是 Claude Code 这类本地 coding agent，Skills 的确非常强。它可以访问当前工作目录，可以调用已经登录过的 CLI，可以读取项目里的配置和约定。此时一个 skill 脚本调用云厂商 CLI、GitHub CLI 或内部工具，体验上会很像调用一个 MCP tool。
判断点很简单：如果能力强依赖本机环境、当前代码库、现成 CLI 登录态和团队操作流程，优先考虑 Skill；如果能力要给多个 Agent、多个环境或云端服务稳定复用，优先考虑 MCP。
论点四：自研 Agent 微服务仍然需要 MCP 这类标准接口
视频后半段把视角从“我电脑上的 Claude Code”切到“我自己写的 Agent 微服务”。这时 Skills 的本地目录树优势就弱了：微服务要访问的是外部系统，要处理的是认证、实时数据、可观测性、错误边界和接口契约。对这种场景，MCP 提供的标准接口仍然有意义。
讲者还提到一个值得关注的趋势：未来 Skills 也可能通过 Python API 等方式进入自研 Agent 运行时。但至少在视频录制时，这种用法还不够普遍，不应该因此提前把 MCP 判死刑。
04决策矩阵：到底该用 Skill、MCP，还是两者一起用？
| 场景 | 优先方案 | 为什么 | 主要风险 | 工程建议 |
|---|---|---|---|---|
| Claude Code 本地代码审查、文档生成、测试流程 | Skill | 流程知识、模板、脚本和项目文件都在本地，Agent 可以直接读取并执行。 | 容易把临时脚本写成隐式依赖，换机器后复现困难。 | 把触发条件、依赖、输入输出和失败处理写进 SKILL.md。 |
| 调用已登录的 GitHub CLI、云厂商 CLI、内部命令行工具 | Skill 或 Skill + CLI | 本机已有认证态，脚本包装成本低，适合个人或小团队工作台。 | 权限边界不够显式，日志里可能泄露敏感参数。 | 限制脚本参数，避免输出 token，把 destructive 操作做成显式步骤。 |
| 多个 Agent 都要访问同一套工单、知识库、数据库或消息流 | MCP | 需要标准化能力发现、实时数据访问、鉴权和跨运行时复用。 | server 维护成本更高，接口设计不好会让 tool 变得碎片化。 | 把常用查询设计成少量高质量 tools，并保留清晰错误语义。 |
| 云端无人值守 Agent 微服务，需要执行外部副作用 | MCP 或专门服务 API | 这类系统需要服务端认证、审计、重试、限流和可观测性。 | 本地 skill 脚本很难表达长期运行服务的权限和状态模型。 | 用 MCP 承接工具边界，用应用层处理策略、队列和恢复逻辑。 |
| 团队流程既有本地操作手册，又要访问远端系统 | Skill + MCP | Skill 负责告诉 Agent “怎么做”，MCP 负责提供稳定的外部能力。 | 重复封装同一个能力，导致文档和接口漂移。 | 让 Skill 引导流程，让 MCP server 成为唯一外部数据/副作用入口。 |
这张表的背后，其实是一条很朴素的架构原则：不要因为某个机制“也能做到”就把它推到所有场景里。Skills 是低摩擦的本地知识和脚本分发方式；MCP 是面向工具生态和外部系统的协议边界。好的 Agent 系统往往会同时用到二者。
05引用块：这支视频最值得带走的判断
Skills 不需要运行在云端，它们是 Agent 能看见的一组本地文件；MCP server 则更像一段基础设施，负责把真实系统里的工具和资源标准化暴露出来。
在本地 coding agent 场景里，Skill 调 CLI 的确会让人感觉像 MCP tool；但一旦转向自己写的云端 Agent 微服务，MCP 的接口和治理价值又会回来。
开发者不应该只学其中一个。这个领域变化很快，MCP 和 Skills 都是 2026 年 Agent 工程的基础词汇。
06时间戳目录：按视频脉络快速复看
- 00:00提出争议：Skills 到处出现，是否意味着 MCP 的结束？
- 00:35快速复习 MCP：Agent、LLM、tools/resources 与 MCP server 的关系。
- 01:35生态观察：resources API 使用不多，很多资源访问被包装成 tool call。
- 02:05MCP 的新进展：streamable HTTP 更适合网络和云端部署。
- 02:35OAuth 2.1：本地 Agent 通过用户授权访问 GitHub 等服务的体验。
- 03:45转入 Skills：一个 skill 是 Markdown 指令加目录树，可包含资源和脚本。
- 05:05Skills 与 MCP 的资源差异：静态本地参考 vs 实时外部数据。
- 06:10脚本和 tools 的重叠：CLI 登录态让 skill 脚本看起来像 MCP tool。
- 07:15关键分界：本地 coding agent 可以用 Skills，但云端 Agent 微服务仍需要 MCP。
- 08:35未来趋势：Skills API 可能进入自研 Agent，但目前仍要同时理解 MCP 与 Skills。
07相关推荐：继续补齐 Agent 工程地图
如果你看完这支视频，最自然的下一步不是再追一个新名词，而是把三个层次串起来：本地 Agent 工作台怎么组织流程，MCP 怎么接入真实工具，团队级 Agent 系统怎么做治理。