Agent 的 DAG 调度模式：从理论框架到框架实现

横向可视图：多 Agent 协作 DAG 与核心调度服务

                          ┌──────────────────────────────────────────────┐
                          │          核心调度服务（控制平面）              │
                          │  图管理 │ 状态机 │ 入度就绪 │ 资源预算 │ 失败回退 │
                          │  上下文 │ 并发控制 │ 无环校验 │ 可观测 │ 终止条件 │
                          └──────────────────────────────────────────────┘
                                          ▲               │
                          提交DAG/申请扩展 │               │ 调度指令
                                          │               ▼
用户请求 ─▶ 接收Agent ─▶ 规划Agent ─┬─▶ 检索Agent ──┐
                                    ├─▶ 记忆Agent ──┼─▶ 推理Agent ──┐
                                    └─▶ 工具Agent ──┘                ├─▶ 验证Agent ─▶ 汇总Agent ─▶ 输出Agent
                                              │                      │
                                              └────▶ 代码Agent ──────┘

这张图里：接收 Agent 先解析请求；规划 Agent 拆解任务；之后检索、记忆、工具三个 Agent 可以并行；检索和记忆的结果汇入推理 Agent；工具 Agent 的结果既供推理，也供代码 Agent；推理和代码都完成后，验证 Agent 才启动；验证通过后，汇总 Agent 生成结果，输出 Agent 负责最终返回。

它有分叉、有并行、有汇合，不是直线图。直线链只是 DAG 最特殊、最简单的一种形态。整张图的背后有一个核心调度服务在统一管控：谁先跑、谁等谁、谁能并行、预算给谁、失败了怎么办、什么时候终止。

Agent 的 DAG 调度模式，一句话：把每个 Agent 当作节点，把 Agent 之间的依赖、数据流、控制流当作有向边，调度器按有向无环图触发 Agent——上游 Agent 完成后，下游 Agent 才允许执行；没有依赖的 Agent 可以并行跑。

DAG = Directed Acyclic Graph，有向无环图。

一、为什么 Agent 需要 DAG 调度

2024 年，很多团队构建 AI 应用的方式还是“把几个 LLM 调用串起来”。到 2025 年，这种模式在生产环境中遇到了严重问题：死锁、状态损坏、静默失败、成本失控。一项针对多 Agent 系统可靠性的分析发现，主要失败类别包括：LLM 产出了语法正确但逻辑错误的工具调用参数、一个 Agent 写入错误状态后下游 Agent 继承并放大错误、Agent A 等待 B 而 B 等待 A 导致死锁且没有超时触发、缺少预算约束的 Agent 无限重试昂贵的 LLM 调用、Agent 进程崩溃后没有检查点导致整个作业重新开始。

这些问题无法通过 prompt engineering 解决，它们需要结构性的方案——这正是 DAG 调度提供的。

Gartner 预测到 2026 年底，40% 的企业应用将包含任务特定的 AI Agent，而 2025 年这一比例还不到 5%。在这个规模下，临时的 Agent 协调方式不可行。

单个 Agent 做复杂任务时，容易出现几个问题：

上下文太长，什么都塞给一个模型，成本和延迟都高。
职责混乱，既要规划，又要检索，又要写代码，又要验证。
不可观测，出错后不知道卡在哪一步。
不好恢复，中间失败往往只能从头再来。
不好并行，本来可以同时查资料、查记忆、调工具，却只能串行。

多 Agent 分工后，就需要一个调度模式来回答：谁先执行？谁依赖谁？谁能并行？上游失败后下游怎么办？上下文和中间结果怎么传递？谁来统一管控全局？DAG 调度就是其中一种很自然的答案。

二、DAG 到底是什么

DAG 由四个关键点组成：

节点：一个 Agent、任务或作业步骤。
边：Agent 之间的依赖关系，比如 A 完成后才能做 B。
方向：表示执行先后顺序。
无环：不能出现 A → B → C → A 这种循环依赖，否则永远无法确定谁先执行，会死锁。

注意：DAG 是图结构，不是直线结构。它可以有多个根节点、多个分支、多个汇合点。上图中的检索、记忆、工具是并行分支；推理和代码是中间汇合点；验证是总汇合点。

另外要注意：Agent 内部可以有循环，比如 ReAct 式的“思考—行动—观察”循环；但 Agent 之间的编排图必须无环。这两件事不矛盾。

三、DAG 调度的核心规则

DAG 调度器通常围绕“入度”工作：

