Apache Airflow 是一个开源的工作流编排平台，简单说就是「用代码写流水线，交给它自动跑」。数据工程师、机器学习工程师和 AI 应用团队用它把一串有依赖关系的任务组织成管道：平台负责按计划触发、按依赖顺序执行、失败自动重试，并用网页界面展示每一步的进度与日志。它不负责具体任务里的计算，只负责「调度与协调」——这是理解它的关键。
它不是小圈子项目。apache/airflow 是 Apache 软件基金会的顶级项目，GitHub 上拥有 46.7k star、17.7k fork、4,000 多名贡献者，约 500 家组织在官方名单上公开表明自己在使用，另有 1.9 万个仓库依赖它。最新稳定版 3.3.1 于 2026 年 8 月发布，上一代 2.x 线已于 2026 年 4 月停止维护（EOL）。
它解决什么问题
单机定时任务（如 cron）在任务数量少、依赖简单时够用，一旦任务变多、依赖变复杂、需要跨系统协同，纯脚本就管不住了：谁先谁后、失败了怎么重试、跑到哪一步了，全都靠人脑记。Airflow 把「任务以及任务之间的依赖关系」抽象成一张有向无环图（DAG），可以理解为一张任务路线图：每个节点是一次任务，连线表示先后或依赖关系，图中不允许出现循环。调度器（Scheduler）按这张图驱动执行，一个任务只有等它依赖的前置任务全部成功后才会启动，失败则按设定重试。
核心概念（白话版）
- DAG：任务与依赖关系的路线图，用 Python 代码定义，肉眼可读、可评审。
- Operator：一个具体的动作，比如「执行一段 SQL」「调用一个 HTTP 接口」「跑一个 Python 函数」。Airflow 内置大量常用 Operator，也可以自己写。
- 调度器与 Worker：调度器负责按图分配任务，Worker 是实际执行任务的机器，可以是一台，也可以是一组集群。
- XCom：任务之间传递小数据的机制（如把上一个任务算出的参数传给下一个）。大流量数据官方不建议在任务间搬运，应交给专门的数据系统。
用代码定义管道的好处
Airflow 把「管道即代码（workflow as code）」作为核心主张：工作流用 Python 写出来后，可以进版本控制、可以写测试、可以走代码评审，像管理普通软件一样管理数据管道。官方总结了三条设计原则：Dynamic（支持动态生成 DAG，比如按配置批量生成相似管道）、Extensible（可扩展，内置丰富 Operator 之外还能自定义）、Flexible（灵活，内置 Jinja 模板引擎，任务参数可以模板化）。
新角色：编排 AI 与 LLM 工作负载
官方 README 明确提到它的新方向：除了传统数据管道，Airflow 被广泛用于编排机器学习工作流——训练、重训、评估、部署；并且日益用于编排智能体（Agent）与 LLM（大语言模型）的工作负载：协调一条 AI 管线的数据准备、工具调用、模型调用、评估等步骤，而不是自己充当智能体。
一个典型场景：每日自动生成行业简报的 AI 应用，可以用 Airflow 串联「夜间拉取数据 → 清洗 → 调用大模型生成摘要 → 质量检查 → 发布」几个步骤，每一步都可重试、可监控、可追溯，出问题时能准确知道卡在哪一环。
适用边界
- 最适合结构相对固定、变化缓慢的工作流；需要频繁改动结构的不适合。
- 它不是流式处理平台，但常被用来把实时数据分批拉下来处理。
- 任务最好设计成幂等的——重复执行结果一致、不会产生重复数据。
- 生产环境官方只支持 Linux（官方 Docker 镜像基于 Debian Bookworm）；Windows 需通过 WSL2 运行。
- 安装官方支持 pip 与 uv；当前支持 Python 3.10-3.14、Kubernetes 1.30-1.35、PostgreSQL 14-18。
结论：Airflow 是把「任务编排」做成标准基础设施的开源平台。数据管道是它的老本行，AI 与 LLM 多步骤工作流是它正在快速渗透的新场景。如果你要管理的是一批「按依赖关系定时执行」的任务，它几乎是现成的答案，上手成本主要在于理解 DAG 和 Operator 这两个概念。