过去做 ERP 权限，大家问的问题通常很直接。

谁能看订单？谁能改库存？谁能审批采购？谁能导出结算数据？

这些问题最后大多会落到菜单、按钮、字段和数据范围上。一个角色能不能进入某个页面，能不能看到某个仓库，能不能点击某个操作，权限设计基本就完成了。

但当 AI Agent 开始进入 ERP，这套逻辑不够用了。

因为 AI 不只是多了一个新页面。它可以理解一句模糊的问题，跨订单、库存、履约、结算等多个对象查找信息，再生成判断、草稿，甚至发起动作。

这时真正要回答的，不再只是“这个人能不能点这个按钮”，而是：AI 能看到什么？它可以基于这些信息得出什么结论？它能代表谁发起什么动作？出了问题，又该怎么追溯？

所以我越来越觉得，AI 时代的 ERP 权限设计，值得重新做一遍。

一、传统权限管理的是页面，AI 面对的是上下文

在传统 ERP 中，权限常常和页面绑定。

采购人员能进采购模块，仓库人员能处理入库和出库，财务人员能看结算和账单。即使再细一些，也通常是“能否查看、能否编辑、能否审批”这几种区别。

这种方式适合人操作页面，因为人的意图相对明确。进入一个页面、点击一个按钮，系统比较容易判断他想做什么。

AI 的情况不一样。

当用户问：“最近哪些商品有缺货风险，先处理什么？”AI 为了回答，可能需要看到销量、可用库存、在途、订单占用、补货周期和渠道优先级。

这些信息来自不同对象，也可能属于不同的数据范围。单看每一份数据都不敏感，拼在一起却可能暴露更完整的经营情况。

因此，AI 的权限不能只按菜单划分。它还要管理上下文：哪些业务对象可以被查询，哪些字段可以被使用，哪些数据只能汇总展示，哪些不能被带入回答和分析。

二、能看数据，不等于能使用数据做判断

这是 AI 场景里很容易被忽略的一层。

有些信息可以让用户看到，但不一定适合被 AI 当成经营判断的依据。

比如，已经确认的库存和订单状态，可以作为相对可靠的经营事实；外部回传的物流轨迹、尚未完成的仓库处理进度，可能仍在变化；销量预测、缺货风险则更像分析结果，本身就带着假设。

如果 AI 不区分这些信息的性质，很容易把一条尚未确认的状态，当成确定事实；把一个风险提示，当成必须执行的结论。

所以，权限设计除了回答“能不能看”，还要回答“能不能用于判断”。

AI 在回答或提出建议时，应该知道哪些是已确认事实，哪些只是参考，哪些需要提醒用户二次确认。否则表面上是给了更聪明的分析，实际是在放大数据口径不清带来的风险。

三、AI 可以提建议，但不能天然拥有执行权

很多团队做到后面，都会遇到一个很现实的问题：AI 已经发现了异常、整理了影响范围、生成了方案，那能不能顺手帮用户执行？

答案不应该是一刀切的“可以”或“不可以”，而应该看动作本身。

让 AI 汇总信息、生成日报、准备沟通草稿、提醒责任人，通常风险较低。这些动作不直接改变经营事实，更多是在替团队节省查找和整理的时间。

让 AI 识别库存风险、判断影响、列出补货或调拨方案，风险会更高一些。它可以完成分析，但最终选择什么方案，应该由负责人来确认。

一旦涉及库存调整、采购提交、价格变化、履约承诺、资金相关操作，性质就变了。AI 可以按规则发起，但不能因为用户说了一句“你看着处理”，就自动拿到最终执行权。

这里最重要的不是给 AI 一个很大的权限，而是把授权说清楚：它能代表哪个角色，在什么条件下，调用哪一个标准动作；这个动作是否需要审批；失败、超时或重复提交后，谁来处理。

四、权限不再只属于人，也要属于一次任务

传统权限通常以“人”为中心：张三是什么角色，能访问什么数据，能执行什么操作。

但 Agent 在系统里工作时，还需要增加一个维度：这一次任务是什么。

同一个用户，问“帮我解释这周的履约异常”和说“帮我提交一批采购单”，对应的权限要求应该完全不同。

前者可能只需要读取授权范围内的数据；后者除了要校验用户本人的操作权限，还要检查采购规则、审批条件、金额范围和当前业务状态。

也就是说，AI 不该拿着用户的全部权限到处使用。更合理的做法是，按任务临时授予最小范围的权限。

它为了回答一个问题，只拿到完成这个问题需要的数据；它为了发起一个动作，只得到这一次动作所需的授权。任务结束，授权也就结束。

这样做会让设计复杂一点，但能避免“用户有某项权限，AI 就自动拥有所有相关能力”的问题。

五、AI 的每一次动作，都要比人工更容易追溯

人操作 ERP 时，我们通常会记录操作人、操作时间、变更前后内容。

AI 发起动作时，至少还要多记几件事。

是谁发起了这次请求？AI 用了哪些数据和规则？它给出了什么建议？用户或审批人确认了什么？最终调用了哪个业务动作？执行过程卡在哪里，结果是否被外部系统确认？

这不是为了把日志做得更复杂。

它的作用是让团队在出现问题时能回答：这是 AI 自己推断错了，数据本身有问题，规则没有定义清楚，还是人在确认时作了错误取舍？

只有把这些过程留下来，AI 才不是一个不可解释的黑盒，而是一个可以被复盘、被纠正的协作角色。

从“菜单权限”走向“数据、任务和动作权限”

如果要给 AI 时代的 ERP 重新设计权限，我觉得至少要把权限拆成三层。

第一层是数据权限。谁能看到哪些业务对象、哪些字段、哪些组织或数据范围；AI 能否读取，以及能否在回答中使用这些信息。

第二层是任务权限。AI 是否可以为这个用户处理这类问题，例如查数、分析异常、生成草稿或调用某一类 Skill。任务不同，获得的上下文也应该不同。

第三层是动作权限。AI 是否可以发起某个标准操作；操作能否直接执行，还是必须进入审批；发生失败或异常时，应该由谁接住。

这三层不是为了让权限系统变得更重，而是为了让 AI 的能力越强，边界越清楚。

最后：AI 权限的核心，不是“限制”，而是“可放心地使用”

很多人一谈权限，第一反应是限制 AI，不让它做事。

但权限真正的价值，是让团队知道什么可以放心交给 AI，什么必须保留给人和既定流程。

边界不清，AI 只能停留在聊天和演示；边界清楚，它才能真正进入订单、库存、履约、结算等日常工作流，为团队减少重复劳动。

下一次设计 AI Agent 时，不妨先问五个问题：

1. AI 为完成这个任务，最少需要读取哪些数据？
2. 哪些数据可以展示，但不应直接作为判断依据？
3. 它可以提出建议到什么程度，哪一步必须由人确认？
4. 它代表谁发起动作，动作是否符合既有审批和业务规则？
5. 出现错误、超时或重复执行时，我们能否还原完整过程？