企业官网建设流程全解析

一家制造企业的IT负责人跑来找我聊了个挺有意思的事：他们刚把AI工作台通过MCP接入ERP和MES，产线主管用自然语言就能查工单、看报工、问库存，效果确实不错。但聊到权限的时候他问了一句：既然MCP这么方便，能不能干脆用它把企业权限系统替代掉？当时我一愣，然后花了半小时跟他讲清楚为什么这条路走不通。

这个疑问其实非常典型。MCP出来之后，很多做企业集成的朋友第一反应是"以后接系统不就一个MCP Server搞定"，然后把权限这层老古董想当然地省了。这篇文章我想把这笔账算清楚：AI工作台接ERP、MES时，MCP到底在哪个环节起作用，为什么它天生做不了权限系统，以及真正应该怎么设计权限边界。看完你就能明白，MCP解决的是"AI够不够得着工具"的问题，企业权限系统解决的是"你有没有资格碰这些数据"的问题，两件事差着整整一个治理层。

1. 先搞清楚：AI工作台借助MCP接入ERP/MES时，技术链路长什么样

1.1 MCP在企业集成里的真实身份：连接器，不是裁判

MCP全称Model Context Protocol，模型上下文协议，本质上是给AI应用和外部工具之间定的一套标准化接口。你可以把它理解成一条通用数据线，AI工作台（客户端）和ERP/MES系统（服务端）各插一头，约定好格式，数据就能流转起来。它解决了过去最大的痛点：每个系统一个私有API，AI接一个系统要写一套适配代码，接十个系统要维护十套，集成成本居高不下。

但这里有个关键点需要先明确：MCP协议约定的是"客户端怎么发现服务端提供的工具、怎么发起调用、怎么返回结果"，它管的是连接和调用格式。协议层面没有定义"什么用户能调什么工具"这件事。这就好比快递公司约定好了面单格式、收发货流程，但面单上填谁的身份证号、谁有权拆包裹，那是仓库管理系统的职责，快递公司管不着。

在企业集成的语境里，MCP Server通常部署在ERP/MES周边，把一个具体的业务能力包装成AI可调用的"工具"。比如把MES的"查询工单进度"接口包装成mcp_tool_query_wo_progress，把ERP的"查询库存台账"包装成mcp_tool_query_inventory。AI工作台通过MCP协议看到这些工具的名字和入参格式，然后按需调用。到这里为止，一切正常，但很多人恰恰是在写MCP Server这一步开始犯迷糊：为了图省事，直接在Server里塞了一个ERP超管账号的API Key。

1.2 一条典型链路：AI工作台到ERP/MES的调用全貌

我们先画一条完整的技术链路，后面所有问题都在这条链路上展开。企业内部的AI工作台（不管是自研Agent、开源框架还是商业产品）作为MCP客户端，通过配置好的MCP Server地址发起请求；MCP Server收到请求后，解析出工具名和参数，再调用ERP或MES对外开放的API；业务系统接到API请求后，执行查询或操作，把结果原路返回；最后AI工作台把结果组织成自然语言回复给用户。

这条链路上有一个非常重要的点：真正的数据访问发生在MCP Server调用ERP/MES API这一步。也就是说，权限裁决的关键位置在业务系统这一侧，在ERP/MES的API网关里，在它们自己的权限模型里，而不是在MCP协议里。MCP Server只是中间搬运工，它手里那个API Key决定了"这台服务器能调多少东西"，但决定"当前这个提问的用户能不能看这批数据"的，必须是业务系统基于用户身份做的判断。

这就是整个问题的分水岭：如果你在MCP Server里配了一个拥有全部权限的API Key，相当于给所有用AI工作台的员工发了一把万能钥匙。钥匙本身能开所有门，至于开门之后该不该看里面的文件，AI不知道，也不会去判断。我见过不少集成项目，把权限寄托在"AI只调工具、不乱调"的假设上，这等于把安全交给运气，早晚出事。

2. 为什么MCP天然做不了权限系统

2.1 MCP协议栈的设计里没有"终端用户"

MCP协议里最重要的几个概念是Client、Server、Tool、Resource、Prompt，你翻遍整个协议规范，找不到一个叫"终端用户身份"的一等公民。协议层的Session通常只区分"哪一个MCP客户端实例连接了服务端"，客户端后面是张三还是李四，协议本身不关心。这是一条硬性设计边界，也是一条安全边界，但很多人没意识到。

