热榜都在吹 MCP Skills 万能，我搭了个 AI Agent 才发现最大的坑不是 Skill

最近打开掘金，满屏都是 MCP Skills

什么"10万人都在用的 top10 skills"，什么"一句话生成整套 API"……说实话，看得我手痒。

我是个独立开发者，一直想给自己搭一个 AI Agent——不是那种对话机器人，是真正能帮我干活的 Agent：能读文档、能搜网页、能调不同的大模型做不同的事。

上周末终于动手了。踩的坑比想象中多得多，而且最大的坑根本不在 MCP 这层。

先说需求：我想要什么样的 Agent

我的目标很明确：

1. 用 MCP 把工具串起来（读飞书文档、搜索网页、操作数据库）
2. 不同任务用不同模型（代码生成用 Claude，摘要用 GPT-4o-mini 省钱，中文理解用 DeepSeek）
3. 整个 Agent 要能自主决策调哪个模型

看起来很简单对吧？MCP + Skills + 几个 API 就完事了。

哈哈哈哈，太天真了

第一个坑：MCP Skill 写起来没那么丝滑

热榜文章把 MCP Skill 吹得跟写 README 一样简单。实际上……

# 我以为的 Skill
name: doc-reader
description: 读取文档并总结

# 实际的 Skill（省略了一堆配置）
name: doc-reader
description: |
  读取指定 URL 的文档内容，支持 HTML/PDF/Markdown。
  输出结构化摘要，包含：标题、核心内容、关键数据。
  如果文档超过 8000 token，先分块再合并摘要。
tools:
  - web_fetch
  - file_read
input_schema:
  type: object
  properties:
    url:
      type: string
      description: 文档 URL
    format:
      type: string
      enum: [summary, full, key_points]

Skill 本身不难写，但调试是真的烦。MCP 的错误信息很不友好，经常就一个 tool_call_failed，连哪里挂了都不告诉你。

我的建议：先在本地把每个 tool 单独跑通，再组装成 Skill。别上来就写一个大的。

第二个坑（也是最大的坑）：多模型调用的地狱

Agent 跑起来了，Skill 也串好了。然后我发现了真正的问题——

我需要同时调 3 个不同厂商的大模型 API。

• Claude Opus 4.6：写代码、复杂推理 → Anthropic API
• GPT-4o-mini：轻量摘要、分类 → OpenAI API
• DeepSeek V3：中文语义理解 → DeepSeek API

三个厂商，三套 SDK，三种认证方式，三个不同的 rate limit 策略。

# 我最初的代码，看着就头疼
import anthropic
import openai
from openai import OpenAI as DeepSeekClient

# Claude
claude = anthropic.Anthropic(api_key=os.getenv("ANTHROPIC_API_KEY"))

# GPT
gpt = openai.OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

# DeepSeek（用 OpenAI 兼容格式）
ds = DeepSeekClient(
    api_key=os.getenv("DEEPSEEK_API_KEY"),
    base_url="https://api.deepseek.com/v1"
)

def ask_model(task_type, prompt):
    if task_type == "code":
        # Claude 的消息格式和 OpenAI 不一样...
        resp = claude.messages.create(
            model="claude-opus-4-6-20250929",
            messages=[{"role": "user", "content": prompt}],
            max_tokens=4096
        )
        return resp.content[0].text
    elif task_type == "summary":
        resp = gpt.ch@t.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": prompt}]
        )
        return resp.choices[0].message.content
    elif task_type == "chinese":
        resp = ds.ch@t.completions.create(
            model="deepseek-ch@t",
            messages=[{"role": "user", "content": prompt}]
        )
        return resp.choices[0].message.content

这代码能跑，但问题一堆：

1. 三套错误处理：Claude 返回 overloaded_error，OpenAI 返回 RateLimitError，DeepSeek 有时候直接超时。每个都得单独 catch
2. Key 管理噩梦：3 个 API key，3 个账单页面，3 个用量坚控
3. 国内访问：Claude 和 OpenAI 在国内都不太稳定，经常超时。DeepSeek 倒是快，但不是所有任务都适合

我为了搞定网络问题，先后试了：

• 自建代理 → 延迟不稳定，维护麻烦
• 用 Cloudflare Workers 中转 → 有 CPU 时间限制，SSE 流式输出经常断
• 直接买了个香港 VPS → 又多了一个要维护的东西

折腾了两天，Agent 的核心逻辑 1 小时就写完了，80% 的时间都在跟 API 接入较劲。

转折：一个 base_url 解决的问题

后来在 V2EX 看到有人提了一嘴 API 聚合平台的思路，大意是一个 endpoint 搞定所有模型。

研究了一圈，发现现在做这个的还不少。我最后选了一个叫 ofox.ai 的，原因很简单：

1. OpenAI 格式兼容 — 只要改一个 base_url，代码几乎不用动
2. 国内直连，不用番强 — 阿里云/火山云节点，延迟比我自建代理还低
3. 50+ 模型一个 key — Claude、GPT、Gemini、DeepSeek 全有

改完之后的代码：

from openai import OpenAI

# 一个 client 搞定所有模型
client = OpenAI(
    api_key=os.getenv("OFOX_KEY"),
    base_url="https://api.ofox.ai/v1"
)

def ask_model(task_type, prompt):
    model_map = {
        "code": "claude-opus-4-6-20250929",
        "summary": "gpt-4o-mini",
        "chinese": "deepseek-ch@t",
    }

    resp = client.ch@t.completions.create(
        model=model_map[task_type],
        messages=[{"role": "user", "content": prompt}],
        stream=True  # 流式输出也正常
    )

    result = ""
    for chunk in resp:
        if chunk.choices[0].delta.content:
            result += chunk.choices[0].delta.content
    return result

从 30 行变成 15 行，三套 SDK 变成一套，三个 key 变成一个。

延迟实测对比（北京，单位 ms）：

国产模型差距不大，但海外模型的差距是真的明显。不用自己折腾网络这一点就值了。

最终效果：Agent 跑起来了

MCP Skill + 多模型 Agent 的最终架构很简单：

用户输入
  ↓
MCP Router（根据意图选择 Skill）
  ↓
┌─────────────┬──────────────┬─────────────┐
│ doc-reader   │ code-gen     │ data-query  │
│ (GPT-4o-mini)│ (Claude)     │ (DeepSeek)  │
└─────────────┴──────────────┴─────────────┘
  ↓              ↓              ↓
  统一 API 层（一个 endpoint，一个 key）

跑了一周，稳定性还不错。Agent 能根据任务自动选模型，成本也控制住了——轻量任务走便宜模型，重活才上 Claude/GPT。

总结：MCP 不是银弹，API 层才是基建

掘金热榜把 MCP Skills 吹上天了，但实际搭 Agent 你会发现：

1. MCP Skill 本身不难，难的是调试和组合
2. 多模型调用才是真正的基建问题 — 如果你的 Agent 只调一个模型，那随便搞。但凡要用 2 个以上，API 管理就变成大坑
3. 别自己造网络轮子 — 自建代理、VPS 中转这些路我都走过，ROI 太低。能花钱解决的问题就别花时间

给同样在搞 AI Agent 开发的朋友一个建议：先把 API 层搞定，再去折腾 MCP 和 Skill。地基不稳，上层建筑盖得再花哨也白搭。

如果你也在搞 Agent 或者 MCP 相关的东西，评论区聊聊你踩过什么坑？