Coding MCP 运行时：先看边界，再决定接入

最近比较了三个公开 Coding MCP 项目：

这不是“谁更强”的排名，而是一次接入判断。不同项目解决的层次不同，先把它们放进同一张边界表，才能避免把工具服务器、远程会话和多机器控制面混成一个概念。

四个比较维度

第一是工具范围：有的项目专注于文件、搜索、补丁和命令执行等低层编程原语，有的项目加入长期会话、远程实例或更多控制能力。第二是安全边界：要看工作区限制、权限模式、认证和危险动作确认在哪里生效。第三是跨平台观测：Unix socket、Windows named pipe、路径隔离和进程生命周期都可能影响实际接入。第四是成本：工具越多，权限面、配置面和测试面也越大。

评测结论

这三个仓库是第三方项目，本文只记录我们的评测、比较和接入判断，不把它们的提交包装成自己的代码成果。最终选择并不是“换掉所有现有工具”，而是保留现有的 Coding Agent 工作流，把第三方运行时当作需要具体场景再接入的候选。

一个好的评测结论应该能说明“不接入”的原因：权限边界尚未满足、运行时重叠、维护成本过高，或者现有工作流已经覆盖了当前需求。能停止错误的集成方向，本身也是项目产物。