WorkBuddy+金蝶云星空落地一席谈：权限怎么管

因为后台的咨询声音热烈，从本期开始，老丁正式开始写WorkBuddy+企业ERP落地一席谈。

WorkBuddy+企业ERP落地的话题，无论在公众号，还是在某书，现在还处在一个很初级的阶段，老丁本身也是在学习的过程中。

所以这个话题我就想到哪说到哪，有些是实践过的，有些是自己的设想，如果大家有不同意见，我也算是抛砖引玉，我们共同探讨学习，共同碰撞出进步的火花。第一期先从大家最感兴趣、也最关注的权限问题说起。

话说那天WorkBuddy接上了云星空，群里一片「能查了能查了」，每个人都很兴奋，仿佛推开了新世界的大门。试点的那几天，大家用一个共享账号，查客户、拉报表、问库存，AI对答如流，体验拉满。

兴奋劲过了，第一个问题从开始冒了出来：销售经理张三能查客户数据没问题，但隔壁部门的李四凭什么也能查？更麻烦的是，李四不光能查，还能改。

试点阶段通常是这样：一个人、一个账号、一个目标，跑通就行。

推到部门就变味了。财务数据、客户信息、合同金额、库存流水，几十个人用同一个WorkBuddy身份进去，理论上什么都能看到。不是大家不可信，而是企业信息系统的底线从来不是「信任」，是「边界」。

问题不在于AI太聪明，而在于AI不知道你企业的组织边界在哪。

WorkBuddy本身没有「谁能看什么」的概念。它只是一个AI执行引擎：你问什么，它调什么。权限这件事，必须加一层来做。

WorkBuddy的对话自由，和ERP长期建立的数据权限体系，必须共存。

第1层是大门：这个人有没有公司钥匙。

第2层是走廊：进了公司，哪几个房间的门对他开放。

第3层是房间：进了办公室，是只能翻柜子，还是能改档案、能删记录。

这一层怎么在WorkBuddy里生效？关键不在WorkBuddy本身，而在代理层的身份映射。

代理层收到WorkBuddy发来的请求后，先查映射表，把WorkBuddy用户ID换成对应的云星空账号，然后以这个云星空用户的身份去调OpenAPI。从云星空的角度看，这个请求和一个真实用户登录后点击菜单发起的请求没有任何区别。张三的token只能查华北区客户，那代理层用张三的身份调API，返回的自然也只有华北区客户。李四没有财务模块权限，代理层就算帮他请求财务接口，云星空自己就会返回「无权限」。

代理层负责「扮演谁」，云星空负责「能做什么」。两件事不混淆，权限体系才是闭合的。

不要在代理层复制一份云星空的权限规则。两套规则一旦不一致，而且必然不一致，排查问题和安全审计的成本会指数级上升。让业务系统管业务权限，代理层只管「你是谁」和「你能去哪」。

为什么不直接把密钥给少数人？

说到权限，很多团队的直觉是：把云星空的API密钥只配给几个信得过的人，其他人WorkBuddy里没密钥，连都连不上。物理隔离，最是简单直接。

这条路在1-2人验证连通性时完全够用。但人数一上来，三个问题就藏不住了：

权限粒度：有密钥就等于拥有一切。 财务主管拿到密钥后，他的WorkBuddy能查客户、能改库存、能删订单。云星空那边根本分不清这个人是财务还是销售，因为所有操作走的是同一个密钥对应的同一个账号。要么全有，要么全无。

审计追溯：三个人共用一个密钥，日志里三个人是同一个「人」。 客户数据被误删了，库存数量被改错了，在云星空的操作日志里你只能查到「是那个账号干的」，查不到具体是谁。不是信任问题，是管理问题：好人也会出错，出错了找不到人。

密钥轮换：有人离职，所有人跟着改配置。 换一次密钥，每个持有者都要更新本地的WorkBuddy配置。漏掉一个人，他就断连了。更麻烦的是，你可能根本不知道哪些人的电脑上存过这份密钥。代理层模式下，服务器端改一次，所有人自动生效。

