orbitproxy MCP Composer - Virtual MCP 服务解决方案
随着团队使用越来越多的MCP 服务， Virtual MCP Server(虚拟MCP 服务)的概念进入了企业级MCP 解决方案的视野，虚拟MCP 服务通过将多个上游MCP 服务的多个tools 整合到一个统一的控制面板中， 并简化其配置和鉴权流程，为团队解决解决MCP和AI Agent 之间的Context 爆炸以及强耦合关联，本文可以让你了解到虚拟MCP服务是如何工作以及 orbitproxy MCP Composer的相关使用用例
为什么需要Virtual MCP服务
MCP目前在无论是在个人开发者或者创业团队亦或者大型企业，其采用程度都已经迅速飞升，并超越了单开发人员的量级，每个团队会使用大量的外部第三方MCP，如：
- 使用 remote 类型的Github MCP, 企微MCP, 微信支付MCP去快速接入第三方服务商以使用其能力
- 使用Streamable HTTP类型的 clickhouse MCP, kafka MCP, promethus MCP去快速对接内部各类基础设施
- 使用 stdio 类型的Mysql MCP, Docker MCP, Shell MCP去实时调试生产环境 bug 或者快速分析日志数据等
除此之外，每个团队自身的项目也会提供不少MCP能力出去，对一个目前成熟的产研团队或者高效率的个人开发者来说，AI Agent 对接自身项目数十个MCP已经是很常见的事情， 而每个MCP服务又都提供自己的一套tools, 最终每个Agent可能会直连到多个MCP服务， 这其中会带来一些问题：
- 多个MCP服务的直连配置产生MCP配置地狱， 1 个 2 个MCP配起来简单， 但十多个MCP， 每个鉴权都不一样， 其配置风险和难度直线飙升
- 在团队管理中，某个成员的AI Agent实际应该能看到哪些工具？（技术负责人和普通开发人员肯定不可能一视同仁）
- 如何让AI Agent 识别同一环境的多个工具？（如现在有 2 套环境， test 和 prod, 每个环境都有相同的 mysql, docker, clickhouse MCP, 当AI Agent 遇到 2 个Mysql MCP时， 如何快速进行识别和区分？ 在联动排查问题时，又如何让AI Agent 明白哪些mcp是同属于测试环境， 哪些是属于生产环境的？）
- 我们如何才能在各个团队和成员之间一致的配置MCP访问权限呢，以及当我们需要为数十个MCP分别配置其访问权限时是否会觉得力不从心呢？
而MCP虚拟服务解决了其中一些问题， orbitproxy 在此基础上提出了MCP Composer 能力（行业先发）将MCP虚拟服务再进一次， MCP Composer 如开头的架构图一样， 架在MCP 服务和AI Agent 之间， 去起承转合，承上启下
Virtual MCP的定义
Virtual MCP服务（MCP Composer）器允许你创建和组合来自多个上游MCP服务的所有MCP Tools
从AI Agent 角度来说， 每个AI Agent 永远只需要连接一个MCP服务端点，而在Virtual MCP节点上，其背后控制和对接了多个底层MCP服务器， 以及向每个底层MCP服务器拿到了对应的 tools，最终统一返回给AI Agent， 这改变了团队使用和配置MCP的方式， 团队无需将团队中成员的每个客户端连接到多个MCP服务器，而是可以:
- 一次性将所有的上游MCP服务组合到一起，每个成员只需要配置一个统一的访问地址
- 将鉴权以及访问控制由技术负责人或者IT安全部门统一打在这个唯一的访问入口上
- 无论上游MCP进行增加或者删减， 该统一的MCP访问地址无需改变， 访问入口非常稳定
orbitproxy MCP Composer
在上面这种场景下，当MCP服务一多， 则可能会产生成百上千个 tools一次性返回给AI Agent, 极容易造成 tools 上下文爆炸，所以在此基础上， orbitproxy 提出动态MCP 概念，并将其命名为MCP Composer, 其核心定义为:
orbitproxy MCP Composer始终对所有AI Agent 固定提供 3 个MCP Tool
- orbit_search_tool: 按当前要办的事，找出该用哪个 tool
- orbit_get_tool_schemas: 读取这个 tool 的参数说明
- orbit_execute_tool: 发起调用。Composer 转到对应的 MCP，再把结果交回 Agent
比如在 Cursor 里说「查一下订单表今天有多少笔订单」：
- Cursor会先向 orbitproxy MCP Gateway 发送搜索请求，定位到 Mysql 上用来查询的那个 tool。Docker、Shell 这些不会因此被摊进上下文。
- 再读取它的参数说明，知道查询该怎么写。
- 然后执行。Composer 把这次查询交给 Mysql MCP，把结果返回给 Agent。
这种按需读取，动态加载的方式，让AI Agent 无需再一次性被投喂成百个 tools， 而是每次需要用到时根据需求临时检索，提高AI 循环效率。
Virtual MCP Server (MCP Composer)仍需要治理
随着Virtual MCP Server以及更强大的 orbitproxy MCP Composer逐渐成为团队主流选择， 它们自然而然成为了企业使用MCP的最关键的节点，它们位于代理和实际系统之间，聚合来自内部和第三方 MCP 服务器的工具，并通过单一界面将其公开。在这个层面上，访问权限、可见性和安全性等问题比简单的连接性更为重要。
团队需要了解哪些AI Agent可以使用哪些的Virtual MCP，这些工具在实践中是如何被调用的，是否能观测透明， 以及使用情况是否符合预期。如果没有有效的管理，Virtual MCP服务可能会成为另一个盲点——虽然功能强大，但一旦投入生产环境，就难以进行有效的分析。
而 orbitproxy提供了大规模安全运行虚拟 MCP 服务器所需的基础设施。
orbitproxy MCP Gateway充当 MCP 使用的控制平面，使团队能够了解工具调用、延迟和故障情况，同时确保跨环境访问边界的一致性。平台团队无需孤立地管理 MCP 组件，而是可以将虚拟 MCP 服务器视为其更广泛的 AI 平台的一部分，与模型、路由和可观测性等组件并列。
这样一来，就可以在各个团队中推广 MCP，而不会失去控制或增加运营成本。
如果您已经在使用多个 MCP 服务器，那么下一步就是将 MCP 视为平台基础设施。
要了解orbitproxy的 MCP 网关如何帮助团队运行和管理 MCP 服务器， 可参考我们的另一篇推文 ： MCP治理和MCP 网关在团队生产中的实际意义