夜雨聆风管过服务器集群的人大概都有这个经历：
一开始就是几个Cron任务，配好时间，跑着跑着发现任务之间有依赖关系——A跑完才能跑B，B跑完C和D可以并行，C出错了要通知人，D成功了要触发部署。这些逻辑一开始用Shell粘着，粘着粘着就成了几百行的脚本，出了问题全靠人脑推理。
这时候有人提议"上Airflow吧"，然后你发现光部署就得好几台机器，PostgreSQL、Redis、Worker、Scheduler全得装。这个复杂度本身就已经超纲了。
这个开源工作流编排工具把这两件事都给解决了。
源代码地址：https://www.gitcc.com/juxian/dagu-cn
01 它是什么
这是一套Go语言实现的工作流调度引擎，核心设计理念是本地优先——一个二进制文件，不需要数据库，不需要消息队列，不需要Redis，装完就能跑。
工作流用YAML声明式定义 DAG 有向无环图，不需要写代码。你在配置文件里写清楚步骤、依赖关系、分支条件，调度、重试、日志、审批全部由引擎兜底。内置可视化Web看板，支持定时调度、失败重试、人工审批、并发控制。分布式多机扩展靠Workers横向扩容，单机跑不动了加机器，配置几行搞定。
02 它最厉害的地方
它做了什么？
把复杂工作流的编排这件事，从"运维大工程"变成了"写配置文件"。
传统方案里，Airflow、Prefect这类调度工具确实解决了编排问题，但代价是你要维护一整套基础设施：数据库存状态、消息队列传任务、Web服务展示界面、Worker执行任务。光这套系统的部署和运维，就得占掉一个人几天的工作量。
该系统的做法是：把所有这些全部砍掉，把状态存在本地文件里，把调度逻辑塞进一个二进制文件里，用YAML描述工作流。你要做的，就是在YAML里写清楚"先做什么，再做什么，失败怎么办，有人要审批吗"。剩下的事情它全部兜底。
你得到什么？
最直接的改变：一个脚本改半天变成改一个YAML文件。
你写了一个ETL流程，数据抽取、转换、入库三步，每步之间有依赖，中间某步失败了要重试，失败了要通知人。传统做法是写Shell脚本，里面嵌套一堆判断逻辑，出问题了很难定位是哪一步卡住。用它的YAML定义，三行配一个步骤，depends配依赖关系，retry_policy配失败重试，handler_on.failure配通知脚本。运行的时候Web界面直接看到每一步的实时日志，哪一步失败了、跑了多久、输出了什么，一目了然。
分支条件处理也很干净。不是在脚本里写if [ $? -eq 0 ]; then ... fi，是在YAML里用condition: step.ok或者condition: step.err，成功走一条路径，失败走另一条路径，配置比Shell脚本清晰得多。
人工审批节点是它很实用的一个细节。你可以在流程中途插入一个"暂停"——流程跑到审批节点就停下来，等有人在Web界面点确认，才继续往下执行。适合发布流程、数据库变更这类需要人二次确认的操作，不是自动一路跑到底，而是中间有人把关。
还有一个对AI时代很有意义的能力——原生MCP协议支持。它内置了MCP服务器，Claude Code或者其他MCP客户端可以直接调用它的接口，读工作流状态、修改配置、触发运行、重跑失败任务。这意味着你可以让AI帮你管运维流水线：哪个流程失败了，AI读了日志，分析原因，然后帮你重跑或者修改步骤——不需要人登录服务器手动操作。
03 适合谁用
比如你有服务器需要定期跑运维任务，但不想部署Airflow那么重的系统。Cron加零散脚本跑久了，维护成本越来越高——任务之间有依赖，失败了没日志，没重试，不知道卡在哪一步。该系统给你一个轻量级的替代方案，一个二进制文件装完，YAML配好，定时调度、可视化日志、失败重试全有了。
比如你在做AI应用的研发流程，需要让AI Agent能够读写和触发运维流水线。Claude Code或者其他AI编程工具通过MCP协议直接对接它，AI能够读取流程状态、判断失败原因、触发重跑，整个运维闭环可以在对话里完成，不需要切到终端。
04 为什么是现在
大模型在编程领域的渗透越来越深，AI Agent已经可以帮你写代码、跑测试、甚至改部署脚本。但这些能力需要一个前提：你的运维流水线得是AI能读、能写、能触发的。传统Cron加Shell脚本，AI根本进不去。
MCP协议在这两年逐步成为AI Agent调用外部工具的标准。它第一个把这个协议内置进调度引擎里——不是后来打补丁，是从一开始就把AI调度能力做进了核心架构。
一个单二进制文件的DAG工作流调度引擎，YAML定义任务，支持AI Agent通过MCP协议读写流水线。
源代码地址：https://www.gitcc.com/juxian/dagu-cn