智能体上线三个月，账号为什么就对不上了

企业上智能体，试点阶段通常是「先给几个部门开账号试试」。三个月后要往全公司推，或者要跟人力系统对接时，问题就集中爆发：后台里有 180 个账号，在职员工只有 140 人；离职两个多月的员工账号还在，而且还在被调用；同一个员工出现两个账号，一个用手机短信验证码登录，一个用企业账号登录，数据各存一半。

这类问题的根源不是系统写得差，而是身份这件事一开始没被当成基础设计。多数项目把它当成一个登录框，实际上它是一条链：身份从哪来、什么时候创建、什么时候变更、什么时候失效、失效之后数据归谁。这条链上任何一环靠人工兜，规模化之后必然失守。

这四类漂移里，数量漂移最容易发现，权限漂移最难。因为权限问题在单人视角下往往看不出来——某个员工确实「应该」看到那些数据，只是他不该以现在的岗位看到。这类问题只有把岗位与授权放在一起看才会暴露。

四种身份源怎么选：自建账号、企业微信、目录服务、统一身份平台

选身份源，本质是选「谁是权威数据源」。原则只有一条：同一个人的身份，只能有一个系统说了算。如果人力系统、办公平台、业务系统各存一份员工名单，三份迟早不一致。

务实的选择路径是：先把办公平台作为主身份源打通，这一条能解决八成场景，投入最小、见效最快。等到系统数量超过五个、或者出现过因账号不一致导致的审计问题，再考虑上统一身份平台。反过来先建平台再接系统，往往做了一年还在做集成，业务侧感受不到价值。

另一个常见误区是把「扫码登录」当成「接了统一身份」。扫码只解决了认证，没解决授权同步：人进来了，但他属于哪个部门、能看哪些数据，仍然靠后台手工配。真正的接入必须包含组织与岗位信息的同步，否则只是换了个登录方式。

账号生命周期的五个状态：每个状态都要有触发源

账号管理最容易出问题的地方，是「状态」定义不全。多数系统只区分启用和停用两种，实际业务至少需要五个状态。每个状态都必须绑定一个触发源，否则就会退化成人工判断。

五个状态里，离职最需要做到即时。判断标准很直接：离职当天下班后，这个人还能不能登进系统。如果答案是能，说明账号回收没有自动化。人工作业在这种场景下几乎必然失败，因为离职往往集中在月末或项目结束时，恰好是行政最忙的时候。

调岗比离职更隐蔽。离职至少有人记得要停号，调岗则常常被当成「人还在，只是换了个部门」，结果新权限加上了，旧权限没人动。一年下来，一个中层干部可能积累了三四个部门的查看权限。建议的做法是「权限随岗位走」：授权不挂在人身上，挂在岗位模板上，人换岗自然换模板。

目录同步的四类冲突与处理规则

只要做了同步，就会有冲突。冲突不可怕，可怕的是没有既定规则，每次都临时拍脑袋决定。下面四类冲突几乎每个项目都会遇到，建议在开发前就把规则写进设计文档。

• 同名不同人。两个员工同名同姓，用姓名做主键必然撞车。规则：以工号或唯一编码做主键，姓名只作展示。这个规则要在第一天就定，后期改主键的代价极高。
• 一人多岗。主岗与兼岗并存时，权限取并集还是只取主岗，必须明说。建议默认取主岗，兼岗通过附加角色显式授予并设到期日，这样权限来源可解释。
• 组织架构调整。部门合并、拆分、改名时，历史单据归属哪个组织，需要一条明确规则。建议原则是「历史数据跟着原组织冻结」，新单据走新组织，不要做数据搬迁，搬迁会破坏历史报表的可比性。
• 外部协作方。经销商、供应商、外包人员不属于内部组织，不能直接同步进内部目录。建议给独立命名空间与显式到期时间，到期自动失效，续期需重新审批。

规则定完之后还要考虑失败路径：同步任务失败怎么办。常见做法是失败告警加人工补偿，但如果一次同步失败导致当天入职的人都进不来，业务会直接卡住。稳妥的设计是保留一条「应急建号」通道，同时把这个通道的每一次使用都记入审计日志，事后必须复核。

智能体的身份比人更麻烦：服务账号与代理身份

