技术 · 熟练
工具送到了，说明书没送到
连上就有能力，还是连上再翻文档？
接 MCP 的人几乎都撞过同一面墙：工具是接上了，但「什么时候该按这个按钮」还得靠人反复提醒。协议解决的是「能调用什么」，没解决「这类任务该怎么组织步骤」。2026 年 9 月这件事有了正式答案——MCP 的 Skills 扩展定稿，服务器可以把「操作说明书」和工具一起送过来：连上即获得、按需加载、逐文件校验。但「说明书送到了」和「活干得可靠」之间还差三步：来源要认、内容会变、权限得管。这一页把这套机制与实际落地差距讲清，重点是那条容易被忽略的设计——校验粒度从「一份文件」下沉到「每个文件」，这决定了你信的是「一个技能」还是「一次下载」。
方法 · 一图看懂
1
分清「能力」与「用法」 — 工具回答「能调用什么」，技能回答「这类任务怎么排步骤、什么不能做」；两者是两件事，缺前者干不了，缺后者干不稳
2
认来源，不只认名字 — 同名技能来自不同服务时流程可能完全相反（一个要求先核缺失数据，一个直接跳过）；判据是「哪个服务 + 哪份文件 + 当前内容是什么」三者一起认
3
按需加载，别一次装齐 — 技能是「先拿到一行描述，需要哪个再拉全文」；把全部技能塞进上下文，等于把额度和注意力一起烧掉
4
逐文件校验，不看单点摘要 — 摘要只盖住入口文件时，服务端可以「过审一份良性的、再换掉一份被模型同样照读的参考文件」；校验粒度必须覆盖技能内每一个文件
5
先定权限再谈自动化 — 技能会写文件、跑脚本；在把服务交给无人值守流程之前，先把「需要授权的动作自动拒绝」这类边界设好
原理 · 为什么有效
为什么值得为「说明书」单独做一层机制：现在的能力落差，多半不在工具够不够，而在工具与用法脱节。一个服务器把 API 交出去，agent 知道有这个按钮，但不知道「先核时间范围、再查缺失字段、最后按团队口径汇总」——这段知识此前只活在人的往返提醒里。把说明书随连接一起分发，等于让「这套流程该怎么走」变成可被发现、可被动更新的资产：服务端改一次，所有连上来的 agent 都拿到新版。代价也要说清：远程可更新的说明书同时也是一条新的信任面——地址没变不等于内容没变，所以「逐文件摘要 + 来源一致 + 授权约束」这三样不是可选项，它们是让「连接即获得」不至于变成「连接即被替换」的前提。行业侧也有对冲的动作：本季度已经出现专门在安装前扫提示注入与数据外泄的技能扫描器，以及国家层面对生成代码安全审查与智能编程工具恶意指令注入的明确要求。
适用场景
适用：正在接 MCP，或准备把技能分发给多端 / 多客户端的团队；也适用于「同一条流程要在多个 agent 上跑」的团队。判据一句话：你有没有过「工具接好了，但用法还得靠人讲」的时刻？有，本页算的就是这段落差。不适用：只用单一客户端自带的少量技能、不涉及分发与远程更新的个人使用者——那种情况下逐文件校验与来源一致性带来的收益很小，按需加载这一条仍然值得照做。
自测 · 5 问
我能说清我接的这套里，哪些是「能力」（工具）、哪些是「用法」（技能），而不是混在一起谈
我对每个远程技能都确认了「来源服务 + 文件路径 + 当前内容」三样，而不是只凭技能名
我的上下文里没有一次性塞入全部技能描述（按需加载这一条我实际做过）
我校验的粒度覆盖到技能内每一个文件，而不是只看入口那份摘要
在把任何技能交给无人值守流程之前，我已经把「需要授权的动作自动拒绝」这类边界设好
怎么上手 · 验证步骤
拿你手上一个已经接好的 MCP 服务，做三件事：① 让它列出自己对外提供的技能（`skills/list` 一类接口），把返回项记下来 ② 挑其中一个，核对它的来源与文件清单，看校验粒度是覆盖整包还是只覆盖入口文件 ③ 把它接进一条无人值守的流程之前，先设一条「需要授权即自动拒绝」的规则，并让被拒的动作显式报错而不是静默跳过。三件事做完，你对「说明书能不能信」就有自己的判断了。
如果一条流程跑完却「什么都没做」，先去看它是不是被权限规则拒掉了——无人值守下「被拒绝」必须表现为一次失败，而不是一次成功。