“有了 Skills，是不是就不需要 MCP 了？”
这个问题容易把两件事混在一起：Agent 知不知道该怎么做，以及它能不能拿到需要的信息、调用需要的能力。
我的判断是：两者经常一起使用。要选什么，先看任务卡在哪一步。
先拆开一次代码评审
假设你让 Agent 评审一个改动。它至少要完成这些事：读需求，找到对应代码，判断有没有实际问题，给出能复核的依据。
如果它只能泛泛地说“注意异常处理”，缺的可能是评审方法。你可以把准则整理成 Skill：每条问题必须交代触发条件、代码位置、影响和最小改法；没有成立的问题，就明确说没有。
如果它连改动内容都拿不到，继续增加评审准则也没用。此时要解决的是访问问题：通过已有 CLI、API，或者 MCP 服务读到代码和讨论。
先分清缺的是方法、访问能力，还是验证，工具选择才有依据。
Skill：把工作方法交给 Agent
Agent Skills 的基本单位是一个目录。核心的 SKILL.md 放名称、描述和指引，也可以带脚本、参考资料与素材。官方设计采用渐进加载：先发现名称与描述，在相关任务中再读取完整指引，其他资源按需使用。Agent Skills 概览
这很适合保存反复使用的方法。比如我公开的 review-rules，关注需求是否完整、改造是否必要、复杂度是否值得，以及责任边界是否清楚。
$review-rules 复核这条评审意见：
“这里应该增加一个通用重试层。”
请结合当前需求、已有实现和失败场景给出判断。
上面是一个调用示例。它的价值在于把“认真 Review”变成具体的检查问题。至于模型会不会正确应用这些准则，仍然要看输出。
不同宿主怎样发现、触发和执行 Skill，要看各自实现。不能把某个 Agent 的加载方式，当成所有 Agent 都遵守的运行机制。规范中的 allowed-tools 也是实验性字段，支持情况因实现而异。Agent Skills 规范
MCP：约定能力怎样被发现和调用
MCP 定义客户端与服务端交换上下文的协议。服务端可以提供工具、资源和提示模板；它不只是“工具列表”。当前官方架构文档列出 stdio 与 Streamable HTTP 两种传输方式。MCP 架构，2026-07-28 版
回到代码评审：一个服务可以提供读取变更、查询讨论的能力，宿主通过约定的接口使用它。这解决了如何接入的问题。拿到信息以后，按什么标准形成评审结论，还需要任务要求、模型判断与验证。
协议也在变化。查资料时，我会先确认文章描述的版本，再对照实际客户端和服务端。不能拿旧版本的连接流程，直接推断今天所有实现的行为。
放在一起，会发生什么
下面是一个示意流程，不代表某次真实执行记录：
- 用户明确评审范围：这个分支，相对哪个基线，是否允许修改。
- Agent 读取评审 Skill，知道哪些问题值得报、结论要附什么依据。
- 通过已授权的 CLI 或 MCP 能力，读取改动和上下文。
- 结合代码形成判断，必要时运行针对性的验证。
- 给出结论，同时说明没有验证到的部分。
Skill 可以指引 Agent 使用 MCP，也可以使用它已经具备的本地工具。MCP 提供的提示模板也可能承载工作指引，所以“Skill 只负责怎么做、MCP 只负责能做什么”是方便入门的概括，不能当成没有交集的硬边界。
我更愿意用这三个问题来检查一个方案：
| 检查什么 | 一个具体问题 |
|---|---|
| 工作方法 | 它知道一条有效的评审结论需要哪些证据吗？ |
| 可用能力 | 它能读取这次任务实际需要的代码和讨论吗？ |
| 验证结果 | 它说“有问题”或“已修复”时，有什么能复核的依据？ |
我的选择顺序
已有工具能完成任务时，先把反复出现的方法写清楚。需要跨应用复用一组接口、接入外部系统时，再评估 MCP 的接入收益和维护成本。
还有一种情况：方法和工具都有，结果依旧不可靠。此时应该检查上下文有没有缺失、权限是否合适、验收标准是否具体。继续堆 Skill 或服务，不一定能解决问题。
文档里的“不要写入”和执行环境里的“无法写入”也要分开看。判断一次任务的权限边界，要检查宿主、工具和实际授权。仅凭它叫 Skill 还是 MCP，无法判断整套流程的风险。
我在做 Agent 工具时越来越关心的是：一次任务究竟在哪里失败，下一次能不能更早发现。 Skills 和 MCP 都可以帮忙，但最后仍要回到具体任务和结果。
本文基于 2026 年 3 月 10 日的《一文讲透 Skills 与 MCP：从源码看清两者的真正边界》修订。本站版调整了传输方式和加载机制的表述，删去了没有固定版本依据的源码路径及热度数字。技术资料复核于 2026 年 9 月 10 日。