Agent Skill 能不能替代 MCP，视频给了条件

先补齐这几个词

Agent Skill：Anthropic 推出的一种 AI Agent 设计模式，实际载体是放在指定文件夹里的一份 skill.md 说明文档，模型按需翻阅。在这条视频里，它决定了后面所有讨论都围绕「让模型自己决定读什么」展开。

MCP：把大模型连接外部数据源的机制，解决的是数据从哪来的问题。视频把它放在 Agent Skill 的对面当参照物，两者的分工是整条视频的主线。

渐进式披露：把一份说明拆成几层、只在使用时才展开的加载方式。视频用它解释 Agent Skill 为什么能少占上下文，先看目录，再看正文，最后才动资源。

Token 与上下文：Token 是大模型处理文本的基本单位，上下文窗口能装下的量有限。视频里 Reference 和 Script 的差别就落在这个衡量标准上，读进来的内容要占位置，直接跑起来的脚本不占。

值得讨论的地方在哪

这条视频里最容易引起争论的结论，是 Agent Skill 和 MCP 的边界画在哪。视频给出的定位是分工：MCP 负责连接和供给数据，Agent Skill 负责教大模型怎么处理数据。这个说法本身没什么人反对，问题出在视频紧接着又承认，Agent Skill 自己也能连接数据。

第二处分歧在渐进式披露上。视频把它描述成一套精密的三层机制，元数据始终加载，指令按需加载，资源层再分读取与执行。认同的人看到的是成本控制；怀疑的人并不否认机制本身，而是认为脱离具体任务量谈省 Token 没有意义。

两处分歧其实指向同一个问题：Skill 到底能承担多少原本属于外部系统的活。做集成的人和踩过坑的人，答案会不一样。

视频给出的一侧理由

视频倾向于「Skill 可以接手一部分原本交给 MCP 的工作」，论据有三条。

一是按需加载。初期只加载所有 Skill 的名称和描述，被选中之后才加载完整指令，因此不必每次把整套规则重新塞一遍，省下的是 Token。

二是资源层的 Reference 支持条件性加载。视频举的例子是，会议内容涉及财务时才去加载财务手册，相当于在按需之上再按需一次。

三是 Script 只执行、不读取。脚本跑完，模型通常不去看代码本身，只关心执行结果，占用的上下文很少。视频里给的场景是上传文件这类自动化操作。

这三条合起来的意思是，日常任务不必都升级成一套服务，一份说明文档加一个脚本就能覆盖。

另一侧的理由是什么

反方的通行看法是，Skill 的强项在处理规则，不在连接与权限。视频自己也提到，Agent Skill 在代码执行的安全性和稳定性方面不如 MCP。一个主要负责「怎么处理」的机制去碰数据和执行，安全边界就得由外部来兜底，这部分责任不会因为写在 skill.md 里就消失。

另一类质疑针对渐进式披露的代价。三层结构意味着文件要拆得足够细，拆分和维护的活是人来干的，规模上去以后，这部分成本只是从 Token 账上挪到了工程账上，并没有消失。

视频之外还有其他做法，比如干脆把规则写进系统提示词，或者把整套流程封装成独立服务，本文不展开这几条路线。

什么条件下哪一侧成立

任务只涉及轻量级脚本和简单逻辑时，Skill 这一侧成立。把规则写进 skill.md，需要时挂一个脚本，不需要额外起服务，也不用维护连接层。

任务要接的是长期维护的数据源，或者要处理权限、审计这类问题，MCP 这一侧更稳。视频的用词是「更适合」和「不如」，不是「不能」，两者也可以结合在一起用。

判断标准可以简化成一句：这段逻辑里的数据和权限由谁管。没人管、也不打算专门管，Skill 是省事的做法；已经有一套数据接入在跑了，让 skill.md 只管规则就行。

需要自己核验的事实

视频发布时的说法里，有几项会随时间变化：Anthropic 对 Agent Skill 的标准与实现细节、开放标准的落地进度、各家模型对 skill.md 的支持程度。这几项以官方当前文档为准。

还有两点要自己确认。一是你用的模型平台是否支持 Reference 和 Script 这两层资源，视频讲的是机制设计，具体到某个产品能不能跑脚本、脚本在什么沙箱里执行，要看该平台的说明。二是成本口径，省 Token 不等于省钱，脚本执行本身可能有单独的计费项。