Console Web AI Teams 需求与现有代码 Gap

[jason-aelf]

背景

Console Web 的目标是 AI Team Workbench，不是后端对象浏览器。
本讨论用于对齐 AI Teams 产品需求与当前 aevatar 代码能力之间的 Gap，并决定哪些进入 P0 实现、哪些保留为后续阶段。

关联本地文档：

• docs/designs/2026-05-14-console-web-ai-teams-implementation-alignment.md
• docs/designs/2026-05-13-saas-ai-team-member-creation-and-collaboration.md
• docs/discussions/2026-05-11-frontend-architecture-discussion.md
• docs/canon/frontend-design.md

对齐基准

1. 本文讨论的是 Console Web AI Teams 产品需求与当前 C# 代码能力之间的落差，不重新定义底层架构。
2. 与 Scope、StudioTeam、StudioMember、Service Governance、Workflow、ServiceInvoke、Connector Binding、Event Topology 相关的口径，以现有实现语义为约束。
3. 产品可以展示“我的 AI 团队”，但实现侧必须区分认证工作区、团队资源、成员资源、服务发布、运行时执行和观察投影。
4. P0 应优先形成真实可用闭环，不用前端假数据伪装尚不存在的 EventEnvelope 级能力。

核心结论

1. Scope 不是 Team；Scope 是认证工作区 / 租户边界。
2. Team 应由 StudioTeam 表达；一个 Scope 下可以有多个 StudioTeam。
3. StudioMember 是 Team 内的成员 / workflow / script / GAgent / service 承载，是用户可理解的团队成员 / 能力单元，但不直接等同 runtime actor。
4. “Team Member = Governance Service = 底层 workflow / scripting / GAgent”应理解为成员发布、服务发现、治理和运行时绑定关系，不应理解为同步执行结果关系。
5. 成员协作优先通过 Workflow 编排 Service / Member；AgentTool ServiceInvoke 可作为现有调用能力。
6. Connector Binding 在产品上应区分“配置 / 治理 / 展示事实”和“运行时 connector client”。
7. Event topology 的 P0 口径应先落为 Workflow run audit / actor graph，不声称已经具备完整 EventEnvelope 级观察。

当前实现约束

1. Service invoke 返回 accepted receipt，不代表目标成员执行完成，也不包含业务输出。
2. Workflow 调用其他 Service 时必须显式构造 typed payload；StepCompletedEvent.Output 不会自动跨 Service 变成 ServiceInvocationRequest.Payload。
3. 当前 AgentTool ServiceInvoke 的核心路径是 list_services + invoke_service；目标 Agent 必须先作为 Service 暴露，调用默认还会经过 approval。
4. 当前 AgentTool ServiceInvoke 和 scope invoke 入口都没有可信 Caller.ServiceKey；如果目标 Service 使用 InvokeAllowedCallerServiceKeys 做 allowlist 保护，当前 invoke_service 不能安全通过该门禁。
5. Connector Binding 当前能记录、查询、展示 connector ref，但还没有 binding_id / connector_type / connector_id -> runtime connector client 的桥接。
6. EventEnvelope 级观察目前缺少 TopologyAudience、流转方向、publisher、target、route type、envelope id 和对应 observation / projection readmodel。

Team 模型对齐

Scope = Team 和多团队需求不一致。当前后端里的 scopeId 更接近认证后的用户工作区 / 租户隔离键，而不是用户可自由创建的 Team 资源；认证开启时，请求路径里的 scopeId 会被校验为必须等于登录身份里的 scope_id，所以一个用户通常只能访问自己的当前 scope，不能把“创建多个团队”理解成“创建多个 scope”。

dev 分支已有 StudioTeam 和 StudioMember 后，产品语义更自然地变成：

Scope        = 当前认证工作区 / 租户边界
StudioTeam   = 当前 Scope 内用户创建的 AI Team
StudioMember = Team 内的成员 / workflow / script / GAgent / service 承载

因此多团队能力应基于 StudioTeam 实现，而不是继续沿用旧文档里的 Scope = Team 映射。统一口径应为：Scope 不是 Team，Scope 是认证后的工作区 / 租户隔离边界；Team 是 Scope 内的业务资源，由 StudioTeam 表达；一个 Scope 下可以有多个 StudioTeam，每个 StudioTeam 管理自己的 StudioMember。

对产品层来说仍然展示“我的 AI 团队”，但实现上应理解为“当前工作区下的 StudioTeam 列表”。进入团队详情时使用 teamId 表示用户选择的团队，scopeId 只作为当前认证上下文和访问边界。

