Model Orchestrator Fugu

要解决的问题

多模型协作的常见做法是固定流水线：planner 先出方案，researcher 补资料，critic 检查，synthesizer 汇总。问题是这条流水线默认每一步都会成功，也不关心任务是否真的需要六个人轮流发言。结果往往是中间角色产出大量冗余上下文，critic 发现问题后也无法触发重做，只能带着错误继续往下走。

此外，只要某一个模型临时限流或返回空响应，整条流程就可能终止。这类失败通常只暴露一个 error 字符串，运维侧很难判断到底是限流、超时、认证失败，还是模型输出了空内容。

核心机制

Model Orchestrator Fugu 是一个规则驱动的协调器。它把模型调用拆成有限角色：planner、researcher、analyst、counterparty、critic、synthesizer，并提供四种模式：

• fast：一个主模型直接回答，适合边界清晰的小任务。
• balanced：planner、analyst、critic、synthesizer 四角色协作。
• deep：在 balanced 基础上加入 researcher 与 counterparty，用于复杂报告或需要对抗性校验的场景。
• auto：按任务复杂度在以上三者间选择。

v0.4.0 引入了更接近 TRINITY 设计思路的三角色抽象：Thinker、Worker、Verifier。执行不再是一次性跑完全部角色，而是由 Verifier 给出 ACCEPT 或 RECVISE，RECVISE 会触发 Worker 重新执行，直到通过或达到最大轮次。默认最大轮次为 5，简单任务通常在 3 轮内收敛。

稳定性由几个机制共同保障：

• 指数退避重试：每个角色默认最多重试 3 次；遇到 HTTP 429 时限流退避时间额外乘以 1.5。认证错误与格式错误不重试。
• 自动降级：全部重试失败后，按 degradation_chains 顺序切换到备用 provider，并在结果中标记 degraded: true 与 degraded_from。
• 角色级超时：planner 30 秒，researcher 90 秒，其余角色在 45～60 秒之间。
• 中间结果缓存：成功的角色输出按内容哈希缓存，部分失败时只重跑失败角色。
• 失败分类：把失败归因到 rate_limit、timeout、server_error、network、empty_response、auth_error、format_error 七类，决定是否重试。
• 四维指标：记录成功率、耗时、降级次数、失败分布，用于复盘路由策略。

另一个独立层是自进化：scripts/evolution.py 会记录任务轨迹，基于失败案例优化角色提示词，并支持查看仪表盘和回滚。核心编排逻辑在 scripts/orchestrator.py，负责多模型调用、角色分工、重试、降级与缓存。

适用边界与注意点

这是一个规则驱动的编排器，不是自主智能体。它不会自己决定更换任务目标，也不会绕过 provider 的能力上限。如果底层模型本身在某个领域能力不足，再多次 RECVISE 也不会凭空产生更好的答案。

deep 模式和 --parallel 并行会显著增加 token 消耗和延迟，适合高价值报告或明确需要对抗性校验的场景，不建议用于日常问答。默认路由将 LongCat 作为稳定基座，DeepSeek 用于补充批判性分析，具体策略会随 benchmark 复盘调整。

API key 只能通过环境变量传入，编排器不会写入文件、不会在终端回显，也不会出现在最终回复里。所有 provider 均要求 OpenAI 兼容接口，不支持的模型需要自行适配后再接入。