入度：一个任务有多少个前置依赖。
入度为 0：没有前置依赖，可以立刻执行。
上游任务成功：把下游任务的入度减 1。
下游任务入度变成 0：进入就绪队列，等待调度执行。
所有任务完成，或者按失败策略终止。

简单说：

谁没有前置依赖，谁就先跑；
谁的上游都完成了，谁才被解锁；
彼此没有依赖的任务，可以并行。

横向流程可以表示为：

提交 Agent DAG ─▶ 解析依赖 ─▶ 计算入度 ─▶ 就绪队列 ─▶ 分配模型/工具 ─▶ Agent执行 ─▶ 解锁下游 ─▶ 全部完成
                                      ▲                                        │
                                      └──────────── 入度减 1 ◀──────────────────┘

四、一个稍复杂的执行例子

还是用开头的图：

用户请求
   │
   ▼
接收Agent ──▶ 规划Agent ──┬──▶ 检索Agent ──┐
                          ├──▶ 记忆Agent ──┼──▶ 推理Agent ──┐
                          └──▶ 工具Agent ──┘                ├──▶ 验证Agent ──▶ 汇总Agent ──▶ 输出Agent
                                    │                       │
                                    └────▶ 代码Agent ───────┘

执行顺序大致是：

接收 Agent 解析用户请求，提取目标、约束和输出格式。
规划 Agent 制定计划，生成或补全下游 Agent 子图。
检索 Agent、记忆 Agent、工具 Agent 并行执行。
检索和记忆的结果汇入推理 Agent，形成初步判断。
工具结果同时进入代码 Agent，代码 Agent 生成代码或执行脚本。
推理 Agent 和代码 Agent 都完成后，验证 Agent 启动。
验证通过后，汇总 Agent 整合证据、代码、结论，生成最终回答。
输出 Agent 做格式化、敏感信息检查、发送或落库。

如果中间某个 Agent 失败，调度器可以按配置处理：自动重试、换一个模型或换一个 Agent、跳过非关键分支、阻塞下游并告警、请求人工确认、回滚或终止整个 DAG。

五、关键问题：图是提前规划好的，还是边跑边生成？

这是理解 Agent DAG 调度最关键的问题之一。答案不是二选一，而是：两种模式都存在，实际系统通常是“静态骨架 + 动态扩展”的混合模式。

模式	图什么时候确定	谁决定	典型场景
静态 DAG	执行前一次性规划好	规划 Agent 或人工配置	流程固定、步骤可枚举
动态 DAG	执行中逐步生成	每个 Agent 运行时决定	开放式研究、复杂排障
混合模式	骨架静态 + 局部动态	规划 Agent 定骨架，执行 Agent 动态扩展	大多数生产级多 Agent 系统

5.1 静态 DAG：规划 Agent 一开始就规划好

规划 Agent 接收用户请求后，一次性输出完整的 Agent 调用图。调度器拿到这张图后，按标准 DAG 调度流程执行。

优点： 调度简单，可预测、可审计、可回放，容易做超时、预算、SLA 控制。
问题： 规划 Agent 必须“未卜先知”，一旦某步结果出乎意料，整张图可能失效。

5.2 动态 DAG：边跑边生成

规划 Agent 不一次性规划整张图，只决定当前这一步做什么。每个 Agent 执行完后，根据结果决定下一步调用谁。

用户请求 ─▶ 规划Agent ─▶ 执行Agent1 ─▶ 观察结果 ─▶ 规划Agent ─▶ 执行Agent2 ─▶ 观察结果 ─▶ ...
                  ▲                                    │
                  └────────────────────────────────────┘

优点： 灵活，能应对开放式、不确定任务。
问题： 调度器复杂，难以全局优化并行度，容易跑偏、发散、成本失控。

5.3 混合模式：静态骨架 + 动态扩展

这是生产系统里最常见的做法。规划 Agent 先给出一个高层骨架，只固定关键阶段和关键依赖；具体子步骤由各阶段 Agent 运行时动态展开。

接收 ─▶ 规划 ─▶ 检索 ─▶ 推理 ─▶ 验证 ─▶ 输出

这是静态骨架，五阶段固定。但检索阶段内部可以动态决定调几个检索源；推理阶段内部可以动态决定要不要调代码 Agent；验证阶段内部可以动态决定验证几轮、要不要回退到推理。

这其实是层级调度：外层静态骨架 DAG 调度，内层每个阶段内部动态子 DAG 调度。

