MCP 并没有被 Skills 干掉，相反它们一起解决了 AI Agent 最大的坑

很多人以为 Skills 是来取代 MCP 的，但 Ras Mic 在这期视频里给了一个反直觉的答案：真正的问题从来不是工具不够，而是 Agent 根本不会用。这篇文章拆解 MCP 为什么曾经“翻车”，Skills 又是如何把幻觉、混乱和上下文灾难一并收拾干净的。

行业最大的误会：Skills 不是 MCP 的对手

过去几个月，关于 MCP 和 Skills 的讨论越来越多，但几乎所有争论都建立在一个错误前提上：它们是二选一的关系。Ras Mic 直接点破——“这可能是离真相最远的理解”。

MCP 的角色其实非常清晰：连接。它把 Notion、Gmail、日历、Stripe 这些外部工具暴露给 Agent，让模型“看得到、摸得着”。但问题也恰恰出在这里：当你一次性给 Agent 太多工具时，它并不会变聪明，反而开始胡来。

早期的 MCP Agent 体验堪称灾难：同样的任务，它可能选错工具、跳错步骤，甚至直接开始编造结果。不是 MCP 设计失败，而是我们误以为“只要给模型工具，它自然会知道怎么用”。

工具不等于能力：Home Depot 的残酷隐喻

Ras Mic 用了一个极其贴切的比喻：你和我去 Home Depot，买齐了建后院的所有工具。锯子、电钻、木材一应俱全。问题是——没人知道第一步该干嘛。

MCP 就像这家五金店：它把所有工具整整齐齐摆在你面前。但 Agent 就像两个只会写代码的开发者，根本不知道木头该怎么选、地基先打还是先铺板。

Skills 的价值就在这里显现出来了。它不是新工具，而是专家经验的封装：步骤顺序、决策逻辑、失败兜底，全都写清楚。Skills 把“我能访问什么工具”升级成了“我该在什么情况下，用哪个工具，按什么流程”。这一步，直接把 Agent 从实习生拉到了能独立干活的水平。

MCP 曾经卡死在上下文里，Skills 用“渐进披露”救场

MCP 早期还有一个致命问题：上下文爆炸。为了让模型理解所有工具，你不得不把大量描述一股脑塞进 prompt，结果就是模型反而更不稳定，调用 MCP Server 的成功率直线下降。

Skills 的解决方式非常工程化。一个 Skill，本质上就是一个包含 skill.md 的目录，通过“渐进披露（progressive disclosure）”的方式，把信息按需喂给模型。需要决策时给决策信息，需要执行时给执行步骤。

这和 MCP Server 自带的工具描述并不冲突。Ras Mic 说得很直白：“让 MCP 负责连接，让 Skills 负责呈现、顺序和工作流逻辑。” 这不是语义之争，而是系统边界的重新划分。

Skills 正在变成新基础设施，而不是语法糖

视频最后一个容易被忽略的信号，是 skills.sh 这样的 Skills Marketplace 出现。这意味着 Skills 正在从“团队内部的 prompt 经验”，变成可以交易、复用、标准化的资产。

一旦 Skills 被广泛共享，AI Agent 的竞争力就不再只是模型大小，而是谁掌握了更好的 SOP。MCP 解决的是“能不能连”，Skills 决定的是“连上之后能不能靠谱地干完活”。

这也解释了为什么 Skills 没有取代 MCP，反而让 MCP 真正可用。没有 Skills，MCP 是一堆危险按钮；有了 Skills，MCP 才变成可控的自动化系统。

总结

如果你正在做 AI Agent，最大的 takeaway 只有一句话：别再指望模型自己想明白流程。MCP 给你的是能力边界，Skills 才是行为边界。短期来看，你应该把精力从“多接几个工具”转向“把一个流程写到极致”；长期来看，Skills 很可能会像 API 一样，成为新的竞争壁垒。下一个问题是：当 Skills 可以被市场化时，你的核心经验，还剩下多少是不可复制的？

关键词： MCP， Skills， AI Agent， 幻觉， 工作流

事实核查备注： 需要核查：1）视频发布时间 2026-01-29 是否准确；2）skills.sh 是否为视频中提到的正式名称；3）progressive disclosure 是否为作者原话或术语转述；4）赞助商名称 Grapile / Reptile 的准确拼写。