AI工作台对接ERP为何必须加权限与审计网关

1. 这不是多此一举：AI工作台连上ERP后，权限与审计网关的底层逻辑

你刚把AI工作台接入了公司ERP系统，测试时一切顺利——能查库存、能调订单、能生成销售摘要，甚至还能用自然语言问“华东区Q3毛利最高的三个SKU是什么”。你松了口气，觉得集成完成了。结果第二天，财务总监发来邮件：“为什么AI助手能导出含成本价的完整采购明细表？谁授权它访问PAC成本法模块？这个视图明明只对成本会计组开放。”——问题来了：既然ERP本身就有用户登录、角色分配、菜单权限控制，为什么还要在AI工作台和ERP之间再加一层“权限与审计网关”？这不是叠床架屋吗？

答案很直接：ERP的权限模型，是为“人”设计的；而AI工作台，是一个没有身份、不守规则、不知疲倦的“数字执行体”。它不点击菜单，不走审批流，不看弹窗提示，更不会因为“权限不足”就停下来思考。它拿到一个API Token，就能像一把万能钥匙，捅开所有它能识别的接口门锁。ERP原生的RBAC（基于角色的访问控制）管的是“张三作为销售主管，能看哪些单据”，但管不了“AI工作台以张三身份调用时，能不能把整张采购明细表导出成Excel发到外部邮箱”。这就是本质差异。

我做过7个制造业和零售业的AI+ERP落地项目，最深的教训就是：第一个被攻破的不是防火墙，而是权限边界。有次上线第三天，AI助手根据销售经理的日常提问习惯，自动聚合了近半年所有供应商的付款账期、违约金条款、历史退货率，生成了一份《高风险供应商预警清单》——这本身没问题。但它顺手把原始数据（含银行账号、合同金额、法人身份证号后四位）一并打包进了附件。没人教它不能传，ERP也没拦住它，因为销售经理本人确实有查看这些字段的权限。问题出在哪？出在“行为粒度”上：人看数据是“浏览”，AI调数据是“搬运”；人导出是“有明确目的”，AI导出是“为后续分析做准备”。而传统ERP权限体系，只定义“能不能看”，不定义“能不能批量导出”“能不能跨模块关联”“能不能写入非授权字段”。

所以，“权限与审计网关”不是ERP权限的复制品，而是它的“翻译器”和“守门人”。它把ERP里静态的、粗粒度的角色权限，翻译成AI工作台动态的、细粒度的行为策略；它把“张三能看采购单”这个事实，拆解成“张三通过AI工作台查询采购单时，仅允许返回单号、日期、供应商名称、总金额，禁止返回单价、数量、收货地址、联系人电话，并且导出操作必须经二次确认”。它还干一件ERP根本不做的事：全程录像。每一次AI调用ERP接口，它都记下“谁发起的（用户ID）、用了什么提示词（脱敏后）、调了哪个API、传了什么参数、返回了多少条数据、是否触发了导出/写入动作、响应耗时多少、有没有异常重试”。这份日志，不是给IT运维看的，是给内审、合规、风控部门看的——当有人质疑“AI是不是泄露了客户数据”，你拿不出这份带上下文的审计流水，就只能靠嘴说。

关键词“MCP”在这里不是指某个具体工具，而是指一种架构理念：Model-Controller-Proxy（模型-控制器-代理）。AI工作台是Model（负责理解意图、生成逻辑），ERP是Backend（提供数据与业务能力），而权限与审计网关，就是那个关键的Controller+Proxy——它不参与业务计算，但决定每个请求能否通行、以何种方式通行、通行后留下什么痕迹。没它，AI工作台就像一辆没有刹车、没有导航、没有行车记录仪的自动驾驶汽车，跑得越快，风险越大。

2. ERP权限的三大先天局限：为什么它管不住AI

要真正理解为什么必须加网关，得先看清ERP原生权限体系的“软肋”。这不是ERP不好，而是它的设计目标从来就不是防AI。我把这三大局限，结合真实踩过的坑，一条条拆给你看。

2.1 权限粒度太粗：管不到字段级、行为级、上下文级