六、核心调度服务：DAG 调度的控制平面

DAG 调度必须有一个核心调度服务来把握全局。更准确地说：需要一个调度控制平面。它不一定是一个独立微服务，也可以是一个库、引擎或运行时，但逻辑上一定要有这么一个“大脑”。

规划Agent / 各执行Agent
        │
        │ 提交DAG、申请扩展节点、上报结果
        ▼
┌──────────────────────────────────────────────┐
│              核心调度服务（控制平面）           │
│  图管理 │ 状态机 │ 入度就绪 │ 资源预算 │ 失败回退 │
│  上下文 │ 并发控制 │ 无环校验 │ 可观测 │ 终止条件 │
└──────────────────────────────────────────────┘
        │
        │ 调度指令
        ▼
┌──────────────────────────────────────────────┐
│           执行运行时（数据平面）               │
│   Agent实例 │ 模型调用 │ 工具调用 │ 沙箱 │ API  │
└──────────────────────────────────────────────┘

6.1 核心调度服务管什么

图管理：保存 DAG 的节点、边、依赖、版本；校验无环；支持动态扩展和子图回退。

状态管理：每个 Agent 节点维护状态：

pending → ready → running → success
                    │
                    ├→ failed → retry / replace / skip / block
                    └→ timeout → 终止或人工介入

入度与就绪判定：

上游全部 success → 当前节点入度归零 → 进入就绪队列 → 等待调度

调度决策：优先级、并发度、资源分配（模型、工具、token 预算）、限流、亲和性。

上下文与数据流：上游输出怎么给下游，是共享状态、消息传递，还是黑板模式；上下文太长时怎么摘要压缩；中间结果怎么持久化。

失败处理：重试同一个 Agent、换模型或换 Agent、跳过非关键分支、回退到某个上游重跑、阻塞下游并告警、请求人工确认、终止整个 DAG。

预算与终止条件：最大步数、最大深度、全局 token 预算、单 Agent 预算、超时时间、目标达成判定。

可观测与审计：每个 Agent 的输入输出、思考轨迹、工具调用记录、DAG 实时状态、失败原因和重试历史、回放和审计。

6.2 规划与调度要分开

角色	负责什么	不负责什么
规划 Agent	生成图、扩展图、决定下一步做什么	不直接调度执行
执行 Agent	完成具体任务，返回结果	不决定全局顺序
核心调度服务	管图、管状态、管资源、管失败、管终止	不替 Agent 做业务决策

规划 Agent 可以“画图”，但“按图施工”的是核心调度服务。动态 DAG 下，Agent 可以申请“加一个节点”，但加不加、能不能加、会不会成环、预算够不够，由调度服务校验和决定。

七、框架实现：核心调度服务是怎么落地的

理论讲完了，下面来看具体的框架是怎么实现这套调度服务的。

7.1 LangGraph：Pregel 执行引擎

LangGraph 的运行时是 Pregel，灵感来自 Google 的大规模图计算算法，采用 Bulk Synchronous Parallel（BSP） 模型。

执行过程分三步：

Plan（计划） ：确定这一步要执行哪些 actor。第一步选出订阅了输入通道的 actor；后续步骤选出订阅了上一步更新通道的 actor。
Execution（执行） ：并行执行所有选中的 actor，直到全部完成、某个失败或超时。在这个阶段，通道更新对 actor 不可见。
Update（更新） ：用本步 actor 写入的值更新通道。

核心概念：

PregelNode：actor，订阅通道、读取数据、写入数据。
Channel：通道，用于 actor 之间的通信。默认的 LastValue 通道存储最后写入的值；Topic 通道支持 PubSub 语义，可以累积多个值。
条件边：LangGraph 支持动态决策，通过条件边在运行时根据全局状态选择下一个执行节点，可以实现分支、分流、循环重试、异常回滚等复杂逻辑。

检查点与时间旅行：LangGraph 的每次状态变更都会创建一个检查点（checkpoint），是 Agent 状态的完整快照。时间旅行功能允许检查任意检查点、查看 Agent 持有的精确状态，并从该点恢复执行以探索替代路径。

评估数据：LangGraph 在跨框架基准测试中，复杂分支工作流的任务完成率约 94%，并且是唯一通过 DAG 检查点内置时间旅行调试的编排框架。

7.2 Eino：类型安全的 DAG 图编排引擎

