Skills vs MCP：到底谁在“接管” Agent 生态？

如果你在 2026 年初混过一阵子「coding agent 圈」，大概率见过一句话：“Skills 会不会把 MCP 干掉？”

Skills 不会“接管”MCP，MCP 也不会“吞掉”Skills。真正正在发生的，是 Agent 生态终于开始分层：

• Skills 负责“怎么做”：把团队经验、流程、判断标准写成可复用的工作法（通常是 SKILL.md + references/scripts）。
• MCP 负责“能做什么”：把真实世界的工具、数据源、权限边界变成 Agent 能调用的“能力接口”（JSON-RPC 协议 + server）。

Block 的 Goose 官方文章用 GitHub Actions vs Bash 的类比讲得很直白：工作流文件不执行命令，runner 才执行；Skills 描述流程，MCP 提供 runner。

一. 为什么“Skills vs MCP”会被吵成二选一？

因为它们都在解决同一个终极问题：让 Agent “做成事”，而不是“说得像回事”。但人类很容易把“结果相似”误判成“机制相同”。

你看到一个 Agent 能完成“排查 CI 失败、修 PR、再发起部署”，很自然会问：这到底靠的是 Skills，还是 MCP？

答案是：靠两者的协作。

• Skills 让 Agent 知道你们团队的“正确姿势”：优先看哪类日志、怎样输出诊断、哪些改动必须走人工确认、格式要不要带 owner、要不要补回归测试。
• MCP 让 Agent 真正拿得到“证据”和“操作杆”：拉取 workflow runs、读取 job logs、查 deployment 状态、调用内部工单系统、查监控指标。

如果你只看到了 Skills 目录里有 scripts/，就会误以为“Skills 也能执行”。但 Goose 那篇文章强调得很清楚：Skill 可以带脚本，但执行脚本的能力来自工具层（比如 MCP 提供的 shell / filesystem / GitHub API 这类能力）。

二. 把概念拆清：Skills、MCP、AGENTS.md 各管哪一层？

别把它们当“竞品”，而是把它们当“不同层的配置与协议”。

2.1 Skills：可复用的“流程 + 经验”

GitHub Copilot 的官方定义非常直接：Agent Skills 是由 instructions、scripts、resources 组成的文件夹，Copilot 会在相关任务时加载以提升效果；SKILL.md 是必需的。

Anthropic / OpenAI 的 skills repo 也强调同样结构：一个技能就是一个文件夹，有 SKILL.md，可选 scripts/、references/。

关键点在于：Skills 更像“组织化的上下文”，而不是“连接器”。

2.2 MCP：把外部系统变成“工具/资源/提示”的开放协议

MCP 的官方规格明确：消息遵循 JSON-RPC 2.0，协议包含 lifecycle、capability negotiation、以及 server 暴露的 resources/prompts/tools 等层。

MCP 生态还有一个很关键的事实：它不是“某个工具的私有插件框架”，而是一整套 client–server 的通用协议 + SDK + server registry。官方 GitHub 组织把 SDK 和 server reference repo 都列得清清楚楚。

2.3 AGENTS.md：给 Agent 的“README”

AGENTS.md 的定位非常像“面向 Agent 的贡献指南”：构建、测试、代码风格、PR 规范。

它解决的是“项目常驻上下文”的问题：放哪、怎么组织、如何层级覆盖（比如 monorepo 里多个 AGENTS.md）。

• AGENTS.md：常驻规则（always-on）
• Skills：按需加载的流程包（on-demand playbook）
• MCP：外部能力接口（tools/resources runtime）

这套分工也和 Thoughtworks 在 2026 年 2 月那篇“Context Engineering for Coding Agents”里对“context interfaces”的划分高度一致：把 tools、MCP servers、skills 都视为“让模型获取更多上下文/能力的接口”，并强调“上下文越来越多，反而需要策略化管理”。

