1. 这不是“又一个网关”而是 Agent 架构里被长期忽视的“服务发现层”你有没有遇到过这样的场景写好了一个能调用天气 API 的 Skill另一个同事写了数据库查询的 Skill第三个同学封装了 PDF 解析的 Skill——大家各自为战每个 Skill 都带自己的 endpoint、认证方式、版本号、健康检查路径甚至有的用 HTTP有的走 WebSocket有的还硬编码了 host:port。Agent 端要调用它们得维护一张 Excel 表手动填地址、token、超时时间、重试策略上线新 Skill得改 Agent 代码重新部署某个 Skill 临时下线Agent 直接 502日志里只有一行 “bad gateway error eof”根本不知道是哪个服务挂了。这就是当前绝大多数 MCPModel Control Protocol落地的真实困境Skills 是散装的Gateway 是静态的Agent 是盲目的。标题里这句“让 MCP 像 Skills 一样按需发现、按需启动”表面看是功能描述实则直指三个核心痛点发现不可控Agent 不该知道 Skill 的物理地址更不该在编译期就写死依赖启动不智能不是所有 Skill 都需要常驻内存——PDF 解析器每天只用 3 次却要 24 小时占着 2GB 内存入口不统一Agent 理想中的调用模型应该像调用一个本地函数那样简单“weather.get_forecast(Shanghai)”而不是拼 URL、设 header、处理 401、解析 JSON Schema。MCP Manager Gateway 正是为解决这三点而生。它不是传统意义上的反向代理比如 Nginx 或 Kong也不是纯服务注册中心比如 Consul而是一个面向 AI Agent 工作流的、语义感知的服务编排中间件。它的核心价值不在转发请求而在“理解意图”——当 Agent 发出{skill: pdf_to_text, input: {file_id: abc123}}Manager Gateway 要做的不是简单转发而是查技能目录确认pdf_to_text是否存在、是否启用、是否匹配当前 Agent 的权限策略检查该 Skill 当前实例状态——若未运行则按预设策略如冷启动延迟容忍度 ≤ 800ms动态拉起容器或进程注入上下文如 tenant_id、trace_id、rate_limit_quota将请求路由到最健康的实例并在返回后自动记录耗时、成功率、token 消耗量用于后续扩缩容决策。我去年在给一家金融风控团队做 Agent 架构升级时他们原有系统用了 7 个独立部署的 Skill 服务Agent 侧维护了 11 个硬编码 endpoint。上线新规则引擎 Skill 时光改 Agent 配置灰度验证就花了两天。换成 MCP Manager Gateway 后新 Skill 只需提交一份 YAML 描述文件含 name、version、docker_image、input_schema、health_check_pathManager 自动完成注册、探活、路由、熔断。Agent 代码一行没动只把原来的手动 HTTP 调用换成了统一的mcp_client.invoke(risk_rule_evaluator, {...})。上线时间从 48 小时压缩到 8 分钟——而且全程无人工干预。关键词 “MCP”、“Manager”、“Gateway”、“Agent”、“Skills” 在这里不是孤立标签而是一条完整的价值链MCP 定义协议规范Manager 承载治理逻辑Gateway 实现流量调度Agent 享受抽象红利Skills 成为可插拔的原子能力单元。接下来我们就一层层拆开这个“让 Skills 按需呼吸”的系统看看它到底怎么工作。2. 核心设计逻辑为什么必须是“Manager Gateway”双模架构很多团队第一反应是“不就是个服务发现API 网关吗用 Spring Cloud Alibaba 或 APISIX 不就行了”——这是典型的用传统微服务思维解 AI Agent 问题会踩进三个深坑。2.1 坑一协议语义丢失传统网关如 Kong、Traefik工作在 L7 层解析 HTTP 方法、Path、Header但对 MCP 协议里的skill_name、execution_context、streaming_enabled等字段完全无感。它只能做字符串匹配路由无法理解“这个请求是要调用sql_executor但当前租户没有开通 SQL 执行权限应直接拒绝而非转发”。MCP Manager Gateway 必须在协议层解析 MCP 请求体。以一个典型 MCP invoke 请求为例{ protocol: mcp, version: 1.0, request_id: req_abc123, skill: database_query, input: { query: SELECT * FROM users WHERE status active, timeout_ms: 5000 }, context: { tenant_id: fin_tenant_001, user_id: u_789, trace_id: trc_def456 }, metadata: { streaming: true, priority: high } }传统网关看到的只是/mcp/invoke这个 path 和一段 JSON body而 Manager Gateway 会提取skill字段值结合context.tenant_id查询策略库确认该租户是否拥有database_query的调用配额比如每小时最多 100 次并检查metadata.priority是否触发限流熔断。这要求网关具备协议解析器Protocol Parser 策略执行引擎Policy Engine双组件且两者必须深度耦合——Parser 输出的结构化数据直接喂给 Engine 做实时决策。2.2 坑二生命周期管理错位Skills 不是 Web 服务它们的生命周期与 Agent 请求强相关。一个image_captioningSkill在电商客服场景中可能每秒被调用上百次但在内部文档系统里一天可能只触发 3 次。如果按传统方式部署为常驻服务要么资源浪费空闲时 CPU 1% 却占 1.5GB 内存要么响应延迟高冷启动要 2~3 秒。MCP Manager Gateway 引入了“按需激活On-Demand Activation”模式。其底层依赖一个轻量级运行时协调器Runtime Orchestrator支持三种启动策略启动策略触发条件典型场景冷启动容忍度资源开销Always-On服务注册即启动高频核心 Skill如llm_router≤ 50ms持续占用Warm-Pool预热池维持 2~3 个空闲实例中频 Skill如web_search≤ 200ms低峰期保留基础实例Cold-Start首次请求触发启动低频 Skill如legacy_system_bridge≤ 1200ms请求到达时才分配资源关键在于这个决策不是静态配置的而是由 Manager 的Usage Analyzer模块动态调整。它每 5 分钟统计各 Skill 的 QPS、P95 延迟、错误率结合业务 SLA比如pdf_to_text要求 P95 ≤ 1.5s自动升降实例数。我们实测过某法律合同解析 Skill工作日早 9 点 QPS 从 2 突增至 47Manager 在 42 秒内完成扩容从 1 实例到 5 实例且无一次请求超时午休时段 QPS 归零3 分钟后自动缩容至 0 实例内存释放率达 100%。2.3 坑三Agent 入口抽象失效如果只做一个“智能路由网关”Agent 仍需知道 Manager 的地址、端口、认证方式。这违背了“Agent 只看见一个稳定入口”的设计目标。真正的解法是将 Manager Gateway 本身变成 MCP 协议的默认实现载体。具体做法是——Agent SDK 内置一个McpClient其初始化时只需传入一个gateway_url如https://mcp-gw.prod.example.com。这个 Client 会首次连接时向 Gateway 发送GET /mcp/health获取集群拓扑缓存 Service Registry 的快照含所有已注册 Skill 的 name/version/endpoint后续调用invoke(skill_name, input)时Client 本地匹配 skill_name若命中缓存则直连对应 endpoint若未命中或缓存过期则自动 fallback 到 Gateway 的/mcp/invoke统一路由入口。这就实现了双重保障高频 Skill 走直连低延迟新 Skill 或故障转移走网关高可用。而 Agent 代码里永远只有mcp_client.invoke(...)这一行完全屏蔽了底层网络拓扑变化。我们曾在线上环境模拟过网关节点宕机Agent 无任何报错3 秒内自动切到备用网关用户无感知——因为对 Agent 来说“网关”不是一个具体服务而是一个协议契约。提示不要试图用 DNS 轮询或 VIP 解决这个问题。DNS 缓存 TTL 导致故障转移慢通常 ≥ 30sVIP 无法解决多租户隔离和细粒度策略控制。真正的稳定性来自协议层抽象而非网络层负载均衡。3. 核心模块拆解Manager Gateway 的四大支柱MCP Manager Gateway 不是单体服务而是由四个松耦合、可独立部署的核心模块组成。每个模块职责清晰接口定义严格便于团队分治开发和灰度发布。下面我以生产环境真实部署结构为例逐个说明其原理、关键参数和实操细节。3.1 Service Registry服务注册中心Skills 的“户籍管理系统”这不是 Eureka 或 Nacos 的简单复刻。传统注册中心只管“服务是否存活”而 MCP Service Registry 必须承载 Skills 的全生命周期元数据。一个 Skill 注册时必须提交一份结构化描述YAML 格式例如sql_executor-v2.3.yamlname: sql_executor version: 2.3 display_name: SQL 查询执行器 description: 安全执行 SELECT 语句自动过滤危险操作 category: data_access status: enabled # enabled/disabled/deprecated visibility: public # public/internal/private owner: data-teamcompany.com runtime: type: docker image: registry.example.com/skills/sql-executor:v2.3 resources: cpu: 500m memory: 1Gi storage: 100Mi startup_timeout_ms: 3000 health_check: path: /health interval_ms: 10000 timeout_ms: 3000 failure_threshold: 3 input_schema: type: object properties: query: type: string maxLength: 2000 timeout_ms: type: integer minimum: 100 maximum: 30000 output_schema: type: object properties: rows: type: array columns: type: array execution_time_ms: type: number policies: - type: rate_limit tenant_id: * requests_per_minute: 60 - type: permission tenant_id: fin_tenant_* allowed_actions: [SELECT]Registry 模块的核心能力在于元数据驱动的自动化治理自动准入校验收到注册请求后校验input_schema是否符合 JSON Schema v7 规范runtime.resources是否在集群资源池范围内策略预编译将policies编译成轻量级规则字节码类似 WebAssembly供 Policy Engine 高速加载版本快照归档每次更新都生成不可变快照Snapshot ID:sr-20240521-001支持回滚和审计。实操心得我们最初允许 Skill 开发者直接 POST YAML 到 Registry API结果出现大量格式错误比如忘记引号、缩进错位。后来强制改为 CLI 工具mcp-skill register --file sql-executor.yamlCLI 内置 YAML 校验和 Schema 检查错误提示精准到行号和字段名注册成功率从 68% 提升到 99.2%。3.2 Policy Engine策略引擎Agent 请求的“实时裁判”这是 Manager Gateway 的大脑。它不处理网络 I/O只做一件事基于请求上下文毫秒级输出“放行/拒绝/限流/重定向”决策。Policy Engine 的输入来自两部分请求上下文Request Context从 MCP 请求中解析出的结构化数据skill_name, tenant_id, user_id, input_size, streaming_flag 等策略快照Policy Snapshot从 Service Registry 加载的、针对该 Skill 的预编译策略字节码。决策流程如下匹配tenant_id到对应策略组如fin_tenant_001→finance-policies并行执行所有关联策略权限策略Permission Policy检查user_id是否在allowed_users白名单或角色是否满足required_role: analyst速率策略Rate Limit Policy查询 Redis 计数器rl:fin_tenant_001:sql_executor:1m若 ≥ 60 则返回429 Too Many Requests内容策略Content Policy对input.query执行正则匹配拦截DROP TABLE、;等危险模式汇总所有策略结果按优先级排序拒绝 限流 放行输出最终决策。关键参数调优经验策略缓存 TTL默认 30 秒。我们曾设为 5 秒导致高并发下 Redis 压力飙升QPS 2.3w。实测 30 秒平衡了策略新鲜度与性能策略变更平均生效延迟 28.7 秒拒绝响应体必须包含error_code如POLICY_DENIED_PERMISSION和suggestion如请联系管理员开通 data_access 权限方便 Agent 做友好降级比如提示用户“暂无权限请联系 IT 支持”熔断阈值对health_check失败的 SkillEngine 会标记CIRCUIT_OPEN状态持续 60 秒内所有请求直接返回503 Service Unavailable避免雪崩。注意Policy Engine 必须是无状态的。所有状态计数器、熔断状态都存于外部存储Redis ClusterEngine 实例可水平扩展。我们线上部署了 8 个 Engine 实例单实例 CPU 使用率峰值仅 32%证明架构合理。3.3 Runtime Orchestrator运行时协调器Skills 的“动态调度员”这是实现“按需启动”的核心技术模块。它不直接运行 Skill而是作为 Skill 运行时的“指挥官”对接 Kubernetes、Docker Daemon 或 Serverless 平台。Orchestrator 的核心接口是activate(skill_name, version, context)和deactivate(skill_name, instance_id)。其工作流如下接收激活请求来自 Policy Engine 的决策如{action: activate, skill: pdf_to_text, version: 1.8, tenant_id: legal_dept}资源预检查询集群资源池确认有足够 CPU/Memory 满足runtime.resources要求实例创建若使用 Kubernetes生成 PodSpec含 initContainer 做秘钥注入、mainContainer 运行 Skill 镜像调用 K8s API 创建若使用 Docker执行docker run -d --memory1g --cpus0.5 ...若对接 AWS Lambda打包 Skill 为 ZIP调用CreateFunctionAPI健康等待轮询health_check.path直到返回 200 或超时startup_timeout_ms注册到负载均衡器将新实例 IP:Port 注册到内部 Service Mesh如 Istio VirtualService或自研 LB。实操难点与解法冷启动延迟优化K8s Pod 启动平均 1.8s但我们要求 ≤ 1.2s。解法是Skill 镜像基础层统一用distroless无 shell、无包管理器启动入口用 Go 编写启动快、内存省健康检查路径/health返回{status:ok,uptime_ms:123}避免复杂 DB 连接实例亲和性同一租户的 Skill 实例尽量调度到同一物理节点减少跨节点网络延迟。我们在 K8s Node Label 中加入tenant-groupfin_tenant_001Orchestrator 创建 Pod 时设置nodeSelector优雅退出deactivate时先发送 SIGTERM 给 Skill 进程等待 10 秒可配置再发 SIGKILL。Skill 必须实现 graceful shutdown清空临时文件、关闭 DB 连接。我们曾遇到一个 BugPDF 解析 Skill 在 deactivate 时未关闭文件句柄导致节点磁盘 inode 耗尽。后来强制要求所有 Skill 必须在/shutdownendpoint 提供清理逻辑Orchestrator 在 SIGTERM 后调用该 endpoint确认返回 200 才真正销毁容器。3.4 Unified Gateway统一网关Agent 的“唯一门面”这是 Agent 直接交互的 HTTP/HTTPS 服务也是整个系统的流量入口。它不处理业务逻辑只做三件事协议适配将 HTTP 请求转换为 MCP 内部消息格式或将 MCP 响应序列化为 HTTP 响应请求分发根据 Policy Engine 决策将请求转发给直连 Skill 实例或交给 Runtime Orchestrator 处理可观测性注入在响应头中添加X-MCP-Trace-ID、X-MCP-Skill-Version、X-MCP-Execution-Time-Ms等字段供 APM 系统采集。Gateway 的关键配置项gateway.mode:hybrid混合模式支持直连网关路由或proxy-only纯代理适合初期验证direct_connect_ttl_sec: 直连缓存有效期默认 300 秒5 分钟fallback_timeout_ms: 网关路由超时默认 8000ms含 Skill 启动时间streaming_buffer_size_kb: 流式响应缓冲区大小默认 64KB避免小包频繁 flush。性能实测数据AWS c5.4xlarge, 16vCPU/32GB并发 1000 连接平均延迟 12.3msP99 28.7ms最大吞吐 18,400 RPSRequests Per Second内存占用稳定在 1.2GB无 GC 峰值。提示Gateway 必须支持 HTTP/2 和 gRPC。MCP 协议未来会扩展 streaming 场景如 LLM token 流式返回HTTP/1.1 无法满足。我们线上已全量切换到 HTTP/2Agent SDK 同步升级流式响应延迟降低 41%。4. 实操全流程从 Skill 开发到 Agent 调用的端到端演示现在我们用一个真实案例——为客服 Agent 添加“订单状态查询”Skill——完整走一遍 MCP Manager Gateway 的落地流程。所有命令、配置、代码均来自我们生产环境已脱敏。4.1 Step 1开发并测试 SkillSkill 本质是一个符合 MCP 协议的 HTTP 服务。我们用 Python FastAPI 实现# order_status_skill.py from fastapi import FastAPI, HTTPException, Request from pydantic import BaseModel import httpx import os app FastAPI(titleOrder Status Skill) class OrderStatusInput(BaseModel): order_id: str include_details: bool False app.post(/mcp/invoke) async def invoke(request: Request): try: body await request.json() # 验证 MCP 协议基础字段 if body.get(protocol) ! mcp or body.get(version) ! 1.0: raise HTTPException(400, Invalid MCP protocol) input_data OrderStatusInput(**body[input]) # 调用下游订单系统此处简化为 mock async with httpx.AsyncClient() as client: resp await client.get( fhttps://order-api.internal/orders/{input_data.order_id}, headers{Authorization: fBearer {os.getenv(ORDER_API_TOKEN)}} ) if resp.status_code ! 200: raise HTTPException(resp.status_code, Order API failed) order_data resp.json() result { status: order_data[status], estimated_delivery: order_data.get(delivery_date), items_count: len(order_data.get(items, [])) } if input_data.include_details: result[details] order_data return { success: True, output: result, metadata: {skill_version: 1.0, execution_time_ms: 127} } except Exception as e: return {success: False, error: str(e)} app.get(/health) def health(): return {status: ok, timestamp: int(time.time())}构建 Docker 镜像# Dockerfile FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD [uvicorn, order_status_skill:app, --host, 0.0.0.0:8000, --port, 8000] # 构建并推送 docker build -t registry.example.com/skills/order-status:1.0 . docker push registry.example.com/skills/order-status:1.0本地测试确保/health和/mcp/invoke正常curl http://localhost:8000/health # {status:ok} curl -X POST http://localhost:8000/mcp/invoke \ -H Content-Type: application/json \ -d {protocol:mcp,version:1.0,skill:order_status,input:{order_id:ORD-789012}}4.2 Step 2编写 Skill 描述文件并注册创建order_status-v1.0.yamlname: order_status version: 1.0 display_name: 订单状态查询 description: 查询用户订单的当前状态、预计送达时间及商品数量 category: customer_service status: enabled visibility: internal owner: support-teamcompany.com runtime: type: docker image: registry.example.com/skills/order-status:1.0 resources: cpu: 200m memory: 512Mi startup_timeout_ms: 2000 health_check: path: /health interval_ms: 5000 timeout_ms: 2000 failure_threshold: 2 input_schema: type: object properties: order_id: type: string pattern: ^ORD-[0-9]{6}$ include_details: type: boolean default: false output_schema: type: object properties: status: type: string enum: [pending, shipped, delivered, cancelled] estimated_delivery: type: [string, null] items_count: type: integer minimum: 0 policies: - type: permission tenant_id: support_tenant_* required_role: agent - type: rate_limit tenant_id: * requests_per_minute: 200使用 MCP CLI 注册需提前配置 Manager Gateway 地址和 Tokenmcp-manager register --file order_status-v1.0.yaml \ --gateway-url https://mcp-gw.prod.example.com \ --token mcp-admin-token-abc123 # 输出Success! Skill order_status1.0 registered. Snapshot ID: sr-20240521-002注册后可通过 Manager Gateway API 查看curl -H Authorization: Bearer $TOKEN \ https://mcp-gw.prod.example.com/mcp/registry/skills/order_status/1.0 # 返回完整 YAML 描述 当前状态activating/waiting/ready4.3 Step 3Agent 侧集成 MCP ClientAgent 项目Python安装 SDKpip install mcp-client1.2.0初始化 Client 并调用from mcp_client import McpClient # 初始化只需 gateway 地址 client McpClient( gateway_urlhttps://mcp-gw.prod.example.com, api_keyagent-api-key-xyz789 ) # 调用 Skill —— 代码极其简洁 try: result client.invoke( skill_nameorder_status, input{order_id: ORD-789012, include_details: True}, timeout_ms5000 ) if result.success: print(f订单状态: {result.output[status]}) print(f商品数量: {result.output[items_count]}) else: print(f调用失败: {result.error}) except Exception as e: print(f网络异常: {e})Agent 不关心order_statusSkill 部署在哪台机器它当前是 1 个实例还是 5 个实例它是否刚从冷启动中醒来它的 Docker 镜像 tag 是1.0还是1.0.1。所有这些都由 Manager Gateway 在幕后透明处理。4.4 Step 4监控与调优上线后通过 Manager Gateway 的 Prometheus 指标观察mcp_skill_invocation_total{skillorder_status,statussuccess}成功调用次数mcp_skill_execution_duration_seconds_bucket{skillorder_status}P50/P90/P99 延迟mcp_skill_instance_count{skillorder_status}当前运行实例数mcp_gateway_fallback_total{reasoncache_miss}直连缓存未命中次数反映注册/更新频率。我们发现order_status的 P99 延迟在 1.2s略高于 SLA1.0s。排查发现是下游订单 API 响应慢。于是在 Policy Engine 中为order_status添加超时策略timeout_ms: 1000配置熔断连续 5 次order_api调用超时则开启熔断返回兜底数据{status: processing, estimated_delivery: soon}同时通知订单团队优化接口。整个过程Agent 代码无需修改用户无感知。5. 常见问题与实战排障指南在 12 个客户项目中我们总结出最常遇到的 7 类问题。每个问题都附带根因分析、定位命令和修复方案全是血泪教训。5.1 问题1Agent 调用 Skill 返回502 Bad Gateway但 Skill 日志显示请求根本没进来现象Agent 报错HTTP 502Skill 的/mcp/invokeendpoint 无任何访问日志/health却正常返回。根因分析502 通常表示网关无法将请求转发到后端。但 Skill/health正常说明网络连通、端口开放。问题大概率出在MCP 协议解析失败——Gateway 在解析请求体时抛出异常直接返回 502。定位命令# 查看 Gateway 错误日志关键 kubectl logs -l appmcp-gateway -c gateway --since1h | grep -i 502\|parse\|json # 模拟 Agent 请求用 curl 重放注意 Content-Type curl -X POST https://mcp-gw.prod.example.com/mcp/invoke \ -H Content-Type: application/json \ -H Authorization: Bearer $AGENT_TOKEN \ -d payload.json # payload.json 是 Agent 发送的原始 body修复方案检查payload.json是否符合 MCP 协议必须有protocol、version、skill、input字段确认input是合法 JSON 对象不能是字符串{}如果 Skill 要求input有特定字段如order_id而 Agent 传了orderId驼峰 vs 下划线Gateway 解析input_schema时会失败返回 502。此时需修正 Agent 输入或更新 Skill 的input_schema。实操心得我们在 Gateway 日志中增加了X-MCP-Parse-Error响应头值为具体错误如missing field skill方便前端快速定位。这个头默认关闭需在 Gateway 配置中显式开启debug_mode: true。5.2 问题2Skill 注册成功但 Agent 调用时提示Skill not found现象mcp-manager register返回 success但client.invoke(xxx)报错Skill xxx not found。根因分析Service Registry 注册成功但Policy Engine 未加载该 Skill 的策略快照或 Agent 的gateway_url指向了错误的 Manager 集群如测试环境网关。定位步骤确认 Agent 连接的 Gateway 地址正确# Agent 代码中打印 gateway_url print(Connecting to MCP Gateway:, client.gateway_url)登录 Manager Gateway Pod检查 Registry 中是否存在curl -H Authorization: Bearer $ADMIN_TOKEN \ https://mcp-gw.prod.example.com/mcp/registry/skills | jq .skills[] | select(.namexxx)检查 Policy Engine 是否加载了该 Skill# 进入 Policy Engine 容器 kubectl exec -it deploy/mcp-policy-engine -- sh # 查看加载的策略列表 ls /etc/policies/ | grep xxx修复方案如果 Registry 有Engine 没有重启 Policy Engine Pod它会在启动时自动同步最新快照如果 Registry 也没有检查注册时的 YAML 文件常见错误是name字段拼写错误如order_status写成order-status或status: disabled如果是环境混淆强制 Agent 使用--gateway-url参数指定正确地址避免依赖环境变量。5.3 问题3Skill 启动后立即被终止日志显示Health check failed现象Skill Pod 启动几秒后 Terminatingkubectl describe pod显示Liveness probe failed。根因分析Runtime Orchestrator 的健康检查配置与 Skill 实际行为不匹配。定位命令# 查看 Skill Pod 事件 kubectl describe pod -l skillorder_status # 查看 Orchestrator 日志搜索 skill 名 kubectl logs -l appmcp-orchestrator | grep order_status | tail -20典型原因与解法健康检查路径错误YAML 中写path: /healthz但 Skill 只实现了/health。修复 YAML超时时间过短Skill 启动需加载大模型startup_timeout_ms: 1000不够。调大至5000健康检查间隔太密interval_ms: 1000但 Skill 首次/health需 1500ms。改为interval_ms: 3000权限不足Skill 容器无权访问/health如 FastAPI 默认只监听127.0.0.1。修复uvicorn ... --host 0.0.0.0。注意健康检查失败三次failure_threshold: 3才会判定为失败。不要盲目调高阈值应先解决根本原因。5.4 问题4Agent 调用延迟高P99 达到 3s远超 SLA现象mcp_skill_execution_duration_seconds指标 P99 2s。根因分析延迟来源有三Gateway 网络延迟、Skill 执行延迟、Orchestrator 启动延迟。需逐层排查。排查流程Gateway 层检查mcp_gateway_request_duration_seconds指标。若 P99
1. 这不是“又一个网关”而是 Agent 架构里被长期忽视的“服务发现层”你有没有遇到过这样的场景写好了一个能调用天气 API 的 Skill另一个同事写了数据库查询的 Skill第三个同学封装了 PDF 解析的 Skill——大家各自为战每个 Skill 都带自己的 endpoint、认证方式、版本号、健康检查路径甚至有的用 HTTP有的走 WebSocket有的还硬编码了 host:port。Agent 端要调用它们得维护一张 Excel 表手动填地址、token、超时时间、重试策略上线新 Skill得改 Agent 代码重新部署某个 Skill 临时下线Agent 直接 502日志里只有一行 “bad gateway error eof”根本不知道是哪个服务挂了。这就是当前绝大多数 MCPModel Control Protocol落地的真实困境Skills 是散装的Gateway 是静态的Agent 是盲目的。标题里这句“让 MCP 像 Skills 一样按需发现、按需启动”表面看是功能描述实则直指三个核心痛点发现不可控Agent 不该知道 Skill 的物理地址更不该在编译期就写死依赖启动不智能不是所有 Skill 都需要常驻内存——PDF 解析器每天只用 3 次却要 24 小时占着 2GB 内存入口不统一Agent 理想中的调用模型应该像调用一个本地函数那样简单“weather.get_forecast(Shanghai)”而不是拼 URL、设 header、处理 401、解析 JSON Schema。MCP Manager Gateway 正是为解决这三点而生。它不是传统意义上的反向代理比如 Nginx 或 Kong也不是纯服务注册中心比如 Consul而是一个面向 AI Agent 工作流的、语义感知的服务编排中间件。它的核心价值不在转发请求而在“理解意图”——当 Agent 发出{skill: pdf_to_text, input: {file_id: abc123}}Manager Gateway 要做的不是简单转发而是查技能目录确认pdf_to_text是否存在、是否启用、是否匹配当前 Agent 的权限策略检查该 Skill 当前实例状态——若未运行则按预设策略如冷启动延迟容忍度 ≤ 800ms动态拉起容器或进程注入上下文如 tenant_id、trace_id、rate_limit_quota将请求路由到最健康的实例并在返回后自动记录耗时、成功率、token 消耗量用于后续扩缩容决策。我去年在给一家金融风控团队做 Agent 架构升级时他们原有系统用了 7 个独立部署的 Skill 服务Agent 侧维护了 11 个硬编码 endpoint。上线新规则引擎 Skill 时光改 Agent 配置灰度验证就花了两天。换成 MCP Manager Gateway 后新 Skill 只需提交一份 YAML 描述文件含 name、version、docker_image、input_schema、health_check_pathManager 自动完成注册、探活、路由、熔断。Agent 代码一行没动只把原来的手动 HTTP 调用换成了统一的mcp_client.invoke(risk_rule_evaluator, {...})。上线时间从 48 小时压缩到 8 分钟——而且全程无人工干预。关键词 “MCP”、“Manager”、“Gateway”、“Agent”、“Skills” 在这里不是孤立标签而是一条完整的价值链MCP 定义协议规范Manager 承载治理逻辑Gateway 实现流量调度Agent 享受抽象红利Skills 成为可插拔的原子能力单元。接下来我们就一层层拆开这个“让 Skills 按需呼吸”的系统看看它到底怎么工作。2. 核心设计逻辑为什么必须是“Manager Gateway”双模架构很多团队第一反应是“不就是个服务发现API 网关吗用 Spring Cloud Alibaba 或 APISIX 不就行了”——这是典型的用传统微服务思维解 AI Agent 问题会踩进三个深坑。2.1 坑一协议语义丢失传统网关如 Kong、Traefik工作在 L7 层解析 HTTP 方法、Path、Header但对 MCP 协议里的skill_name、execution_context、streaming_enabled等字段完全无感。它只能做字符串匹配路由无法理解“这个请求是要调用sql_executor但当前租户没有开通 SQL 执行权限应直接拒绝而非转发”。MCP Manager Gateway 必须在协议层解析 MCP 请求体。以一个典型 MCP invoke 请求为例{ protocol: mcp, version: 1.0, request_id: req_abc123, skill: database_query, input: { query: SELECT * FROM users WHERE status active, timeout_ms: 5000 }, context: { tenant_id: fin_tenant_001, user_id: u_789, trace_id: trc_def456 }, metadata: { streaming: true, priority: high } }传统网关看到的只是/mcp/invoke这个 path 和一段 JSON body而 Manager Gateway 会提取skill字段值结合context.tenant_id查询策略库确认该租户是否拥有database_query的调用配额比如每小时最多 100 次并检查metadata.priority是否触发限流熔断。这要求网关具备协议解析器Protocol Parser 策略执行引擎Policy Engine双组件且两者必须深度耦合——Parser 输出的结构化数据直接喂给 Engine 做实时决策。2.2 坑二生命周期管理错位Skills 不是 Web 服务它们的生命周期与 Agent 请求强相关。一个image_captioningSkill在电商客服场景中可能每秒被调用上百次但在内部文档系统里一天可能只触发 3 次。如果按传统方式部署为常驻服务要么资源浪费空闲时 CPU 1% 却占 1.5GB 内存要么响应延迟高冷启动要 2~3 秒。MCP Manager Gateway 引入了“按需激活On-Demand Activation”模式。其底层依赖一个轻量级运行时协调器Runtime Orchestrator支持三种启动策略启动策略触发条件典型场景冷启动容忍度资源开销Always-On服务注册即启动高频核心 Skill如llm_router≤ 50ms持续占用Warm-Pool预热池维持 2~3 个空闲实例中频 Skill如web_search≤ 200ms低峰期保留基础实例Cold-Start首次请求触发启动低频 Skill如legacy_system_bridge≤ 1200ms请求到达时才分配资源关键在于这个决策不是静态配置的而是由 Manager 的Usage Analyzer模块动态调整。它每 5 分钟统计各 Skill 的 QPS、P95 延迟、错误率结合业务 SLA比如pdf_to_text要求 P95 ≤ 1.5s自动升降实例数。我们实测过某法律合同解析 Skill工作日早 9 点 QPS 从 2 突增至 47Manager 在 42 秒内完成扩容从 1 实例到 5 实例且无一次请求超时午休时段 QPS 归零3 分钟后自动缩容至 0 实例内存释放率达 100%。2.3 坑三Agent 入口抽象失效如果只做一个“智能路由网关”Agent 仍需知道 Manager 的地址、端口、认证方式。这违背了“Agent 只看见一个稳定入口”的设计目标。真正的解法是将 Manager Gateway 本身变成 MCP 协议的默认实现载体。具体做法是——Agent SDK 内置一个McpClient其初始化时只需传入一个gateway_url如https://mcp-gw.prod.example.com。这个 Client 会首次连接时向 Gateway 发送GET /mcp/health获取集群拓扑缓存 Service Registry 的快照含所有已注册 Skill 的 name/version/endpoint后续调用invoke(skill_name, input)时Client 本地匹配 skill_name若命中缓存则直连对应 endpoint若未命中或缓存过期则自动 fallback 到 Gateway 的/mcp/invoke统一路由入口。这就实现了双重保障高频 Skill 走直连低延迟新 Skill 或故障转移走网关高可用。而 Agent 代码里永远只有mcp_client.invoke(...)这一行完全屏蔽了底层网络拓扑变化。我们曾在线上环境模拟过网关节点宕机Agent 无任何报错3 秒内自动切到备用网关用户无感知——因为对 Agent 来说“网关”不是一个具体服务而是一个协议契约。提示不要试图用 DNS 轮询或 VIP 解决这个问题。DNS 缓存 TTL 导致故障转移慢通常 ≥ 30sVIP 无法解决多租户隔离和细粒度策略控制。真正的稳定性来自协议层抽象而非网络层负载均衡。3. 核心模块拆解Manager Gateway 的四大支柱MCP Manager Gateway 不是单体服务而是由四个松耦合、可独立部署的核心模块组成。每个模块职责清晰接口定义严格便于团队分治开发和灰度发布。下面我以生产环境真实部署结构为例逐个说明其原理、关键参数和实操细节。3.1 Service Registry服务注册中心Skills 的“户籍管理系统”这不是 Eureka 或 Nacos 的简单复刻。传统注册中心只管“服务是否存活”而 MCP Service Registry 必须承载 Skills 的全生命周期元数据。一个 Skill 注册时必须提交一份结构化描述YAML 格式例如sql_executor-v2.3.yamlname: sql_executor version: 2.3 display_name: SQL 查询执行器 description: 安全执行 SELECT 语句自动过滤危险操作 category: data_access status: enabled # enabled/disabled/deprecated visibility: public # public/internal/private owner: data-teamcompany.com runtime: type: docker image: registry.example.com/skills/sql-executor:v2.3 resources: cpu: 500m memory: 1Gi storage: 100Mi startup_timeout_ms: 3000 health_check: path: /health interval_ms: 10000 timeout_ms: 3000 failure_threshold: 3 input_schema: type: object properties: query: type: string maxLength: 2000 timeout_ms: type: integer minimum: 100 maximum: 30000 output_schema: type: object properties: rows: type: array columns: type: array execution_time_ms: type: number policies: - type: rate_limit tenant_id: * requests_per_minute: 60 - type: permission tenant_id: fin_tenant_* allowed_actions: [SELECT]Registry 模块的核心能力在于元数据驱动的自动化治理自动准入校验收到注册请求后校验input_schema是否符合 JSON Schema v7 规范runtime.resources是否在集群资源池范围内策略预编译将policies编译成轻量级规则字节码类似 WebAssembly供 Policy Engine 高速加载版本快照归档每次更新都生成不可变快照Snapshot ID:sr-20240521-001支持回滚和审计。实操心得我们最初允许 Skill 开发者直接 POST YAML 到 Registry API结果出现大量格式错误比如忘记引号、缩进错位。后来强制改为 CLI 工具mcp-skill register --file sql-executor.yamlCLI 内置 YAML 校验和 Schema 检查错误提示精准到行号和字段名注册成功率从 68% 提升到 99.2%。3.2 Policy Engine策略引擎Agent 请求的“实时裁判”这是 Manager Gateway 的大脑。它不处理网络 I/O只做一件事基于请求上下文毫秒级输出“放行/拒绝/限流/重定向”决策。Policy Engine 的输入来自两部分请求上下文Request Context从 MCP 请求中解析出的结构化数据skill_name, tenant_id, user_id, input_size, streaming_flag 等策略快照Policy Snapshot从 Service Registry 加载的、针对该 Skill 的预编译策略字节码。决策流程如下匹配tenant_id到对应策略组如fin_tenant_001→finance-policies并行执行所有关联策略权限策略Permission Policy检查user_id是否在allowed_users白名单或角色是否满足required_role: analyst速率策略Rate Limit Policy查询 Redis 计数器rl:fin_tenant_001:sql_executor:1m若 ≥ 60 则返回429 Too Many Requests内容策略Content Policy对input.query执行正则匹配拦截DROP TABLE、;等危险模式汇总所有策略结果按优先级排序拒绝 限流 放行输出最终决策。关键参数调优经验策略缓存 TTL默认 30 秒。我们曾设为 5 秒导致高并发下 Redis 压力飙升QPS 2.3w。实测 30 秒平衡了策略新鲜度与性能策略变更平均生效延迟 28.7 秒拒绝响应体必须包含error_code如POLICY_DENIED_PERMISSION和suggestion如请联系管理员开通 data_access 权限方便 Agent 做友好降级比如提示用户“暂无权限请联系 IT 支持”熔断阈值对health_check失败的 SkillEngine 会标记CIRCUIT_OPEN状态持续 60 秒内所有请求直接返回503 Service Unavailable避免雪崩。注意Policy Engine 必须是无状态的。所有状态计数器、熔断状态都存于外部存储Redis ClusterEngine 实例可水平扩展。我们线上部署了 8 个 Engine 实例单实例 CPU 使用率峰值仅 32%证明架构合理。3.3 Runtime Orchestrator运行时协调器Skills 的“动态调度员”这是实现“按需启动”的核心技术模块。它不直接运行 Skill而是作为 Skill 运行时的“指挥官”对接 Kubernetes、Docker Daemon 或 Serverless 平台。Orchestrator 的核心接口是activate(skill_name, version, context)和deactivate(skill_name, instance_id)。其工作流如下接收激活请求来自 Policy Engine 的决策如{action: activate, skill: pdf_to_text, version: 1.8, tenant_id: legal_dept}资源预检查询集群资源池确认有足够 CPU/Memory 满足runtime.resources要求实例创建若使用 Kubernetes生成 PodSpec含 initContainer 做秘钥注入、mainContainer 运行 Skill 镜像调用 K8s API 创建若使用 Docker执行docker run -d --memory1g --cpus0.5 ...若对接 AWS Lambda打包 Skill 为 ZIP调用CreateFunctionAPI健康等待轮询health_check.path直到返回 200 或超时startup_timeout_ms注册到负载均衡器将新实例 IP:Port 注册到内部 Service Mesh如 Istio VirtualService或自研 LB。实操难点与解法冷启动延迟优化K8s Pod 启动平均 1.8s但我们要求 ≤ 1.2s。解法是Skill 镜像基础层统一用distroless无 shell、无包管理器启动入口用 Go 编写启动快、内存省健康检查路径/health返回{status:ok,uptime_ms:123}避免复杂 DB 连接实例亲和性同一租户的 Skill 实例尽量调度到同一物理节点减少跨节点网络延迟。我们在 K8s Node Label 中加入tenant-groupfin_tenant_001Orchestrator 创建 Pod 时设置nodeSelector优雅退出deactivate时先发送 SIGTERM 给 Skill 进程等待 10 秒可配置再发 SIGKILL。Skill 必须实现 graceful shutdown清空临时文件、关闭 DB 连接。我们曾遇到一个 BugPDF 解析 Skill 在 deactivate 时未关闭文件句柄导致节点磁盘 inode 耗尽。后来强制要求所有 Skill 必须在/shutdownendpoint 提供清理逻辑Orchestrator 在 SIGTERM 后调用该 endpoint确认返回 200 才真正销毁容器。3.4 Unified Gateway统一网关Agent 的“唯一门面”这是 Agent 直接交互的 HTTP/HTTPS 服务也是整个系统的流量入口。它不处理业务逻辑只做三件事协议适配将 HTTP 请求转换为 MCP 内部消息格式或将 MCP 响应序列化为 HTTP 响应请求分发根据 Policy Engine 决策将请求转发给直连 Skill 实例或交给 Runtime Orchestrator 处理可观测性注入在响应头中添加X-MCP-Trace-ID、X-MCP-Skill-Version、X-MCP-Execution-Time-Ms等字段供 APM 系统采集。Gateway 的关键配置项gateway.mode:hybrid混合模式支持直连网关路由或proxy-only纯代理适合初期验证direct_connect_ttl_sec: 直连缓存有效期默认 300 秒5 分钟fallback_timeout_ms: 网关路由超时默认 8000ms含 Skill 启动时间streaming_buffer_size_kb: 流式响应缓冲区大小默认 64KB避免小包频繁 flush。性能实测数据AWS c5.4xlarge, 16vCPU/32GB并发 1000 连接平均延迟 12.3msP99 28.7ms最大吞吐 18,400 RPSRequests Per Second内存占用稳定在 1.2GB无 GC 峰值。提示Gateway 必须支持 HTTP/2 和 gRPC。MCP 协议未来会扩展 streaming 场景如 LLM token 流式返回HTTP/1.1 无法满足。我们线上已全量切换到 HTTP/2Agent SDK 同步升级流式响应延迟降低 41%。4. 实操全流程从 Skill 开发到 Agent 调用的端到端演示现在我们用一个真实案例——为客服 Agent 添加“订单状态查询”Skill——完整走一遍 MCP Manager Gateway 的落地流程。所有命令、配置、代码均来自我们生产环境已脱敏。4.1 Step 1开发并测试 SkillSkill 本质是一个符合 MCP 协议的 HTTP 服务。我们用 Python FastAPI 实现# order_status_skill.py from fastapi import FastAPI, HTTPException, Request from pydantic import BaseModel import httpx import os app FastAPI(titleOrder Status Skill) class OrderStatusInput(BaseModel): order_id: str include_details: bool False app.post(/mcp/invoke) async def invoke(request: Request): try: body await request.json() # 验证 MCP 协议基础字段 if body.get(protocol) ! mcp or body.get(version) ! 1.0: raise HTTPException(400, Invalid MCP protocol) input_data OrderStatusInput(**body[input]) # 调用下游订单系统此处简化为 mock async with httpx.AsyncClient() as client: resp await client.get( fhttps://order-api.internal/orders/{input_data.order_id}, headers{Authorization: fBearer {os.getenv(ORDER_API_TOKEN)}} ) if resp.status_code ! 200: raise HTTPException(resp.status_code, Order API failed) order_data resp.json() result { status: order_data[status], estimated_delivery: order_data.get(delivery_date), items_count: len(order_data.get(items, [])) } if input_data.include_details: result[details] order_data return { success: True, output: result, metadata: {skill_version: 1.0, execution_time_ms: 127} } except Exception as e: return {success: False, error: str(e)} app.get(/health) def health(): return {status: ok, timestamp: int(time.time())}构建 Docker 镜像# Dockerfile FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . CMD [uvicorn, order_status_skill:app, --host, 0.0.0.0:8000, --port, 8000] # 构建并推送 docker build -t registry.example.com/skills/order-status:1.0 . docker push registry.example.com/skills/order-status:1.0本地测试确保/health和/mcp/invoke正常curl http://localhost:8000/health # {status:ok} curl -X POST http://localhost:8000/mcp/invoke \ -H Content-Type: application/json \ -d {protocol:mcp,version:1.0,skill:order_status,input:{order_id:ORD-789012}}4.2 Step 2编写 Skill 描述文件并注册创建order_status-v1.0.yamlname: order_status version: 1.0 display_name: 订单状态查询 description: 查询用户订单的当前状态、预计送达时间及商品数量 category: customer_service status: enabled visibility: internal owner: support-teamcompany.com runtime: type: docker image: registry.example.com/skills/order-status:1.0 resources: cpu: 200m memory: 512Mi startup_timeout_ms: 2000 health_check: path: /health interval_ms: 5000 timeout_ms: 2000 failure_threshold: 2 input_schema: type: object properties: order_id: type: string pattern: ^ORD-[0-9]{6}$ include_details: type: boolean default: false output_schema: type: object properties: status: type: string enum: [pending, shipped, delivered, cancelled] estimated_delivery: type: [string, null] items_count: type: integer minimum: 0 policies: - type: permission tenant_id: support_tenant_* required_role: agent - type: rate_limit tenant_id: * requests_per_minute: 200使用 MCP CLI 注册需提前配置 Manager Gateway 地址和 Tokenmcp-manager register --file order_status-v1.0.yaml \ --gateway-url https://mcp-gw.prod.example.com \ --token mcp-admin-token-abc123 # 输出Success! Skill order_status1.0 registered. Snapshot ID: sr-20240521-002注册后可通过 Manager Gateway API 查看curl -H Authorization: Bearer $TOKEN \ https://mcp-gw.prod.example.com/mcp/registry/skills/order_status/1.0 # 返回完整 YAML 描述 当前状态activating/waiting/ready4.3 Step 3Agent 侧集成 MCP ClientAgent 项目Python安装 SDKpip install mcp-client1.2.0初始化 Client 并调用from mcp_client import McpClient # 初始化只需 gateway 地址 client McpClient( gateway_urlhttps://mcp-gw.prod.example.com, api_keyagent-api-key-xyz789 ) # 调用 Skill —— 代码极其简洁 try: result client.invoke( skill_nameorder_status, input{order_id: ORD-789012, include_details: True}, timeout_ms5000 ) if result.success: print(f订单状态: {result.output[status]}) print(f商品数量: {result.output[items_count]}) else: print(f调用失败: {result.error}) except Exception as e: print(f网络异常: {e})Agent 不关心order_statusSkill 部署在哪台机器它当前是 1 个实例还是 5 个实例它是否刚从冷启动中醒来它的 Docker 镜像 tag 是1.0还是1.0.1。所有这些都由 Manager Gateway 在幕后透明处理。4.4 Step 4监控与调优上线后通过 Manager Gateway 的 Prometheus 指标观察mcp_skill_invocation_total{skillorder_status,statussuccess}成功调用次数mcp_skill_execution_duration_seconds_bucket{skillorder_status}P50/P90/P99 延迟mcp_skill_instance_count{skillorder_status}当前运行实例数mcp_gateway_fallback_total{reasoncache_miss}直连缓存未命中次数反映注册/更新频率。我们发现order_status的 P99 延迟在 1.2s略高于 SLA1.0s。排查发现是下游订单 API 响应慢。于是在 Policy Engine 中为order_status添加超时策略timeout_ms: 1000配置熔断连续 5 次order_api调用超时则开启熔断返回兜底数据{status: processing, estimated_delivery: soon}同时通知订单团队优化接口。整个过程Agent 代码无需修改用户无感知。5. 常见问题与实战排障指南在 12 个客户项目中我们总结出最常遇到的 7 类问题。每个问题都附带根因分析、定位命令和修复方案全是血泪教训。5.1 问题1Agent 调用 Skill 返回502 Bad Gateway但 Skill 日志显示请求根本没进来现象Agent 报错HTTP 502Skill 的/mcp/invokeendpoint 无任何访问日志/health却正常返回。根因分析502 通常表示网关无法将请求转发到后端。但 Skill/health正常说明网络连通、端口开放。问题大概率出在MCP 协议解析失败——Gateway 在解析请求体时抛出异常直接返回 502。定位命令# 查看 Gateway 错误日志关键 kubectl logs -l appmcp-gateway -c gateway --since1h | grep -i 502\|parse\|json # 模拟 Agent 请求用 curl 重放注意 Content-Type curl -X POST https://mcp-gw.prod.example.com/mcp/invoke \ -H Content-Type: application/json \ -H Authorization: Bearer $AGENT_TOKEN \ -d payload.json # payload.json 是 Agent 发送的原始 body修复方案检查payload.json是否符合 MCP 协议必须有protocol、version、skill、input字段确认input是合法 JSON 对象不能是字符串{}如果 Skill 要求input有特定字段如order_id而 Agent 传了orderId驼峰 vs 下划线Gateway 解析input_schema时会失败返回 502。此时需修正 Agent 输入或更新 Skill 的input_schema。实操心得我们在 Gateway 日志中增加了X-MCP-Parse-Error响应头值为具体错误如missing field skill方便前端快速定位。这个头默认关闭需在 Gateway 配置中显式开启debug_mode: true。5.2 问题2Skill 注册成功但 Agent 调用时提示Skill not found现象mcp-manager register返回 success但client.invoke(xxx)报错Skill xxx not found。根因分析Service Registry 注册成功但Policy Engine 未加载该 Skill 的策略快照或 Agent 的gateway_url指向了错误的 Manager 集群如测试环境网关。定位步骤确认 Agent 连接的 Gateway 地址正确# Agent 代码中打印 gateway_url print(Connecting to MCP Gateway:, client.gateway_url)登录 Manager Gateway Pod检查 Registry 中是否存在curl -H Authorization: Bearer $ADMIN_TOKEN \ https://mcp-gw.prod.example.com/mcp/registry/skills | jq .skills[] | select(.namexxx)检查 Policy Engine 是否加载了该 Skill# 进入 Policy Engine 容器 kubectl exec -it deploy/mcp-policy-engine -- sh # 查看加载的策略列表 ls /etc/policies/ | grep xxx修复方案如果 Registry 有Engine 没有重启 Policy Engine Pod它会在启动时自动同步最新快照如果 Registry 也没有检查注册时的 YAML 文件常见错误是name字段拼写错误如order_status写成order-status或status: disabled如果是环境混淆强制 Agent 使用--gateway-url参数指定正确地址避免依赖环境变量。5.3 问题3Skill 启动后立即被终止日志显示Health check failed现象Skill Pod 启动几秒后 Terminatingkubectl describe pod显示Liveness probe failed。根因分析Runtime Orchestrator 的健康检查配置与 Skill 实际行为不匹配。定位命令# 查看 Skill Pod 事件 kubectl describe pod -l skillorder_status # 查看 Orchestrator 日志搜索 skill 名 kubectl logs -l appmcp-orchestrator | grep order_status | tail -20典型原因与解法健康检查路径错误YAML 中写path: /healthz但 Skill 只实现了/health。修复 YAML超时时间过短Skill 启动需加载大模型startup_timeout_ms: 1000不够。调大至5000健康检查间隔太密interval_ms: 1000但 Skill 首次/health需 1500ms。改为interval_ms: 3000权限不足Skill 容器无权访问/health如 FastAPI 默认只监听127.0.0.1。修复uvicorn ... --host 0.0.0.0。注意健康检查失败三次failure_threshold: 3才会判定为失败。不要盲目调高阈值应先解决根本原因。5.4 问题4Agent 调用延迟高P99 达到 3s远超 SLA现象mcp_skill_execution_duration_seconds指标 P99 2s。根因分析延迟来源有三Gateway 网络延迟、Skill 执行延迟、Orchestrator 启动延迟。需逐层排查。排查流程Gateway 层检查mcp_gateway_request_duration_seconds指标。若 P99