Member / Service / Workflow 对齐

需求中“一个 Team Member（SaaS 层）= Governance 下的一个 Service（Platform 层）= 底层的 workflow / scripting / GAgent”应理解为成员发布、服务发现、治理和运行时绑定关系，不应理解为同步执行结果关系。Aevatar 当前最快实现 Agent 协作的方式是 Workflow 编排 Service 协作，但这条路径需要正视两个语义限制。

第一，调用 Service 返回的是 receipt，不是执行结果。IServiceInvocationPort.InvokeAsync(...) 返回的 ServiceInvocationAcceptedReceipt 只表示调用已被接受、已解析到目标 Service / endpoint，并进入投递或启动流程；它不代表目标 workflow / script / GAgent 已完成处理，也不包含业务输出。因此 workflow 不能把 Service invoke 当同步函数调用。如果本轮要求“调用成员后拿到目标结果并继续当前 workflow”，需要新增异步 continuation 方案：当前 workflow step 先持久化 pending invocation，再等待正式 result / failure event 或事件化 timeout signal，由 workflow actor 对账后恢复当前 step。

第二，跨 Service 时必须显式构造 payload。StepCompletedEvent.Output 只在当前 workflow run actor 内部被 workflow kernel 写入 variables，并作为下一步本地 step 的 input；它不会自动变成另一个 Service 的 ServiceInvocationRequest.Payload。调用其他 Service 时，必须从当前 workflow state / variables 显式映射出目标 endpoint 需要的 typed payload，再放进 ServiceInvocationRequest.Payload，不能依赖 StepCompletedEvent.Output 自动跨 Service 传递。

因此 P0 如果要做“成员协作”，应把它定位成“workflow 里显式调用已发布 Service，并通过事件 / read model / audit 观察结果”，而不是“成员函数同步返回另一个成员的最终输出”。如果不补齐 pending continuation / result event / timeout 对账机制，P0 只能承诺 accepted / running / audit 可见，不能承诺当前 workflow 自动拿到目标成员输出并继续执行。

AgentTool ServiceInvoke 对齐

需求中“一个 Agent 调用另一个 Agent”，除了 Workflow 编排 Service，在当前 C# 代码中还可以通过 IAgentTool 的 ServiceInvoke 工具实现。也就是说，接待员 Agent 可以通过工具调用订单员 Agent 或售后专员 Agent，订单员 Agent 也可以继续调用跟进员 Agent。这个能力的运行时基础已经存在，但它更接近“Service 调用能力”，还不是一个完整产品化的 Team Member 协作模型。

当前核心调用路径是 list_services + invoke_service。list_services 用于查询当前 scope 下有哪些可调用的 Service 以及对应 endpoint；它不按 StudioTeam / teamId 过滤，也不能直接表达“当前 Team 的成员列表”。Team 维度成员选择应来自 StudioTeam / StudioMember，而不是 ServiceInvoke 的 list_services。invoke_service 用于调用指定的 service_id + endpoint_id，并把任务投递给目标 GAgent Service。对 Agent 协作来说，Agent B 需要先作为 Service 暴露出来，Agent A 才能通过 ServiceInvoke 工具调用它。

需要注意的是，invoke_service 返回的是 accepted receipt，不是目标 Agent 的最终处理结果。它只表示调用请求已经被接受、目标 Service 已解析并进入后续投递或执行流程；它不代表订单员 Agent、售后 Agent 或跟进员 Agent 已经完成业务处理。

另外，当前 invoke_service 的 ApprovalMode 是 AlwaysRequire，所以 Agent 调用另一个 Agent 默认需要 approve。也就是说，接待员 Agent 想调用订单员 Agent 时，系统会先产生工具调用审批，审批通过后才会真正调用目标 Service。

还需要单独对齐 Service 调用安全语义。InvokeAllowedCallerServiceKeys 可以作为 Service invoke 的安全门禁，但它依赖一个前提：调用请求里必须有可信的 caller service key。当前 admission 链路会检查 ServiceInvocationRequest.Caller.ServiceKey；如果策略里配置了 InvokeAllowedCallerServiceKeys，而 caller service key 为空或不在 allowlist 中，调用会被拒绝。

