1. 生产环境里 MCP Server 为什么总在半夜挂掉MCP Server 说白了就是给大模型装的一双手模型负责想Server 负责干比如查库、调接口、读文件。LeanMCP 是围绕 MCP 协议做的一层 Runtime 工具链TypeScript 优先同时能和 Python 写的逻辑共存。它适合谁适合那些已经把 Agent Demo 跑通、准备把 MCP Server 放到线上长期跑的人而不是只想在本地玩两把的。我见过太多团队卡在同一个地方本地npm run dev一切正常一上生产就出问题。表现通常是三种。第一种是进程莫名其妙没了日志里什么都没有第二天早上发现 Agent 调工具全部超时。第二种是并发一上来就雪崩本来单个请求 800ms十个请求一起打过来变成 8 秒。第三种是出了问题完全不知道从哪查工具到底调没调、调了几次、哪一步慢全靠猜。根因其实不复杂。MCP 本身是协议标准它规定的是模型和工具之间怎么对话但没规定这个 Server 进程怎么守护、怎么限流、怎么健康检查、怎么优雅退出。官方 SDK 给的示例大多是单进程前台运行适合演示不适合当服务。生产环境要的是进程挂了能自动拉起、启动前能确认依赖就绪、请求进来能并行处理、出问题有结构化日志可查。这篇就按这个思路把 LeanMCP 的部署骨架、TypeScript 与 Python 双 Runtime 配置、CC Switch 接入统一 Key 通道、以及启动验证和排障动作一次讲清楚。2. 部署前先把 TaoToken 通道和 Key 准备好在动 LeanMCP 之前建议先把模型调用通道固定下来。原因是 MCP Server 在生产里往往不只服务一个 Agent如果每个 Agent 各自配一套 Key 和地址后面换模型、加配额、查调用量都会很乱。TaoToken 在这里的角色是统一入口你拿到一个 Key通过同一个 API 地址访问不同模型MCP Server 里只认这一套配置。具体动作打开 https://taotoken.net/api 对应的控制台进入 API Keys 页面创建一个新 Key。建议按环境拆开比如prod-agent-runtime和staging-agent-runtime各一个别用同一个 Key 跑测试和生产否则排查问题时分不清流量来源。创建完把 Key 存到环境变量里不要写进代码仓库。如果你用的是 Claude Code 这类编码工具或者想让 MCP Server 走 Anthropic 兼容通道可以看下 https://taotoken.net/api 的接入文档里面有针对 ClaudeCodeAnthropic 的说明。模型对话调试可以直接在 https://taotoken.net/api 的模型对话页面试确认 Key 能用、模型能返回再去配 LeanMCP这样能把问题范围缩小。注意Key 只放环境变量或密钥管理服务别提交到 Git。生产 Key 和测试 Key 分开方便按环境看用量。3. LeanMCP 的 TypeScript Runtime 配置骨架LeanMCP 的 CLI 建项目很快但生产部署不能只靠npm run dev。下面这套骨架是我实际用下来比较稳的。先建项目npm install -g leanmcp/cli npx leanmcp/cli create agent-runtime cd agent-runtime npm install然后改package.json的启动脚本把开发和生产分开{ scripts: { dev: leanmcp dev, build: tsc -p tsconfig.json, start: node dist/server.js, health: node dist/healthcheck.js } }生产启动不要用 dev 模式dev 模式带热更新和文件监听吃内存且不适合守护进程。构建产物放dist用node直接跑。接下来是工具定义。LeanMCP 用装饰器风格TypeScript 的类型直接当 Schema 用省掉手写 JSON 的环节import { tool } from leanmcp/core; import { requireAuth } from leanmcp/auth; requireAuth() tool(search_docs) export async function searchDocs(query: string, topK: number 5) { const started Date.now(); const result await vectorStore.search(query, topK); logger.info({ tool: search_docs, ms: Date.now() - started, hits: result.length }); return result; }这里有两个生产要点。一是每个工具里都打结构化日志记录工具名、耗时、结果条数后面排障全靠它。二是认证装饰器放在工具级不同工具可以有不同权限不要整个 Server 一个开关。进程守护方面Linux 上用 systemd 最省事。写一个 unit 文件[Unit] DescriptionLeanMCP Agent Runtime Afternetwork.target [Service] Typesimple WorkingDirectory/opt/agent-runtime EnvironmentFile/etc/agent-runtime/env ExecStart/usr/bin/node dist/server.js Restartalways RestartSec3 StandardOutputappend:/var/log/agent-runtime/out.log StandardErrorappend:/var/log/agent-runtime/err.log [Install] WantedBymulti-user.targetRestartalways配合RestartSec3能覆盖大部分崩溃自愈场景。EnvironmentFile里放TAOTOKEN_API_KEY和TAOTOKEN_BASE_URL权限设成 600。4. Python 逻辑与 TypeScript Runtime 的混合配置很多团队的算法和数据处理是 Python 写的不可能全迁到 TS。LeanMCP 的做法是Runtime 和网关用 TypeScript具体工具逻辑可以用 Python 实现通过标准 MCP 协议对接。这样分工清楚TS 管并发、认证、监控Python 管推理和后处理。Python 侧装官方包pip install modelcontextprotocol写一个 Python 工具服务暴露给 LeanMCP 调用from modelcontextprotocol.server import Server from modelcontextprotocol.types import Tool app Server(python-tools) app.tool(Tool(nameembed_text, description生成文本向量)) async def embed_text(text: str) - list[float]: vec model.encode(text) return vec.tolist() if __name__ __main__: app.run(host127.0.0.1, port9100)然后在 LeanMCP 的config.toml里注册这个上游[runtime] name agent-runtime max_concurrency 32 request_timeout_ms 15000 [[upstreams]] name python-tools transport http endpoint http://127.0.0.1:9100 health_path /healthmax_concurrency控制同时处理的请求数别设太大按机器核数和工具 IO 特性调。request_timeout_ms是单请求上限防止某个慢工具拖死整个 Runtime。Python 服务本身也用 systemd 守护和 TS Runtime 分开管互不影响。CC Switch 接入 TaoToken 的配置放在settings.json里统一 Key 和地址{ provider: taotoken, baseUrl: https://taotoken.net/api, apiKeyEnv: TAOTOKEN_API_KEY, models: { default: claude-sonnet, fallback: gpt-4o-mini }, timeoutMs: 20000, retry: { maxAttempts: 2, backoffMs: 500 } }这样 Runtime 里所有模型调用都走同一个通道换模型只改models.default不用动业务代码。5. 启动验证与成功结果确认配置写完别急着上流量先按顺序验证。第一步单独起 Python 工具服务确认端口通curl -s http://127.0.0.1:9100/health # 期望返回 {status:ok}第二步构建并启动 TS Runtimenpm run build node dist/server.js启动日志里应该能看到 Runtime 名称、监听端口、注册的上游列表、并发上限。如果看到upstream python-tools registered和listening on 0.0.0.0:8080说明骨架起来了。第三步发一个真实工具调用请求curl -s -X POST http://127.0.0.1:8080/mcp \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d {tool:search_docs,params:{query:部署指南,topK:3}}成功的话返回里会有结果数组同时日志里出现一条toolsearch_docs ms... hits3的记录。这一步能过说明认证、路由、工具执行、日志四条链路都通了。第四步压一下并发确认并行调度生效for i in $(seq 1 20); do curl -s -X POST http://127.0.0.1:8080/mcp \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d {tool:search_docs,params:{query:test}} done wait观察日志里 20 条记录的耗时分布。如果总耗时接近单次耗时而不是 20 倍说明并行调度在工作。这一步是区分玩具和生产的关键。6. 本篇常见错误排查启动即退出日志只有一行。多半是环境变量没加载。检查 systemd 的EnvironmentFile路径和权限手动source一下再跑确认TAOTOKEN_API_KEY有值。工具调用返回 401。Key 没传对或者 CC Switch 里apiKeyEnv写的变量名和实际环境变量不一致。用env | grep TAOTOKEN确认。Python 上游连不上。先curl健康检查再确认config.toml里的endpoint端口和 Python 服务监听端口一致。常见坑是 Python 绑了127.0.0.1但 Runtime 在容器里跨容器访问不到改成绑0.0.0.0并加内网访问控制。并发上不去耗时线性增长。检查max_concurrency是不是设成了 1或者工具里有全局锁。另外确认工具本身是异步的同步阻塞代码会占满事件循环。日志里工具名对不上。装饰器里的名字和请求里的tool字段必须完全一致大小写敏感。建议在启动时打印一份已注册工具清单方便核对。进程反复重启。看err.log如果是 OOM调小max_concurrency或加内存如果是端口占用检查是不是有残留进程没杀干净。7. 把 Runtime 长期跑稳的几个动作部署只是开始长期稳定靠的是日常动作。第一健康检查要接进监控/health返回非 200 就告警别等用户反馈。第二日志按天切割out.log和err.log都配上 logrotate不然磁盘迟早满。第三Key 定期轮换TaoToken 控制台里可以建新 Key 再下线旧的轮换时改环境变量重启即可不影响业务。如果你的 Agent 要长期跑编码任务或者做复杂 Agent 编排建议看下 Coding Plan 这类方案把模型调用配额和 Runtime 部署一起规划省得后面流量涨了再临时补。接入文档在 https://taotoken.net/api 的 doc 页API Keys 在 console 里管理模型调试用模型对话页。整套跑下来MCP Server 才算真正从 Demo 变成了能扛流量的服务。