1MCP：一站式 MCP 服务器聚合运行时

当每个 AI 工具都想"接入"你时，问题来了

你正在用 Cursor 写代码，Cursor 配置了一个 MCP 服务器来查 GitHub issues；你的 Claude Code 需要访问文件系统和一个向量数据库；你的团队 Claude Desktop 又配了另一套工具链。三个客户端，三套 MCP 配置，三个不同的认证方式——这是 2025 年初 AI 开发者最真实的"配置地狱"。

更糟糕的是，随着 agent 会话越来越长，进入上下文的工具列表越来越长：20 个工具里 agent 只用了 3 个，但 token 成本和推理时间都在燃烧。这就是 Anthropic 在 2024 年 11 月推出 MCP（Model Context Protocol）之后，整个生态迅速面临的两大挑战——配置碎片化和工具膨胀。

1MCP（One MCP）正是为解决这个问题而生：它是一个统一的 MCP 运行时，将多个 MCP 服务器聚合在一个 1mcp serve 进程后面，同时提供专为 AI agent 设计的渐进式工具发现工作流。

背景：MCP 生态的快速增长与随之而来的复杂度

2024 年底 Anthropic 开源 MCP 后，生态爆发式增长。PulseMCP 目录显示，截至 2026 年中已有超过 17,970 个 MCP 服务器注册，覆盖 GitHub、数据库、浏览器 DevTools、截图生成等几乎所有开发场景。然而这种繁荣带来了现实问题：每个 AI 客户端（Cursor、Claude Desktop、Windsurf 等）都要求独立的 MCP 配置，包括认证凭证、过滤器规则、工具可见性策略等。

开发者 William Xu（GitHub: xuzp，邮箱 xuzp@1mcp.app）从这一痛点出发，构建了 1MCP 作为统一网关。目前项目已有 459 颗 GitHub stars、54 个 forks、Apache-2.0 开源许可，获得了稳定的社区关注。

核心架构：三层入口、一个运行时

1MCP 的架构设计非常清晰，可以用"三层入口、一个核心"来概括。

三层入口是指用户或 AI agent 与 1MCP 交互的三种方式：

第一种是 CLI 模式（推荐给 Codex、Claude Code 等自主 agent 使用），工作流程是 instructions → inspect → run 三步。Agent 通过 1mcp instructions 了解当前运行时状态和推荐流程；通过 1mcp inspect <server> 只发现当前需要的服务器；通过 1mcp run <server>/<tool> --args '<json>' 执行单个工具。这种渐进式发现策略显著缩小了每次 agent 循环中暴露的工具表面。

第二种是 stdio 代理模式（1mcp proxy），为最大兼容性设计。它通过 stdio 传输与 1MCP HTTP 服务通信，保留了 .1mcprc 项目上下文，并支持模板 MCP 服务器。官方推荐 CLI 之后的第二选择。

第三种是 直接 MCP 附件，面向原生支持 MCP HTTP 流的客户端，直接配置 mcpServers 指向 http://127.0.0.1:3050/mcp。

一个核心是指 1mcp serve 这个统一运行时。静态服务器在启动时加载，模板服务器在客户端上下文已知时动态解析（支持按仓库、按分支、按会话区分配置），运行时支持异步加载和懒加载以减少启动阻塞。

关键功能：模板变量、预设与过滤

1MCP 的配置系统非常灵活，核心能力体现在三个方面：

模板变量系统（.1mcprc）支持丰富的上下文插值。项目上下文包括 {project.path}、{project.name}、{project.environment}、Git 信息（分支、commit hash）等；用户上下文包括 {user.username}、{user.email}（来自 git config）、{user.home}；自定义变量由用户在 .1mcprc 的 custom 字段中定义，并通过 {project.custom.*} 引用。这意味着同一个 MCP 服务器配置，在不同项目、不同分支、不同用户下可以解析出完全不同的参数。

预设系统允许保存和复用完整的服务器配置组合。一个预设可以包含多个服务器、过滤规则和指令聚合设置，通过 1mcp preset 系列命令管理。