当前 AgentTool ServiceInvoke 不满足这个前提。invoke_service 构造请求时会把 Caller.ServiceKey 设为空，只携带当前 scope 的 tenant / app 信息；scope invoke HTTP 入口也是空 caller service key。因此它可以调用未配置 caller allowlist 的 Service，但不能代表“Agent A 作为 Service A”去安全调用受保护的 Service B。

也不能简单让前端、LLM 或工具参数传入 caller service key，因为那只是调用方自报，不能作为安全边界。要让 ServiceInvoke 真正支持 InvokeAllowedCallerServiceKeys，需要先建立可验证的 caller service identity 来源，例如来自当前运行中的 Service actor / run context、dispatch envelope、绑定凭证或治理签发的 capability token。只有系统能证明“这次调用确实来自某个已授权 Service”时，才能填充 Caller.ServiceKey 并通过 allowlist 校验。

因此当前 P0 口径应是：ServiceInvoke 具备基础调用能力，但还不是完整的 Service-to-Service 安全协作模型。短期可以定位为“受审批的工具调用 / 非 allowlist 保护 endpoint 调用”；凡是依赖 InvokeAllowedCallerServiceKeys 保护的 Service，不应通过当前 invoke_service 暴露或调用，除非后续补齐可信 caller service identity。

Connector Binding 对齐

按需求文档本身看，C# 对“Team 详情的连接器 Tab 可展示当前绑定配置”已经有基础：Governance binding API 能保存、查询、展示 connector ref。这个部分大体满足“可见性”。

但对“Scope 下所有 GAgent 共享外部连接器 / secrets”和“先用已有 Telegram connector 跑通”的执行层语义，目前只满足了一半：旧 workflow connector 系统可以跑“启动时注册的 named connector”，Governance Binding Connector 可以记录 connector_type + connector_id，但两者没有桥接。因此现在的状态更像：

Governance binding connector = 配置 / 治理 / 展示 / 门禁事实
Workflow connector_call      = 本地启动配置里的 named connector 调用
缺失部分                      = binding_id / connector_type / connector_id -> runtime connector client

因此 P0 需要明确边界：如果目标只是 Team 详情展示当前绑定配置，则现有能力大体可用；如果目标是“Team 成员运行时直接使用绑定的 Telegram / external connector”，则需要新增 Governance binding 到 workflow runtime connector client 的桥接设计，不能只靠前端配置页完成。

Telegram 入口对齐

Aevatar 目前有 Telegram 入站 / 读取能力，但没有 Team 级自动入口。

现有两种能力分别是：

1. NyxID Relay 入站

Telegram message -> Nyx relay -> ChatActivity -> ConversationGAgent -> NyxidChat LLM reply -> Telegram

2. telegram_user Connector

workflow / GAgent 主动调用 connector 去发消息或轮询消息

适合 workflow 主动问 Telegram / 发 Telegram。

缺失的是：

Telegram message -> 自动进入某个 Team -> 自动路由到接待员 / 团队成员

事件拓扑与事件流对齐

当前实际能支持的是 Workflow 运行观察，不是完整的 EventEnvelope 观察系统。事件拓扑图目前拿到的是 getActorGraphEnriched(actorId) 返回的 Workflow 投影图，包含 actor / workflow run / workflow step 节点，以及 OWNS、CONTAINS_STEP、CHILD_OF 这类结构关系；它可以画出一次 Workflow run 的执行结构，但不是逐条 EventEnvelope 的真实路由链路。

事件流目前拿到的是 getServiceRunAudit() 返回的 Workflow audit timeline，包含 run summary、steps、role replies、timeline、final output / error 等数据。timeline 里有 workflow.start、step.request、step.completed、step.failed、role.reply、tool.call、workflow.completed 等阶段信息，可以做运行审计列表，但它不是原始 EventEnvelope 流，也不是所有 agent 间消息的逐跳流水。

和需求的主要差距是：现在没有 EventEnvelope 级的 TopologyAudience、流转方向、publisher、target、route type、envelope id，也没有 Telegram / LLM 这类外部服务节点和实时流动动画数据。结合当前实现语义，更适合先落地为“Team Member / Service 的 Workflow 运行观察页”；如果要严格满足“事件拓扑 + EventEnvelope 瀑布流”，还需要新增 EventEnvelope observation / projection readmodel。

P0 因此应避免把 Workflow audit topology 命名成“完整事件拓扑”。更诚实的命名是“运行审计”“Workflow run topology”或“成员协作轨迹”；EventEnvelope 级实时拓扑可作为后续 Harness / observation 能力。

Gap Matrix

