MCP + Skills 实战：从搭一个 MCP Server 到让 AI Agent 真正干活

Posted on In

MCP 解决了一个根本问题：Agent 如何连接真实世界的数据和系统。没有这个连接，Agent 就只是一个沙盒里的玩具。

最近 Anthropic 发布了工程博客《Code execution with MCP: Building more efficient agents》（2025-11-04），系统阐述了 MCP 协议如何让 Agent 更高效地接入生产系统。网上已有不少解读文章，但大多是”官方说了什么”的搬运。

这篇文章不一样。我用一个真实的公司内部运维诊断系统作为案例，手把手展示 MCP 和 Skills 怎么配合——将官方思路落地到我们的实践中，看看每一步到底对不对。

一、MCP 30 秒理解

先解决一个基本问题：MCP 到底是什么？

一句话：MCP 是一个标准协议，让任何 AI Agent 都能用同一套接口连接任何外部系统。

一张图：

mcp

根据 Anthropic 官方博客和 MCP 协议的设计意图，Agent 连接外部系统有三条路径：

路径 特点 适用场景
直接 API 调用 最简单，但每个 Agent × 每个系统 = 独立集成 1:1 简单场景
CLI 命令行 轻量快速，但无法穿透到移动端和云端 本地调试
MCP 标准化协议，一次实现处处可用 生产环境，规模化

我们的实践验证：在公司内部，我们选择了 MCP 路径来构建运维诊断系统——Agent 通过 MCP 协议连接监控数据平台，而不是为每个 Agent 写一套独立的 API 集成代码。

二、动手：搭一个 MCP Server

理解了 MCP 是什么，接下来动手。以我们内部的运维诊断 MCP Server 为例。

2.1 一行命令安装

在 Claude Code 中，安装一个远程 MCP Server 只需要一行命令：

1
claude mcp add --transport http ai-ops-mcp https://内部域名/ai-ops/streamablehttp

关键参数说明：

  • --transport http：使用 HTTP 传输协议（远程服务器必须用 HTTP 或 SSE，不能用 stdio）
  • --header "apikey:xxxx"：自定义请求头，用于内部网关鉴权

2.2 连通性验证

安装后，Claude Code 自动检测 MCP 工具。在对话中直接问 Claude：

1
"帮我看看有哪些 ai-ops 相关的工具"

Claude 会列出所有 mcp__ai-ops-mcp__ 开头的工具：

1
2
3
4
5
6
7
8
9
10
11
12
13
mcp__ai-ops-mcp__getAppCpuUsageLastHour   → Pod 级别 CPU 使用率
mcp__ai-ops-mcp__getAppQps                 → 按接口/Pod 请求率
mcp__ai-ops-mcp__getAppResponseTime        → 按接口平均响应时间
mcp__ai-ops-mcp__getAppDruidActiveCount    → 活跃数据库连接数
mcp__ai-ops-mcp__getAppDruidPoolingCount   → 连接池大小
mcp__ai-ops-mcp__getAppJvmGcCms            → CMS GC 耗时/次数
mcp__ai-ops-mcp__getAppJvmGcG1Old          → G1 Old GC 耗时/次数
mcp__ai-ops-mcp__getAppJvmGcG1Young        → G1 Young GC 耗时/次数
mcp__ai-ops-mcp__getAppJvmGcParNew         → ParNew GC 耗时/次数
mcp__ai-ops-mcp__getAppJvmThreadCount      → 线程数变化量
mcp__ai-ops-mcp__getAppElasticJobFail      → 定时任务失败数
mcp__ai-ops-mcp__getAppElasticJobSuccess   → 定时任务成功数
mcp__ai-ops-mcp__getAppErrorLog            → 最近 100 条错误日志

13 个工具，覆盖了运维诊断的全部核心指标。

2.3 对照官方：远程优先

官方核心思路：构建远程 MCP Server，让 Agent 通过标准化协议连接，而非直连每个系统的 API。

我们的实践完全吻合：ai-ops-mcp 就是纯远程服务器，使用 HTTP Streamable HTTP 传输协议，部署在内网网关上。所有 Agent（Claude Code、QoderCLI 等）通过 HTTP 连接，不需要本地安装任何额外依赖。

验证结论：我们的 MCP Server 是远程部署的，与官方核心思路一致。

三、动手：让 Agent 真正干活

装好 MCP Server 后，Agent 已经能拿到数据了。但问题来了——

3.1 有数据≠会诊断

试试直接让 Claude 诊断一个问题：

1
"帮我诊断 trade 应用，最近响应很慢"

