Fusion 如何分配智能
Fusion 是 FUMO Lab 构建的融合智能系统，根据任务每一步的需求选择合适的模型能力。
一个边界清晰的请求可能只需要一个合适的模型。Agent 工作流则会从探索转向实现，从失败的操作转向诊断，再从候选结果转向验证。随着任务状态改变，最有价值的能力也会改变。
本页概述 Fusion 白皮书 Revision 0.1↗ 中的架构与研究方向；当前对客户端开放的具体能力，以 API 参考为准。
从路由到能力分配
当请求的需求在开始时就足够明确，路由很有用。Fusion 将路由视为更广泛的能力分配过程中的一种操作。
一次分配可以决定模型、角色、上下文范围和计算预算，也可以决定停止调用。具体选择取决于待解决的问题：此刻可能需要另一个求解者、领域专家、独立审查者，或一次确定性检查。
目标是获取可能改变下一步决策的证据。
一个任务状态，多种观察视角
Fusion 将传入的任务信息整理为统一的状态描述，包括用户意图、约束、已有决策、工具观察、失败记录和验收条件。
各个角色按需获取相关上下文：探索者可能只需要待解的问题，审查者需要候选方案及其约束，负责汇总结果的模型则需要保留完整的对话要求和动作约束。每个角色承担明确的任务，工作流由系统统一控制。
公开 API 采用无状态设计，客户端需在每次请求中发送完整的对话与工具历史。Fusion 不存储可通过 previous_response_id 续接的 Responses 对象。
将模型视为证据来源
模型在当前步骤中的价值取决于角色、上下文、已有证据、可靠性、延迟和成本。
Fusion 按各个模型的长处分配工作：用领域模型回答局部问题，用高效模型完成范围明确的检查，在需要更强判断力的决策上投入前沿模型。每项贡献都需要评估，误导性或重复的证据可能损害结果。
每个角色都有明确的证据需求。角色设置和内部模型池可以随系统发展而调整。
围绕下一步决策形成闭环
白皮书将能力分配描述为一个反复进行的过程：
- 理解状态 — 识别发生了什么变化，以及哪些不确定性可能影响下一步答案或动作。
- 选择下一次计算 — 决定来源、角色、上下文视图与预算，或判断不值得继续增加调用。
- 评估证据 — 记录证据来源，比较不同结论，核实矛盾之处并排除不可靠的材料。
- 形成唯一结果 — 遵循客户端的接口约定，返回最终答案或工具调用。
- 根据观察更新 — 客户端返回工具结果或用户补充信息后，基于更新的历史推进下一步。
图中展示了一种协作过程。实际路径会随任务状态调整，有些步骤由单个模型即可完成。
唯一的最终答案或动作
候选答案、审查意见、测试结果和工具调用建议，都需要根据其相关性和可靠性进行评估。
只有最终响应路径可以向客户端发出工具调用。中间贡献者不能独立执行客户端工具，也不能各自对外部世界做出相互冲突的修改。
客户端负责执行受支持的 function 或 custom/freeform 工具调用并回传结果。公开接口支持由客户端执行的工具，不提供托管 Web Search 或 Computer Use。具体支持范围请查看 Chat Completions 和 Responses 参考。
计算投入跟随证据价值
任务早期，另一条独立思路可能很有价值；已有实现后，验证可能比再生成一个候选方案更重要。当现有证据足以支撑下一步决策，额外推理可能只增加延迟和成本。
因此，Fusion 将是否调用、是否协作、是否升级能力以及何时停止视为相关的分配决策。这些选择需要权衡继续计算的预期收益、成本和延迟。
两种进步来源
白皮书区分了两种进步：模型进步扩大可用能力，分配能力的进步改善这些能力的使用方式。
Revision 0.1 描述了结构化任务感知和明确的策略边界。学习式能力分配是后续研究方向，白皮书提出通过版本化评测和可回滚的策略变更来控制风险。
研究目标是在提升系统能力的同时，控制前沿模型的计算消耗。这一关系还需要更多评测来验证。