Area	Product expectation	Current code	Gap	P0 direction
Team model	用户可创建多个 AI Team	StudioTeam 已存在，scopeId 是认证工作区 / 租户边界	旧文档中 Scope = Team 口径需要修正	统一为 Scope -> StudioTeam[]，Team 详情使用 teamId
Scope isolation	Team 拥有独立 connector / secret / route / permission 边界	当前 Scope 承担认证和访问边界	Team 级隔离不是现有默认语义	P0 不承诺 Team 级完全隔离；如需要另建模型
Member model	Team 内成员可创建、配置、发布	StudioMember + binding 已存在	需要明确 member lifecycle 和 UI 操作闭环	P0 以 workflow / service member 为默认闭环
Member publish	Team Member 可成为可调用能力	Governance Service / endpoint 可表达发布与发现	SaaS member 与 service 发布关系需要产品化映射	用 StudioMember 绑定 workflow / script / GAgent，并发布为 Service
Workflow collaboration	接待员调用订单员 / 售后员	Workflow 可编排 Service 调用	Service invoke 只返回 accepted receipt，不返回最终输出	P0 至少显示 accepted / running；若要 completed / output 驱动后续 step，需要新增 result continuation
Cross-service payload	上一步输出可喂给下一个成员	StepCompletedEvent.Output 只在当前 workflow run 内写入 variables	不会自动变成另一个 Service 的 payload	必须提供显式 typed payload 映射
Workflow continuation	调用成员后等待结果并继续当前 workflow	当前 Service invoke 不自带“等待目标完成并恢复当前 step”语义	缺 pending invocation 状态、result/failure event、timeout signal 和 actor 内对账恢复	作为独立后端方案决策；不做则 P0 是 fire-and-observe
AgentTool collaboration	Agent 可通过工具调用另一个 Agent	list_services + invoke_service 基础存在	目标 Agent 需先暴露为 Service，且默认 approval	可作为高级能力
Approval semantics	Agent 间调用可自动或可控审批	invoke_service 当前 ApprovalMode = AlwaysRequire	默认会产生工具调用审批	P0 UI 需要展示 / 处理 approval，不默认为静默调用
ServiceInvoke security	Agent / Service 可安全调用受保护 Service	admission 会检查 Caller.ServiceKey 与 InvokeAllowedCallerServiceKeys；当前 invoke_service caller service key 为空	缺可信 caller service identity 来源，不能安全通过 allowlist	P0 不通过当前 ServiceInvoke 暴露 / 调用 allowlist 保护 endpoint；后续补 caller identity / capability token
Connector binding	Team 连接器 Tab 可配置并驱动运行	Governance binding 可记录 connector ref；旧 workflow connector 可调用 named connector	binding 与 workflow runtime connector client 未桥接	P0 可先展示治理事实；若要跑 Telegram，需要补 runtime 桥接
Event topology	展示 EventEnvelope 流转动画	当前有 workflow graph / run audit	缺 EventEnvelope audience / route / envelope id / readmodel	MVP 先做 Workflow run audit topology
Event stream	展示所有 agent 间消息逐跳流水	getServiceRunAudit() 有 timeline / steps / role replies / tool calls	不是原始 EventEnvelope 流，也缺 Telegram / LLM 外部节点	命名为运行审计 / 协作轨迹，不声称完整事件流

建议的 P0 最小闭环

1. Team 列表和 Team Detail 基于 StudioTeam。
2. Member 列表和 Member Detail 基于 StudioMember。
3. Member 可绑定 workflow / script / GAgent，并发布为 Service。
4. Team Detail 能从成员进入 Studio 编辑 / 测试。
5. Workflow 中调用成员时显式选择目标 Service / endpoint，并显式映射 payload。
6. 如果 Call Team Member 需要驱动后续 workflow step，必须补齐 pending continuation、result/failure event、eventized timeout 和 actor 内对账恢复；否则 P0 只展示 accepted / running / audit。
7. AgentTool ServiceInvoke 可作为高级协作能力，但默认展示 approval 流程，且不用于调用依赖 InvokeAllowedCallerServiceKeys 保护的 endpoint。
8. Connector Tab 先展示 Governance binding 事实；运行时桥接作为独立后端 Gap 明确排期。
9. 事件视图先展示 workflow run audit / actor graph，不声称是完整 EventEnvelope 路由。
10. 所有 Console 文案避免暴露 actorId / raw EventEnvelope / primaryActorId 等底层实现细节。

