一排没有主人到岗却永远亮着的工位指示灯，每张卡片上写着身份、凭据与有效期

一、给了身份，不等于随时可用

据公开报道，有一类个人 AI 助理产品把形态做成了”每个智能体一份身份”：独立邮箱、独立联系方式、独立的支付额度与一台专属运行环境，机主退出登录后它继续干活。报道里一周实测给出的结论值得抄在墙上——身份是给了，随时可用仍然没做到。

这句话对我们的工程判断很有价值，因为它把瓶颈从模型挪开了。一个能长期跑的智能体，它跑不动的原因通常不是推理能力不够，而是：它登不进某个系统、它的凭据昨天过期、它依赖那台运行环境被回收了、或者它以为自己做到第三步而外部世界其实停在第一步。这几件事全都是账号与运维问题，不是算法问题。

所以我们把一个智能体当作”组织里一类不会下班的主体”来对待。这个对待方式的第一步不是给它更强的工具，而是给它建一张台账。台账没有建起来之前，任何”我们的智能体全天候可用”的说法都是运气，不是能力。

二、台账：七个字段先立起来

台账不是一个目录清单，它要能回答”这个智能体现在有没有权做这件事，谁给的权利，谁负责”。最少七个字段。

字段 为什么必须有 缺失后的典型后果
创建者与批准人 说明这个主体为什么存在 出问题后没人承认是自己起的
代表的真人 每个智能体最终要挂在一个可联系的人身上 半夜出事找不到决策人，只能整体停机
授权范围 系统、数据、动作类型三层各自的边界 权限只增不减，越跑越宽
有效期 非人主体不该有”永久” 项目结束后仍在活跃调用
凭据存放位置 密钥库、托管服务还是某台机器的配置文件 凭据散落在笔记本与镜像层里
停用权限 谁能一键停，多快能停 需要拉群讨论该不该停
事故联系人 出事时按什么顺序通知谁 影响面扩散后才开始找人

七个字段里最容易被省掉的是”代表的真人”与”停用权限”。前者被省掉，系统里就出现了一批无主主体，行为像正常机器，出事像故意破坏；后者被省掉，应急动作要现攒审批链，等于把止损时间交给了流程。这两项我们在合同交付里会明确写成上线前置条件，洹拓经手的几个自动化项目里，返工成本最高的一处往往就补在这里。

三、人类员工账号与智能体账号：治理对照

拿员工账号的治理办法套智能体账号，方向是对的，但每一段的默认值都不同。

治理环节 人类员工账号 智能体账号
创建入口 入职流程触发，有 HR 记录 常常由某个人一次点击产生，需要显式审批才能进台账
身份来源 组织目录里的唯一条目 由目录条目派生，但派生关系要记下来，否则无法反查代表谁
权限授予 按岗位模板，变更走申请 按任务范围授予，且要写”任务结束即失效”的语义
变更同步 调岗、转部门由流程自动带动 没人管：代表的真人离职了，智能体还在跑
闲置处理 长期不登录会告警并回收 需要按”最后一次有效动作”判定，而不是按登录
退役注销 账号停用，凭据与邮箱一并回收 除了账号，还要注销令牌、退出会话、清理它写入的外部状态
审计粒度 以人与会话为单位 以任务为单位，一次任务可能横跨几十个动作与多个系统
出错归责 责任在持账号的人 责任在创建者、批准人与代表的人三者，要事先写清

差异里最容易出事的是”变更同步”。组织变动的自动化流程是为人生计的：人离职，账号回收。智能体账号在这个流程里通常不存在，于是它成了离职后仍然有效的门。把智能体账号放进目录系统、和它代表的真人建立强关联，是让同步机制能顺手把它一起处理掉的唯一办法。

四、生命周期四段

台账建好之后是四段管理，每段要有出口条件。

第一段，创建审批。谁能建、以什么理由建、初始授权范围是什么、有效期给多长。默认值应该是有期限的窄范围，而不是无限期的宽范围——因为收窄需要停机，放宽只需要一次变更。