Eino 是字节跳动开源的 Go 语言 AI Agent 框架，基于 Pregel 模型构建 DAG 执行引擎，默认启用 Eager 执行策略，推理效率较传统串行框架提升 5-8 倍。

核心概念：

Node：一个处理步骤，具有泛型化的输入类型 I 和输出类型 O。
Edge：节点间的有向连接，数据沿 Edge 流动且携带类型信息。
Branch：动态条件分支，根据运行时输出决定路由到哪个下游节点。
State：全图流转的强类型状态。

类型安全是 Eino 与 LangChain 最本质的区别。Node 的输入输出类型由 Go 泛型保障，编译器确保 Node 的输入输出类型匹配，消除运行时类型断言风险。而 LangChain 使用运行时字典，如果 executor 期望的 key 不在 planner 输出中，只能在运行时才崩溃。

Eager 执行：v0.4.0 版本默认启用 AllPredecessor 触发的 Eager 执行，所有前置节点完成后立即触发后续节点，摒弃了旧的 SuperStep 同步逻辑，显著降低延迟。同时移除了非线程安全的 GetState 接口，改用 compose.ProcessState 回调保障状态安全，消除高并发场景下的竞态风险。

中断与恢复：Eino 已经上线了 interrupt 和 checkpoint，支持图执行的中断和继续能力，以及多智能体交互方式的探索。

ReAct 循环：通过 Branch 实现循环控制，反思分支在不满足条件时回到 think 节点重新规划。

7.3 Dify：可视化 DAG 引擎与拓扑排序

Dify 是一个低代码 LLM 应用平台，V1.8.0 引入了基于 DAG 的执行引擎与动态节点注入机制，将任务节点抽象为图顶点，依赖关系定义为边，通过拓扑排序算法实现动态调度。

调度实现：采用 Kahn 算法进行拓扑排序，从入度为 0 的节点开始逐层推进：统计所有节点的入度，将入度为 0 的节点加入就绪队列，依次出队并执行。

数据流转：节点之间不直接传递数据对象，而是通过一个共享的变量池（Variable Pool） 进行间接通信。节点执行完毕后将结果写入变量池，下游节点执行前从变量池读取所需变量。这种“发布-订阅”式的内存模型极大地解耦了节点关系。

动态分支：对于 If/Else 节点或 QuestionClassifier 节点，节点执行后返回一个特定的 edge_id 或 port_id（即命中的路径），调度器只会将命中路径上的下游节点加入执行队列，未命中路径上的节点将被自动跳过。

并发控制：Dify 引入了 Parallel 节点和 Iteration 节点来处理并发需求。遇到并行分支时，利用 ThreadPoolExecutor 创建线程池，每个分支可配置独立的资源配额。

7.4 Airflow：传统 DAG 调度器的 Agent 扩展

Airflow 是经典的工作流调度器，通过 apache-airflow-providers-common-ai 添加了 LLM 和 Agent 能力，基于 Pydantic AI 构建，支持 20+ 模型提供商。

核心装饰器：

@task.llm：单次 LLM 调用，返回结构化输出，下游任务通过 XCom 获取结构化数据。
@task.agent：多步骤 Agent，Agent 自主决定调用哪些工具，循环直到获得答案。底层 Agent 会自主调用 list_tables、get_schema、query 等工具。
@task.llm_branch：LLM 驱动的分支，LLM 返回由下游任务 ID 构建的受约束枚举，决定哪些下游任务运行。

生产案例：Astronomer 的博客展示了一个编排 10 个 AI Agent 的 Airflow DAG 流水线，其中包含两次 human-in-the-loop 步骤——一次审批标题生成 Agent 的输出，一次在最后审批最终资产。

7.5 Temporal：持久化执行

Temporal 通过 Durable Execution（持久执行） 模型实现工作流的持久化，基于事件溯源、持久状态跟踪和自动重试。每个工作流执行维护完整的执行历史，持久存储在 Temporal 后端，无论 worker 失败、机器重启还是任务停滞，工作都不会丢失。

Temporal 将编排与副作用分离：Workflow 代码必须是确定性的，以便从崩溃中恢复时“重放”进度重建状态；与外部世界交互的操作放在 Activity 中。虽然 Temporal 要求 Workflow 代码具有确定性，但 AI Agent 可以根据非确定性的 LLM 结果做出决策。

Temporal 的架构将集群分解为 Frontend（gRPC API）、History、Matching、Worker 四个角色。在每秒 10k 次执行、DAG 最多 10k 节点的场景下，基于哈希范围分片的调度器配合 Kafka 分发和 Temporal 风格的事件溯源历史是合适的组合。