P0 后端 Gap

1. Team / Member API 需要清晰表达 scopeId 是认证上下文，teamId 是业务资源 ID。
2. StudioMember 到 Governance Service / endpoint 的发布、查询、状态回写需要形成稳定闭环。
3. Workflow 调 Service 的 payload mapping 需要强类型或明确 schema，不能靠临时 JSON bag 表达核心语义。
4. 如果 Call Team Member 要等待目标成员结果并恢复当前 workflow，需要新增异步 continuation 方案：invocationId / correlationId、pending step 状态、result/failure event contract、eventized timeout signal、workflow actor 内对账恢复，以及对应 run audit / readmodel。
5. Service invoke result 的权威来源需要明确：优先使用正式 result/failure event；read model / run audit 只能作为观察与展示来源，不能在 query path 中临时推导并驱动 workflow 恢复。
6. AgentTool ServiceInvoke 的 approval、调用记录、错误、超时需要能在 Console 里被用户理解。
7. AgentTool ServiceInvoke 如果要支持 InvokeAllowedCallerServiceKeys，需要新增可信 caller service identity 来源；不能依赖前端、LLM 或工具参数自报 caller service key。
8. Connector binding 到 runtime connector client 的桥接如果进入 P0，需要新增明确设计；否则 P0 只展示 binding 可见性。
9. Workflow run audit topology 需要明确 DTO，不混称 EventEnvelope topology。
10. EventEnvelope observation / projection readmodel 若进入本轮，需要单独设计 publisher、target、route type、envelope id、audience 和外部服务节点。

候选方案：Call Team Member Workflow Step

本节对应后文“Call Team Member 是否进入本轮，还是先用 ServiceInvoke 做高级能力？”这个团队决策项，用于描述如果 Call Team Member 进入本轮，应采用的方案边界。

Call Team Member 是在 Workflow 基础上做的能力，更准确地说，它应该是一个 Workflow extension / workflow step，不是新的 runtime，也不是新的 Multi-Agent 平台 primitive。

简单描述是：Call Team Member 是 Workflow 中的一个成员调用节点。它运行在当前 workflow run 里，由当前步骤根据 memberId 和 action 找到目标团队成员，再通过 member binding 解析到目标成员背后的 Service / Workflow / Script / GAgent，最终走 Service Invocation + EventEnvelope 投递。需要注意的是，投递完成后只能立即得到 accepted receipt；如果要让当前 workflow 等待目标成员结果并继续执行，必须新增 pending continuation / result event / timeout 对账方案。

核心链路：

Current Workflow Run
  -> Workflow step: Call Team Member
  -> memberId + endpoint/action + typed input mapping
  -> resolve member binding
  -> publishedServiceId / active revision / endpoint contract
  -> trusted caller service context
  -> IServiceInvocationPort.InvokeAsync(...)
  -> admission / governance
  -> accepted receipt
  -> EventEnvelope dispatch
  -> target Workflow / Script / GAgent runtime
  -> target publishes explicit result/failure event
  -> or eventized timeout signal fires
  -> workflow actor validates runId + stepId + invocationId
  -> complete/fail pending step and continue workflow

其中 accepted receipt 不是当前 workflow step 的完成信号。若本轮只实现到 accepted receipt，则该 step 的产品语义应是 fire-and-observe：Console 可以展示调用已接受、运行中、审计轨迹，但不能把目标成员输出作为后续 step 的输入。若本轮要支持“等待目标输出后继续”，至少需要补齐：

• pending invocation 持久态：记录 workflowRunId、stepId、invocationId / correlationId、目标 memberId、目标 serviceId / endpointId、timeout deadline 和 expected result contract。
• result/failure event 契约：目标成员完成后发布正式事件，携带 invocationId / correlationId 和强类型输出或错误，供当前 workflow actor 对账消费。
• eventized timeout：异步 timeout 只能发布内部 timeout signal，不能在回调线程直接修改 workflow 状态；workflow actor 收到后校验仍为活跃 pending step，再标记超时。
• workflow 恢复语义：当前 workflow actor 在自己的事件处理流程内完成 step output/error 写入、状态推进和后续节点调度。

它能解决的问题：