ERP的权限配置，绝大多数停留在“模块→菜单→按钮”三级。比如SAP中，给“采购管理”角色分配“采购订单查询”事务码ME2N，这个人就能看到所有采购订单列表。Oracle EBS里，给“采购专员”职责赋予权限，他就能运行PO_POXPOEPO_XML_PKG包里的过程。这看起来很完备，但问题在于：它默认假设使用者是“人”，而人会本能地遵守界面约束。人点开ME2N，界面上只显示单号、日期、供应商、总金额，他看不到单价、税率、付款条件这些敏感字段——不是ERP不让他看，是前端UI根本没渲染出来。

AI工作台不走UI。它直连后端API，比如调用/api/po/list?status=approved&limit=10000。如果这个API返回的是完整的JSON结构，包含unit_price、tax_rate、payment_terms、delivery_address，那AI就全拿到了。ERP的权限检查，往往只发生在“用户是否有权调用这个API”的层面，一旦放行，后面的数据字段、返回条数、是否允许分页拉取，统统不管。我遇到过最典型的案例：某客户用鼎捷ERP，其API文档里写着“GET /v1/inventory返回库存主数据”，实际返回字段多达87个，其中cost_price（成本价）、min_stock_level（安全库存）、vendor_code（供应商编码）都是商业机密。开发AI工作台时，工程师按文档调用，结果AI助手在回答“哪些SKU缺货风险最高”时，顺手把成本价和供应商信息也列在了分析结论里——因为ERP没告诉它“这些字段禁止在非成本模块场景下返回”。

更致命的是“行为级”缺失。ERP能控制“能不能删除订单”，但控制不了“能不能把1000条订单数据导出成CSV”。导出功能通常是个独立按钮，权限单独配。但AI工作台调用/api/order/export?format=csv&all=true，这个接口很可能没单独设权限，或者权限检查只验证了“用户是否登录”，没验证“本次导出是否超出单次500条限制”。结果AI一口气拉走全量订单，包括未审核、已作废、测试单——这些数据本不该出现在任何报表里。

2.2 权限上下文丢失：AI的“身份”是模糊的、可伪造的、易复用的

ERP权限校验，高度依赖“会话上下文”。用户登录后，系统生成Session ID，绑定用户ID、角色、组织架构、时间戳。每次请求带着Session ID，后端从Session里读取权限缓存。这套机制对人很稳，但对AI是灾难。

首先，AI工作台的身份是“代理身份”。它不是以张三个人账号登录ERP，而是用一个服务账号（如ai-service@company.com）统一调用。这个账号需要足够高的权限，才能覆盖所有用户可能提出的AI需求。于是，它往往被赋予“超级查询员”角色——能读所有模块，但不能写。问题来了：当张三问“我的待办审批有哪些”，AI用服务账号调用审批API，返回的是全公司所有人的待办，然后AI再用张三的员工ID去过滤。过滤发生在AI侧，不是ERP侧。如果AI代码有bug，漏掉了过滤，或者张三的提示词诱导AI去“对比我和李四的审批效率”，AI就可能把李四的待办也一并拉回来。ERP只看到“服务账号在查审批”，它认为合法；AI却把数据混在一起处理了。

其次，Token易复用、难追溯。很多ERP API采用Bearer Token认证，AI工作台拿到Token后，可以反复使用。如果这个Token被意外泄露（比如日志里明文打印了），攻击者就能用它直接调ERP接口，绕过所有前端权限。ERP日志里只会记“Token XXXX 调用了 /api/user/list”，但不知道这个Token是AI工作台用的，还是被黑的。而权限与审计网关，强制要求每个AI请求必须携带“发起人ID”（即张三的工号）和“请求指纹”（由提示词哈希生成），网关用这两个信息动态生成一次性的、带时效的内部Token，再转发给ERP。这样，即使内部Token泄露，也只对单次请求有效，且能精准定位到是张三在什么时间、问了什么问题触发的。

最后，上下文无法继承。ERP的权限常和组织架构强绑定。比如“华东区销售总监”能看到华东区所有数据，但看不到华北区。AI工作台如果只是简单传递用户ID，ERP后端可能无法识别这个ID对应的组织归属，因为它没走标准的SSO流程，或者AI调用的是老版本API，不支持传组织参数。结果AI要么报错“无权限”，要么默认返回全量数据。网关在这里充当“上下文翻译器”，它查用户主数据，拿到张三的部门、岗位、管理范围，再把这些信息作为X-Context-Region: EastChina、X-Context-Role: SalesDirector这样的Header，附加在转发给ERP的请求上。ERP后端只要稍作改造，就能基于这些Header做二次过滤。

