智能体问数，谁能问哪些数？权限要卡在数据行上

一句「帮我查一下」，跨了三个部门

周一早上，销售总监在对话框里敲了一行字：把华南区今年上半年的毛利率按客户拉一下。三秒后图表出来，前五名客户一目了然。

这行字背后发生了什么？系统要知道「华南区」在这个组织里对应哪几个销售组织、哪几个工厂的出货；要知道「毛利率」用的是哪一版口径——含不含运费、返利算不算成本；还要知道提问的人有没有权限看到客户级的价格与成本。三件事里任何一件没答对，图都出不来，或者出一个错的。

而最容易出事的，是第四件事：这个人到底该不该看到这些客户的价格。

AI 问数让取数变简单了，同时也让越权变简单了。以前要越权，得知道去哪个菜单、点哪个导出、绕过谁的审批；现在只需要把问题问得委婉一点。所以智能体上线时真正要设计的东西，不是「能问多少」，而是「谁能问哪些」。

智能体不是新开一个数据出口

很多企业上 AI 问数，第一反应是给智能体配一份「数据源账号」。这个动作看似省事，实际上是给全公司开了一个只读的后门：智能体用一个高权限账号连库，然后所有提问的人都借这个账号取数。

问题在于，这个账号的权限跟提问的人没有关系。仓管问一句「上个月原材料成本多少」，智能体照样答得出来——因为它连的是那个高权限账号。这类系统在演示时体验极好，一进审计就解释不通：谁在什么时候看了什么数据，日志里只有「智能体」。

正确的做法反过来：智能体不持有自己的数据权限，它继承当前登录人的权限上下文。用户是谁、属于哪个部门、担任什么岗位、能看到哪些数据行，这些在请求进来的那一刻就确定了，智能体只是在这个边界内组织查询、生成图表、写清口径。

判断一个 AI 问数产品是不是这么做的，有个很简单的问法：把同一个人从 A 部门调到 B 部门，第二天他问同样的问题，答案会不会变？会变，说明权限是真的在起作用；不变，说明权限是装饰。

JEDP 的双智能体就是这个结构：设计态用自然语言建模、经设计器发布；运行态在本人授权范围内问数，可输出对话框图文，也可导出 Office、HTML、Markdown，并可经平台业务接口创建单据、办理审核。它不直写数据库，取数也不会超出当前账号在对应列表页上命中的权限组。

权限组决定智能体能查到哪些行

平台列表取数本来有两道关：页面上的过滤条件由前端打包下来，发布时配的权限组由服务端强制执行。智能体问数只认后面这一道——它拿不到前端的过滤包，也不该拿。所以真正决定「智能体能问到哪些数」的，是权限组，不是模型自觉。

一个人命中多个组时取并集；一个组都没命中、或者这个列表页压根没配权限组，落到本人可见——这是最严的一档，不是最松。所谓本人可见，也不只是「我建的单」，还包括我待办过、已办过、被抄送或转发过的流程单据。平台列表就是这么算的，智能体必须对齐，否则用户会立刻发现「列表里有、问数查不到」。

用户问的那句话未必带着列表页。系统会先按列表名反查、再按主表反查，逐级往下找；都找不到，仍然落到本人可见。不管走哪条路径，铁律只有一条：同一个登录人，智能体可见的行必须是他能在对应列表页看到的行的子集——可以更严，不能更宽。

字段权限更容易出岔子：藏起来不等于问不出来。列表上把「成本价」这一列藏了，如果只在页面上隐藏、执行层没把列裁掉，用户换个说法——「帮我把这个物料的采购单价列出来」——数据照样出来。隐藏是展示，裁列才是权限。

越权要当场拒绝，而且要留痕

「先问出来再说」是 AI 问数最危险的一句话。它的诱惑在于：数据反正已经在库里，模型也读到了，不给看有点浪费。

但拒绝本身是有价值的。用户问「华南区客户毛利」而他只有华东权限时，系统应该明确告诉他：当前账号的数据范围是华东，无法返回华南客户明细。这句话同时完成了三件事——告知边界、避免误判为系统故障、留下一条可审计的记录。