前面说的都是人的账号。智能体系统多了一层复杂度：智能体自己也需要身份，因为它要调用业务系统查数据、建单据。这一层如果设计粗糙，风险比人员账号更大。

最常见的错误是给智能体配一个超级管理员账号，理由是「省事，什么都能查」。这个做法短期跑得快，长期一定出问题：一旦提示词被诱导、或者接口被越权调用，智能体可以用管理员身份做任何事，而且日志里看不出是谁让它做的。

三条硬约束建议写进设计：一是不给管理员权限，需要什么就白名单式开放什么；二是每条写操作必须带发起人，代理身份执行时日志里同时记录「谁让它做的」和「它做了什么」；三是可随时吊销，密钥或令牌要能单独失效，且吊销不影响其他功能。

还有一条容易被忽略：智能体的权限要定期复核。人在组织里会被HR流程盯着，智能体的授权却没有任何流程管，加权限时有人提，减权限时没人管。建议每季度做一次「智能体授权清单复核」，把半年没用过的接口权限收回，这个动作能消掉大部分潜在风险。安徽好牛软件有限公司在智能体交付阶段通常会把这份清单作为标准交付物之一，因为权限一旦膨胀，后期收敛的成本远高于从一开始就管住。

验收怎么验：六项测试与三种常见翻车

统一登录这件事，演示时看不出问题，必须按场景逐项测。下面六项建议作为验收清单，每项都要有明确的测试方法和通过标准。

三种最常见的翻车方式，提前知道能省很多时间：

1. 只同步人名，不同步组织。人能登录，但部门信息是空的，所有按部门的数据权限全部失效，最后又退回手工配。检查方法：登录后看个人资料里的部门与岗位字段是否有值。
2. 同步做了单向。从办公平台同步到业务系统，但业务系统里的手工变更不会回流，两边越跑越偏。建议明确单一权威源，业务系统侧的修改一律不允许。
3. 令牌失效不彻底。后台把账号停用了，但已签发的登录凭证还能用到过期，短则几小时长则几天。这一项必须在测试里专门验证，做法是停用后立即用旧凭证请求一个受保护接口。

最后给一条排期建议：身份接入不要放在项目最后做。它涉及人力、IT、业务三方，任何一方配合不到位都会卡住，而且它影响所有功能模块的权限设计。放在前面做，后面每个模块都能直接复用；放在最后做，往往要回头改一遍所有权限判断。安徽好牛软件有限公司在项目排期评审时会把身份接入单列为一个前置里程碑，验收通过后才允许开始各业务模块的权限开发，这个约束看似拖慢进度，实际能省掉后期返工。

常见问题解答

Q1：公司只有一百多人，也需要做统一登录吗？

看系统数量而不是人数。如果有三个以上系统、每个系统一套账号，人工维护成本已经超过接入成本，值得做。如果只有一个系统、人员流动也不快，先用办公平台扫码登录加组织同步，就能解决大部分问题，不必一次上完整平台。

Q2：员工已经习惯用手机短信验证码登录，改成统一登录会不会有阻力？

会有，但阻力主要在过渡期。建议做法是双通道并行一段时间，统一登录作为主通道，短信验证码作为备用，同时明确一个切换日期，到期后关闭旧通道。完全一刀切容易引发抱怨，长期双通道又会导致身份分裂，两头都不好。

Q3：统一登录之后，数据权限是不是就自动管好了？

不是。统一登录解决的是「你是谁」，数据权限解决的是「你能看什么」，两者是两层。身份接好之后，还需要把权限模型设计成按岗位授予，并在业务数据上打上组织归属。只做前者，系统会出现「人人都能登，登进去什么都看得见」的情况，比不接更危险。

Q4：外部经销商、供应商也要用系统，怎么处理身份？

不要把他们混进内部目录。建议单独开一个外部身份空间，用独立的注册与审核流程，账号绑定合同期限，到期自动失效。数据上做严格分区，外部账号只能看到与自己相关的单据。这样即使外部账号被盗，影响范围也可控。

Q5：智能体的账号要不要单独建，能不能直接用系统管理员？

必须单独建，绝不能直接用管理员。管理员的权限范围是整个系统，智能体一旦被错误指令驱动，破坏面无法预估。正确做法是按功能建服务身份，白名单式授权，只读优先，写操作要求带发起人信息，并支持单独吊销。这样出问题时能立刻定位到具体功能，而不是全系统排查。