"
连接只是第一步。权限怎么管，数据安全怎么保障，如何满足审计要求，才是企业级系统落地的真正门槛……
因为后台的咨询声音热烈，从本期开始，老丁正式开始写WorkBuddy+企业ERP落地一席谈。
WorkBuddy+企业ERP落地的话题，无论在公众号，还是在某书，现在还处在一个很初级的阶段，老丁本身也是在学习的过程中。
所以这个话题我就想到哪说到哪，有些是实践过的，有些是自己的设想，如果大家有不同意见，我也算是抛砖引玉，我们共同探讨学习，共同碰撞出进步的火花。第一期先从大家最感兴趣、也最关注的权限问题说起。
话说那天WorkBuddy接上了云星空，群里一片「能查了能查了」，每个人都很兴奋，仿佛推开了新世界的大门。试点的那几天，大家用一个共享账号，查客户、拉报表、问库存，AI对答如流，体验拉满。
兴奋劲过了，第一个问题从开始冒了出来：销售经理张三能查客户数据没问题，但隔壁部门的李四凭什么也能查？更麻烦的是，李四不光能查，还能改。
试点阶段通常是这样：一个人、一个账号、一个目标，跑通就行。
推到部门就变味了。财务数据、客户信息、合同金额、库存流水，几十个人用同一个WorkBuddy身份进去，理论上什么都能看到。不是大家不可信，而是企业信息系统的底线从来不是「信任」，是「边界」。
问题不在于AI太聪明，而在于AI不知道你企业的组织边界在哪。
WorkBuddy本身没有「谁能看什么」的概念。它只是一个AI执行引擎：你问什么，它调什么。权限这件事，必须加一层来做。
WorkBuddy的对话自由，和ERP长期建立的数据权限体系，必须共存。
第1层是大门：这个人有没有公司钥匙。
第2层是走廊：进了公司，哪几个房间的门对他开放。
第3层是房间：进了办公室，是只能翻柜子，还是能改档案、能删记录。
这一层怎么在WorkBuddy里生效？关键不在WorkBuddy本身，而在代理层的身份映射。
代理层收到WorkBuddy发来的请求后，先查映射表，把WorkBuddy用户ID换成对应的云星空账号，然后以这个云星空用户的身份去调OpenAPI。从云星空的角度看，这个请求和一个真实用户登录后点击菜单发起的请求没有任何区别。张三的token只能查华北区客户，那代理层用张三的身份调API，返回的自然也只有华北区客户。李四没有财务模块权限，代理层就算帮他请求财务接口，云星空自己就会返回「无权限」。
代理层负责「扮演谁」，云星空负责「能做什么」。两件事不混淆，权限体系才是闭合的。
核心原则：第3层不重新发明轮子。云星空运行了这么多年，角色、数据权限、组织隔离体系已经成熟。WorkBuddy应该照单全收，而不是另起炉灶再造一套「AI权限」。
不要在代理层复制一份云星空的权限规则。两套规则一旦不一致，而且必然不一致，排查问题和安全审计的成本会指数级上升。让业务系统管业务权限，代理层只管「你是谁」和「你能去哪」。
为什么不直接把密钥给少数人？
说到权限，很多团队的直觉是：把云星空的API密钥只配给几个信得过的人，其他人WorkBuddy里没密钥，连都连不上。物理隔离，最是简单直接。
这条路在1-2人验证连通性时完全够用。但人数一上来，三个问题就藏不住了：
权限粒度：有密钥就等于拥有一切。 财务主管拿到密钥后，他的WorkBuddy能查客户、能改库存、能删订单。云星空那边根本分不清这个人是财务还是销售，因为所有操作走的是同一个密钥对应的同一个账号。要么全有，要么全无。
审计追溯：三个人共用一个密钥，日志里三个人是同一个「人」。 客户数据被误删了，库存数量被改错了，在云星空的操作日志里你只能查到「是那个账号干的」，查不到具体是谁。不是信任问题，是管理问题：好人也会出错，出错了找不到人。
密钥轮换：有人离职，所有人跟着改配置。 换一次密钥，每个持有者都要更新本地的WorkBuddy配置。漏掉一个人，他就断连了。更麻烦的是，你可能根本不知道哪些人的电脑上存过这份密钥。代理层模式下，服务器端改一次，所有人自动生效。
密钥分发和代理层不是对立的，而是同一件事的不同阶段：
控制力随着规模同步增长，不需要一步到位。
前文讲过代理层的两个角色：协议转换（WorkBuddy说MCP，云星空说OpenAPI）和安全隔离（密钥不下发，流量不出企业边界）。
本文补上第三个角色：身份守门人。
具体怎么做：
关键在于，云星空看到的还是原来的用户。张三的查询走张三的云星空账号，李四的查询走李四的。云星空内置的权限引擎原封不动地工作：张三只能看华北区客户，李四只能看华东区，该怎样还怎样。
代理层不是再造一套门禁系统，而是给每个人配了一把云星空已有的钥匙。钥匙不一样，能开的门自然不一样。
代理层做的事极其简单。一张映射表，管两件事：你能进哪些系统、你能做什么操作。
workbuddy_user_zhangsan → 云星空xs_zhang_sales（销售经理）
可操作系统：云星空（客户、合同、回款）、iKnow
允许操作：查询、看板、导出
禁止操作：新增、修改、删除
workbuddy_user_lisi → 云星空xs_li_finance（财务）
可操作系统：云星空（财务、应收应付）
允许操作：查询、看板
禁止操作：新增、修改、删除、导出
workbuddy_user_wangwu → 云星空xs_wang_ops（运营主管）
可操作系统：云星空（库存、订单）、知识库
允许操作：查询、新增、修改、看板、导出
禁止操作：删除
代理层管操作类型（查/改/删/导出/看板），云星空管数据范围（哪个区、哪些字段）。两层叠加，权限才完整。
具体怎么部署，取决于企业规模和使用阶段。
推荐路径：先用A：静态映射，跑通再切B：SSO打通。
路径A看起来「土」，但它是验证权限模型的最快方式。3-5个人、一张JSON表、半天上线。过程中发现的边界问题、角色冲突、异常场景，正好为后续切SSO积累经验。
如果一上来就做SSO打通，权限模型还没想清楚就绑死了身份源，后面想调整成本极高。
不管走路径A还是B，准备工作都一样。三步走：
角色选择建议（仅为示例）：
这三个角色覆盖了企业最典型的权限场景。试点跑通后，再逐步加入采购、仓库、高管等角色。
第2步选人时，每个角色至少安排两个人：一个主要使用，一个备用观察。目的不是互相制衡，而是在出现「他能查但我不能」「我查到的和他不一样」这类问题时，能快速对比两个相同角色账号的权限差异，定位是映射表问题还是云星空权限问题。
权限方案做得再好，审计过不去就是零。代理层方案在审计视角下的表现，优势明确，短板也需要正视。
四条审计及格线，代理层全部命中：
身份可追溯。代理层以映射后的云星空用户身份调API，云星空原生日志里记录的是「xs_zhang_sales在14:32查询了客户表」。审计员查的是云星空自己的日志，不需要额外培训。对比密钥分发模式下三人共用一个账号、日志全是「admin在操作」，审计直接判不合格。
权限清单可查。代理层的映射表，谁对应哪个云星空账号、允许查哪些模块、什么操作可以做，天然就是一份可提交审计的权限配置文档。不需要另外写权限说明书。
操作日志双链交叉验证。代理层加一层独立日志，以只追加模式（append-only）记录每一次身份切换和操作请求。审计时两条链交叉比对：代理层记「谁用什么身份做了什么」，云星空记「API层的请求与响应」，篡改其中一条会被另一条暴露。
最小权限原则。查/改/删/导出分级控制，每个人的权限范围精确到模块和操作类型，不存在「有钥匙就什么都能干」的模糊地带。
两个需要提前补的短板：
登录认证强度。代理层做身份映射的前提是WorkBuddy用户确实是本人。建议第一版就接入企业微信或飞书的统一认证，登录强度对齐企业现有标准。这是少数几个「越早做成本越低」的事情。
代理层自身的权限不能过大。代理层的服务凭证与业务用户凭证必须分离。代理层用自己的服务账号维持运行，切换身份时用的是各业务用户独立获取的token，而不是以管理员身份「模拟」用户。每个业务用户的token单独获取、单独存储、单独过期。代理层自己永远不会变成「超级账号」。
一般企业审计够用。涉及金融、医疗等强合规行业，需要补登录认证和日志防篡改两块，但这不是方案本身的缺陷，这些行业对所有系统接入都有同样的要求。
权限这件事，做得早不累，做得晚全是坑。
试点阶段大家用一个账号没人觉得有问题，等推广到50人、100人再回头补权限，那时候数据的访问记录已经混在一起，谁看了什么、谁改了什么，完全无法追溯。
代理层多写几十行映射代码，换来的是企业敢把AI交给每一个员工。而且这笔投入不是一次性的：后续其它系统接进来，都复用同一套身份体系。加一行「允许访问的系统」即可。三个系统也好，十个系统也好，代理层只维护一张表。
安全不是限制，是信任的边界。边界清晰了，AI才能在企业的每个角落里放心地跑起来
粤ICP备14082021号
免费POC，
零成本试错
