如果你最近在折腾 WorkBuddy多半绕不开两个词Skill 和 MCP。我见过很多人把 Skill 当成 MCP 的替代品也有人把 MCP server 当成“装了就完事”的插件结果配了十个连接器实际能稳定用上的没几个。这篇文章不会讲花哨的概念而是直接把我自己配过、跑过、踩过坑的 10 套 MCP 服务全部摆出来做横向测评同时把 Skill 和 MCP 的边界彻底说清楚。先给出结论MCP 是协议层的外部能力接入Skill 是模型侧的技能封装两者是互补关系不是替代关系。WorkBuddy 之所以强调“连接器”是因为它对 MCP 的兼容做得比较彻底本地服务、远程服务、带环境变量的服务都能在项目级配置里一键拉起。文章后面我会给出完整的配置 JSON、命令行启动方式和实战点评适合正在用 WorkBuddy、Cursor、Claude Code 这类 AI 编程工具的开发者参考也适合打算把 MCP 接入自己团队工作流的人。1. WorkBuddy 的 MCP 连接器到底解决什么问题1.1 MCP 协议是什么给 AI 装上一根通用“数据线”MCP全称 Model Context Protocol中文一般叫模型上下文协议。你可以把它理解成 AI 应用和外部工具之间的 USB 接口没有这个协议之前每个 AI 工具要接数据库、接浏览器、接设计软件都是各写各的插件换一个客户端就要重新对接。有了 MCP 之后只要工具厂商实现一个 MCP server所有支持 MCP 的客户端WorkBuddy、Cursor、Claude Code 等都能直接调用。从 WorkBuddy 的角度看MCP 连接器就是让 AI 助手“长出手脚”的通道。AI 本身只负责生成文本、分析代码、推理逻辑但它不能直接读你磁盘上的文件、不能帮你提交 Git、也不能打开浏览器看页面效果。这些动作全部要通过 MCP server 以工具调用的形式暴露给模型模型在对话中决定“我现在需要读哪个文件”然后由客户端帮你把这个请求转发给对应的 MCP server拿回结果后再继续推理。这里有一个很多人没意识到的点MCP 的本质是进程管理加 JSON-RPC 通信。WorkBuddy 在启动时会帮你拉起多个 MCP server 进程每个进程占用一条通信通道工具调用的请求和响应都走标准 JSON-RPC。所以 MCP 连接器并不是一个“配置文件”那么简单它是实打实的本地进程你给它配置了多少服务你的机器上就会多运行多少个进程。1.2 为什么 WorkBuddy 强调“连接器”而不是“插件”早期 AI 编程工具更爱强调“插件”概念比如 IDE 插件、编辑器插件。插件的问题在于它跟宿主深度绑定宿主升级插件就得跟着改插件之间还经常互相干扰。WorkBuddy 走的是 MCP 路线把外部能力全部统一成连接器好处非常明显第一跨工具复用。你今天在 WorkBuddy 里配好的 filesystem 连接器明天换到 Claude Code只需要复制同一个 JSON 配置不用重新开发。第二隔离性强。MCP server 是独立进程即使某个连接器挂了最多是工具调用报错不会把整个 IDE 拖垮。第三安全边界清晰。每个连接器可以单独配环境变量、单独限定可访问目录不像传统插件那样一装就拿到全部权限。我个人的体会是“连接器”这个叫法本身就提示了它的定位它不是 AI 能力的一部分而是 AI 与外部世界之间的桥梁。你把桥梁设计得越规范AI 能触达的能力就越稳定。1.3 什么时候该用连接器什么时候不该用这个问题的答案很多人搞反了。MCP 连接器适合解决的是“需要真实环境反馈”的任务比如读取文件、查询数据库、操作浏览器、获取实时搜索结果。但它不适合“纯推理”类任务比如让 AI 总结一段文本、写一段代码、做数学推导这些不需要外部工具强行接连接器只会增加延迟和失败率。我自己有一条非常朴素的原则如果这个任务模型靠上下文就能完成就不加连接器如果模型“知道但不掌握实时数据”才上连接器。比如模型知道 Git 的原理但不知道你当前分支有没有未提交的更改这时候 Git 连接器才有价值。知道但拿不到才是 MCP 的用武之地。2. Skill 和 MCP 的边界2.1 Skill 是什么用一份 Markdown 文件教会模型做一件事Skill 这个词最近热度很高尤其是 Anthropic 发布 Agent Skills 之后“impeccable skill”“skill creator”这类热词频繁出现。你可以在 WorkBuddy 的目录里创建一个 skills 文件夹里面每个子文件夹放一份SKILL.md再加一些脚本或模板资源。SKILL.md 的结构非常轻量一般长这样--- name: demo-skill description: 当用户需要生成新项目脚手架时使用可以根据技术栈生成完整目录结构。 --- # 项目脚手架生成 ## 适用场景 - 初始化前端项目 - 初始化后端项目 ## 执行步骤 1. 询问用户技术栈 2. 根据模板生成目录 3. 输出初始化命令 ## 注意事项 - 不要覆盖已有文件 - 生成前先检查目录是否为空YAML frontmatter 里最关键的是description字段模型会根据 description 判断这个 Skill 是否适用于当前任务。正文部分就是纯 Markdown写清楚步骤、规则、注意事项。模型在对话开始时会把所有可用的 Skill 名称和描述加载进上下文真正用的时候才读取完整内容。所以 Skill 本质上是一份“高质量提示词加可复用脚本”的打包体它改变的是模型的行为方式不提供模型本身没有的信息。2.2 MCP 是什么把外部工具变成模型的能力MCP 则完全不一样。它不改变模型的思维方式而是给模型提供“手”。一个 MCP server 可以暴露多个工具比如 filesystem server 暴露了read_file、write_file、list_directory等工具模型在推理过程中按需调用。调用过程是这样的模型先判断“我需要看这个文件的内容”然后在对话流中发起一个 tool callWorkBuddy 收到后把请求转发给 MCP server拿到结果再塞回上下文模型继续分析。整个过程是动态的、间歇性的模型可以反复调用同一个工具也可以一次调用多个工具。MCP server 的运行位置也很多样可以在本地通过npx、uvx启动也可以部署在远程服务器上通过 HTTP 提供接口。本地服务的优势是延迟低、能访问本地资源远程服务的优势是团队共享、算力集中。2.3 Skill 与 MCP 的对比表为了把边界说清楚我整理了一张表维度SkillMCP 连接器本质提示词 脚本 资源文件一个独立的工具服务进程承载内容方法论、步骤、代码模板文件读写、API 调用、浏览器操作等工具函数何时生效对话开始即被模型感知模型在推理过程中按需动态调用数据来源模型已有知识 Skill 内嵌文本外部真实环境能否访问系统资源不能除非 Skill 里写了脚本能这是它的核心价值配置成本低写一份 Markdown 即可中高要处理启动命令、环境变量、权限典型例子代码审查 Skill、SQL 优化 Skillfilesystem、git、fetch、mastergo看这张表就清楚了Skill 管的是“怎么做”MCP 管的是“能做什么”。举个实际例子你写一个“代码审查 Skill”里面规定审查顺序、关注点、输出格式但 Skill 本身读不到代码得配合 Git 或 filesystem 这类 MCP 连接器模型先调用工具拿到代码再按 Skill 的流程来审查。2.4 在 WorkBuddy 里怎么组合使用我的建议是两套机制同时上各管各的。Skill 负责沉淀团队的最佳实践比如“数据库迁移规范”“前端组件开发流程”这些内容是稳定的、不经常变化的。MCP 负责提供实时的外部能力比如连数据库、读设计稿、做浏览器验证。WorkBuddy 的配置目录我一般这样组织.workbuddy/ ├── skills/ │ ├── code-review/ │ │ └── SKILL.md │ └── sql-optimize/ │ ├── SKILL.md │ └── templates/ ├── mcp.json └── settings.json如果团队里有新人加入只需要把这个.workbuddy目录推到 Git 仓库所有人拉到本地就能共享同一套 Skill 和 MCP 配置。这是我觉得最舒服的协作方式。3. 十套 MCP 服务横向测评实录下面进入正题我把实战中用过的 10 套 MCP 服务按类别拆开每套服务会给出用途、配置方式、实测体验和踩坑记录。测评环境是 Ubuntu 22.04 Node.js 20 Python 3.11WorkBuddy 版本为写这篇文章时的最新稳定版。3.1 文件系统与网页抓取组filesystem、fetch第一套必配的是modelcontextprotocol/server-filesystem。它解决的是“AI 读取本地文件”的问题也是所以我建议第一个装的连接器。配置示例{ mcpServers: { filesystem: { command: npx, args: [ -y, modelcontextprotocol/server-filesystem, /home/user/projects/demo, /home/user/documents ] } } }注意 args 里的路径就是你允许 AI 访问的目录白名单一次可以配多个。这是我的血泪教训刚开始我只给了项目根目录结果 AI 想读项目外的一个配置文件直接报权限错误。后来我把文档目录也加了进去使用顺畅了很多。还有一点路径一定要写绝对路径写相对路径大概率会启动失败。另一套通用服务是mcp-server-fetch专门用来抓取网页内容转成 Markdown。这个连接器非常适合做资料调研比如你让 AI 去读某个 API 文档它可以直接抓取并总结。{ mcpServers: { fetch: { command: npx, args: [-y, mcp-server-fetch] } } }实测下来fetch 对普通网页的抓取效果不错但对 JS 渲染较重的页面基本无能为力抓回来的是空壳。这种页面建议交给后面的 Playwright用真实浏览器渲染。3.2 代码工程组git、githubGit 连接器我几乎是每台机器必装的因为 AI 写代码最大的痛点是不知道仓库当前状态。有了mcp-server-gitAI 能自己执行git status、git diff、git log写代码前先看变更写完代码自动检查 diff体验非常顺滑{ mcpServers: { git: { command: uvx, args: [mcp-server-git] } } }这个服务用uvx启动前提是你装了 Python 的 uv 包管理器。如果你没有 uv也可以用pip install mcp-server-git后换个启动方式。实测最常用的场景是让 AI 写完代码后自动帮我审查 diff它能很准确地指出“你这里改动了签名但没改调用方”这类问题。GitHub 连接器modelcontextprotocol/server-github则是走 API 操作远程仓库需要配置 token{ mcpServers: { github: { command: npx, args: [-y, modelcontextprotocol/server-github], env: { GITHUB_PERSONAL_ACCESS_TOKEN: ghp_xxxxxxxxxxxx } } } }用它可以创建 issue、查看 PR、读仓库文件、管理 release。个人开发者可能觉得用处不大但在团队协作场景里非常香AI 可以直接在你提 PR 之前把代码变更总结成 release notes。3.3 数据库连接组sqlite、jdbc数据库类连接器是“含金量”最高的也是配置报错率最高的。先看轻量级的mcp-server-sqlite它内置了一个 SQLite 数据库引擎可以直接执行 SQL 查询{ mcpServers: { sqlite: { command: uvx, args: [mcp-server-sqlite, --db-path, /home/user/projects/demo/data.db] } } }我第一次让 AI 分析线上数据库表结构时就是靠它直接查sqlite_masterAI 把表结构和数据量统计得清清楚楚。但它只能连 SQLite如果项目用的是 MySQL、PostgreSQL 或者其他关系型数据库就需要更通用的 JDBC 连接器。JDBC 连接器可以让你连几乎所有支持 JDBC 驱动的数据库配置相对繁琐{ mcpServers: { jdbc: { command: npx, args: [ -y, mcp-server-jdbc, --url, jdbc:mysql://localhost:3306/demo_db?userrootpassword123456, --driver, com.mysql.cj.jdbc.Driver, --classpath, /path/to/mysql-connector-j-8.0.33.jar ] } } }这里最大的坑就是--classpath需要你提前下载对应数据库的 JDBC 驱动 jar 包而且不同数据库驱动类名不一样。MySQL 8 的驱动类是com.mysql.cj.jdbc.DriverPostgreSQL 的是org.postgresql.Driver写错了大概率启动失败。另外一个很坑的点是如果你用 JDBC 连接生产数据库一定要用只读账号。AI 执行 SQL 的能力非常强一个不小心就可能跑出UPDATE或DELETE语句。我给自己定的规矩是生产环境默认给只读权限需要写操作时在 WorkBuddy 里单独开一套带写权限的连接器用完立刻关掉。3.4 设计还原与三维场景组蓝湖 MasterGo、Blender、Unity这一组是很多前端和游戏开发同学最关心的。先说设计稿接入蓝湖 MasterGo 官方提供了 MCP 服务配置时需要先去 MasterGo 开放平台申请 API Key然后在 WorkBuddy 里通过环境变量注入{ mcpServers: { mastergo: { command: npx, args: [-y, mastergo/mcp-server], env: { MASTERGO_API_KEY: mg_xxxxxxxxxx } } } }实测体验接入蓝湖 MCP 之后AI 可以直接读取设计稿里的图层、颜色、字体、标注信息。前端写页面的时候不再需要来回切设计稿截图直接让 AI “照着设计稿还原”就行效率提升非常明显。但这个连接器对网络要求较高如果公司内网有限制需要确认能正常访问 MasterGo 的 API 域名。Blender MCP 适合做 3D 资产生成和场景构建。它需要在 Blender 里安装一个插件插件会在本地开一个 WebSocket 端口默认是 9876WorkBuddy 里的 MCP server 通过这个端口向 Blender 发指令。配置如下{ mcpServers: { blender: { command: npx, args: [-y, blender-mcp], env: { BLENDER_MCP_PORT: 9876, BLENDER_MCP_HOST: 127.0.0.1 } } } }我试过让 AI 生成一个低多边形场景它能通过 Python API 操作 Blender建模、打光、调相机一气呵成。不过要提醒的是Blender MCP 的插件版本和 Blender 版本如果差太多端口连接会失败报错也常常是莫名其妙的 JSON 解析错误。遇到这种情况不用怀疑人生先去确认插件日志是否正常打印。Unity MCP 的配置思路类似需要在 Unity 工程中导入官方提供的 MCP 包然后配置端点和 API Key{ mcpServers: { unity: { command: npx, args: [-y, unity/mcp-server], env: { UNITY_MCP_API_KEY: xxxxxxxx, UNITY_MCP_ENDPOINT: http://127.0.0.1:8080 } } } }Unity MCP 更适合编辑器自动化比如批量创建 prefab、查场景中的物体列表、调整组件参数。但我自己的体验是它还不够稳定复杂操作偶尔会触发 Unity 的异常弹窗需要一定耐心。游戏团队如果要用建议先在测试工程里充分验证再做推广。3.5 浏览器自动化组Playwright最后一组是浏览器自动化。playwright/mcp是微软官方维护的配置最简单效果却非常炸裂{ mcpServers: { playwright: { command: npx, args: [-y, playwright/mcplatest] } } }装好之后AI 能自己打开浏览器、访问页面、点击按钮、填写表单、截图、抓取 DOM 内容。我最常用的场景是让 AI 做前端自测写完页面代码后直接让它跑一遍页面流程看控制台有没有报错视觉上有没有问题。这比我自己手动点一遍要省力得多。很多人会把它和 Computer Use 类比这两者其实是两个层次的东西。Playwright 走的是 MCP 协议提供的是浏览器工具集它的动作完全基于 DOM 元素选择器操作精准但只限于浏览器内部。Computer Use 则是指 AI 通过屏幕截图模拟鼠标键盘操作的是整个操作系统能点任何应用但不精准。WorkBuddy 里两者都能接但我的建议是能上 Playwright 就优先上 Playwright精准、快速、反馈稳定。3.6 十套服务横向对比把前面十套服务汇总成一张表方便你快速决策服务名称启动方式核心能力推荐指数主要风险filesystemnpx本地文件读写极高目录权限配错fetchnpx网页抓取转 Markdown高JS 渲染页面失效gituvx本地仓库状态与变更极高依赖 uv 环境githubnpx远程仓库 API高Token 权限过大sqliteuvx本地 SQLite 查询高只能连 SQLitejdbcnpx通用数据库连接中高驱动 jar 难配mastergonpx设计稿读取高网络限制blendernpx3D 建模控制中插件版本兼容差unitynpxUnity 编辑器自动化中稳定性一般playwrightnpx浏览器自动化极高资源占用高4. 连接器配置参数与安全细节4.1 mcpServers 标准配置格式解析WorkBuddy 的 MCP 配置统一放在mcp.json中顶层就是一个mcpServers对象每个 key 是一个连接器名称value 是一个启动配置。核心字段有四个command表示启动命令args是命令参数列表env是注入的环境变量另外还可以通过timeout字段控制启动超时时间。{ mcpServers: { my-server: { command: npx, args: [-y, package-name], env: { API_KEY: xxxx }, timeout: 60 } } }这里有个容易忽视的细节MCP server 的进程通信默认走 stdio也就是标准输入输出。这意味着 MCP server 进程的日志绝对不能往 stdout 里打否则会把日志和协议数据混在一起导致连接报错。很多连接器启动后一直显示“连接中”但实际没成功八成就是这个原因。如果你的连接器支持日志参数请一定把日志重定向到文件。4.2 本地服务与远程服务的差异本地 MCP server 通过command启动适合需要访问本地资源的场景。但有些场景不适合本地比如团队共用一个内部数据库或者某个服务算力很大不适合每个人本地跑。这时应该用远程 MCP serverWorkBuddy 支持以 HTTP 方式接入配置格式会变成{ mcpServers: { remote-server: { url: https://mcp.example.com, headers: { Authorization: Bearer xxxx } } } }远程服务用的是流式 HTTP 或 SSE 传输与本地服务的最大区别在于延迟更高、需要认证、而且没有本地文件访问能力。远程服务的优势是配置更轻不需要本地进程但随之而来的问题是网络波动、服务端鉴权和数据安全都要你自己负责。我的建议是个人日常开发优先本地团队基础设施优先远程。4.3 排查连接器异常的通用流程连接器出了问题不要急着重装。我总结了四步排查法第一步确认启动命令本身能跑。把 config 里的 command 和 args 复制到终端里手动执行看有没有报错。很多问题在终端里一眼就能看到比如端口被占用、Python 包没装、Node 版本不兼容。第二步确认环境变量正确。特别是 token 类的环境变量检查有没有多余的空格、换行很多从网页复制过来的 Key 会带上隐藏字符肉眼看不出来但程序读不到。第三步检查日志。MCP server 通常有独立的日志文件或者在终端会输出启动信息。WorkBuddy 的日志面板也会记录连接过程排序后查看最后几行往往能找到关键报错。第四步确认白名单和权限。filesystem 类路径对不对、数据库账号权限够不够、网络端口通不通这都属于这一类问题。4.4 安全边界最小权限原则最后必须强调安全。MCP 连接器给 AI 赋予了真实操作能力这实际上是双刃剑。我的安全清单如下本地文件类连接器只开放必要目录不要给整个磁盘。数据库连接器使用只读账号单独设立专用密码。GitHub、云服务等远程 API 不要用最高权限 token按最小权限创建。一旦发现连接器行为异常立即在配置里禁用而不是直接删除便于回溯。不要把生产环境的敏感配置写在env字段里建议通过 WorkBuddy 的环境变量引用功能注入。5. 怎么选场景化推荐与工作流建议5.1 按角色和场景推荐普通开发者最省心的配置是三件套filesystem git playwright。这三个能覆盖日常开发 80% 的需求读本地代码、看仓库状态、启动页面自测。再加一个数据库连接器sqlite 或 jdbc覆盖查数据场景就够了。前端工程师强烈建议加上蓝湖 MasterGo MCP设计稿还原效率翻倍。做游戏开发或三维内容的再考虑 Blender 或 Unity。做技术调研或内容运营的fetch 是刚需可以考虑再加一个搜索类的 MCP 服务。团队负责人则应该重点关注 Skill 的沉淀。把团队的代码规范、架构约定、发版流程写成 Skill 文件放进共享目录配合团队共享的 MCP 配置新人上手速度会快很多。5.2 一套可直接复制的工作流我现在的日常工作流是这样的先让 AI 通过 filesystem 读项目结构和关键文件快速定位当前代码在做什么然后让 AI 通过 git 看最近改动确认自己的改动能兼容存量逻辑写代码时如果涉及数据库通过 sqlite/JDBC 查看表结构和样例数据最后启用 playwright 跑一遍关键路径确认页面没被改坏。整个过程中 Skill 起着“指挥官”的作用。我在.workbuddy/skills/里放了一个code-review技能里面规定了审查顺序、关注点、输出格式。AI 在执行代码审查时会先通过 filesystem 抓代码、git 看 diff然后严格按 SKILL.md 里的步骤输出审查意见。整个流程不需要我来指挥AI 自己就知道下一步该干什么。5.3 维护心得连接器不是越多越好踩过无数次坑之后我的经验是连接器数量一定要克制。每多一个连接器AI 每次对话就要多加载一部分工具定义既增加 token 消耗又可能引入误调用。我见过有人配了二十多个连接器结果 AI 经常在不需要的时候去调用某个工具反而把简单任务搞复杂了。更好的做法是按项目维度配置每个项目只保留真正需要的 4 到 6 个连接器。工作流类的能力做成 Skill不占连接器名额。这样团队复制配置时成本也低。最后再分享一个小技巧定期更新连接器版本。MCP 生态更新非常快很多 bug 修复和新能力都依赖新版。我会每个月跑一次npx -y modelcontextprotocol/server-filesystem --version之类的版本检查顺手把更新推给团队。连接器这东西用得越简单、越稳定AI 能发挥的价值越大。