这里的工作流究竟是什么
人工智能领域多数所谓「工作流」的工具，不过是提示链外加一层薄壳。ToRun 的搭建器是一张由带类型步骤组成的有向无环图：你把模型调用、工具调用、条件分支、循环与子流程连成一张图，引擎按依赖顺序执行，在图允许的地方并行。
每一步都是一等实体，带着自己的配置：步骤类型（大模型调用、网页检索、代码执行、图像生成、检索、变换等）、输入模式、错误策略（快速失败、退避重试、转到备选）、按步的执行预算上限与超时。
每个大模型步骤内部的模型分流，走的是与 ToRun 其他一切相同的能力管线。你声明所需——结构化输出、视觉、工具调用、推理、至少 N 词元的上下文窗口——执行器便在当时可用的供应商中解析出最匹配的模型。若你偏爱的供应商返回 5xx，回退链会自动接手。
质量优先的执行器，以及它在实务上改变了什么
当你运行工作流时，执行器有意选择质量档的模型，而非最便宜的选项。两个理由：自动化产出的成果（报告、生成的内容、代码）没人会立刻复核，于是质量上的瑕疵悄悄累积；而在中等用量下，成本差额小于一次糟糕输出的代价——那会逼出一次重跑或人工修补。
实务上这意味着「把研究总结并写一份报告」的工作流，会为总结挑一个扎实的推理模型、为撰写挑一个高质量的文本模型，而不是奔向价格底部。若你知道某一步用轻量模型就够，可以逐步覆盖。
计费沿用 ToRun 的其余部分：工作流内每一次模型调用都写下恰好一条记录，附带冻结的价格快照。一次在五个步骤里调用三个不同模型的运行，会产生五条记录。你可以事后核查每次运行的确切成本，并按步骤拆分——哪怕在供应商价格已经变动的几个月之后。
剖析一次运行
每一次工作流运行都会产出结构化的轨迹。轨迹展示这张图，并为每个节点加注：开始时刻、结束时刻、解析出的模型、输入与输出的词元数、发生的工具调用，以及若有错误也一并记下。在大模型步骤上，你可以展开发送出去的确切提示与收到的原始响应。
若某一步失败，轨迹会告诉你错误来自模型调用（供应商错误、上下文溢出、内容策略拒绝）、来自下游工具（网络超时、模式校验失败），还是来自你自己的条件逻辑。你不必添加日志：每次运行都在基础设施层面被捕获。
任何一次运行都可以用同样的输入重放，这让复现一次故障很直接。
一个小例子：每周的竞品跟踪工作流
设想一条你每周一早晨启动的工作流：
- 网页检索步——为一组竞品关键词搜索近期报道，返回一份地址与摘录的清单。
- 检索步——从知识库取出最近四份报告，以奠定起始上下文。
- 总结步（大模型）——把检索结果提炼成结构化的发现：新功能、价格变动、值得注意的公告。
- 撰写步（大模型）——以一致的内部文风写一份简短备忘，扎根在已总结的发现上。
- 投递步——把备忘发到配置好的 Webhook 端点。
这张图有天然的依赖：第 3 步依赖第 1、2 步（两者可以并行），第 4 步依赖第 3 步，第 5 步依赖第 4 步。执行器无须任何显式的并行设置便如此推进：它读的是边。