> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 技能+CLI：比MCP便宜20倍
- URL: https://www.hubwiz.com/blog/skills-plus-cli-20x-cheaper-than-mcp/
- Published: 2026-03-18T03:47:04.000Z
- Updated: 2026-03-18T03:47:04.000Z
- Description: MCP服务器注入10000-55000个工具模式令牌，但CLI工具为相同能力只需200-500令牌。
- Author: admin
- Tags: AGENT, #Import 2026-10-14 14:41

GitHub官方Copilot MCP服务器暴露了43个工具。

连接它会在你的Agent读取任何代码行之前向你的上下文窗口注入约**55000个令牌**。

模型**在开始思考之前就开始付费了**。

按Claude Sonnet 4定价（每百万输入令牌3美元），每个会话仅工具定义就要0.16美元。每天运行10000个自动化会话，你每天在管道上烧掉**1600美元**。

CLI工具为相同能力只需200-500令牌，而技能在此基础上添加渐进式披露：静止时30-50令牌，仅在触发时加载完整指令。

此外，**CLI比MCP便宜10-32倍，具有100%可靠性，而且技能提高Agent通过率**。

这真的是关于**物理学**，不仅仅是其他任何东西。

本指南是关于**为什么技能+CLI架构比MCP密集设置产生更好Agent输出的技术分析**，基于令牌经济学、注意力研究和真实基准。

我将带你了解**证据**，向你展示**代码**，让你自己决定。

如果你在生产中构建Agent，这将**为你省钱**。如果你在评估Agent编码工具，这将**磨练你的框架**。如果你在设计Agent架构，这可能会**完全改变你对工具界面的看法**。

## 1、gh --help vs. MCP规范

以下是相同能力在实践中的样子：

```
# CLI方法：约200令牌
$ gh issue create --help
在GitHub上创建问题。

用法：
gh issue create [flags]

标志：
-a, --assignee login 通过登录名分配人员
-b, --body string 提供正文
-l, --label name 按名称添加标签
-t, --title string 提供标题
...

```

Agent从训练数据中已经知道`gh`。

它一次性组合命令。

总交互成本：不到500令牌。

比较MCP等价物：服务器通常发送`create_issue`的完整JSON模式加上42个Agent永远不会接触的其他工具。

### 1.1 MCP税是真实的

Scalekit最近运行了75个基准测试，在相同模型（Claude Sonnet 4）上对CLI、CLI+技能和MCP与相同任务进行比较。

数字：

对于最简单的任务"这个仓库是什么语言？"，这是**32倍令牌差异**。

MCP Agent携带webhook管理、gist创建和PR审查配置的模式。

它使用了一个工具。

而且它28%的时间失败了。

每次失败都是到GitHub远程MCP服务器的TCP超时。

CLI在本地运行。没有什么会超时。

### 1.2 这不仅仅是关于钱

Anthropic自己的工程团队也记录了直接MCP工具调用如何强制中间结果通过模型上下文：

> "每个中间结果必须通过模型。在这个例子中，完整调用记录流经两次。对于2小时的销售会议，这意味着可能处理额外的50000令牌。"

他们展示了通过从直接MCP工具调用切换到Agent通过文件系统按需发现工具的代码执行方法，从**150000令牌减少到2000令牌**，节省98.7%。

令牌成本也是认知的。

你在模式定义上浪费的每个令牌都是Agent不能用于推理的令牌。

### 1.3 上下文退化：模型随着上下文填满变笨

Chroma Research的"上下文腐坏"研究测试了18个最先进模型，发现：

- **性能随着输入长度增加而持续下降**，跨所有模型，即使对简单任务也是如此
- 当针问题相似性降低时（更现实的场景），**退化加速**
- 模型在**随机打乱的文本**上比逻辑排序的内容表现更好，这是一个结构悖论，表明注意力机制不像你预期的那样运作
- **Claude在不确定时弃权；GPT自信地幻觉**——不同的失败模式，相同根本原因

斯坦福"中间迷失"论文已经确立了基础发现：性能遵循**U形曲线**。

模型在上下文开头和结尾很好地回忆信息，但中间位置的信息准确率可能下降**超过30%**。

