AI热榜 AI 工作流是一系列为完成某项任务而串联起来的步骤，其中一个或多个步骤包含对大语言模型（LLM）的调用。
在此，我们将这些步骤组合在一起的逻辑（包括步骤的顺序和分支）称为工作流的协调逻辑。
对于这些工作流的生产要求，与过去十年间任何长期运行的分布式系统相同：它们需要能够经受住部署和崩溃的考验，能够以幂等的方式重试，并实现水平扩展。
工作流引擎早在多年前就已经解决了这一类问题。
AI 工作流的独特之处在于，LLM 步骤的输出质量可能会随着每次提示词微调或模型变更而发生漂移。
因此，必须通过评估（即在标注数据集上离线运行工作流并对输出进行评分）来对其进行验证。
反过来，这又要求经典工作流引擎具备其设计时未曾考虑的功能：一个成本足够低、能够重复运行数百次的快速评估循环。
这两项要求是相互矛盾的。
生产环境的持久性需要一个重量级、分布式的持久化运行时环境；而评估迭代则需要一个轻量级、可在进程内运行的短暂循环，而且要能够在几秒钟内重新运行。
大多数技术栈都是围绕其中一种运行时环境构建的。
虽然持久性优先的运行时确实提供了测试环境，但它们需要为一个根本不需要这些组件的评估循环搭建沙箱、任务队列和测试服务器。
本文介绍了我们用来消除这种权衡的模式。
该模式源自 Brex 的 AI 工作流平台。
该平台采用 TypeScript 编写，由五名工程师组成的团队负责维护。
其工作进程运行在 Brex 的 Kubernetes 集群上，并连接到托管型 Temporal 服务 Temporal Cloud 来执行长期运行的代理。
代理通过 Vercel AI SDK 访问大语言模型（LLM）。
该 SDK 会将请求路由至内部 LLM 网关，该网关集中管理速率限制和身份验证。
评估则在我们的自建平台上运行。
生产环境稳定性与快速离线评估之间的权衡 让我们先从工作流引擎的功能说起。
持久化执行要求在执行下一步之前，必须将每一步的结果持久化存储。
如果流程发生崩溃、被重新部署，或者被重新调度到另一个工作节点上，引擎会回放历史记录，并从中断处精确地继续执行。
状态的存续时间超过任何单个进程。
这正是人们对一个深度研究代理的期望——该代理需运行一小时，期间会调用数十次大语言模型（LLM）并调用各类工具：绝不能因为一个 Pod 被回收而损失四十分钟的工作成果。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接