最近这个月我做了一件让同事看来有点“折腾”的事把 Claude 从单纯的聊天窗口里搬了出来接进了我整个开发工作流。现在我在 Claude Code 里可以直接查线上 PostgreSQL、让 MCP 工具去读 Sealos 上的服务状态、一键触发部署或回滚全程不用切出编辑器。让这一切发生的就是 MCP 协议和一组跑在 Sealos 云上的 MCP Server。这篇文章写给两类人一类是已经在用 Claude Code、Claude Desktop但还没有把远程 MCP 真正用起来的人另一类是听说过 MCP 和 Sealos但不清楚这俩组合在一起到底能解决什么问题的人。我会从“为什么折腾”说起再到完整部署步骤、配置文件、工作流改造最后把踩过的坑全部摊开。先说结论如果只是让 AI 写写单机代码MCP Sealos 这套组合确实有点重。但只要你需要在代码之外“碰到”数据库、服务器、CI/CD 这些系统这套方案带来的效率提升是立刻能感觉到的。1. 为什么接开发者的时间都花在了“搬运”上1.1 六个窗口来回切的一天先描述我过去一天最常见的场景。早上到公司产品扔过来一个问题“线上订单金额算错了帮我看下。”接下来就是标准的搬运工时间打开 Navicat 连测试库导数据没问题再连生产库查订单表发现金额字段对不上接着 ssh 上服务器看应用日志grep 半天关键字最后打开 Grafana 看有没有异常曲线。等把数据、日志、监控三样东西凑齐二十分钟没了中间还容易漏掉关键信息。这还只是排查。如果要改代码、跑测试、构建镜像、部署到 staging、再部署到生产每一步都要切到对应的工具里操作。人的精力是有限的频繁的上下文切换会让最简单的任务也变得容易出错。我经常出现这种情况SQL 查出来结果了还没来得及记录就被一条告警带走了注意力。1.2 不是让 AI 替我干活而是让 AI 不打断我干活我最初用 Claude Code 的时候体验已经很惊艳——它能在仓库里读代码、改代码、执行测试。但它有个明显的天花板它只能碰到本地文件系统和命令行。我想让它“看一下线上订单为什么异常”它做不到因为它连不上生产库也看不到线上服务的状态。这就是我折腾 MCP 的起点。MCP 全称 Model Context Protocol作用是给 Claude 这类模型提供一套标准化的“手和脚”——通过 MCP ServerAI 可以去调用数据库、读取监控平台、操作部署系统。Sealos 则是这些 MCP Server 的宿主不用我自己买服务器、配环境、担心宕机云上点几下就能得到一个稳定的 HTTPS 服务地址。所以这套组合解决的不是“AI 会不会写代码”的问题而是“AI 能不能接触到你真实工作环境”的问题。模型再聪明碰不到数据就是空转一旦能通过工具碰数据、碰服务它的价值就从“代码补全”升级成了“能参与整个项目的运行”。1.3 预期收益和花费的时间成本老实说第一次搭这套东西花费的时间不短。从理解协议、选镜像、部署、配认证到最终在 Claude Code 里跑通第一个真实查询我断断续续用了一个周末。但跑通之后那些每天重复的“搬运”工作——查库、看状态、翻日志——都变成了对话里的几句话而且每次操作的记录都留在了 MCP Server 的日志里可审计、可回溯。2. MCP 协议速览别被术语吓住它就是个“万能插座”2.1 三个角色Host、Client、ServerMCP 的架构第一次看会觉得名词很多其实就三个角色。Host你直接面对的程序比如 Claude Desktop 或 Claude Code。它负责展示界面、收集你的指令并把 AI 的请求转发出去。ClientHost 内部的一个协议组件负责和 MCP Server 建立连接、维持会话、收发 JSON-RPC 消息。Server提供具体能力的独立服务可以是一个本地进程也可以是一个远程 HTTP 服务。它暴露一系列工具、资源和提示词模板等着 Host 来调用。打个比方Host 是一个遥控器Client 是遥控器里的红外发射器Server 就是空调、电视、音响这些被控设备。MCP 协议相当于统一了遥控信号的标准让任何品牌的遥控器都能控制任何品牌的设备。2.2 三类能力Tools、Resources、Prompts一个 MCP Server 能提供三种东西Tools可执行的“动作”比如执行 SQL、创建 GitHub Issue、触发构建。模型会根据对话内容主动决定调用哪个工具、传什么参数。Resources可读取的“数据”比如一个文件的内容、一张表的 schema。有点像给 AI 准备的只读资料库。Prompts预置的提示词模板定义某种场景下应该怎么组织对话。我实际用得最多的是 Tools。因为工作流要的是“动手能力”——让 Claude 去查库、去部署而不是简单地给它一堆文档看。2.3 stdio 和 HTTP本地与远程的本质区别MCP Server 有两种主流传输方式传输方式适用场景特点stdio本地进程启动快、零网络配置、和本地文件系统天然亲近HTTP / SSE远程服务可部署在云端、可共享、多端可访问stdio 模式适合 filesystem、git 这类必须访问本机资源的工具。但它的上限也明显Server 和 Host 必须在一台机器上。而 HTTP 模式让 MCP Server 可以跑在任何地方——包括 Sealos 云上——你的笔记本关机了服务照样在团队里的其他人也能共用。这里要提一句协议版本MCP 在 2025-03-26 版本之后主推 Streamable HTTP 传输老的 SSE 模式逐渐被社区弃用。如果你找的 MCP Server 镜像只支持 SSE也能用但我是建议优先选支持 Streamable HTTP 的因为超时处理、连接复用都更好。3. Sealos 在组合里的位置把 MCP Server 当普通云应用部署3.1 Sealos 能干什么Sealos 是一个基于 Kubernetes 的云操作系统对普通开发者的意义是不需要理解 K8s 的概念也能用上云原生能力。在它的控制台里你可以像使用手机 App 一样操作应用一键部署应用填镜像地址、端口、环境变量、存储点一下就能跑起来数据库市场PostgreSQL、MySQL、Redis 等常见数据库直接创建实例模板市场很多开源项目做成了模板选中即部署公网访问部署完成的应用自动获得一个 HTTPS 域名不用自己配 Nginx、配证书。就我的使用体验来说Sealos 最大的价值是“把运维成本降到了接近零”。我不需要关心节点、Ingress、证书轮换这些事只需要关心我的服务本身。3.2 为什么把 MCP Server 放云端而不是本地跑有人可能会问MCP Server 本地起一个不就行了为什么要费劲放到 Sealos 上我当时的理由有三个。第一稳定性。本地起服务意味着你的笔记本不能关机、不能休眠、IP 不能变。对于个人实验没问题但要真正进工作流一个 7x24 小时在线的服务才靠得住。第二贴近目标资源。我要让 Claude 查的是线上数据库而数据库实例本身也在 Sealos 上。MCP Server 和数据库同在一个云环境里网络延迟低还不用把数据库端口暴露到公网——MCP Server 在云端通过内网地址连数据库更安全。第三可共享。团队里三个人都要用同一个 MCP Server如果跑在各自笔记本上每个人的配置、版本、token 都不一样迟早出问题。集中部署之后大家连同一个地址版本由一个人维护体验就一致了。3.3 三种托管姿势我怎么选的在 Sealos 上托管 MCP Server我试过三种方式方式操作难度灵活度我的评价模板市场一键部署最低低适合验证环境模板数量有限自定义 Docker 镜像部署中等高主力方式可控性最强Devbox 云开发环境托管中等高适合开发调试生产不建议我最常用的是第二种先把 MCP Server 代码写好、构建成镜像推到镜像仓库再在 Sealos 的应用管理里创建一个应用填镜像地址和环境变量暴露端口完事。整个过程和在服务器上跑 docker run 差不多但 Sealos 帮我管好了重启策略、磁盘、域名。4. 从零到一部署一套“Claude PostgreSQL MCP”的完整链路4.1 搭建一个最简单的 PostgreSQL MCP Server我先说清楚目标我要让 Claude 能对一个 PostgreSQL 数据库执行只读 SQL 查询。为此需要一个 MCP Server它接收 Claude 发来的工具调用请求把 SQL 发给数据库把结果返回给 Claude。假设你自己写这个 Server核心代码用 Python 的 FastMCP 来实现大概长这样# server.py import os import psycopg2 from mcp.server.fastmcp import FastMCP mcp FastMCP(pg-assistant) mcp.tool() def query_database(sql: str) - str: 对 PostgreSQL 数据库执行只读 SQL 查询只允许 SELECT。 if not sql.strip().lower().startswith(select): return 错误只允许 SELECT 查询 conn psycopg2.connect(os.environ[DATABASE_URL]) try: cur conn.cursor() cur.execute(sql) rows cur.fetchmany(100) if not rows: return 查询无结果 cols [d[0] for d in cur.description] return \n.join([, .join(cols)] [, .join(str(c) for c in r) for r in rows]) finally: conn.close() if __name__ __main__: mcp.run(transportstreamable-http)Dockerfile 也不用复杂FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY server.py . EXPOSE 8000 CMD [python, server.py]requirements.txt 里需要 mcp官方 Python SDK 自带 FastMCP、psycopg2-binary、uvicorn 这几个包。注意mcp SDK 版本迭代很快具体 API 可能因版本略有差异你拉新版本时建议先翻一下官方文档。代码写完构建镜像推到 Docker Hub 或 GitHub Container Registry。然后在 Sealos 控制台创建应用镜像地址填你的仓库地址端口填 8000环境变量里配 DATABASE_URL值是你在 Sealos 上创建的 PostgreSQL 实例的内网连接串再加一个环境变量 MCP_AUTH_TOKEN作为访问凭证。4.2 暴露公网 HTTPS 并验证端点Sealos 会给应用自动分配 HTTPS 域名。部署完成后在应用详情页能看到一个形如https://xxxxx.sealos.run的地址。MCP 的 Streamable HTTP 端点默认在根路径/或/mcp取决于你的 Server 实现。用 curl 验证是最快的curl -X POST https://你的域名/mcp \ -H Content-Type: application/json \ -H Authorization: Bearer 你的MCP_AUTH_TOKEN \ -d {jsonrpc:2.0,id:1,method:initialize,params:{protocolVersion:2025-03-26,capabilities:{},clientInfo:{name:curl-test,version:0.1.0}}}如果返回类似下面的内容说明 MCP Server 已经正常在公网提供服务了{jsonrpc:2.0,id:1,result:{protocolVersion:2025-03-26,capabilities:{tools:{}},serverInfo:{name:pg-assistant,version:0.1.0}}}我一直到这一步都会顺手 curl 一次再接入客户端能省很多后面排查的时间。4.3 Claude Desktop 接入远程 MCPClaude Desktop 的配置在 macOS 是~/Library/Application Support/Claude/claude_desktop_config.jsonWindows 是%APPDATA%\Claude\claude_desktop_config.json。在里面加上远程 MCP Server{ mcpServers: { pg-assistant: { url: https://你的域名/mcp, headers: { Authorization: Bearer 你的MCP_AUTH_TOKEN } } } }保存后完全退出 Claude Desktop 再重新打开在对话框里往往就能看到已连接的工具。你可以在对话里直接问“现在有哪些工具可以用”它会列出 MCP Server 暴露出来的工具。4.4 Claude Code 接入远程 MCPClaude Code 更方便支持两种方式。方式一在项目根目录创建.mcp.json{ mcpServers: { pg-assistant: { type: http, url: https://你的域名/mcp, headers: { Authorization: Bearer 你的MCP_AUTH_TOKEN } } } }方式二用命令直接添加claude mcp add pg-assistant --transport http https://你的域名/mcp --header Authorization: Bearer 你的MCP_AUTH_TOKEN添加完执行claude mcp list能看到 Server 的状态。进入交互界面后Claude 会在需要时自动调用这个工具你也可以在对话里用斜杠命令强制检查工具列表。4.5 用一次真实查询验证全链路配置好后我在 Claude Code 里输入了一句“用 pg-assistant 查询 orders 表最近 24 小时的订单总数按状态分组。”Claude 会先调用query_database工具传入 SQL然后展示返回结果。我确认 SQL 没问题后再让它继续分析。整个调用链路Claude Code - MCP Client - HTTPS - Sealos 上的 MCP Server - 内网 PostgreSQL - 返回完整走通。到这里一个最小可用的远程 MCP 就搭好了。后面所有工作流都是在这个基础上扩展。5. 接通之后我的日常工作流变成了什么样5.1 线上问题排查从半小时到三分钟最直观的变化是排查线上问题的速度。以前要开 Navicat、连服务器、翻日志现在我在 Claude Code 里用自然语言描述现象它自己决定查哪张表、跑什么 SQL。如果查出来的结果不对我直接补一句条件它立刻重新组织 SQL 再跑。这种“边走边问”的交互方式比传统工具链高效在一点SQL 不是固定写死的而是针对当前问题动态生成的能顺着线索往深挖。我只需要盯着它的 SQL 有没有问题而不是自己写一半又切出去查表结构。5.2 部署与回滚给 AI 一把“最小权限钥匙”我后来又写了一个 deployment MCP Server暴露三个工具查看当前版本、升级到指定镜像、回滚到上一版本。这个 Server 用的是只读权限的 kubeconfig并且限定在 staging 命名空间。Claude 可以查看状态、执行部署但没法删集群、没法动生产环境。这让“部署”和“回滚”变成了对话操作。比如我说“把 staging 升到 20240718-1 这个镜像”Claude 会先执行“查看当前版本”再执行“升级到指定镜像”每一步都展示命令让我确认。由于关键操作需要人在对话里确认安全性是可控的。5.3 多项目复用MCP Server 变成团队公共设施在 Sealos 上部署的一个好处是同一个 MCP Server 可以被整个团队使用。我把连接信息写进团队的.mcp.json模板后新同事 clone 项目下来配置好本地的 Claude Code就能直接查询共享的测试数据库。省掉了“来个人就配一遍数据库连接串”的重复劳动也避免了每个开发者各自保存一份生产库密码的安全隐患。5.4 红线哪些能力我坚决不交给 AI工具给了 AI 之后一定要明确边界。我的红线有三条默认只读。所有数据库 MCP 默认只允许 SELECT写操作必须单独写一个“受控写”工具并且每个写操作都要人在对话里显式确认。最小权限。给 MCP Server 的凭证永远是最小的那个比如只读账号、单命名空间的 kubeconfig绝不拿管理员 token 喂给 AI。敏感表隔离。用户隐私数据所在的表不暴露给 MCP Server用白名单机制只允许查询业务表。6. 踩坑实录远程 MCP 接入的完整问题清单6.1 Windows 上 Claude 工作区启动失败的两类报错我在 Windows 机器上装 Claude Desktop 时遇到过两个让很多人卡住的报错。第一个报错是 “Claudes workspace requires the virtual machine platform on Windows. Enable...”。这是 Claude Desktop 的工作区功能依赖 Windows 的虚拟机平台组件。解决办法打开“控制面板 - 程序 - 启用或关闭 Windows 功能”勾选“虚拟机平台”和“Windows 虚拟机监控程序平台”然后重启电脑。这俩组件是 Windows 自带的虚拟化功能和 Docker Desktop 开启 Hyper-V 是同一类操作。第二个报错是 “failed to start claudes workspace rpc error -1: sdk version ... not verified” 之类。多半是安装包版本和本地缓存不一致导致的。我试过最有效的办法是彻底卸载 Claude Desktop清掉%APPDATA%\Claude下的缓存目录然后安装最新版本。升级前看一下 SDK 版本号保持 Client 端一致能少很多事。6.2 连上了但工具列表为空第一次配置完成后我在 Claude Desktop 里看到 Server 状态显示已连接但对话里说“当前没有可用工具”。排查链路很重要别瞎猜。先用 curl 直接调 MCP 端点确认 Server 本身没问题。我之前遇到的根因是路径不对有的镜像把 Streamable HTTP 端点挂在/mcp有的在/还有老镜像只支持 SSE挂在/sse。配置里 URL 路径写错一位连接状态照样显示正常但工具就是拉不下来。手动用 curl 发送 initialize 和 tools/list 请求是最快的定位方式。6.3 远程调用超时和连接被断开另一个高频问题是Claude 思考一会儿后再调用远程工具返回“connection closed”或超时。我定位后发现这类问题的根因往往不是客户端而是中间的网关或 Server 自身的空闲超时设置。Sealos 的网关和本地 Nginx 一样超过一定时间没有数据传输会断开连接。解决办法有三个思路一是服务器加心跳定期发送 ping 保持连接二是把工具设计成“快进快出”单次调用尽量在几秒内返回长任务用“提交任务 - 查询状态”两步模式而不是让一次工具调用跑几分钟三是客户端侧合理设置超时时间给足网络往返余量。我自己后来把所有的重活都改成了“异步任务模式”调用就稳定了很多。6.4 Token 过期导致客户端静默失联远程 MCP 的认证我用的是 Bearer Token但 Token 一旦更新Claude Desktop 和 Claude Code 并不会自动重新读取经常要重启客户端才生效。后来我把 Token 统一放到环境变量里配置文件里只写${MCP_TOKEN}这种占位符换 Token 只需要在 Shell 环境变量或 CI 变量里改一处不用逐个改 JSON。另外提醒一点MCP Server 端一定要校验每个请求的 Authorization 头别指望“域名够冷门别人发现不了”。公网服务分分钟会被扫描器探到。7. 进阶方向把个人方案升级成团队基础设施7.1 统一 MCP 网关一个地址接入所有能力跑了一段时间后我意识到每个能力一个独立域名的方式不可持续于是加了一层 MCP Gateway把多个 MCP Server数据库、部署、GitHub统一到一个入口后面按路径路由。这样客户端只需要配置一个地址认证也在网关层统一处理MCP Server 本身不直接暴露公网。实现网关并不复杂一个 Nginx 配置加上基于 auth_request 的 Token 校验就能起步或者在 Sealos 上再部署一个轻量的 API 网关服务。重要的是让团队只有一个“入口”权限和审计都集中在这一层。7.2 从“工具粒度”到“技能粒度”我第二个进阶动作是把 MCP 暴露的工具从原子操作“执行任意 SQL”改成业务技能“查询订单异常清单”“对比两个版本配置差异”。原子操作灵活但给了模型太多自由发挥的空间容易出格业务技能把 SQL 写成白名单模版模型只负责填参数安全性和准确性都大幅提升。当然前提是你得先梳理出团队里最高频、最值得自动化的一批“技能”否则过早抽象只会让维护成本翻倍。我建议从排查类技能做起这类问题多、重复度高、成就感也最强。7.3 成本、限流与审计MCP Server 跑在 Sealos 上资源就是成本。我在部署时为每个 MCP Server 设置了资源限额防止某个工具被递归调用把 CPU 打满。同时在网关层做了简单的限流每人每秒钟最多 N 次工具调用。日志方面MCP Server 收到的每个 JSON-RPC 请求都记录了用户身份、工具名、参数摘要和执行结果出了问题可以完整回放这也是团队能接受“让 AI 操作生产系统”的前提。7.4 与 CI/CD 和更多 AI 客户端打通最后一步是把这套 MCP 能力接入到现有 CI/CD 的“人机校验”环节比如部署前让 Claude 生成变更说明并审核 SQL再由 MCP Server 触发流水线。MCP 这套标准不绑定 ClaudeCursor、Codex、以及其他支持 MCP 的客户端都能连同一个 Server。这意味着你花在 MCP Server 上的每份投入都能被多个 AI 工具复用不会绑定死在某一家。对我来说这套组合真正改变的不是“AI 替我干活”这种感觉而是“AI 和我面对同一个系统状态”——我看到什么它也看到什么我操作什么它能帮我验证。把护栏建好之后它让我从大量重复的“搬运”里解脱出来把精力放回真正需要判断力的事情上。最后再分享一个小技巧把你团队的常用 MCP 配置整理成一份.mcp.json模板放进仓库根目录新人 clone 下来就能用。这套组合的上限不取决于 AI 模型有多聪明而取决于你把多少真实的系统接进了工具层。我的经验是先接一个高频场景跑通再扩比一开始就想搭一个大而全的平台靠谱得多。