提案讨论：在 model 路由层支持挂载外部 learned-routing provider（orchestrator-as-provider）

[eanzhao]

背景

当前 aevatar 的 model 选择是一条声明式优先级链 + provider failover：

caller-explicit model > account default > chat route policy > deployment default

• 优先级链：IngressModelPreference
• 运行时规则匹配（actor 化策略 ChatRoutePolicyGAgent → projection → readmodel）：ChatRouteResolver
• provider 层 failover：FailoverLLMProvider
• 可热插拔的 provider 池：CompositeLLMProviderFactory

选择依据是声明式元数据（model / channel / command / tool_mode / scope policy），不是 query 的难度或质量感知。这是有意的轻量设计：LLM 经 NyxID 黑盒经纪，model 选择留给声明式策略 + failover，"组合 > 单体"的编排放在更高的 agent / workflow / member 层。

缘起

Sakana Fugu（2026-06）及其开源复刻 OpenFugu 提出 learned per-query 模型选择：一个小模型 + 学出来的打分头，按每个 query 在一池 worker 大模型里选"最该回答这题"的那个，纯编排（不改权重）就能显著高于最强单体，对外是单一 OpenAI 兼容端点。

提案：把外部 learned router 作为 provider 接入（orchestrator-as-provider）

把这类 orchestrator 作为外部 OpenAI 兼容 provider 接入现有 provider 池：

1. 外部 learned router（如 OpenFugu）self-serve 成一个 OpenAI 兼容端点，内部自己做多模型路由；
2. 在 aevatar 侧把它注册为 provider 池里的一个 provider / model（例如 fugu）；
3. ChatRoutePolicyGAgent 的 default_target 可以把选定范围的请求 forward 给它。

之所以可行且顺架构：provider 池本身已经是 OpenAI 兼容、可热插拔、composite 的（CompositeLLMProviderFactory），接入点天然存在，不需要改动内核的 model 选择算法——aevatar 把"选哪个底层模型"这件事委托给这个外部 provider，自己仍只面对一个 provider 契约。

需要先讨论清楚的开放问题

1. 凭证治理 / NyxID 经纪边界：外部 orchestrator 背后还要调一池模型，这些凭证在哪、是否经 NyxID 经纪？这是和现有凭证治理的接缝。
2. streaming：ChatStreamAsync 是主链强约束；orchestrator 选完模型后能否无损透传 token stream，还是只能整体返回？
3. tool / function calling：主链重度依赖 tool loop；被选中的 worker 必须支持 tool calls，且 orchestrator 要无损透传 tool_call 协议。
4. failover 分层：orchestrator 自身故障 vs 它选中的 worker 故障，failover 责任落在哪一层。
5. 可观察性归因：现在记 gen_ai.provider.name = provider；经 orchestrator 后实际回答的 worker 对 aevatar 不可见，是否需要回传 / 如何归因。
6. 成本 / 延迟：多一跳 orchestrator + 小模型推理的开销，在什么场景下值得。
7. 部署形态：谁来 serve orchestrator、生命周期归谁。