生产要持久、评估要轻量——把编排从运行时里拆出来

两个要求，方向相反

AI 工作流是一串步骤，其中一步或多步会调用大模型。对它的生产要求，和过去十年任何长期运行的分布式系统没有区别：扛得住部署与崩溃、能幂等重试、能水平扩展。工作流引擎多年前就解决了这类问题。

AI 工作流独有的那一半是：LLM 步骤的输出质量会随每次提示词微调或模型变更而漂移，所以必须靠评估来验证——在标注数据集上离线跑一遍并打分。

于是引擎需要一个它当初没为之设计的能力：便宜到能重复跑几百次的快速评估循环。

这两个要求互相矛盾：

• 持久化执行要求每一步结果先落盘再走下一步，崩溃或重新调度后能回放历史、从中断处继续。状态活得比任何单个进程都久。一个跑一小时、调用几十次模型的深度研究智能体，不能因为一个 Pod 被回收就损失四十分钟。
• 评估迭代是局部的、进程内的、短暂的。你改一行提示词，加载几百个样本，看汇总分数。它不该在集群范围内持久化或调度任何东西，运行结束后什么都不该留下。

把评估代码塞进工作流引擎，你会继承持久化、任务队列、工作进程和回放语义——全是这个紧凑循环不需要的开销。反过来把生产代码塞进评估框架，则拿不到那个一小时智能体依赖的任何持久性保证。

为什么大多数技术栈逼你二选一

因为主流工具把编排和运行时耦合在一起。

LangGraph、Mastra 这类框架在自己的 SDK 里直接表达编排逻辑：你的控制流被翻译成图的节点与边，或者框架提供的 DSL。编排逻辑和框架本身是同一个东西。 要评估这段逻辑就得运行框架，要部署它也得运行框架——不存在独立于框架的编排。

这条判据可以直接搬走

不管你用不用他们的方案，有一个问题值得对着自己的技术栈问一遍：

我的编排逻辑，能不能脱离运行时单独存在？

如果不能，那么「换运行时」和「重写业务逻辑」就是同一件事，而评估循环的成本会被运行时的重量绑架。

这与本站《系统设计的权衡》里那条判据同构：每一层抽象都是拿控制换省事，而框架把编排收进 DSL，换走的正是「在别处运行同一段逻辑」这个控制权。

平台本身的规模，说明这不是玩具也不是大厂特例

• TypeScript，五名工程师维护
• 工作进程跑在 Kubernetes 上，接托管的 Temporal Cloud 执行长期运行的智能体
• 通过 Vercel AI SDK 访问模型，请求路由到内部 LLM 网关集中做限流与鉴权
• 评估跑在自建平台上

五个人这个数字值得留意：它说明这个模式的实现成本，在一个中等规模团队的承受范围内。