ARTICLE · 1257319
MCP 不是插件:搞懂 MCP,你的 WorkBuddy 智能体才算真正能用
在看完上一篇沙箱科普之后，很多人开始动手搭建 WorkBuddy 自动化。 打开配置页，一眼看到 MCP，下意识理解成：这就是给 Agent 装插件、装工具的地方。
这个认知偏差，直接限制了你 Agent 能力的上限。
MCP 不是插件。它不是功能包，不是一键安装的扩展，不是简单的函数调用包装。MCP 全称 Model Context Protocol，模型上下文协议，是一套开放、标准化的双向通信规范，是 Agent 连接外部世界的通用接口底座Model Cont...。 理解清楚它，才算真正理解 WorkBuddy 智能体的运行架构。
一、先分清：插件、函数调用、MCP，三者完全不是一回事
很多新手在这里混淆，我们做清晰区分：
- 插件（Plugin）
：封闭、平台绑定的功能模块。只适配某一个大模型、某一个应用，换框架就要重写，接口各不相同，能力由开发者预先写死。插件是成品功能。 - Function Call（函数调用）
：模型按照 JSON Schema 调用预设函数，单向为主，侧重 “执行一次动作”，上下文、资源、会话状态很难持续传递。它是单次动作调用。 - MCP（模型上下文协议）
：一套中立开放标准，基于 JSON-RPC，采用客户端 - 服务端架构。它定义统一规范，让任意兼容 MCP 的 Agent，和任意 MCP 服务端双向通信，持续读取资源、调用工具、加载预设提示词、维持会话状态Model Cont...。它是通信标准、连接通道。
一句话类比： 插件像品牌专属充电头，只能适配自家设备； 函数调用像临时拉一根电线，用完即断；MCP 就像 USB 标准。只要设备遵循 USB 规范，硬盘、键盘、读卡器都可以即连即用，不需要为每一个设备单独写一套适配代码。
MCP 定义了通信语言，不定义具体功能。 MCP Server 才对外暴露能力：文件读取、数据库查询、邮件收发、浏览器操作、接口请求、读取日志。 WorkBuddy 作为 MCP Client，去对接这些服务端。
二、MCP 三大核心原语：Resources、Tools、Prompts
MCP 规范里只定义三类基础能力，所有扩展都基于这三者构建，这也是 WorkBuddy 里 MCP 的核心： ✅ Resources｜只读资源纯读取，无副作用。读取本地文档、表格、日志、知识库内容、网页原文。作用是把原始上下文喂给模型，相当于给 Agent 提供阅读素材。它不会修改任何数据。
✅ Tools｜可执行工具带有副作用的动作：写入文件、执行脚本、发送邮件、发起接口请求、批量重命名。 工具调用需要权限管控，这也是为什么 MCP 天然要和沙箱配合使用。
✅ Prompts｜预设提示模板服务端托管的标准化提示词模板。把固定的任务范式放在 MCP 服务端，Agent 直接加载，统一任务约束、输出格式。
重点：MCP 只规定怎么协商能力、怎么收发消息、怎么管理会话生命周期；具体要读什么文件、执行什么脚本，由 MCP 服务端实现Model Cont...。
三、放到 WorkBuddy 架构里：MCP、沙箱、Harness 三者分工
结合上一篇沙箱文章，这里把整套链路串起来，形成完整认知：
- 沙箱：边界隔离层
管控权限，划定 Agent 可以触碰的范围，防止越界破坏本地系统与文件。负责定义「不能做什么」。 - MCP：交互通信层
标准化通道，让 Agent 安全访问资源、调用外部能力。解决 Agent “怎么和外部系统对话”。 - Harness：任务编排层
拆解目标、规划步骤、校验结果、循环重试，指挥 Agent 按流程完成复杂任务。负责教 Agent「应该怎么干」。
三者配合，才是一套完整可信的 Agent 体系：
Harness 规划任务 → 通过 MCP 请求资源 / 调用工具 → 所有高危执行动作，全部在沙箱隔离环境内落地。
很多人只装 MCP 服务、不开启沙箱，等于打通了通道，却拆掉了围栏，这是最高发的安全隐患。 MCP 本身不自带安全隔离；MCP 负责打通通路，沙箱负责锁好边界。
四、MCP 两种部署形态：本地 MCP Server vs 远程 MCP Server
在 WorkBuddy 实操里，两种模式适用场景完全不同：
- 本地 MCP Server
跑在你的本机，对接本地文件系统、本地 Shell、内网数据库。数据不出本机，适合处理内部文档、内网业务。风险点：一旦没有沙箱，工具调用可以直接操作本机文件。 - 远程 MCP Server
部署在云端，通过网络接入。比如第三方邮箱服务、在线数据库、SaaS 系统。本机只发起调用，计算与执行在远端。适合不想开放本地权限、跨设备共用工具的场景。
关键点：MCP 协议是中立的。同一个 MCP 服务端，不仅 WorkBuddy 可以接入，其他支持 MCP 的 Agent 客户端同样可以对接，这就是标准化带来的复用价值。插件做不到这一点。
五、常见误区澄清
误区 1：装上 MCP，Agent 就变强了
MCP 只是通道。如果 MCP 服务端暴露的工具本身有缺陷、权限过大，只会放大风险。能力强弱取决于 MCP 服务端实现、权限策略、沙箱约束、Harness 校验规则。通道本身不解决逻辑正确性问题。
误区 2：MCP=RAG
RAG 是检索增强方案，解决事实信息来源问题；MCP 是通信协议。RAG 知识库可以封装成一个 MCP Resources 对外提供，但二者不属于同一维度概念。
误区 3：官方 MCP 才靠谱，自建 MCP 不安全
MCP 规范对所有人开放，你完全可以自建轻量 MCP 服务对接私有业务系统。风险不在于 “自建”，而在于权限是否最小化、执行是否放进沙箱、入参有没有校验。最小权限原则，是 MCP 安全的核心准则。
六、普通人落地建议：MCP 使用顺序
先评估需求：我是只读取文档，还是需要写入、执行命令？ 优先最小权限配置：MCP 服务只开放必要资源与工具，不开放全盘读写、高危系统命令。 只要包含 Tools（写、执行），强制搭配沙箱运行。 先用本地 MCP 做小范围验证，稳定后再考虑远程托管。 做好调用日志审计：记录每一次 MCP 资源读取、工具调用入参和返回结果，方便排查幻觉、异常动作。
结语
插件时代，Agent 的能力被平台锁死；MCP 时代，我们拥有统一、可迁移、可自建的交互底座。 沙箱给 Agent 划定安全的笼子，MCP 给 Agent 向外延伸的触手，Harness 给 Agent 做事的思路。 读懂 MCP，你才算跳出 “给 AI 装插件” 的浅层玩法，真正开始搭建可控、可复用、可落地的自动化智能体。
后续再搭建复杂工作流，你会发现：Agent 的上限，往往取决于 MCP 层的设计，而不是提示词写得多精妙。
💬 互动：你目前在用哪些 MCP 服务？是官方自带，还是已经尝试自建？欢迎评论区交流踩坑经历。