Anthropic的上下文工程指南在这里引入了有用的框架：

> "就像人类有有限的工作记忆容量一样，LLM在解析大量上下文时有'注意力预算'。每引入一个新令牌都会消耗这个预算。"

Transformers为n个令牌创建n²成对关系。随着上下文增长，模型捕获这些关系的能力变得薄弱。

模型从训练数据中发展出注意力模式，其中较短的序列更常见，意味着它们对长距离依赖有更少的专门参数。

这是一个架构属性。

位置编码插值允许处理更长序列，但对令牌位置理解的退化。

U形注意力曲线，在开头和结尾强，在中间弱，持续存在。

这意味着你的MCP工具模式落在上下文中间。这是Agent可能需要引用的信息的*最差位置*。

### 1.4 这对实践中的Agent意味着什么

长时间上下文中的Agent陷入**循环**，重复相同的无效动作直到达到步骤限制。

它们忘记 earlier 建立的约束，它们错误地表示 earlier 有效但已改变的状态。

现在将其连接到MCP。

典型的MCP密集设置在单条消息之前消耗51%上下文：

你从50码线开始每场对话，当你添加代码文件、对话历史和工具输出时，你深入退化区域。

### 1.5 二次陷阱

多轮Agent循环使这变得更糟。

Stevens Institute研究还记录了令牌成本如何二次增长：

> "运行10个周期的Reflexion循环可能消耗单次线性传递50倍的令牌。研究表明，不受约束的Agent每个任务可能花费5到8美元。"

每轮携带完整历史。

MCP模式烘焙到每轮中，你正在复合浪费。

## 2、技能架构：Agent的渐进式披露

技能是三级渐进式披露系统。

该模式在Anthropic的Agent技能规范中正式化，随后被Claude Code、OpenAI Codex、Cursor和Gemini CLI采用。

核心想法：**不要一开始就告诉Agent一切。给它一个目录，让它加载它需要的。**

```
# 三层架构
第一层：元数据（始终加载）
→ 技能名称+单行描述
→ 每个技能成本：约10-30令牌
→ Agent知道什么存在

第二层：完整SKILL.md（按需加载）
→ 完整指令、工作流程、约束
→ 每个技能成本：约200-2000令牌
→ Agent知道如何做

第三层：参考文档（需要时加载）
→ API规格、深度文档
→ 每个技能成本：约2000-20000令牌
→ Agent处理边缘情况

```

使用200k上下文窗口，立即加载所有技能占用约10%。技能通常使用<1%。

### 2.1 技能与工具的区别

有一个根本区别：

技能不替换工具，但它们**教Agent何时以及如何使用工具**。

Jira MCP服务器暴露函数，但Jira技能说："我在金融部门，我的项目空间是FIN-，默认以高优先级创建工单。

### 2.2 为什么2-3个技能是最佳点

SkillsBench，第一个技能增强的严格基准测试，在Claude Code、Gemini CLI和Codex CLI上测试了7308个轨迹。一个跳出的发现：

更多技能并不意味着更好的性能，最佳设计是**每任务2-3个专注技能**。

技能复杂度也很重要。**详细**技能（+18.9pp）优于**综合**技能（-2.9pp）。

## 3、CLI优先Agent设计：代码示例和模式

**模式1：CLI组合优于MCP编排**

当技能包装CLI工具时，Agent可以**组合**，链接Unix管道，就像从数百万训练示例中学到的那样：

```
# Agent组合的CLI管道：查找失败的部署
aws cloudwatch get-metric-data \
--metric-name FailedDeployments \
--start-time 2026-03-11T00:00:00Z \
--end-time 2026-03-12T00:00:00Z \
--output json | \
jq '.MetricDataResults[] | select(.Values[] > 0)' | \
sort -k2 -rn | head -20

```

当技能包装MCP工具时，它必须是**规定性的**。

Agent不能即兴MCP工具链，因为其训练数据中没有可组合性语法。

每个操作都变成顺序的往返。

**模式2：800令牌技能文件**

800令牌技能文件，仅是一个`gh`技巧文档，与naive CLI相比，可以减少三分之一的工具调用和三分之一的延迟：

