22,000 个 Token 的沉重代价：我为何放弃 MCP 服务转向脚本集成

在最近的一次公司研讨会上，我与一群刚刚开始接触大语言模型（LLM）的开发者发生了一场激烈的争论。他们的核心关注点是成本：他们每周在 API 调用上花费约 25 欧元，并希望通过优化提示词将其降至 20 欧元。我的回答非常直接：“你们正处于学习阶段。应该多花钱，而不是少花钱。去尝试、去破坏、去创造支出。从 50 欧元的账单中获得的洞察力，其价值远超你省下的那 5 欧元。”

然而，我紧接着提出了一个关键的警告。在一种特定情况下，Token 的消耗至关重要，但这与你的银行余额无关，而与 上下文保留（Context Preservation） 有关。当你通过 n1n.ai 使用高性能模型时，你在会话开始时发送的每一个 Token，都是对后续所有响应质量的一种“征税”。这就是我要分享的故事：我如何发现自己仅仅为了启动 AI 智能体就支付了 22,000 个 Token 的税，以及我最终为何停掉 MCP 服务以夺回这些上下文空间。

隐形杀手：上下文腐烂（Context Rot）

研究和实践经验都证实了一个被称为“上下文腐烂”或“迷失在中间（Lost in the Middle）”的现象。随着 LLM 上下文窗口的填满，它对所提供信息进行有效推理的能力会下降。即使是像 Claude 3.5 Sonnet 或 GPT-4o 这样拥有巨大上下文窗口的模型，信息的密度依然至关重要。如果你在窗口的前 20% 填充了大量无用的元数据，模型的“注意力”就会被分散。

在 Claude Code 等工具的早期阶段，当达到限制时，会话会直接报错崩溃。现在，我们有了自动压缩（Auto-compaction）功能，它会总结之前的对话内容以腾出空间。但自动压缩是一个有损的过程。你永远无法确定哪些关键信息在压缩中幸存了下来。因此，启动时加载的每一个不必要的 Token，都是对会话长期智能的直接威胁。

22,000 个 Token 的审计报告

一天晚上，我决定审计一下自己的开发环境。当时我运行了三个模型上下文协议（MCP）服务器：

1. mcp-atlassian：用于 Jira 和 Confluence 集成。
2. chrome-devtools：用于浏览器自动化。
3. context7：用于本地文档查找。

我开启了一个新会话并运行了 /context 命令。结果令人震惊：在我输入任何提示词之前，系统已经消耗了 22,000 个 Token。

最大的罪魁祸首是 Atlassian MCP 服务器。它注册了 33 个不同的工具，而我实际上只使用了其中的 6 个。我曾尝试在 Claude Code 的配置中使用 disabledTools 来精简，但审计揭示了一个令人沮丧的事实：disabledTools 仅仅是一个运行时过滤器。

当你在配置中禁用一个工具时，AI 只是被告知不要去 调用 它，但 MCP 服务器依然会启动，Docker 容器依然会运行，最重要的是——这些工具的定义和 Schema 依然会被注入到上下文窗口中。每个工具的 Schema 可能会占用 300 到 500 个 Token 的元数据。乘以 33 倍，你就在那些明确表示不想使用的工具上浪费了超过 10,000 个 Token。在使用 n1n.ai 提供的 API 服务时，这种浪费不仅影响性能，也变相降低了有效信息的承载量。

解决方案：向 Shell 脚本“毕业”

我意识到 MCP 正在抽象化一些其实并不复杂的逻辑。大多数现代企业工具（如 Jira）都有非常成熟的 REST API。如果你已经在使用 n1n.ai 接入稳定的 LLM 终端，你并不需要一个笨重的中台协议来与 Web 服务通信。

我决定用一组轻量级的 Shell 脚本替换整个 Atlassian MCP 服务器。模式非常简单：凭据存储在安全的 JSON 文件中，使用 curl 进行请求，使用 jq 进行解析。

第一步：安全的凭据管理

与其将环境变量放在 Docker 容器中，我选择使用本地配置文件：

# ~/.config/jira/credentials.json
{
  "personal_token": "你的_API_TOKEN",
  "base_url": "https://your-company.atlassian.net"
}

通过 chmod 600 ~/.config/jira/credentials.json 命令确保该文件仅对当前用户可见。

第二步：逻辑脚本实现

这是一个用于获取 Jira Issue 的简化版脚本。它取代了原本需要 300 个 Token 的 MCP Schema，且在未调用时开销为 0。

#!/bin/bash
# jira-get-issue.sh

TOKEN=$(jq -r '.personal_token' ~/.config/jira/credentials.json)
BASE_URL=$(jq -r '.base_url' ~/.config/jira/credentials.json)
ISSUE_ID=$1

if [ -z "$ISSUE_ID" ]; then
  echo "用法: jira-get-issue <任务编号>"
  exit 1
fi

curl -s -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     "$BASE_URL/rest/api/2/issue/$ISSUE_ID"

为什么脚本优于 MCP？

1. 零启动成本：MCP 工具必须在每个会话开始时向 LLM 描述自己，而 Shell 脚本（或称为 Skills）仅在需要时才被调用。这瞬间节省了 10,000 多个 Token。
2. 高度自定义：我可以将特定于项目的默认参数直接写入脚本。例如，我可以强制每个新工单都包含特定的“团队”标签或“组件”，而无需每次都向 AI 解释这些规则。
3. 更高的可靠性：我发现通过 MCP 创建 Jira 工单经常因为复杂的自定义字段而失败。通过直接的 curl POST 请求，我可以完全按照 Jira 的要求构造 JSON，成功率达到了 100%。

以下是一个“一键成功”的工单创建脚本示例：

curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "fields": {
      "project": {"key": "PROJ"},
      "issuetype": {"name": "Task"},
      "summary": "'"$1"'",
      "components": [{"name": "API"}]
    }
  }' "$BASE_URL/rest/api/2/issue"

核心对比表

何时该选择哪种方案？

MCP 是一个非常出色的“入门级”工具。如果你正在进行探索性实验，想要快速查看可能性，它的低门槛是非常有吸引力的。然而，一旦你进入专业的生产流程——尤其是当你使用来自 n1n.ai 的高速、高可靠性 API 时——你最终会撞上“抽象之墙”。

当你的智能体正在执行需要消耗 10 万以上 Token 的多步工作流时，你无法承受将 10% 的上下文浪费在从未使用的工具定义上。向 Shell 脚本“毕业”不仅仅是一种优化，更是保持 AI 会话在长时间跨度内维持“智力”的必然选择。

总结：工程化思维胜过过度抽象

从 MCP 回退到 Shell 脚本最初看起来像是倒退，但实际上是向工程成熟度迈进了一步。通过移除中间层，我获得了更高的可见性，节省了资源，并显著提升了 LLM 的表现。

如果你发现你的 AI 智能体在会话后期变得健忘或开始犯错，请检查一下你的“Token 税”。你可能会发现，你正在为许多从未真正使用过的“工具”支付高昂的代价。

立即在 n1n.ai 获取免费 API 密钥。