AI Team 成员分工协作

[jason-aelf]

背景

AI Team 的核心产品语义是“一组 AI Agent 成员分工协作”。Team 和 Member 都是 SaaS 层业务对象，不是运行时本身。

AI Team
  -> team_id、名称、描述、入口、发布版本

AI Team Member
  -> member_id、名称、角色、职责、调用条件、权限策略

Member Runtime Binding
  -> runtime_kind: Workflow | GAgent | Scripting | Service
  -> target_id / revision / endpoint / input contract / output contract

典型业务流程：

接待员 -> 处理员 -> 跟进员

其中：

• AI Team 是业务团队，不是运行时。
• AI Team Member 是业务成员，例如接待员、处理员、跟进员。
• Workflow、GAgent、Scripting、Service 都不是成员本身，而是成员绑定的运行时或调用入口。
• 外部调用 Team 时，当前应通过 Scope Service invoke API 进入 Team 的顶层入口，而不是直接调用 Scope Workflow catalog API。

当前代码底座已经具备一部分能力：

• Service definition、revision、deployment、default serving revision 等基础能力。
• Scope Service invoke API：
  • POST /api/scopes/{scopeId}/services/{serviceId}/invoke/{endpointId}
  • POST /api/scopes/{scopeId}/services/{serviceId}/invoke/{endpointId}:stream
• Service 背后可以绑定 Workflow、Scripting、Static/GAgent 三类实现。
• Studio Member 已有创建、查询和绑定能力。
• Member 可以绑定 Workflow / Script / GAgent。
• Member 可以解析到 Published Service。
• Scope Service 支持 member-first invoke：
  • 调用成员时先解析到成员的 Published Service
  • 再通过 Service invocation dispatcher 分发到 Workflow / Scripting / GAgent
• 这些 member-first invoke 能力属于单成员调用底座，不表示顶层 Workflow 已经支持编排 Member。
• Workflow 编排引擎已有顺序、分支、循环、并行等流程能力。
• Workflow runtime 已支持 workflow_call。
• LLM / chat 型 GAgent runtime 已支持 llm_call：
  • target_role 调用 workflow role agent
  • parameters.agent_type / parameters.agent_id 调用指定 GAgent actor
• Scope Workflow 支持动态保存和查询：
  • PUT /api/scopes/{scopeId}/workflows/{workflowId}
  • GET /api/scopes/{scopeId}/workflows
  • GET /api/scopes/{scopeId}/workflows/{workflowId}
• Scope Script 支持通过 API 动态保存：
  • PUT /api/scopes/{scopeId}/scripts/{scriptId}
• Script runtime 底层能力已存在，可以 provision runtime 并投递运行命令。

当前需要澄清的核心问题是：顶层 Team Workflow 到底编排什么。

方案一：
  编排 Service endpoint

方案二：
  编排 Workflow / GAgent / Scripting runtime

方案三：
  编排 AI Team Member / Agent
  再通过 Member Runtime Binding 解析到 runtime

这三种方案都可以让 Team 页面展示接待员、处理员、跟进员，但执行语义不同。差异不在“成员是否绑定 runtime”，而在“顶层协作图里连接的是 runtime，还是 Member”。

提议

方案一：编排 Service

这个方案把 Service 作为顶层编排目标：

顶层 Workflow
  -> 调用 receptionist Service
  -> 调用 handler Service
  -> 调用 follow-up Service

AI Team 页面仍然可以展示接待员、处理员、跟进员，但执行层主要连接的是 Service endpoint。

适合场景：

• Service-to-Service 编排。
• 统一 endpoint、统一发布、统一权限治理。
• 某些成员能力需要作为独立 Service 被多个 Team 复用。
• 平台能力 PoC。

主要缺口：

• Workflow 内部调用 Service endpoint 的一等能力，或者明确通过工具/HTTP invoke Service 的过渡方式。
• 如果编排步骤要等待业务结果，需要补结果观察机制；普通 invoke 当前主要返回 accepted receipt。
• 如果 Service 和 AI Team Member 需要在 UI 与审计上对应，需要补 member -> service 的稳定映射和运行记录。
• 如果要做受治理的 Service-to-Service allowlist，需要补可信 caller service key 注入，不能只依赖请求体或模型声明。

