Mistral AI 于 4 月 29 日发布 Workflows,一款面向企业 AI 的编排层,目前作为 Studio 平台的一部分进入公开预览。该次发布瞄准了一个如今熟悉的缺口:AI 模型与 agent 越来越强,但把它们可靠地推到生产仍然困难,因为「协调、监控、恢复」这一层的基础设施一直是临时拼装的。Workflows 用 Python 定义,把模型、agent 与外部连接器组合成结构化的多步流程,并可通过 Le Chat 触发,执行过程在 Studio 中追踪与稽核。技术底座:Workflows 建在 Temporal 之上 —— 这是 Coinbase、Datadog、Snap 等公司用于实现持久化执行的开源 workflow-as-code 引擎 —— 并针对 AI 扩展了 streaming、payload 处理与增强的可观测性。
真正值得记住的架构选择,是控制面/数据面的分离。编排跑在 Mistral 托管的基础设施上;执行 worker 与数据处理则留在客户的环境内,无论是云、本地或混合。这一分离,正是那些「不能把数据交给第三方编排面、但又想要托管调度器」的企业的正确答案。这也是一项有意为之的竞争选择:AWS Bedrock、Google Vertex/Agents CLI、Anthropic 的 MCP 推动,各自都有编排叙事,但「数据留本地」的承诺,在「编排厂商即模型厂商」的情况下更难做。Mistral 是欧洲公司,这与该公司两年来一直在做的「欧盟数据主权」论点对接得很顺。功能层面:有状态执行(从故障点恢复)、不消耗算力即可暂停的 human-in-the-loop 检查点、重试策略、限流、tracing —— 编排的入门门槛,被打包好了。工程师 Prashanth Velidandi 给出了诚实的反应:「我们终于有了一个像样的编排层,但实操中,问题往往出在再下一层。把模型在不同 workload 下跑得稳、不浪费 GPU、能扛住真实流量,这些事还是一团乱麻。」
agent 编排市场正在迅速收敛。本届会话早些时候我们写过 Slack 的 coordinator/director/critic/timeline 架构 —— 作为工程参考公开发布的内部模式。我们写过 Google 的 Agents CLI —— 开源 CLI,与 Claude Code、Cursor、Gemini CLI 都打通。AWS 在同一周发布了 Bedrock Managed Agents。Anthropic 有 MCP 推动。如今 Mistral 把 Workflows 建在 Temporal 上。五种不同的方案,在解决同一个问题(多步 AI 流程会失败、要重试、需要人审批、需要可稽核),并且基本都在同一个月里发布。共同的收敛点是:每一种方案都在用「给 agent 提供确定性工具、运行多步流程、跨故障保留状态、允许人工介入」的某种变体。差异点会出现在区域(欧盟数据主权)、工具链(Temporal vs 自研)与分发渠道(Le Chat vs Bedrock vs Agents CLI)上。下面那一层 —— MCP 或近似等价物 —— 正在被标准化。
对 builders,三件具体事情。第一,如果你已经在用 Temporal 做非 AI 的 workflow,那 Mistral Workflows 就是「在其中加入 LLM 步骤」摩擦最小的迁移路径 —— 一样的执行语义、一样的 SDK 模式。如果你没在用 Temporal,那在押注前请同 Inngest、Restate、DBOS 比较一下。第二,「控制面/数据面分离」是你正在搭的任何企业级 AI 工具应有的架构 —— 编排属于 SaaS 表面,执行属于客户。即便你不在 Mistral 上出货,也复制这个模式。第三,「不消耗计算就能暂停、收到输入再恢复」的 human-in-the-loop 检查点,正是任何高风险 AI 工作流应该用的原语。绝大多数自家手写的编排代码这件事做得很差 —— 「暂停」往往意味着一个还在烧钱的轮询循环。Mistral 基于 Temporal 的暂停-恢复,是你应当对照实现的参考行为。