```
# github-skill.md（约800令牌）
## 仓库操作
- 使用`gh repo view --json name,description,primaryLanguage`获取结构化输出
- 使用`gh api repos/{owner}/{repo}`获取CLI中没有的字段
- 管道到`jq`进行过滤：`gh pr list --json number,title | jq '.[] | select(.title | test("fix"))'`

## PR工作流程
- `gh pr list --state merged --limit 20 --json number,title,mergedAt`
- `gh pr view {number} --json files,additions,deletions`获取差异统计
- 链接：`gh pr list --json number | jq '.[].number' | xargs -I{} gh pr view {} --json title,body`

## 问题模式
- `gh issue list --label bug --state open --json number,title,labels`
- 使用文件创建：`gh issue create --title "Bug" --body-file ./description.md`

## 输出技巧
- 始终使用`--json`标志获取结构化数据
- 使用`jq`过滤，而不是在格式化输出上grep
- `gh api`支持GraphQL：`gh api graphql -f query='{ repository(owner:"org", name:"repo") { ... } }'`

```

Agent已经知道`gh`，技能只是磨练它的本能。

**模式3：代码执行优于工具调用**

Anthropic的代码执行模式将数据处理完全移出上下文窗口：

```
// 而不是MCP工具调用将10k行流经上下文：
// 工具调用：gdrive.getSheet(sheetId: 'abc123') → 上下文中有10,000行

// 代码执行：过滤发生在上下文窗口之外
import * as gdrive from './servers/google-drive';

const allRows = await gdrive.getSheet({ sheetId: 'abc123' });
const pendingOrders = allRows.filter(row =>
  row["Status"] === 'pending'
);
console.log(`Found ${pendingOrders.length} pending orders`);
console.log(pendingOrders.slice(0, 5)); // 只有5行进入上下文

```

Agent编写调用工具的代码，而不是直接调用工具。数据除非Agent明确记录，否则永远不会接触上下文窗口。

**模式4：文件系统作为上下文存储**

```
// 在执行步骤之间持久化状态，无上下文开销
const leads = await salesforce.query({
  query: 'SELECT Id, Email FROM Lead LIMIT 1000'
});
const csvData = leads.map(l => `${l.Id},${l.Email}`).join('\n');
await fs.writeFile('./workspace/leads.csv', csvData);

// 后续执行从中断处继续——零上下文成本
const saved = await fs.readFile('./workspace/leads.csv', 'utf-8');

```

此模式保持上下文窗口干净。文件系统成为Agent的长期记忆。

## 4、决策框架

以下是CLI+技能获胜的情况：

- **开发者工具**，其中Agent作为用户操作
- **Agentic编码**工作流程（调试、重构、部署）
- **高频循环的本地数据处理**
- **成熟的供应商CLI**（AWS、GitHub、GCP、kubectl）
- **大规模Token敏感的生产**（10000+会话/天）

MCP仍然有意义的情况：

- **多租户SaaS**，其中Agent代表客户操作
- **企业认证**，需要每用户OAuth、RBAC和审计追踪
- **没有CLI的服务**（大多数SaaS API）
- **合规要求**，需要对每个Agent操作有结构化、可查询的记录

你也可以采用混合架构，因为生产答案不是CLI**或**MCP。

它是两者之上的技能：

```
┌─────────────────────────────────┐
│ 技能层                           │ ← 静止时30-50令牌
│  (要做什么 + 领域上下文)          │ ← 渐进式披露
├─────────────────────────────────┤
│ CLI传输            │ MCP        │
│  (本地工具、gh、   │ (OAuth、   │ ← 执行层
│  aws、kubectl)     │  SaaS)     │
├─────────────────────────────────┤
│  文件系统/状态                   │ ← 上下文之外的持久化
└─────────────────────────────────┘

```

技能作为智能层坐在顶部。

它们为本地工作路由到CLI，为受管的外部访问路由到MCP。

Agent不知道或不在乎哪个传输处理执行。

---

原文链接: [I deleted all my MCPs: Skills + CLI outperform at \~20x lower cost](https://agentnativedev.medium.com/i-deleted-all-my-mcps-skills-cli-outperform-at-20x-lower-cost-8e86e05fcca6?ref=hubwiz.com)

汇智网翻译整理，务公开明出处