「用 GPT-4 就完了」的问题
多数人工智能平台替你悄悄做了决定：挑一个自己中意的模型，把一切接上去，然后继续。这行得通，直到行不通——直到模型宕机，直到竞争者在某项任务上放出更好的东西，直到你想带上自己的 API 密钥、把成本留在自己账上，直到你需要生成图像而默认模型不会。
惯常的药方是一个下拉列表。挑一个模型，处处都用它，权衡自己扛。那不是分流，那是甩锅。ToRun 做的是结构上不同的事。
把能力放在前面的管线
ToRun 的每次请求在碰到模型之前要走过四步。
1. 模式确定产品面。 当你打开一次对话会话或启动一项研究任务时，你就在选择模式。模式不只是界面上的标签：它带着一组既定的必需能力与可选能力。研究任务需要工具（网页检索）、长上下文与结构化输出。普通对话会话默认只需要文本生成。
2. 能力集合变成筛子。 ToRun 维护一份来自众多供应商的模型目录——OpenAI、Anthropic/Claude、Google/Gemini、DeepSeek、xAI/Grok、Mistral 等。每一条都带着该模型实际支持的能力并集：视觉、工具、代码执行、图像生成、音频输入、音频输出、视频生成、嵌入、重排、实时流、推理等。第一步得出的集合与这份目录相比对。凡不满足全部必需能力的模型都被淘汰。
3. 价格与质量的排序挑出胜者。 在通过筛子的模型中，ToRun 按请求实际是什么来排序。短而简单的问题按成本排序，于是你得到又快又便宜的回答。更长或更难的问题在守住质量下限的前提下，按每单位成本的能力排序。带图像的一轮按模型看得多好来排序，而非按每元的推理。工作流执行器切换到质量优先，因为无人盯着运行的自动化管线应当奔向最好的结果，而不是最便宜的近路。BYOK 用户进入定价的方式不同，因为请求走的是他们自己的供应商账户。
4. 回退链吸收供应商故障。 若所选模型返回服务错误，同一条管线会排除该模型后再跑一次。第二合适的模型作答。除非全部可行的候选都已宕机，否则你看不到任何错误。
一个具体例子：视觉加工具
假设你贴上一张截图，请 ToRun 到网上找找它所显示内容的背景。这次请求同时触及两项能力：视觉（模型必须接受图像作为输入）与工具（模型必须能调用网页检索函数）。
在单模型的做法下你会卡住：你的平台要么支持这个组合，要么不支持。在按能力分流下，ToRun 把两项要求取交集。只有确认同时支持视觉与工具调用的模型才通过筛子。在这份短名单里，按价格与质量的排序为你当前的模式挑出最好的。若首选候选被限流或宕机，下一个会在你什么都不做的情况下处理这次请求。
实务上这很要紧：具备视觉的模型阵容在过去一年变化很大，并将继续变化。按能力分流让 ToRun 在新模型入库的那一刻就自动把它们纳入考量，无须你这边做任何更新。
为什么这胜过锁定
单模型平台只有一条回退之策：等供应商修好故障。以能力为先的平台有一份目录。OpenAI 出事故时，Anthropic 或 Gemini 能承接的请求就在那里得到处理。当某个新的 Mistral 模型在结构化输出上给出更好的性价比时，它会进入相关模式的排序，而不需要强制迁移。
同样的逻辑适用于 BYOK。当你为某供应商加上自己的 API 密钥，那份凭据被关在分流层内部。与该供应商合适模型相配的请求可以取用你的密钥而非 ToRun 的账户，在恰当的计费层把成本转到你与供应商的关系上。分流管线不变：变的只是执行时刻用哪份凭据。
代价是诚实：ToRun 无法保证最便宜的模型对你的任务最聪明。排序是敞开的——你能看到选了什么、为什么选，也可以覆盖。这份透明正是目的。每次请求都会写下计费记录，含所用模型、执行时生效的计价单位与成本拆分。你可以在几个月后核查任何一次调用，哪怕供应商已改价，因为快照在请求运行的那一刻就被冻结了。
一个包办一切的模型是个舒服的杜撰。你真正想要的，是一个为每项任务找出合适模型、并让这份选择可读的平台。