WorkBuddy MCP 配置指南：连接工具，但别把整台电脑交给 Agent

先说结论

MCP 让 WorkBuddy 真正有用，因为外部服务可以变成可调用工具；但它也扩大了后果边界。新接入应从只读、项目级工具开始，测试拒绝行为，再把写入能力放到审批之后。

WorkBuddy 官方 MCP 指南把 MCP 定义为连接外部工具和数据源的方式，并说明可以在界面中完成配置。它还记录了两种配置级别：用户级 ~/.workbuddy/mcp.json 用于复用，项目级 <项目目录>/.workbuddy/mcp.json 用于当前项目专属的能力。

用户级还是项目级

范围	文件	适合	主要风险
用户级	~/.workbuddy/mcp.json	通用只读服务和通知	所有项目都可能发现工具
项目级	<项目目录>/.workbuddy/mcp.json	某个仓库、数据集或流程	项目继承过强能力

凡是能读取客户数据、修改记录、发送消息或产生费用的工具，都优先放项目级。一个项目能用的配置，不应无声扩散到电脑上的所有任务。

MCP 官方指南是协议与配置路径的核对依据。

产品页用于核对工作台与连接器的关系。

企业文档支持连接器、工作区和凭证管理的讨论。

安全接入顺序

1. 先添加一个只读工具。
2. 确认服务名、输入 Schema 和超时。
3. 分别运行一个应该成功、一个应该被拒绝的任务。
4. 检查工具 Trace 和返回数据，确认没有泄漏密钥。
5. 再添加需要审批的窄范围写入动作。
6. 保存回滚快照并记录负责人。

以企业微信机器人为例，Webhook 应放在密钥管理或托管凭证字段里。不要把它粘进 Prompt、提交进 .workbuddy/mcp.json，也不要截图展示。Agent 应拿到能力，而不是拿到凭证本身。

MCP 本身不是权限系统

MCP 统一了工具描述和调用方式，却不会判断某个人是否有权删除记录、导出客户名单或给全员发消息。宿主仍需处理身份、Scope、审批、限流和审计。

用户身份 -> WorkBuddy 策略 -> MCP 工具 -> 外部系统
                  |              |
                审批           审计事件

记录请求动作、校验后的参数、实际身份、审批决定、结果和重试。必要时脱敏 Payload，但要留下足够的元数据来重建故障。

内置能力、MCP 和自建 API 对比

方案	配置成本	灵活性	适合
WorkBuddy 内置工具	最低	受产品能力限制	常见办公任务
MCP Server	中等	可组合、可复用	连接受控系统
自建 API 集成	最高	完全控制契约	面向客户的严格生产流程

一个具体的配置与测试方案

配置应尽量单一、窄化。项目级配置只声明一个服务，通过宿主支持的 Secret 机制传入凭证，只开放验收任务真正需要的方法。不要把 Token 粘贴进 Prompt，也不要把它和 JSON 一起提交到仓库。启用写入前，先做一张权限矩阵：

动作	预期结果	是否审批	应保留的证据
列出项目记录	允许	否	请求与响应 Schema
读取一条测试记录	允许	否	记录 ID、脱敏结果
修改测试记录	暂停或拒绝	是	审批事件与 Diff
读取父目录	拒绝	否	策略错误
发送外部消息	暂停	是	收件人、正文哈希、审批决定

用一次性项目和测试身份跑完整矩阵，并在 WorkBuddy、MCP Server 或凭证变化后重跑。这样能抓住一个常见问题：自然语言里说“只读”，底层工具的参数却仍然接受写入操作。

发生异常时，先禁用项目级 Server，保留失败请求和工具 Trace，轮换受影响的凭证，再只用只读动作复现。重启进程可能清掉状态，却不能解释 Agent 当时尝试做了什么。

FAQ

MCP Server 应该配置在哪里？

安全、跨项目复用的能力放用户级；绑定某个仓库、数据集或团队流程的工具放项目级。官方指南同时说明了这两种路径。

MCP 可以读取本地文件吗？

如果宿主和 Server 都授予权限，就可以。应限制到明确工作区，拒绝父目录，并测试路径穿越和软链接行为。

工具调用失败怎么排查？

把 Schema 错误、认证失败、网络超时、策略拒绝和下游应用错误分开。保留原始错误，只有可重试的失败才自动重试。

MCP 比直接 API 更安全吗？

不自动更安全。MCP 改善了发现和组合能力，安全来自最小权限、参数校验、审批、凭证隔离和日志。

来源：WorkBuddy MCP 指南、WorkBuddy 产品页、腾讯云企业快速开始。