Multi-Agent 没死，而是在进化：深入理解 Anthropic 的 DAG Multi-Agent 架构

- [1. 背景：传统 Multi-Agent 为什么需要改变？](#1. 背景：传统 Multi-Agent 为什么需要改变？)
- - [1.1 传统 Multi-Agent 的主要问题](#1.1 传统 Multi-Agent 的主要问题)
- [2. Knowledge Point 01：Directed Acyclic Graph（DAG）](#2. Knowledge Point 01：Directed Acyclic Graph（DAG）)
- - [2.1 DAG 的定义](#2.1 DAG 的定义)
  - [2.2 为什么使用 DAG？](#2.2 为什么使用 DAG？)
- [3. Knowledge Point 02：Dynamic Task Decomposition](#3. Knowledge Point 02：Dynamic Task Decomposition)
- - [3.1 Static Planning 的局限](#3.1 Static Planning 的局限)
  - [3.2 Dynamic Planning 的核心机制](#3.2 Dynamic Planning 的核心机制)
  - [3.3 Dynamic DAG 的设计要求](#3.3 Dynamic DAG 的设计要求)
  - [3.4 与 DeepSeek Harness（DSH）的实现对比](#3.4 与 DeepSeek Harness（DSH）的实现对比)
- [4. Knowledge Point 03：DAG-Based Task Scheduling](#4. Knowledge Point 03：DAG-Based Task Scheduling)
- - [4.1 Ready Queue](#4.1 Ready Queue)
  - [4.2 Parallel Execution](#4.2 Parallel Execution)
- [5. Knowledge Point 04：Independent Verification](#5. Knowledge Point 04：Independent Verification)
- - [5.1 为什么不能依赖 Agent 自行判断？](#5.1 为什么不能依赖 Agent 自行判断？)
  - [5.2 Prove2Me 如何实现 Independent Verification？](#5.2 Prove2Me 如何实现 Independent Verification？)
  - [5.3 Independent Verification 如何影响 DAG Scheduling？](#5.3 Independent Verification 如何影响 DAG Scheduling？)

摘要： Anthropic 利用 Claude、Prove2Me 和 Lean 4，在 11 天内完成了费马大定理（Fermat's Last Theorem）的计算机形式化证明，生成约 1300 万行 Lean 代码。这项成果背后值得关注的不只是模型能力，还有一套基于 Directed Acyclic Graph（DAG）、Dynamic Task Decomposition、Independent Verification 和 Artifact-Based Collaboration 的 Multi-Agent 协作架构。本文从核心知识点出发，分析其工作原理、架构设计和工程实践价值。

关键词： Multi-Agent、DAG、Agent Harness、Dynamic Planning、Task Scheduling、Verifier、Artifact、State Machine、Lean 4、Prove2Me

1. 背景：传统 Multi-Agent 为什么需要改变？

2026 年 9 月 4 日，Anthropic 发布了《Formalizing Fermat's Last Theorem》，介绍 Claude 在数学形式化验证方面的一项重要成果。

整个过程具有以下特点：

指标	结果
Execution Duration	11 天
Generated Code	约 1300 万行 Lean 代码
Verified Theorems	约 30,300 个
Intermediate Theorems Used	约 29,500 个
Proof Assistant	Lean 4
Collaboration Platform	Prove2Me
Agent Framework	Claude Code-based Multi-Agent Harness

这里需要明确：Claude 并不是从零发现了费马大定理的新证明，而是参考已有数学证明，生成能够由 Lean 检查的 Formal Proof。

这一成果的重要性在于，多个 Agent 能够持续执行大规模复杂任务，并通过统一的基础设施协调依赖关系和复用已有成果。

1.1 传统 Multi-Agent 的主要问题

常见 Multi-Agent System 通过 Planner、Executor、Reviewer 等角色进行分工。

补充知识点：Multi-Agent Roles

Planner、Executor、Reviewer 是常见的 Agent Roles，但并非完整分类。根据具体任务和 Architecture，Multi-Agent System 还可以包含 Coordinator、Supervisor、Researcher、Retriever、Coder、Tester、Verifier、Memory Manager、Integrator 等角色。

需要注意，Agent Role 并不存在统一、固定的分类标准。同一个 Agent 可以承担多个 Role，而 Scheduler、State Manager、Artifact Store 等 System Components 也不一定需要由 LLM Agent 实现。

感兴趣的读者可以进一步了解：

Role-Based Collaboration：基于角色的 Agent 协作机制。

Supervisor Architecture：通过 Supervisor 管理 Agent 的任务分配与协作。

Hierarchical Multi-Agent Architecture：分层组织 Agent。

Graph-Based Multi-Agent Architecture：通过 Graph 管理协作关系和任务依赖。

本文重点讨论 DAG-Based Multi-Agent Architecture，因此不再展开各类 Agent Roles 的具体实现。

但是，当任务规模扩大、运行时间延长时，容易出现以下问题。

（1）Context Degradation(推理时上下文变长带来的性能下滑)

Agent 长期执行任务后，可能逐渐丢失或混淆之前的决策、执行进度和依赖关系。

即使使用 Context Summarization，也无法完全避免信息压缩带来的损失。

（2）Coordination Overhead(协调开销)

多个 Agent 频繁沟通会增加 Token Consumption 和协调成本。

当 Agent 数量增加时，沟通开销不一定呈线性增长。

（3）State Inconsistency

不同 Agent 可能对任务状态产生不同理解。

例如：

Agent A 认为 Task X 已完成。
Agent B 仍然认为 Task X 处于 Running。
Agent C 使用了 Task X 尚未验证的结果。

（4）Write Conflict

多个 Agent 同时修改同一文件、配置或共享资源，可能产生 Race Condition 和数据覆盖问题。

（5）Error Propagation

如果缺少 Independent Verification，一个错误结果可能被多个 Agent 反复引用，最终污染整个任务链。

因此，问题并不是 Agent 数量不足，而是缺少可靠的任务组织、状态管理与验证机制。

2. Knowledge Point 01：Directed Acyclic Graph（DAG）

2.1 DAG 的定义

Directed Acyclic Graph 是一种具有方向且不存在有向环的图结构。

可以表示为：

G = (V, E)

其中：

V（Vertices）：任务节点集合。
E（Edges）：节点之间的有向依赖关系。

在 DAG Multi-Agent 中，每个 Node 表示一个独立 Task，每条 Edge 表示一个 Dependency。

例如：

text 复制代码

Task A ──┐
         ├──> Task D ──> Final Goal
Task B ──┘                    ^
                              |
Task C ───────────────────────┘

这里采用 Dependency → Dependent 的连线方向。

Task D 依赖 Task A 和 Task B，而 Final Goal 依赖 Task C 和 Task D。

2.2 为什么使用 DAG？

第一，Dependency Management。

通过显式 Dependency，系统可以判断哪些任务必须先完成。

第二，Parallel Execution。

对于没有相互依赖的 Task，可以使用不同 Agent 并行执行。

第三，Task Scheduling。

Scheduler 根据 Dependency 和 Task State 判断节点是否可以进入 Ready Queue。

第四，Failure Isolation。

当某个 Task 执行失败时，可以阻止依赖它的后续 Task 继续执行，避免错误传播。

第五，Progress Tracking。

系统能够根据 DAG 追踪任务执行进度、阻塞原因和剩余依赖。

DAG 不仅是一种任务可视化结构，更是复杂 Agent System 的执行基础。

3. Knowledge Point 02：Dynamic Task Decomposition

3.1 Static Planning 的局限

在传统 Agent Workflow 中，通常由 Planner 根据用户目标预先生成 Task Plan，再由 Executor 按照既定的 Execution Order 和 Task Dependencies 执行。

这种以预先确定的任务计划为主要执行依据的方式，可以称为 Static Planning。

Static Planning 适用于任务结构明确、执行步骤相对固定的场景。但对于复杂任务，Planner 很难在执行开始前预知所有潜在问题和必要的 Preconditions。

举个例子：

假设用户提出一个需求：

开发一个数据分析程序，读取 CSV 文件，对数据进行清洗，并生成可视化报告。

Planner 根据需求生成初始计划：

text 复制代码

Data Loading
     ↓
Data Cleaning
     ↓
Data Analysis
     ↓
Report Generation

按照原计划，Executor 只需要依次完成各个 Task。

但在实际执行 Data Loading 时，Agent 发现部分 CSV 文件使用 UTF-8 编码，另一些则使用 GBK 编码，导致程序无法正确读取全部文件。

问题出现了：初始计划默认数据可以被正常读取，却没有考虑 Encoding Compatibility。

此时，Data Loading 无法继续完成，而后续任务也因为依赖尚未满足而处于等待状态。

text 复制代码

Initial Task Plan

Data Loading
     │
     ✕ Blocked
     │
     │ Unexpected Issue:
     │ Mixed File Encodings
     │
     ▼
Data Cleaning       (Waiting)
     ↓
Data Analysis       (Waiting)
     ↓
Report Generation   (Waiting)

对于仅依赖固定 Task Plan 的 Workflow，系统可能需要停止当前任务、触发预先定义的 Error Handling，或者由外部 Planner 重新生成计划。

但真正的问题并不是 CSV 文件读取失败，而是：

执行过程中发现了初始规划阶段没有识别出来的新 Preconditions（前置条件）。

为了继续完成原来的目标，系统需要补充以下任务：

Encoding Detection：识别不同 CSV 文件的字符编码。
Encoding Normalization：将文件内容统一转换为目标编码。
Data Validation：检查转换后的数据是否完整、有效。

新的任务依赖关系可以表示为：

text 复制代码

Encoding Detection
        ↓
Encoding Normalization
        ↓
  Data Validation
        ↓
  Resume Data Loading
        ↓
   Data Cleaning
        ↓
   Data Analysis
        ↓
 Report Generation

这些新增的 Subtasks 并不是初始计划中的内容，而是执行过程中根据实际问题发现的。

需要注意，Static Planning 并不意味着计划绝对不能修改。它的局限在于，当任务执行过程出现未知 Dependencies 时，仅依赖预先确定的 Task Graph，难以自主完成新的 Task Decomposition 和 Dependency Update。

如果引入 Dynamic Planning，Agent 就可以根据 Execution Feedback 分析当前任务缺失的 Preconditions，在 Runtime 生成必要的 Subtasks，并动态调整 Task Graph。

因此，两种方式的核心区别在于：

Static Planning：主要依据预先确定的 Task Plan 执行。
Dynamic Planning：允许根据 Execution Feedback，在 Runtime 持续调整和扩展 Task Plan。

关键思想：Planning 不必在 Execution 开始前一次性完成，而可以随着任务执行持续演进。

这也引出了下一节的 Dynamic Task Decomposition：当 Agent 发现新的 Preconditions 时，如何创建 Subtasks、更新 DAG，并在相关任务验证完成后恢复原任务的执行？

3.2 Dynamic Planning 的核心机制

在传统 Static Planning 中，Planner 通常在 Execution 开始前生成 Task Plan，Executor 再按照预先确定的 Dependency Relationship 执行任务。

但对于复杂任务，Planner 很难在一开始就预知所有可能遇到的问题。

Dynamic Planning 的核心思想，就是允许系统根据 Execution Feedback，在 Runtime 持续调整和扩展 Task Plan。

其中，一个重要机制是 Dynamic Task Decomposition：当 Agent 发现当前 Task 缺少必要的 Preconditions 时，可以动态创建新的 Subtasks，而不必完全推翻原有计划。

继续使用前面的 CSV 数据分析案例。

假设 Agent 正在执行 Data Loading，却发现部分 CSV 文件使用 GBK 编码，而当前程序只支持 UTF-8。

此时，原有任务无法继续执行。

传统的固定 Workflow 可能将任务标记为 Failed，或者触发预先定义的 Error Handling。

而支持 Dynamic Task Decomposition 的系统，可以先分析当前 Task 为什么无法完成，再根据缺失的 Preconditions 创建新的 Subtasks。

例如：

text 复制代码

Initial DAG:

Data Loading
     ↓
Data Cleaning
     ↓
Data Analysis
     ↓
Report Generation

执行过程中发现 Encoding Compatibility 问题，于是动态扩展 DAG：

text 复制代码

Updated DAG:

Encoding Detection
        ↓
Encoding Normalization
        ↓
   Data Validation
        ↓
    Data Loading
        ↓
    Data Cleaning
        ↓
    Data Analysis
        ↓
  Report Generation

注意，这里不仅增加了三个 Subtasks，还改变了原有的 Dependency Relationship。

原本可以直接执行的 Data Loading，现在需要等待 Encoding Detection、Encoding Normalization 和 Data Validation 完成后，才能继续推进。

整个执行逻辑可以抽象为：

text 复制代码

1. Select Task
2. Check Known Dependencies
3. Attempt Execution

4. If Blocked by Missing Preconditions:
      Analyze Missing Preconditions
      Generate Subtasks
      Validate DAG Changes
      Update DAG
      Suspend Parent Task

5. Schedule & Execute Subtasks
6. Verify Subtask Results
7. Resume Parent Task

这里有三个关键点。

首先，Check Dependencies 只能检查当前已经记录的依赖。即使一个 Task 已经满足已知 Dependencies，也可能在实际执行时发现新的 Preconditions。

其次，Blocked 不等于所有类型的 Failed。如果只是网络超时，可以优先通过 Retry 解决；如果发现缺少必要的功能或处理步骤，才可能需要 Dynamic Task Decomposition。

最后，新增 Subtasks 完成后，不能直接恢复 Parent Task。系统还需要通过 Verifier 检查相关结果，确保新增 Dependencies 已经满足预设的 Verification Criteria。

当 Parent Task 的 Dependencies 全部满足后，Scheduler 才能将其重新置于 Ready State，恢复执行。

如果执行过程中又发现新的 Preconditions，系统可以再次进行 Task Decomposition。

因此，Dynamic Planning 并不是一次性的重新规划，而是能够随着任务执行持续发生。

其核心过程可以表示为：

text 复制代码

Initial Planning
       ↓
Execution
       ↓
Execution Feedback
       ↓
Need Replanning?
       │
       ├── No ──> Continue Execution
       │
       └── Yes
            ↓
     Generate Subtasks
            ↓
         Update DAG
            ↓
     Execute & Verify
            ↓
      Resume Execution

关键思想：Planning 不再局限于 Execution 开始前，而是能够根据 Execution Feedback 持续调整 Task Graph。

这也是 Dynamic Planning 与单纯增加 Retry Mechanism 的区别：前者能够改变 Task Structure 和 Dependencies，而后者通常是在既定任务结构内重新尝试执行。

需要注意，Dynamic Planning 不一定必须使用 DAG。DAG 是组织动态任务依赖的一种方式，而不是 Dynamic Planning 唯一的实现形式。

3.3 Dynamic DAG 的设计要求

在上一节中，我们介绍了 Dynamic Task Decomposition：当 Agent 在 Execution 过程中发现新的 Preconditions 时，可以创建 Subtasks，并将它们加入原有的 DAG。

但这里存在一个容易被忽略的问题：

Agent 能够生成新的 Task，并不意味着这些 Task 可以直接加入 DAG。

因为在 Multi-Agent System 中，DAG 不仅用于描述 Task Dependencies，还直接影响 Scheduler 如何分配任务，以及整个 Workflow 能否继续执行。

如果 Agent 随意修改 DAG，可能产生循环依赖、重复任务、状态不一致，甚至导致多个 Agent 对同一 Task 的修改相互冲突。

因此，Dynamic DAG 的核心设计要求是：允许 Task Graph 在 Runtime 发生变化，同时保证每次变化都是合法、一致且可追踪的。

继续使用前面 CSV 数据分析的例子。

假设初始 DAG 如下：

text 复制代码

Data Loading
     ↓
Data Cleaning
     ↓
Data Analysis
     ↓
Report Generation

执行过程中，Agent A 发现 Data Loading 无法处理部分 CSV 文件的编码，于是提出新增三个 Subtasks：

text 复制代码

Encoding Detection
        ↓
Encoding Normalization
        ↓
   Data Validation
        ↓
    Data Loading
        ↓
    Data Cleaning
        ↓
    Data Analysis
        ↓
  Report Generation

表面上看，只需要创建三个 Task Nodes，并增加相应的 Dependency Edges。

但在真正修改 DAG 之前，系统至少需要解决以下五个问题。

（1）Acyclicity：新增 Dependency 会不会产生循环依赖？

Acyclicity（无环性）是 DAG 的基本约束，即 Graph 中不能存在 Directed Cycle。

例如，已有依赖关系：

text 复制代码

Task A → Task B → Task C

这里约定 A → B 表示 Task B 依赖 Task A。

如果某个 Agent 又提出新增：

text 复制代码

Task C → Task A

那么整个 Graph 就变成：

text 复制代码

Task A → Task B → Task C
   ↑                   |
   └───────────────────┘

此时，Task A 等待 Task C，Task C 等待 Task B，而 Task B 又等待 Task A。

三个 Task 互相等待，无法根据现有 Dependency Relationship 正常执行。

因此，系统不能直接接受 Agent 生成的 Dependency Edge，而是需要在更新前执行 Cycle Detection。

具体来说，准备添加 X → Y 时，需要判断现有 DAG 中是否已经存在 Y → X 的 Directed Path。如果存在，添加新 Edge 就会形成 Directed Cycle，必须拒绝。

对于一般规模的 DAG，可以采用 DFS-Based Cycle Detection；对于规模较大、更新频繁的 DAG，则可以研究 Incremental Topological Ordering，在维护合法 Topological Order 的同时减少重复计算。

（2）Dependency Consistency：新增的依赖关系是否真实、有效？

保证没有 Directed Cycle 还不够。

例如，Agent A 创建 Task X，并要求 Data Loading 等待 Task X 完成。

text 复制代码

Task X
   ↓
Data Loading

但如果 Task X 实际上不存在，或者引用的是错误的 Task ID，那么 Data Loading 就可能一直处于等待状态。

因此，系统需要检查 Dependency Reference 是否有效。

此外，还有一个更重要的问题：

Dependency 已经执行完成，是否就意味着 Parent Task 可以继续执行？

不一定。

假设 Encoding Normalization 已经执行完成，但生成的 CSV 文件仍然存在乱码。

此时，虽然它的 Execution State 是 Completed，但结果并没有满足预设的 Verification Criteria。

所以，不能仅凭 Completed 就认为前置条件已经满足。

对于需要验证的任务，可以区分：

text 复制代码

RUNNING
   ↓
COMPLETED
   ↓
VERIFYING
   ├── VERIFIED
   └── FAILED

这里的 Completed 只表示执行动作已经结束，而 Verified 才表示结果通过了相应的检查。

因此，Dependency Consistency 不只是检查 Task 是否存在，还需要确认 Dependency Reference、Version 和 Verification Status 是否满足要求。

（3）Task Identity：如何区分不同 Agent 创建的 Task？

在 Dynamic Planning 中，不同 Agent 可能同时创建新的 Subtasks。

例如：

text 复制代码

Agent A:
    Create Task "Detect CSV Encoding"

Agent B:
    Create Task "Detect CSV Encoding"

两个 Task 的名称相同，但这并不能直接说明它们是同一个 Task。

它们可能处理不同的数据文件，也可能确实是在重复解决同一个问题。

如果系统只通过 Task Name 管理节点，就容易出现重复执行、错误引用或结果覆盖。

因此，每个 Task 都需要稳定且唯一的 Task ID。

例如：

json 复制代码

{
  "task_id": "task_103",
  "parent_task_id": "task_100",
  "goal": "Detect CSV encoding",
  "status": "PENDING",
  "dependencies": []
}

这里：

task_id：唯一标识当前 Task。
parent_task_id：记录 Subtask 与 Parent Task 的关系。
goal：描述 Task 需要完成的目标。
status：记录当前 Task State。
dependencies：记录执行该 Task 所需的其他 Task。

有了稳定的 Task Identity，系统才能正确维护 Dependency Relationship，并将 Execution Logs、Verification Results 和 Artifacts 关联到对应的任务。

对于语义相同的重复 Task，还可以结合 Task Fingerprint 等机制进行去重或结果复用。

（4）Atomic Graph Update：如果 DAG 更新到一半失败怎么办？

这是 Dynamic DAG 中非常重要的工程问题。

假设 Agent A 发现 Data Loading 缺少三个 Subtasks，系统需要执行以下操作：

text 复制代码

1. Create Encoding Detection
2. Create Encoding Normalization
3. Create Data Validation
4. Add Dependency Edges
5. Set Data Loading = BLOCKED

如果系统执行到第三步时发生异常，就可能出现以下情况：

text 复制代码

Encoding Detection       Created
Encoding Normalization   Created
Data Validation          Created
Dependency Edges         Missing
Parent Task State        RUNNING

此时，Task Nodes 已经创建，但 Dependency Relationship 尚未完整建立，Parent Task 也没有正确进入 Blocked State。

Scheduler 如果读取到这个中间状态，就可能错误地调度任务。

因此，需要通过 Atomic Graph Update（原子性图更新） 保证相关修改的一致性。

可以将创建 Nodes、添加 Edges、更新 Parent Task State 等操作放在同一个 Database Transaction 中。

这样，要么所有修改一起 Commit，要么全部 Rollback。

text 复制代码

Begin Transaction
        ↓
Create Task Nodes
        ↓
Add Dependency Edges
        ↓
Validate Graph
        ↓
Update Parent Task State
        ↓
Commit Transaction

如果任何一步失败，则执行 Rollback，避免其他组件看到不完整的 DAG。

这里需要注意：Atomicity 保证的是一组修改的一致提交，不等于 DAG 的内容必然正确。

Acyclicity、Dependency Consistency 等规则仍然需要单独验证。

（5）Idempotency：重复提交会不会创建重复任务？

在 Multi-Agent System 中，同一操作可能因为 Timeout、Retry 或 Worker Recovery 而重复执行。

例如：

text 复制代码

Agent A:
    Create Encoding Detection
        ↓
    Server creates Task X
        ↓
    Response Timeout
        ↓
    Agent A retries

实际上，第一次请求已经成功创建了 Task X，只是 Agent A 没有收到响应。

如果第二次请求再次创建一个新的 Task，就可能变成：

text 复制代码

Encoding Detection X
        ↓
    Data Loading
        ↑
Encoding Detection Y

两个 Task 执行相同工作，造成重复计算和不必要的资源消耗。

因此，需要引入 Idempotency（幂等性）。

一种常见方式是为每次修改请求分配稳定的 Idempotency Key。

text 复制代码

Request:
    Create Encoding Detection

Idempotency Key:
    parent100-operation03

First Request:
    Create Task X
    Return Task ID = X

Repeated Request:
    Return Task ID = X
    Do Not Create Another Task

这样，即使同一个请求被重复提交，也不会产生非预期的重复副作用。

不过，Idempotency 并不是禁止所有重新执行。系统仍然需要区分 Repeated Request 和用户明确发起的 New Execution。

理解了以上五项要求后，还需要考虑一个更复杂的场景：多个 Agent 同时修改 DAG 怎么办？

例如，某个 DAG 当前包含两个 Task：

text 复制代码

Task A       Task B

它们暂时没有依赖关系。

此时：

Agent A 提议新增 Task A → Task B。
Agent B 同时提议新增 Task B → Task A。

如果两个 Agent 都基于同一个旧版 DAG 独立检查，就可能都认为自己的修改合法。

但是，一旦两次修改全部生效：

text 复制代码

Task A → Task B
   ↑         |
   └─────────┘

就形成了 Directed Cycle。

注意，这个问题不是普通的 Cycle Detection 就一定能够解决的，因为两个 Agent 各自检查时看到的都可能是修改前的 Graph。

真正的问题是：检查所依据的 Graph State，与最终写入时的 Graph State 可能已经不同。

这就是并发修改中的典型一致性问题。

一种解决方式是使用 Optimistic Concurrency Control（乐观并发控制） 和 Graph Versioning（图版本管理）。

假设当前：

text 复制代码

graph_version = 12

Agent A 和 Agent B 都基于 Version 12 生成了修改方案。

Agent A 先提交：

text 复制代码

Expected Version: 12
Add Edge: A → B

Validation: PASS
Commit: SUCCESS

graph_version = 13

然后 Agent B 再提交：

text 复制代码

Expected Version: 12
Add Edge: B → A

Current Version: 13

Result: VERSION_CONFLICT

系统发现 Agent B 使用的是过期版本，因此拒绝直接提交。

Agent B 必须重新读取 Version 13，并在最新 DAG 上重新检查。

这时，系统发现新增 B → A 会形成 Directed Cycle，于是拒绝该 Dependency。

因此，Graph Versioning 的价值在于避免 Agent 基于过期 Graph State 直接覆盖或提交修改。

需要注意，版本检查、图结构校验与最终提交必须受到同一事务或其他等效并发控制机制保护，否则仍然可能出现检查通过后 Graph 又被修改的问题。

除了 Optimistic Concurrency Control，也可以使用 Database Locking 或统一的 Graph Coordinator 管理 DAG Mutation。

最后，Dynamic DAG 还必须与 State Machine 配合使用。

当 Agent 在执行 Data Loading 时发现新的 Preconditions，系统需要在 DAG Update 成功后，将其状态从 Running 转为 Blocked。

text 复制代码

Data Loading
    RUNNING
       ↓
Missing Preconditions
       ↓
Generate Subtasks
       ↓
Validate & Update DAG
       ↓
    BLOCKED
       ↓
Wait for Dependencies
       ↓
     READY
       ↓
    RUNNING

当新增的 Subtasks 完成并通过 Verification 后，Scheduler 才能重新将 Data Loading 加入 Ready Queue。

这一过程体现了 Dynamic Planning、DAG Scheduling、Verification 和 State Management 之间的协作关系。

因此，一个可靠的 Dynamic DAG 更新过程可以概括为：

text 复制代码

Agent Proposes DAG Update
           ↓
Validate Task Identity
           ↓
Validate Dependencies
           ↓
Cycle Detection
           ↓
Check Graph Version
           ↓
Atomic Commit
           ↓
Update Task State
           ↓
Scheduler Re-evaluates Ready Tasks

其中，Graph Version Check、Validation 和 Commit 应在能够保证一致性的受控更新流程中完成，而不是彼此独立、无并发保护地运行。

总结来说，Dynamic DAG 的难点不在于如何动态添加 Task Nodes，而在于多个 Agent 同时执行、失败、重试和修改任务依赖时，系统如何始终维护一张合法、一致且能够被正确调度的 Task Graph。

Acyclicity 和 Dependency Consistency 负责保证 Graph Structure 的合法性；Task Identity 负责确定每个节点的身份；Atomic Graph Update 与 Idempotency 负责保证更新操作的可靠性；Concurrency Control 和 State Machine 则进一步保证多个 Agent 协作时的状态一致性。

这些机制共同构成了 Dynamic DAG 能够长期、可靠运行的基础。

3.4 与 DeepSeek Harness（DSH）的实现对比

前面介绍的 Dynamic DAG，强调通过显式的 Task Dependency Graph 组织任务，并在 Runtime 动态扩展 Nodes 和 Edges。

但在实际 Agent Framework 中，并不是所有 Dynamic Planning 都采用这种实现方式。

DeepSeek 开源的 DeepSeek Harness（DSH） 就提供了另一种值得参考的思路。

DSH 的核心设计原则是 Everything is a Plugin，通过 Plugin-Based Architecture 组合 Agent Runtime、Tool、Subagent 和 Workflow 等能力。

其中，与 Dynamic Planning 最相关的是 Agent Loop 和 Dynamic Workflow。

两者的相同点在于：都允许 Agent 根据 Execution Feedback 调整后续执行过程，而不是完全依赖初始计划。

例如，执行 CSV Data Loading 时发现 Encoding Compatibility 问题。

在 Dynamic DAG 中，系统可以创建新的 Subtasks，更新 Task Dependency Graph，再交由 DAG Scheduler 调度。

而在 DSH 中，Parent Agent 可以根据 Tool Result 调整后续行动，或者生成新的 Workflow Script，安排 Subagents 处理编码检测、转换和验证工作。

DSH 的 Dynamic Workflow 提供了 agent()、parallel()、pipeline() 等 API，可以通过 JavaScript 组织 Subagent 的执行逻辑。

例如：

javascript 复制代码

// 示意代码：展示 DSH Workflow 的组织思路

const results = await parallel([
  () => agent("Analyze CSV encoding compatibility"),
  () => agent("Check CSV data validation requirements")
]);

return results;

通过 parallel()，两个相互独立的 Subagent Tasks 可以并发执行；通过 await 和 pipeline()，可以组织需要满足先后顺序的任务。

这里有一个重要区别：

DSH 更强调通过可执行的 Workflow Script 组织协作，而 Prove2Me 式 Dynamic DAG 更强调维护显式的 Dependency Graph。

例如：

text 复制代码

Dynamic DAG:

Task Nodes
    ↓
Dependency Graph
    ↓
DAG Scheduler
    ↓
Agent Workers
    ↓
Independent Verifier
    ↓
Update Task State

而 DSH 的 Workflow 可以概括为：

text 复制代码

Parent Agent
    ↓
Generate Workflow Script
    ↓
Workflow Runtime
    ↓
Subagent Execution
    ↓
Collect Results
    ↓
Parent Agent Continues

需要注意，DSH 的 Workflow Script 可以包含 Conditions、Parallel Execution 和其他控制逻辑，但这并不意味着它默认维护一张持久化的全局 Dynamic DAG。

同样，DSH 的 Plan Mode 主要用于引导 Agent 进行规划，不能直接等同于自动维护 Task Dependency Graph 的 DAG Planner。

两种思路的主要区别如下：

比较维度	Dynamic DAG / Prove2Me 思路	DeepSeek Harness
核心结构	Task Dependency Graph	Plugin-Based Runtime
Dynamic Planning	Runtime 新增 Nodes 和 Edges	根据 Feedback 调整行动或生成 Workflow
Task Scheduling	DAG Scheduler	Agent Loop、Workflow Runtime
Dependency Management	显式 Graph Relationships	Script Control Flow
Parallel Execution	基于 DAG Dependency	`parallel()`、Subagent
Verification	Prove2Me 使用 Lean	根据任务接入相应验证能力
State Management	Task / Dependency State	Session / Workflow State
主要优势	显式依赖与结果复用	灵活编排与插件扩展

这里还需要区分 Verification Mechanism。

在 Prove2Me 中，数学证明由 Lean 进行 Formal Verification，只有满足验证条件的 Proof Artifact 才能被作为可靠成果复用。

而 DSH 是通用 Agent Harness，并没有规定所有任务都必须通过同一种 Formal Verifier。开发者可以根据实际场景接入测试工具或自定义 Verification Mechanism。

从架构设计角度来看，两种方案也并不冲突。

例如，可以将 DSH 作为 Agent Execution Runtime，在其上层增加 Dynamic DAG Scheduler，统一管理 Task Dependencies，再通过 Plugin 接入 Independent Verifier 和 Artifact Store。

这样就可以将 DAG-Based Task Orchestration 与 Plugin-Based Agent Execution 结合起来。

不过，这属于一种可扩展的工程设计方案，并不代表 DSH 官方已经默认实现了完整的 Prove2Me 式 Dynamic DAG。

总结来说，Dynamic DAG 侧重于管理"任务之间的依赖关系"，而 DSH Dynamic Workflow 更侧重于管理"任务如何被组织和执行"。

二者都可以支持复杂的 Multi-Agent Collaboration，但在 Dependency Representation、Execution Control 和 State Management 方面采用了不同的设计思路。

4. Knowledge Point 03：DAG-Based Task Scheduling

DAG 解决的是任务依赖关系，而真正负责执行分配的是 Scheduler。

4.1 Ready Queue

Ready Queue 保存已经满足全部执行条件、但尚未运行的 Task。

一个 Task 可以进入 Ready Queue，通常需要满足：

所有 Dependencies 已通过验证。
当前 Task 没有被其他 Worker 占用。
所需计算资源满足执行条件。
Task 没有处于 Failed 或 Cancelled 等禁止执行状态。

4.2 Parallel Execution

当多个 Task 相互独立时，可以使用 Thread Pool、Process Pool 或 Distributed Workers 进行并行处理。

例如：

text 复制代码

                 Scheduler
                    |
          +---------+---------+
          |         |         |
       Worker A  Worker B  Worker C
          |         |         |
       Task A     Task B    Task C
          |         |         |
          +---------+---------+
                    |
               Verifier

Scheduler 不应简单追求最大 Agent 数量，还需要考虑：

Concurrency Limit
Resource Allocation
Critical Path
Task Priority
Rate Limiting
Backpressure

其中，Critical Path 尤为重要。

对于 DAG，整体完成时间通常受到最长依赖路径的约束，而不只是节点总数。

因此，增加 Worker 数量不一定能持续缩短任务完成时间。

5. Knowledge Point 04：Independent Verification

Independent Verification（独立验证）是 DAG Multi-Agent Architecture 中非常重要的机制。

前面介绍的 Dynamic Planning 和 DAG Scheduling，主要解决的是 Task 如何分解、如何组织 Dependencies，以及如何进行 Parallel Execution。

但这些机制并不能保证 Agent 生成的结果一定正确。

假设某个 Agent 完成了 Task A，并告诉 Scheduler：

Task A has been completed successfully.

Scheduler 是否应该立即将 Task A 标记为完成，并允许依赖它的其他 Task 继续执行？

答案是不一定。

因为 Task Execution Completed 和 Task Result Verified 是两个不同的概念。

这就引出了 Independent Verification。

5.1 为什么不能依赖 Agent 自行判断？

LLM 生成结果具有概率性，其输出可能存在 Hallucination、Logical Error、Incomplete Implementation 等问题。

即使 Agent 声称某个 Task 已经完成，也不能直接认定其结果符合预期。

例如，假设 Agent 正在开发一个 CSV 数据处理程序。

当前任务是：

实现 CSV Encoding Normalization，将不同编码的 CSV 文件统一转换为 UTF-8。

Agent 生成代码并执行后，发现程序没有抛出异常，于是报告：

text 复制代码

Task: Encoding Normalization

Execution Status: Completed

Agent Response:
    Successfully converted all CSV files.

但没有报错，就一定意味着转换正确吗？

不一定。

例如：

Data Corruption：编码转换过程中可能发生字符丢失或替换。
Incomplete Processing：可能只有部分文件成功转换。
Schema Mismatch：转换后的字段结构可能不符合预期。
Silent Failure：程序可能没有报错，但输出结果存在问题。

因此，Agent 判断自己执行成功，并不意味着结果已经满足 Task Requirements。

更重要的是，如果 Scheduler 直接相信 Agent 的完成声明，就可能将错误结果传递给下游 Tasks。

例如：

text 复制代码

Encoding Normalization
         ↓
     Data Cleaning
         ↓
     Data Analysis
         ↓
   Report Generation

如果 Encoding Normalization 产生错误数据，那么后续 Data Cleaning、Data Analysis 和 Report Generation 即使执行成功，也可能建立在错误数据的基础上。

这就是 Error Propagation。

为了解决这个问题，需要引入 Independent Verifier。

text 复制代码

       Agent Worker
            ↓
      Task Execution
            ↓
       Artifact Output
            ↓
     Independent Verifier
            ↓
       Verification
         /       \
       PASS      FAIL
        |          |
        v          v
     VERIFIED    REJECTED
        |
        v
  Unlock Dependencies

这里最关键的变化是：

Agent 负责执行 Task，Verifier 负责判断 Artifact 是否满足预先定义的 Verification Criteria。

在职责上，执行与验证被分离，避免仅凭 Agent 的自我声明决定任务结果是否可以被复用。

需要注意，Independent Verification 不一定意味着必须使用另一个 LLM Agent。

例如，Verifier 可以由以下组件实现：

Compiler：检查 Source Code 是否符合语言要求。
Type Checker：检查类型约束。
Unit Test：验证具体功能是否符合预期。
Schema Validator：验证数据结构。
Checksum Validator：检查数据完整性。
Formal Verification Tool：依据形式化规则验证特定性质。

相比单纯由另一个 LLM 进行主观评价，能够执行明确检查规则的 Verifier 通常更容易提供可复现的 Verification Result。

当然，Verifier 本身也存在能力边界。例如，Unit Test 只能检查测试所覆盖的行为，不能证明整个程序不存在错误。

5.2 Prove2Me 如何实现 Independent Verification？

在 Anthropic 的形式化数学证明案例中，Independent Verification 主要依靠 Lean 4。

Lean 4 是一种支持 Formal Verification 的语言和 Proof Assistant，能够通过 Type Checking 检查形式化证明是否满足指定的 Theorem Statement。

在 Prove2Me 中，Agent 的工作并不是简单地生成自然语言证明，而是生成 Lean 可以检查的 Formal Proof。

例如：

lean 复制代码

theorem add_zero_example (n : Nat) : n + 0 = n := by
  simp

这里：

Theorem Statement ：n + 0 = n，表示需要证明的数学命题。
Proof ：by simp，表示使用 Lean 的证明策略生成证明。
Lean Kernel：最终检查生成的 Proof Term 是否满足相应的类型要求。

如果证明存在逻辑错误或无法完成，Lean 就不会将其当作有效的完整证明接受。

因此，数学证明的有效性不需要完全依赖 Agent 自行判断，而是由 Lean 的 Formal Verification Mechanism 进行检查。

不过，这里还有一个更重要的细节。

验证一个 Parent Theorem 可以从若干 Child Theorems 推出，并不意味着所有 Child Theorems 都已经真正得到证明。

假设：

text 复制代码

Theorem A ──┐
            ├──> Theorem X
Theorem B ──┘

Agent 生成了 Theorem X 的证明，并说明只要 A 和 B 成立，就能推出 X。

Lean 可以检查这个推导关系是否有效。

但是，如果 Theorem A 和 Theorem B 仍然是未完成的证明目标，就不能直接宣布整个证明已经完成。

只有所需的 Child Theorems 最终也得到有效证明，相关 Dependency Chain 才算闭合。

因此，可以区分：

Local Verification：验证当前证明步骤或推导是否成立。
Dependency Verification：检查当前证明依赖的其他 Theorems 是否已经得到证明。
Proof Completion：确认最终目标具有完整、有效的证明。

还需要注意，Lean 验证的是形式化表达及证明在指定逻辑和假设下是否成立，并不自动保证 Agent 选择了最优的 Task Decomposition，也不保证形式化命题准确表达了原本想研究的问题。

这也是为什么在 Prove2Me 的架构中，DAG 和 Verifier 必须协同工作。

DAG 负责管理 Theorem Dependencies，Verifier 负责判断 Proof Artifact 是否有效。

5.3 Independent Verification 如何影响 DAG Scheduling？

前面介绍 DAG Scheduling 时提到，当一个 Task 的 Dependencies 全部满足后，Scheduler 就可以将其加入 Ready Queue。

但现在需要进一步明确：

对于要求独立验证的 Task，Dependency 是否满足，不应该只取决于 Execution 是否结束，还应该取决于 Verification Result。

例如：

text 复制代码

Task A ──┐
         ├──> Task C
Task B ──┘

Task C 依赖 Task A 和 Task B。

假设当前状态为：

text 复制代码

Task A: VERIFIED
Task B: COMPLETED
Task C: BLOCKED

虽然 Task A 和 Task B 都已经执行完成，但 Task B 还没有经过 Verification。

因此，Task C 仍然不能进入 Ready State。

只有当：

text 复制代码

Task A: VERIFIED
Task B: VERIFIED

并且其他执行条件也已经满足时，Scheduler 才能将 Task C 置为 READY。

这样就可以避免未经验证的 Artifact 直接进入后续执行流程。

在工程实现中，可以将 Task State Machine 设计为：

text 复制代码

PENDING
   ↓
READY
   ↓
RUNNING
   ↓
COMPLETED
   ↓
VERIFYING
   ├── PASS → VERIFIED
   |
   └── FAIL → REJECTED / RETRY

这里的 COMPLETED 表示执行已经结束，但尚未通过最终验证。

只有 VERIFIED 才表示相应的 Verification Criteria 已经满足。

在实际系统中，Verifier 还可以生成 Verification Report，记录：

Task ID：被验证的 Task。
Artifact ID：被验证的执行产物。
Verification Rules：使用的检查规则。
Verification Result：验证是否通过。
Failure Reason：验证失败的原因。
Verification Timestamp：验证时间。

这些信息可以与 Artifact 一起保存，供其他 Agent、Scheduler 和后续审计流程使用。

对于复杂 Multi-Agent System，这种机制具有两个重要价值。

第一，减少 Error Propagation。

未经验证的执行结果不会被直接作为可靠 Dependency Result 使用。

第二，支持 Artifact Reuse。

当某个 Artifact 已经通过 Verification，并且其适用条件与版本仍然有效时，后续 Agent 可以直接搜索和复用这个结果，而不必重复完成相同任务。

因此，Independent Verification 不仅是一个质量检查环节，更是连接 Task Execution、Dependency Resolution、Artifact Management 和 DAG Scheduling 的重要机制。

总结来说，Dynamic Planning 解决的是如何发现和组织新的任务，DAG Scheduling 解决的是任务何时能够执行，而 Independent Verification 解决的是执行结果何时可以被信任和复用。

只有将这些机制结合起来，Multi-Agent System 才能在长期、复杂的任务执行过程中，更可靠地管理任务依赖和成果复用。