三. 到底是谁在“接管”生态？真正接管的是：分发与可组合性

如果你非要找“接管”的对象，那不是 Skills，也不是 MCP，而是“可组合、可分发、可治理”的工程体系。

2026 年技能生态爆起来，和两个现实因素强相关：

1）分发突然变得像包管理器一样顺滑

Vercel 推了 npx skills + skills.sh，把“到处复制粘贴 prompt 文件夹”的时代直接翻篇：安装、更新、发现、排行榜、甚至 telemetry 都做成产品。

2）多 Agent 时代逼你把“经验”打包

GitHub Copilot 在 2025 年 12 月明确宣布支持 Agent Skills，且能读取 .claude/skills 等目录——这等于把 Skills 从 “某一家” 推到“跨工具”的通用格式上。

所以，生态的“接管者”其实是：

• 标准格式（SKILL.md / AGENTS.md）
• 分发网络（skills.sh / registry.modelcontextprotocol.io）
• 安全治理（供应链扫描、权限边界、审计）

四. 从工程视角对比：Skills vs MCP 不是“谁更强”，是“谁更靠近风险源”

4.1 Skills 的主要风险：供应链 + “流程权威化”

Skills 说白了就是可共享的工作法。一旦被广泛安装，它会变成某种“默认权威”。这带来两类风险：

• 供应链风险：skills.sh 这种开放目录让“任何 GitHub repo 都可能被安装”，这和 npm/PyPI 的风险结构非常像。Socket 专门写了文章，强调对 skills 生态做供应链扫描，因为风险形态与包生态高度同构（恶意内容、typosquatting、维护者被攻陷等）。
• 流程固化风险：你的团队如果把一个不成熟的 Skill 当“圣经”，Agent 会稳定地、重复地犯错——而且错得很一致，排查起来还挺“像是有人故意的”。

应对策略（企业级更要做）：

• Skills vendoring：把外部 skill 固定 commit/版本拉进内网仓库再使用（像 vendor 依赖）。
• 对 scripts/ 一律 code review + 最小权限执行（沙箱/容器/只读 token）。
• 明确“需人工确认”的边界：例如修改 CI 权限、触发生产发布、操作客户数据等。

4.2 MCP 的主要风险：权限边界 + “真实世界写入”

MCP 的危险更“硬核”：它不是教 Agent 怎么做，而是真的给它一把钥匙。

MCP spec 和 servers repo 都强调了 capability negotiation、server features、以及 server 暴露 tools/resources/prompts 的机制；你暴露什么，就等于允许 Agent 在什么边界内行动。

这也是为什么 MCP 的生态会迅速出现 Registry，试图把 server 分发与可发现性标准化。

应对策略（尤其是 ToB）：

• 最小暴露：不要把“删除数据/转账/关服务”这类 admin 动作直接做成 tool；或者必须二次确认。
• 强审计：所有 tool invocation 记日志、带 trace id、可回放。
• 权限分层：读 vs 写、测试 vs 生产、单租户 vs 多租户隔离。
• 把“写操作”做成“提交变更请求”，由人或审批系统执行（Agent 生成 PR / 提案，而不是直接改生产）。

五. 2026 的趋势判断

如果你观察 2025 Q4 之后的信号，会发现行业正在把“协议/格式”从公司资产迁移到更中立的治理结构。Wired 报道提到 OpenAI、Anthropic、Block 等把关键技术放到 Linux Foundation 旗下的新组织，推动 Agent 标准协作（文中点名 MCP、AGENTS.md、Goose）。
同类报道也提到 MCP 与 AGENTS.md 的开源治理与社区驱动方向。这意味着：

• MCP 会越来越像“AI 时代的 LSP/HTTP”：基础设施层的协议，一旦形成网络效应，很难被替代。
• Skills/AGENTS.md 会越来越像“AI 时代的 README + runbook + policy-as-code”：你不一定每天谈它，但你会越来越依赖它来规模化协作。