在腾讯云总裁班的交流现场我被问得最多的一句话是“你们讲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、ServerMCP的全称是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 HTTPServer是一个独立服务通过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软件很难卖出溢价因为产品是标准化的客户随时可以走官网下单。但“WorkBuddySkillMCP工具”是一套解决方案要诊断客户系统、要写MCP适配层、要配置Skill流程、要培训员工。每一项都是服务费而且这些服务产生的业务理解是长在代理商身上的客户替换成本很高。这也是我为什么一直跟同行说不要把MCP当成一个技术名词去背要把它当成一种交付能力的载体。你不需要自己研发AI模型但你可以成为最懂怎么把AI接进客户系统的那个角色。4. 最小可运行链路把企业系统通过 MCP 暴露给 WorkBuddy4.1 第一步挑一个能先跑起来的 MCP ServerMCP生态现在很热闹官方和社区已经有不少现成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接到他系统上的人。