夜雨聆风想让 AI 真正替你干活，先分清 Skill 和 MCP
现在很多人聊 AI Agent，都会提到两个词：Skill 和 MCP。听起来它们都像是在给 AI 增加能力，所以不少人会把它们混在一起理解。表面上看，这样说也不是完全错，但如果真要用它们搭建工作流，这个理解就太粗了。
因为 Skill 和 MCP 不是同一个层级的东西。
简单说，Skill 更像是流程层。它回答的是：这类任务到底应该怎么做。先看哪些信息，后执行哪些步骤，输出要长什么样，最后怎么检查结果，这些都属于 Skill 关心的范围。
而 MCP 更像是能力层。它回答的是：Agent 能不能通过一套标准接口去连接外部系统。比如读取公司内部系统的数据，查询业务接口，获取数据库当前的 schema，或者对某些外部工具执行创建、更新、发送等操作。
所以一句话概括就是：Skill 负责告诉 Agent 怎么干活，MCP 负责让 Agent 能连接到外部工具和数据源。
先看 Skill。
你可以把 Skill 理解成一份写给 Agent 的专项工作说明书。比如你经常让 AI 帮你写公众号文章，每次都要提醒它文章结构、表达风格、哪些词不能用、代码要怎么标记、最后要输出成什么格式。一次两次还好，如果每天都要复制这些要求，就会很麻烦，也很容易漏掉关键规则。
这时候，把这套固定流程整理成一个 Skill，就会更合适。以后只要遇到同类任务，Agent 就可以按这份说明书来做，而不需要你每次重新讲一遍。
所以 Skill 的核心价值，不是让 Agent 突然拥有一个新的外部能力，而是把你反复使用的工作方法固定下来。它更像是把经验沉淀成流程，让 AI 每次处理同类任务时都更稳定。
还有一个很实际的好处，就是减少上下文浪费。
如果你每次都把一整套规则复制进对话，模型的上下文很快就会被占掉一大块。像一些支持 Skill 机制的 Agent 工具，通常不会一开始就把完整说明全部塞进去，而是先把 Skill 的名称、描述和路径放进上下文。等它判断这次任务确实需要这个 Skill 时，再读取完整内容。
这就像你去公司办事，前台先知道有哪些部门，等确认你要办哪类业务，再把你带到对应部门，而不是一开始就把所有部门的制度手册都塞给你。
那什么情况下值得做一个 Skill 呢？
可以看几个信号。第一，同一类任务已经重复做过很多次。第二，每次开始任务前，你都要复制一大段规则。第三，任务质量很依赖固定流程，不是简单一句提示词就能稳定完成。
如果满足这些条件，就可以考虑做成 Skill。反过来，如果只是一次性任务，或者一句话就能说清楚需求，那就没必要专门建一个 Skill。为了一个很小的临时任务单独建流程，反而会增加维护成本。
从结构上看，一个最简单的 Skill 通常就是一个文件夹，里面放一个 SKILL.md。如果任务更复杂，还可以继续放脚本、模板、参考资料和素材文件。比如可以有 scripts/、references/、assets/ 这些目录。
真正关键的是 SKILL.md 这个文件。里面最重要的字段通常是 name 和 description。尤其是 description，它不能只写一句很空的话，比如“用于写文章”或者“用于处理数据”。更好的写法是说明清楚：什么时候应该用这个 Skill，什么时候不应该用，以及它适合解决哪类任务。
因为 Agent 能不能正确调用一个 Skill，很大程度上取决于描述是否清楚。如果描述太泛，它可能会误用；如果描述太窄，它又可能该用的时候没用。
Skill 放在哪里，也要看你希望哪个工具来读取它。比如在 Codex 里，项目级路径通常是 .agents/skills，个人级路径通常是 $HOME/.agents/skills。在 Claude Code 里，项目级路径一般是 .claude/skills，个人级路径一般是 $HOME/.claude/skills。
如果你希望同一套 Skill 同时给多个工具使用，就不要只放在某一个工具专属目录里。更稳妥的做法是选一个目录作为源文件，然后同步到各个工具会扫描的位置。个人使用时，可以用软链接；团队协作时，如果担心软链接在不同系统上表现不一致，也可以用同步脚本，或者提交两份目录。但一定要明确哪一份是源文件，否则后面很容易出现两边内容不一致的问题。
这里还要特别注意一点：Skill 不能凭空给 Agent 增加外部连接能力。
如果一个 Skill 只是说明文档，那它再详细，也只是告诉 Agent 应该怎么做。它本身不会自动获得查询数据库、访问内部系统、调用业务接口的能力。如果任务需要读取实时数据，或者需要对外部系统执行操作，背后还必须有脚本、插件、MCP 服务，或者其他已经授权的工具来支撑。
也就是说，Skill 可以把这些能力组织成流程，但它不等于能力本身。
再看 MCP。
MCP 可以理解成一套连接外部工具和外部系统的标准接口。很多时候，Agent 只能看到当前对话、当前项目文件，或者你手动上传的内容。但真实工作里，很多关键信息都在外部系统里，比如订单系统、日志平台、数据库、工单系统、消息工具、知识库等等。
如果没有连接能力，Agent 就只能根据你给它的内容猜。你不给它订单状态，它就不知道订单状态；你不给它日志，它就无法判断接口为什么报错；你不给它数据库结构，它就只能凭空推测字段名。
MCP 的作用，就是让 Agent 在授权范围内，用统一方式连接这些外部系统。这样它就不只是一个“会聊天的模型”，而是可以在真实工具和真实数据上工作。
不过，MCP 对上下文的影响和 Skill 不一样。
它通常不会一上来就把外部系统里的所有真实数据全部塞进对话。更常见的方式是先让 Agent 知道当前有哪些 MCP 服务、有哪些工具、每个工具大概能做什么、需要什么参数、会返回什么结果。
也就是说，工具名称、工具描述、参数结构、服务说明这些元信息，本身就会占用上下文。真正的业务数据，一般是在调用工具之后，才会进入当前上下文。
所以不能说 MCP 默认会把所有外部数据都加载进来，但也不能说它完全没有上下文成本。接入的 MCP 服务越多，工具越多，元信息就越多。一次查询返回的记录太多、字段太杂、时间范围太大，也会让 Agent 判断变得更困难。
用 MCP 时，一个很重要的原则是：让查询尽量小而准。
只开启必要工具，只查询必要系统，只返回必要字段，只拿这次任务真正用得上的信息。不要为了省事，一次性把一堆无关数据都扔给模型。数据越多，不一定答案越好，有时候只会让它更容易跑偏。
那什么时候应该考虑接入 MCP 呢？
可以问自己几个问题。这个信息是不是经常变化？这个信息是不是不在当前项目里？每次查询能不能只返回必要内容？这个工具会不会修改外部系统？
如果某类信息经常变化，而且不在当前项目或当前对话里，那它就很适合通过 MCP 接入。比如订单状态、支付记录、接口日志、客服消息、库存数据，这些都不是静态文档，靠手动复制很低效，也容易过期。
第三个问题是上下文边界。查询结果一定要控制范围，最好能按订单号、时间范围、字段列表来精确返回。第四个问题是安全边界。只读工具和写入工具完全不是一回事。能查询数据，风险相对可控；能创建、更新、删除、发送内容，就必须更谨慎。
刚开始接 MCP 时，建议先从只读工具做起。比如先让 Agent 能查日志、查订单、查文档、查接口状态。等流程稳定后，再考虑是否开放写操作。写操作最好加确认机制，避免模型误操作外部系统。
如果是在 Codex 里配置 MCP，常见做法可以通过命令行添加，也可以修改配置文件。例如添加一个 MCP server，可能会用到类似这样的命令：codex mcp add context7 -- npx -y @upstash/context7-mcp。
配置完成后，可以用 codex mcp --help 查看当前环境支持哪些 MCP 相关命令。在 Codex 的终端界面里，也可以用 /mcp 查看当前启用的 MCP 服务。如果是手动配置，默认位置通常是 ~/.codex/config.toml。如果项目已经被设为可信，也可以使用项目级的 .codex/config.toml。
现在把 Skill 和 MCP 放在一起看，区别就很明显了。
Skill 负责沉淀流程。比如文案怎么写、代码评审怎么做、订单排查先看什么后看什么、报告最后怎么输出。它解决的是“做事方法”的问题。
MCP 负责连接工具。比如查订单系统、查日志平台、读数据库结构、调用消息工具、访问内部知识库。它解决的是“能不能拿到外部数据、能不能操作外部系统”的问题。
举个具体场景，你想让 Agent 排查一笔订单为什么退款失败。
项目里的规则文件可以告诉它业务背景，比如退款状态有哪些、失败码怎么理解、哪些场景需要人工介入。订单排查 Skill 可以告诉它操作流程，比如先查订单状态，再查支付记录，再查退款记录，最后查看日志并整理原因。MCP 或其他连接能力，则负责真正去订单系统、支付系统、日志平台里读取实时数据。
在这个场景里，几类东西的分工非常清楚。
业务规则放在项目规则文件里。排查方法放在 Skill 里。读取外部系统数据这件事，由 MCP、脚本或者插件提供。Skill 可以规定应该怎么使用这些能力，但不能替代这些能力本身。
这也是很多人最容易误解的地方。他们以为写了一个很详细的 Skill，Agent 就能自动访问所有系统。实际上不是。Skill 只是流程说明，它告诉 Agent 该怎么查、怎么判断、怎么输出。但如果没有外部连接能力，它最多只能基于已有上下文工作。
反过来，如果你只接了很多 MCP 工具，却没有好的 Skill，也会出现另一个问题：Agent 虽然能查很多系统，但不知道该按什么顺序查，也不知道哪些结果更重要，更不知道最后应该怎么整理结论。这样就会变成“能力很多，但流程混乱”。
所以真正好用的 Agent 工作流，往往不是只靠 Skill，也不是只靠 MCP。而是把两者配合起来。
Skill 让 Agent 做事更稳定，MCP 让 Agent 能接触真实系统。前者是方法，后者是接口。前者偏流程，后者偏能力。一个负责把事情做对，一个负责让事情做得成。
如果你只是想让 AI 按固定风格写文章、整理会议纪要、检查代码规范、生成报告，那优先考虑 Skill。如果你想让 AI 查询实时数据、读取内部系统、调用业务接口、操作外部工具，那就需要考虑 MCP 或类似的连接能力。
判断得越清楚，设计出来的 Agent 就越靠谱。否则很容易出现两种极端：要么把所有事情都写进提示词，最后上下文又长又乱；要么接了一堆工具，却没有流程约束，结果 AI 查了很多东西，还是给不出稳定结论。
一句话收尾：Skill 不是插件，MCP 也不是流程文档。Skill 解决“怎么做”，MCP 解决“能连接什么”。把这两个层级分清楚，你才算真正开始理解 AI Agent 的工程化用法。
