*—— 当90%的人都在追MCP时，有人选择了另一条路*
---
MCP（Model Context Protocol）火遍全网。
Anthropic开源、Cursor/Claude官方支持、社区Server爆发式增长...看起来，MCP就是AI工具调用的"标准答案"。
但今天，我想说一句可能得罪人的话：
90%的人踩坑了。
不是MCP不好，而是很多人用错了场景。
---
一、MCP的"坑"在哪里？
坑1：架构复杂度
为了让Agent调一个工具，你需要：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Agent │────▶│ MCP Client │────▶│ MCP Server │
│ (LLM) │ │ (stdio/SSE)│ │ (工具实现) │
└─────────────┘ └─────────────┘ └─────────────┘
│
▼
┌─────────────┐
│ Schema │
│ (JSON定义) │
└─────────────┘
问题：
- 会话管理复杂（生命周期、错误处理、超时）
- 调试困难（调不通不知道哪炸了）
- 部署麻烦（每个Server都要独立运行）
坑2：上下文效率灾难
这是那个CI/CD案例的核心痛点。
MCP方案：
- 每个Server的Schema都要塞进prompt
- 几十个Server = 几万token
- 活没干，钱包先空
| 方案 | Token消耗 | 开发时间 |
|---|---|---|
| MCP | 25,000+ | 1-2周 |
| CLI+Skill | 50 | 1天 |
| 效率提升 | 500倍 | 10倍 |
坑3：过度工程化
很多工具根本不需要MCP的复杂度：
- 一个文件读取操作
- 一个简单的API调用
- 一个本地命令执行
值得吗？
---
二、CLI+Markdown：回归本质
2.1 核心思想
工具调用的本质是什么？
> 告诉AI："有一个命令叫xxx，参数是yyy，输出是zzz"
就这么简单。
2.2 具体实现
SKILL.md 示例：
# Git操作工具
## git_status
查看当前仓库状态
**用法：**
**输出格式：**
- `M` = 修改
- `A` = 新增
- `D` = 删除
- `??` = 未跟踪
## git_commit
提交更改
**用法：**
**参数：**
- `message`: 提交信息（简洁描述更改内容）
Agent调用：
用户：看看仓库状态
AI：我来查看一下 → 执行 `git status --short`
用户：提交这些更改
AI：我来提交 → 执行 `git commit -m "更新文档"`
2.3 为什么更高效？
| 维度 | MCP | CLI+Markdown |
|---|---|---|
| Token消耗 | Schema JSON（冗长） | 自然语言描述（精简） |
| 开发时间 | 1-2周 | 几小时 |
| 调试难度 | 高（多层架构） | 低（直接执行） |
| 部署复杂度 | 高（Server管理） | 低（本地命令） |
| 学习成本 | 高（协议+SDK） | 低（写文档） |
三、什么时候用MCP，什么时候用CLI？
用MCP的场景
1. 复杂的多工具生态
- 需要统一管理几十个工具
- 工具之间有依赖关系
- 需要动态发现和能力协商
- 工具在远程服务器
- 需要SSE长连接
- 多Agent共享工具池
- 严格的权限控制
- 审计日志
- 标准化治理
用CLI+Markdown的场景
1. 简单工具调用
- 文件操作、Git、Docker...
- 本地命令执行
- 单次调用，无状态
- 验证想法
- 内部工具
- MVP阶段
- Token预算有限
- 上下文窗口紧张
- 成本控制严格
四、OpenClaw的实践：混合策略
OpenClaw作为Agent运行时，采用了务实的混合策略：
4.1 内置工具：CLI方式
# tools.yaml
- name: read
description: 读取文件内容
command: "cat {{file_path}}"
- name: exec
description: 执行shell命令
command: "{{command}}"
优势：
- 零token开销（内置）
- 即开即用
- 无需额外部署
4.2 外部能力：MCP兼容
# mcp_servers.yaml
- name: filesystem
transport: stdio
command: npx -y @modelcontextprotocol/server-filesystem
args: ["/home/user"]
- name: fetch
transport: stdio
command: uvx mcp-server-fetch
优势：
- 复用社区生态
- 标准化接口
- 跨进程隔离
4.3 Skill系统：最佳实践
skills/
├── git/
│ └── SKILL.md # Git操作文档
├── docker/
│ └── SKILL.md # Docker操作文档
└── deploy/
└── SKILL.md # 部署流程文档
Agent加载Skill：
[[skill:git]]
用户：部署最新版本
AI：
1. git pull origin main
2. docker build -t app:latest .
3. docker-compose up -d
---
五、那个CI/CD案例的深度分析
5.1 为什么MCP方案要25000 token？
典型MCP Server Schema：
{
"name": "deploy",
"description": "部署应用到生产环境",
"parameters": {
"type": "object",
"properties": {
"environment": {
"type": "string",
"enum": ["staging", "production"],
"description": "部署环境"
},
"version": {
"type": "string",
"pattern": "^\\d+\\.\\d+\\.\\d+$",
"description": "版本号，格式x.y.z"
},
"rollback": {
"type": "boolean",
"default": false,
"description": "是否回滚"
}
},
"required": ["environment", "version"]
}
}
几十个这样的Schema = 几万token
5.2 CLI+Skill方案为什么只要50 token？
SKILL.md：
# CI/CD部署
## deploy
部署应用到指定环境
**用法：**
**示例：**
Agent看到的：
[Skill: CI/CD部署]
- deploy: ./deploy.sh <env> <version> [--rollback]
几十行描述 = 50 token
---
六、给开发者的建议
6.1 不要盲从
MCP是趋势，但不是银弹。
问自己：
- 我真的需要动态工具发现吗？
- 我的工具有多复杂？
- Token成本敏感吗？
- 开发时间充裕吗？
6.2 从简单开始
阶段1：CLI+Markdown
- 快速验证想法
- 低成本试错
- 积累领域知识
- 工具稳定后，考虑封装
- 评估是否需要MCP
- 逐步迁移
- 对外开放
- 社区共享
- 标准化协议
6.3 混合策略
像OpenClaw一样：
- 简单工具 → CLI
- 复杂生态 → MCP
- 领域知识 → Skill
七、结语：工具的本质
MCP和CLI+Markdown，不是对立关系。
它们只是不同抽象层级的工具调用方式。
- MCP = 企业级、标准化、生态化
- CLI+Markdown = 轻量级、快速、低成本
不要被"全网都在用"绑架，也不要为了技术而技术。
最简单的方案，往往就是最好的方案。
---
参考
- MCP官方文档：https://modelcontextprotocol.io
- OpenClaw Skill系统：https://docs.openclaw.ai/skills
- Anthropic MCP介绍：https://www.anthropic.com/news/model-context-protocol
*"不要为了用锤子而找钉子，而是为了钉钉子而选工具。"*