局限：

• 顶层执行语义更偏 Service 编排，而不是 AI Team Member 协作。
• 如果只记录 Service call，成员级职责、调用条件、成员版本和成员审计会比较弱。
• 成员运行时替换时，顶层 Workflow 可能需要跟着调整 Service 或 endpoint。

方案二：成员绑定 Workflow/GAgent/Scripting，使用 Workflow 编排运行时

这个方案让 AI Team Member 绑定具体 runtime，但顶层 Workflow 编排的是 Workflow / GAgent / Scripting runtime，不是 Member。

接待员成员 -> 绑定 GAgent
处理员成员 -> 绑定 Workflow
跟进员成员 -> 绑定 Scripting

顶层 Team Workflow
  -> llm_call agent_id / agent_type
  -> workflow_call workflow_id
  -> scripting runtime call

产品模型上仍然可以有 AI Team Member 和 Member Runtime Binding，但运行时执行图展开后连接的是具体 runtime。成员主要用于产品展示、配置归属、绑定校验和发布时生成/校验顶层 Workflow。

适合场景：

• 快速验证 AI Team 成员绑定 runtime 的产品体验。
• 复用现有 workflow_call、llm_call 和 runtime 调用能力。
• 希望 Script 通过 API 动态保存后，不重启服务即可被成员绑定并被 Team Workflow 调用。
• 可以接受顶层 Workflow 直接绑定具体 runtime 类型和 runtime id。

主要缺口：

• AI Team 聚合模型，用于表达 Team 与 Member 的归属关系。
• Team Draft / Team Revision，用于冻结成员、绑定和顶层 Workflow。
• 顶层 Team Workflow 的 runtime 调用校验，确保只能调用当前 Team 成员声明的绑定 runtime。
• 如果希望 Workflow 直接调用 Scripting，需要补 Scripting runtime 的 workflow 调用接入，或通过 Service dispatcher 间接调用。
• 如果要从运行记录反查到成员，需要在 Workflow step 与 Member Binding 之间保存稳定映射。
• Runtime Call 运行记录；Member Run 只能通过 step/member 映射间接还原，不是天然执行对象。
• 对非 chat 型 GAgent，如果 Workflow step 要等待业务结果，需要补结果观察机制。

定位：

方案二 = runtime 编排过渡方案

它可以用于快速跑通第一版体验，但不是完整的 AI Team 成员协作模型。

方案三：编排 Member（Agent）

这个方案把 AI Team Member / Agent 作为一等协作对象。当前落地范围仍然只做 Workflow mode，也就是顶层 Team Workflow 编排 Member；Manager、handoff、并行汇总、人工审批、共享任务空间等模式只作为后续长期扩展方向。

AI Team
  -> Member: 接待员
  -> Member: 处理员
  -> Member: 跟进员

当前实现范围：
  -> Workflow mode
  -> 顶层 Team Workflow 编排 Member
  -> 通过 Member Runtime Binding 调用 Workflow / GAgent / Scripting

长期扩展方向：
  -> Manager / Supervisor
  -> Agent-to-Agent handoff
  -> 并行协作 + 汇总
  -> 人工审批
  -> 共享任务空间

方案三和方案二的关键差异是编排对象：

方案二：
  顶层 Team Workflow 编排 Workflow / GAgent / Scripting runtime
  成员绑定用于配置、校验、展示和发布生成

方案三当前：
  顶层 Team Workflow 编排 Member / Agent
  运行时通过 Member Runtime Binding 解析到 Workflow / GAgent / Scripting

方案三长期：
  再扩展 Manager / Handoff / Parallel / Approval / Workspace 等多种 mode

因此，如果选择方案二，顶层 Workflow 可以直接写 workflow_id、agent_id 或 script_id。如果选择方案三，Workflow 图里的业务目标应是 member_id，运行时再通过成员绑定解析到具体 runtime。

适合场景：