• 降低 SaaS 用户理解成本：把底层 service_id + endpoint_id + payload + actorId 包装成“调用某个成员的某个能力”。
• 统一成员协作入口：不管目标成员背后是 Workflow、Script 还是 GAgent，调用方都使用统一的 memberId + action + input mapping。
• 避免绕过治理：不直接使用 actor_send / SendToAsync(actorId, proto)，而是走 IServiceInvocationPort，保留 endpoint contract、policy、revision、admission 和 ServiceRun 记录。
• 保证 caller identity 可信：调用方身份来自平台注入的 trusted caller service context，而不是前端、YAML、LLM 或用户手填的 caller_service_key。

不建议做

1. 不把 Scope 当 Team。
2. 不让 Console 用户填写 actorId / primaryActorId / raw EventEnvelope。
3. 不用前端假数据伪造 EventEnvelope 级拓扑。
4. 不把 Governance connector binding 等同于 runtime connector client。
5. 不在没有 EventEnvelope readmodel 的情况下展示 envelope id、route type、audience 等字段。
6. 不让前端、LLM 或工具参数填写 callerServiceKey 来绕过 InvokeAllowedCallerServiceKeys。
7. 不把 ServiceInvocationAcceptedReceipt 当成目标成员完成结果，也不通过 query-time 读取 run audit / readmodel 来临时拼装 workflow 恢复。

需要团队决策的问题

1. P0 是否明确采用 Scope -> StudioTeam[] -> StudioMember[] 模型？
   需要确认：Scope 只作为认证工作区 / 租户边界，StudioTeam 才是用户可创建的 AI Team。
   决策结果会影响 Console 路由、API 入参、权限模型、文案和旧文档里的 Scope = Team 是否需要统一修正。

2. Workflow 协作是否作为 P0 的默认成员协作路径？
   需要团队在“Workflow 编排 Service 协作”和“AgentTool ServiceInvoke 协作”之间确定默认路径。
   当前倾向：P0 用 workflow 编排 service 协作，因为它更适合表达显式步骤、状态、审计和结果观察。

3. Call Team Member 本轮是否需要等待目标成员结果并恢复当前 workflow？
   需要决定：P0 是只支持 fire-and-observe，还是支持“调用成员 -> 等待目标输出 -> 写回当前 step output -> 继续后续节点”。
   如果需要等待并恢复，必须新增 pending continuation、result/failure event、eventized timeout 和 workflow actor 内对账恢复方案。

4. Service invoke 的结果权威来源本轮采用哪一种？
   需要决定：目标成员执行完成后的结果由正式 result/failure event 承载，还是只在 run audit / readmodel 中展示。
   建议：驱动 workflow 恢复的只能是正式事件；run audit / readmodel 只做观察，不作为 query-time 恢复来源。

5. Call Team Member Workflow Step 是否进入本轮？
   这是文档里最关键的产品化决策之一。
   如果进入本轮，它应作为 workflow extension / workflow step：用 memberId + action + typed input mapping 解析到目标 Service / endpoint，再走 IServiceInvocationPort。
   如果不进入本轮，则 P0 可以先暴露底层 ServiceInvoke 或 workflow service step，但用户理解成本会更高。

6. InvokeAllowedCallerServiceKeys 保护下的 Service 协作是否进入 P0？
   当前 ServiceInvoke 构造请求时 Caller.ServiceKey 为空，scope invoke HTTP 入口也是空 caller service key。
   需要决定：P0 是否支持调用配置了 InvokeAllowedCallerServiceKeys 的受保护 endpoint。
   如果进入 P0，必须先设计可信 caller service identity / capability token，不能让前端、LLM 或工具参数自报 caller service key。

7. Connector Binding 本轮只展示治理事实，还是必须驱动运行时执行？
   当前 Governance binding 可以保存、查询、展示 connector ref；但 binding_id / connector_type / connector_id -> runtime connector client 的桥接还不存在。
   需要明确 P0 边界：只做 Team 详情 Connector Tab 的配置可见性，还是要求成员运行时真的使用这些绑定。

8. Event topology 本轮是否明确降级为 Workflow run audit topology？
   当前实际可用的是 workflow graph / run audit，不是完整 EventEnvelope 观察系统。
   需要决定：P0 页面是否命名为“运行审计”“Workflow run topology”或“成员协作轨迹”，而不是“完整事件拓扑”。

9. 是否需要新增 topology / message ledger readmodel？
   如果产品坚持要“事件拓扑 + EventEnvelope 瀑布流”，团队需要决定是否本轮新增 observation / projection readmodel。
   该 readmodel 至少需要表达 publisher、target、route type、envelope id、audience、方向、时间、水位和外部服务节点。
   如果不新增，P0 只能做 workflow run audit timeline。