ChatDev 2.0 Literal 节点深度实战固定文本注入、条件分支响应与流程初始化的完整实现指南【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/GitHub_Trending/ch/ChatDev本文基于 ChatDev 2.0 多智能体协作工作流引擎系统讲解literal字面量节点它如何在任意时刻忽略上游输入、稳定输出预定义文本以及如何借助role角色标记影响下游 Agent 的消息处理。读完本文你将掌握 literal 节点的全部配置字段、源码级校验规则与执行原理并能在固定提示注入、条件分支兜底响应、循环工作流初始化、下游逻辑测试等场景中直接落地可用。Literal 节点概述工作流中的常量节点在 ChatDev 2.0 的图工作流Graph Workflow中节点是执行的基本单元节点之间通过有向边edge传递消息Message。literal节点是其中最简单却也最常用的一类当节点被触发时它忽略所有输入直接输出一段预定义的消息内容。这一行为特性可以类比编程语言中的常量——无论上下文如何变化literal节点的输出始终是同一段文本。从 节点注册源码 可以看到它的官方定义为Emits the configured text message every time it is triggered每次被触发时发出配置好的文本消息与agent节点依赖 LLM 生成、消耗 Token、支持工具与记忆不同literal节点不调用任何模型、不消耗 Token、无网络请求纯粹是确定性的本地输出。因此它也是调试工作流、隔离下游逻辑问题时最可靠的工具之一。三种转发型节点的差异对比在 ChatDev 2.0 的节点家族中有几个节点容易被混淆这里做一个源码层面的区分见 builtin_nodes.py节点类型行为典型用途literal忽略输入输出固定文本固定提示注入、默认响应、流程初始化passthrough将上游节点输出原样转发不做修改透传、汇聚后的转发agent调用 LLM 生成回复可挂载工具/记忆/思考核心对话与推理配置项详解字段、类型与源码校验规则literal节点的配置非常精简只有两个字段。下表完整继承自 官方文档字段类型必填默认值说明contenttext是-输出的固定文本内容不能为空rolestring否user消息角色user或assistant源码中的配置校验逻辑这两个字段并非简单透传而是经过严格的运行时校验。在 entity/configs/node/literal.py 的LiteralNodeConfig.from_dict与validate方法中content require_str(mapping, content, path) if not content: raise ConfigError(content cannot be empty, f{path}.content) role_value optional_str(mapping, role, path) role MessageRole.USER if role_value: normalized role_value.strip().lower() if normalized not in (MessageRole.USER.value, MessageRole.ASSISTANT.value): raise ConfigError(role must be user or assistant, f{path}.role) role MessageRole(normalized)从中可以提炼出三个关键约束content非空空字符串或缺失content会在配置解析阶段直接抛出ConfigError错误路径指向content字段而不是等到运行期才发现role大小写不敏感配置中写User、USER、user都会被strip().lower()归一化为user但仅允许user与assistant两个合法值其他取值如system会报错role可省略省略时默认取MessageRole.USER即user。此外FIELD_SPECS 中还为两个字段声明了 UI 层面的元信息显示名、类型提示、必填性、默认值、枚举选项等这意味着前端可视化工作台如WorkflowWorkbench会根据这份规格自动渲染表单让用户在界面上就能以单选下拉的方式选择角色从源头避免非法取值。核心概念固定输出与消息角色固定输出literal节点的核心特性可以概括为三点忽略输入不管上游传入什么内容都不影响输出。执行器甚至不读取inputs参数固定内容每次执行都输出相同的content确定性输出、可重复执行角色标记输出的消息携带指定的角色标识供下游节点识别消息来源性质。对应地在 runtime/node/executor/literal_executor.py 中执行逻辑与这三个特性一一对应def execute(self, node: Node, inputs: List[Message]) - List[Message]: if node.node_type ! literal: raise ValueError(fNode {node.id} is not a literal node) config node.as_config(LiteralNodeConfig) if config is None: raise ValueError(fNode {node.id} missing literal configuration) self._ensure_not_cancelled() return [self._build_message( roleconfig.role, contentconfig.content, sourcenode.id, preserve_roleTrue, )]这段代码值得注意的细节有入参inputs被完全忽略输出只与config.content和config.role有关self._ensure_not_cancelled()会在执行前检查工作流取消事件cancel_event若任务被取消则抛出WorkflowCancelledError参见 base.py保证节点可被安全中断preserve_roleTrue表示该消息的角色标记在后续传递过程中保持不被改写这是 literal 节点区别于普通 agent 输出的重要标志。消息角色ChatDev 2.0 内部使用统一的MessageRole枚举见 entity/messages.py包含四个取值class MessageRole(str, Enum): SYSTEM system USER user ASSISTANT assistant TOOL tool而literal节点只允许配置前两者之一user表示这是用户发出的消息。典型场景是向工作流注入用户提问或用户指令assistant表示这是助手AI发出的消息。典型场景是作为 Agent 的默认回复或角色扮演输出。角色设置会影响下游节点对消息的处理方式。以agent节点为例在 agent_executor.py 中输入消息会按其角色被组装进对话历史conversationuser角色的消息会被当作待回答的提问进入上下文而assistant角色的消息则会作为已有回复参与多轮对话的组织。若角色标错例如把用户指令标成assistant下游 Agent 可能将其理解为已存在的回答而不是待执行的指令从而改变整个对话走向。何时使用 Literal 节点基于上述特性literal节点在以下四类场景中最有价值固定提示注入向流程中注入固定的指令、系统约束或上下文规则且不希望被上游内容干扰测试调试使用固定输入测试下游节点的处理逻辑排除上游随机性快速定位问题默认响应在特定条件下如意图分类结果不明确时返回固定兜底消息流程初始化作为工作流的起点提供初始内容充当入口种子。此外由于literal不依赖任何外部服务它还是工作流单元测试与 CI 验证中的理想桩stub节点——即便模型服务不可用也能完整跑通图的拓扑与边逻辑。实战示例四类核心用法以下示例均取自并完整覆盖 官方文档可直接复制到工作流 YAML 中使用。基础用法最简单的literal节点输出一句欢迎语角色标记为assistant。nodes: - id: Welcome Message type: literal config: content: | 欢迎使用智能助手请描述您的需求。 role: assistant注意这里使用了 YAML 的块标量语法|可以原样保留换行与缩进适合书写多行长文本。注入固定上下文把固定的行为规则注入到 Agent 之前用role: user让它作为用户指令进入对话上下文随后由agent节点消费nodes: - id: Context Injector type: literal config: content: | 请注意以下规则 1. 回答必须简洁明了 2. 使用中文回复 3. 如有不确定请说明 role: user - id: Assistant type: agent config: provider: openai name: gpt-4o edges: - from: Context Injector to: Assistant条件分支中的固定响应literal节点最常见的进阶用法是与条件边Conditional Edge配合实现分支兜底。下面的例子中分类 Agent 输出KNOWN或UNKNOWN两条keyword条件边分别把不同结果路由到两个literal节点返回固定话术nodes: - id: Classifier type: agent config: provider: openai name: gpt-4o role: 判断用户意图回复 KNOWN 或 UNKNOWN - id: Known Response type: literal config: content: 我能帮助您完成这个任务。 role: assistant - id: Unknown Response type: literal config: content: 抱歉我无法理解您的请求请换一种方式描述。 role: assistant edges: - from: Classifier to: Known Response condition: type: keyword config: any: [KNOWN] - from: Classifier to: Unknown Response condition: type: keyword config: any: [UNKNOWN]这里的condition.type: keyword是 ChatDev 2.0 内置的条件类型之一。从 runtime/edge/conditions/builtin_types.py 的注册信息看keyword类型基于包含/排除关键词或正则匹配做声明式判断any列表中的任意关键词命中即放行。把literal与条件边组合就能构建出不消耗任何 LLM 调用的确定性分支响应既省 Token 又稳定。测试用途使用literal提供固定输入验证下游python节点的处理逻辑。start: [Test Input]显式声明了工作流入口nodes: - id: Test Input type: literal config: content: | 这是一段测试文本用于验证下游处理逻辑。 包含多行内容。 role: user - id: Processor type: python config: timeout_seconds: 30 edges: - from: Test Input to: Processor start: [Test Input]仓库真实案例Literal 在循环与动态工作流中的应用literal节点并非仅存在于文档示例中在当前仓库的多个真实工作流 YAML 里都有实际应用可作为进阶参考。循环工作流中的角色分工在 yaml_instance/demo_loop_counter.yaml 中literal节点承担了作家与评论家两个角色配合loop_counter节点实现写作-评审-修订的循环- id: Writer type: literal description: Responsible for outputting a fixed draft. config: content: Draft iteration from Writer role: assistant - id: Critic type: literal description: Simulates human feedback, always requesting further revisions. config: content: Please revise again role: user可以看到一个非常典型的分工模式Writer 输出assistant角色的草稿Critic 输出user角色的评审意见两者在Writer - Critic - Writer的循环边中交替传递最后由Loop Gateloop_counter在第三次迭代时放行至Finalizer同样是 literal 节点输出最终结论。description字段在这里也起到了文档化作用值得在复杂图中沿用。动态工作流中的多路入口种子在 yaml_instance/demo_dynamic.yaml 中多个literal节点被用作动态图Dynamic Map/Tree的多路起始输入每个入口注入一段独立的用户请求如规划上海游玩项目规划交通方式规划住宿再由动态节点并行分发处理- id: B type: literal config: content: Please plan what to do for fun in Shanghai for me. role: user - id: D type: literal config: content: - Please plan how to get around in Shanghai for me (public transportation, taxis, car rentals, etc.). role: user这段 YAML 还展示了两个值得注意的写法一是role省略时默认即为user此处显式写出便于阅读二是使用了-折叠标量语法写长文本与|保留换行形成对比两者可依据文本是否含换行来选择。其他使用literal的真实示例还包括 yaml_instance/demo_edge_transform.yaml 与 yaml_instance/ChatDev_v1.yaml 等读者可按需查阅。源码级实现剖析从配置解析到执行器为了更深入地理解 literal 节点下面沿注册 → 配置 → 执行三个环节梳理完整实现链路。1. 节点类型注册所有内置节点在 runtime/node/builtin_nodes.py 中统一注册。literal的注册信息为register_node_type( literal, config_clsLiteralNodeConfig, executor_clsLiteralNodeExecutor, capabilitiesNodeCapabilities(), summaryEmits the configured text message every time it is triggered, )config_cls负责 YAML 配置的解析与校验executor_cls负责运行期执行两者通过register_node_type绑定到字符串标识literal这也是 YAML 中type: literal能正确解析到对应实现的依据。2. 配置解析与校验LiteralNodeConfig 是一个dataclass包含content: str 与role: MessageRole MessageRole.USER两个字段。from_dict在加载 YAML 时执行用require_str强制content为字符串空内容直接抛出ConfigError(content cannot be empty)role先做小写归一化再与枚举值比对非法值抛出ConfigError(role must be user or assistant)。这样绝大多数配置错误在加载阶段即可暴露而不是在运行中途才失败。3. 运行期执行LiteralNodeExecutor 继承自NodeExecutor见 base.py实现统一的execute(node, inputs)接口。执行流程为校验node.node_type literal否则抛ValueError通过node.as_config(LiteralNodeConfig)取出配置_ensure_not_cancelled()检查取消事件调用基类_build_message构造单条消息返回。其中_build_message见 base.py会把node.id写入消息的metadata.source便于日志追踪与消息溯源返回的单元素列表会沿边继续传递给下游节点。注意事项content字段不能为空字符串否则配置加载阶段即报错如需输出空消息请改用其他节点如passthrough或重新设计图结构使用 YAML 多行字符串语法|便于编写长文本保留换行若需单行折叠文本可使用-选择正确的role以确保下游节点正确处理消息——user适合注入指令与问题assistant适合输出回复与默认话术literal是确定性节点不消耗 LLM Token在需要保证分支必有输出的地方如条件分支的兜底路径优先使用它可以显著提升工作流的稳定性与可测试性在执行器层面literal 输出带preserve_roleTrue角色在传递中不会被改写。延伸阅读节点总览文档了解与之配套的 Agent、Python、Human 等节点工作流编写指南YAML 图的整体结构与编写规范执行逻辑文档节点与边的运行时执行机制动态执行文档dynamic 图与多路入口的进阶用法LiteralNodeConfig 源码配置字段与校验逻辑LiteralNodeExecutor 源码执行器实现循环工作流示例literal 在循环中的真实用法【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/GitHub_Trending/ch/ChatDev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ChatDev 2.0 Literal 节点深度实战：固定文本注入、条件分支响应与流程初始化的完整实现指南
ChatDev 2.0 Literal 节点深度实战固定文本注入、条件分支响应与流程初始化的完整实现指南【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/GitHub_Trending/ch/ChatDev本文基于 ChatDev 2.0 多智能体协作工作流引擎系统讲解literal字面量节点它如何在任意时刻忽略上游输入、稳定输出预定义文本以及如何借助role角色标记影响下游 Agent 的消息处理。读完本文你将掌握 literal 节点的全部配置字段、源码级校验规则与执行原理并能在固定提示注入、条件分支兜底响应、循环工作流初始化、下游逻辑测试等场景中直接落地可用。Literal 节点概述工作流中的常量节点在 ChatDev 2.0 的图工作流Graph Workflow中节点是执行的基本单元节点之间通过有向边edge传递消息Message。literal节点是其中最简单却也最常用的一类当节点被触发时它忽略所有输入直接输出一段预定义的消息内容。这一行为特性可以类比编程语言中的常量——无论上下文如何变化literal节点的输出始终是同一段文本。从 节点注册源码 可以看到它的官方定义为Emits the configured text message every time it is triggered每次被触发时发出配置好的文本消息与agent节点依赖 LLM 生成、消耗 Token、支持工具与记忆不同literal节点不调用任何模型、不消耗 Token、无网络请求纯粹是确定性的本地输出。因此它也是调试工作流、隔离下游逻辑问题时最可靠的工具之一。三种转发型节点的差异对比在 ChatDev 2.0 的节点家族中有几个节点容易被混淆这里做一个源码层面的区分见 builtin_nodes.py节点类型行为典型用途literal忽略输入输出固定文本固定提示注入、默认响应、流程初始化passthrough将上游节点输出原样转发不做修改透传、汇聚后的转发agent调用 LLM 生成回复可挂载工具/记忆/思考核心对话与推理配置项详解字段、类型与源码校验规则literal节点的配置非常精简只有两个字段。下表完整继承自 官方文档字段类型必填默认值说明contenttext是-输出的固定文本内容不能为空rolestring否user消息角色user或assistant源码中的配置校验逻辑这两个字段并非简单透传而是经过严格的运行时校验。在 entity/configs/node/literal.py 的LiteralNodeConfig.from_dict与validate方法中content require_str(mapping, content, path) if not content: raise ConfigError(content cannot be empty, f{path}.content) role_value optional_str(mapping, role, path) role MessageRole.USER if role_value: normalized role_value.strip().lower() if normalized not in (MessageRole.USER.value, MessageRole.ASSISTANT.value): raise ConfigError(role must be user or assistant, f{path}.role) role MessageRole(normalized)从中可以提炼出三个关键约束content非空空字符串或缺失content会在配置解析阶段直接抛出ConfigError错误路径指向content字段而不是等到运行期才发现role大小写不敏感配置中写User、USER、user都会被strip().lower()归一化为user但仅允许user与assistant两个合法值其他取值如system会报错role可省略省略时默认取MessageRole.USER即user。此外FIELD_SPECS 中还为两个字段声明了 UI 层面的元信息显示名、类型提示、必填性、默认值、枚举选项等这意味着前端可视化工作台如WorkflowWorkbench会根据这份规格自动渲染表单让用户在界面上就能以单选下拉的方式选择角色从源头避免非法取值。核心概念固定输出与消息角色固定输出literal节点的核心特性可以概括为三点忽略输入不管上游传入什么内容都不影响输出。执行器甚至不读取inputs参数固定内容每次执行都输出相同的content确定性输出、可重复执行角色标记输出的消息携带指定的角色标识供下游节点识别消息来源性质。对应地在 runtime/node/executor/literal_executor.py 中执行逻辑与这三个特性一一对应def execute(self, node: Node, inputs: List[Message]) - List[Message]: if node.node_type ! literal: raise ValueError(fNode {node.id} is not a literal node) config node.as_config(LiteralNodeConfig) if config is None: raise ValueError(fNode {node.id} missing literal configuration) self._ensure_not_cancelled() return [self._build_message( roleconfig.role, contentconfig.content, sourcenode.id, preserve_roleTrue, )]这段代码值得注意的细节有入参inputs被完全忽略输出只与config.content和config.role有关self._ensure_not_cancelled()会在执行前检查工作流取消事件cancel_event若任务被取消则抛出WorkflowCancelledError参见 base.py保证节点可被安全中断preserve_roleTrue表示该消息的角色标记在后续传递过程中保持不被改写这是 literal 节点区别于普通 agent 输出的重要标志。消息角色ChatDev 2.0 内部使用统一的MessageRole枚举见 entity/messages.py包含四个取值class MessageRole(str, Enum): SYSTEM system USER user ASSISTANT assistant TOOL tool而literal节点只允许配置前两者之一user表示这是用户发出的消息。典型场景是向工作流注入用户提问或用户指令assistant表示这是助手AI发出的消息。典型场景是作为 Agent 的默认回复或角色扮演输出。角色设置会影响下游节点对消息的处理方式。以agent节点为例在 agent_executor.py 中输入消息会按其角色被组装进对话历史conversationuser角色的消息会被当作待回答的提问进入上下文而assistant角色的消息则会作为已有回复参与多轮对话的组织。若角色标错例如把用户指令标成assistant下游 Agent 可能将其理解为已存在的回答而不是待执行的指令从而改变整个对话走向。何时使用 Literal 节点基于上述特性literal节点在以下四类场景中最有价值固定提示注入向流程中注入固定的指令、系统约束或上下文规则且不希望被上游内容干扰测试调试使用固定输入测试下游节点的处理逻辑排除上游随机性快速定位问题默认响应在特定条件下如意图分类结果不明确时返回固定兜底消息流程初始化作为工作流的起点提供初始内容充当入口种子。此外由于literal不依赖任何外部服务它还是工作流单元测试与 CI 验证中的理想桩stub节点——即便模型服务不可用也能完整跑通图的拓扑与边逻辑。实战示例四类核心用法以下示例均取自并完整覆盖 官方文档可直接复制到工作流 YAML 中使用。基础用法最简单的literal节点输出一句欢迎语角色标记为assistant。nodes: - id: Welcome Message type: literal config: content: | 欢迎使用智能助手请描述您的需求。 role: assistant注意这里使用了 YAML 的块标量语法|可以原样保留换行与缩进适合书写多行长文本。注入固定上下文把固定的行为规则注入到 Agent 之前用role: user让它作为用户指令进入对话上下文随后由agent节点消费nodes: - id: Context Injector type: literal config: content: | 请注意以下规则 1. 回答必须简洁明了 2. 使用中文回复 3. 如有不确定请说明 role: user - id: Assistant type: agent config: provider: openai name: gpt-4o edges: - from: Context Injector to: Assistant条件分支中的固定响应literal节点最常见的进阶用法是与条件边Conditional Edge配合实现分支兜底。下面的例子中分类 Agent 输出KNOWN或UNKNOWN两条keyword条件边分别把不同结果路由到两个literal节点返回固定话术nodes: - id: Classifier type: agent config: provider: openai name: gpt-4o role: 判断用户意图回复 KNOWN 或 UNKNOWN - id: Known Response type: literal config: content: 我能帮助您完成这个任务。 role: assistant - id: Unknown Response type: literal config: content: 抱歉我无法理解您的请求请换一种方式描述。 role: assistant edges: - from: Classifier to: Known Response condition: type: keyword config: any: [KNOWN] - from: Classifier to: Unknown Response condition: type: keyword config: any: [UNKNOWN]这里的condition.type: keyword是 ChatDev 2.0 内置的条件类型之一。从 runtime/edge/conditions/builtin_types.py 的注册信息看keyword类型基于包含/排除关键词或正则匹配做声明式判断any列表中的任意关键词命中即放行。把literal与条件边组合就能构建出不消耗任何 LLM 调用的确定性分支响应既省 Token 又稳定。测试用途使用literal提供固定输入验证下游python节点的处理逻辑。start: [Test Input]显式声明了工作流入口nodes: - id: Test Input type: literal config: content: | 这是一段测试文本用于验证下游处理逻辑。 包含多行内容。 role: user - id: Processor type: python config: timeout_seconds: 30 edges: - from: Test Input to: Processor start: [Test Input]仓库真实案例Literal 在循环与动态工作流中的应用literal节点并非仅存在于文档示例中在当前仓库的多个真实工作流 YAML 里都有实际应用可作为进阶参考。循环工作流中的角色分工在 yaml_instance/demo_loop_counter.yaml 中literal节点承担了作家与评论家两个角色配合loop_counter节点实现写作-评审-修订的循环- id: Writer type: literal description: Responsible for outputting a fixed draft. config: content: Draft iteration from Writer role: assistant - id: Critic type: literal description: Simulates human feedback, always requesting further revisions. config: content: Please revise again role: user可以看到一个非常典型的分工模式Writer 输出assistant角色的草稿Critic 输出user角色的评审意见两者在Writer - Critic - Writer的循环边中交替传递最后由Loop Gateloop_counter在第三次迭代时放行至Finalizer同样是 literal 节点输出最终结论。description字段在这里也起到了文档化作用值得在复杂图中沿用。动态工作流中的多路入口种子在 yaml_instance/demo_dynamic.yaml 中多个literal节点被用作动态图Dynamic Map/Tree的多路起始输入每个入口注入一段独立的用户请求如规划上海游玩项目规划交通方式规划住宿再由动态节点并行分发处理- id: B type: literal config: content: Please plan what to do for fun in Shanghai for me. role: user - id: D type: literal config: content: - Please plan how to get around in Shanghai for me (public transportation, taxis, car rentals, etc.). role: user这段 YAML 还展示了两个值得注意的写法一是role省略时默认即为user此处显式写出便于阅读二是使用了-折叠标量语法写长文本与|保留换行形成对比两者可依据文本是否含换行来选择。其他使用literal的真实示例还包括 yaml_instance/demo_edge_transform.yaml 与 yaml_instance/ChatDev_v1.yaml 等读者可按需查阅。源码级实现剖析从配置解析到执行器为了更深入地理解 literal 节点下面沿注册 → 配置 → 执行三个环节梳理完整实现链路。1. 节点类型注册所有内置节点在 runtime/node/builtin_nodes.py 中统一注册。literal的注册信息为register_node_type( literal, config_clsLiteralNodeConfig, executor_clsLiteralNodeExecutor, capabilitiesNodeCapabilities(), summaryEmits the configured text message every time it is triggered, )config_cls负责 YAML 配置的解析与校验executor_cls负责运行期执行两者通过register_node_type绑定到字符串标识literal这也是 YAML 中type: literal能正确解析到对应实现的依据。2. 配置解析与校验LiteralNodeConfig 是一个dataclass包含content: str 与role: MessageRole MessageRole.USER两个字段。from_dict在加载 YAML 时执行用require_str强制content为字符串空内容直接抛出ConfigError(content cannot be empty)role先做小写归一化再与枚举值比对非法值抛出ConfigError(role must be user or assistant)。这样绝大多数配置错误在加载阶段即可暴露而不是在运行中途才失败。3. 运行期执行LiteralNodeExecutor 继承自NodeExecutor见 base.py实现统一的execute(node, inputs)接口。执行流程为校验node.node_type literal否则抛ValueError通过node.as_config(LiteralNodeConfig)取出配置_ensure_not_cancelled()检查取消事件调用基类_build_message构造单条消息返回。其中_build_message见 base.py会把node.id写入消息的metadata.source便于日志追踪与消息溯源返回的单元素列表会沿边继续传递给下游节点。注意事项content字段不能为空字符串否则配置加载阶段即报错如需输出空消息请改用其他节点如passthrough或重新设计图结构使用 YAML 多行字符串语法|便于编写长文本保留换行若需单行折叠文本可使用-选择正确的role以确保下游节点正确处理消息——user适合注入指令与问题assistant适合输出回复与默认话术literal是确定性节点不消耗 LLM Token在需要保证分支必有输出的地方如条件分支的兜底路径优先使用它可以显著提升工作流的稳定性与可测试性在执行器层面literal 输出带preserve_roleTrue角色在传递中不会被改写。延伸阅读节点总览文档了解与之配套的 Agent、Python、Human 等节点工作流编写指南YAML 图的整体结构与编写规范执行逻辑文档节点与边的运行时执行机制动态执行文档dynamic 图与多路入口的进阶用法LiteralNodeConfig 源码配置字段与校验逻辑LiteralNodeExecutor 源码执行器实现循环工作流示例literal 在循环中的真实用法【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/GitHub_Trending/ch/ChatDev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考