• 第一版目标是正式 AI Team 成员分工协作。
• 希望成员从第一版开始进入执行链路和审计链路。
• 希望后续从 Workflow mode 演进到 Manager、handoff、并行、人工审批等多种协作模式。

主要缺口：

• AI Team 聚合模型。
• Team 与 Member 的归属关系。
• Team Draft / Team Revision。
• Workflow 内部成员调用能力。
• Member Binding Resolver。
• 顶层 Team Workflow 的成员调用约束。
• Team Run / Member Run / Runtime Call 三层运行事实和审计。
• Scripting runtime 在成员调用链中的输入、输出、完成事实和错误语义。

当前方案三不需要增加多种协作策略，只需要 Workflow mode。成员协作关系当前由顶层 Team Workflow 承载，不需要立即把 Team Collaboration Plan 抽成独立业务概念。

后续当需要 Manager / handoff / parallel / approval / workspace 等多种 mode 时，再把 Team Collaboration Plan 抽成独立业务概念。长期可扩展的协作模式包括：

• 固定顺序：接待员 -> 处理员 -> 跟进员。
• 条件路由：按问题类型选择不同成员。
• Manager / Supervisor：统一入口理解意图并分派成员。
• Agent-to-Agent handoff：成员在执行中转交给另一个成员。
• 并行协作 + 汇总：多个成员并行处理后交给汇总员。
• Human-in-the-loop：Agent 草拟、人工审批、Agent 执行。
• 共享任务空间：成员围绕同一个任务空间写入发现、草稿、决策和状态。

外部调用入口

Team 的默认对外入口不应直接暴露某个成员，也不应直接暴露 Scope Workflow catalog API。

当前建议做法：

顶层 AI Team 入口
  -> 绑定/发布为 Scope Service
  -> 外部通过 Scope Service invoke API 调用

推荐入口：

POST /api/scopes/{scopeId}/invoke/chat:stream

如果一个 scope 下有多个 Team / Workflow 入口，可以使用 service-level 入口：

POST /api/scopes/{scopeId}/services/{serviceId}/invoke/chat:stream

当前 Scope Workflow API 更偏 catalog/read/write 面：

PUT /api/scopes/{scopeId}/workflows/{workflowId}
GET /api/scopes/{scopeId}/workflows
GET /api/scopes/{scopeId}/workflows/{workflowId}

目前没有公开的直接运行接口，例如：

POST /api/scopes/{scopeId}/workflows/{workflowId}:run

如果未来希望绕过 Service 入口，按 workflowId 直接运行 saved workflow，需要新增公开的 scope workflow run API。

成员级 invoke 可以用于成员测试、调试、独立复用或内部调用，但不应作为 Team Run 的默认外部入口。

推荐选择

维度	方案一：编排 Service	方案二：编排 Workflow/GAgent/Scripting	方案三：编排 Member（Agent）
编排对象	Service endpoint	Workflow / GAgent / Scripting runtime	AI Team Member / Agent
成员地位	偏展示或映射	产品配置、展示、绑定和校验对象	执行和审计的一等协作对象
协作方式	Workflow / 工具调用 Service	顶层 Team Workflow 直接连接 runtime	当前是 Workflow 编排 Member；长期再扩展多种协作模式
主要缺口	Workflow 内部调用 Service endpoint、结果观察、Service-to-Service 治理	runtime 调用校验、step 到 member 的映射、Scripting 调用接入、结果观察	Workflow 内部成员调用、Member Binding Resolver、Team/Revision/Run 模型、成员级审计
推荐定位	PoC、Service 复用、平台治理场景	runtime 编排过渡方案	正式 AI Team 成员协作方案

建议：

• 如果只是验证平台能力或做 Service-to-Service 编排，采用方案一。
• 如果第一版只是快速验证运行时编排，采用方案二。
• 如果第一版目标是正式 AI Team 成员分工协作，采用方案三。
• 长期如果要支持更完整的 AI Agent 分工协作，在方案三基础上扩展 Manager / Handoff / Parallel / Approval / Workspace 等多种协作模式。