Dagu 本地优先声明式工作流作业

要解决的问题

现有的自动化往往散落在各处：一个 shell 脚本、一个 Python 任务、几条 SSH 命令、一个 SQL 作业，彼此之间没有统一的调度和可见性。一旦某个环节失败，工程师只能翻服务器上的日志，靠 grep 和经验判断哪里断了，重试逻辑也常常是各自实现的。

Dagu 要解决的就是这件事：把已有的自动化收拢成一组声明式工作流作业。你不用换掉现有脚本，也不需要引入重量级编排器，而是用 YAML 描述任务之间的依赖关系，让 Dagu 替你调度、重试、记录日志和产物。

技能如何工作

核心能力可以归纳为三点：

• 文件即工作流：整个工作流由 YAML 文件定义，结构紧凑，可以放进代码仓库做版本管理。
• 复用已有资产：shell 脚本、Python 脚本、容器、SSH 命令、SQL 作业、HTTP 调用、AI 框架和可重用的 action 包都能直接被引用，不必重写。
• 轻量级操作界面：通过 Web UI 查看运行详情、步骤日志和文档，失败时聚焦到具体一步，而不是在一堆散落日志里找线索。

典型的上手路径是：先看 examples 目录了解工作流如何定义，再对照 YAML 结构和 action: / actions: 语法的仓库级映射，最后把自己已有的任务逐步搬进 Dagu。迁移是渐进的，不需要一次性推翻现有体系。

适用边界与注意点

Dagu 默认自托管，状态存储在本地文件中，没有外部依赖，但也意味着它能跑到什么程度取决于你的机器和工作负载：

• CPU、磁盘速度、工作流持续时间都会影响表现。
• 队列配置和 worker 容量需要你自己评估和调整。
• 官方文档位于 docs.dagu.sh/oss，遇到细节问题建议直接查上游文档。

换句话说，这个技能适合中小规模的本地优先场景，而不是无上限的水平扩展场景。如果你的自动化已经在多台机器上跑得很复杂，先想清楚 worker 容量和状态文件的可靠性，再决定是否整体迁移。