上个月我给 Agent 接了一个第三方抓取服务，顺手把调用方法复制进本地的 SKILL.md：批量任务怎么拆、报错后等多久、结果到哪里取。
两周后，对方服务调整了限流策略，推荐抓取流程也改了，而我本地那份文件还停在第一次跑通时的旧规矩。
Agent 能调通接口，却照着旧流程乱撞。Skills Over MCP 最值得解决的，就是工具已经更新、使用方法却留在原地的脱节。
看完提案草案和工作组记录，我的判断是：它有实际价值，但适用场景比舆论热度窄得多。
少维护一份跟不上服务的说明
Skills Over MCP 的核心意图，是让你接入一个外部服务时，能顺带读取配套的技能。工具与操作规范由提供方统一维护并发布，开发者不需要再去满世界找仓库、手动复制粘贴。
工具描述只负责讲清单次调用；跨工具的选择条件、调用时序和校验方法，则放进配套的 Skill。
静态配置文件无法感知远端服务的变动。Git 或包管理工具当然也能做更新，但需要额外维护一条分发链路。MCP 的工程价值在于复用现有连接，把接口与使用方法的版本绑定在一起。
但这仅仅是分发协议的便利，内容是否匹配工具版本，依然完全依赖提供方的工程质量。
按需加载并不依赖新协议
很多讨论把“按需加载”当成 MCP 扩展独有的卖点。
实际上，把几百行工作流塞进系统提示词，确实会挤占上下文。但通过名称和简介做前置路由、命中时才动态读取正文与附件，这套渐进披露机制早在标准的本地 Skill 规范里就已经跑通了。
即便不用新协议，宿主给模型挂载一个基础的读取工具，模型同样能在需要时调出正文。
标准化协议省下的是各家客户端重复适配的成本。扩展的核心收益在于让宿主统一管理这些技能：清晰展示来源、统一权限审批、过滤禁用项目。
这是一项标准化的产品功能，而不是模型理解力上的跨越。
省掉了更新动作，省不掉信任判断
远端技能本质上是一段带有明确操作意图的第三方文本。
它可能指导 Agent 正确分页，也可能要求 Agent 读取本地密钥、执行 Shell 脚本并将数据外发。把它冠以 Skill 的名字，并不会让这些要求自动合法。
SHA-256 摘要只能证明收到的文件与清单一致。恶意提供方完全可以写出恶意内容并附上正确的摘要，哈希校验照样全绿。
草案对安全边界做出了要求：远端技能在触发本地代码执行前，必须取得逐项审批；且一旦远端文件哈希发生变化，原有批准立即作废，必须重新向用户确认。
这意味着“静默全自动更新”在安全规范下根本无法成立。宿主审得严，每一次依赖更新都会打断交互；放得宽，远端文本注入就会直接击穿本地沙箱。
哪些技能才值得随连接分发
最适合迁移的，是接口与策略持续变动的第三方 SaaS 服务。比如爬虫服务、云厂商 API 或 GitHub 工具链。这类服务的工具与最佳实践由同一方提供，接口更新与限制调整高度同步，厂商有充分动力去合并维护。
企业内部的复杂协同也有价值：服务端可以根据员工登录凭据动态下发业务流，销售看到销售规约，法务拿到合规检查清单。
但对于绝大多数场景，本地文件依然是最佳解：
- 个人静态技能与写作模板：这类规范没有外部同步需求，放在本地仓库最稳妥；
- 团队代码风格与架构规约：代码仓库本身就是事实的唯一来源，单独起一套 MCP 服务只会引入单点故障；
- 强顺序依赖的操作链：三两句能讲清的调用顺序，直接写在工具定义里；必须严格遵循的确定性逻辑，直接写进宿主代码，不要交给模型临场发挥。
Skills Over MCP 本质上是分发与版本协同协议，不要指望它能凭空拔高 Agent 的推理上限。
在急着把本地目录推倒重构之前，先去翻翻你的代码库，找出一份真正因为跟不上远端服务而导致任务跑偏的 SKILL.md。如果找不到，就先别搬。