没有 Skill 的情况下，Claude 会怎么做？

  1. 先调用 getAppQps 看请求量
  2. 再调用 getAppResponseTime 看响应时间
  3. 再调用 getAppCpuUsageLastHour 看 CPU
  4. 再调用 getAppDruidActiveCount 看连接池
  5. 再调用 getAppDruidPoolingCount 看池大小
  6. … 还要调 GC、线程、日志？

Agent 有数据，但它不知道什么时候该看什么指标、怎么看、怎么关联分析、什么值算正常什么值算异常。就像一个新手医生——有血压计、心电图、血检报告，但不知道该先测什么、哪些指标相关、什么数值意味着什么。

3.2 引入 Skill：给 Agent 一套 SOP

我们开发了 ai-ops-troubleshoot Skill，它提供了一套完整的诊断流程知识：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
┌─────────────────────────────────────────────────────────────┐
│                     Claude Code                              │
│                                                              │
│  ┌───────────────────────────────────────────────────────┐  │
│  │         ai-ops-troubleshoot Skill (知识层)            │  │
│  │  • 症状识别："慢"→性能问题，"CPU高"→CPU问题            │  │
│  │  • 工具选择：性能问题→并行调 QPS+响应时间+CPU           │  │
│  │  • 阈值判定：CPU>85%严重，响应时间>500ms严重            │  │
│  │  • 跨维度关联：CPU高→检查GC，响应慢→检查DB连接          │  │
│  │  • 报告生成：概要+异常指标+根因+建议                    │  │
│  └───────────────────────────────────────────────────────┘  │
│                         │                                    │
│                    MCP Protocol                              │
│                         │                                    │
│  ┌───────────────────────────────────────────────────────┐  │
│  │          ai-ops-mcp Server (能力层)                    │  │
│  │  • getAppCpuUsageLastHour → CPU 数据                  │  │
│  │  • getAppQps → QPS 数据                               │  │
│  │  • getAppResponseTime → 响应时间数据                   │  │
│  │  • getAppJvmGc* → GC 数据                              │  │
│  │  • getAppDruid* → 连接池数据                           │  │
│  │  • getAppErrorLog → 错误日志                           │  │
│  └───────────────────────────────────────────────────────┘  │
│                         │                                    │
│                    HTTP Transport                            │
│                         │                                    │
│  ┌───────────────────────────────────────────────────────┐  │
│  │              监控数据源                                 │  │
│  │  Prometheus / Druid / ElasticJob / Redis               │  │
│  └───────────────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────────────┘

现在再试一次：

1
"帮我诊断 trade 应用，最近响应很慢"

有了 Skill 后，Claude 的行为变了：

  1. 症状识别：”响应很慢” → 性能问题类别
  2. 精准调用：并行调用 getAppQps + getAppResponseTime + getAppCpuUsageLastHour（只调 3 个，不再盲调 13 个）
  3. 阈值判定：响应时间 > 500ms → 严重，CPU 70-85% → 警告
  4. 跨维度关联：发现 CPU 高 → 自动调用 GC 工具检查是否 GC 导致
  5. 生成报告：概要 + 异常指标 + 根因分析 + 建议措施

这就是 Anthropic 说的：MCP 给 Agent「能力」，Skills 给 Agent「知识」。

只有 MCP MCP + Skills
类比 有血压计但不会诊断的新手 有血压计且有诊断 SOP 的医生
行为 盲调所有工具，逐一猜测 精准调用，阈值判定，关联分析
结果 可能找到答案，但效率低 快速定位根因，结构化输出

四、MCP + Skills 最佳实践

通过这次实战，我们提炼出 MCP 和 Skills 配合的几条最佳实践。

实践一：远程部署，从一开始就做对的决策

很多人用 stdio 传输跑本地 MCP Server，开发调试很方便：

1
claude mcp add my-server node ./my-server.js

但一旦 Agent 跑在云端（Claude Managed Agents、Claude Cowork），本地 MCP Server 就完全不可用。正确的做法是从第一天就构建远程 MCP Server。

我们的 ai-ops-mcp 就是纯远程部署——HTTP Streamable HTTP 传输协议，部署在内部网关上。所有 Agent（Claude Code、QoderCLI）通过一行 claude mcp add 连接，无需本地安装任何依赖。

为什么远程优先？ 因为生产环境的 Agent 跑在云端，你的服务器也必须能跑在云端。只有远程服务器才能覆盖 Web、移动端和云端 Agent 的所有场景。本地服务器只能给本地开发环境用，无法触达真正的生产用户。

实践二：MCP 做原子能力，Skill 做意图编排

很多人在构建 MCP Server 时会犯一个错误：围绕 API 端点一对一翻译工具。结果是 Agent 要调几十次才能完成一个任务，每次都要从上下文里重新理解”现在在哪一步”。

