在腾讯云总裁班的交流现场，我被问得最多的一句话是：“你们讲WorkBuddy能接企业系统，那MCP到底是怎么接的？”问这个问题的人，既有做渠道交付的代理商，也有甲方负责信息化的老总。大家手里其实都不缺AI产品，缺的是把AI和客户已有的ERP、PLM、OA这些系统真正打通的那条通路。今天这篇就围绕WorkBuddy、MCP协议和企业系统对接这件事，把我从项目里实际趟出来的经验完整写一遍，给准备在企业侧落地的代理商和实施团队做个参考。
先说结论：MCP解决的是AI模型与企业系统之间的“连接标准化”问题，WorkBuddy解决的是“智能体工作台”的问题，两者配合，才真正让AI从“只会聊天”变成“能干活”。下面按我的理解逐步拆开讲。
1. 总裁班上的真实场景：AI 工具不缺，卡在企业系统这一环
1.1 代理商都在问同一个问题
现在市面上AI工具多得数不过来，编码助手、写作助手、会议纪要工具，各家的代理商手里都压着一堆产品。但只要走到中大型企业客户那边，问题就来了：客户不关心你的AI多聪明，他们只问一句——能不能连我们的ERP？能不能直接查订单、写工单、调PLM里的BOM表？
我在企动云的交付项目里经常面对这种场景。客户之前已经买过各种SaaS、传统软件，甚至自研了一套内部系统，数据和管理流程都在里面。你光给他一个AI对话框，他没法用。因为他真正的工作流是从一个系统跳到另一个系统，AI如果碰不到这些系统，就只是个高级搜索引擎。
这其实暴露了AI进入企业市场最大的瓶颈：不是模型能力，而是连接能力。
1.2 传统API对接模式为什么在AI时代失灵了
在过去十年里，企业系统之间做对接，主流做法是REST API。每个系统暴露一堆接口，调用方按文档拼参数、处理鉴权、解析返回结果。这套模式对传统软件好用，但对AI来说就很别扭。
别扭在哪？举个例子：一个ERP有几千个接口，你想让AI帮你查一张销售订单，你得先告诉AI“订单查询接口叫什么、参数是什么、返回哪些字段”。可是ERP的接口文档有几百页，AI模型根本不可能把所有接口都塞进上下文里。就算塞进去了，每次对话的token消耗也受不了。
更麻烦的是，AI需要具备“动态发现能力”——它得知道当前系统提供了哪些工具、每个工具需要什么参数、哪些参数有枚举值。这些东西在传统API模式下不存在，因为传统API的Schema是给人看的，不是给模型看的。而MCP做的事情，就是把这些工具的元数据、参数定义、调用方式标准化，让模型像读菜单一样读取并调用。
1.3 从“聊天机器人”到“能动手的智能体”
很多企业之前都上过聊天机器人，最后大部分都变成了摆设，原因很简单：只会说，不会做。你说“帮我查一下上周华东区退货率”，机器人跟你说“好的，正在查询”，然后就没下文了。
MCP带来的变化是，模型可以把“查询”这件事实实在在地执行掉。它调用一个封装好的MCP工具，工具去ERP里查数据，把结果返回给模型，模型再组织语言回复给用户。也就是说，MCP给了AI一双手。这不只是体验升级，而是智能体能不能在企业里真正干活的分水岭。
所以，对代理商来说，谁先把“AI+企业系统连接”这条路跑通，谁就能从卖软件许可证变成卖数字化服务，客单价和客户粘性完全不是一个量级。
2. MCP 的组成与工作原理：Host、Server、工具发现机制
2.1 三个角色一次看懂：Host、Client、Server
MCP的全称是Model Context Protocol，模型上下文协议。它由Anthropic在2024年底开源，目前已经成了AI工具连接外部系统的标准协议。理解MCP，先把三个角色分清楚。
- MCP Host：运行AI模型的宿主应用，比如WorkBuddy、Claude Desktop、各种IDE插件。它是用户直接面对的那一层。
- MCP Client：宿主内部负责和MCP Server通信的组件，处理协议细节、连接管理、请求转发。
- MCP Server：把某个能力或某套系统封装成标准化接口的独立服务。可以是一个本地进程，也可以是远程服务，对外暴露工具列表、资源和提示词。
我用一个生活化的类比帮你记：Host就是手机的机身，MCP Server就是蓝牙耳机、摄像头、手柄这些外设，MCP Client负责让手机和外设握手配对。传统API模式等于你要为每个外设单独焊一根线，MCP模式则统一成同一个接口标准，插上就能用。
2.2 三类核心原语：工具、资源、提示词
MCP协议里定义了三个核心原语，理解这三个就理解了整个协议的功能边界。
第一个是工具（Tools）。工具是可供模型调用的函数，比如“查询订单详情”“创建审批单”“读取CRM客户资料”。每个工具都带一个JSON Schema格式的输入参数定义，模型看了Schema就知道该怎么传参。这一点至关重要，因为大模型生成的是文本，如果没有清晰的参数规则约束，它很容易乱传参数。
第二个是资源（Resources）。资源是以URI形式暴露的可读数据，比如文件内容、数据库表、日志片段。模型可以通过资源接口直接读取数据，而不需要经过工具调用。工具侧重“做动作”，资源侧重“读数据”。
第三个是提示词（Prompts）。提示词是预定义好的模板，帮助模型在特定场景下快速进入状态。比如你封装一个“客户投诉处理”的提示词，模型拿到投诉工单后，会按照固定套路来分析问题严重程度、建议处理路径。
2.3 两个关键协议细节：初始化与调用流程
MCP底层基于JSON-RPC 2.0协议通信。整个交互流程分两步。
第一步是初始化握手。Client连接Server后，双方交换协议版本、客户端能力、服务端能力。握手成功后，Client会主动调用tools/list接口，把Server提供的所有工具列表拉下来，包括每个工具的说明和参数Schema。这个“拉菜单”的动作，就是MCP跟传统API最大的不同——传统API的接口清单是写在文档里的，MCP的接口清单是模型启动时动态发现、实时获取的。
第二步是工具调用。模型根据用户需求，从已经加载的工具列表里挑一个工具，生成符合Schema的参数，然后通过tools/call接口把请求发给Server。Server执行完，返回结构化结果。模型再基于结果继续推理，组织最终答复。
这里的传输通道有两种常见形式：本地开发时常用stdio，也就是MCP Server作为子进程启动，通过标准输入输出跟Client通信；生产环境中常用Streamable HTTP，Server是一个独立服务，通过HTTP接口通信，支持鉴权和跨网络部署。企业环境里，远程HTTP模式才是主流，因为系统不可能都跟AI工作台跑在同一台机器上。
3. WorkBuddy 在企业侧的定位：工作台、Skill 与 MCP 工具层
3.1 WorkBuddy 和 CodeBuddy 的分工
很多代理商分不清WorkBuddy和CodeBuddy，这也是我在总裁班上被反复问到的问题。按我们实际使用的体感来区分：CodeBuddy主攻编码场景，定位是IDE里的AI编程助手，帮开发者写代码、改Bug、做代码解释；WorkBuddy则更偏向智能体工作台，承载的是日常工作流编排和多方系统协作。
你可以这样理解：CodeBuddy是“写代码的人”，WorkBuddy是“协调活儿的人”。对于一个销售下采购单、查询审批进度、汇总多部门报表这些场景，CodeBuddy帮不上什么忙，但WorkBuddy可以通过编排多个MCP工具把这些流程串起来。
在企动云的交付案例里，我们通常把WorkBuddy装到客户管理人员和业务人员的电脑上，把MCP Server接到客户的后端系统，工作台就成了业务人员面对AI的统一入口。包括它支持自定义系统缓存目录、跨设备同步配置，这些细节对在企业电脑环境里部署还挺关键的，很多企业电脑有统一的软件管理策略，缓存目录不调整就会被清理工具误删。
3.2 Skill 与 MCP 工具的区别和配合
WorkBuddy里还有一个概念叫Skill（技能），很多人把它跟MCP工具搞混。区别在于：Skill是预先编排好的流程或知识包，比如“生成周报”Skill，它规定了模型应该分几步、每步做什么、输出什么格式；而MCP工具是能力单元，比如“读取订单数据”这个动作本身。
落实到具体使用上，Skill和MCP工具通常是配合的关系。Skill负责“怎么想”，MCP工具负责“怎么做”。举个例子，你定义一个“客户对账”Skill，里面规定：先调用MCP工具读取客户应收账款，再调用另一个MCP工具读取银行流水，然后按对账规则做匹配。Skill本身不直接连系统，它编排MCP工具来完成实际动作。
这个组合拳对代理商来说意义很大。因为Skill是可以沉淀、复制、迭代的。你在一个客户那边打磨好的对账流程，换个客户只需要改几个参数，就能重新上架复用，边际成本很低。
3.3 代理商为什么盯上这个组合
从生意角度看，代理商卖单个AI软件很难卖出溢价，因为产品是标准化的，客户随时可以走官网下单。但“WorkBuddy+Skill+MCP工具”是一套解决方案：要诊断客户系统、要写MCP适配层、要配置Skill流程、要培训员工。每一项都是服务费，而且这些服务产生的业务理解是长在代理商身上的，客户替换成本很高。
这也是我为什么一直跟同行说：不要把MCP当成一个技术名词去背，要把它当成一种交付能力的载体。你不需要自己研发AI模型，但你可以成为最懂怎么把AI接进客户系统的那个角色。
4. 最小可运行链路：把企业系统通过 MCP 暴露给 WorkBuddy
4.1 第一步：挑一个能先跑起来的 MCP Server
MCP生态现在很热闹，官方和社区已经有不少现成Server可选，覆盖文件系统、数据库、浏览器、设计工具等。比如企业内部常见的MySQL、PostgreSQL数据库，有现成的MCP Server可以直接用；像蓝湖、Figma这类设计协作工具也有社区适配；甚至有人做了逆向工程工具和数据库管理工具的MCP插件。在挑Server这件事上，我的建议是：先用现成的，不要一上来就自己写。
但现实情况是，企业核心系统比如自研ERP、PLM，通常没有现成MCP Server。这时候就需要用官方SDK自己封装。MCP官方提供了TypeScript、Python、Java等语言的SDK，写一个Server的门槛不高：定义几个工具函数，声明好参数Schema，设置好回调逻辑，基本就完成了。
我自己常用的是Python SDK，因为企业内部系统大多是Java技术栈，Python写适配层比较灵活，团队里也容易招到人。核心代码思路很简单：在SDK里注册工具，工具内部去调用现有系统的API或者直接查数据库。
4.2 客户端配置文件的写法与启动方式
MCP Server准备好之后，需要在WorkBuddy里注册。注册方式一般是编辑MCP配置文件，在mcpServers字段下增加服务声明。本地跑的话，典型配置长这样：
{ "mcpServers": { "erp-order": { "command": "python", "args": ["/opt/mcp-servers/erp_order_server.py"], "env": { "ERP_API_BASE": "http://10.0.1.20:8080", "ERP_APP_KEY": "from-company-secret-store" } } } }配置好之后，WorkBuddy启动时会自动拉起这个Python进程，完成MCP握手，把工具列表加载进来。如果是企业内网Linux服务器部署，我建议不要把MCP Server直接在前台跑，而是用systemd托管成服务，开机自启、崩溃自动重启，日志统一输出，运维省心很多。
这里要提醒一句：env里的密钥千万不要写死在配置文件里。企业环境要用密钥管理服务或者配置中心下发，我见过不少项目因为把数据库密码直接写在JSON里，最后被运维扫出漏洞的。
4.3 内网部署与远程MCP的鉴权选择
本地stdio模式适合开发调试，真正常用是远程MCP模式。远程模式下，MCP Server变成一个HTTP服务，WorkBuddy通过HTTPS访问。这里面最核心的问题是鉴权，我推荐的做法是走API Key或者OAuth 2.0。
腾讯云这类云平台上部署远程MCP时，一般还会配合API网关，网关层做IP白名单、流量限制和身份认证，MCP服务本身不直接暴露公网。如果你用Linux服务器部署，SSH登录本身就建议用密钥而非密码，我习惯在SecureCRT里配置密钥对登录，避免密码爆破问题。MCP远程接口同样要遵循这种安全习惯，宁可多套几层防护，也不要裸奔。
整个最小可运行链路跑通后，效果是：用户在WorkBuddy里说一句话，模型自动选择对应工具，调用企业系统API，拿回数据做整理后再答复。这个“一句话到系统操作”的闭环一旦跑通，后面所有扩展都建立在这个基础上。
5. 真实项目里的交付细节：权限、数据格式与运维
5.1 权限设计：AI能读的和能写的必须分开
我们刚开始做MCP接入时犯过一个错：把查询和修改接口一股脑全暴露给模型。结果是模型在一次对话里既查了数据也改了数据，虽然没出大事，但把客户IT负责人吓出了一身冷汗。从那以后，我们定了一条规矩：MCP工具的权限按“读、写、执行”三级严格分离。
| 权限级别 | 典型工具示例 | 默认策略 |
|---|---|---|
| 只读 | 查询订单、读取库存、拉取报表 | 直接放行 |
| 受限写 | 创建草稿、发起审批、修改备注 | 人工确认后执行 |
| 高风险写 | 删除数据、大批量更新、对外发送 | 默认禁止，走审批流程 |
具体实现上，可以在MCP Server内部做RBAC（基于角色的访问控制），也可以在企业系统的API网关层做。我倾向于两层都做：Server层验证用户身份和角色，API层验证操作范围和频次。AI能走的权限，永远不应该超过普通员工的权限。
5.2 流式输出与长任务处理
企业系统里很多操作不是瞬时完成的，比如生成一份上万个订单的汇总表，可能要跑几十秒甚至几分钟。如果MCP Server同步等待结果，HTTP连接早就超时了。
我们现在的做法是异步任务模式：MCP Server收到工具调用后，立即返回一个任务ID，后台任务继续执行；WorkBuddy里的Skill流程轮询任务状态，任务完成后主动拉取结果文件。如果结果是超大文本或报表文件，就用流式输出的方式直接写到服务器指定目录，再提供给用户下载，而不是一次性全塞进对话上下文里。
这里还牵扯到WorkBuddy的系统缓存目录配置。默认缓存路径在一些企业域环境下空间有限，我们一般在一开始就把缓存目录改到独立数据盘，避免跑大型MCP工具时磁盘写满。这个细节看着小，但生产环境里栽过跟头的人都知道有多痛。
5.3 部署升级与日志排查
MCP工具接入企业系统之后，一定会进入迭代维护阶段。几个经验供参考。
第一，版本锁定。MCP Server依赖的SDK版本、Python版本、Node版本都要锁定，最好用容器镜像或虚拟环境隔离。我曾经被一个SDK的破坏性更新坑过，升级后所有工具调用都报参数校验失败，排查了整整一天。
第二，日志规范。每个MCP Server启动时，把初始化握手日志、工具调用日志、错误堆栈都输出到统一日志目录。生产环境里用systemd管理的服务，直接通过journalctl查日志非常方便。比如WorkBuddy提示“找不到MCP Server”，十有八九是命令或参数路径写错了，日志里一眼就能定位。
第三，调用审计。企业客户通常会要求记录每一次AI对系统的操作。我们会在MCP Server里加一层审计日志，记录操作人、操作时间、调用工具、入参和出参摘要。这既是安全要求，也是后续优化Skill流程的依据——通过调用记录，你能看出哪些工具被高频使用、哪些工具形同虚设。
6. 代理商落地经验：企动云在项目里实际做的事
6.1 先诊断企业痛点，再决定接哪些系统
很多代理商听到MCP，第一反应是赶紧研究技术，找几个系统练手。但以我们在企动云做交付的经验，第一步恰恰不是技术，而是业务诊断。
制造企业的痛点往往集中在几个方面：PLM里图纸和BOM变更频繁，跟ERP的物料数据对不上；销售要份报价单，要跨三个系统手工凑数据；管理层问个经营数据，IT要导Excel做半天。每个痛点对应的接入深度完全不一样。如果只是一张报表查询，做个只读MCP工具就够；如果要自动生成报价单并触发审批，那就是跨系统编排，复杂度和权限要求高一个量级。
所以每次接项目，我们第一个星期基本不做开发，而是拉着客户各业务线负责人访谈，把高频操作和管理痛点梳理成清单，然后逐条标注“哪个环节可以被MCP工具替代或辅助”。等到客户自己认可了这份清单，项目的路就顺了。
6.2 交付节奏：从单点验证到全量铺开
我建议代理商朋友不要一上来就承诺“一站式全连接”，而是按照三个节奏推进。
第一个阶段，单点验证。挑一个价值最高、技术最简单的场景，比如“查询订单状态”，把MCP链路跑通，让客户业务人员实际用起来。这个阶段的目的是建立信任，让客户看到AI确实能碰到真实系统。
第二个阶段，价值深化。加写回类工具，比如“发起审批单”“更新客户备注”，配合人工确认机制一起上线。这个阶段要跟客户IT团队深度配合，确认好权限边界和数据合规规则。
第三个阶段，流程编排。把多个MCP工具编排成Skill，比如“月度经营分析自动生成”，从多个系统取数、清洗、汇总、生成报告。到这一步，项目就从工具交付变成了业务流程重构，客单价和续约率才会真正体现出来。
6.3 给代理商和执行团队的三条建议
第一条，不要过度承诺。MCP再强也只是协议，它解决连接问题，不解决数据质量问题。如果客户源头数据就是乱的，AI接进去只会更快地暴露出“垃圾进垃圾出”的现状。跟客户沟通预期时，把数据治理的必要性讲在前面。
第二条，尽早拉IT部门入伙。企业系统对接绕不开IT部门，他们的顾虑是安全和运维。你越早让他们参与架构评审，后续上线阻力越小。反过来，如果已经做完才通知IT，大概率会被拦下来重新审查。
第三条，把每个项目的Skill沉淀成自己的资产。一个客户的对账流程、报表生成流程，稍作参数化就能卖给同行业客户。这是代理商最应该积累的复利型资产。我们在企动云内部建立了一个Skill库，每次交付完项目，把通用环节抽出来做成模板，后面接同行客户的速度肉眼可见地加快。
说到底，MCP落在企业系统里的价值，不在于协议本身多先进，而在于它第一次让AI有了统一的方式去操作企业的数据资产。WorkBuddy这类工作台负责把这种能力呈现在终端用户面前，代理商做的事情则是穿针引线——既要懂业务痛点，又要能搞定技术落地，还要守得住安全底线。这三样凑齐了，AI进企业这件事才能真正从演示变成生产。我自己跑完这几个项目最大的感受是：客户不缺AI，缺的是那个能把AI接到他系统上的人。