举个更直观的例子：一个AI工作台可能供全公司100个人使用，但这100个人通过MCP连接同一个Server时，从Server视角看，连接方只是同一个Client实例。如果Client直接把当前用户的身份塞进参数里传给MCP Server，Server也没有义务去验证这个身份是真的、有没有被篡改。因为协议不做身份断言，它只做数据搬运。你想在MCP层做细粒度权限，等于在一个没有"用户"概念的水管里装水表，管道本身连水表接口都没留。

我在实际项目里验证过这个限制。去年有个团队想做一个"基于MCP的资源级授权"，在Server端维护一份用户清单，每个工具调用前查一下发起IP是不是在白名单里。听着能跑，但实际上漏洞百出：同一台跳板机的用户可以共用IP，AI Agent的代理解析可能被诱导调用敏感工具。最终结论还是得回到企业权限系统，MCP层根本不该承担身份识别和授权裁决的职能。

2.2 工具注册列表和角色权限表，完全是两种东西

MCP Server会暴露一个工具列表，每个工具用JSON Schema描述名称、描述、参数、返回结构。有人看到这个列表就觉得：这不就是权限表吗？反正服务器上定义了哪些工具，AI就只能调哪些工具，那不就能控制权限了？这是典型的混淆。

工具注册列表描述的是"接口长什么样、有什么能力"，它是系统能力目录，不是访问控制清单。角色权限表描述的是"某个角色对某个资源有什么操作权限"，它是人员资格的集合。你在一个MCP Server里定义了100个工具，好比一个图书馆里摆了10万本书，书在书架上不等于任何人都能借走每一本书，能不能借得看借书证的等级和馆藏的管控规则。

更进一步，同一个工具在不同用户面前应该返回不同结果。比如ERP里的"查询销售订单"工具，销售总监和跟单员能看的字段可以天差地别，跟单员还可能只能看到自己负责区域的数据。这种差异如果按工具粒度控制，根本无法表达。你得在工具之下再做一层：按用户身份过滤行级数据、按角色隐藏敏感字段、按组织关系隔离数据域，这些恰恰是企业权限系统最擅长做的事情，MCP工具列表完全做不到。

2.3 AI能"自己决定调什么"，但决定不了"你有没有资格调"

还有一层更微妙的误判：既然AI Agent能根据用户问题自主决定调哪个工具，是不是说明它"理解"该给用户什么信息？这里必须清醒一点，AI的自主性和数据授权完全是两码事。AI判断"用户想知道A车间的完工率"是意图理解，它判断不了"用户是A车间的操作工还是集团总裁，该不该看这个完工率"。意图理解和数据授权，隔着一条合规和审计的鸿沟。

换句话说，AI是这个链条上最不擅长做权限判断的节点。它的优化目标是"准确回答用户"，它的天性就是要满足提问者。你让一个以"有求必应"为目标的模型去执行"该拒绝就拒绝"的权限策略，等于让厨师去当海关关员，专业技能再强也不顶用。真正靠谱的做法是，让AI把请求完整地传给业务系统，让权限系统对业务系统说"不"，然后AI把"拒绝"翻译成自然语言反馈给用户。权限决策留在企业权限系统里，AI只负责转达和表达。

3. 企业权限系统到底在管什么：以ERP/MES为例

3.1 功能权限之外，还有数据权限和字段权限

很多人理解的权限就是"谁能登录ERP、谁能点某个菜单"，这叫功能权限。但企业权限系统的真正复杂度在数据层。同一个ERP里，分公司A的财务不应该看到分公司B的账，这是数据权限；同一个销售订单报表里，普通业务员不该看到毛利率字段，产品经理不该看到客户联系方式，这是字段权限。权限系统要对数据做分层过滤，这一层是MCP工具列表完全够不着的。

拿MES举例，MES系统通常按工厂、车间、产线、工序组织数据。一个操作工登录MES,看到的是自己所在车间的在制品状态；一个计划员能看整个工厂的排产；集团层的人才能跨工厂看全局。如果AI工作台通过MCP调MES的工单接口，而你在这个接口后面不加数据权限过滤，结果就是：任何能打开AI工作台的人都能问出"全集团所有工厂的工单进度"，产线员工的账号也能看到总裁级的数据范围。这不是危言耸听，我在客户的MES集成测试里就真实复现过这种越权。

