Conductor：Netflix 出品的智能体工作流引擎

图1：Conductor 项目标志

当你的 AI 程序突然崩溃，能不能自动从断点恢复？

这是一个真实场景：某公司的 AI 客服系统正在处理 1000 个用户请求，突然数据库连接超时，导致正在执行到第 537 号请求的 AI agent 直接崩溃。如果没有一个靠谱的工作流引擎，这意味着从第 537 号开始，500 多条用户请求将永远石沉大海，工程师半夜爬起来手动重启，数据丢失，客服体验大打折扣。

Conductor 解决的就是这个问题。它最初由 Netflix 在 2016 年内部开发，用于解决微服务编排的复杂性，后来开源并演进为 AI Agent 工作流引擎的核心基础设施，如今在 Netflix、Tesla、LinkedIn、J.P. Morgan 等顶级公司的生产环境中运行，每天处理数百万次工作流执行。

图2：Conductor 架构概览，支持多语言 SDK 客户端连接

背景：为什么 Netflix 需要自己造轮子？

在 Conductor 诞生之前，Netflix 内部的微服务编排主要依赖chronos+ossync的模式，即通过异步队列来串联服务。但随着业务复杂度增长，这种方式的弊端显现：缺乏集中式的流程可视化，服务间的依赖关系像一团乱麻；故障恢复靠人工排查，一个环节出问题可能导致整个链路卡死；状态管理分散，出了问题无法精确追溯。

Netflix 工程师决定自己动手，写了一个专门的工作流引擎，将「流程编排」和「业务逻辑」彻底解耦——流程定义用 JSON 描述，具体的任务实现由各个 Worker 独立完成，双方通过 REST API 通信。2016 年，Netflix 将 Conductor 开源，随后在 2024 年将项目移交给独立的开源基金会 conductor-oss 运营，Orkes 公司提供商业支持。

项目 GitHub 目前已有超过 3.1 万颗星，是工作流引擎领域最受欢迎的开源项目之一。

核心概念：三句话讲清楚 Conductor 是怎么工作的

第一，工作流即代码，也即配置。 与 Temporal 等代码优先的引擎不同，Conductor 的工作流通过 JSON/YAML 定义，包含了任务序列、条件分支、超时策略、重试规则等完整信息。这意味着非工程师也可以通过 UI 或 API 理解和修改业务流程，降低了协作门槛。

第二，每个任务由独立的 Worker 执行。 Worker 是一个长期运行的进程，通过轮询 Conductor 服务器来领取任务、执行逻辑、汇报结果。Worker 与服务器之间通过 REST 或 gRPC 通信，完全松耦合，可以用任意语言实现（官方提供 Java、Python、JavaScript、Go、C# SDK，Ruby 和 Rust 正在孵化中）。

第三，状态持久化，容错无忧。 所有工作流状态存储在数据库（支持 Redis+Elasticsearch、Cassandra、PostgreSQL、MySQL 等多种后端），即使服务重启，也能从断点恢复，不丢一条记录。这种「持久化执行」能力，是 Conductor 与普通消息队列编排方案的本质区别。

AI Agent 原生支持：Conductor 的杀手级特性

近年来 Conductor 最重要的演进，是将 AI Agent 支持作为一等公民。项目的 ai 模块原生集成了 14+ 主流大模型提供商：OpenAI GPT-4o/4o-mini/DALL-E、Sora、Anthropic Claude 3.5/4 系列、Google Gemini 2.5、AWS Bedrock、Azure OpenAI、Mistral、Cohere、Grok、Perplexity、HuggingFace、Ollama（本地部署）、Stability AI，覆盖聊天、嵌入、图片生成、音视频合成、文档生成等多种模态。

同时还支持 MCP（Model Context Protocol）工具调用，允许 AI Agent 在工作流中动态调用外部工具，实现类似 Claude Code/Gemini CLI 中的 Agent 能力。更重要的是，所有 AI 任务都是持久化执行的——如果 AI 模型响应超时，Conductor 可以自动重试，不必担心任务被吞掉。

Conductor 还支持向量数据库集成（Pinecone、Weaviate、Chroma、Milvus、Qdrant、Redis、Elasticsearch），让 RAG（检索增强生成）场景下的工作流编排变得轻而易举——定义工作流时直接引用向量搜索任务，检索结果自动注入下游 LLM 任务的上下文中。

部署体验：10 分钟跑起来

Conductor 提供了开箱即用的 Docker Compose 配置，一条命令启动完整服务栈：Conductor 服务器、Redis（任务队列）、Elasticsearch（工作流索引）、Web UI。默认配置下只需 4GB 内存即可运行，门槛非常低。

图3：Conductor Web UI

对于有 Java 21+ 环境的用户，官方提供了 conductor_server.sh 单脚本启动模式，脚本会自动下载最新 JAR 包并启动服务，无需 Docker。如果你已经有 Gradle 构建环境，也可以从源码 server/ 或 server-lite/ 目录直接构建。

SDK 生态：多语言覆盖

Conductor 的客户端 SDK 生态相当完善，覆盖了主流语言：Java（最成熟，Maven 中央仓库直接引入）、Python（pip 安装，异步支持）、JavaScript/TypeScript（npm 包）、Go、C#（.NET）、Ruby（孵化中）和 Rust（孵化中）。SDK 之间功能对齐较好，基本覆盖了工作流定义、启动、查询、事件订阅等核心操作。

此外，官方还推出了 Conductor Skills 工具集，允许 Claude Code、Gemini CLI 等 AI 编程助手直接在终端里创建、部署和管理 Conductor 工作流——这意味着你甚至可以让 AI 来帮你编排 AI 的工作流程。

局限与挑战

尽管功能强大，Conductor 也有一些需要注意的地方。首先，Java 21 是唯一官方支持的 JDK 版本，如果你的团队还在用 Java 11/17，需要先升级 JDK。其次，工作流 JSON 定义虽然灵活，但对于习惯了代码即流程的开发者（比如 Temporal 用户）来说，可能需要一定时间适应 JSON 配置的思维方式。第三，K8s 部署虽然可行（官方案例中有 Cassandra+ES7 的 K8s 配置），但没有官方的 Helm Chart，需要自行适配。

行业意义：工作流引擎的新范式

Conductor 代表了一种新兴的工作流编排思路：声明式流程 + 持久化执行 + 多语言 Worker。与 Airflow（批处理 DAG）、Temporal（代码优先的持久化 WF）、AWS Step Functions（云绑定）相比，Conductor 在「可视化 + 可配置 + AI 原生」三者的交叉点上找到了独特定位。

在 AI Agent 快速普及的当下，Conductor 的「AI 任务即 Worker」理念非常有吸引力——你可以把 LLM 调用当作普通任务放到工作流里，配合重试、超时、人机确认等机制，让 AI Agent 的执行变得可控可观测。随着 Orkes（商业公司）的持续投入和开源社区的活跃，Conductor 有望成为 AI Agent 生产化部署的标准底座之一。