密钥分发和代理层不是对立的，而是同一件事的不同阶段：

控制力随着规模同步增长，不需要一步到位。

前文讲过代理层的两个角色：协议转换（WorkBuddy说MCP，云星空说OpenAPI）和安全隔离（密钥不下发，流量不出企业边界）。

本文补上第三个角色：身份守门人。

具体怎么做：

关键在于，云星空看到的还是原来的用户。张三的查询走张三的云星空账号，李四的查询走李四的。云星空内置的权限引擎原封不动地工作：张三只能看华北区客户，李四只能看华东区，该怎样还怎样。

代理层不是再造一套门禁系统，而是给每个人配了一把云星空已有的钥匙。钥匙不一样，能开的门自然不一样。

代理层做的事极其简单。一张映射表，管两件事：你能进哪些系统、你能做什么操作。

代理层管操作类型（查/改/删/导出/看板），云星空管数据范围（哪个区、哪些字段）。两层叠加，权限才完整。

具体怎么部署，取决于企业规模和使用阶段。

路径A看起来「土」，但它是验证权限模型的最快方式。3-5个人、一张JSON表、半天上线。过程中发现的边界问题、角色冲突、异常场景，正好为后续切SSO积累经验。

如果一上来就做SSO打通，权限模型还没想清楚就绑死了身份源，后面想调整成本极高。

不管走路径A还是B，准备工作都一样。三步走：

角色选择建议（仅为示例）：

这三个角色覆盖了企业最典型的权限场景。试点跑通后，再逐步加入采购、仓库、高管等角色。

权限方案做得再好，审计过不去就是零。代理层方案在审计视角下的表现，优势明确，短板也需要正视。

四条审计及格线，代理层全部命中：

身份可追溯。代理层以映射后的云星空用户身份调API，云星空原生日志里记录的是「xs_zhang_sales在14:32查询了客户表」。审计员查的是云星空自己的日志，不需要额外培训。对比密钥分发模式下三人共用一个账号、日志全是「admin在操作」，审计直接判不合格。

权限清单可查。代理层的映射表，谁对应哪个云星空账号、允许查哪些模块、什么操作可以做，天然就是一份可提交审计的权限配置文档。不需要另外写权限说明书。

操作日志双链交叉验证。代理层加一层独立日志，以只追加模式（append-only）记录每一次身份切换和操作请求。审计时两条链交叉比对：代理层记「谁用什么身份做了什么」，云星空记「API层的请求与响应」，篡改其中一条会被另一条暴露。

最小权限原则。查/改/删/导出分级控制，每个人的权限范围精确到模块和操作类型，不存在「有钥匙就什么都能干」的模糊地带。

两个需要提前补的短板：

登录认证强度。代理层做身份映射的前提是WorkBuddy用户确实是本人。建议第一版就接入企业微信或飞书的统一认证，登录强度对齐企业现有标准。这是少数几个「越早做成本越低」的事情。

代理层自身的权限不能过大。代理层的服务凭证与业务用户凭证必须分离。代理层用自己的服务账号维持运行，切换身份时用的是各业务用户独立获取的token，而不是以管理员身份「模拟」用户。每个业务用户的token单独获取、单独存储、单独过期。代理层自己永远不会变成「超级账号」。

一般企业审计够用。涉及金融、医疗等强合规行业，需要补登录认证和日志防篡改两块，但这不是方案本身的缺陷，这些行业对所有系统接入都有同样的要求。

权限这件事，做得早不累，做得晚全是坑。

试点阶段大家用一个账号没人觉得有问题，等推广到50人、100人再回头补权限，那时候数据的访问记录已经混在一起，谁看了什么、谁改了什么，完全无法追溯。

代理层多写几十行映射代码，换来的是企业敢把AI交给每一个员工。而且这笔投入不是一次性的：后续其它系统接进来，都复用同一套身份体系。加一行「允许访问的系统」即可。三个系统也好，十个系统也好，代理层只维护一张表。

安全不是限制，是信任的边界。边界清晰了，AI才能在企业的每个角落里放心地跑起来