再补一个ERP里很典型的场景，热词里有朋友在搜Oracle ERP的PAC成本法。PAC（Period Average Costing）周期平均成本法下，成本计算和分摊逻辑非常敏感，成本数据往往是企业级保密数据。同样一个"查询物料成本"接口，成本会计能看到单位成本和差异分析，普通仓管连成本字段都不该在返回报文里出现。这种按字段粒度的控制，靠MCP Server加几个参数是根本没戏的。

3.2 职责分离：系统权限背后是内控要求

企业权限系统还有一个很多人忽略的硬约束：职责分离，英文叫Separation of Duties，简称SoD。这是审计和内控的基本要求，核心思想是"一个人不能同时拥有互相冲突的权限"。最经典的场景就是采购和付款：下单的人不能同时审批付款，因为如果一个人既能创建采购订单又能审核付款，他就可以虚构供应商、伪造采购、把钱打给自己人。ERP系统里对这类冲突权限有专门的检测规则，管理员定期跑SoD报告。

如果MCP把AI接进来，问题会更复杂。AI工作台天然是一个"全能执行器"：同一个对话里，它可以先查询采购单、再发起付款审批、还能查看供应商银行账号。假如MCP Server背后的API Key没有做职责分离隔离，AI就变成一个有史以来最高效的"内控绕过工具"。你不用担心人有没有权限冲突，AI通过一个超权限的API Key把冲突权限全串起来了。

我见过一个真实案例：某企业给AI工作台开通了MES报工接口和ERP生产订单接口，初衷是让AI帮班长快速录入报工数据。但API Key权限过大，AI不仅能报工，还能改工艺参数、能下生产订单、能查成本。一旦出问题，责任根本说不清楚。这就是权限系统存在的意义：不是为了让流程变慢，而是为了让每一个操作具备可追溯的资格边界和义务边界。

3.3 审计和合规，是权限系统存在的硬理由

最后一条硬理由，叫审计和合规。制造企业面临各种内审、外审、体系审核，每次有重大操作，都要能回答一个问题：谁在什么时间，用什么账号，对哪笔数据做了什么操作？企业权限系统配合审计日志，把这个问题回答得清清楚楚。

MCP这一层很难给你这个答案。MCP Server的日志里记录的是工具调用时间、工具名、参数、返回状态，它不太容易记录"终端用户的工号、登录设备、在业务流程中处于哪个节点"。即使你让MCP Server打日志，日志里也缺一个可信的身份字段。更麻烦的是，如果权限决策不是按真正的用户身份做的，审计追踪到一半就断了：你知道AI工作台调了"查询供应商报价"这个工具，但你不知道是哪个用户在什么理由下查询的，这个日志就失去了审计价值。

从这个角度说，企业权限系统不是可选的，它是企业数字化的基础设施。MCP这类协议解决的是效率问题，权限系统解决的是责任问题。效率再高，责任不能丢。丢了责任，企业连正常经营都站不住脚。

4. 踩坑实录：MCP接入权限系统时最容易翻车的4个场景

4.1 共享API Key引发的越权事故

先说最经典的坑：MCP Server里配置一个共享服务账号的API Key，整个公司所有的AI工作台请求都走这个账号。表面上省事，实际上是把所有用户的权限边界全部抹平。举个例子，一线操作工用AI工作台问MES"今天的产出多少"，系统返回的是全厂的产出数据，因为MCP Server背后的服务账号能看到全厂数据，所以所有用户看到的都是全厂数据。

这种事故的可怕之处在于，它不是偶发故障，而是结构性漏洞。你没法通过"改某个用户的权限"来修复，因为所有请求已经混在一个池子里了。我遇到过一个更极端的：MCP Server用的服务账号竟然有ERP的接口维护权限，AI在工作台里被引导调用了创建接口的工具，直接生成了一张错误的采购申请单，事后追责怎么也查不到具体是谁让AI干的。

4.2 身份链断裂：系统知道是"AI"，不知道是"谁"

第二个坑是身份链断裂。MCP调用链路的尽头，ERP和MES系统看到的是一个服务账号在调用API，它们无从得知真正的请求者是哪个终端用户。业务系统想按用户维度做数据隔离，结果传过来的身份字段是"mcp-server-robot"，所有用户都变成同一个机器人。

后果很直观：你没法在MES里配置"某个用户只能看某个车间"，因为MES根本识别不出终端用户。这个问题的根子是MCP协议默认不传递终端用户身份，你需要自己在应用层做上下文注入，把当前登录用户的工号、部门、角色一路透传到业务系统的API请求头里。不做这一步，所谓的"AI工作台"对ERP/MES来说就是一堆无差别的机器人请求。

