---
title: 从 MCP 到 SKILL：关于 Agent 扩展机制的思考
date: '2026-01-14 23:34:02'
draft: false
summary: MCP 解决连接标准化，SKILL 解决工作流编排与状态外部化；当 Agent 进入复杂任务阶段，真正的关键不再是能力多少，而是上下文、状态和执行边界如何分层。
slug: from-mcp-to-skill
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/5255134503765413
- platform: X / Twitter
  url: https://x.com/jolestar/status/2011461813767155828
tags:
- mcp
- skill
- agent
topics:
- ai
- software-engineering
type: post
---

去年 MCP 爆火，大家一度有种感觉：只要把工具都接进来，AI Agent 就会“活”过来，像一个长了手脚的人，什么都能干。

如果把 LLM 看作大脑，tool call / function call 就像让它能指挥四肢：模型填参数，代码去执行，再把结果喂回去继续推理。MCP（Model Context Protocol）把这套机制做成了“标准插头”。

所以当时最乐观的推论很自然：只要 MCP 工具够多，Agent 就有无限多的手脚。

但很快大家就撞墙了。

## 第一堵墙：容量瓶颈

工具的定义本身要进入系统 prompt 或等价的工具上下文；工具越多，占用越多，留给“干活”的空间越少。某些 AI coding 工具最多支持配置 100 个 tools，而一个 GitHub MCP 可能就带 50 多个。

你想把世界都接进来，但大脑的工作台面就这么大。

## 第二堵墙：任务闭环瓶颈

很多 MCP 的调用结果会被直接回填上下文。短结果当然舒服，长结果就会触发两个问题：要么上下文爆炸，要么被截断丢尾巴。

我在做 `holon` 的时候就踩过这个坑：让 AI 去处理 PR 的 review comments，如果 comments 一多，直接回填上下文就会被截断，结果总是漏修。

后来反而退回到更“原始”的 GitHub CLI 会更稳：AI 先用 `gh` 把评论拉下来写成文件，再用 `grep`、`jq` 或简单脚本去筛选、聚合，只把必要的摘要喂回上下文继续推理。

这个过程让我意识到一个很基础、但之前容易被忽略的问题：上下文更适合承载决策信息，而不是当作数据存放层。文件、数据库、对象存储这些外部介质，天然支持分页、寻址和重复访问，更适合用来承接中间状态。

## SKILL 为什么会冒出来

也正是在这样的背景下，SKILL 开始受到关注。

如果 SKILL 只是纯文本，它更像分层 prompt 的组织方式；但当它和命令行工具、脚本结合起来，它就不只是“提示词技巧”，而是一种场景化的工作流封装：同一类任务的步骤、产物、工具链、失败重试方式、输出格式，都被聚合在一起。

普通用户可能搞不清 MCP 是干啥的，但他能理解“这个技能帮我把评论整理出来并逐条修复”。

从实现上看，这有点像“以前用胶水代码粘合工具”，现在用“自然语言 + LLM + Bash / 脚本”来粘合工具。并且这种范式正在让 Prompt Engineering 转向 Skill Engineering。

## MCP 和 SKILL 的分工

我并不觉得有了 SKILL，MCP 就没意义了。恰恰相反，我更倾向于一种分工：

- MCP 解决连接标准化
- SKILL 解决工作流编排与状态外部化

前者让能力能规模化接入，后者让任务能稳定闭环。

MCP 不一定要“由 Agent 直接调用并回填上下文”，它完全可以被 SKILL 里的脚本调用，让结果先落地为可寻址对象，再把摘要与索引回填给模型。这样上下文就回到它最擅长的位置：做决策、做推理、做取舍，而不是当缓存。

MCP、SKILL 仍处在早期阶段，只是 Agent 插件机制演化中的不同形态。当 Agent 开始承担复杂任务时，真正重要的已不再是能力本身，而是上下文、状态与执行边界如何被拆分和安放。