1. 从一个真实场景说起AI工作台直连ERP之后发生了什么去年下半年我参与了一个制造业客户的AI工作台落地项目。背景很典型他们用的是易飞ERP系统日常有大量采购单查询、库存核对、成本核算的需求业务部门希望能用自然语言直接问AI比如上个月A物料在华东仓的期末库存是多少AI工作台通过MCP协议对接ERP的数据接口把结果拉回来展示。项目上线第一周就出事了。一个采购专员在AI工作台里输入了一句模糊的指令AI理解成了批量查询供应商报价历史结果触发了ERP里一个没有做分页限制的接口瞬间拉了几万条记录把ERP的应用服务器CPU打到了95%整个采购模块卡了将近二十分钟。更麻烦的是事后排查时发现这个操作在ERP侧只留下了一条接口调用的日志根本看不出来是谁、通过什么方式、出于什么目的发起的。这件事让我彻底想明白一个问题AI工作台连接ERP技术上打通只是第一步真正决定这套系统能不能在生产环境活下去的是中间那层权限与审计网关。很多人以为MCP协议把接口标准化了AI就能安全地调用企业系统了这个认知是有偏差的。MCP解决的是怎么连的问题权限与审计网关解决的是谁能连、能连到什么程度、连了之后留下什么痕迹的问题两者根本不在一个层面上。这篇文章我想把这件事掰开揉碎讲清楚。适合正在做AI工作台与ERP集成的人看也适合负责企业系统安全的同学参考。我会从架构设计、权限模型、审计实现、实操踩坑几个角度展开尽量给出可以直接抄作业的方案。2. 为什么MCP打通了接口问题反而更多了2.1 MCP到底解决了什么又没解决什么MCPModel Context Protocol这两年被讨论得很多从Playwright MCP做自动化测试到百度地图MCP接入AI再到各种ERP、禅道系统的MCP封装本质上它做的事情是把原本五花八门的接口调用方式统一成一套AI能理解的工具描述格式。以前你要让AI调用ERP得自己写一堆函数封装、参数映射、返回值解析现在通过MCP Server把这些能力暴露成标准化的toolAI工作台侧只要按协议调用就行。但这里有个容易被忽略的点MCP是一个通信协议不是安全框架。它规定了工具怎么描述、参数怎么传、结果怎么返回但它没有规定这个工具该不该被这个用户调用、一次调用最多返回多少数据、调用失败要不要重试、敏感字段要不要脱敏。这些全是空白。我见过不少团队的做法是在MCP Server里直接写死ERP的连接账号AI工作台拿到工具列表就能随便调。这种方案在Demo阶段跑得飞快一上生产就是灾难。因为ERP的账号权限往往是粗粒度的一个能查库存的账号可能同时能改库存AI一旦被诱导或者理解偏差后果不可控。2.2 直连模式下的四类典型风险我把实际项目里遇到过的问题归了归类大致是这四类第一类是越权访问。AI工作台通常服务多个部门销售、采购、财务都在用。如果MCP Server用的是统一的高权限账号那么销售问一句帮我看看这个供应商的付款条件AI可能真的就把财务数据拉出来了。这不是AI的错是权限边界没划清楚。第二类是数据过量。就像开头那个案例AI对上个月所有全部这类词的理解和人类不一样它可能生成一个没有LIMIT的查询。ERP的老接口很多是没有强制分页的一旦被大结果集打爆影响的是整个系统。第三类是操作不可追溯。ERP原生日志记录的是某个账号调用了某个接口但AI工作台的调用链路是用户 → AI工作台 → MCP Server → ERP接口。中间经过了好几层ERP侧看到的只是最后一跳。出了问题要回溯是谁在什么时候通过AI做了什么光靠ERP日志根本拼不出来。第四类是敏感操作失控。查询类操作出问题顶多是性能但如果是写操作——比如AI帮用户提交了一张采购申请、修改了一条物料主数据——没有二次确认和审批拦截风险等级完全不一样。2.3 权限与审计网关的定位所以权限与审计网关要放在AI工作台和MCP Server之间或者MCP Server和ERP之间具体位置取决于你的架构。它的职责很明确认证确认发起调用的用户身份而不是只认MCP Server的服务账号鉴权判断这个用户对这个工具、这个参数范围有没有权限限流与配额控制调用频率、返回数据量、并发数审计完整记录调用链路包括用户、工具、参数、结果摘要、耗时拦截与脱敏对敏感字段做过滤对高危操作做二次确认你可以把它理解成ERP系统的门卫监控保险丝三合一。MCP是门网关是门口那套安检系统。3. 权限与审计网关的架构设计思路3.1 网关放在哪一层最合适这是设计时第一个要拍板的问题。常见的三种位置部署位置优点缺点适用场景AI工作台与MCP Server之间对AI侧透明统一管控所有MCP调用需要AI工作台支持自定义endpoint多AI工作台共用一套MCPMCP Server与ERP之间贴近数据源能拿到最细粒度的ERP上下文每个MCP Server都要接一遍单一MCP Server对接多ERPMCP Server内部作为中间件部署简单无需改网络拓扑与MCP Server耦合升级麻烦小规模、快速验证我个人的建议是优先选第一种。原因是AI工作台往往是多个的有人用CherryStudio有人用自研的有人用IDE插件而MCP Server可能是每个业务系统一个。把网关放在AI工作台出口能做到一次接入全局管控而且网关不依赖具体ERP的实现细节通用性更强。如果你们的MCP Server本身就是自研的第二种方案也可以好处是能直接拿到ERP的会话信息做行级权限控制更方便。但代价是每接一个新ERP就要重新配置一遍网关规则。3.2 核心模块拆解一个能打的网关我一般会拆成这么几个模块接入层负责协议适配。AI工作台过来的可能是HTTP、可能是SSE、可能是WebSocket网关要能统一收口。这一层还要做TLS终止、请求体大小限制这些基础防护。认证模块要解决你是谁。理想情况下AI工作台在调用时应该带上用户的身份令牌比如OAuth的access token或者企业内部的JWT网关验证令牌有效性解析出用户ID、部门、角色。如果AI工作台不支持传用户身份那至少要做到每个用户一个MCP连接通过连接维度区分身份虽然粗糙但比完全没有强。鉴权模块是核心。它要回答三个问题这个用户能不能调用这个工具能传什么参数能拿到什么结果我通常用策略引擎来实现把规则写成配置而不是硬编码。比如采购部用户只能调用query_inventory工具且warehouse参数必须在[华东仓, 华南仓]范围内。审计模块负责记录。这里有个坑不能只记录请求还要记录响应摘要。因为排查问题时经常需要知道AI到底返回了什么给用户。但响应体可能很大全量存成本高我的做法是存结构化摘要——记录返回条数、涉及的关键字段、是否命中敏感数据标记原始响应按需采样存储。流控模块做限流和熔断。按用户、按工具、按ERP系统三个维度分别设阈值。比如单用户每分钟最多20次调用单工具并发不超过10ERP整体QPS不超过50。超过就排队或者拒绝保护后端。3.3 为什么不用API网关直接替代有人会问企业不是已经有API网关了吗比如Kong、APISIX为什么还要单独做一层我的实测经验是通用API网关解决不了AI场景的特有问题。传统API网关的鉴权粒度是接口级而AI场景需要工具级参数级。传统网关的审计是请求日志而AI场景需要意图链路。传统网关的限流是QPS而AI场景还要控制单次返回数据量。举个具体例子ERP的查询接口传统网关看到的是POST /api/inventory/query它不知道body里的keyword参数如果是空字符串会触发全表扫描。但AI网关可以针对这个工具配置keyword为空时直接拒绝的规则。这种业务语义级别的管控通用网关做不了。所以我的结论是通用API网关做基础防护AI权限审计网关做业务语义管控两层配合不冲突。4. 权限模型怎么设计才够用又不复杂4.1 从RBAC到ABAC的取舍最朴素的做法是RBAC——给用户分配角色角色绑定工具列表。这个方案上手快但很快会遇到瓶颈。比如同样是采购专员角色华东区的和华南区的能查的仓库不一样这时候RBAC就表达不了了你得给每个区域建一个角色角色数量爆炸。我的建议是RBAC打底ABAC补充。角色决定能用哪些工具属性策略决定能用工具里的哪些数据。属性可以来自用户画像部门、区域、职级、环境时间、IP段、资源仓库、供应商、物料类别。具体实现上我习惯用类似这样的策略配置policy: - name: 采购专员库存查询 subject: role: purchase_specialist resource: tool: query_inventory condition: - user.region in resource.warehouse_region - request.params.limit 100 effect: allow - name: 禁止批量导出 subject: role: * resource: tool: query_inventory condition: - request.params.export true effect: deny注意deny规则的优先级要高于allow这是安全设计的基本原则——白名单可以漏黑名单必须硬。4.2 工具粒度的权限划分MCP工具的描述方式决定了权限划分的粒度。我一般把工具分成三档只读查询类库存查询、订单查询、物料信息查询。这类工具风险最低权限可以放宽但要在参数上做限制比如强制limit、禁止空条件全表查。聚合分析类成本核算、报表生成、趋势分析。这类工具往往涉及跨表关联计算量大要单独限流而且结果可能包含敏感的经营数据需要按用户职级做脱敏。写操作类提交单据、修改主数据、审批流转。这类工具必须走二次确认而且我强烈建议默认全部禁用需要业务方明确申请才逐个开通。开通后也要配置操作前人工确认的流程AI只能生成待确认的操作不能直接执行。4.3 参数级管控的实操细节参数级管控是网关最体现价值的地方也是最容易做过头的地方。我踩过的坑是一开始想把所有参数都校验一遍结果规则写了上千条维护成本极高业务方改个需求就要改规则。后来我调整了思路只管控三类参数第一类是范围参数比如仓库、区域、时间范围。这类参数直接决定数据边界必须校验。做法是把用户的属性范围和参数值做交集超出范围就拒绝或者自动收窄。第二类是数量参数比如limit、pageSize、topN。这类参数决定返回数据量必须设上限。我的经验值是单次查询默认limit 50最大不超过500超过就强制截断并提示用户。第三类是敏感标识参数比如includeCost、showSalary、export。这类参数一旦为true就可能泄露敏感数据需要单独鉴权。其他参数交给MCP Server和ERP自己校验就行网关不用管太细。4.4 一个容易忽略的点工具发现阶段的权限MCP协议里有个tools/list的能力AI工作台启动时会拉取可用工具列表。很多实现是把所有工具都返回给所有用户然后在调用时才鉴权。这其实泄露了信息——用户能看到自己无权使用的工具名称和描述本身就是一种信息暴露。正确的做法是在工具发现阶段就做过滤只返回当前用户有权限的工具。这样AI在规划任务时也不会去尝试调用无权工具减少无效请求。实现上就是在网关拦截tools/list响应按用户权限过滤后再返回。5. 审计日志怎么做才有排查价值5.1 审计日志必须包含的字段我见过太多团队的审计日志就是一行用户X调用了工具Y出问题时完全不够用。一份有排查价值的审计记录至少要包含这些字段字段说明示例trace_id全链路追踪ID贯穿AI工作台到ERPuser_id真实用户标识zhangsancorpsession_idAI会话ID用于关联同一对话的多次调用tool_name调用的工具名query_inventoryparams_digest参数摘要脱敏后warehouse华东仓,limit50result_summary结果摘要返回23条,含成本字段latency_ms耗时342status状态success/denied/errorpolicy_hit命中的策略采购专员库存查询client_info客户端信息CherryStudio v1.2其中session_id特别重要。因为AI的一次对话可能触发多次工具调用排查问题时需要把同一会话的所有调用串起来看才能还原AI的完整决策过程。5.2 日志的存储与查询审计日志的量级会比想象中大。一个中等规模的企业AI工作台日活几百人每人每天几十次调用一天就是上万条记录。全量存ES或者ClickHouse都行但要注意冷热分离——最近7天的热数据支持实时查询更早的归档到对象存储。查询接口要支持多维度组合按用户查、按工具查、按时间范围查、按状态查。我一般还会加一个异常视图自动聚合被拒绝的调用、超时的调用、返回数据量异常的调用方便安全同学日常巡检。5.3 敏感数据的脱敏策略审计日志本身也可能成为泄露源。如果日志里明文存了成本、薪资、客户联系方式那日志系统的访问权限就成了新的风险点。我的做法是分级脱敏普通字段原样存敏感字段存哈希或者掩码只有特定角色比如安全审计员能通过专门的接口查看脱敏前的值且查看行为本身也要记录审计。这样既保证了排查能力又控制了泄露面。6. 实操落地从零搭一个最小可用网关6.1 技术选型如果你们团队Java栈为主我推荐用Spring Cloud Gateway做基础自定义filter实现鉴权和审计。如果偏Go可以用APISIX做底座写Lua或者Wasm插件。如果只是想快速验证Node.js Express写个中间层也够用但生产环境要考虑性能和稳定性。数据库方面策略配置存MySQL或者PostgreSQL都行审计日志我建议直接上ClickHouse写入吞吐和查询性能都比传统关系库强很多。6.2 核心流程的代码骨架下面是一个简化的鉴权filter逻辑用Java伪代码示意public class AuthFilter implements GlobalFilter { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { // 1. 提取用户身份 String token exchange.getRequest().getHeaders().getFirst(X-User-Token); UserContext user tokenService.parse(token); if (user null) { return reject(exchange, UNAUTHENTICATED); } // 2. 解析MCP请求 McpRequest req parseBody(exchange); // 3. 工具发现请求特殊处理 if (tools/list.equals(req.getMethod())) { ListTool allowed policyEngine.filterTools(user, req.getTools()); return returnFiltered(exchange, allowed); } // 4. 工具调用鉴权 Decision decision policyEngine.evaluate(user, req.getTool(), req.getParams()); if (!decision.isAllowed()) { auditService.record(user, req, denied, decision.getPolicyHit()); return reject(exchange, decision.getReason()); } // 5. 参数收窄 req.setParams(decision.narrowParams(req.getParams())); // 6. 记录审计并放行 String traceId UUID.randomUUID().toString(); exchange.getAttributes().put(traceId, traceId); auditService.recordAsync(user, req, pending, decision.getPolicyHit()); return chain.filter(exchange).doOnSuccess(r - { auditService.updateResult(traceId, summarize(r)); }); } }这段代码的关键点在于鉴权在转发之前审计在转发前后各记一次。前一次记录意图后一次记录结果两次通过traceId关联。6.3 策略配置的热更新策略不能写死在代码里业务方改权限需求很频繁。我的做法是把策略存在数据库网关启动时加载到内存同时监听配置变更事件。变更后做双缓冲切换——新策略加载到新缓冲加载完成后原子切换指针避免切换瞬间的规则不一致。配置变更本身也要审计记录谁在什么时候改了哪条策略改前改后是什么。这个在合规检查时经常被问到。6.4 灰度与回滚网关是链路中间件一旦出问题影响面很大。上线时一定要支持灰度先对部分用户或者部分工具启用网关观察一段时间没问题再全量。同时要准备好旁路模式——网关故障时可以一键切到直连虽然失去管控但保证业务不中断。这个开关要做得足够简单最好是一行配置或者一个按钮别搞成需要重启服务。7. 常见问题与排查技巧实录7.1 典型问题速查表现象可能原因排查方向解决方式AI工作台报工具不存在工具发现被过滤检查用户权限配置补权限或调整策略调用返回403鉴权拒绝看审计日志的policy_hit确认策略是否符合预期返回数据被截断触发limit上限查result_summary提示用户收窄条件ERP响应变慢网关限流排队看流控指标调整阈值或扩容审计日志缺失异步写入失败检查日志队列补同步兜底用户身份识别错误token解析异常检查token格式修正认证配置7.2 几个我踩过的坑第一个坑是token透传问题。有些AI工作台在调用MCP时不会带上用户token只带自己的服务token。这时候网关拿不到真实用户身份只能退化成按连接识别。我的解决办法是在AI工作台侧做改造让它在建立MCP连接时就把用户token带上如果改造成本高至少要在请求头里加一个用户标识字段。第二个坑是流式响应的审计。MCP支持流式返回网关如果等响应完全结束再记录审计遇到长连接会一直占着内存。我的做法是边转发边聚合摘要记录条数、字节数、关键字段流结束后再落库。这样内存占用可控。第三个坑是策略冲突。多条策略同时命中时如果优先级没定义清楚会出现该拒的没拒。我的经验是deny优先于allow具体优先于宽泛并且策略命中后要记录是哪条策略生效的方便回溯。第四个坑是时间同步。网关、MCP Server、ERP三方的服务器时间如果不一致审计日志的时间线会错乱排查时非常痛苦。上线前一定要确认NTP同步日志里统一用UTC时间戳。7.3 性能优化的几个实用技巧网关在链路上性能不能成为瓶颈。我实测下来有效的几个优化策略缓存用户权限计算结果缓存5分钟避免每次调用都查库连接池复用到MCP Server和ERP的连接都要池化别每次新建异步审计审计写入走消息队列不阻塞主流程但要配同步兜底防止丢日志摘要计算下推结果摘要的计算尽量在网关内存里做别把大响应体全load进来压测的时候重点关注P99延迟我的目标是网关引入的额外延迟控制在20ms以内。超过这个数就要看看是不是策略计算太重或者审计写入阻塞了。8. 关于这套方案的一些个人体会做AI工作台和ERP集成这两年我最大的感受是技术打通的兴奋感会让人低估治理的复杂度。MCP让接口调用变得优雅但优雅的背后是更多的调用、更复杂的链路、更模糊的责任边界。权限与审计网关不是给系统加负担而是让这套系统能真正在生产环境跑起来的前提。我见过太多项目卡在Demo很惊艳上线就出事的阶段。问题往往不在AI能力本身而在这些看起来不性感的基础设施上。把网关这层做扎实后面无论是接更多的ERP、开放更多的工具、还是应对合规检查都会从容很多。如果你们团队刚开始做这块我的建议是先做最小可用的审计再做权限。因为审计能帮你快速看清实际调用情况知道哪些工具被高频使用、哪些参数容易出问题这些数据是设计权限策略的依据。反过来先做权限很容易拍脑袋定规则最后要么太松没效果要么太紧影响业务。最后分享一个小技巧网关上线初期把deny策略先设成只记录不拦截的观察模式跑一两周看看会拦掉哪些调用确认没有误伤再真正开启拦截。这个缓冲期能避免很多上线事故。 
长河君 · 2026/10/26 8:29:38 · 阅读 1.2k AI工作台直连ERP后系统崩溃？MCP协议下的权限与审计网关设计实战
1. 从一个真实场景说起AI工作台直连ERP之后发生了什么去年下半年我参与了一个制造业客户的AI工作台落地项目。背景很典型他们用的是易飞ERP系统日常有大量采购单查询、库存核对、成本核算的需求业务部门希望能用自然语言直接问AI比如上个月A物料在华东仓的期末库存是多少AI工作台通过MCP协议对接ERP的数据接口把结果拉回来展示。项目上线第一周就出事了。一个采购专员在AI工作台里输入了一句模糊的指令AI理解成了批量查询供应商报价历史结果触发了ERP里一个没有做分页限制的接口瞬间拉了几万条记录把ERP的应用服务器CPU打到了95%整个采购模块卡了将近二十分钟。更麻烦的是事后排查时发现这个操作在ERP侧只留下了一条接口调用的日志根本看不出来是谁、通过什么方式、出于什么目的发起的。这件事让我彻底想明白一个问题AI工作台连接ERP技术上打通只是第一步真正决定这套系统能不能在生产环境活下去的是中间那层权限与审计网关。很多人以为MCP协议把接口标准化了AI就能安全地调用企业系统了这个认知是有偏差的。MCP解决的是怎么连的问题权限与审计网关解决的是谁能连、能连到什么程度、连了之后留下什么痕迹的问题两者根本不在一个层面上。这篇文章我想把这件事掰开揉碎讲清楚。适合正在做AI工作台与ERP集成的人看也适合负责企业系统安全的同学参考。我会从架构设计、权限模型、审计实现、实操踩坑几个角度展开尽量给出可以直接抄作业的方案。2. 为什么MCP打通了接口问题反而更多了2.1 MCP到底解决了什么又没解决什么MCPModel Context Protocol这两年被讨论得很多从Playwright MCP做自动化测试到百度地图MCP接入AI再到各种ERP、禅道系统的MCP封装本质上它做的事情是把原本五花八门的接口调用方式统一成一套AI能理解的工具描述格式。以前你要让AI调用ERP得自己写一堆函数封装、参数映射、返回值解析现在通过MCP Server把这些能力暴露成标准化的toolAI工作台侧只要按协议调用就行。但这里有个容易被忽略的点MCP是一个通信协议不是安全框架。它规定了工具怎么描述、参数怎么传、结果怎么返回但它没有规定这个工具该不该被这个用户调用、一次调用最多返回多少数据、调用失败要不要重试、敏感字段要不要脱敏。这些全是空白。我见过不少团队的做法是在MCP Server里直接写死ERP的连接账号AI工作台拿到工具列表就能随便调。这种方案在Demo阶段跑得飞快一上生产就是灾难。因为ERP的账号权限往往是粗粒度的一个能查库存的账号可能同时能改库存AI一旦被诱导或者理解偏差后果不可控。2.2 直连模式下的四类典型风险我把实际项目里遇到过的问题归了归类大致是这四类第一类是越权访问。AI工作台通常服务多个部门销售、采购、财务都在用。如果MCP Server用的是统一的高权限账号那么销售问一句帮我看看这个供应商的付款条件AI可能真的就把财务数据拉出来了。这不是AI的错是权限边界没划清楚。第二类是数据过量。就像开头那个案例AI对上个月所有全部这类词的理解和人类不一样它可能生成一个没有LIMIT的查询。ERP的老接口很多是没有强制分页的一旦被大结果集打爆影响的是整个系统。第三类是操作不可追溯。ERP原生日志记录的是某个账号调用了某个接口但AI工作台的调用链路是用户 → AI工作台 → MCP Server → ERP接口。中间经过了好几层ERP侧看到的只是最后一跳。出了问题要回溯是谁在什么时候通过AI做了什么光靠ERP日志根本拼不出来。第四类是敏感操作失控。查询类操作出问题顶多是性能但如果是写操作——比如AI帮用户提交了一张采购申请、修改了一条物料主数据——没有二次确认和审批拦截风险等级完全不一样。2.3 权限与审计网关的定位所以权限与审计网关要放在AI工作台和MCP Server之间或者MCP Server和ERP之间具体位置取决于你的架构。它的职责很明确认证确认发起调用的用户身份而不是只认MCP Server的服务账号鉴权判断这个用户对这个工具、这个参数范围有没有权限限流与配额控制调用频率、返回数据量、并发数审计完整记录调用链路包括用户、工具、参数、结果摘要、耗时拦截与脱敏对敏感字段做过滤对高危操作做二次确认你可以把它理解成ERP系统的门卫监控保险丝三合一。MCP是门网关是门口那套安检系统。3. 权限与审计网关的架构设计思路3.1 网关放在哪一层最合适这是设计时第一个要拍板的问题。常见的三种位置部署位置优点缺点适用场景AI工作台与MCP Server之间对AI侧透明统一管控所有MCP调用需要AI工作台支持自定义endpoint多AI工作台共用一套MCPMCP Server与ERP之间贴近数据源能拿到最细粒度的ERP上下文每个MCP Server都要接一遍单一MCP Server对接多ERPMCP Server内部作为中间件部署简单无需改网络拓扑与MCP Server耦合升级麻烦小规模、快速验证我个人的建议是优先选第一种。原因是AI工作台往往是多个的有人用CherryStudio有人用自研的有人用IDE插件而MCP Server可能是每个业务系统一个。把网关放在AI工作台出口能做到一次接入全局管控而且网关不依赖具体ERP的实现细节通用性更强。如果你们的MCP Server本身就是自研的第二种方案也可以好处是能直接拿到ERP的会话信息做行级权限控制更方便。但代价是每接一个新ERP就要重新配置一遍网关规则。3.2 核心模块拆解一个能打的网关我一般会拆成这么几个模块接入层负责协议适配。AI工作台过来的可能是HTTP、可能是SSE、可能是WebSocket网关要能统一收口。这一层还要做TLS终止、请求体大小限制这些基础防护。认证模块要解决你是谁。理想情况下AI工作台在调用时应该带上用户的身份令牌比如OAuth的access token或者企业内部的JWT网关验证令牌有效性解析出用户ID、部门、角色。如果AI工作台不支持传用户身份那至少要做到每个用户一个MCP连接通过连接维度区分身份虽然粗糙但比完全没有强。鉴权模块是核心。它要回答三个问题这个用户能不能调用这个工具能传什么参数能拿到什么结果我通常用策略引擎来实现把规则写成配置而不是硬编码。比如采购部用户只能调用query_inventory工具且warehouse参数必须在[华东仓, 华南仓]范围内。审计模块负责记录。这里有个坑不能只记录请求还要记录响应摘要。因为排查问题时经常需要知道AI到底返回了什么给用户。但响应体可能很大全量存成本高我的做法是存结构化摘要——记录返回条数、涉及的关键字段、是否命中敏感数据标记原始响应按需采样存储。流控模块做限流和熔断。按用户、按工具、按ERP系统三个维度分别设阈值。比如单用户每分钟最多20次调用单工具并发不超过10ERP整体QPS不超过50。超过就排队或者拒绝保护后端。3.3 为什么不用API网关直接替代有人会问企业不是已经有API网关了吗比如Kong、APISIX为什么还要单独做一层我的实测经验是通用API网关解决不了AI场景的特有问题。传统API网关的鉴权粒度是接口级而AI场景需要工具级参数级。传统网关的审计是请求日志而AI场景需要意图链路。传统网关的限流是QPS而AI场景还要控制单次返回数据量。举个具体例子ERP的查询接口传统网关看到的是POST /api/inventory/query它不知道body里的keyword参数如果是空字符串会触发全表扫描。但AI网关可以针对这个工具配置keyword为空时直接拒绝的规则。这种业务语义级别的管控通用网关做不了。所以我的结论是通用API网关做基础防护AI权限审计网关做业务语义管控两层配合不冲突。4. 权限模型怎么设计才够用又不复杂4.1 从RBAC到ABAC的取舍最朴素的做法是RBAC——给用户分配角色角色绑定工具列表。这个方案上手快但很快会遇到瓶颈。比如同样是采购专员角色华东区的和华南区的能查的仓库不一样这时候RBAC就表达不了了你得给每个区域建一个角色角色数量爆炸。我的建议是RBAC打底ABAC补充。角色决定能用哪些工具属性策略决定能用工具里的哪些数据。属性可以来自用户画像部门、区域、职级、环境时间、IP段、资源仓库、供应商、物料类别。具体实现上我习惯用类似这样的策略配置policy: - name: 采购专员库存查询 subject: role: purchase_specialist resource: tool: query_inventory condition: - user.region in resource.warehouse_region - request.params.limit 100 effect: allow - name: 禁止批量导出 subject: role: * resource: tool: query_inventory condition: - request.params.export true effect: deny注意deny规则的优先级要高于allow这是安全设计的基本原则——白名单可以漏黑名单必须硬。4.2 工具粒度的权限划分MCP工具的描述方式决定了权限划分的粒度。我一般把工具分成三档只读查询类库存查询、订单查询、物料信息查询。这类工具风险最低权限可以放宽但要在参数上做限制比如强制limit、禁止空条件全表查。聚合分析类成本核算、报表生成、趋势分析。这类工具往往涉及跨表关联计算量大要单独限流而且结果可能包含敏感的经营数据需要按用户职级做脱敏。写操作类提交单据、修改主数据、审批流转。这类工具必须走二次确认而且我强烈建议默认全部禁用需要业务方明确申请才逐个开通。开通后也要配置操作前人工确认的流程AI只能生成待确认的操作不能直接执行。4.3 参数级管控的实操细节参数级管控是网关最体现价值的地方也是最容易做过头的地方。我踩过的坑是一开始想把所有参数都校验一遍结果规则写了上千条维护成本极高业务方改个需求就要改规则。后来我调整了思路只管控三类参数第一类是范围参数比如仓库、区域、时间范围。这类参数直接决定数据边界必须校验。做法是把用户的属性范围和参数值做交集超出范围就拒绝或者自动收窄。第二类是数量参数比如limit、pageSize、topN。这类参数决定返回数据量必须设上限。我的经验值是单次查询默认limit 50最大不超过500超过就强制截断并提示用户。第三类是敏感标识参数比如includeCost、showSalary、export。这类参数一旦为true就可能泄露敏感数据需要单独鉴权。其他参数交给MCP Server和ERP自己校验就行网关不用管太细。4.4 一个容易忽略的点工具发现阶段的权限MCP协议里有个tools/list的能力AI工作台启动时会拉取可用工具列表。很多实现是把所有工具都返回给所有用户然后在调用时才鉴权。这其实泄露了信息——用户能看到自己无权使用的工具名称和描述本身就是一种信息暴露。正确的做法是在工具发现阶段就做过滤只返回当前用户有权限的工具。这样AI在规划任务时也不会去尝试调用无权工具减少无效请求。实现上就是在网关拦截tools/list响应按用户权限过滤后再返回。5. 审计日志怎么做才有排查价值5.1 审计日志必须包含的字段我见过太多团队的审计日志就是一行用户X调用了工具Y出问题时完全不够用。一份有排查价值的审计记录至少要包含这些字段字段说明示例trace_id全链路追踪ID贯穿AI工作台到ERPuser_id真实用户标识zhangsancorpsession_idAI会话ID用于关联同一对话的多次调用tool_name调用的工具名query_inventoryparams_digest参数摘要脱敏后warehouse华东仓,limit50result_summary结果摘要返回23条,含成本字段latency_ms耗时342status状态success/denied/errorpolicy_hit命中的策略采购专员库存查询client_info客户端信息CherryStudio v1.2其中session_id特别重要。因为AI的一次对话可能触发多次工具调用排查问题时需要把同一会话的所有调用串起来看才能还原AI的完整决策过程。5.2 日志的存储与查询审计日志的量级会比想象中大。一个中等规模的企业AI工作台日活几百人每人每天几十次调用一天就是上万条记录。全量存ES或者ClickHouse都行但要注意冷热分离——最近7天的热数据支持实时查询更早的归档到对象存储。查询接口要支持多维度组合按用户查、按工具查、按时间范围查、按状态查。我一般还会加一个异常视图自动聚合被拒绝的调用、超时的调用、返回数据量异常的调用方便安全同学日常巡检。5.3 敏感数据的脱敏策略审计日志本身也可能成为泄露源。如果日志里明文存了成本、薪资、客户联系方式那日志系统的访问权限就成了新的风险点。我的做法是分级脱敏普通字段原样存敏感字段存哈希或者掩码只有特定角色比如安全审计员能通过专门的接口查看脱敏前的值且查看行为本身也要记录审计。这样既保证了排查能力又控制了泄露面。6. 实操落地从零搭一个最小可用网关6.1 技术选型如果你们团队Java栈为主我推荐用Spring Cloud Gateway做基础自定义filter实现鉴权和审计。如果偏Go可以用APISIX做底座写Lua或者Wasm插件。如果只是想快速验证Node.js Express写个中间层也够用但生产环境要考虑性能和稳定性。数据库方面策略配置存MySQL或者PostgreSQL都行审计日志我建议直接上ClickHouse写入吞吐和查询性能都比传统关系库强很多。6.2 核心流程的代码骨架下面是一个简化的鉴权filter逻辑用Java伪代码示意public class AuthFilter implements GlobalFilter { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { // 1. 提取用户身份 String token exchange.getRequest().getHeaders().getFirst(X-User-Token); UserContext user tokenService.parse(token); if (user null) { return reject(exchange, UNAUTHENTICATED); } // 2. 解析MCP请求 McpRequest req parseBody(exchange); // 3. 工具发现请求特殊处理 if (tools/list.equals(req.getMethod())) { ListTool allowed policyEngine.filterTools(user, req.getTools()); return returnFiltered(exchange, allowed); } // 4. 工具调用鉴权 Decision decision policyEngine.evaluate(user, req.getTool(), req.getParams()); if (!decision.isAllowed()) { auditService.record(user, req, denied, decision.getPolicyHit()); return reject(exchange, decision.getReason()); } // 5. 参数收窄 req.setParams(decision.narrowParams(req.getParams())); // 6. 记录审计并放行 String traceId UUID.randomUUID().toString(); exchange.getAttributes().put(traceId, traceId); auditService.recordAsync(user, req, pending, decision.getPolicyHit()); return chain.filter(exchange).doOnSuccess(r - { auditService.updateResult(traceId, summarize(r)); }); } }这段代码的关键点在于鉴权在转发之前审计在转发前后各记一次。前一次记录意图后一次记录结果两次通过traceId关联。6.3 策略配置的热更新策略不能写死在代码里业务方改权限需求很频繁。我的做法是把策略存在数据库网关启动时加载到内存同时监听配置变更事件。变更后做双缓冲切换——新策略加载到新缓冲加载完成后原子切换指针避免切换瞬间的规则不一致。配置变更本身也要审计记录谁在什么时候改了哪条策略改前改后是什么。这个在合规检查时经常被问到。6.4 灰度与回滚网关是链路中间件一旦出问题影响面很大。上线时一定要支持灰度先对部分用户或者部分工具启用网关观察一段时间没问题再全量。同时要准备好旁路模式——网关故障时可以一键切到直连虽然失去管控但保证业务不中断。这个开关要做得足够简单最好是一行配置或者一个按钮别搞成需要重启服务。7. 常见问题与排查技巧实录7.1 典型问题速查表现象可能原因排查方向解决方式AI工作台报工具不存在工具发现被过滤检查用户权限配置补权限或调整策略调用返回403鉴权拒绝看审计日志的policy_hit确认策略是否符合预期返回数据被截断触发limit上限查result_summary提示用户收窄条件ERP响应变慢网关限流排队看流控指标调整阈值或扩容审计日志缺失异步写入失败检查日志队列补同步兜底用户身份识别错误token解析异常检查token格式修正认证配置7.2 几个我踩过的坑第一个坑是token透传问题。有些AI工作台在调用MCP时不会带上用户token只带自己的服务token。这时候网关拿不到真实用户身份只能退化成按连接识别。我的解决办法是在AI工作台侧做改造让它在建立MCP连接时就把用户token带上如果改造成本高至少要在请求头里加一个用户标识字段。第二个坑是流式响应的审计。MCP支持流式返回网关如果等响应完全结束再记录审计遇到长连接会一直占着内存。我的做法是边转发边聚合摘要记录条数、字节数、关键字段流结束后再落库。这样内存占用可控。第三个坑是策略冲突。多条策略同时命中时如果优先级没定义清楚会出现该拒的没拒。我的经验是deny优先于allow具体优先于宽泛并且策略命中后要记录是哪条策略生效的方便回溯。第四个坑是时间同步。网关、MCP Server、ERP三方的服务器时间如果不一致审计日志的时间线会错乱排查时非常痛苦。上线前一定要确认NTP同步日志里统一用UTC时间戳。7.3 性能优化的几个实用技巧网关在链路上性能不能成为瓶颈。我实测下来有效的几个优化策略缓存用户权限计算结果缓存5分钟避免每次调用都查库连接池复用到MCP Server和ERP的连接都要池化别每次新建异步审计审计写入走消息队列不阻塞主流程但要配同步兜底防止丢日志摘要计算下推结果摘要的计算尽量在网关内存里做别把大响应体全load进来压测的时候重点关注P99延迟我的目标是网关引入的额外延迟控制在20ms以内。超过这个数就要看看是不是策略计算太重或者审计写入阻塞了。8. 关于这套方案的一些个人体会做AI工作台和ERP集成这两年我最大的感受是技术打通的兴奋感会让人低估治理的复杂度。MCP让接口调用变得优雅但优雅的背后是更多的调用、更复杂的链路、更模糊的责任边界。权限与审计网关不是给系统加负担而是让这套系统能真正在生产环境跑起来的前提。我见过太多项目卡在Demo很惊艳上线就出事的阶段。问题往往不在AI能力本身而在这些看起来不性感的基础设施上。把网关这层做扎实后面无论是接更多的ERP、开放更多的工具、还是应对合规检查都会从容很多。如果你们团队刚开始做这块我的建议是先做最小可用的审计再做权限。因为审计能帮你快速看清实际调用情况知道哪些工具被高频使用、哪些参数容易出问题这些数据是设计权限策略的依据。反过来先做权限很容易拍脑袋定规则最后要么太松没效果要么太紧影响业务。最后分享一个小技巧网关上线初期把deny策略先设成只记录不拦截的观察模式跑一两周看看会拦掉哪些调用确认没有误伤再真正开启拦截。这个缓冲期能避免很多上线事故。