1. 从一个真实场景说起AI工作台直连ERP之后发生了什么去年下半年我帮一家做电子元器件分销的客户做AI工作台的落地。他们的诉求很朴素销售在AI工作台里用自然语言问一句“华东区上个月A类客户的回款情况”系统自动去ERP里拉数据、算指标、生成图表。听起来是个标准的Text-to-SQL加数据看板的需求团队两周就把链路跑通了——AI工作台通过MCP协议挂载了ERP的数据查询接口模型解析意图后调用工具结果回传渲染。上线第三天出事了。一个销售的账号在凌晨两点批量调用了库存查询接口频率是每分钟四十多次把ERP的应用服务器连接池打满了第二天早班整个订单模块响应超时。运维查日志才发现AI工作台调用ERP用的是同一个服务账号所有终端用户共享一套凭证根本分不清是谁在调、调了什么、为什么调这么频繁。更麻烦的是这个服务账号的权限是当初为了图省事直接给的“全模块只读”意味着任何一个销售理论上都能通过精心构造的提问把成本价、供应商底价这类敏感字段套出来。这件事之后客户的技术负责人问了我一个问题也是这篇文章要展开的核心AI工作台已经连上ERP了接口能通、数据能取为什么还要在中间加一层权限与审计网关这个问题不是个例。我后来陆续接触了七八个类似项目涉及制造业、零售、医药流通用的ERP有国产的也有海外的AI工作台侧有的走MCP有的走自研的AI系统连接器但踩的坑高度相似。大家一开始的关注点都在“怎么连上”——MCP是什么、怎么把REST接口快速转成MCP工具、playwright mcp怎么做自动化——等连通性解决了才发现真正的难题在连通之后谁在用AI访问ERP、访问的边界在哪、出了事能不能追溯。这篇文章适合三类人看正在做AI工作台与ERP集成的一线开发和架构师、负责企业数据安全与合规的技术管理者、以及刚开始接触MCP协议想搞清楚它在企业级场景里到底该怎么用的工程师。我会把权限与审计网关这层为什么必须存在、它具体解决什么问题、怎么落地实现结合我实际项目里的配置和踩坑记录尽量讲透。2. 先搞清楚AI工作台连ERP连的到底是什么2.1 MCP在中间扮演的角色以及它不负责什么MCPModel Context Protocol是让大模型能够标准化调用外部工具的一套协议。你可以把它理解成“AI世界的USB接口”——以前每个AI应用要调ERP都得自己写一套适配代码现在只要ERP侧暴露一个符合MCP规范的服务端AI工作台侧就能像插U盘一样把工具挂上去。热词里出现的“java rest接口快速转为mcp接口”“playwright mcp自动化0到1”说的就是这类适配工作。但这里有个认知误区必须点破MCP解决的是“能不能调”的问题它不解决“该不该调、谁在调、调了多少”的问题。MCP协议本身对认证授权有基础定义但在企业实际部署中这些基础能力远远不够。原因在于MCP的设计初衷是让模型方便地发现和使用工具它的默认信任模型偏向“工具提供方信任调用方”而企业ERP场景恰恰相反——ERP是核心资产它对任何调用方都应该是零信任的。我见过一个典型的错误做法把ERP的数据库账号密码直接配在MCP服务端的配置文件里AI工作台通过MCP调用时服务端拿这个账号去查库。这样做的结果是ERP侧看到的永远是同一个数据库用户审计日志里全是这个账号的操作终端用户是谁完全丢失。这就是为什么“ai账号工作台”这类词会跟“已损坏、无法打开”一起出现在热搜里——很多时候不是工作台本身坏了是底层的账号体系混乱导致整个链路不可用。2.2 ERP侧的真实约束不是所有接口都适合开放给AIERP系统无论是易飞、Oracle ERP还是其他它们的接口设计初衷是给确定的业务系统调用的不是给一个概率性的、会自由组合工具调用的AI准备的。这里面有几个硬约束第一接口的粒度问题。ERP的REST接口往往是粗粒度的比如一个“查询销售订单”接口返回的字段可能包含成本、利润、客户信用等级等敏感信息。AI工作台为了回答一个简单问题可能只需要其中三四个字段但接口一调全部字段都出来了。如果没有网关做字段级过滤敏感数据就在模型上下文里裸奔。第二调用频率与事务边界。ERP的数据库连接、应用服务器线程都是有限资源。AI工作台的一个复杂提问可能触发模型连续调用多个工具形成调用链。如果没有频率控制和事务边界管理一个用户的提问就可能拖垮整个ERP。前面提到的凌晨批量调用就是这个问题。第三语义歧义带来的误操作。AI工作台如果挂载了写操作接口比如“创建采购订单”“修改客户信用额度”模型对自然语言的理解偏差可能导致误操作。我遇到过用户说“把这个订单取消掉”模型理解成“删除订单记录”直接调了删除接口。这种场景下网关必须有能力区分读写、对写操作做二次确认或人工审批。2.3 权限与审计网关的定位AI与ERP之间的“海关”把权限与审计网关理解成AI工作台和ERP之间的海关这个类比很贴切。海关不生产货物也不消费货物但它做三件事验证通行者身份、检查携带物品是否合规、记录所有进出境行为。对应到技术层面身份验证与映射把AI工作台的终端用户身份映射成ERP能识别的、有明确权限边界的身份。不是共享一个服务账号而是每个用户或每类角色有独立的身份标识。权限校验与字段过滤在请求到达ERP之前判断这个用户有没有权限调这个接口、能看哪些字段、能执行什么操作。无权限的请求直接拦截有权限的请求按最小必要原则裁剪数据。全链路审计记录谁、在什么时间、通过什么AI工作台、以什么自然语言意图、调用了哪个ERP接口、传了什么参数、返回了什么结果、耗时多少、是否成功。这些记录要能关联到具体的终端用户而不是一个模糊的服务账号。这层网关不是ERP自带的也不是AI工作台自带的它必须是一个独立的、介于两者之间的组件。原因很简单ERP的权限体系是为传统客户端设计的它不理解AI工作台的用户模型AI工作台的权限体系是为模型调用设计的它不理解ERP的业务语义。网关是两者的翻译官和仲裁者。3. 为什么不能把权限控制做在AI工作台里3.1 AI工作台的权限模型与ERP权限模型的错位AI工作台通常有自己的用户体系可能是基于角色的管理员、普通用户、访客也可能是基于租户的。它的权限控制粒度往往是“能不能用这个AI功能”“能不能访问这个知识库”。而ERP的权限模型是业务导向的能不能看这个客户的订单、能不能改这个物料的库存、能不能审批这个金额的付款单。这两套模型的语言都不一样。如果硬要把ERP权限塞进AI工作台意味着要在AI工作台里重建一套ERP权限映射而且每次ERP权限调整都要同步。我试过在一个项目里这么做结果是维护成本极高而且因为AI工作台的开发团队不熟悉ERP的业务规则映射经常出错。更致命的是AI工作台本身可能被绕过——用户直接调MCP服务端的接口不经过工作台的权限检查。3.2 审计的完整性要求独立记录点审计的核心要求是不可抵赖和完整关联。如果审计日志由AI工作台自己记录那么工作台被攻破或配置错误时日志可能被篡改或丢失。而且工作台记录的日志只包含它自己知道的信息比如它调了哪个MCP工具但工具内部又调了哪些ERP接口、传了什么参数工作台是不知道的。独立的审计网关在链路上处于必经之路所有请求必须经过它才能到达ERP。它记录的日志是“所见即所得”的——请求原样进来响应原样出去中间没有经过任何可能篡改的环节。这种独立性是合规审计的基本要求。3.3 一个反例当AI工作台直接持有ERP凭证我见过最危险的做法是把ERP的API Key直接配置在AI工作台的MCP客户端配置里。这样做的直接后果是任何能访问AI工作台配置文件的人都能拿到ERP凭证。凭证轮换时需要同时更新AI工作台和所有相关配置容易遗漏。ERP侧无法区分请求来自哪个终端用户审计日志形同虚设。一旦AI工作台被入侵攻击者直接获得ERP的访问权限没有第二道防线。权限与审计网关的存在让AI工作台永远不持有ERP的真实凭证。工作台只知道网关的地址和它自己的身份凭证网关持有ERP凭证并在验证通过后代理请求。这样即使工作台被攻破攻击者也只能通过网关的权限校验无法直接触达ERP。4. 权限与审计网关的核心能力拆解4.1 身份映射从AI用户到ERP用户的三层转换身份映射是网关最基础也最容易做错的部分。我把它拆成三层第一层终端用户身份识别。AI工作台在调用网关时必须携带终端用户的身份标识。这个标识可以是工作台自己的用户ID也可以是统一的SSO标识。关键是这个标识要能唯一对应到一个自然人。如果工作台支持多租户还要带上租户标识。第二层角色与权限组映射。网关根据终端用户身份查找预配置的映射规则确定这个用户在ERP侧对应什么角色。比如“销售经理”映射到ERP的“销售订单查询角色”加“客户信息只读角色”。这个映射关系应该由ERP管理员和业务负责人共同维护而不是由AI团队拍脑袋决定。第三层ERP凭证注入。网关根据映射结果使用对应的ERP凭证或ERP支持的委托授权机制向ERP发起请求。这里有个关键设计选择是每个ERP角色一个凭证还是每个终端用户一个ERP凭证前者管理简单但审计粒度粗后者审计精细但凭证管理复杂。我的经验是对于大多数企业场景按角色分配ERP凭证加终端用户标识透传是平衡点——ERP侧看到的是角色账号但请求头里带有终端用户标识审计日志可以关联到人。下面是一个身份映射配置的示例结构用YAML表示identity_mapping: - ai_user_pattern: sales_* erp_role: SALES_QUERY erp_credential_ref: vault://erp/sales_query allowed_tools: - erp.query_sales_order - erp.query_customer field_filters: erp.query_sales_order: exclude: [cost_price, profit_margin, supplier_base_price] erp.query_customer: exclude: [credit_rating, bank_account] - ai_user_pattern: finance_* erp_role: FINANCE_FULL erp_credential_ref: vault://erp/finance_full allowed_tools: - erp.query_sales_order - erp.query_customer - erp.query_payment field_filters: {}这个配置的意思是销售类用户只能调销售订单和客户查询工具且成本价、利润率、供应商底价、信用等级、银行账号这些字段被过滤掉财务类用户可以调更多工具且不做字段过滤。凭证从密钥管理服务动态获取不落盘。4.2 工具级与字段级权限控制工具级权限控制相对直观这个用户能不能调这个MCP工具。但字段级控制才是真正体现网关价值的地方。ERP接口返回的JSON往往嵌套很深字段过滤需要支持路径表达式。我通常用JSONPath或类似的表达式来定义过滤规则。比如要过滤掉销售订单响应里每个订单行的成本字段规则可以写成$.data.orders[*].items[*].cost_price网关在收到ERP响应后按规则删除这些路径的字段再把裁剪后的结果返回给AI工作台。这样做的好处是AI工作台和模型完全感知不到被过滤字段的存在从源头上杜绝了敏感信息进入模型上下文。这里有个实操心得字段过滤规则要支持继承和覆盖。基础规则定义所有角色都不能看的字段比如密码、密钥角色规则在此基础上追加。这样新增角色时不用重复定义基础规则减少遗漏。4.3 调用频率与配额管理频率控制不是简单的限流它要结合AI工作台的特点。AI工作台的调用模式跟传统客户端不同一个用户提问可能触发一串工具调用这些调用在时间上很集中。如果按传统的每秒请求数限流很容易误伤正常提问。我的做法是按会话维度做配额。每个用户会话一次提问到回答完成分配一个调用预算比如最多调20次ERP接口、总耗时不超过30秒。网关在会话开始时初始化计数器每次调用扣减超预算直接拒绝并返回明确错误。这样既能防止单个提问失控又不会因为瞬时并发误伤。另外写操作要单独限流且更严格。读操作可以宽松些写操作我通常设置每分钟不超过5次且要求二次确认。对于高风险写操作删除、批量修改直接走人工审批流网关挂起请求等审批通过后再放行。4.4 全链路审计日志的设计要点审计日志要回答六个问题Who谁、When何时、Where从哪个工作台、What调了什么、How怎么调的、Result结果如何。日志结构我一般设计成{ trace_id: a1b2c3d4-..., timestamp: 2025-01-15T14:23:01.123Z, ai_workspace: sales-assistant-v2, ai_user_id: zhangsancompany.com, ai_session_id: sess-789, natural_language_intent: 查询华东区上月A类客户回款, erp_role: SALES_QUERY, erp_tool: erp.query_payment, erp_request: { method: POST, path: /api/payment/query, params: {region: east, month: 2024-12, customer_level: A} }, erp_response_status: 200, erp_response_time_ms: 342, fields_filtered: [$.data[*].bank_account], result_summary: 返回23条记录已过滤银行账号字段 }几个设计要点trace_id贯穿全链路从AI工作台发起请求到ERP返回所有环节用同一个trace_id方便串联。natural_language_intent要记录这是AI场景特有的审计维度。传统系统审计只看接口调用但AI场景下同一个接口调用可能源于完全不同的用户意图记录意图对事后分析至关重要。fields_filtered要记录证明网关执行了数据保护策略这是合规审计的证据。日志要异步写入且不可篡改。我通常用消息队列解耦日志写入独立的存储设置只追加权限定期归档到冷存储。5. 落地实操从零搭建一个权限与审计网关5.1 技术选型与部署形态网关的技术选型取决于团队的技术栈和ERP的部署位置。我经历过三种典型形态形态一独立微服务。用Java Spring Cloud Gateway或Node.js Express写一个独立服务部署在AI工作台和ERP之间的网络区域。优点是灵活、可控缺点是团队要自己维护高可用和性能。适合中大型企业有专门的中间件团队。形态二API网关插件。如果企业已经有Kong、APISIX这类API网关可以开发自定义插件实现权限与审计逻辑。优点是复用现有网关的高可用和运维体系缺点是插件开发受限于网关的扩展机制。适合已有API网关基础设施的企业。形态三Service Mesh Sidecar。在Kubernetes环境下把网关逻辑做成Sidecar注入到ERP的访问路径上。优点是网络层透明对应用无侵入缺点是调试复杂且需要ERP容器化。适合云原生程度高的企业。我个人的偏好是形态一因为AI场景的权限逻辑变化快独立服务迭代更灵活。部署上至少两个实例做高可用前面挂负载均衡配置从配置中心动态拉取支持热更新。5.2 与MCP服务端的集成方式网关和MCP服务端的关系需要理清。有两种集成模式模式A网关在MCP服务端之前。AI工作台先调网关网关校验通过后网关再以MCP客户端的身份调MCP服务端。这种模式下MCP服务端只信任网关AI工作台不直接接触MCP服务端。优点是安全边界清晰缺点是网关要理解MCP协议。模式B网关在MCP服务端之后。MCP服务端暴露工具AI工作台直接调MCP服务端MCP服务端在调用ERP之前经过网关。这种模式下网关更像一个ERP的代理。优点是MCP服务端不用改缺点是AI工作台和MCP服务端之间的调用没有审计。我推荐模式A因为审计的完整性要求网关在必经之路上。具体实现时网关需要实现MCP客户端的握手、工具发现、工具调用等流程。如果MCP服务端支持自定义认证头网关在调用时注入终端用户标识和trace_id。5.3 关键配置一个完整的网关策略示例下面是一个相对完整的网关策略配置涵盖身份映射、工具权限、字段过滤、频率控制gateway_policy: version: 1.0 identity: header_name: X-AI-User-Id session_header: X-AI-Session-Id workspace_header: X-AI-Workspace intent_header: X-AI-Intent rate_limit: per_session: max_calls: 20 max_duration_seconds: 30 per_user_per_minute: read: 30 write: 5 audit: enabled: true async: true queue: audit-queue include_request_body: true include_response_body: false mask_fields: [password, token, secret] roles: - name: SALES_QUERY erp_credential: vault://erp/sales_query tools: - name: erp.query_sales_order field_filters: exclude: - $.data.orders[*].items[*].cost_price - $.data.orders[*].items[*].supplier_base_price - name: erp.query_customer field_filters: exclude: - $.data[*].credit_rating - $.data[*].bank_account write_tools: [] - name: FINANCE_FULL erp_credential: vault://erp/finance_full tools: - name: erp.query_sales_order - name: erp.query_customer - name: erp.query_payment write_tools: - name: erp.create_payment_voucher require_approval: true approval_webhook: https://approval.internal/api/v1/request这个配置里require_approval: true表示写操作需要审批网关会挂起请求并调用审批系统的webhook审批通过后继续执行。vault://前缀表示凭证从密钥管理服务动态获取不写在配置文件里。5.4 审批流的实现细节写操作的审批流是网关里比较复杂的部分。我的实现方式是网关收到写操作请求先做权限校验和频率检查。校验通过后生成一个审批单包含请求详情、发起人、AI会话上下文、trace_id。调用审批系统的接口把审批单推送给对应的审批人。网关挂起请求返回一个“待审批”状态给AI工作台。审批人通过后审批系统回调网关网关继续执行原请求。审批拒绝或超时网关返回拒绝结果。这里有个坑AI工作台的超时设置。如果审批需要几分钟AI工作台的HTTP连接可能已经超时了。解决办法是网关返回一个异步任务IDAI工作台轮询或通过回调获取结果。这要求AI工作台侧支持异步工具调用不是所有工作台都支持。如果不支持就只能对写操作设置较短的审批超时或者干脆禁止AI工作台直接发起写操作只允许它生成“操作建议”由人工在ERP里执行。6. 常见问题与排查技巧实录6.1 连接类问题速查现象可能原因排查步骤解决方式AI工作台报“账号工作台已损坏无法打开”网关返回了非预期格式的错误响应工作台解析失败抓包看网关返回的HTTP状态码和body统一错误响应格式网关异常时返回标准JSON错误ERP连接超时网关到ERP的网络不通或ERP连接池满从网关所在机器telnet ERP端口查ERP连接池监控检查网络策略调整网关到ERP的连接池配置MCP工具列表为空网关未正确转发MCP的工具发现请求查网关日志中MCP initialize和tools/list的转发记录确认网关实现了MCP客户端握手流程字段过滤不生效JSONPath表达式与实际响应结构不匹配打印ERP原始响应对照过滤规则逐层验证用在线JSONPath测试工具验证表达式注意数组通配符6.2 权限类问题排查问题用户反馈“我明明有权限为什么AI说我没权限”排查思路先确认用户在ERP里的权限再确认网关的角色映射配置。常见原因是角色映射的通配符写错了比如sales_*匹配不到sales_manager_zhangsan因为中间还有下划线。另一个常见原因是ERP凭证对应的角色权限不足网关映射的角色和ERP凭证实际权限不一致。问题审计日志里找不到某次操作。排查思路确认请求是否真的经过了网关。如果AI工作台配置了直连MCP服务端的备用路径请求可能绕过了网关。检查AI工作台的MCP配置确保所有ERP相关工具都指向网关地址。另外检查审计日志的异步队列是否积压日志可能还没落盘。6.3 性能类问题网关作为中间层必然引入延迟。我的实测数据是一个简单的权限校验加字段过滤额外延迟在5到15毫秒之间。如果延迟超过50毫秒通常是以下原因凭证从密钥管理服务获取时没有缓存每次请求都去拉。解决办法是凭证缓存设置合理的TTL比如5分钟。字段过滤用了低效的JSON解析库对大响应体处理慢。换成流式JSON处理器或者对超过一定大小的响应做采样过滤。审计日志同步写入阻塞了主流程。改成异步写入用内存队列缓冲。6.4 几个我踩过的坑坑一把网关做成了单点。早期项目里网关只部署了一个实例结果网关重启时AI工作台完全不可用。后来改成至少双实例加健康检查滚动更新。坑二字段过滤规则写得太死。一开始把字段路径硬编码在代码里ERP接口一升级字段结构变了过滤就失效。后来改成配置化且加了单元测试每次ERP接口变更都跑一遍过滤规则测试。坑三忽略了MCP的流式输出。热词里有“使用mcp工具流式输出内容到文件”MCP支持流式返回。如果网关按普通HTTP响应处理会把流式响应缓冲成完整响应再返回破坏了流式特性。解决办法是网关对MCP的流式响应做透传不缓冲同时审计日志记录流式响应的摘要而非全文。坑四审批流的回调地址配错。审批系统回调网关时用了内网地址但审批系统在另一个网络区域回调不通。后来统一用服务发现的内网域名并加了回调重试机制。7. 这套网关方案还能怎么扩展权限与审计网关的定位决定了它有很强的扩展性。我在不同项目里基于这个架构做过这些扩展扩展一敏感数据动态脱敏。除了静态的字段过滤还可以根据用户角色和请求上下文做动态脱敏。比如同样是客户手机号销售看到的是完整号码客服看到的是中间四位掩码。规则引擎根据角色和字段敏感等级实时决定脱敏策略。扩展二AI意图风险评分。网关可以接入一个轻量模型对natural_language_intent做风险评分。比如“查询所有客户的银行账号”这种意图风险分高网关可以自动降级为只返回汇总数据或者触发人工审核。这个扩展对防范提示注入攻击特别有用。扩展三与ERP的PAC成本法审计对接。热词里提到“oracle erp pac成本法”PAC是Periodic Average Cost定期平均成本法。在采用PAC成本法的ERP里成本数据的查询和修改有严格的期间控制。网关可以对接ERP的成本期间状态在成本未结算期间禁止AI工作台查询成本明细避免未结算数据泄露。扩展四多ERP的统一网关。大型企业往往有多个ERP系统比如国内用一套、海外用一套。网关可以做成多租户的根据用户所属组织路由到不同的ERP同时保持统一的权限模型和审计格式。这样AI工作台只需要连一个网关地址不用关心后端有几个ERP。扩展五审计日志的智能分析。审计日志积累到一定量后可以用它来训练异常检测模型。比如某个用户突然在非工作时间大量查询敏感字段或者某个AI会话的调用模式偏离历史基线网关可以实时告警甚至自动阻断。这比传统的规则引擎更适应AI场景的动态性。8. 最后分享几个实操中的小技巧关于凭证管理我的经验是永远不要在配置文件里写明文凭证哪怕是在测试环境。用密钥管理服务或者至少用环境变量注入。我见过太多因为配置文件泄露导致ERP被访问的案例。关于字段过滤先做加法再做减法。意思是先定义每个角色能看到哪些字段白名单而不是先定义不能看哪些字段黑名单。白名单更安全因为ERP新增字段时默认不可见不会因为忘记加黑名单而泄露。关于审计日志的存储至少保留180天金融和医药行业建议保留一年以上。日志要加密存储访问日志本身也要有审计防止内部人员篡改。关于网关的测试一定要做混沌测试。模拟ERP超时、网关实例宕机、密钥管理服务不可用等场景验证AI工作台的降级行为是否符合预期。我做过一次混沌测试发现ERP超时时网关没有正确返回错误码导致AI工作台一直重试反而加剧了ERP的负载。后来加了熔断机制才解决。关于和业务部门的沟通权限映射规则一定要让业务负责人签字确认。技术团队不要自己决定“销售经理应该能看什么”这是业务决策。我吃过这个亏技术团队按自己的理解配了权限结果业务部门发现销售能看到不该看的客户信息追责时技术团队背了锅。后来改成权限映射表由业务负责人审批技术团队只负责实现。这套网关方案从第一个项目到现在前后迭代了两年多配置结构改了四版踩的坑基本都在这篇文章里了。如果你正在做类似的事情希望这些经验能帮你少走点弯路。 
长河君 · 2026/10/26 8:29:38 · 阅读 1.2k AI工作台直连ERP后为何必须加权限与审计网关？
1. 从一个真实场景说起AI工作台直连ERP之后发生了什么去年下半年我帮一家做电子元器件分销的客户做AI工作台的落地。他们的诉求很朴素销售在AI工作台里用自然语言问一句“华东区上个月A类客户的回款情况”系统自动去ERP里拉数据、算指标、生成图表。听起来是个标准的Text-to-SQL加数据看板的需求团队两周就把链路跑通了——AI工作台通过MCP协议挂载了ERP的数据查询接口模型解析意图后调用工具结果回传渲染。上线第三天出事了。一个销售的账号在凌晨两点批量调用了库存查询接口频率是每分钟四十多次把ERP的应用服务器连接池打满了第二天早班整个订单模块响应超时。运维查日志才发现AI工作台调用ERP用的是同一个服务账号所有终端用户共享一套凭证根本分不清是谁在调、调了什么、为什么调这么频繁。更麻烦的是这个服务账号的权限是当初为了图省事直接给的“全模块只读”意味着任何一个销售理论上都能通过精心构造的提问把成本价、供应商底价这类敏感字段套出来。这件事之后客户的技术负责人问了我一个问题也是这篇文章要展开的核心AI工作台已经连上ERP了接口能通、数据能取为什么还要在中间加一层权限与审计网关这个问题不是个例。我后来陆续接触了七八个类似项目涉及制造业、零售、医药流通用的ERP有国产的也有海外的AI工作台侧有的走MCP有的走自研的AI系统连接器但踩的坑高度相似。大家一开始的关注点都在“怎么连上”——MCP是什么、怎么把REST接口快速转成MCP工具、playwright mcp怎么做自动化——等连通性解决了才发现真正的难题在连通之后谁在用AI访问ERP、访问的边界在哪、出了事能不能追溯。这篇文章适合三类人看正在做AI工作台与ERP集成的一线开发和架构师、负责企业数据安全与合规的技术管理者、以及刚开始接触MCP协议想搞清楚它在企业级场景里到底该怎么用的工程师。我会把权限与审计网关这层为什么必须存在、它具体解决什么问题、怎么落地实现结合我实际项目里的配置和踩坑记录尽量讲透。2. 先搞清楚AI工作台连ERP连的到底是什么2.1 MCP在中间扮演的角色以及它不负责什么MCPModel Context Protocol是让大模型能够标准化调用外部工具的一套协议。你可以把它理解成“AI世界的USB接口”——以前每个AI应用要调ERP都得自己写一套适配代码现在只要ERP侧暴露一个符合MCP规范的服务端AI工作台侧就能像插U盘一样把工具挂上去。热词里出现的“java rest接口快速转为mcp接口”“playwright mcp自动化0到1”说的就是这类适配工作。但这里有个认知误区必须点破MCP解决的是“能不能调”的问题它不解决“该不该调、谁在调、调了多少”的问题。MCP协议本身对认证授权有基础定义但在企业实际部署中这些基础能力远远不够。原因在于MCP的设计初衷是让模型方便地发现和使用工具它的默认信任模型偏向“工具提供方信任调用方”而企业ERP场景恰恰相反——ERP是核心资产它对任何调用方都应该是零信任的。我见过一个典型的错误做法把ERP的数据库账号密码直接配在MCP服务端的配置文件里AI工作台通过MCP调用时服务端拿这个账号去查库。这样做的结果是ERP侧看到的永远是同一个数据库用户审计日志里全是这个账号的操作终端用户是谁完全丢失。这就是为什么“ai账号工作台”这类词会跟“已损坏、无法打开”一起出现在热搜里——很多时候不是工作台本身坏了是底层的账号体系混乱导致整个链路不可用。2.2 ERP侧的真实约束不是所有接口都适合开放给AIERP系统无论是易飞、Oracle ERP还是其他它们的接口设计初衷是给确定的业务系统调用的不是给一个概率性的、会自由组合工具调用的AI准备的。这里面有几个硬约束第一接口的粒度问题。ERP的REST接口往往是粗粒度的比如一个“查询销售订单”接口返回的字段可能包含成本、利润、客户信用等级等敏感信息。AI工作台为了回答一个简单问题可能只需要其中三四个字段但接口一调全部字段都出来了。如果没有网关做字段级过滤敏感数据就在模型上下文里裸奔。第二调用频率与事务边界。ERP的数据库连接、应用服务器线程都是有限资源。AI工作台的一个复杂提问可能触发模型连续调用多个工具形成调用链。如果没有频率控制和事务边界管理一个用户的提问就可能拖垮整个ERP。前面提到的凌晨批量调用就是这个问题。第三语义歧义带来的误操作。AI工作台如果挂载了写操作接口比如“创建采购订单”“修改客户信用额度”模型对自然语言的理解偏差可能导致误操作。我遇到过用户说“把这个订单取消掉”模型理解成“删除订单记录”直接调了删除接口。这种场景下网关必须有能力区分读写、对写操作做二次确认或人工审批。2.3 权限与审计网关的定位AI与ERP之间的“海关”把权限与审计网关理解成AI工作台和ERP之间的海关这个类比很贴切。海关不生产货物也不消费货物但它做三件事验证通行者身份、检查携带物品是否合规、记录所有进出境行为。对应到技术层面身份验证与映射把AI工作台的终端用户身份映射成ERP能识别的、有明确权限边界的身份。不是共享一个服务账号而是每个用户或每类角色有独立的身份标识。权限校验与字段过滤在请求到达ERP之前判断这个用户有没有权限调这个接口、能看哪些字段、能执行什么操作。无权限的请求直接拦截有权限的请求按最小必要原则裁剪数据。全链路审计记录谁、在什么时间、通过什么AI工作台、以什么自然语言意图、调用了哪个ERP接口、传了什么参数、返回了什么结果、耗时多少、是否成功。这些记录要能关联到具体的终端用户而不是一个模糊的服务账号。这层网关不是ERP自带的也不是AI工作台自带的它必须是一个独立的、介于两者之间的组件。原因很简单ERP的权限体系是为传统客户端设计的它不理解AI工作台的用户模型AI工作台的权限体系是为模型调用设计的它不理解ERP的业务语义。网关是两者的翻译官和仲裁者。3. 为什么不能把权限控制做在AI工作台里3.1 AI工作台的权限模型与ERP权限模型的错位AI工作台通常有自己的用户体系可能是基于角色的管理员、普通用户、访客也可能是基于租户的。它的权限控制粒度往往是“能不能用这个AI功能”“能不能访问这个知识库”。而ERP的权限模型是业务导向的能不能看这个客户的订单、能不能改这个物料的库存、能不能审批这个金额的付款单。这两套模型的语言都不一样。如果硬要把ERP权限塞进AI工作台意味着要在AI工作台里重建一套ERP权限映射而且每次ERP权限调整都要同步。我试过在一个项目里这么做结果是维护成本极高而且因为AI工作台的开发团队不熟悉ERP的业务规则映射经常出错。更致命的是AI工作台本身可能被绕过——用户直接调MCP服务端的接口不经过工作台的权限检查。3.2 审计的完整性要求独立记录点审计的核心要求是不可抵赖和完整关联。如果审计日志由AI工作台自己记录那么工作台被攻破或配置错误时日志可能被篡改或丢失。而且工作台记录的日志只包含它自己知道的信息比如它调了哪个MCP工具但工具内部又调了哪些ERP接口、传了什么参数工作台是不知道的。独立的审计网关在链路上处于必经之路所有请求必须经过它才能到达ERP。它记录的日志是“所见即所得”的——请求原样进来响应原样出去中间没有经过任何可能篡改的环节。这种独立性是合规审计的基本要求。3.3 一个反例当AI工作台直接持有ERP凭证我见过最危险的做法是把ERP的API Key直接配置在AI工作台的MCP客户端配置里。这样做的直接后果是任何能访问AI工作台配置文件的人都能拿到ERP凭证。凭证轮换时需要同时更新AI工作台和所有相关配置容易遗漏。ERP侧无法区分请求来自哪个终端用户审计日志形同虚设。一旦AI工作台被入侵攻击者直接获得ERP的访问权限没有第二道防线。权限与审计网关的存在让AI工作台永远不持有ERP的真实凭证。工作台只知道网关的地址和它自己的身份凭证网关持有ERP凭证并在验证通过后代理请求。这样即使工作台被攻破攻击者也只能通过网关的权限校验无法直接触达ERP。4. 权限与审计网关的核心能力拆解4.1 身份映射从AI用户到ERP用户的三层转换身份映射是网关最基础也最容易做错的部分。我把它拆成三层第一层终端用户身份识别。AI工作台在调用网关时必须携带终端用户的身份标识。这个标识可以是工作台自己的用户ID也可以是统一的SSO标识。关键是这个标识要能唯一对应到一个自然人。如果工作台支持多租户还要带上租户标识。第二层角色与权限组映射。网关根据终端用户身份查找预配置的映射规则确定这个用户在ERP侧对应什么角色。比如“销售经理”映射到ERP的“销售订单查询角色”加“客户信息只读角色”。这个映射关系应该由ERP管理员和业务负责人共同维护而不是由AI团队拍脑袋决定。第三层ERP凭证注入。网关根据映射结果使用对应的ERP凭证或ERP支持的委托授权机制向ERP发起请求。这里有个关键设计选择是每个ERP角色一个凭证还是每个终端用户一个ERP凭证前者管理简单但审计粒度粗后者审计精细但凭证管理复杂。我的经验是对于大多数企业场景按角色分配ERP凭证加终端用户标识透传是平衡点——ERP侧看到的是角色账号但请求头里带有终端用户标识审计日志可以关联到人。下面是一个身份映射配置的示例结构用YAML表示identity_mapping: - ai_user_pattern: sales_* erp_role: SALES_QUERY erp_credential_ref: vault://erp/sales_query allowed_tools: - erp.query_sales_order - erp.query_customer field_filters: erp.query_sales_order: exclude: [cost_price, profit_margin, supplier_base_price] erp.query_customer: exclude: [credit_rating, bank_account] - ai_user_pattern: finance_* erp_role: FINANCE_FULL erp_credential_ref: vault://erp/finance_full allowed_tools: - erp.query_sales_order - erp.query_customer - erp.query_payment field_filters: {}这个配置的意思是销售类用户只能调销售订单和客户查询工具且成本价、利润率、供应商底价、信用等级、银行账号这些字段被过滤掉财务类用户可以调更多工具且不做字段过滤。凭证从密钥管理服务动态获取不落盘。4.2 工具级与字段级权限控制工具级权限控制相对直观这个用户能不能调这个MCP工具。但字段级控制才是真正体现网关价值的地方。ERP接口返回的JSON往往嵌套很深字段过滤需要支持路径表达式。我通常用JSONPath或类似的表达式来定义过滤规则。比如要过滤掉销售订单响应里每个订单行的成本字段规则可以写成$.data.orders[*].items[*].cost_price网关在收到ERP响应后按规则删除这些路径的字段再把裁剪后的结果返回给AI工作台。这样做的好处是AI工作台和模型完全感知不到被过滤字段的存在从源头上杜绝了敏感信息进入模型上下文。这里有个实操心得字段过滤规则要支持继承和覆盖。基础规则定义所有角色都不能看的字段比如密码、密钥角色规则在此基础上追加。这样新增角色时不用重复定义基础规则减少遗漏。4.3 调用频率与配额管理频率控制不是简单的限流它要结合AI工作台的特点。AI工作台的调用模式跟传统客户端不同一个用户提问可能触发一串工具调用这些调用在时间上很集中。如果按传统的每秒请求数限流很容易误伤正常提问。我的做法是按会话维度做配额。每个用户会话一次提问到回答完成分配一个调用预算比如最多调20次ERP接口、总耗时不超过30秒。网关在会话开始时初始化计数器每次调用扣减超预算直接拒绝并返回明确错误。这样既能防止单个提问失控又不会因为瞬时并发误伤。另外写操作要单独限流且更严格。读操作可以宽松些写操作我通常设置每分钟不超过5次且要求二次确认。对于高风险写操作删除、批量修改直接走人工审批流网关挂起请求等审批通过后再放行。4.4 全链路审计日志的设计要点审计日志要回答六个问题Who谁、When何时、Where从哪个工作台、What调了什么、How怎么调的、Result结果如何。日志结构我一般设计成{ trace_id: a1b2c3d4-..., timestamp: 2025-01-15T14:23:01.123Z, ai_workspace: sales-assistant-v2, ai_user_id: zhangsancompany.com, ai_session_id: sess-789, natural_language_intent: 查询华东区上月A类客户回款, erp_role: SALES_QUERY, erp_tool: erp.query_payment, erp_request: { method: POST, path: /api/payment/query, params: {region: east, month: 2024-12, customer_level: A} }, erp_response_status: 200, erp_response_time_ms: 342, fields_filtered: [$.data[*].bank_account], result_summary: 返回23条记录已过滤银行账号字段 }几个设计要点trace_id贯穿全链路从AI工作台发起请求到ERP返回所有环节用同一个trace_id方便串联。natural_language_intent要记录这是AI场景特有的审计维度。传统系统审计只看接口调用但AI场景下同一个接口调用可能源于完全不同的用户意图记录意图对事后分析至关重要。fields_filtered要记录证明网关执行了数据保护策略这是合规审计的证据。日志要异步写入且不可篡改。我通常用消息队列解耦日志写入独立的存储设置只追加权限定期归档到冷存储。5. 落地实操从零搭建一个权限与审计网关5.1 技术选型与部署形态网关的技术选型取决于团队的技术栈和ERP的部署位置。我经历过三种典型形态形态一独立微服务。用Java Spring Cloud Gateway或Node.js Express写一个独立服务部署在AI工作台和ERP之间的网络区域。优点是灵活、可控缺点是团队要自己维护高可用和性能。适合中大型企业有专门的中间件团队。形态二API网关插件。如果企业已经有Kong、APISIX这类API网关可以开发自定义插件实现权限与审计逻辑。优点是复用现有网关的高可用和运维体系缺点是插件开发受限于网关的扩展机制。适合已有API网关基础设施的企业。形态三Service Mesh Sidecar。在Kubernetes环境下把网关逻辑做成Sidecar注入到ERP的访问路径上。优点是网络层透明对应用无侵入缺点是调试复杂且需要ERP容器化。适合云原生程度高的企业。我个人的偏好是形态一因为AI场景的权限逻辑变化快独立服务迭代更灵活。部署上至少两个实例做高可用前面挂负载均衡配置从配置中心动态拉取支持热更新。5.2 与MCP服务端的集成方式网关和MCP服务端的关系需要理清。有两种集成模式模式A网关在MCP服务端之前。AI工作台先调网关网关校验通过后网关再以MCP客户端的身份调MCP服务端。这种模式下MCP服务端只信任网关AI工作台不直接接触MCP服务端。优点是安全边界清晰缺点是网关要理解MCP协议。模式B网关在MCP服务端之后。MCP服务端暴露工具AI工作台直接调MCP服务端MCP服务端在调用ERP之前经过网关。这种模式下网关更像一个ERP的代理。优点是MCP服务端不用改缺点是AI工作台和MCP服务端之间的调用没有审计。我推荐模式A因为审计的完整性要求网关在必经之路上。具体实现时网关需要实现MCP客户端的握手、工具发现、工具调用等流程。如果MCP服务端支持自定义认证头网关在调用时注入终端用户标识和trace_id。5.3 关键配置一个完整的网关策略示例下面是一个相对完整的网关策略配置涵盖身份映射、工具权限、字段过滤、频率控制gateway_policy: version: 1.0 identity: header_name: X-AI-User-Id session_header: X-AI-Session-Id workspace_header: X-AI-Workspace intent_header: X-AI-Intent rate_limit: per_session: max_calls: 20 max_duration_seconds: 30 per_user_per_minute: read: 30 write: 5 audit: enabled: true async: true queue: audit-queue include_request_body: true include_response_body: false mask_fields: [password, token, secret] roles: - name: SALES_QUERY erp_credential: vault://erp/sales_query tools: - name: erp.query_sales_order field_filters: exclude: - $.data.orders[*].items[*].cost_price - $.data.orders[*].items[*].supplier_base_price - name: erp.query_customer field_filters: exclude: - $.data[*].credit_rating - $.data[*].bank_account write_tools: [] - name: FINANCE_FULL erp_credential: vault://erp/finance_full tools: - name: erp.query_sales_order - name: erp.query_customer - name: erp.query_payment write_tools: - name: erp.create_payment_voucher require_approval: true approval_webhook: https://approval.internal/api/v1/request这个配置里require_approval: true表示写操作需要审批网关会挂起请求并调用审批系统的webhook审批通过后继续执行。vault://前缀表示凭证从密钥管理服务动态获取不写在配置文件里。5.4 审批流的实现细节写操作的审批流是网关里比较复杂的部分。我的实现方式是网关收到写操作请求先做权限校验和频率检查。校验通过后生成一个审批单包含请求详情、发起人、AI会话上下文、trace_id。调用审批系统的接口把审批单推送给对应的审批人。网关挂起请求返回一个“待审批”状态给AI工作台。审批人通过后审批系统回调网关网关继续执行原请求。审批拒绝或超时网关返回拒绝结果。这里有个坑AI工作台的超时设置。如果审批需要几分钟AI工作台的HTTP连接可能已经超时了。解决办法是网关返回一个异步任务IDAI工作台轮询或通过回调获取结果。这要求AI工作台侧支持异步工具调用不是所有工作台都支持。如果不支持就只能对写操作设置较短的审批超时或者干脆禁止AI工作台直接发起写操作只允许它生成“操作建议”由人工在ERP里执行。6. 常见问题与排查技巧实录6.1 连接类问题速查现象可能原因排查步骤解决方式AI工作台报“账号工作台已损坏无法打开”网关返回了非预期格式的错误响应工作台解析失败抓包看网关返回的HTTP状态码和body统一错误响应格式网关异常时返回标准JSON错误ERP连接超时网关到ERP的网络不通或ERP连接池满从网关所在机器telnet ERP端口查ERP连接池监控检查网络策略调整网关到ERP的连接池配置MCP工具列表为空网关未正确转发MCP的工具发现请求查网关日志中MCP initialize和tools/list的转发记录确认网关实现了MCP客户端握手流程字段过滤不生效JSONPath表达式与实际响应结构不匹配打印ERP原始响应对照过滤规则逐层验证用在线JSONPath测试工具验证表达式注意数组通配符6.2 权限类问题排查问题用户反馈“我明明有权限为什么AI说我没权限”排查思路先确认用户在ERP里的权限再确认网关的角色映射配置。常见原因是角色映射的通配符写错了比如sales_*匹配不到sales_manager_zhangsan因为中间还有下划线。另一个常见原因是ERP凭证对应的角色权限不足网关映射的角色和ERP凭证实际权限不一致。问题审计日志里找不到某次操作。排查思路确认请求是否真的经过了网关。如果AI工作台配置了直连MCP服务端的备用路径请求可能绕过了网关。检查AI工作台的MCP配置确保所有ERP相关工具都指向网关地址。另外检查审计日志的异步队列是否积压日志可能还没落盘。6.3 性能类问题网关作为中间层必然引入延迟。我的实测数据是一个简单的权限校验加字段过滤额外延迟在5到15毫秒之间。如果延迟超过50毫秒通常是以下原因凭证从密钥管理服务获取时没有缓存每次请求都去拉。解决办法是凭证缓存设置合理的TTL比如5分钟。字段过滤用了低效的JSON解析库对大响应体处理慢。换成流式JSON处理器或者对超过一定大小的响应做采样过滤。审计日志同步写入阻塞了主流程。改成异步写入用内存队列缓冲。6.4 几个我踩过的坑坑一把网关做成了单点。早期项目里网关只部署了一个实例结果网关重启时AI工作台完全不可用。后来改成至少双实例加健康检查滚动更新。坑二字段过滤规则写得太死。一开始把字段路径硬编码在代码里ERP接口一升级字段结构变了过滤就失效。后来改成配置化且加了单元测试每次ERP接口变更都跑一遍过滤规则测试。坑三忽略了MCP的流式输出。热词里有“使用mcp工具流式输出内容到文件”MCP支持流式返回。如果网关按普通HTTP响应处理会把流式响应缓冲成完整响应再返回破坏了流式特性。解决办法是网关对MCP的流式响应做透传不缓冲同时审计日志记录流式响应的摘要而非全文。坑四审批流的回调地址配错。审批系统回调网关时用了内网地址但审批系统在另一个网络区域回调不通。后来统一用服务发现的内网域名并加了回调重试机制。7. 这套网关方案还能怎么扩展权限与审计网关的定位决定了它有很强的扩展性。我在不同项目里基于这个架构做过这些扩展扩展一敏感数据动态脱敏。除了静态的字段过滤还可以根据用户角色和请求上下文做动态脱敏。比如同样是客户手机号销售看到的是完整号码客服看到的是中间四位掩码。规则引擎根据角色和字段敏感等级实时决定脱敏策略。扩展二AI意图风险评分。网关可以接入一个轻量模型对natural_language_intent做风险评分。比如“查询所有客户的银行账号”这种意图风险分高网关可以自动降级为只返回汇总数据或者触发人工审核。这个扩展对防范提示注入攻击特别有用。扩展三与ERP的PAC成本法审计对接。热词里提到“oracle erp pac成本法”PAC是Periodic Average Cost定期平均成本法。在采用PAC成本法的ERP里成本数据的查询和修改有严格的期间控制。网关可以对接ERP的成本期间状态在成本未结算期间禁止AI工作台查询成本明细避免未结算数据泄露。扩展四多ERP的统一网关。大型企业往往有多个ERP系统比如国内用一套、海外用一套。网关可以做成多租户的根据用户所属组织路由到不同的ERP同时保持统一的权限模型和审计格式。这样AI工作台只需要连一个网关地址不用关心后端有几个ERP。扩展五审计日志的智能分析。审计日志积累到一定量后可以用它来训练异常检测模型。比如某个用户突然在非工作时间大量查询敏感字段或者某个AI会话的调用模式偏离历史基线网关可以实时告警甚至自动阻断。这比传统的规则引擎更适应AI场景的动态性。8. 最后分享几个实操中的小技巧关于凭证管理我的经验是永远不要在配置文件里写明文凭证哪怕是在测试环境。用密钥管理服务或者至少用环境变量注入。我见过太多因为配置文件泄露导致ERP被访问的案例。关于字段过滤先做加法再做减法。意思是先定义每个角色能看到哪些字段白名单而不是先定义不能看哪些字段黑名单。白名单更安全因为ERP新增字段时默认不可见不会因为忘记加黑名单而泄露。关于审计日志的存储至少保留180天金融和医药行业建议保留一年以上。日志要加密存储访问日志本身也要有审计防止内部人员篡改。关于网关的测试一定要做混沌测试。模拟ERP超时、网关实例宕机、密钥管理服务不可用等场景验证AI工作台的降级行为是否符合预期。我做过一次混沌测试发现ERP超时时网关没有正确返回错误码导致AI工作台一直重试反而加剧了ERP的负载。后来加了熔断机制才解决。关于和业务部门的沟通权限映射规则一定要让业务负责人签字确认。技术团队不要自己决定“销售经理应该能看什么”这是业务决策。我吃过这个亏技术团队按自己的理解配了权限结果业务部门发现销售能看到不该看的客户信息追责时技术团队背了锅。后来改成权限映射表由业务负责人审批技术团队只负责实现。这套网关方案从第一个项目到现在前后迭代了两年多配置结构改了四版踩的坑基本都在这篇文章里了。如果你正在做类似的事情希望这些经验能帮你少走点弯路。