7.6 Prefect：动态 DAG 与事件驱动

Prefect 的核心特点是不在执行前预编译 DAG，而是在运行时根据实际数据或条件动态创建任务，在执行过程中生成新任务和分支，实现真正的数据驱动工作流。

Prefect 的富状态系统允许在运行时改变底层 DAG 结构，同时仍提供所有底层工作流保证：单个任务可以有自己的重试设置、交换数据、激活通知。Task Looping 是一等公民操作，可以与 mapping 结合实现真正动态的工作流。

Prefect 的事件驱动能力允许从 Webhook、云事件或状态变更触发工作流，主动事件总线实时检测发生或未发生的事件。

7.7 Ray：分布式 DAG 调度

Ray 的 DAG API 提供声明式方式将 Ray tasks 和 actors 组合成执行图。Compiled Graphs（实验性）通过融合相邻节点、消除不必要的序列化、预计算调度决策来优化 DAG 执行。

Compiled DAG 通过绕过分布式调度器来消除传统 Ray 任务提交开销，使用预分配的通信通道、静态调度、共享内存优化来加速任务图执行。

Agentic-Ray 使任何框架构建的 Agent 能够使用 Ray 作为运行时，在集群中分发工具调用，并提供用于执行 AI 生成代码的沙箱环境。

7.8 框架调度能力对比

框架	核心调度机制	动态图支持	持久化/恢复	类型安全	最适合的场景
LangGraph	Pregel BSP 运行时	✅ 条件边	✅ 检查点 + 时间旅行	❌ 运行时字典	需要循环/分支的复杂 Agent
Eino	Pregel + Eager 执行	✅ Branch	✅ interrupt + checkpoint	✅ Go 泛型	Go 生态高并发 Agent
Dify	拓扑排序 + 变量池	✅ 动态节点注入	✅ 执行轨迹回放	❌ JSON 配置	低代码可视化编排
Airflow	静态 DAG Scheduler	⚠️ llm_branch	✅ 任务级重试	❌ XCom	已有 Airflow 基础设施
Temporal	持久化执行	✅ Workflow 代码	✅ 事件溯源	❌	长时间运行 + 故障恢复
Prefect	动态 DAG	✅ 运行时创建	✅ 任务级持久化	❌	动态分支 + 人工介入
Ray	DAG API + Compiled Graphs	⚠️ 有限	⚠️ 有限	❌	分布式集群级调度

7.9 按场景选型指南

你的场景	推荐框架	理由
Python 生态，需要循环/分支的 Agent	LangGraph	Pregel 运行时，条件边，时间旅行调试，94% 任务完成率
Go 语言，高并发 Agent 工作流	Eino	类型安全 DAG，Eager 执行，并发安全设计
低代码/可视化编排	Dify	可视化 DAG 引擎，拓扑排序，动态节点注入
已有 Airflow 基础设施	Apache Airflow	`@task.agent`，Dag-as-a-tool，渐进式集成
长时间运行 + 故障恢复	Temporal	持久化执行，事件溯源，确定性工作流
复杂动态分支 + 人工介入	Prefect	动态 DAG，运行时分支，事件驱动
分布式/集群级 Agent 调度	Ray	Compiled Graphs，Agentic-Ray 沙箱

八、和普通 DAG / 普通 Agent 调用的区别

对比项	普通函数调用	普通 DAG 调度	Agent DAG 调度
节点	函数	任务/算子	Agent
边	调用关系	数据/控制依赖	数据/控制/条件/工具/上下文依赖
执行	确定性	相对确定	有自主性，可能动态决策
资源	CPU/内存	计算资源	模型、token、工具、沙箱、API 配额
失败处理	异常	重试/跳过	重试、换 Agent、人工确认、回退
并行	线程/协程	无依赖任务并行	无依赖 Agent 并行
可观测	日志/链路	DAG 状态	DAG 状态 + Agent 思考/工具调用轨迹

九、主要优点

复杂任务可分解：规划、检索、推理、执行、验证各司其职。
并行提效：检索、记忆、工具等无依赖 Agent 可以同时跑。
可观测：能清楚看到哪个 Agent 卡住、哪个分支失败。
可恢复：支持重试、断点续跑、替换 Agent、人工接管。
可扩展：新增 Agent 只需接入 DAG，不必重写整个流程。
适合人机协同：关键节点可以插入人工审核 Agent 或人工确认。
全局可控：核心调度服务统一管预算、并发、失败和终止。
确定性：给定相同输入，执行顺序一致，使调试和审计可行。

