ChatDev (DevAll 2.0) — 架构与原理
30 秒导读: ChatDev 2.0(代号 DevAll)不再是「一家 写代码的虚拟软件公司」,而是一个零代码多智能体编排平台。你用一份 YAML 描述「哪些 agent、谁连谁、什么条件下传给谁、循环几次」,它就把这张图跑起来。经典的「CEO→程序员→测试→复审」软件开发流程,在 2.0 里只是这张图的一个 YAML 实例(
yaml_instance/ChatDev_v1.yaml)。
本项目较大,拆成 index + 5 章。本页讲清「这是什么 / 大盘怎么转」,各机制细节进对应章节。
1. 这是什么(零基础也能懂)
一句话定义。 ChatDev 2.0 是一个把多智能体协作流程画成有向图、再用 YAML 描述、由一个执行器跑起来的平台。
它解决谁的什么问题。 假设你想搭一套「多个 AI 角色分工协作」的系统——比如一个负责写代码、一个负责复审、一个负责测试,出错就打回重写,循环几轮直到通过。手写这套调度逻辑(谁先跑、什么时候停、消息怎么传)既繁琐又容易错。ChatDev 2.0 让你不写编排代码:把角色写成节点、把协作关系写成边、把「循环几次」写成一个计数器节点,平台负责调度。
版本是个大转折(必须先说清)。 2.0 是一次彻底重写,和大众熟悉的 1.0 不是同一套代码:
| ChatDev 1.0(legacy 分支) | ChatDev 2.0 / DevAll(本仓 main) | |
|---|---|---|
| 定位 | 虚拟软件公司,专做软件开发 | 通用多智能体编排平台(Developing Everything) |
| 怎 么定制 | 改 ChatChainConfig.json + Phase/Role 代码 | 写一份描述图的 YAML,零代码 |
| 核心抽象 | ChatChain(链式 Phase) | 任意拓扑的工作流图(DAG / 带环 / 多数投票) |
| 软件开发流程 | 内建 | 退化成一个 YAML 实例 ChatDev_v1.yaml |
本文档讲的是 2.0 / DevAll(commit 4fd4da60)。
用起来什么样。 命令行入口 run.py:挑一份 YAML(图)、给项目名、输入任务,就开跑。
# 示意,真实参数见 run.py:38-75 的 argparse
python run.py --path yaml_instance/ChatDev_v1.yaml --name my_app
# 然后交互式输入任务:
# Please enter the task prompt: 做一个贪吃蛇游戏
run.py:94-117 做的事:load_config 读 YAML → GraphConfig.from_definition 建图配置 → GraphContext 包一层运行态 → GraphExecutor.execute_graph(...) 真正执行。
一句话直觉。 把它想成 「给多智能体用的流程图编译器 + 解释器」:YAML 是源码,图是 AST,GraphExecutor 是解释器,节点是指令,边是带条件的跳转 + 数据搬运。
本节不碰底层代码。下面进顶层全景。
2. 顶层全景(它大概怎么转)
2.1 一张图看懂数据流
怎么读这张图:从上到下是一次运行的生命周期,左边是「配置态」(读 YAML、建图),右边是「运行态」(执行器调度节点)。
YAML 文件 (yaml_instance/*.yaml)
│ load_config() ← check/check.py
▼
DesignDefinition ──► GraphConfig ──► GraphContext
│ (节点定义 / 边定义 / vars / start / end) ← entity/graph_config.py
▼
┌─────────────────── GraphExecutor.run() ───────────────────┐
│ │
│ ① GraphManager.build_graph() │
│ · 实例化节点、连边、检测环、算拓扑分层 │
│ ② 建 memory / thinking / 各类型 node executor │
│ ③ 选执行策略: │
│ DAG ──► 分层并行 带环 ──► 超节点调度 投票 ──► 全并行 │
│ ④ 逐节点 execute: │
│ node executor 产出 Message │
│ → 对每条出边跑「条件 + 搬数据 + 触发」 │
│ → 命中的目标节点入队、被点亮(triggered) │
└────────────────────────────────────────────────────────────┘
│
▼
final_node 的最后一条输出 = 整图结果 ← graph.final_message()
2.2 部件一句话职责
| 部件 | 干什么 | 在哪个文件 |
|---|---|---|
run.py / server_main.py | CLI 入口 / FastAPI 服务入口 | run.py、server_main.py |
load_config | 把 YAML 解析成 DesignDefinition | check/check.py |
GraphConfig / GraphContext | 图的配置态与运行态(节点、边、vars、目录) | entity/graph_config.py、workflow/graph_context.py |
GraphManager | 建图:实例化节点、连边、检 测环、分层 | workflow/graph_manager.py |
GraphExecutor | 总调度器:选策略、逐节点跑、处理出边 | workflow/graph.py |
| 执行策略 | DAG / Cycle / MajorityVote 三种跑法 | workflow/runtime/execution_strategy.py |
| Node executor | 每种节点类型(agent/loop/human/python…)的实际执行逻辑 | runtime/node/executor/*.py |
| Edge condition / processor | 出边的「放不放行」与「怎么改写 payload」 | runtime/edge/conditions/*、runtime/edge/processors/* |
| Provider | 真正调 LLM(OpenAI / Gemini) | runtime/node/agent/providers/* |
| Tool manager | 执行 function-calling 工具 | runtime/node/agent/tool/tool_manager.py |
2.3 主线走一遍(高层,不进代码)
以 ChatDev_v1.yaml(软件开发流程)为例,一次运行的高层叙事:
- 用户任务从
start节点(USER、Coding Phase Prompt for Assistant)注入。 Programmer Coding(agent 节点)调 LLM、调工具把代码写进工作区。- 输出沿边流向
Code Review/Test阶段;每个阶段挂一个loop_counter节点,它先「吞掉」输出 N 次,达到上限才放行——这就是「复审/测试循环 N 轮」的实现。 - 边上的
keyword条件(如出现<INFO> Finished)决定是否跳出循环、进入下一阶段。 - 最后流到
FINAL(passthrough 节点),它的输出即整图结果。
关键认知:这张图里没有「主控大脑」按剧本调度。 调度完全是数据驱动 + 拓扑驱动:节点被「点亮(triggered)」才执行,边的条件决定数据往哪走,循环靠计数器节点而非中央 for 循环。理解这点,就理解了 2.0 的全部精髓。
3. 阅读地图(建议顺序)
| 想搞懂的问题 | 去哪章 |
|---|---|
| 节点/边到底是什么数据结构?trigger 和 condition 有什么区别? | 01 — 图模型 |
| 执行器怎么决定先跑谁?循环和环是怎么跑的? | 02 — 执行引擎 |
| 一个 agent 节点内部,一次 LLM 调用经历了什么? | 03 — agent 节点 |
| context_window / keep_message / clear_context / 扇出(map/tree)怎么玩? | 04 — 上下文与路由 |
| 代码地图、巧妙之处、边界、和兄弟项目比 | 05 — 地图与边界 |
全部引用 as-of commit
4fd4da603801766b14ad8788649cfc1ad21f99a6。