第二段，权限随组织变更同步。三个触发点要接上：代表的真人发生岗位变动或离职；被授权系统的角色模型调整；智能体承接的任务边界变化。第三个触发点最难做，因为任务边界通常只写在提示词里。可行的做法是把任务与权限模型绑成一个可版本化的配置，而不是靠自然语言描述。

第三段，闲置回收。判定用”最后一次真实动作”，不是”最后一次登录”——长驻会话会让后者永远新鲜。给一个明确的闲置阈值，命中后先降级（凭据挂起、只留读权限），再回收，并在两个阶段都通知创建者。降级而不是立刻删除，是为了避免误杀季度性任务。

第四段，退役注销。这一段是三段的总和还要长，因为智能体的痕迹不止在账号里：令牌要吊销，会话要强制失效，它订阅的通知要退订，它在外部系统写过的中间状态要标注来源，它托管的额度要清零。退役单上如果只有”停用账号”一项，那这份记录基本没有价值。

五、”退出登录后继续工作”的三处代价

这个卖点在工程上意味着会话不再依附于人的在线状态，代价分三处。

凭据保存位置。人的凭据可以放在浏览器和钥匙串里，因为那台设备归他。智能体长期运行需要一份能在无人时读取的凭据，于是凭据要么进托管密钥服务，要么进某个运行环境的持久卷，要么被写进配置——第三种迟早出问题。判据很简单：任何一份长期凭据必须能回答”谁能读到、有没有第二份、能不能在不接触它的情况下吊销”。

令牌过期后的续期。短期令牌是安全设计的成果，长驻任务却把它当障碍。合理做法是用刷新凭据换短期令牌，并让刷新凭据本身也带期限与轮换；把令牌有效期改成一年，只是把风险从运维挪给了安全。更麻烦的是续期需要在浏览器里点一下的场景：这类”需要人来推一把”的依赖，要在台账里显式记成一个周期任务，而不是记成”到时候再说”。

无人值守时的二次验证。短信码、动态口令、设备确认，这三类都假定有个人在。给智能体留一条通道，等价于给攻击者留同一条通道。可行的替代是把二次验证换成基于设备与策略的验证（受管运行环境、密钥类凭据、按动作风险触发人工介入），并把”必须人工确认”的动作单独列一份清单——这一份清单要短，长了就变成了谁都不看的通知。需要说清的是，我们不主张把真人名下的号码与支付账户转给智能体使用，那是把个人身份和一个自动化主体的行为风险绑在一起。

六、四个断点与三个可验收项

把可用性做成能验收的东西，先承认断点只有四类。

断点 现场表现 检测信号 缓解
凭据过期 任务提交后无声失败 认证类错误码计数、距过期时间的倒计时 到期前告警，自动轮换，台账记录凭据寿命
被目标系统风控判定异常 突然要人工验证或被限速 同一动作的失败率陡增、验证页出现次数 走正式接入通道而不是模拟点击；限速与身份声明按对方规则来
运行环境被回收 重启后丢失本地状态与临时凭据 环境实例 ID 变化、磁盘剩余空间 状态外置，凭据不入镜像，环境可重建当作默认假设
任务状态与外部状态不同步 智能体以为做完了，外部没变 提交后回读实际状态的比例 关键动作后强制回读校验，把”外部状态”作为一等字段存下来

断点之外，还要三件事能被验收。第一，时效：任务提交后多久能给出结果，按业务分别给一个上限，超时要能说明卡在哪一段——是排队、是执行、还是在等人工确认。第二，可续：中断之后能否从断点继续，而不是从头再来；这一项我们在设计评审里只问一句”重跑会不会做两遍”，答不上来说明没做。第三，可解释：失败要给出人可读的原因，含失败发生在哪一步、外部系统当时的状态是什么、下一次该改什么。

三问合起来就是那句实测结论的工程翻译：身份是台账里的一行，可用性是上面挂着的四个断点有没有监控、三段管理有没有出口、三个验收项有没有数字。缺一样，”全天候”就只是没人值班时的另一种说法。

#智能体运维 #账号生命周期 #非人身份 #权限回收 #可用性