4.3 MCP Server成了明晃晃的权限黑洞

第三个坑是MCP Server自己变成权限黑洞。很多团队把MCP Server当成一个常规微服务，部署在默认网络区域，暴露了不必要的端口，安全组开得过于宽松，日志没有集中收集，密钥管理靠配置文件写死。结果MCP Server从集成组件变成了攻击面，一旦被攻破，攻击者等于拿到了一个业务系统后门。

我见过一个工厂的MCP Server，部署在一台无域控、无加固的Windows机器上，跑着Administrator权限，配置文件里明文存着好几个系统的连接字符串。当时测试的温控工程师只要打开这台机器的桌面，就能看到全厂所有生产系统的账密。这个级别的安全隐患，跟MCP协议本身没关系，但确实是"接入AI工作台"这个动作带进来的，很多企业做完集成后根本没有对MCP Server做等保加固和访问控制。

4.4 日志链断裂，出事后找不着人

第四个坑是审计追溯。MCP调用日志和业务系统操作日志如果不做关联，出事之后根本还原不了现场。MCP Server的日志里有一个工具调用时间、有一个请求参数，ERP系统日志里有服务账号的API访问记录，但两个日志系统之间没有任何traceId贯穿，你无法把"AI工作台某次提问"和"ERP里某笔生产订单被修改"对上号。

我处理过一次客户投诉的数据泄露排查：疑似有员工通过AI工作台导出了竞品分析数据，但审计时发现MCP日志里只有一条"工具调用成功"的笼统记录，连参数详情都没有，更不用说当时是哪个用户在提问。最后只能靠人工访谈排查，白白花了两周时间。如果一开始就在MCP调用链里埋好统一的请求ID和用户身份字段，这个排查五分钟就能定位。

5. 正确姿势：MCP做连接，权限系统做裁决

5.1 权限下放：业务系统才是真正的裁决点

既然MCP做不了权限，那正确做法就很清晰了：MCP Server只做协议转换和请求转发，权限裁决永远下放到ERP/MES业务系统本身。MCP Server手里不应该握有"能查一切"的超管Key，它持有的应该是业务系统里一个经过严格裁剪的、与具体工具能力一一对应的服务账号。

这里有一个实操原则：MCP Server里的服务账号权限，必须小于等于"这个Server暴露的所有工具所需的最小权限集合"。比如Server暴露了"查询工单进度"和"报工录入"两个工具，那服务账号在MES里只需要分配这两个菜单的对应接口权限，别的权限一律不给。这样即使MCP Server被人为攻破或者被越权调用，攻击面也被限制在已经暴露的工具范围内，不至于整个ERP数据裸奔。

5.2 把用户身份上下文一路传到底

权限要准，身份必须先到位。正确做法是在AI工作台入口完成用户认证，认证成功后把用户身份（工号、部门、角色、区域）塞进MCP调用链的上下文里，通过MCP请求扩展字段一路传给MCP Server，再由MCP Server转换成业务系统API的身份请求头。

这个链条里要注意一个安全细节：MCP Server不能盲目信任AI工作台传过来的用户身份，它应该把用户身份基础设施里签发的认证凭证（比如短效token或JWT）一并带上，业务系统收到请求后需要验签和校验有效期。这样身份信息在链路里是可信的、可追溯的，而不是"客户端说谁就是谁"。我见过有的团队直接让AI工作台把用户名作为普通参数传给MCP Server，业务系统也照单全收，这就是典型的逻辑漏洞，任何人改个参数就能冒充别人。

5.3 MCP Server侧的工具级最小权限

MCP Server这一层也不是彻底放弃管控，它应该做工具级的最小权限控制：每个用户角色在MCP Server上可见的工具列表不同，未授权工具直接不暴露。这层控制不是替代企业权限系统，而是给业务系统减负，在入口处就过滤掉明显越权的请求。

举个例子，操作工角色的MCP工具列表里只有"查询本车间工单"和"提交报工"；车间主任多一个"查询全部工单"和一个"发起返工"；集团高管多一个"跨厂查询工时效率"。这些工具清单可以和企业的角色主数据联动，角色调整了，工具清单跟着变。你可以在MCP Server里维护一张"角色-工具-业务系统权限点"的映射表，每次发布新工具先过一遍映射关系，确认无误再上线。

5.4 审计日志统一收口

