编译式工作流（Compiled Workflow）是指把一条多步骤的 AI 任务流程，在执行之前先整体“翻译”成一份明确的可执行计划（execution plan），运行时照这份计划一路跑下去，而不是每走一步都回头向调度器询问一次下一步做什么。
打个比方：新手做菜，每做完一步都要翻回菜谱确认下一句，翻书、找页码、核对食材，这些动作本身不产出菜。老手则先把整份菜谱改写成一张自己的工序单：先切什么、哪两样可以同时起锅、哪一步要等水开，全部提前排好，进了厨房只看这张单子。编译式工作流就是后者。
之所以值得这么做，是因为大多数工作流框架（workflow orchestration）本质上是一个调度循环（scheduler loop）：执行节点 → 拿到输出 → 序列化并持久化状态 → 判断路由 → 挑下一个节点。每一步都要拼上下文、读写状态、做分支判断。链路越长、分支和循环（loop）越多，这部分“管理成本”占比就越高，真正调用模型反而只占少数。编译式的做法是把能在运行前确定的东西提前定下来：对图结构做静态分析、把可并行的节点合并调度、提前绑定参数、先校验类型与权限，运行期只保留真正依赖运行时数据的动态决策点。
和相邻概念的区别：提示链（prompt chaining）说的是“步骤怎么串”，属于逻辑结构；编译式说的是“这些步骤怎么被执行”，属于执行策略——同一条链既可以逐步跑，也可以编译后跑。缓存（caching）复用上一次的结果；编译优化的是这一次怎么跑，不依赖历史。它和数据库里的查询计划（query plan）思路同源：SQL 也是先被优化器编译成执行计划再执行，而不是边解析边执行。
| 维度 | 逐步回放（解释式） | 编译式工作流 |
|---|---|---|
| 执行前 | 不做整图分析 | 先产出一份可执行计划 |
| 每步开销 | 调度、状态读写、路由判断 | 计划内步骤直接推进 |
| 灵活性 | 可随时改道 | 运行时才确定的分支需预留动态节点 |
| 可校验性 | 跑到才知道 | 跑前可做静态检查与成本预估 |
| 适合场景 | 探索性、路径不确定 | 路径稳定、重复执行、链路长 |
对从业者来说，编译式换来的是更少的重复调度与状态开销、更好的并行度，以及一份可审计、可预检的计划：出了问题先看“计划对不对”，而不只是回放日志。代价是灵活性——流程图一改就要重新编译，遇到没预料到的输入得留人工介入或动态分支作为应急通道。对普通使用者，直观感受是同类任务响应更快、更稳、批量跑更省；但当出现流程“没见过”的情况时，它不会像人那样随手改道。具体到某个框架支持到什么程度，以官方文档为准。