[RFC] Scope 与 AI Team 边界 —— 新增 AI Team 支持 scope 多团队

[jason-aelf]

背景

当前后端里的 scopeId 已经是资源隔离边界，但还不是产品意义上的 AI Team。

现有实现大致是：

一个登录账号 / 认证会话
  -> 解析出一个当前 scopeId
  -> 所有 scope API 都围绕这个 scopeId 读写资源

一个用户现在实际上只有一个 scopeId，原因很简单：后端是从当前认证信息里解析“当前 scope”，并且访问 scope API 时要求这个 scope 必须等于路由里的 {scopeId}。也就是说，认证上下文里没有“这个用户可访问多个 scope”的列表；同时后端也没有独立的 AI Team catalog，用来表达一个 scope 下可以创建、列举和管理多个 AI Team。

核心问题是：后端现在只支持“当前用户访问一个当前 scope 下的资源”，不支持“在同一个 scope 下创建和管理多个 AI Team”，也不支持为 AI Team 显式维护 Agent 组成关系。

具体来说：

• scopeId 目前只是 workflow、service、binding、run 等资源的命名空间。
• 认证与访问控制当前按“用户当前 scope == 路由里的 scope”判断。
• 后端没有独立的 AI Team catalog，也没有 AI Team 内部的 Agent 关系。
• 因此当前所谓 Team 最多只是当前 scopeId 下的一个展示视图，不是一个可创建、可列举、可管理的 AI Team 产品资源。

如果直接把 scopeId 改名成 teamId，会把两个语义混在一起：

概念	当前语义	应承担的职责
scopeId	runtime / resource namespace	service、workflow、binding、run、projection 等资源隔离边界
teamId	当前不存在	AI Team 的产品资源 ID，表示一组可协作的 Agent 编排单元
Agent	当前不存在独立关系模型	AI Team 内有哪些 Agent，以及它们在 Team 中的角色、能力和协作关系

所以，“一个 scope 下多个 AI Team”不是前端页面问题，也不是字段改名问题，而是后端缺少 AI Team catalog 与 AI Team Agent 事实源。

提议

结论是：scopeId 继续作为 runtime/resource namespace，teamId 作为 AI Team 业务资源 ID，Agent 作为 AI Team 内部的编排成员显式建模。三者不能通过字段改名混在一起。

建议按下面的边界整理：

1. 保留 scopeId 的现有职责

scopeId 继续表示资源命名空间，用来隔离 workflow、service、binding、run、projection 等后端资源。现有 /api/scopes/{scopeId} 形态不需要因为 AI Team 而整体改名。

2. 新增 AI Team

AI Team 应该是 scope 下的独立产品资源。一个 scopeId 下可以有多个 AI Team；每个 AI Team 有自己的 teamId、展示名称、状态和生命周期。

AI Team 不应该从 scopeId 字符串临时推导，也不应该把 Team 名称、展示信息或 Agent 关系塞进 scope 级配置。

3. AI Team 只组织和编排 scope 下已有能力

现有 workflow、service、binding、run 等能力仍然在 scope 下执行。AI Team 不替代 scope API，而是在当前 scope 内组织一组 Agent，并把这些 Agent 关联到对应的 service、workflow 或能力配置。

用户进入某个 AI Team 时，后端应该先确认这个 Team 属于当前 scopeId，再读取该 Team 的 Agent 组成关系，然后基于现有 scope 能力继续执行。