更好的做法是分两层思考：

  • MCP 层：围绕「指标意图」设计原子工具——getAppCpuUsageLastHour 获取一类指标数据，而非直译 Prometheus 的查询 API
  • Skill 层：围绕「业务意图」编排组合——用户说”诊断响应慢”，Skill 知道该并行调用 QPS + 响应时间 + CPU，而非让 Agent 自行猜测

以我们的运维诊断系统为例：

1
2
3
4
5
6
7
用户意图："诊断响应慢"
    ↓ Skill 编排（知识层）
    → 并行调用 3 个 MCP 工具：getAppQps + getAppResponseTime + getAppCpuUsageLastHour
    ↓ MCP 执行（能力层）
    → 返回各指标原始数据
    ↓ Skill 分析（知识层）
    → 阈值判定 + 跨维度关联 + 报告生成

如果把”诊断响应慢”做成一个 MCP 工具 diagnoseSlowResponse，也能解决问题，但会失去灵活性——当诊断逻辑变化时，需要重新发布 MCP Server。而 Skill 只是一个 Markdown 文件，修改后即时生效。

最佳实践：MCP 提供原子能力（稳定、可复用），Skill 承担意图编排（灵活、易迭代）。两者配合覆盖从原子到意图的完整链路。

实践三：大面积 API 用「代码编排」模式

如果你的 MCP Server 要对接一个拥有几千个端点的超级平台（AWS、Cloudflare、Kubernetes），光工具定义本身就会吃掉大量上下文 Token，Agent 的推理能力会被严重稀释。

最佳做法：只暴露两个薄工具：

1
2
1. search（搜索）→ 让 Agent 发现它需要的操作
2. execute（执行）→ 让 Agent 写一个短脚本，你的服务器在沙盒里运行

Cloudflare 的 MCP 服务器就是标杆案例：通过 code execution 模式，**2 个工具覆盖大量 API 端点，工具定义的 Token 消耗从约 150,000 降至约 2,000，节省 98.7%**（Anthropic 官方工程博客数据）。极简的表面，强大的内核。

我们的运维监控 API 只有 13 个端点，暂时不需要代码编排模式。但这个设计思路值得记住——如果未来监控平台扩展到几百个端点，暴露 searchMetrics + executeQuery 两个工具就能覆盖全部能力。

实践四：认证标准化，让云端 Agent 能持握令牌

当 MCP Server 需要连接有 OAuth 认证的外部系统时，一个核心问题是：云端运行的 Agent 怎么持有和复用用户的认证令牌？

传统痛点：

  • Agent 每次连接都要重新授权 → 用户体验差
  • OAuth 令牌存储在本地 → 云端 Agent 无法复用
  • 令牌过期后需要手动刷新 → 维护成本高

标准方案（MCP 规范方向）：

  1. CIMD（Client ID Metadata Documents）：MCP 规范正在推进的快速首次认证流程，用户体验更顺滑，避免反复弹窗
  2. Vaults（令牌保险库）：Claude Managed Agents 的能力——注册一次 OAuth 令牌，运行时自动注入到每个 MCP 连接，并自动刷新

我们的内部场景暂未涉及 OAuth，用 --header "noSign:true" 的网关鉴权方式简化了认证。但接入外部系统时，CIMD + Vaults 是标准路径——你不需要自己搭密钥存储系统。

实践五：返回丰富语义，而非纯文本

MCP 社区正在推进一个协议扩展方向——让工具返回可交互界面而非纯文本：

  • 返回一个图表而不是一串数字
  • 返回一个表单让用户填写而不是让 Agent 猜参数
  • 返回一个内嵌仪表盘而不是一行状态文字

直观来看，当用户能看到清晰的可视化结果时，他们更信任这个工具，也更愿意继续用它。这是 MCP 协议演进的自然方向——从”返回数据”到”返回体验”。

我们的 ai-ops-mcp 目前返回 JSON 格式的指标数据，纯文本呈现。这是下一步的改进方向——诊断报告可以返回可视化仪表盘而非纯文字。

最佳实践总结

# 最佳实践 说明
1 远程部署优先 从第一天就构建远程 MCP Server，不要走 stdio 本地捷径
2 MCP 做原子能力，Skill 做意图编排 MCP 提供稳定可复用的原子工具，Skill 提供灵活易迭代的编排逻辑
3 大面积 API 用代码编排 只暴露 search + execute，极简表面覆盖全部能力
4 认证标准化 内部场景可简化鉴权，外部系统走 CIMD + Vaults
5 返回丰富语义 让工具返回可交互界面而非纯文本，从”返回数据”到”返回体验”

五、踩坑实战：Token 消耗与客户端优化

