统一数字身份演进路线（注册表模式）

0. 原则

UM 核心（用户身份 + OAuth + SSO + 开放接口）已能跑，不推倒。向「统一数字身份系统」演进的三块增量能力，一律采用声明式注册表 + 按注册表路由模式：

UM 持有数据与路由，各应用持有能力执行；UM 不做各应用逻辑的单体实现。

---

1. 现状基线

• ✅ 用户身份、UMID 联邦、OAuth 2.1、RBAC、多租户 SaaS
• ✅ 开放接口（appid / OAuth 2.1 / UMOpenClient·UMOpenLogin·UMOpenQr SDK）
• ⚠️ um_apps 偏「OAuth 客户端」，未作为「身份主体」统一建模
• ⚠️ 跨应用能力调用靠硬编码（如 IF_MF_SECRET），无注册表
• ⚠️ UM 仅签发 token，不做跨应用调用路由

---

2. 缺口与分阶段规格

阶段一：应用 / 智能体作为一等身份主体

• 将 um_apps 抽象为「身份主体」的一种类型（与用户同级的 principal），统一建模。
• 新增主体类型枚举：person / application / agent / device / service。
• 风险：低（演进式加表 / 字段），不破坏现有 OAuth 流程。

阶段二：能力注册表

• 新增 um_capabilities（能力目录）：各应用声明 provides / consumes。
• 注册表为纯数据，UM 只读不实现。
• 风险：中（需定义注册协议与校验）。

阶段三：按注册表路由的 broker

• UM 新增轻量 broker：接收跨应用能力调用请求，按注册表路由到提供方（如 MF 模型能力、IF 体验能力），不持有各方逻辑。
• 取代 IF_MF_SECRET 等硬编码，统一为注册表驱动的授权 + 路由。
• 风险：中（需限流 / 熔断 / 审计，防止中心化 SPOF）。

---

3. 护栏

• 所有改动遵守服务器纪律（低峰、备份、零停机、内存保护）。
• 不把各应用业务逻辑写入 UM；UM 始终保持「身份 + 注册表 + 路由」的轻实现。
• 每阶段独立可验证，不一次性动全局。