AI Team Agent 协作问题

[jason-aelf]

范围

这里讨论的两种 Aevatar Agent 协作方式分别是：

1. 固定流程：Workflow 编排 Service / Member。
2. 智能委托：GAgent 通过 AgentTool ServiceInvoke 调用其他 GAgent。

核心结论是：两种方式都能表达 Agent 间调用，但当前都还不能直接等同于完整的 Agent-to-Agent 协作协议。固定流程的问题是协作关系清楚，但结果 continuation、可信 caller identity 和 caller allowlist 通过方式都不完整；智能委托的问题是它更接近受审批的 Service 工具调用，还缺可信 caller identity 和标准结果闭环。

固定流程：Workflow 编排 Service / Member

这种方式适合表达确定流程、强审计和可控业务链路。它的问题主要不是不能协作，而是目前还缺少“调用目标 Agent 后等待其结果并继续”的完整协作闭环；同时，如果 workflow step / member invoke 最终仍走 ServiceInvoke admission，它也同样缺少可用于受保护 endpoint 的可信 caller identity。

问题	具体表现
Workflow step 调 Agent 不能自然等结果	Workflow 编排 Service / Member 时，调用目标成员通常只能拿到 accepted receipt，不能像本地函数一样同步拿最终输出。
后续步骤缺少权威输入来源	如果下一步依赖目标 Agent 的输出，需要额外定义 result event / failure event / timeout event，否则 workflow 不知道何时、用什么结果继续。
Workflow 编排缺少可信 caller identity	Workflow definition、run、step 或 member 关系本身不能自动等同于平台可信 Caller.ServiceKey；必须有平台侧的“workflow/member 代表哪个 service identity 调用”的签发契约。
无法安全通过 caller allowlist	ServiceInvoke 时 Caller.ServiceKey 为空或来自请求体/参数，不能安全通过 InvokeAllowedCallerServiceKeys。

候选解决方案：Call Team Member Workflow Step

Call Team Member 应定位为 Workflow extension / workflow step，而不是新的 runtime 或新的 Multi-Agent 平台 primitive。它作为当前 workflow run 内的成员调用节点，由 step 按 memberId + action/endpoint + typed input mapping 解析 StudioMember binding，找到目标成员背后的 published Service、active revision 和 endpoint contract，再通过平台注入的 trusted caller service context 调用 IServiceInvocationPort.InvokeAsync(...)，继续走 admission、governance 和 EventEnvelope dispatch 到目标 Workflow / Script / GAgent runtime。

建议链路是：

Current Workflow Run
  -> Workflow step: Call Team Member
  -> memberId + action/endpoint + 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 result/failure event or 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 的权威输入。

如果要解决“调用目标成员后等待其结果并继续”的 workflow 问题，至少需要补齐以下契约：

契约	解决的问题
pending invocation 持久态	当前 workflow actor 记录 workflowRunId、stepId、invocationId / correlationId、目标 memberId、目标 serviceId / endpointId、timeout deadline 和 expected result contract，避免把 accepted 当完成。
result / failure event	目标成员完成后发布正式事件，携带 invocationId / correlationId 以及强类型输出或错误，作为当前 workflow 恢复的权威输入。
eventized timeout	timeout 只能发布内部 timeout signal，再由 workflow actor 校验活跃 pending step 后标记超时；禁止回调线程直接修改 workflow 状态。
workflow 恢复语义	当前 workflow actor 在自身事件处理流程内完成 step output/error 写入、状态推进和后续节点调度。
trusted caller service context	caller identity 由平台根据 workflow/member 运行上下文注入，不能由前端、YAML、LLM 或用户参数自报 callerServiceKey。
typed input/output mapping	跨 Service 调用必须显式构造强类型 payload，并显式声明结果契约；不能依赖 StepCompletedEvent.Output 自动跨 Service 传递。

result / failure event 的来源边界

上表中的 result / failure event 不是要求所有 Service 额外发明同一种完成事件，而是要求 Call Team Member 对不同 Service 类型声明清楚“哪个已提交事实可以作为本次 step 的业务输出”。accepted receipt 只表示调用已被接受；Workflow 能否继续，取决于目标 runtime 是否存在可观察、可对账的业务完成事实。