十、主要缺点

调度复杂：要处理模型资源、工具配额、上下文长度、优先级。
上下文传递成本高：Agent 之间传太多会贵，传太少会丢信息。
错误会传播：上游 Agent 输出错误，下游可能一路错下去。
Agent 可能发散：自主性越强，越可能跑偏或产生无效调用。
资源消耗大：多 Agent 并行会放大 token、API 和计算成本。
动态分支难处理：运行中生成新节点、条件跳过、跨 DAG 依赖都更复杂。
图必须无环：Agent 之间的依赖一旦成环，调度器就无法确定执行顺序。

十一、常见使用场景

深度研究：检索 Agent + 记忆 Agent + 推理 Agent + 验证 Agent + 汇总 Agent。
代码生成：规划 Agent + 代码 Agent + 测试 Agent + 审查 Agent。
数据分析：取数 Agent + 清洗 Agent + 分析 Agent + 可视化 Agent。
客服工单：意图识别 Agent + 知识检索 Agent + 工单工具 Agent + 人工审核 Agent。
自动化运维：监控 Agent + 诊断 Agent + 修复 Agent + 验证 Agent。
RAG 与知识库：查询改写 Agent + 检索 Agent + 重排 Agent + 答案生成 Agent。

十二、总结

Agent 的 DAG 调度模式，本质上是“依赖图驱动 + 核心调度服务管控”的多智能体编排方式：

节点是 Agent；
边是依赖、数据流、控制流；
无环保证可执行；
入度为 0 的 Agent 先跑；
上游完成解锁下游；
能并行的 Agent 并行；
失败可重试、替换、人工确认；
核心调度服务统一管图、状态、资源、上下文、失败和终止。

它不是直线图，而是有向无环图。直线链只是它最简单的一种形态；真实的 Agent 工作流往往像开头那张图一样，有分叉、有并行、有汇合，也有验证和汇总。

图可以是提前规划好的（静态 DAG），也可以是边跑边生成的（动态 DAG），生产系统多用混合模式：规划 Agent 出骨架，各阶段 Agent 动态扩展子图，核心调度服务统一调度执行。

从框架实现来看，LangGraph 用 Pregel BSP 模型实现了带条件边和时间旅行的图运行时；Eino 用 Go 泛型实现了类型安全的 DAG 引擎，Eager 执行大幅降低延迟；Dify 用拓扑排序和变量池实现了可视化编排；Airflow 通过装饰器将 Agent 任务融入传统 DAG；Temporal 用事件溯源实现了持久化执行；Prefect 用动态 DAG 支持运行时分支；Ray 用 Compiled Graphs 实现了分布式加速。

无论哪种框架，不变的都是那套调度骨架：状态机 + 入度驱动 + 就绪队列 + 资源分配 + 上下文传递 + 失败回退 + 终止条件 + 核心调度服务。

posted @ 2026-10-14 11:29 若-飞阅读(10) 评论(0) 收藏举报

刷新页面返回顶部

若-飞

Agent 的 DAG 调度模式：从理论框架到框架实现

Agent 的 DAG 调度模式：从理论框架到框架实现

一、为什么 Agent 需要 DAG 调度

二、DAG 到底是什么

三、DAG 调度的核心规则

四、一个稍复杂的执行例子

五、关键问题：图是提前规划好的，还是边跑边生成？

5.1 静态 DAG：规划 Agent 一开始就规划好

5.2 动态 DAG：边跑边生成

5.3 混合模式：静态骨架 + 动态扩展

六、核心调度服务：DAG 调度的控制平面

6.1 核心调度服务管什么

6.2 规划与调度要分开

七、框架实现：核心调度服务是怎么落地的

7.1 LangGraph：Pregel 执行引擎

7.2 Eino：类型安全的 DAG 图编排引擎

7.3 Dify：可视化 DAG 引擎与拓扑排序

7.4 Airflow：传统 DAG 调度器的 Agent 扩展

7.5 Temporal：持久化执行

7.6 Prefect：动态 DAG 与事件驱动

7.7 Ray：分布式 DAG 调度

7.8 框架调度能力对比

7.9 按场景选型指南

八、和普通 DAG / 普通 Agent 调用的区别

九、主要优点

十、主要缺点

十一、常见使用场景

十二、总结

公告