多 MCP 服务聚合到一个端点的网关架构
当一个团队有多个 MCP Server（内部业务系统、第三方数据服务、语音助手技能库），却只能给助手暴露一个接入点时，聚合网关是最常见的解法。这篇文章讲清它的分层设计：接入层、路由层、治理层，以及上下文渐进披露的实现思路。
接入层：统一端点与协议
聚合网关对外只暴露一个 MCP Server 端点（wss://…/mcp/?token=…），承担协议接入与传输安全。客户端（语音助手、Agent）只需配置这一个 URL；网关负责把不同客户端的会话映射到对应租户，完成鉴权、限流与 TLS。
统一端点的好处是：设备端配置永久稳定，不再随工具数量增长而变动；新增 MCP 服务只是网关内部的事。
路由层：按命名空间分发工具调用
工具名使用「命名空间 + 工具名」的格式（例如 calculator_add、amap_geocode、skills_提醒）。网关维护一张路由表：工具名前缀 → 后端 MCP 服务地址。
收到 tools/call 时，网关先解析前缀找到对应服务，再做参数校验与权限检查，最后以 MCP Client 身份调用后端服务，并把结果透传回语音助手。后端服务的协议细节被完全屏蔽在网关之后。
治理层：配额、审计与热更新
多租户 SaaS 里，治理能力决定了平台能不能规模化。网关在每次调用前检查：该租户当日配额是否用尽、该工具是否被租户停用、调用频率是否超限。
每一次调用（来源、参数、结果状态、耗时）都会写入审计日志，租户管理员可查、平台方可汇总。应用与技能的增删、启停通过配置热更新即时生效，无需重启语音助手或网关进程。
渐进披露：把上下文留给真正的对话
上下文渐进披露（Progressive Disclosure）是语音助手工具编排的关键优化：不把全部工具描述一次性上报，而是按需加载。
典型实现是「两级清单」：连接握手与每次会话开始时，只上报每个技能的一句话简介与触发条件；当模型判断需要某个技能时，网关再动态加载该技能完整指令（SKILL.md），交给模型展开。
效果：几十个技能的场景下，助手每次请求携带的 token 从几万降到几百，首响延迟与成本同步下降，指令更聚焦、误调用更少。