2.3 审计能力缺失：日志是“发生了什么”，不是“为什么发生”

ERP的日志，通常是系统级的、碎片化的。Oracle EBS有Audit Trail，SAP有SM19，但它们记录的是“谁在什么时候执行了什么事务码”，格式是[2024-06-15 14:22:03] USER:ZhangSan TCODE:ME2N ACTION:READ。这对你排查“张三是不是违规查了不该看的单据”有用，但对分析“AI助手为什么生成了错误的库存预测”毫无帮助。

AI的决策是黑盒。它可能基于10个不同API的返回数据，经过3层推理，最终给出结论。ERP日志只告诉你它调了/api/inventory和/api/sales/history，但不告诉你：

• 它为什么调这两个接口？（是因为提示词里提到“预测下周缺货”）
• 它怎么组合数据的？（是简单求和，还是用了指数平滑算法？）
• 它有没有忽略某些条件？（比如没过滤掉已取消的销售订单）
• 它的输出是否触发了下游动作？（比如自动生成了补货建议单）

没有这些上下文，审计就是盲人摸象。权限与审计网关的日志，则是“全链路叙事”。它记录：

• RequestID: req-abc123 | Initiator: zhangsan@company.com | Timestamp: 2024-06-15T14:22:03Z
• Prompt: "预测华东仓未来7天缺货风险最高的5个SKU，需考虑在途采购和已承诺销售" | PromptHash: sha256:...
• API Calls: [GET /api/inventory?warehouse=EC, GET /api/po/intransit?warehouse=EC, GET /api/sales/committed?warehouse=EC]
• Data Volume: inventory(248 rows), intransit(17 rows), committed(89 rows)
• Post-Processing: Applied safety filter to exclude SKUs with cost_price > 10000, flagged 3 SKUs for manual review
• Response: {"risk_skus": ["SKU-A", "SKU-B", "SKU-C"], "reason": "in_transit_delay > 5_days AND committed_qty > inventory_qty"}

这份日志，让审计人员能还原整个AI决策链条：张三问了什么，AI理解成什么，它调了哪些数据，怎么加工的，最终输出是否合规。更重要的是，它能把“行为”和“意图”挂钩。比如发现某次调用/api/finance/profit返回了PAC成本法的详细分摊数据，网关日志会显示这次调用的PromptHash对应的是“帮我分析Q3各产品线毛利率”，而另一次PromptHash对应的是“导出所有SKU的成本构成表”，后者就会被标记为高风险，触发告警。ERP日志里，两次调用看起来一模一样。

3. 权限与审计网关的核心设计：不是加一层，而是重构信任链

很多人以为加个网关，就是部署一个中间件，配几条规则，完事。错了。真正的网关，是一套重新定义“AI如何可信地使用ERP”的信任协议。它不替代ERP权限，而是把ERP的静态权限，升级为动态的、可解释的、可追溯的信任凭证。我把它拆成四个核心模块，每个模块都解决一个关键问题。

3.1 策略引擎：把“人”的规则，翻译成“AI”的指令

这是网关的大脑。它不硬编码规则，而是用一套声明式策略语言（我们内部叫AIPSL - AI Permission Specification Language），把业务规则翻译成机器可执行的指令。举个真实例子：某客户要求“销售代表只能通过AI查看自己名下客户的订单，且不能导出含单价的明细”。

在ERP里，这可能是两条权限：

• 角色“SalesRep”有“订单查询”菜单权限
• 角色“SalesRep”无“订单导出”按钮权限

但在AIPSL里，它被写成：