再一个绕不开的环节：日志。MCP Server、AI工作台、业务系统，三方日志必须做统一收口。最直接的做法是引入一个全局traceId，AI工作台发起一次请求时生成，贯穿MCP调用链，一路透传到业务系统的响应头里，三个系统都按这个traceId记录日志。日志里必须包含：用户工号、工具名、参数摘要、业务系统返回状态、响应时长、统一的时间戳。

这个设计看起来费一点功夫，但排查问题的效率能翻好几倍。有一次客户那边反馈"AI工作台报工重复"，我第一反应是让运维把traceId拉出来，一秒定位到是MCP Server的超时重试机制导致同一条报工提交了两次。没有统一日志的话，这种问题通常要前后端扯皮半天。审计人员来检查的时候，你直接按traceId导出一串完整调用链，清晰得很。

5.5 从零落地：一套可以直接照搬的步骤

最后给一套可以照着做的落地步骤，适用于大多数用AI工作台接ERP/MES的企业：

第一步，梳理AI工作台要暴露的用例清单，精确到"哪个角色、要通过AI完成什么业务动作、涉及ERP/MES的哪些接口"。 第二步，针对每个用例，在业务系统里创建独立的API服务账号，权限用最小集，每个账号对应一段明确的业务场景，不要复用。 第三步，在MCP Server里为每个接口建立工具定义，同时建立"角色-工具"映射表，明确谁的工具列表里有什么。 第四步，改造AI工作台的认证模块和MCP客户端，让用户身份以安全凭证形式贯穿调用链，凭证需要被业务系统验证。 第五步，在AI工作台、MCP Server、业务系统三层统一接入traceId日志，测试阶段全链路演练权限隔离和越权阻断。 第六步，上线后定期复核服务账号权限，每三个月做一次工具清单和角色映射的对照检查，防止权限随人员变动逐渐失控。

6. 给企业集成者的实操建议和自查清单

6.1 不同规模企业怎么选式

如果你是在小微企业做AI集成，系统少、用户少、流程短，第一版可以用简化方案：MCP Server持有业务系统的最小权限Key，AI工作台只做只读类查询，暂不做写操作。这种模式先把价值跑出来，坏人风险相对可控。但我要提醒一点：就算规模小，也不要让MCP Server持有超管Key，哪怕只有一个员工在用，也不行。安全习惯是从小就养成的，权限收敛从一开始就要做，不要等出事再补。

中大型企业尤其是制造集团，建议认真做身份上下文传递和审计收口。这块的投入不是可有可无，而是安全底线。集团型企业里，数据跨法人、跨工厂、跨成本域，权限模型本来就很复杂，AI一旦接进去，如果没有严格的权限透传，一次越权查询就可能把整个集团的敏感数据暴露给一个车间操作工。这种场景下，不要急着让AI"什么都干"，先把权限边界画清楚，再一点点放开。

6.2 上线前自查清单

这里列一份自查清单，你可以直接在项目上线前对照检查：

• 是否所有MCP Server的服务账号都按最小权限配置，杜绝超管Key？
• 是否测试过"无权限用户通过AI工作台直接调用敏感工具"的越权场景？
• 用户身份是否以可信凭证全程透传到业务系统，业务系统是否验证？
• AI工作台发起的写操作（报工、审批、下单）是否有事前的二次确认？
• 三类日志（AI工作台、MCP Server、业务系统）是否有统一traceId关联？
• 是否定义了MCP Server的部署网络安全策略，是否明确哪些IP可访问？
• 是否有工具清单的定期复核机制，人员角色变化时工具权限能否同步？

我在好几个客户项目里都是用这份清单做上线检查的，每次都至少能查出两三条问题。最常见的还是服务账号权限过大和日志链路缺失这两项，几乎成了行业通病。

6.3 常见问题速查表

最后说点我自己的体会。MCP是个好东西，它把AI和业务系统之间的连接成本打下来了，让"AI工作台"不再只是聊天的玩具，而是真能伸手干活的生产力工具。但它好就好在"做好连接"这件事上，一旦越界去管权限，你得到的不是一个更聪明的权限系统，而是一个更危险的漏洞。每次做这类集成，我都会提醒团队的伙伴们：先定身份，再定权限，最后才谈智能。顺序反了，后面全得返工。我也建议做企业管理软件的朋友们别焦虑，AI不会代替ERP和MES，也不会代替权限系统，它会成为这些老系统的新入口，而权限这层始终是入口前面的那道闸机——它必须还在。