指令聚合是一个容易被低估的功能。它能够将多个 MCP 服务器提供的 instructions 文本进行聚合，生成统一的上下文说明，帮助 agent 更好地理解整个工具矩阵的边界和能力。

技术栈与代码质量

项目采用 TypeScript + Node.js 构建，使用 pnpm workspaces 管理 monorepo 结构（主包 @1mcp/agent 发布至 npm），主要依赖包括：

• @modelcontextprotocol/sdk：MCP 协议的官方 Node.js 实现
• yargs：命令行参数解析
• express：HTTP 传输层服务器
• vitest：单元测试和 E2E 测试
• eslint + prettier：代码风格检查

源码结构按关注点清晰分层：src/auth/ 处理 OAuth 认证流程和会话管理；src/commands/ 定义所有 CLI 命令（serve、proxy、cli-setup、inspect、instructions、run 等）；src/core/ 实现核心运行时逻辑；src/transport/ 实现 HTTP/STDO 传输层。认证模块尤其完善，支持 OAuth 2.1 授权码流程、Session 管理和多种存储后端。

项目维护质量较高：使用了 Husky pre-commit 钩子进行代码检查和格式化、Dependabot 自动依赖更新、多套 CI 工作流（构建、测试、发布、Docker 镜像）。文档使用 VitePress 构建，有完整的 ADR（Architecture Decision Records）记录重大架构决策。

部署方式：Docker 一键启动，CLI 快速配置

1MCP 提供两条快速部署路径：

Docker 路线（推荐快速体验），一行命令启动：docker compose up -d，默认暴露 3050 端口。docker-compose.yml 中已配置好 npm registry 和 uv Python 包管理器的国内镜像，适合国内网络环境。

npm 全局安装路线（适合深度定制）：

npm install -g @1mcp/agent
1mcp serve

然后在另一个终端运行 CLI 模式连接 agent：

1mcp cli-setup --codex
1mcp inspect context7
1mcp run context7/query-docs --args '{"libraryId":"/mongodb/docs","query":"aggregation pipeline"}'

1MCP 没有 Web UI 界面，它是一个纯后台守护进程工具，通过 HTTP API 与 AI agent 通信。对于想图形化管理配置的用户，当前需要通过命令行或编辑 ~/.config/1mcp/config.toml 和 .1mcprc 文件来实现。

硬件需求极低：不需要 GPU，512MB RAM 即可运行，适合在开发机或小型服务器上长期部署。

局限与争议

1MCP 作为新生项目，也存在一些需要注意的地方。

单点依赖风险：1mcp serve 是所有工具的入口，如果该进程崩溃，所有依赖它的 AI 客户端都会受影响。生产环境需要配置进程管理（如 PM2、systemd）来保证高可用。

OAuth 认证配置复杂：虽然 OAuth 2.1 支持是企业级功能，但配置流程涉及多个回调 URL 和客户端凭证，对个人用户有一定门槛。

生态锁定：1MCP 的 .1mcprc 配置格式是专有的，迁移到其他 MCP 聚合工具（如官方 MCP 客户端）需要重新配置服务器。不过项目本身是 Apache-2.0 开源，不存在供应商锁定。

Web UI 缺失：对于非技术用户来说，纯命令行的配置方式不够友好。社区中已有功能请求希望增加 Web 管理界面。

行业意义与趋势

1MCP 的出现折射出一个明确趋势：MCP 聚合层正在成为 AI 开发工具链的"中间件"。就像 Nginx 作为 Web 服务器的反向代理统一入口，1MCP 正在扮演 AI agent 与 MCP 服务器之间的网关角色。

随着 MCP 协议被 Google Cloud、Accenture 等大厂采纳（MCP-Bench 基准测试已在 ICLR 2026 发表），围绕 MCP 的工具链正在快速成熟。1MCP 的"渐进式工具发现"理念——让 agent 只看到当前任务需要的工具——是一个有前瞻性的设计，它直击大模型上下文窗口有限这一核心瓶颈。

从增长数据看，459 颗 stars 在 MCP 相关项目中属于中等体量，但项目活跃度高（v0.33.0-beta3 版本）、维护积极、文档完善，是值得关注的技术选型。