Fusion Style Workflow CN
OpenRouter Fusion 让很多开发者重新意识到一件事：下一个有价值的模型入口，未必是单个更大的模型，而可能是一个由多个模型、工具、评审和合成步骤组成的复合工作流。
1flowbase 的重点不是只做一个模型路由器，而是让你把这种 Fusion 风格的流程做成一个可复用、可发布、可观测的虚拟模型接口。客户端只需要调用一个模型名，1flowbase 会在后台运行完整工作流，并保留每个节点的输入、输出、Token、工具调用和错误信息。
Fusion 风格工作流适合那些“值得多花一点时间和成本换更可靠答案”的任务：
- 复杂问题研究：让多个模型独立回答，再由评审节点整理共识、冲突和盲点。
- 架构方案评审：让不同模型从实现、风险、成本、维护性等角度给出判断。
- 代码或文档复核：让分支模型检查同一输入，再由汇总模型输出最终建议。
- 多模型降级与成本控制：把强模型、小模型、便宜模型组合成一个可观测的虚拟模型。
- Agent 上游模型封装：让 Claude Code、Codex、OpenCode、Continue 等客户端调用一个标准接口，但实际执行的是你设计的工作流。
不建议把 Fusion 风格工作流用于所有请求。简单问答、低成本分类和普通格式转换通常不需要多模型评审团。更好的做法是只在高价值、高不确定性或高失败成本的任务上启用它。
1flowbase 已经内置 fusion 官方模板。进入顶部导航的 Templates 页面，找到 fusion，点击 Import template 即可导入。
导入后会得到一个可直接预览和修改的工作流。你可以先用模板理解结构，再替换成自己的模型、工具和评审策略。
模板中的核心结构是：
Start -> 主 LLM -> Answer
|
+-> fusion 工具
|
+-> 分支 LLM2 / LLM3 / LLM4
+-> 汇总 LLM5
+-> Tool Result
主 LLM 负责接收用户请求，并在需要多模型评审时调用挂载的 fusion 工具。fusion 工具会把任务分发给多个分支 LLM，再把分支结果交给汇总 LLM，最后将工具结果返回给主 LLM。
上图红框里的部分就是多模型评审团。你可以把分支 LLM 配成不同供应商、不同能力或不同成本层级的模型，例如一个便宜快速模型、一个强推理模型和一个长上下文模型。
在主 LLM 节点的设置面板中打开 Mount LLM，然后新增或编辑一个工具注册项。模板中使用的工具名是 problem_review。
关键配置：
- Description：写清楚这个工具什么时候应该被调用，例如“这是一个工具评审团，调用该工具会对输入任务进行评审”。
- Allow branch LLM：打开后，工具可以调用下游分支 LLM。
-
Tool mode：选择
fusion。 - Pre-intercept / Schema fields：需要强约束输入结构时再添加；普通评审场景可以先保持简单。
- Mounted LLM list：把用于评审和汇总的分支 LLM 接入到该工具。
建议先用模板默认结构跑通，再逐步替换模型。不要一开始就堆太多分支模型，否则成本、延迟和调试复杂度会同时上升。
导入模板后，回到工作流页面点击 Preview，输入一个适合多模型评审的问题，例如：
请评审这个方案是否适合进入下一轮开发：我们要把 Playwright 和质量分层接入 CI/CD，并给出风险、收益和最近两周执行计划。
执行时，主 LLM 会根据上下文决定是否调用 problem_review。如果调用成功，分支 LLM 会并行或按工作流策略执行，汇总节点会生成最终工具结果，主 LLM 再把它整合成用户可读的回答。
进入左侧 Log 页面，选择刚刚的运行记录，打开 Conversation log 的 Track 标签。你可以看到工具调用链、每个子调用的状态和 Token 消耗。
重点查看：
-
Tools区域中是否出现problem_review。 -
fusion Executed successfully是否成功返回。 - 每个分支 LLM 的 Token 消耗，例如 LLM2、LLM3、LLM4、LLM5。
- 哪个节点返回失败、超时或异常结果。
- 最终回答是否真的吸收了分支模型的差异，而不是只复制其中一个输出。
这也是 1flowbase 与普通模型路由器最大的不同：你不只得到一个最终答案，还能看到这个答案背后发生了什么。
工作流调试稳定后，可以点击 publish 将它发布成一个虚拟模型接口。发布后，外部客户端可以像调用普通模型一样调用这个工作流。
常见接入方式：
OpenAI Responses API
OpenAI Chat Completions API
Claude-compatible Messages API
对客户端来说，它只是一个模型名。对你来说，它是一个包含分支 LLM、评审节点、工具回调和日志 Trace 的可观测工作流。
为了让团队更容易理解接口用途，建议给发布后的模型使用清晰名称：
fusion-review
architecture-review-panel
research-fusion
code-review-council
名称应该说明它是“什么时候该用的模型”，而不是只描述底层供应商。
第一次使用时，建议从下面的配置开始：
主 LLM：负责判断是否调用 fusion 工具，并生成最终自然语言回答
分支 LLM A：便宜快速模型，负责快速覆盖常规观点
分支 LLM B：强推理模型，负责发现风险和边界条件
分支 LLM C：不同供应商模型，负责提供模型多样性
汇总 LLM：负责整理共识、冲突、盲点和最终建议
跑通后再考虑加入更多分支、预算阈值、Fallback、JSON Schema 或自定义工具。
为什么执行变慢了？
Fusion 风格工作流会调用多个模型，并等待评审或汇总节点完成。它天然比单模型调用慢，适合高价值问题，不适合所有请求。
为什么成本变高了？
多模型评审会产生多个模型调用。建议在日志中观察每个分支 LLM 的 Token 消耗，再决定是否减少分支数量、替换便宜模型或只在特定任务触发。
为什么最终答案没有明显变好？
先检查工具描述是否足够清楚。如果主 LLM 不知道什么时候调用 problem_review，或者分支 LLM 的角色差异太小，Fusion 的收益会下降。
如何判断哪个模型贡献最大？
查看 Log 的 Track 记录，展开 fusion 工具下的分支 LLM 调用，对比每个模型输出、Token 消耗、失败状态和最终回答吸收的内容。
可以替代 OpenRouter Fusion 吗？
1flowbase 更像是一个可视化、可发布、可观测的 Fusion 风格工作流运行层。你可以调用 OpenRouter 的模型，也可以组合其他供应商模型、本地模型和自己的工具节点。
OpenRouter Fusion 证明了多模型合成有价值。
1flowbase 让这种工作流变得可控、可观测、可复用、可发布。
如果你正在构建 AI Agent、Coding Agent、研究助手或内部知识工作流，Fusion 风格模板可以作为一个起点：先让多个模型独立思考，再让 1flowbase 帮你看清每一步发生了什么。