Conductor 工作流引擎
以持久执行编排微服务、AI 智能体和长时间运行的工作流。
证据展示了只读 CI 内容权限、GitHub Secrets 注入、安全漏洞报告渠道、可检查的工作流输入输出，以及重试、重跑和从指定任务恢复等完善的回滚能力。扣分在于产品明确允许 worker 执行任意代码和 I/O、MCP 工具调用与运行时生成工作流，却未展示统一的最小权限沙箱、外部副作用确认策略或敏感字段屏蔽规则；人工审批仅作为能力宣称，示例中的自主代理可直接调用工具。依赖方面有 Gradle wrapper 校验、冻结的 pnpm 锁文件和受支持版本政策，但 requirements.txt 未锁版本、Actions 使用可移动版本标签，且远程安装脚本直接交给 shell。来源叙述指向 Netflix、Conductor OSS 和 Orkes，但主要来自项目自身陈述，发布者身份仍属未知。
README、CI 和耐久性演示在持久化、重启恢复、任务状态及多后端支持方面基本一致；CI 包含单元、测试工具、多个 E2E 后端和定时全量路径。扣分在于未执行这些路径，常规构建明确排除测试，PR 的部分持久化测试按改动跳过，部分后端被禁用或标为支持不完整；外部 LLM、MCP、数据库和消息系统仍会形成可用性依赖。脚本和 CI 提供了健康检查超时、未知配置、失败任务及日志位置等有用错误信息，但没有证据表明整个产品具有统一、结构化且可操作的错误体系。
材料清楚覆盖微服务、AI 代理、长流程、人工等待、动态分支以及多语言 worker 等受众和场景，并列出多种数据库、消息系统、本地 JVM、Docker 和开发 UI 配置，因此场景覆盖与环境适配证据充分。扣分在于能力边界多以营销式肯定表达，对不支持的组合、资源上限及安全边界说明较少；触发与路由通过显式 JSON 任务图、条件和输入参数表达，具有较好精度，但自主示例依赖 LLM 返回符合约定的 JSON，未展示模式校验失败、未知工具或循环上限的防护。
README 的快速开始、构建说明、SDK 表、后端配置、FAQ、贡献、安全政策、路线图和许可证组织完整，安装前置条件及常见重复创建错误也有说明。Apache-2.0 全文与元数据一致，故许可证满分。扣分在于命名分布于 conductor-oss 与 io-orkes 包名，UI 又有 ui 与 ui-next；已知限制只零散出现在孵化 SDK、Cassandra 部分支持和支持版本表中。发布徽章、工作流定义版本和路线图提供更新路径，但所给材料没有实际变更日志；Orkes 被声明为主要维护者并提供 issue、社区和安全渠道，不过该责任归属没有独立验证。
声明式 JSON、可视化 UI、API、CLI、任务级输入输出和恢复操作使产物总体可操作；耐久执行、跨语言 worker、动态组合及多种持久化后端相对简单代理循环提供明显附加价值。扣分在于没有静态证据量化部署资源、运维复杂度、LLM 调用费用或大规模场景的实际收益，且快速开始仍需 Java、Node、容器或多项外部服务。示例输出可用于演示和调试，但没有展示生产级输出模式、质量约束或消费方契约的完整覆盖。
部分主张可追溯到具体配置和实现：CI 定义测试矩阵，耐久演示明确执行持久化、强制终止和恢复流程，LICENSE 与 SECURITY 文件支持许可和维护政策。扣分在于互联网规模、数十亿执行、知名企业采用、14+ LLM 提供商、完全兼容和确定性保证等强主张在所给文件中主要由 README 重复陈述，缺少独立或更底层证据。事实、架构推论和比较性营销语言常混在一起，例如将演示结果推广为普遍保证，因此事实与推断分离较弱。
- 自主工作流可调用任意 MCP 工具或 worker I/O；部署前应增加工具白名单、网络出口限制、身份分离、参数校验和高影响操作的人工确认。
- 不要直接在高信任环境中执行 README 的远程 curl-to-shell 安装命令；应先固定版本、下载并审查脚本、校验完整性。
- 应审查 debug-docker-credentials 工作流：它会输出 Docker Hub 账户资料和失败响应，可能向 CI 日志暴露不必要的身份或响应数据。
- 互联网规模、企业采用、完全兼容及 14+ 提供商等主张在本次材料中未获得独立验证；本评估也未执行构建、测试或耐久性演示。
- 生产采用前需确认密钥与工作流输入输出的加密、日志脱敏、保留期限、租户隔离和删除策略；所给文件未充分说明这些控制。
这个 Agent 能做什么，适合哪些场景？
Conductor 是一个由 Netflix 创建、现由 Orkes 和社区维护的开源持久化工作流引擎，用于编排微服务、AI 智能体及其他分布式流程。工作流以声明式 JSON 图定义，业务逻辑则由 Java、Python、Go、JavaScript、C#、Ruby 或 Rust worker 执行。引擎持久化每个步骤，并提供重试、超时、从指定任务重跑以及失败步骤重试能力，从而让流程在崩溃、重启或网络故障后继续运行。其 AI 编排功能包括 14 个以上的 LLM 提供商、MCP 工具发现与调用、函数调用、人工审批以及用于 RAG 的向量数据库集成。用户可以通过 CLI、HTTP API、内置 UI 或各语言 SDK 操作工作流，并在 JVM 或 Docker 环境中自行部署。它适合需要可观察、可版本化和可恢复执行的团队，但采用者需要运行 Conductor 服务，并接受 JSON 编排与外部 worker 分离的架构。
用户先以 JSON 定义工作流及任务，然后通过 conductor workflow create workflow.json 注册定义，并用 conductor workflow start -w hello_workflow --sync 启动执行。Conductor 读取工作流输入，解析任务图，并调度内置任务或外部 worker；worker 轮询任务、运行任意业务代码，再回报结果。流程可使用 SWITCH 分支、DO_WHILE 循环、FORK_JOIN 动态并行、SUB_WORKFLOW 组合和运行时解析的 DYNAMIC 任务。智能体流程还能通过 LIST_MCP_TOOLS 发现 MCP 工具，以 LLM_CHAT_COMPLETE 调用模型，再通过 CALL_MCP_TOOL 执行所选工具。引擎会保存每一步的输入、输出、状态、时间和重试历史，最终产生持久化的工作流执行记录及任务输出；用户可在 API 或 UI 中检查、重启、局部重跑或重试这些执行。
- 负责分布式系统的平台团队需要协调多个微服务，并希望在网络故障或服务重启后自动恢复流程。
- 构建自主智能体的 AI 团队需要组合 LLM 推理、MCP 工具发现与调用、循环执行和人工审批。
- 处理订单、审批或其他跨天流程的应用团队需要等待外部信号、定时器或人工操作数周乃至数月。
- 维护批量处理或动态扇出任务的数据与运营团队需要在运行时决定并行任务数量，并只重试失败步骤。
- 拥有多语言服务的企业需要让 Java、Python、Go、JavaScript、C#、Ruby 或 Rust worker 参与同一编排流程。
- 希望自行托管且避免单一存储或消息系统绑定的组织，需要可在 Docker 或 JVM 上运行的 Apache 2.0 工作流引擎。
这个 Agent 有哪些优点和局限？
- 每个步骤都会持久化，并支持可配置的重试、超时、失败步骤重试和从指定任务重跑，适合故障频繁或长时间运行的流程。
- 声明式工作流与业务代码分离，使编排图天然确定；worker 仍可使用任意语言、库、I/O 或 API。
- 原生覆盖 14 个以上的 LLM 提供商，并提供 MCP 工具调用、函数调用、人工审批和向量数据库集成。
- 支持动态分支、循环、并行扇出、子工作流和运行时任务解析，同时保留可观察的执行历史。
- Apache 2.0 自托管方案支持 5 种持久化后端、6 种消息代理，并可在 Docker 或 JVM 环境运行。
- 提供 7 种语言的 worker SDK 路径，其中 Java、Python、JavaScript、Go 和 C# 有明确安装方式。
- 快速启动同时依赖 Node.js 16+ 和 Java 21+；源码构建还需要 Docker Desktop、Node.js 18+ 与 pnpm。
- 采用声明式 JSON 编排意味着团队必须维护工作流定义，并让业务代码通过独立 worker 与引擎交互。
- 生产部署需要自行选择和运营持久化后端、消息代理及 Conductor 服务，增加基础设施与升级责任。
- Ruby 和 Rust SDK 被标为 incubating，不宜假设其成熟度与 Java、Python 等 SDK 相同。
- LLM、MCP、向量数据库或外部 API 工作流仍依赖对应网络服务、配置和凭据；仓库没有给出统一的凭据方案。
- README 宣称可横向扩展到数十亿次执行，但未提供本资料范围内可复现的基准数据或具体容量规划方法。
如何安装或部署这个 Agent？
快速启动要求安装 Node.js 16+ 和 Java 21+：
npm install -g @conductor-oss/conductor-cli
conductor server start随后打开 http://localhost:8080 使用内置 ui-next。也可通过 Docker 启动，UI 位于 5000 端口、API 位于 8080 端口：
docker run -p 5000:5000 -p 8080:8080 conductoross/conductor:next若从源码构建，则还需要 Docker Desktop、Java 21+、Node.js 18+ 和 pnpm：
git clone https://github.com/conductor-oss/conductor
cd conductor
./gradlew build
cd server
../gradlew bootRun这些本地启动步骤未要求 API 凭据；若工作流调用 LLM、MCP 服务或其他外部 API，则相应服务的地址与凭据取决于所配置的集成。
如何使用这个 Agent？
创建并运行首个无需 worker 的示例工作流：
curl -s https://raw.githubusercontent.com/conductor-oss/conductor/main/docs/quickstart/workflow.json -o workflow.json
conductor workflow create workflow.json
conductor workflow start -w hello_workflow --sync重复执行 workflow create 会因定义已存在而报错；修改现有定义应使用 conductor workflow update。实际项目可把任务定义为外部 worker，或使用 LLM_CHAT_COMPLETE、LIST_MCP_TOOLS、CALL_MCP_TOOL 等内置任务。所有 CLI 操作都有对应的 cURL/API 调用，执行状态和各任务的输入、输出、耗时及重试历史也可在内置 UI 中查看。
这个 Agent 与同类方案有什么区别？
与把工作流定义和业务逻辑放在同一运行时、依靠重放代码恢复状态的 code-first 引擎相比，Conductor 将编排图保存为声明式 JSON，并让 worker 保持普通应用代码。这减少了 worker 对确定性编程规则的依赖，也允许不重新部署 worker 就更新或版本化编排；代价是团队需要管理独立的工作流定义、Conductor 服务及 worker 通信边界。资料没有点名具体竞品，因此不能据此作逐产品的功能或性能比较。