Service 类型	可观察的业务完成事实	Workflow 是否能通用等待结果	结论
Workflow Service	WorkflowCompletedEvent	可以	Workflow 可以通过观察目标 workflow run actor 的 WorkflowCompletedEvent，并将 output / error / success 映射为 step 执行结果。
Static RoleGAgent Service	RoleChatSessionCompletedEvent	可以	Workflow 可以通过观察目标 RoleGAgent 的 RoleChatSessionCompletedEvent 获取执行结果；调用时需要用 invocationId 绑定 ChatRequestEvent.session_id，避免不同会话结果混淆。
Script Service	ScriptDomainFactCommitted	有条件可以	Workflow 可以观察脚本提交的 ScriptDomainFactCommitted，但一次执行可能产生多条 fact，暂无法确定哪条 fact 是 step 输出。
Static custom GAgent Service	当前没有统一完成事件	不可以	Static custom GAgent 当前只能通用支持 accepted 语义；除非 custom GAgent 显式声明并提交可观察的结果事件，否则不能通用支持“调用后等待业务输出”。

因此，Call Team Member 的 expected result contract 至少需要表达目标 Service 类型、可观察结果事件、匹配键和结果载荷来源。Workflow Service 和 Static RoleGAgent Service 已经有明确完成事实，可以先纳入可等待结果的范围；Script Service 需要补结果选择契约；Static custom GAgent Service 在没有标准结果事件前只能作为 fire-and-accepted 调用。

这个方案对应解决的 workflow 问题是：用 memberId + action + typed mapping 降低 SaaS 用户理解成本；用 IServiceInvocationPort 保留 endpoint contract、policy、revision、admission 和 ServiceRun 记录；用 pending continuation、result/failure event 和 timeout 对账恢复 workflow；用平台注入身份支持受保护 endpoint 的 caller allowlist。

智能委托：GAgent 通过 AgentTool ServiceInvoke 调其他 GAgent

这种方式更灵活，适合让 Agent 根据上下文自主决定是否委托其他能力。但它的问题是：当前能力更像“Agent 使用工具调用一个 Service”，还不是完整的 Team Member 协作模型。

问题	具体表现
调用结果仍然只是 accepted	AgentTool invoke_service 返回的不是目标 GAgent 的最终业务输出，因此调用方 GAgent 不能天然接着推理。
智能委托会被审批打断	当前 invoke_service 默认可能需要 approval；Agent A 决定委托 Agent B 后，流程可能停在等待用户批准。
缺少可信 caller identity	当前 AgentTool 调用时 Caller.ServiceKey 可能为空或不可信；这会影响受保护 endpoint 的调用。
无法安全通过 caller allowlist	如果目标 Service 配了 InvokeAllowedCallerServiceKeys，调用方必须有平台可信的 caller service identity；不能让 LLM、前端或工具参数自报身份。

对比总结

维度	固定流程：Workflow 编排 Service / Member	智能委托：GAgent AgentTool ServiceInvoke
主要优势	流程明确、可审计、适合确定业务链路	灵活，Agent 可根据上下文自主选择委托对象
主要问题	缺少等待目标 Agent 完成并继续的 continuation 闭环；缺少可信 caller identity / allowlist 通过契约	缺少 Team-aware 边界、可信 caller identity 和结果回传协议
最大风险	把 accepted receipt 误当成目标成员完成结果	把工具调用误当成正式 Agent 协作关系
需要补的关键能力	pending invocation、result / failure / timeout event、typed mapping、workflow/member-scoped trusted caller identity	trusted caller identity、team-scoped service discovery、result continuation
适合定位	P0 默认协作主路径，但需诚实表达当前语义	高级动态委托能力，不宜作为默认主链路

最小结论

固定流程的问题：协作关系清楚，但结果 continuation、可信 caller identity 和 caller allowlist 通过契约都不完整。

智能委托的问题：调用能力已有，但权限身份和结果闭环不完整。