MCP吃掉72%上下文：三种AI工具接入方式怎么选

你用Claude Code接了3个MCP Server，还没开始干活，上下文窗口就被吃掉了72%。

这不是夸张。Milvus团队做了实测：一个200K token的模型，接上文件系统、数据库、GitHub三个MCP Server，光是加载工具描述就消耗了超过14万token。Agent还没读你的代码，窗口就快满了。

2026年3月，HackerNoon上一篇文章直接说”MCP Is Dead”，LinkedIn和Medium上跟着一堆讨论。争的就一件事：AI Agent接外部工具，到底该用MCP、CLI还是Skills？

我把三种方式都用过，说说实际体验。

MCP的问题出在哪

MCP的设计思路没毛病：给AI一个标准协议，连什么工具都行。问题在实现上。

第一，上下文窗口被吞。MCP Server启动时要把所有工具的schema（名称、参数、描述）一次性塞进上下文。一个Server有20个工具，每个工具描述200-500 token，一个Server就是4000-10000 token。接3个Server，轻松吃掉3万-5万token。你的200K窗口听着大，实际可用空间直接砍掉一大截。

第二，被动架构。MCP Server只能等Agent来调用，不能主动推送信息。Agent问一次，Server答一次。如果一个任务需要连续调5个工具串起来，每一步都得Agent自己规划。工具之间没法直接传数据，全靠Agent在中间转。

第三，没法复用Agent的大脑。MCP Server是独立进程，跑自己的代码。如果工具需要做判断（比如搜索结果里哪些有用），得在Server里单独配一个模型和API key。Agent的大模型明明就在旁边，但用不上。

CLI方式：Agent直接跑命令

CLI就是让Agent直接在终端跑命令。比如查GitHub issue，Agent不需要通过MCP Server，直接执行：

gh issue list –repo owner/repo –state open –limit 10

不用加载schema，不用维护Server进程，跑完就完。上下文里只有命令本身和返回结果，几十个token就搞定。

实际对比一下token消耗：

• MCP方式查GitHub issue：加载GitHub MCP Server的schema约8000 token + 调用请求约500 token = 8500 token
• CLI方式查GitHub issue：gh命令约30 token + 返回结果约200 token = 230 token

差了37倍。

CLI的另一个好处：几十年的命令行工具直接拿来用。git、docker、kubectl、curl、jq——这些工具经过了无数人的验证，文档到处都有，Agent也天然认识它们。

Skills方式：给Agent装技能包

Skills是一种更新的方案。一个Skill就是一个文件夹，里面放一个SKILL.md说明文件，告诉Agent”你有什么能力、怎么用、调哪个脚本”。Agent按需加载，用到哪个读哪个。

举个例子，一个天气查询Skill的结构：

skills/weather/
├── SKILL.md    # 说明：查天气用wttr.in，参数是城市名
└── scripts/
    └── get_weather.sh   # 实际执行的脚本

Agent不需要在启动时加载所有Skill的描述。只有用户问”今天天气怎么样”的时候，Agent才去读weather这个Skill的说明，然后调脚本。上下文消耗按需计算，不用的Skill零开销。

Skills还有一个MCP做不到的事：Skill里的脚本可以直接调用Agent的大模型来做判断。搜索结果需要筛选？让Agent自己的模型来选，不用额外配API key。

三种方式怎么选

别纠结选哪一个，混着用才对。我自己的配置逻辑：

用MCP的场景：远程API服务，需要OAuth认证的第三方平台（比如飞书、Notion），或者团队共享的工具服务。MCP的标准化协议在多人协作时有优势，大家用同一个Server，配置统一。

用CLI的场景：本地开发环境的日常操作。git、docker、文件操作、包管理——这些工具本来就是命令行的，没必要再套一层MCP。Agent直接跑命令，快，省token。

用Skills的场景：需要多步骤工作流的复杂任务。比如”查热搜→选题→写文章→配图→发布”，这种流程写成一个Skill，Agent读一遍SKILL.md就知道整个流程怎么走。单个CLI命令干不了这事，MCP也不擅长编排。

一个实际配置参考

我目前的Claude Code环境里，三种方式同时在用：

MCP Server（2个，只留必须的）
├── feishu-doc    # 飞书文档读写，需要OAuth
└── xiaohongshu   # 小红书发布，需要cookie管理

CLI工具（日常开发）
├── gh           # GitHub操作
├── git          # 版本管理
├── curl         # API调试
└── jq           # JSON处理

Skills（30+个，按需加载）
├── weather      # 天气查询
├── wechat-public # 公众号发布流程
├── weibo-manager # 微博发帖流程
└── …          # 更多技能包

MCP Server控制在2个以内，schema加载占用大约1.5万token。CLI工具不占启动开销。Skills有30多个但不影响启动速度，用到哪个才加载。

一条原则：如果一个工具有现成的CLI命令，优先用CLI。如果需要OAuth或远程服务，用MCP。如果是多步骤的复杂流程，写成Skill。

MCP没死，但不该什么都用它

说”MCP已死”太绝对了。MCP在远程服务对接、团队协作、标准化这些方面有不可替代的价值。但把所有工具都塞进MCP Server，确实是给自己添堵。

上下文窗口就那么大，省着点用。

如果你的Agent目前只用MCP接工具，建议做一次清理：数一数你接了多少个MCP Server，算一下schema占了多少token，然后看看哪些能换成CLI命令或Skill。我清理完之后，可用上下文空间多出了将近10万token。差别很明显。

每天一篇AI工具实操干货，关注公众号「AI实战派」不迷路