5.1 问题：13 个工具定义吃掉多少 Token？

当 MCP Server 提供了 13 个工具时，Claude Code 在初始化时会把所有工具定义加载到上下文中。每个工具定义包含工具名、参数说明、返回值描述——13 个工具的定义本身就占了不少 Token。

如果做全面健康检查（并行调用 13 个工具），加上每次调用的参数和返回结果，一次完整诊断的 Token 消耗量可能达到数万级别。

5.2 Anthropic 的优化方案

官方工程博客给出了一个核心优化方向：Code execution with MCP。

核心思路：Tool Search — 按需加载

不预先加载所有工具定义，而是运行时动态搜索工具目录，只在需要时拉入上下文。Anthropic 给出了数据：将工具作为代码文件组织在文件系统中，Agent 通过浏览目录发现需要的工具，工具定义的 Token 消耗从 **150,000 降至 2,000，节省 98.7%**。

延伸思路：Programmatic Tool Calling — 代码沙盒处理结果

把工具调用结果交给代码执行沙盒处理（循环、过滤、聚合），只把最终总结传入上下文，而非把每个原始结果都塞进对话。例如获取 10,000 行数据后，在沙盒中过滤为 5 行再返回给模型——Agent 只看 5 行而非 10,000 行。

5.3 我们的实践：Skill 就是天然的”Tool Search”

回看我们的 ai-ops-troubleshoot Skill，它的诊断流程天然实现了”按需加载”的逻辑：

  • 用户说”响应慢” → Skill 只选择 QPS + 响应时间 + CPU 三个工具
  • 用户说”CPU 高” → Skill 只选择 CPU + 线程 + GC 工具
  • 用户说”定时任务失败” → Skill 只选择 ElasticJob 工具

不是盲调 13 个工具，而是根据症状精准选择 3-6 个。这和官方 Tool Search 的理念一致——只在需要时才加载和使用相关工具。

验证结论：Skill 的症状→工具选择映射，自然实现了 Tool Search 的理念。

六、MCP 是「会复利」的层

前面讲的都是技术和实操。最后想分享一个更深层的认知。

MCP 是一个「会复利」的层。什么叫”复利”？今天你写了一个远程 MCP Server，它可以被所有兼容客户端在任何部署环境下使用——认证、交互性和丰富语义都由协议本身处理。随着更多客户端采用规范、更多扩展进入协议，同一个服务器不需要你重新发布任何东西，就能变得越来越强。

你写的每一个 MCP Server，都在为整个生态系统贡献力量。边缘情况变少了，定制化集成变少了，整个行业的基础设施变强了。这是一种典型的网络效应——用得越多，价值越大。

在我们的实践中也感受到了这一点：ai-ops-mcp 最初只为 Claude Code 设计，但 MCP 协议的标准化让它天然兼容 QoderCLI 和未来的更多 Agent 平台——一次构建，多处受益。

七、行动清单

根据这次实战经验，给不同阶段的读者一个清晰的下一步建议：

给刚接触 MCP 的读者

  1. 先理解核心：MCP 不是又一个 API 协议，它是消除 Agent×系统 M×N 问题的标准化层
  2. 一行命令开始：用 claude mcp add 安装一个远程 MCP Server，感受连通性
  3. 验证连通：让 Claude 列出已安装的 MCP 工具，确认数据可达

给正在构建 MCP Server 的开发者

  1. 远程优先：从第一天就构建远程 MCP Server，不要走 stdio 本地捷径
  2. MCP 做原子，Skill 做编排：MCP 提供稳定可复用的原子工具，Skill 提供灵活易迭代的编排逻辑
  3. 大面积 API 用代码编排：只暴露 search + execute，极简表面覆盖全部能力

给想让 Agent 真正干活的实践者

  1. MCP + Skills 组合：MCP 给能力，Skills 给知识。只装 MCP 不够——Agent 需要一套 SOP 才能高效使用工具
  2. Token 优化：Skill 的精准工具选择天然实现 Tool Search 理念，减少无谓调用
  3. 认证标准化：内部场景可简化鉴权，外部系统走 CIMD + Vaults

给想深入 MCP 生态的建设者

  1. 丰富语义返回：返回图表和表单而非纯文本，从”返回数据”到”返回体验”
  2. Skill 从 MCP Server 分发：社区正在推进标准扩展，让 Skills 和 MCP Server 版本同步
  3. 你的每个 MCP Server 都在贡献复利：网络效应——用得越多，价值越大

本文参考 Anthropic 官方工程博客：Code execution with MCP: Building more efficient agents

中文解读参考：Anthropic官方指南：用MCP协议构建能接入生产系统的AI Agent