policy "salesrep_order_access" { when { user.role == "SalesRep" api.path == "/api/order/list" } then { // 字段过滤：只返回允许的字段 fields_allow = ["order_id", "customer_name", "order_date", "total_amount", "status"] // 行级过滤：只返回该销售代表负责的客户 row_filter = "customer_id IN (SELECT customer_id FROM sales_rep_customer WHERE rep_id = :user.id)" // 行为限制：禁止导出 deny_actions = ["export_csv", "export_excel"] // 上下文增强：注入销售代表的区域信息 inject_headers = { "X-Sales-Region": user.region } } }

这个策略生效时，网关会：

• 拦截AI对/api/order/list的调用
• 解析请求参数，提取customer_id或rep_id等上下文
• 动态改写SQL查询，加入AND customer_id IN (...)子句
• 对返回的JSON数据，只保留fields_allow列表里的键值对
• 如果请求头里有X-Action: export_csv，直接返回403 Forbidden

关键点在于“动态”。策略不是死的。row_filter里的子查询，会实时从HR系统拉取张三当前负责的客户列表；inject_headers里的user.region，是从AD域同步的最新组织架构。这比ERP里固化在角色里的“华东区”权限灵活得多——如果张三临时被借调到华北区支援，他的AI权限第二天就自动更新了，不用IT手动改角色。

3.2 行为沙箱：给AI一个“安全游乐场”

光过滤不够，还得防“意外交互”。AI工作台不是孤立运行的，它可能调用多个ERP API，再把结果喂给大模型做推理，最后生成报告或触发自动化。这个过程中，数据可能在AI内存里“混在一起”。行为沙箱就是给每次AI会话划一个隔离的“数据围栏”。

实现方式很简单：网关为每个AI请求生成唯一的SessionID，并把这个ID注入所有下游API调用的Header里（如X-AI-Session: sess-xyz789）。ERP后端微服务收到这个Header，就知道“哦，这是AI沙箱里的请求，所有数据操作都要打上这个Session标签”。

好处立竿见影：

• 数据血缘追踪：ERP数据库里，每条被AI读取的记录，都自动记录ai_session_id。审计时，直接查SELECT * FROM po_header WHERE ai_session_id = 'sess-xyz789'，就能看到AI这次调用到底看了哪些单据。
• 写入隔离：如果AI要创建测试单据，ERP后端会把ai_session_id作为前缀，写入到po_header_ai_sess_xyz789这样的临时表，而不是正式表。网关定时清理这些临时数据，避免污染生产库。
• 资源熔断：网关监控每个SessionID的调用频次、数据量、耗时。如果发现某个Session在1分钟内调了50次/api/inventory，或者单次返回10万条记录，立刻熔断，返回429 Too Many Requests，并告警。这防止AI因提示词不当或模型幻觉，陷入疯狂循环调用。

我见过最惊险的一次：一个AI助手被训练去“优化采购计划”，它的提示词是“请分析所有SKU的库存和销售，生成补货建议”。模型理解偏差，以为要“穷举所有可能组合”，开始递归调用/api/sku/list获取SKU，再对每个SKU调/api/inventory和/api/sales。没沙箱的话，它能在30秒内打垮ERP的库存服务。有了沙箱，网关在第7次调用时就熔断了，并在日志里清晰标记：“Session sess-abc123 触发高频扫描策略，已拦截”。

3.3 审计流水线：从日志到证据链

网关的审计不是简单记录，而是一条自动组装的“证据链”。它把零散的事件，按时间、按会话、按用户，自动聚合成可读的审计包。每个包包含三个层次：

第一层：请求元数据

• request_id: 全局唯一ID（UUID v4）
• initiator: 发起人（用户邮箱或工号）
• ai_model: 使用的模型（如qwen2-72b、llama3-70b）
• timestamp: 请求到达网关时间（ISO 8601）

第二层：意图解析

• prompt_raw: 原始提示词（脱敏：手机号、身份证、银行卡号替换为[PHONE]、[IDCARD]）
• prompt_intent: NLP模型识别的意图（如inventory_forecast,order_status_inquiry）
• prompt_risk_score: 基于关键词和长度计算的风险分（0-100，>70标红）

第三层：执行轨迹

• api_calls: 数组，每项含path,method,params,response_size,status_code,duration_ms
• data_summary: 统计信息（如"read 128 rows from po_header, 45 rows from po_line"）
• policy_applied: 应用的策略名（如salesrep_order_access,finance_pac_restriction）
• anomalies: 异常标记（如"field_cost_price_was_filtered","export_action_denied"）

这个结构，让审计人员能快速定位问题。比如发现数据泄露，他们不用翻几十个日志文件，只需输入request_id，就能看到完整链条：张三问了什么，AI理解成什么，调了哪些接口，返回了什么数据，网关做了哪些过滤，最终输出是否合规。更重要的是，它支持“反向追溯”。内审发现一份报告里包含了不该出现的成本数据，他们可以用报告里的某个SKU编号，反向搜索所有调用过/api/cost/detail的request_id，再逐个检查prompt_raw，很快就能定位到是哪个提示词（比如“列出所有SKU的完整成本构成”）触发的。

3.4 合规适配器：让网关懂你的行业规矩

不同行业，合规重点不同。金融行业盯“客户隐私”，制造业盯“成本数据”，医疗行业盯“患者信息”。网关不能一刀切，必须有合规适配器。

我们为常见场景预置了适配器：

• PAC成本法适配器：专为Oracle EBS和SAP客户设计。它识别/api/cost/pac、/api/standard/cost等路径，强制启用字段级脱敏（material_cost,labor_cost,overhead_cost全部替换为[COST_HIDDEN]），并记录每次调用的costing_method参数（如FIFO,Average,Standard），确保成本法使用合规。
• 行级权限适配器：对接Java生态的Shiro或Spring Security。它把网关的row_filter表达式，编译成JPA Criteria Query，注入到ERP的DAO层。这样，即使ERP后端是老系统，也能在数据库查询层面实现行级控制，不用动业务逻辑。
• GDPR/CCPA适配器：当检测到提示词含"customer data"、"personal info"等关键词，且initiator是欧盟或加州地区用户时，自动启用强化脱敏：所有姓名、地址、邮箱、电话，无论字段名是什么，一律替换为[PERSONAL_DATA]，并在日志中标记compliance_mode: gdpr_enforced。

适配器的价值，在于把通用的网关能力，变成贴合你ERP系统和行业规范的具体动作。它不是配置开关，而是可插拔的“合规翻译官”。

4. 实操落地：从0到1搭建权限与审计网关的六个关键步骤

理论讲清楚了，现在说怎么动手。别被“网关”二字吓住，它不是要你从头造轮子。我推荐用“渐进式改造”策略，用现有开源组件搭起来，6周内上线最小可行版本（MVP）。下面是我给客户做的标准实施路径，每一步都踩过坑，附上避坑指南。

4.1 步骤一：流量劫持——让所有AI-ERP通信必须经过网关

这是第一步，也是最关键的一步。如果AI工作台还能绕过网关直连ERP，那后面所有策略都是纸老虎。

方案选择：

• 推荐：反向代理（Nginx + OpenResty）
  部署一台Nginx服务器，把ERP的API域名（如erp-api.company.com）DNS指向它。Nginx配置upstream指向真实的ERP后端，并启用OpenResty的Lua脚本做策略执行。优点：轻量、高性能、成熟稳定，90%的客户用这个。
• 备选：Service Mesh（Istio）
  如果你们已经在用K8s和Istio，可以直接在Sidecar里注入网关逻辑。适合云原生架构，但学习成本高，小团队慎用。
• 不推荐：修改AI工作台代码
  让开发在AI代码里硬编码网关地址。问题：每次AI升级都要改，维护成本爆炸，且容易遗漏。

实操要点：

1. 在Nginx配置里，定义location /api/块，所有以/api/开头的请求都走网关逻辑。
2. 关键配置：proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;，确保网关能拿到真实客户端IP。
3. 避坑指南：务必关闭Nginx的proxy_buffering off;。ERP API返回的JSON可能很大（尤其导出类接口），如果缓冲区太小，Nginx会截断响应，导致AI收到不完整数据。我们线上用proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k;。

4.2 步骤二：身份桥接——打通AI用户与ERP用户的映射

网关要知道“谁在用AI”，才能应用策略。这需要一个轻量级的身份桥接服务。

方案：

• 写一个简单的REST API（Python Flask或Node.js Express），接收AI工作台传来的user_token（JWT），解析出user_id、role、department，再查LDAP或HR系统，补充region、manager_id等属性，返回一个标准化的user_contextJSON。

实操要点：

1. AI工作台在每次请求ERP前，先调用这个桥接API，拿到user_context，再把user_context作为Header（如X-User-Context）传给网关。
2. 避坑指南：不要在桥接API里做复杂查询。我们曾有个客户，桥接API要去查4个系统才拼出完整上下文，平均耗时800ms，拖慢了整个AI响应。后来改成：桥接API只查LDAP（毫秒级），其他属性（如region）由AI工作台在登录时缓存并随请求带上，网关只做校验。

4.3 步骤三：策略定义——用AIPSL写你的第一条规则

别一上来就写100条策略。从最痛的点开始，写一条能立刻见效的。

示例：禁止AI导出含成本价的采购单

policy "block_cost_export" { when { api.path == "/api/po/export" user.role in ["SalesRep", "WarehouseStaff"] } then { deny_actions = ["export_csv", "export_excel"] log_message = "AI export blocked: user ${user.role} not authorized for cost data" } }

实操要点：

1. 把策略文件放在Nginx同机的/etc/nginx/aipsl/目录下。
2. OpenResty的Lua脚本启动时，加载所有.aipsl文件到内存。
3. 避坑指南：策略里不要写if user.role == "Admin"这种硬编码。用user.role in ["Admin", "SuperUser"]，方便后期扩展。我们吃过亏：某次客户新增了FinanceAdmin角色，忘了加到策略里，结果这个角色的AI导出也被拦了，引发投诉。

4.4 步骤四：审计日志——用ELK搭建你的AI行为监控台

日志是网关的眼睛。必须让它看得清、查得快。

方案：

• Logstash：Nginx日志格式化后，用Logstash过滤，提取request_id、prompt_hash、api_path等关键字段。
• Elasticsearch：存储结构化日志，建好索引模板（ai-audit-*）。
• Kibana：配置仪表盘，核心看板包括：
  • 实时请求流（按user_id、api_path、status_code着色）
  • 高风险提示词TOP10（按prompt_risk_score排序）
  • 策略命中统计（哪个策略被触发最多）

实操要点：

1. Nginx日志格式必须自定义，包含所有需要的字段：log_format ai_audit '$time_iso8601|$http_x_user_id|$http_x_prompt_hash|$uri|$status|$body_bytes_sent|$request_time|$http_x_policy_applied';
2. 避坑指南：日志量巨大，务必设置索引生命周期（ILM）。我们线上是：热节点存7天，温节点存30天，冷节点存180天。否则ES磁盘爆满，整个监控就瘫了。

4.5 步骤五：沙箱集成——给ERP后端打一个轻量补丁

沙箱能力需要ERP后端配合。好消息是，改动极小。

方案：

• 在ERP后端API的入口函数里，加几行代码：

  // Spring Boot 示例 @Before("execution(* com.company.erp.controller.*.*(..))") public void injectAiSession(JoinPoint joinPoint) { String aiSessionId = request.getHeader("X-AI-Session"); if (StringUtils.isNotBlank(aiSessionId)) { // 将aiSessionId存入ThreadLocal，供后续DAO使用 AiContext.setSessionId(aiSessionId); } }

• DAO层查询时，检查AiContext.getSessionId()，如果有值，就在SQL里加AND ai_session_id = ?条件。

实操要点：

1. 不要改核心业务逻辑，只加“钩子”。我们给客户打补丁，平均每个API加3行代码，半天搞定。
2. 避坑指南：务必处理ai_session_id为空的情况。有些老接口不走网关，AiContext.getSessionId()会是null，DAO层要判空，避免SQL报错。

4.6 步骤六：灰度发布与效果验证——用数据说话

上线不是终点，是起点。必须验证效果。

验证方法：

• 红蓝对抗：让安全团队模拟攻击，用各种提示词（如“导出所有采购单的完整字段”、“给我看张三的工资条”）测试，看网关是否准确拦截。
• A/B测试：对5%的AI流量开启网关，95%直连ERP，对比两组的“高风险API调用次数”、“平均响应时间”、“用户投诉率”。
• 业务验收：找3个典型用户（销售、采购、财务），让他们用AI完成日常任务，记录是否出现“权限不足”报错，以及报错是否合理（比如真不该看的，拦住了；该看的，没拦）。

实操要点：

1. 第一周，只开启审计日志，不拦截任何请求（deny_actions留空）。目的是观察AI的真实行为模式，收集基线数据。
2. 第二周，开启字段过滤（fields_allow），但不禁用导出。
3. 第三周，全面启用所有策略。
4. 避坑指南：永远保留一个“逃生通道”。在网关配置里加一条全局策略：if user.id == "admin@company.com" { bypass_all_policies = true }。万一策略写错导致大面积故障，管理员能立刻绕过，恢复业务。

5. 常见问题与实战排障：那些文档里不会写的细节

再好的设计，落地时也会遇到千奇百怪的问题。我把过去两年帮客户解决的Top 10问题，连同根因和解法，整理成这张表。这些都是血泪教训，不是理论推演。