[RFC] Member 与 Service 边界 —— 新增 Agent 作为 AI Team 产品身份，Service 作为发布运行面

[jason-aelf]

背景

本文只基于当前后端代码整理 Member 与 Service 映射 的讨论内容。标题继续使用 Member 是为了对应原始讨论问题；但本文中的 Member 实际语义不是人类团队成员、权限成员、seat、邀请对象或 billing 计费对象，而是 AI Team 内可配置、可发布、可运行的成员 Agent。

Member 描述不准确，因为在 SaaS 产品和后端权限模型语境中，它通常首先表示人类团队成员、组织成员或权限成员。后端一旦把 Member 作为长期 API / 领域对象命名，ListMembers、AddMember、RemoveMember 这类接口很容易被理解为管理人类成员，而不是管理 AI Team 内的 AI 个体。因此长期命名应收敛为 Agent：human member / org member 继续表示人和权限，Agent 表示 AI Team 内的业务执行单元。

定义 Agent 的目标，是给 AI Team 内每个可协作的 AI 个体一个稳定的产品身份和团队内编排位置。它承载展示名称、角色、能力说明、排序、协作关系、实现引用和发布服务引用；它不是 Service 本身，也不是 runtime actor 地址。Service 的目标是承载该 Agent 对外发布和运行的服务面，包括 revision、deployment、serving、endpoint、policy、binding、run、audit 和 invoke。

当前后端已经有一套比较完整的 Service Runtime / Governance 主链路：

ServiceIdentity
  -> tenantId / appId / namespace / serviceId
  -> ServiceDefinition
  -> ServiceRevision
  -> Deployment / Serving / Governance / Invocation
  -> runs / audit / bindings / policies

其中 ServiceIdentity 在 service_endpoint.proto 中由 tenant_id、app_id、namespace、service_id 组成，ServiceKeys.Build(...) 会把这四段拼成稳定 service key。scope 级 API 再通过 BuildScopeServiceIdentity(...) 把 scopeId 映射到 TenantId，并使用配置里的 ServiceAppId、ServiceNamespace 和路由里的 serviceId 构造 Service Identity。

也就是说，后端现在能稳定表达的是：

• 某个 scope 下有哪些 service。
• 某个 service 有哪些 revision、deployment、serving target、endpoint、policy、binding。
• 某个 service 可以通过 scopeId + serviceId + endpointId 被 invoke。
• 某个 service run 可以按 scopeId + serviceId + runId 查询 summary、audit、resume、signal、stop。

但是，当前后端没有 AI Team 成员 Agent 这类 SaaS 层资源模型，也没有稳定的 agentId。仓库中存在 TeamManagerGAgent 和 TeamMember，但它们属于 Foundation multi-agent runtime：成员身份是 agent_id、agent_name、agent_type、status，用于运行时 agent 注册、状态更新和广播，并不是 Studio / SaaS 层的 AI Team 成员 Agent catalog，也没有绑定到 Service catalog 的 memberId -> publishedServiceId 或 agentId -> publishedServiceId 关系。

所以，当前代码能复用 Service Runtime，但不能推出 AI Team 成员 Agent = Service。serviceId 是发布合同面的稳定标识，用于服务定义、修订、部署、治理、运行记录和 invoke；actorId 是某个 revision / deployment 激活后的运行时实体地址。二者都不是 SaaS 层 AI Team 成员 Agent 身份。如果直接把 Service 当成 AI Team 成员 Agent，会把三层语义混在一起：

概念	当前后端语义	不应承担的职责
agentId	当前不存在	不应由 serviceId 或 actorId 临时代替
serviceId	Service 发布契约标识	不应表达 AI Team 成员 Agent 身份、展示生命周期、在 Team 内的角色
actorId	runtime entity address	不应作为 AI Team 成员 Agent ID，也不应暴露成产品身份
agent_id	Foundation multi-agent runtime 成员标识	不等同于 Studio / SaaS AI Team 成员 Agent catalog

当前代码中的 scope binding 能把 workflow、script、GAgent 三类实现发布成 service：

ScopeBindingUpsertRequest
  -> implementationKind: workflow | scripting | gagent
  -> ServiceDefinitionSpec
  -> ServiceRevisionSpec
  -> ActivateServiceRevision
  -> ScopeBindingUpsertResult(serviceId, revisionId, expectedActorId)

这说明 workflow / script / GAgent 都可以通过 Service 发布、治理和运行。但这仍然只是“实现被发布成 Service”，不是“Service 就是 AI Team 成员 Agent”。如果把这条链路直接命名为成员 Agent，会让后续成员角色、成员配置、成员关系、成员排序、成员启停、成员在 AI Team 内的协作语义都被迫塞进 Service definition / revision / governance，污染 Service 的发布契约边界。

提议

更合理的口径是：AI Team 成员 Agent 是 Studio / SaaS 层的一等对象，Service 是该成员 Agent 对外发布和运行的稳定服务面。

短期后端没有 AI Team 成员 Agent catalog 时，可以从 scope 下已有 Service catalog 派生一个 agent-like 兼容视图。例如：

scopeId
  -> ListServicesAsync(scopeId as tenantId, configured appId, configured namespace)
  -> ServiceCatalogSnapshot[]
  -> agent-like view

这个兼容视图可以复用 ServiceCatalogSnapshot.DisplayName、ServiceId、ActiveServingRevisionId、DeploymentId、PrimaryActorId、Endpoints、PolicyIds 等字段展示“这个 scope 下可运行的 AI 个体”。它的价值是低成本复用现有后端能力：runs、audit、bindings、revisions、invoke、governance 都已经围绕 scopeId + serviceId 成熟工作。

但这个视图必须被明确标记为过渡层：它没有独立 agentId，没有 AI Team 内成员 Agent 语义，也会把 runtime 地址误当产品身份。serviceId、actorId 或 Foundation runtime 的 agent_id 都不能定义成 SaaS 层 AI Team 成员 Agent ID。

因此，长期模型应当是 agent-first，而不是 service-first：

AI Team
  -> teamId
  -> Agents
      -> agentId
      -> displayName
      -> role / capability / ordering / collaboration settings
      -> implementationKind: workflow | script | gagent
      -> implementationRef
      -> publishedServiceId
          -> Service
              -> revisions
              -> deployment / serving
              -> endpoints
              -> policies / bindings
              -> runs / audit / invoke

在这个模型里，AI Team 成员 Agent 负责产品身份和团队内语义；Service 负责发布契约、调用治理和运行时能力。成员 Agent 可以拥有一个 publishedServiceId，但 publishedServiceId 只是成员 Agent 的发布面引用，不是成员 Agent 本身。

长期应新增 AI Team 成员 Agent 后端对象，由后端生成稳定 agentId。模型需要显式维护：

• agentId -> implementationKind / implementationRef
• agentId -> publishedServiceId
• teamId -> agents
• 成员 Agent 在 AI Team 内的角色、协作关系和展示语义

Service 继续保持发布契约边界：负责 revisions、deployment、serving、endpoints、policies、bindings、runs、audit、invoke。AI Team 成员 Agent 作为产品层对象引用 Service，而不是被 Service 替代。