六大AI编码环境的统一MCP配置方案
论述如何开发一套MCP工具自动适配Claude Code、Cursor、Codex、Gemini CLI、Copilot和Windsurf,消除配置漂移,提升工具跨平台复用。
完整中文译文
掌握跨 Harness 的工具一致性:只需构建一个能够自动适配 Claude Code、Cursor、Codex、Gemini CLI、Copilot 和 Windsurf 的 Model Context Protocol(MCP)工具。消除配置漂移,立即将工具的覆盖范围扩大数倍。
AI 辅助开发中的碎片化问题
使用 AI 编程助手的开发者正面临一个日益突出的悖论。Claude Code、Cursor、GitHub Copilot、OpenAI Codex、Google Gemini CLI 和 Windsurf 等工具带来了前所未有的能力。然而,选择越丰富,也催生出了一种新的碎片化。每个环境都有各自集成外部工具、API 和自定义脚本的机制——也就是各自的「Harness」。
传统工作流已经难以为继。你开发了一个出色的自定义工具,用来从私有 API 获取实时文档,或者执行复杂的构建脚本。接着,你却不得不花费数小时编写和维护多套独立且脆弱的配置文件:为 Cursor 准备 .cursorrules 文件,为 Claude Code 编写自定义 slash command,为 Copilot 编写 VS Code 扩展清单,还要为其他环境定制 shell alias。这种配置漂移会带来 bug、增加维护成本,还会让你无法在整个工作流中充分利用最优秀的工具。一个统一而强大的 AI 辅助开发环境,始终遥不可及。
解决方案:通过 Model Context Protocol(MCP)实现标准化
实现跨 Harness 工具一致性的关键,是为工具定义采用一套通用标准。由 Anthropic 大力推动、并逐渐被整个生态系统采用的 Model Context Protocol(MCP),提供了所需的规范。借助 MCP,你只需定义一次工具——即一个公开特定函数及其既定 schema 的服务器——随后便可以在任何兼容的 AI Harness 中使用它。
其核心原则是「一次构建,处处运行」。将工具定义为 MCP server 后,你便创建了一项可移植、与语言无关的能力。这个 server 是工具逻辑与接口的唯一事实来源。此后,每个 AI 编程环境中的配置都只需要以声明式方式指向正在运行的 server,而不再需要针对不同环境分别进行复杂实现。正是这种方式,让真正的工具一致性不仅成为可能,也变得易于维护。
构建你的「唯一」MCP 工具:一个实践示例
让我们通过具体示例来说明。假设我们需要一个工具,用来执行安全、经过沙箱隔离的 shell command,并获取执行输出——这是构建脚本、测试运行器或部署检查中的常见需求。我们不再为每种 Harness 分别开发,而是将它一次性构建成 MCP server。
下面是一个使用 TypeScript 和官方 MCP SDK 编写的简化实现。server 会监听 executeCommand tool call,并运行白名单中的命令。
// src/index.ts
import { McpServer, ResourceTemplate } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import { execFile } from "node:child_process";
import { promisify } from "node:util";
const execFileAsync = promisify(execFile);
const ALLOWED_COMMANDS = ["npm", "git", "python", "node", "cat"];
const server = new McpServer({
name: "SafeCommandExecutor",
version: "1.0.0",
});
// Define the tool
server.tool(
"executeCommand",
"Executes a safe, whitelisted shell command and returns stdout/stderr.",
{
command: z.string().describe("The command to execute (e.g., 'npm', 'git')"),
args: z.array(z.string()).describe("Arguments for the command"),
},
async ({ command, args }) => {
if (!ALLOWED_COMMANDS.includes(command)) {
return {
content: [{ type: "text", text: `Error: Command '${command}' is not in the allowed list.` }],
};
}
try {
const { stdout, stderr } = await execFileAsync(command, args, { timeout: 10000 });
return {
content: [{ type: "text", text: `Stdout:\n${stdout}\nStderr:\n${stderr}` }],
};
} catch (error) {
return {
content: [{ type: "text", text: `Execution failed: ${error.message}` }],
};
}
}
);
async function main() {
const transport = new StdioServerTransport();
await server.connect(transport);
console.error("SafeCommandExecutor MCP server running on stdio");
}
main().catch(console.error);
将这个 server 构建并打包成标准的 Node.js 可执行文件。现在,同一个 safe-command-executor.js 文件就是你唯一需要的构建产物。
配置六种 Harness:「处处运行」的实现方式
MCP server 构建完成后,要配置每个 AI 编程环境,只需将其指向正确的 transport 和 server 路径。下面介绍如何让自定义命令执行器在不同工具中实现一致性。
Claude Code 的配置位于 .claude/settings.json。你需要声明 MCP server command 及其参数。
{
"mcpServers": {
"safe-commands": {
"command": "node",
"args": ["/absolute/path/to/safe-command-executor.js"],
"env": {}
}
}
}
2. Cursor(VS Code Fork)
Cursor 使用 .cursor/mcp.json 文件,与其他 VS Code 扩展类似。它的格式几乎完全相同。
{
"mcpServers": {
"safe-commands": {
"command": "node",
"args": ["/absolute/path/to/safe-command-executor.js"]
}
}
}
3. GitHub Copilot(在 VS Code 中)
Copilot 的 Agent mode 同样能够使用 MCP server。相关配置需要放在标准的 VS Code 设置路径 .vscode/mcp.json 中。
{
"servers": {
"safe-commands": {
"type": "stdio",
"command": "node",
"args": ["/absolute/path/to/safe-command-executor.js"]
}
}
}
4. OpenAI Codex(CLI)
Codex CLI 使用一个简单直观的 JSON 配置文件,通常位于 ~/.codex/config.json。它要求将 server command 放在顶层配置中。
{
"mcpServers": {
"safe-commands": {
"command": "node",
"args": ["/absolute/path/to/safe-command-executor.js"]
}
}
}
Google 的 CLI 工具同样遵循 MCP 模式,通过项目根目录下的 .gemini/mcp_servers.json 文件进行配置。
{
"safe-commands": {
"command": "node",
"args": ["/absolute/path/to/safe-command-executor.js"]
}
}
6. Windsurf(原 Codeium)
Windsurf 通过其设置菜单集成 MCP,但底层配置存储在 .windsurf/mcp.json 中。其格式可以直接对应。
{
"mcpServers": {
"safe-commands": {
"command": "node",
"args": ["/absolute/path/to/safe-command-executor.js"]
}
}
}
留意其中的规律。尽管面对的是六种不同的 Harness,核心配置——「使用这些参数运行这条命令」——却高度一致。唯一的区别只是文件路径,以及少量 JSON key 的差异。这就是标准化协议的力量。
实践中的工具一致性:对比表
我们的目标,是让 executeCommand 工具在全部六个环境中以完全相同的方式出现并运行。下面将拆解实际配置情况,突出它们之间极少的差异。
通过将工具逻辑集中在一个 MCP server 中,你已经实现了功能层面的工具一致性。使用 Cursor 进行结对编程的开发者,可以调用与在终端中使用 Claude Code 的同事相同的 executeCommand 工具;使用 Codex 的 CI/CD pipeline 也能调用同一个工具。它们的行为完全一致。
未来属于可移植能力:为什么工具一致性至关重要
实现这种程度的工具一致性,不只是为了方便,更是一项战略优势。它能让你的自定义集成具备面向未来的能力。当下一个突破性的 AI 编程 Harness 出现时,采用它的门槛将降至接近于零:你只需要添加对应的 MCP client 配置文件。你在构建强大、面向特定领域的工具上投入的资源,也不再被锁定在某一家供应商的生态系统中。
它还能促进真正的协作。团队成员可以自由使用自己偏好的 AI Harness,而不必牺牲对共享关键工具的访问能力。它简化了 onboarding 流程,也减轻了认知负担。你只需定义、测试和部署一次工具。由 MCP 等开放协议促成的「一次构建,处处运行」理念,是我们从碎片化的 AI 辅助编程迈向统一增强型开发平台的必然演进方向。
不要再编写重复的工具配置。立即构建你的第一个 MCP server,解锁无缝的跨 Harness 功能。前往 TormentNexus 了解更多信息并开始使用。
最初发布于 tormentnexus.site。
如需采取进一步措施,你可以考虑屏蔽此人和/或举报滥用行为。