奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

WorkBuddy 的 MCP 和 CodeBuddy 的 MCP 配置方式一样吗？路径和入口都不同

2026-08-16

MCP 是个开放协议，所以「两边都支持 MCP」这句话是对的——但这不意味着配置方式一样。

实际上，光是配置文件的路径就不同。这篇并列双方官方文档写明的内容。

依据：WorkBuddy 官方文档《MCP》（Function-Description/MCP-Guide）与《连接器》；CodeBuddy 官方中文文档 cli/mcp 与 ide/User-guide/MCP。核对日均为 2026-08-16。本文只并列官方事实，不做优劣判断；我们没有安装任何一方的客户端。

一、先说共同点：都是同一个协议

MCP 全称 Model Context Protocol（模型上下文协议）。WorkBuddy 官方给的比方很形象：

MCP 可以理解为 AI 的「USB 接口」——就像电脑通过 USB 连接外设一样，MCP 让 AI 连接各种外部工具和数据源。

协议是公开的，所以理论上一个 MCP Server 两边都能接。 差异在「怎么配置它」。

二、WorkBuddy 侧的官方口径

入口：进入侧边栏「插件」→ 点击右上角「MCP 服务器」→「配置 MCP」。

官方强调的一点：

WorkBuddy 已将 MCP 配置集成到界面中，无需编码、无需手动改配置文件，可视化操作即可完成接入。

两级配置（这是 WorkBuddy 侧官方明确给出的路径）：

级别适用场景配置文件路径
用户级配置一次，所有项目复用~/.workbuddy/mcp.json
项目级仅当前项目生效，互不影响<项目目录>/.workbuddy/mcp.json

官方给的选择标准：频繁跨项目使用的能力（如企微机器人通知）→ 用户级；仅特定项目需要的专属服务 → 项目级。

状态显示：🟢 绿色（连接成功可正常使用）/ 🔴 红色（配置异常，需检查配置内容、命令环境或地址）。

官方给的完整示例（企业微信机器人）：

{
  "mcpServers": {
    "wecom": {
      "command": "uvx",
      "args": ["wecom-bot-mcp-server"],
      "env": {
        "WECOM_WEBHOOK_URL": "your-webhook-url"
      }
    }
  }
}

官方还提供了一个资源入口：腾讯云 MCP 市场。

三、CodeBuddy 侧

CodeBuddy 有两套独立的 MCP 文档：CLI 侧的 cli/mcp（篇幅较长）和 IDE 侧的 ide/User-guide/MCP。

这本身就说明了一件事：同一家的不同形态，MCP 的接入方式各有各的文档，不是同一篇的多个入口。形态之所以要分这么细，根子在两个产品的定位差异上——WorkBuddy 和 CodeBuddy 有什么区别那篇按官方文档把定位、形态与人群三层都并列过。

CLI 侧的 MCP 与它的整套权限体系是打通的——比如权限模式文档里提到，auto 模式下会临时忽略「任意 Agent / Task 规则」这类过宽的 allow 规则，官方给的理由是防止借子代理绕过分类器。这类机制在 WorkBuddy 侧的 MCP 文档里没有对应说明。

具体配置方式以 CodeBuddy 各自的官方文档为准——本文重点是并列关系，不复述另一边的细节。

四、为什么配置路径不同这件事值得知道

一、备份和迁移的时候要找对地方。 换电脑、重装系统，你得知道去哪儿拷那个文件。WorkBuddy 侧是 ~/.workbuddy/mcp.json（用户级）。

二、排查的时候要确认「你配到哪一级了」。 有一种「MCP 没生效」其实是配错了级别——配成项目级，换个项目自然就读不到了。

三、凭证跟着文件走。 项目级配置在项目目录里，如果这个项目被打包、被复制、被同步到共享盘，配置文件也跟着走。官方在安全提示里专门写了：妥善保管 WebHook URL——它是机器人调用凭证，切勿泄露。

所以打包项目前，先看一眼 .workbuddy/mcp.json 里有没有凭证。

五、WorkBuddy 侧还有一层：连接器

这是 CodeBuddy 侧没有对应说明的一块。

官方在连接器文档里写明：连接器基于标准化协议（如 MCP）将外部服务的能力引入 AI 工作流；自定义连接器那一节也说明配置方式与 MCP 配置类似。

关系是：MCP 是协议，连接器是基于这个协议做出来的成品。 目前官方连接器有五个：QQ 邮箱、腾讯乐享、腾讯文档、TAPD、微云，点一下授权就能用，不用碰任何配置文件。

选择很简单：五个里有你要的走连接器，没有的走 MCP 或自定义连接器。

六、这套体系里同名能力不同实现，已经是常态

MCP 是第六个例子。前面几个：

