## 新员工账号与权限开通申请编排 {.case data-case-id="067"} | 字段 | 值 | | --- | --- | | 案例编号 | `067` | | 行业 / 部门 | 金融 / 企业 IT | | 角色 | IT 服务台负责人 | | 难度 | `复杂` | | 调用来源 | `manual`（入职单确认后由 HR 发起一次手动调用，带入岗位与权限需求单） | 新员工周一入职，账号周三才开好，权限申请在聊天记录里漂了两个星期——更糟的是照抄同岗位老人的权限，多开一堆用不上的系统。目标：入职单确认后由 HR 发起一次手动调用，App/Extension 在源头把需求单抽取为岗位标识与权限项代号（不含姓名、证件号等个人数据），按岗位模板生成账号命名方案、邮箱方案与权限开通清单——方案以代号呈现，实际账号与邮箱由 IT 在身份管理系统按方案代号生成；权限按最小必要原则分两道串行审批，每道都是整单二值（确认或驳回）——第一道对模板内权限整批确认，第二道把模板外权限逐项列出（附理由），仍作整单确认或驳回，审批人在驳回理由中指明有问题的项，任一道驳回则整单按驳回处理；两道都通过后生成工单，由获授权 Agent 按“onboard_ref + 平台签发 approval_version + 期望变化 create_onboarding_ticket + 目标 ITSM”的完整业务键登记并通知 IT 在身份管理系统执行，执行由人完成、每步留审计时间戳，工作流不直接创建账号。指标：审批通过的开通单 100% 有模板外权限的理由说明；从审批通过到工单通知 IT 的中位数 ≤ 2 小时；ITSM 重复建单的 0 例；工作流直接创建账号或改权限的 0 例。 - **覆盖**：手动发起、App/Extension 在源头把需求单白名单化为岗位标识与权限项代号（含入职单号令牌）、按岗位模板生成账号命名方案与邮箱方案代号及权限开通清单、模板内整批与模板外整批两道串行整单二值审批、审批通过后生成工单并按“onboard_ref + 平台签发 approval_version + 期望变化 create_onboarding_ticket + 目标 ITSM”业务键登记并通知 IT 执行、驳回退回 HR、需求单不完整告警。 - **不覆盖**：自动创建账号、自动开通权限、自动配置邮箱、自动写回身份管理系统、自动判断岗位职责合理性。 - **假设**：岗位与权限需求单由 App/Extension 在调用源头抽取为岗位标识与权限项代号，连同入职单号（令牌化：权限受控且 Agent 无法反查原值）作为调用输入，Agent 只收到代号化的岗位与权限项，不接收姓名、证件号等个人数据；岗位权限模板作为调用输入提供；任一模板外权限都必须附非空理由，缺失理由整单进入不完整分支且不构造审批载荷；有一个经授权能把工单登记到 ITSM 的 Agent（通过 App/Extension）。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：入职单确认后由 HR 发起一次手动调用，App/Extension 先在源头把岗位与权限需求单抽取为白名单字段——岗位标识、权限项代号与入职单号（令牌化），姓名、证件号等个人数据在源头即被令牌化，Agent 只收到代号化的岗位、权限项与入职单号令牌。按岗位权限模板生成账号命名方案、邮箱方案与权限开通清单（方案以代号呈现：实际账号与邮箱由 IT 在身份管理系统按方案代号生成，工作流与 Agent 全程不见真实账号、邮箱与任何凭据），交 IT 负责人分两道串行审批。权限按最小必要原则：模板内权限逐项列出后第一道整单确认；模板外权限逐项单独成块且每项必须附非空理由，任一理由缺失或空白时整单进入需求不完整分支，禁止生成 account_plan 或任何审批载荷；理由齐全后第二道仍作整单确认或驳回，审批人在驳回理由中指明有问题的项，任一道驳回则整单按驳回处理重新发起。账号与权限最小披露：全程只用账号命名方案代号、邮箱方案代号与权限范围，口令与密钥绝不出现。 触发：手动发起一次调用，调用时带入源头抽取的岗位标识与权限项代号、入职单号（令牌化）、岗位权限模板、IT 服务台频道、审批人（IT 负责人）、恢复 Owner 令牌与值班频道（值班频道作为调用输入提供，用于失败升级）。 生成开通清单环节（审批前）回传 JSON：{onboard_ref: 入职单号令牌, role_code: 岗位标识, perms_in_template: [权限项代号], perms_out_template: [{perm_code: 权限项代号, reason: 非空字符串|缺失}], account_plan: {account_name_scheme: 账号命名方案代号, mailbox_scheme: 邮箱方案代号}, fields_missing: [枚举(岗位标识|权限项|模板外权限理由)], audit_ts: 时间戳}。状态矩阵：onboard_ref、perms_in_template、perms_out_template、fields_missing、audit_ts 始终必填，权限数组每个元素的 perm_code 必填；fields_missing 非空时禁止 account_plan 且禁止构造任何 Approval 请求，其中任一 perms_out_template.reason 缺失或空白时 fields_missing 必须含模板外权限理由；fields_missing 为空时 role_code 与 account_plan 两项方案代号必填、权限项非空时两个权限数组至少一个非空，且每个模板外权限的 reason 必须为非空字符串。此环节发生在审批前，schema 不含任何审批后才产生的产物；缺任一应必填项或违反状态禁止条件视为回传不合结构。 仅接受上述状态矩阵中的组合，其余 callback 一律拒绝并保持原等待点。两道审批都通过后，平台签发 approval_version；ITSM 登记环节（另一个 Agent）独立回传 JSON：{onboard_ref: 入职单号令牌, approval_version: 平台签发令牌（原样回传，不由 Agent 生成）, ticket_ref: ITSM 工单令牌, idempotent_result: 枚举(新建|已存在——按业务键查得), audit_ts: 时间戳}；业务键固定为 onboard_ref+approval_version+期望变更 create_onboarding_ticket+目标 ITSM，ticket_ref 与 idempotent_result 在登记成功后必填，登记响应未知时先按同一键查单：查得已存在则回传已存在并复用原 ticket_ref，不得重复建单；缺任一必填视为回传不合结构。 结果分三类处理（先判需求单完整性，再进审批）： 需求单不完整（缺岗位标识、权限项无法对齐模板，或任一模板外权限的 reason 缺失 / 空白）：告警留审计时间戳，通知调用方补全后新开一次调用，本流程不重试、不拿不完整需求单继续跑。 审批驳回：退回 HR 重新确认需求，本次失败结束并留审计时间戳；要再申请就补全理由后新开一次调用，不重试、不由 AI 改判。 审批通过：生成开通工单，由获授权 Agent 经 App/Extension 登记到 ITSM 并通知 IT 执行——执行在身份管理系统由人完成，每步留审计时间戳，工作流不直接创建账号、不直接开通任何权限；工单只含账号命名方案代号、邮箱方案代号（由 IT 在身份管理系统按方案代号实际生成账号与邮箱，口令与密钥由身份管理系统产出并经其自身渠道交付，工作流与 Agent 全程不见任何凭据）与权限范围，并以 ITSM 工单令牌作为受控的身份映射——工单令牌在平台侧关联入职单号令牌与账号命名方案代号，Agent 无法反查。 审批：分两道串行、每道都是整单二值（确认或驳回，不设自动超时，无默认通过/否决，任一道驳回则整单按驳回处理）：第一道对模板内权限整批确认；第二道只接收理由全部非空的模板外权限并逐项展示，仍作整单确认或驳回——审批人在驳回理由中指明有问题的项，没有逐项打勾的中间态；任何模板外项缺理由时不创建 Approval，两项都通过才进入工单。 异常：Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；ITSM 登记走固定业务键 onboard_ref+approval_version+create_onboarding_ticket+目标 ITSM，重复调用不重复建单；登记响应未知时先按同一键查单再决定是否重写，避免"对方已建单但本地超时"造成重复。取消只停止后续 Workflow 图，不召回工单或通知、不自动补偿；保留 receipt，由恢复 Owner 按业务键查 ITSM 权威状态后决定保留、另建补偿行动卡或升级。有限重试仍失败则升级到值班频道并留待处理记录，登记与升级动作留审计；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：工单通知、驳回退回、需求单不完整告警各自留审计时间戳后结束。 ``` ![案例 067 新员工账号与权限开通申请编排：HR 手动发起一次调用，App/Extension 在源头把需求单抽取为岗位标识、权限项代号与入职单号令牌（个人数据在源头令牌化），按最小必要原则生成账号/邮箱/权限开通清单；需求单不完整（含任一模板外权限缺非空 reason）时禁止 account_plan 与 Approval 请求，告警留审计并通知调用方补全后新开调用不重试；IT 负责人分两道串行整单二值审批——模板内权限整批一道、模板外权限逐项列出附理由再一道（任一道驳回则整单按驳回处理，审批人在驳回理由中指明有问题的项），两道都通过后生成工单，经获授权 Agent 按“onboard_ref + 平台签发 approval_version + 期望变化 create_onboarding_ticket + 目标 ITSM”业务键登记（响应未知先查后写）通知 IT 在身份管理系统执行（由人完成、每步留审计，工作流不直接创建账号），驳回退回 HR 重新确认需求重开调用不重试，均留审计时间戳；回传不合结构停在原等待点](../../../media/cases/fig-case-067-01-flow.svg){#fig-case-067-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见： 1. **手动触发**：入职单确认后，HR 发起一次手动调用，App/Extension 在源头把需求单抽取为岗位标识、权限项代号与入职单号（令牌化），连同岗位权限模板、IT 服务台频道与审批人（IT 负责人）带入。 2. **生成开通清单**：按岗位模板生成账号命名方案、邮箱方案（以代号呈现）与权限开通清单，模板内逐项列出，模板外单独标出且每项理由必须非空；任一理由缺失或空白即进入不完整分支，禁止 account_plan 与 Approval 请求。其他回传缺项或状态矛盾同样被拒绝，原 Effect 保持等待。 3. **分流（先判完整性，再进审批）**： - **需求单不完整**：缺岗位标识、权限项无法对齐模板，或任一模板外权限 reason 缺失 / 空白时，禁止 account_plan 与 Approval 请求，告警留审计时间戳，通知调用方补全后新开一次调用；本流程不重试，不拿不完整需求单继续跑。 - **审批驳回**：退回 HR 重新确认需求，本次失败结束并留审计；要再申请就补全理由后新开一次调用，不由 AI 改判。 - **审批通过（两道都通过）**：生成开通工单，由获授权 Agent 经 App/Extension 登记到 ITSM 并通知 IT 执行——工单登记使用“onboard_ref + 平台签发 approval_version + 期望变化 create_onboarding_ticket + 目标 ITSM”的完整业务键，重复调用不重复建单，响应未知时先按同一键查单再决定是否重写；执行在身份管理系统由人完成，每步留审计时间戳；工单只含账号命名方案代号、邮箱方案代号（实际账号与邮箱由 IT 在身份管理系统生成，工作流与 Agent 不见真实值与凭据）与权限范围，并以 ITSM 工单令牌作为受控的身份映射（在平台侧关联入职单号令牌与方案代号，Agent 无法反查），口令与密钥绝不出现。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"手动生成清单 + 审批 + 工单编排"流程——它知道"生成开通清单"需要一个处理环节、"IT 负责人审批"需要一个审批环节、"登记 ITSM 工单"需要一个发消息并等待回调的 Agent 环节、"通知与告警"各需要一个发消息环节。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **模板外权限没有理由就开通**：这是最危险的失败方式——多余权限从此挂在账号上。任一模板外项缺少非空 reason 时，整单进入需求不完整分支，禁止 account_plan 和任何 Approval 请求；只有理由全部非空，第二道审批才逐项展示模板外权限并作整单确认或驳回。 - **工作流直接改账号**：工作流只编排申请、审批与工单通知，创建账号与开通权限由 IT 在身份管理系统人工完成、每步留审计；直接改账号或权限的 0 例。 - **ITSM 重复建单**：登记使用 onboard_ref+平台签发 approval_version+期望变更 create_onboarding_ticket+目标 ITSM 的完整业务键；响应未知（如"对方已建单但本地超时"）时先按同一键查单再决定是否重写，不盲目重发；有限次重试仍失败则升级到值班频道并留待处理记录。 - **取消后工单仍存在**：取消只停止后续 Workflow 图，不召回工单或通知、不自动补偿；保留 receipt，恢复 Owner 按完整业务键读取 ITSM 权威状态，再决定保留、另建补偿行动卡或升级。 - **拿不完整需求单继续跑**：需求单不完整就告警留审计并通知调用方补全后新开调用，不重试、不降级继续。 - **审批驳回后想再申请**：本次失败结束并留审计；补全理由后由 HR 新开一次调用，没有"AI 自动改判"。 - **通知发送失败**：按重试上限重试投递；超过上限则升级到值班频道（作为调用输入提供），并保留待发内容供人工补发。 - **Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限（如入职日前一天必须批完），由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知 IT 负责人。 开通清单必须经 IT 负责人审批，这是权限开通的生产变更关口，分两道串行、每道都是整单二值（确认或驳回，不设自动超时，无默认通过/否决，任一道驳回则整单按驳回处理）。第一道：模板内权限按最小必要逐项列出，一次整批确认或驳回。第二道：只接收 reason 全部非空的模板外权限并逐项单独展示，仍作整单确认或驳回——任一理由缺失时整单仍在不完整分支，Approval 根本不创建；审批人在驳回理由中指明有问题的项，没有逐项打勾的中间态，也不存在"模板外项混在模板内一并同意"。驳回则退回 HR 重新确认需求；两道都通过后平台才签发 approval_version 并生成工单。 本工作流对 ITSM 的工单登记由获授权 Agent 通过 App/Extension 完成，工作流本身不直接调用外部系统，更不直接对接身份管理系统执行任何变更——账号创建、权限开通、邮箱配置一律由 IT 在身份管理系统人工完成，每步在业务系统侧留审计时间戳，工作流负责编排确认与通知。岗位与权限需求单由 App/Extension 在调用源头抽取为岗位标识与权限项代号，连同入职单号（令牌化）、岗位权限模板、IT 服务台频道与恢复 Owner 作为调用输入提供；进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段。ITSM 的访问凭据用 `` 占位；工单登记使用 onboard_ref+平台签发 approval_version+create_onboarding_ticket+目标 ITSM 的完整业务键，响应未知和取消后均保留 receipt 并按同一键查询权威状态，由恢复 Owner 决定保留、补偿或升级。账号名与权限范围最小披露：工单与通知只含账号命名方案代号、邮箱方案代号与权限范围，口令与密钥绝不出现。 - **回放集与基准**：取最近 20 个历史入职单（含全模板内、有模板外权限、需求单不完整样本）回放，基准为按最小必要原则应生成的开通清单与应有理由说明的模板外项；每次回放记录生成、审批、工单时间戳。 - **最小必要防线**：审批通过的开通单 100% 有模板外权限的非空理由；任一理由缺失或空白的样本 100% 进入不完整分支，account_plan 与 Approval 请求出现 0 次；与基准一致率 ≥ 95%。 - **执行边界**：工作流直接创建账号或改权限的 0 例；IT 在身份管理系统的执行记录 100% 可按工单号对上审计时间戳。 - **源头脱敏**：进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（岗位标识、权限项代号与入职单号令牌，原值不进入以上任何一层），按 10% 抽查四层实际记录，出现姓名或证件号等个人数据的 0 例。 - **幂等防线**：同一 onboard_ref+approval_version+create_onboarding_ticket+目标 ITSM 业务键重复发起 5 次，ITSM 重复建单的 0 例，工单号一一对应。 - **取消后恢复**：取消只停止后续图；工单召回或自动补偿 0 次，receipt 保留率 100%，恢复 Owner 100% 按完整业务键核验权威状态并记录保留、补偿或升级决定。 - **指标**：从审批通过到工单通知 IT 的中位数 ≤ 2 小时；需求单不完整样本 100% 在生成清单前被拦下。 - **最小披露**：每周抽查 5 条工单与通知，只含账号命名方案代号、邮箱方案代号与权限范围，出现真实账号、邮箱、口令或密钥的 0 例；工单令牌身份映射在平台侧可对上入职单号令牌与方案代号。 - **结果可见**：工单通知、驳回退回、需求单不完整告警三类结果 100% 各有可见回执，不出现静默成功。 - **回退说明**：权限开通属生产变更，执行侧回退按身份管理系统既有流程办理并在工单留档，工作流归档附工单号便于追溯。 ### 复用与变体 - **同构迁移**：外包人员临时账号申请、跨部门调岗权限调整申请、第三方系统接入授权申请。 - **双审加固**：涉资金或涉客户数据的模板外权限必须数据 Owner 加签，在提示词里写明，AI 会再串一个整单二值审批环节。 - **离职对账**：与"离职与转岗资产归还提醒"同思路，再加一条定时对账的 Workflow 扫"账号已开但人已异动"的悬挂权限。