最后一行值得多说一句。真正的越权往往不是一次拿全，而是分十次拿局部再自己拼。单条日志都合规，只有把同一账号的提问序列放在一起看，才看得出意图。所以问数日志要能按人、按时间、按指标聚合，而不是只留一句「谁问过什么」。

导出与办理：比「看一眼」危险得多

查询和导出不是一个风险等级。查询的结果留在系统里，导出会把数据带到系统外，一次导出可能等于一次数据外流。

导出至少要管三件事：字段范围（敏感字段默认不进导出模板）、次数与体量（超出阈值要审批或直接拒绝）、可追溯（文件带水印或可定位到人）。薪酬、成本、客户协议价这类域，建议默认只给汇总不给明细。

写操作的风险还要再上一级。让智能体「帮我把这张不合格单关掉」，听起来是效率提升，实际上是绕过了审批链。合规的做法是：智能体可以发起、可以预填、可以提示缺什么字段，但提交必须走业务接口，落到原来的流程节点上，由该节点的审批人办理。智能体不代他人审批，这一点没有例外。

权限从哪来：别在智能体里另建一套

如果智能体需要单独维护一份「谁能问什么」的配置，那它迟早会和主权限系统对不上。对不上的后果不是报错，而是两边都有人相信：业务以为智能体受限，IT 以为主系统受限，中间那段就是空洞。

授权应该只有一处来源。人员入职、调岗、兼岗、离职，权限在主系统里变一次，智能体这边自动跟着变。权限组在列表页发布时一次配好——适用人员、数据范围、字段权限都在那一处；组织引擎提供部门树、岗位任职与汇报关系供条件引用，智能体只做消费方。

有两个细节决定了这套东西能不能长期用下去。第一是授权随任职生效日切换，兼岗、借调、代理要显式建模并设期限，否则「先开着方便」会变成永久超额权限。第二是回收：离职、调岗、项目结束时的授权回收要有人负责、有时间点，权限债务不会自己消失，只会积累到某次审计爆发。

开放顺序：先冻口径，再放范围，最后开写

很多项目一上线就把问数范围开到最大，理由是「让大家先体验到价值」。这个顺序恰好是最危险的。

每一步都设一个明确的完成标志，比设一个上线日期有用得多。特别是第一步——口径没冻结就开放问数，得到的是「同一个毛利率有三个数」的混乱，而且模型会把这种混乱放大，因为它答得又快又自信。

六项验收：能演示才算做到

权限设计最容易停在 PPT 上。验收时不要看架构图，让对方当场演示这六个动作：

1. 用 A 部门账号问 B 部门的数据，系统明确拒绝并说明范围
2. 用同一账号问超出字段权限的敏感列，只拒绝该列，其余正常返回
3. 换一个只有查看权限的账号，尝试发起单据，被拒绝
4. 把账号从 A 部门调到 B 部门，第二天同一问题答案随范围变化
5. 连续快速导出二十次，触发限流或审批
6. 查一条越权记录，能看到谁、什么时候、问了什么、被哪条规则拒绝

六项都能演，权限才算落到了系统里。有一项演不出来，就说明那块还停留在制度层面。

什么情况下先别上

最后说边界。有三种情况，我的建议是先把基础打好，别急着开放问数。

第一种，权限矩阵本身很乱——角色按人复制、数据范围靠约定、离职账号没人停用。这种情况下上智能体，等于把原来要层层点开才能拿到的数据压缩成一句话就能拿到，风险被放大而不是被收敛。

第二种，指标口径还在每周改。模型会把每一版口径都讲得很有道理，用户会以为那是结论。

第三种，主数据没有唯一性——同一个客户三个档案、同一个物料两种编码。问数结果会在聚合时把同一件事算成两件，而且看不出来。

这三种都不是 AI 的问题，AI 只是把它们暴露得更快。反过来说，如果这三件已经做好了，AI 问数带来的效率提升是真实的：不用等人导表、不用为了一个数开半小时会、口径说明跟着答案一起出来。

• 双智能体：设计态与运行态的能力边界
• 权限引擎：数据行与字段级授权
• 组织引擎：以人为核心的组织主数据
• 多租户与组织隔离决策表
• 设计态与运行态为什么必须分开