AI agent 平台只要真正进入企业环境，就一定会碰到一个绕不过去的问题：平台团队不可能继续亲手替每个客户开权限、改配置、暂停连接器、查看执行记录、恢复失败 run。客户会要求更多自助能力，支持团队会要求更快的处理权限，而平台工程又不敢把“平台管理员”那把万能钥匙随便发出去。这不是单纯的 RBAC 问题，而是组织协作已经开始把系统设计逼出来了。
很多团队在这里最常见的两种失误，方向刚好相反。第一种是完全不下放，所有动作都回到平台团队手里，结果客户成功、支持、工程排成长队，平台本来应该提供的自助能力被活生生做成工单系统。第二种是为了提效，一口气给出过宽的租户管理员权限，结果客户自己能动的东西太多，支持也能改的东西太多，出了问题之后谁改了什么、改动有没有越出边界，很快就没人说得清。
所以 delegated admin 真正要解决的，不是“客户能不能自己点按钮”，而是平台能不能把不同角色真正应该拥有的操作边界定义清楚。没有 scoped operations，下放权限最后只会变成把平台风险外包给更多人共同触发。
建议配合 AI agent 安全与权限边界、AI agent Plan Tier Entitlement 与 Tool Gating、AI agent Tenant Config Bundle 与 Override Governance 和 AI agent Run Ledger 审计模型 一起看。
先把“能看什么”“能改什么”“能批准什么”拆开，不要只说谁是不是管理员
| 角色 | 最合理的权限重心 | 最不该默认给它的能力 |
|---|---|---|
| 客户管理员 | 管自己租户下的成员、策略包启停、可见性设置 | 修改平台全局默认值、跨租户查看执行记录 |
| 支持 / CSM | 诊断、回放、有限的恢复动作 | 直接变更客户生产策略或绕过审批 |
| 平台工程 | 处理结构性故障、全局配置、紧急修复 | 长期保有无约束的租户内操作入口 |
| 审批者 / 合规负责人 | 批准高风险动作和例外 | 代替执行层直接操作系统 |
很多权限混乱，其实是因为团队只用“管理员”这一个词去装所有差异。可在 AI agent 平台里，查看 run、恢复失败任务、改 tenant override、发布新策略、批准高风险连接器动作，本来就是完全不同的权限维度。它们既不应该绑在同一个角色里，也不应该总是一起下放。
Delegated admin 不是复制平台管理员，而是把组织边界翻译成可执行操作
真正成熟的 delegated admin，不是给客户一套缩水版平台后台，而是先回答清楚三个组织问题：
- 哪些事情本来就应该由客户自己决定，例如成员管理、部门级配额、低风险自动化开关
- 哪些事情可以由支持代操作，但必须留下理由和审计轨迹，例如恢复某个 run、重触发某类同步
- 哪些事情无论再急，也不能绕开平台或合规审批，例如放开高风险工具权限、关闭关键风控规则
换句话说，delegated admin 的本质不是“界面更多”，而是平台终于把组织协作的责任边界做进系统。系统如果不这么做，最后就会靠 Slack 消息、临时截图和人工口头确认去承担这些边界，风险只会更大。
Scoped operations 的关键，不是界面上出现哪个按钮，而是每次动作都带着范围信封
真正安全的下放，不应该只有“这个角色能不能点这个动作”，还应该有明确的操作 envelope。一次恢复、一次配置修改、一次查看敏感执行记录，至少应该同时带着这些范围：
- 租户范围：只能作用于哪个 tenant、workspace 或 environment
- 能力范围：只能做查看、暂停、恢复，还是允许改配置、发起重跑、调整阈值
- 时间范围：这次授权是长期常驻，还是只在一个窗口内有效
- 证据范围：动作是否必须附带 ticket、事故编号、审批记录或操作原因
如果系统只有“有权”或“没权”，那权限迟早会越用越粗。因为现实里的很多管理动作，本来就是对场景敏感的。支持为了排障需要看一次记录，不代表它从今天开始就应该永久看全部记录；客户管理员需要调整自己部门的额度，不代表它可以顺手改掉租户里的所有风险阈值。
一个常见事故：支持只是想快点救火，最后却把全局默认值一起带偏了
某团队的 AI agent 平台为减少工单量，给支持团队开放了相当广的配置权限。最开始一切都很顺，因为支持终于不用每次都去找平台工程代改。问题出在一个高优客户的紧急恢复场景里。为了让这家客户尽快恢复，支持把某个 connector retry 阈值和 policy 例外开关直接调高了。结果系统用的是共享默认配置路径，这个改动不只作用在目标租户，而是影响了同类连接器的其他客户。
事故并不是因为支持不专业，而是系统没有给动作正确的范围信封。它把“帮一个客户临时放宽边界”做成了“修改平台默认值”。最后团队真正修复的，不是一次培训，而是把所有高影响操作都强制要求附带 scope：必须明确租户、环境、有效期和回滚时间；若 scope 为空，动作根本不能提交。
如果你现在只能先补一层，先把三种 scope 做成系统默认值
不少平台会先想着设计更漂亮的租户后台，或者把角色名起得更完整。那些都没错，但更值得先补的是最基础的三层 scope：tenant scope、capability scope 和 time scope。没有这三层，delegated admin 看起来像在做自助化，实际上是在扩散长期高权。
一个好用的 AI agent 平台，不是每个人都能做更多，而是每个人都能在正确边界里做该做的事。权限真正下放成功的标志，也不是后台按钮变多，而是平台终于不再需要靠“你先帮我改一下”这种隐形通道维持日常运转。
延伸阅读：
