[控场AI]
· 5 分钟阅读· 2,961 字

Executor:一层统一管理多个Coding Agent的MCP代理

Executor:一层统一管理多个Coding Agent的MCP代理

Executor 是一个开源统一 MCP 代理层,让多个 Coding Agent 共享同一份工具配置与认证。

Executor 是一个开源工具,专为同时使用多个 Coding Agent(如 Claude Code、Codex 等)的开发者而设计。它在各 Agent 与外部服务之间插入一层统一代理,所有 MCP Server、OpenAPI、GraphQL 及 Google Discovery 接口只需在 Executor 中配置一次,Agent 侧只需指向 Executor 这一个入口,实现「一次认证、处处可用」。Executor 还提供三档权限策略(始终允许、审批后执行、直接屏蔽),并能根据接口规范自动推导默认策略。部署方式灵活,支持本地 CLI、桌面客户端、官方云服务及 Docker/Cloudflare Worker 自托管,仅需 Node.js 20+ 即可安装,整体上手门槛较低。

如果你同时在使用多个 Coding Agent,大概率遇到过这样的困扰:Claude Code 里配一份 MCP,Codex 里配一份,PyAgent、OpenClaw 又各要一份。同一个 Context Key、同一个 API Key 前前后后要粘贴三四遍。哪天密钥过期了,还得翻遍好几个配置文件逐个修改;想新增一个 MCP Server,也要在每个 Agent 里重复添加。

开源项目 Executor 正是为了解决这一痛点而生。据 B站 UP 主 EV 的介绍,Executor 可以一句话概括为:一层架在多个 Agent 与外部世界之间的统一代理层,本质上是一个集中式的 MCP 管理配置工具。

从「各管各的」到「统一入口」

传统结构下,每个 Agent 各自通过 MCP 直连外部服务,认证、密钥、权限全部分散管理,配置动辄重复三四遍。装上 Executor 之后,架构被彻底重构:外部服务只接入 Executor 一处,由它统一完成集成、认证与集中管理;各个 Agent 只需配置 Executor 这一个 MCP 入口,共享同一份工作目录即可。

认证、密钥、权限各管各的

这种设计带来的直接好处是「一次认证,处处可用」。密钥更新时只需改一处,新增服务时也只需在 Executor 里配置一次,所有 Agent 自动共享。

MCP(Model Context Protocol) 是 Anthropic 于 2024 年末提出的开放协议,旨在标准化 AI 模型与外部工具/数据源之间的通信方式。其核心思想类似 USB 接口——工具开发者只需实现一次 MCP Server,任何支持该协议的 Agent 都能直接调用,无需为每个 AI 平台单独适配。随着 Claude Code、OpenAI Codex、Cursor 等主流 Coding Agent 相继支持 MCP,生态扩张迅速,但也带来了多 Agent 环境下配置分散的新问题,Executor 所针对的正是这一痛点。

不只是 MCP,还能接入老服务

Executor 的接入能力并不局限于 MCP Server。它同时支持 OpenAPI、GraphQL 以及 Google Discovery——只要接口能用 JSON Schema 描述出来,Executor 就能把它统一转换成 Agent 可调用的工具。

这意味着许多没有官方 MCP Server、但提供了 OpenAPI 文档定义的老服务,也能被接入进来,直接暴露给 Agent 使用。对于企业内部大量遗留的 REST 服务而言,这是一个相当实用的能力,省去了单独开发 MCP Server 适配层的麻烦。

OpenAPI、GraphQL 与 Google Discovery 是三种主流的 API 接口描述/查询规范。OpenAPI(原 Swagger)是目前最广泛采用的 REST API 描述标准,以 JSON 或 YAML 格式定义接口路径、参数与返回值;GraphQL 是 Facebook 提出的查询语言,允许客户端精确指定所需数据结构;Google Discovery 则是 Google 内部用于描述其云服务 API 的元数据格式,驱动 Google Workspace、Cloud 等大量官方 API。这三种规范的共同点在于都能以机器可读的 JSON Schema 形式描述接口契约,Executor 正是利用这一点将它们统一转换为 Agent 可调用的工具定义,从而无需为每一个老服务单独手写 MCP 适配层。

三档权限:让 Agent 有边界地行动

工具接进来之后是否就无条件开放?答案是否定的。Executor 为每一个工具都提供了独立的策略设置,共分三档权限:

  • 始终允许:适用于查文档、搜资料等只读操作,直接放行;
  • 审批后执行:适用于发邮件、修改数据等有副作用的操作,Agent 调用前会弹窗让用户确认;
  • 直接屏蔽:对于完全不希望 Agent 触碰的工具,可彻底禁用。

发邮件、修改数据这种有副作用的操作需要审批

如果嫌逐个配置麻烦,Executor 还能根据接口规范自动推导默认策略,比如 GET 请求默认设为始终允许。用户可以先跑起来,再逐步收紧策略,兼顾了上手速度和安全边界。

四种运行方式,覆盖个人到团队

Executor 提供了四种执行方式,适配不同的使用规模:

  • 本地 CLI
  • 桌面客户端
  • 托管到 Executor Cloud
  • 自建 Docker 部署 / 托管到 Cloudflare Worker

团队要共同使用一套集成

个人独立使用时,本地 CLI 或桌面客户端就足够;如果有多台设备,或者团队需要共享同一套集成,则可以托管到官方云服务,或自行用 Docker 部署,实现集中管理。

使用流程与安装步骤

Executor 的使用流程可拆成四步:

  1. 添加集成:比如接入一个 MCP Server;
  2. 创建连接:每个连接下的实例都是一份已配置好、认证过的凭据。以 GitHub 为例,可以在同一个集成下配置一个个人账号连接、再配一个工作账号连接;
  3. 设置策略:即前面提到的允许 / 审批 / 屏蔽权限管理;
  4. 接入 Agent:把各个 Agent 的 MCP 指向 Executor,共享同一份工作目录。

使用 BUN 等工具进行安装

本地安装的门槛不高,只需 Node.js 20 以上版本,用 npm 或 bun 等任意包管理工具即可完成。安装后运行 executor install 将其注册为常驻后台服务,再用 executor web 打开网页管理页面,即可在界面上添加集成、创建连接、配置权限策略。

最关键的一步是把 Executor 接入到 Claude Code 等 Agent 中,支持两种方式:HTTP 方式,或 stdio 方式——后者只需在终端运行一条 NPX 命令即可完成。

价值与适用场景

Executor 的核心价值在于,把散落在各个 Agent 里重复的配置收拢成一份集中配置:一次认证、统一管理、权限控制全部集中到一处。对于同时使用两个以上 Coding Agent 的开发者来说,它解决的是一个真实且高频的痛点。

从架构视角看,这类「代理层 / 网关」思路在多 Agent 协作日益普及的当下颇具前瞻性——随着 MCP 生态扩张,如何统一管理凭据、控制权限、复用服务定义,会逐渐成为绕不开的工程问题。Executor 提供了一个开源、可自托管的解法,值得花十分钟安装体验。

分享:

相关推荐