能力WorkBuddy 侧CodeBuddy 侧
权限模式两档（默认权限 / 完全访问）多种（default / acceptEdits / auto / dontAsk / plan / bypassPermissions / delegate）
定时任务持久配置，按档位限数量会话级，退出即清除、3 天过期
远程控制九个 IM 平台机器人/gateway 本地网关 + 浏览器 Web UI
记忆Function-Description/Memoryide/User-guide/Memory（两套独立文档）
多角色专家 / 专家团（点击召唤）子代理（可配置，有 delegate / ignore 两档权限模式）
MCP侧边栏「插件」→ 可视化配置，两级路径cli/mcp 与 ide/User-guide/MCP 两套文档

所以看到两边都有某个能力时，默认假设应该是「可能不一样」，而不是「应该一样」。

七、WorkBuddy 侧的四条官方最佳实践

这几条对配 MCP 的人很实用，照录：

  • 公共能力配用户级：通知类能力配置一次，多项目复用；
  • 专属接入配项目级：独立配置，避免互相影响；
  • 从成熟示例起步：先接入 WeCom Bot 等路径清晰的 MCP Server；
  • 描述尽量明确：说清通知对象、内容、是否需要 @，调用效果更稳定。

配套的三条安全提示：妥善保管 WebHook URL、检查 JSON 格式（配置失败时优先确认括号、引号是否完整）、关注状态指示灯（绿色可用，红色需排查）。

「从成熟示例起步」这条最值得听——第一个 MCP 挑冷门的，环境问题会成倍增加。

八、我们不写的东西

  • 不写谁的 MCP 支持更完整——需要在同等条件下逐项验证，我们没做；
  • 不做「WorkBuddy 的 MCP 配置等价于 CLI 的 MCP 配置」这类对应——两边文档独立；
  • 不复述 CodeBuddy 侧 MCP 的配置细节——以其官方文档为准；
  • 不写某个具体 MCP Server 在两边的兼容情况——这需要实际安装验证。

九、WorkBuddy 侧配 MCP 的完整流程

官方以企业微信机器人为例给了完整示范，四步：

Step 1：获取 WebHook URL。 在企业微信群中「添加群机器人」→ 获取 WebHook URL。官方给的地址格式是 https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx-...。

Step 2：找到配置入口。 侧边栏「插件」→ 右上角「MCP 服务器」→「配置 MCP」。这个入口有点深——记住是「插件」，不是「设置」。

Step 3：填 mcp.json。 粘贴官方给的那段配置，把 your-webhook-url 换成你的实际地址。两个容易出错的地方：JSON 格式（官方安全提示里明说配置失败时优先确认括号、引号是否完整）、替换时把引号弄丢。

Step 4：看状态灯。 绿色可用；红色要查配置内容、命令环境或地址三个方向。

配完之后怎么用：官方说明用自然语言描述需求即可，会自动调用对应的 MCP Server。官方给的示例指令是「请通过企业微信机器人通知：正式产品已发布，请 @xxxx 进行验收。」

十、红灯排查的顺序

官方给了三个方向，加上配置机制带来的第四条，可以排成一个顺序：

1. JSON 格式   ← 官方点名优先。括号、引号（注意从网页复制带进的全角引号）、逗号
2. 命令环境    ← 配置里的 command（如 uvx）在你机器上存不存在，终端里敲一下
3. 地址        ← 协议头、首尾空白、是否完整（先过一道纯文本编辑器）
4. 配置级别    ← 用户级还是项目级？你现在在哪个项目？

第 4 条是路径差异带来的——有一种「MCP 没生效」其实是配成了项目级，换个项目自然读不到。

第 1 条里的全角引号是最阴的：中文输入法下的弯引号跟 JSON 要的直双引号是不同字符，肉眼几乎看不出来，从聊天软件或文档里复制配置片段时特别容易中招。

小结

  • 共同点：MCP 是同一个公开协议，官方比方是「AI 的 USB 接口」。差异在怎么配置。
  • WorkBuddy 侧：入口在侧边栏「插件」→ 右上角「MCP 服务器」→「配置 MCP」；官方强调无需编码、可视化操作；两级路径 ~/.workbuddy/mcp.json（用户级）与 <项目目录>/.workbuddy/mcp.json（项目级）；状态灯绿/红。
  • CodeBuddy 侧：CLI 与 IDE 各有独立的 MCP 文档，且 CLI 侧的 MCP 与其整套权限体系打通（如 auto 模式会临时忽略过宽的 Agent/Task allow 规则，防止绕过分类器）。
  • 路径不同这件事的三个实际影响：备份迁移要找对地方、排查要确认配到哪一级、项目级配置里的凭证会跟着项目目录走。
  • WorkBuddy 侧独有一层：连接器（官方封装好的五个现成服务，基于 MCP 这类协议实现）。
  • ★ 这套体系里「同名能力不同实现」已经是第六个例子——默认假设应是「可能不一样」。

双方功能与文档表述均以各自官方为准，核对日 2026-08-16。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员