ChatDev Passthrough 透传节点完全指南理线、上下文控制与循环输出过滤实战【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/GitHub_Trending/ch/ChatDevPassthrough透传节点是 ChatDev 2.0 多 Agent 协作工作流中最简单却最实用的一类节点它不做任何计算只负责把上游消息原样转交下游并通过only_last_message参数充当上下文阀门。本文基于官方中文文档 docs/user_guide/zh/nodes/passthrough.md 展开结合仓库源码与真实 YAML 案例系统讲解它的配置字段、透传语义、三类核心实战场景入口上下文保留、循环冗余过滤、条件路由理线与工程最佳实践读完即可在自己的工作流中正确驾驭它。Passthrough 节点是什么在 ChatDev 的节点体系里runtime/node/builtin_nodes.py 将每个可用的工作流节点类型统一注册为配置类 执行器类的组合其中passthrough的注册摘要只有一句话Forwards prior node output downstream without modification把上游节点输出原样转发给下游不做任何修改。这意味着 Passthrough 节点接收上游传入的所有消息默认只传递最后一条消息only_last_message: true设置only_last_message: false时传递所有消息不做任何内容处理或转换。它没有 LLM 调用、没有工具执行、没有记忆读写是整个工作流中执行代价最低的节点类型。透传行为的源码级印证执行逻辑位于 runtime/node/executor/passthrough_executor.py核心代码如下if config.only_last_message: if len(inputs) 1: self.log_manager.debug( fPassthrough node {node.id} received {len(inputs)} inputs; forwarding the latest entry, node_idnode.id, details{input_count: len(inputs)}, ) return [inputs[-1].clone()] else: return [msg.clone() for msg in inputs]从源码可以确认三个关键实现细节最后一条是严格取inputs[-1]即按输入消息列表的先后顺序取最后一条无论是只传最后一条还是传全部消息都通过clone()深拷贝后再下发见 entity/messages.py 中Message.clone()的实现保证下游对消息的任何改动都不会反向污染上游若节点在无输入的情况下被触发会记录一条 warning 日志并返回一个空内容、USER角色的占位消息避免执行链路中断。此外消息对象本身带有keep标记字段entity/messages.py 中Message.keep配合边的keep_message配置可以控制上下文是否常驻这正是 Passthrough 参与上下文控制的底层机制之一。配置项与默认值Passthrough 的配置由 entity/configs/node/passthrough.py 中的PassthroughConfig定义这是全工作流配置面最精简的节点之一字段类型必填默认值说明only_last_messagebool否true是否只传递最后一条消息。设为false时传递所有消息。配置解析细节from_dict中当config字段缺失或为None时直接使用默认值only_last_messageTrue传入的配置必须是一个 mapping字典only_last_message则通过optional_bool解析非法类型会报错而非静默忽略。基本配置默认行为config: {} # 使用默认配置只传递最后一条消息传递所有消息config: only_last_message: false # 传递所有接收到的消息Web UI 中的对应形态在 Web 工作台前端位于 frontend/src/pages/WorkflowWorkbench.vue中Passthrough 节点只有一个开关型配置项Only Last Message与FIELD_SPECS中声明的only_last_message显示名 Only Last Message类型 bool默认 true一一对应。由于该节点没有role、provider、tooling等字段它是创建多分支工作流时最轻量的接线元件。核心价值图结构优化理线Passthrough 节点的核心价值不在于数据处理而在于图结构的优化理线使复杂的边连接更加清晰集中管理出边配置如keep_message作为逻辑分界点提高工作流可读性。在 ChatDev 的真实工作流中这一点体现得尤为明显。yaml_instance/ChatDev_v1.yaml 的顶层图中定义了USER、PSEUDO、FINAL三个 Passthrough 节点USER作为图入口的任务代理接收外部输入后再按边分发给规划、编码、评审等角色FINAL作为收敛出口把多路结果汇合为最终交付它们把谁来接收外部输入谁代表最终输出这两个拓扑职责与具体业务节点解耦。再比如 yaml_instance/subgraphs/reflexion_loop.yaml 中子图入口就是一个名为Task的 Passthrough 节点- id: Task type: passthrough config: {}随后从Task出发的两条边都配置了keep_message: True把用户原始任务同时常驻在 Actor 与 Evaluator 的上下文中——这正是作为入口节点保留初始上下文的仓库级实例。关键用途一作为起始节点保留初始上下文将 Passthrough 作为工作流的入口节点配合边的keep_message: true配置可以确保用户的初始任务始终保留在上下文中不会被后续节点的输出覆盖nodes: - id: Task Keeper type: passthrough config: {} - id: Worker A type: agent config: provider: openai name: gpt-4o - id: Worker B type: agent config: provider: openai name: gpt-4o edges: # 从入口分发任务保留原始消息 - from: Task Keeper to: Worker A keep_message: true # 保留初始任务上下文 - from: Task Keeper to: Worker B keep_message: true start: [Task Keeper]效果Worker A 和 Worker B 都能看到用户的原始输入而不仅仅是上一个节点的输出。这里补充说明keep_message的语义它定义在边配置 entity/configs/edge/edge.py 的EdgeConfig中默认值为false官方字段说明为Whether to always keep this message input in the target node without being cleared是否让这条消息常驻在目标节点且不被清除。它与另一对边级开关clear_context、clear_kept_context配合构成完整的上下文生命周期控制体系——Passthrough 入口节点正是这套机制最常见的挂载点。关键用途二过滤循环中的冗余输出在包含循环的工作流中循环内的节点可能产生大量中间输出。如果将所有输出都传递给后续节点会导致上下文膨胀context bloat既浪费 token 又稀释模型注意力。使用 Passthrough 节点可以只传递循环的最终结果nodes: - id: Iterative Improver type: agent config: provider: openai name: gpt-4o role: 根据反馈不断改进输出 - id: Evaluator type: agent config: provider: openai name: gpt-4o role: | 评估输出质量回复 GOOD 或提供改进建议 - id: Result Filter type: passthrough config: {} - id: Final Processor type: agent config: provider: openai name: gpt-4o role: 对最终结果进行后处理 edges: - from: Iterative Improver to: Evaluator # 循环评估不通过时回到改进节点 - from: Evaluator to: Iterative Improver condition: type: keyword config: none: [GOOD] # 循环结束通过 Passthrough 过滤只传递最后一条 - from: Evaluator to: Result Filter condition: type: keyword config: any: [GOOD] - from: Result Filter to: Final Processor start: [Iterative Improver] end: [Final Processor]效果无论循环迭代多少次Final Processor只会收到Evaluator的最后一条输出表示质量通过的那条而不是所有中间结果。该模式的实现原理这里的关键点在于条件边只决定消息是否从 Evaluator 流向 Result Filter但不会自动丢弃之前已流过的消息。真正把多轮中间结果收敛为一条的是Result Filter这个 Passthrough 节点默认的only_last_message: true行为——它拿到Evaluator在全部迭代中产生的输入列表后只把inputs[-1]最后一条转发给Final Processor。从仓库的循环控制机制看条件边的关键字判定由 runtime/edge/conditions/keyword_manager.py 实现any: [GOOD]表示输出中命中任意关键字即放行、none: [GOOD]表示不含该关键字才放行而循环的终止与释放还可由loop_counter、loop_timer等节点辅助控制见 yaml_instance/ChatDev_v1.yaml 中Code Complete All Phase Loop Counter、Test Phase Loop Counter的用法。Passthrough 在其中扮演的是出循环后的消息闸门职责单一、边界清晰。关键用途三条件分支中的路由理线在分支较多的工作流中直接从分类节点拉出多条带条件的边会让图变得混乱且每条边的keep_message、trigger等配置分散管理。用 Passthrough 做路由中心可以集中收敛这些出边配置nodes: - id: Classifier type: agent config: provider: openai name: gpt-4o role: | 分类输入内容回复 TECHNICAL 或 BUSINESS - id: Router type: passthrough config: {} - id: Tech Handler type: agent config: provider: openai name: gpt-4o - id: Biz Handler type: agent config: provider: openai name: gpt-4o edges: - from: Classifier to: Router - from: Router to: Tech Handler condition: type: keyword config: any: [TECHNICAL] - from: Router to: Biz Handler condition: type: keyword config: any: [BUSINESS]效果分类节点的出边只有一条指向Router所有分支逻辑和对应的条件配置都集中在Router的出边上后续新增分支只需在Router下追加边无需改动上游节点。其他用途占位符在设计阶段预留节点位置先用 Passthrough 占位后续再替换为具体业务节点保证图在未完成时也可运行调试观察点在流程关键位置插入 Passthrough 节点配合log_manager的 debug 日志转发时会记录收到的输入数量input_count可以在不改动业务逻辑的前提下观察消息流转上下文控制节点作为逻辑分界点明确划分工作流的阶段边界让后续的clear_context等清理操作有明确的挂载位置。基础用法速查最简单的 Passthrough 声明只需三行nodes: - id: Router type: passthrough config: {}配合start字段即可作为工作流入口start: [Router]最佳实践清单使用有意义的节点 ID 描述其拓扑作用如Task Keeper、Result Filter、Router、FINAL。仓库中的 yaml_instance/ChatDev_v1.yamlUSER/PSEUDO/FINAL和 yaml_instance/subgraphs/reflexion_loop.yamlTask都遵循这一命名惯例让图的结构意图一目了然作为入口节点时出边配置keep_message: true保留上下文让所有下游 Agent 始终能看到用户的原始任务在循环后使用过滤掉冗余的中间输出让循环外的节点只接收最终结果避免上下文膨胀需要传递全部消息时显式设置only_last_message: false不要在配置上依赖空 config 即传全部的错误假设默认值始终是true把 Passthrough 当作拓扑工具而非数据工具它的价值在理线与控流不要试图让它承担任何内容处理职责——那是边处理器process如正则提取或 Agent 节点的职责参考 runtime/edge/processors/base.py 中的EdgePayloadProcessor。小结Passthrough 节点用零处理换来了工作流图结构上的极大灵活性作为入口节点配合keep_message保留初始上下文作为循环出口过滤冗余中间结果作为路由中心理清条件分支。它的实现只有二十余行runtime/node/executor/passthrough_executor.py配置面只有一个布尔开关却出现在 yaml_instance/ChatDev_v1.yaml、yaml_instance/MACNet_v1.yaml、yaml_instance/deep_research_v1.yaml 等多个真实工作流中——这本身就是它在多 Agent 协作编排中不可替代价值的最好证明。【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/GitHub_Trending/ch/ChatDev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ChatDev Passthrough 透传节点完全指南：理线、上下文控制与循环输出过滤实战
ChatDev Passthrough 透传节点完全指南理线、上下文控制与循环输出过滤实战【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/GitHub_Trending/ch/ChatDevPassthrough透传节点是 ChatDev 2.0 多 Agent 协作工作流中最简单却最实用的一类节点它不做任何计算只负责把上游消息原样转交下游并通过only_last_message参数充当上下文阀门。本文基于官方中文文档 docs/user_guide/zh/nodes/passthrough.md 展开结合仓库源码与真实 YAML 案例系统讲解它的配置字段、透传语义、三类核心实战场景入口上下文保留、循环冗余过滤、条件路由理线与工程最佳实践读完即可在自己的工作流中正确驾驭它。Passthrough 节点是什么在 ChatDev 的节点体系里runtime/node/builtin_nodes.py 将每个可用的工作流节点类型统一注册为配置类 执行器类的组合其中passthrough的注册摘要只有一句话Forwards prior node output downstream without modification把上游节点输出原样转发给下游不做任何修改。这意味着 Passthrough 节点接收上游传入的所有消息默认只传递最后一条消息only_last_message: true设置only_last_message: false时传递所有消息不做任何内容处理或转换。它没有 LLM 调用、没有工具执行、没有记忆读写是整个工作流中执行代价最低的节点类型。透传行为的源码级印证执行逻辑位于 runtime/node/executor/passthrough_executor.py核心代码如下if config.only_last_message: if len(inputs) 1: self.log_manager.debug( fPassthrough node {node.id} received {len(inputs)} inputs; forwarding the latest entry, node_idnode.id, details{input_count: len(inputs)}, ) return [inputs[-1].clone()] else: return [msg.clone() for msg in inputs]从源码可以确认三个关键实现细节最后一条是严格取inputs[-1]即按输入消息列表的先后顺序取最后一条无论是只传最后一条还是传全部消息都通过clone()深拷贝后再下发见 entity/messages.py 中Message.clone()的实现保证下游对消息的任何改动都不会反向污染上游若节点在无输入的情况下被触发会记录一条 warning 日志并返回一个空内容、USER角色的占位消息避免执行链路中断。此外消息对象本身带有keep标记字段entity/messages.py 中Message.keep配合边的keep_message配置可以控制上下文是否常驻这正是 Passthrough 参与上下文控制的底层机制之一。配置项与默认值Passthrough 的配置由 entity/configs/node/passthrough.py 中的PassthroughConfig定义这是全工作流配置面最精简的节点之一字段类型必填默认值说明only_last_messagebool否true是否只传递最后一条消息。设为false时传递所有消息。配置解析细节from_dict中当config字段缺失或为None时直接使用默认值only_last_messageTrue传入的配置必须是一个 mapping字典only_last_message则通过optional_bool解析非法类型会报错而非静默忽略。基本配置默认行为config: {} # 使用默认配置只传递最后一条消息传递所有消息config: only_last_message: false # 传递所有接收到的消息Web UI 中的对应形态在 Web 工作台前端位于 frontend/src/pages/WorkflowWorkbench.vue中Passthrough 节点只有一个开关型配置项Only Last Message与FIELD_SPECS中声明的only_last_message显示名 Only Last Message类型 bool默认 true一一对应。由于该节点没有role、provider、tooling等字段它是创建多分支工作流时最轻量的接线元件。核心价值图结构优化理线Passthrough 节点的核心价值不在于数据处理而在于图结构的优化理线使复杂的边连接更加清晰集中管理出边配置如keep_message作为逻辑分界点提高工作流可读性。在 ChatDev 的真实工作流中这一点体现得尤为明显。yaml_instance/ChatDev_v1.yaml 的顶层图中定义了USER、PSEUDO、FINAL三个 Passthrough 节点USER作为图入口的任务代理接收外部输入后再按边分发给规划、编码、评审等角色FINAL作为收敛出口把多路结果汇合为最终交付它们把谁来接收外部输入谁代表最终输出这两个拓扑职责与具体业务节点解耦。再比如 yaml_instance/subgraphs/reflexion_loop.yaml 中子图入口就是一个名为Task的 Passthrough 节点- id: Task type: passthrough config: {}随后从Task出发的两条边都配置了keep_message: True把用户原始任务同时常驻在 Actor 与 Evaluator 的上下文中——这正是作为入口节点保留初始上下文的仓库级实例。关键用途一作为起始节点保留初始上下文将 Passthrough 作为工作流的入口节点配合边的keep_message: true配置可以确保用户的初始任务始终保留在上下文中不会被后续节点的输出覆盖nodes: - id: Task Keeper type: passthrough config: {} - id: Worker A type: agent config: provider: openai name: gpt-4o - id: Worker B type: agent config: provider: openai name: gpt-4o edges: # 从入口分发任务保留原始消息 - from: Task Keeper to: Worker A keep_message: true # 保留初始任务上下文 - from: Task Keeper to: Worker B keep_message: true start: [Task Keeper]效果Worker A 和 Worker B 都能看到用户的原始输入而不仅仅是上一个节点的输出。这里补充说明keep_message的语义它定义在边配置 entity/configs/edge/edge.py 的EdgeConfig中默认值为false官方字段说明为Whether to always keep this message input in the target node without being cleared是否让这条消息常驻在目标节点且不被清除。它与另一对边级开关clear_context、clear_kept_context配合构成完整的上下文生命周期控制体系——Passthrough 入口节点正是这套机制最常见的挂载点。关键用途二过滤循环中的冗余输出在包含循环的工作流中循环内的节点可能产生大量中间输出。如果将所有输出都传递给后续节点会导致上下文膨胀context bloat既浪费 token 又稀释模型注意力。使用 Passthrough 节点可以只传递循环的最终结果nodes: - id: Iterative Improver type: agent config: provider: openai name: gpt-4o role: 根据反馈不断改进输出 - id: Evaluator type: agent config: provider: openai name: gpt-4o role: | 评估输出质量回复 GOOD 或提供改进建议 - id: Result Filter type: passthrough config: {} - id: Final Processor type: agent config: provider: openai name: gpt-4o role: 对最终结果进行后处理 edges: - from: Iterative Improver to: Evaluator # 循环评估不通过时回到改进节点 - from: Evaluator to: Iterative Improver condition: type: keyword config: none: [GOOD] # 循环结束通过 Passthrough 过滤只传递最后一条 - from: Evaluator to: Result Filter condition: type: keyword config: any: [GOOD] - from: Result Filter to: Final Processor start: [Iterative Improver] end: [Final Processor]效果无论循环迭代多少次Final Processor只会收到Evaluator的最后一条输出表示质量通过的那条而不是所有中间结果。该模式的实现原理这里的关键点在于条件边只决定消息是否从 Evaluator 流向 Result Filter但不会自动丢弃之前已流过的消息。真正把多轮中间结果收敛为一条的是Result Filter这个 Passthrough 节点默认的only_last_message: true行为——它拿到Evaluator在全部迭代中产生的输入列表后只把inputs[-1]最后一条转发给Final Processor。从仓库的循环控制机制看条件边的关键字判定由 runtime/edge/conditions/keyword_manager.py 实现any: [GOOD]表示输出中命中任意关键字即放行、none: [GOOD]表示不含该关键字才放行而循环的终止与释放还可由loop_counter、loop_timer等节点辅助控制见 yaml_instance/ChatDev_v1.yaml 中Code Complete All Phase Loop Counter、Test Phase Loop Counter的用法。Passthrough 在其中扮演的是出循环后的消息闸门职责单一、边界清晰。关键用途三条件分支中的路由理线在分支较多的工作流中直接从分类节点拉出多条带条件的边会让图变得混乱且每条边的keep_message、trigger等配置分散管理。用 Passthrough 做路由中心可以集中收敛这些出边配置nodes: - id: Classifier type: agent config: provider: openai name: gpt-4o role: | 分类输入内容回复 TECHNICAL 或 BUSINESS - id: Router type: passthrough config: {} - id: Tech Handler type: agent config: provider: openai name: gpt-4o - id: Biz Handler type: agent config: provider: openai name: gpt-4o edges: - from: Classifier to: Router - from: Router to: Tech Handler condition: type: keyword config: any: [TECHNICAL] - from: Router to: Biz Handler condition: type: keyword config: any: [BUSINESS]效果分类节点的出边只有一条指向Router所有分支逻辑和对应的条件配置都集中在Router的出边上后续新增分支只需在Router下追加边无需改动上游节点。其他用途占位符在设计阶段预留节点位置先用 Passthrough 占位后续再替换为具体业务节点保证图在未完成时也可运行调试观察点在流程关键位置插入 Passthrough 节点配合log_manager的 debug 日志转发时会记录收到的输入数量input_count可以在不改动业务逻辑的前提下观察消息流转上下文控制节点作为逻辑分界点明确划分工作流的阶段边界让后续的clear_context等清理操作有明确的挂载位置。基础用法速查最简单的 Passthrough 声明只需三行nodes: - id: Router type: passthrough config: {}配合start字段即可作为工作流入口start: [Router]最佳实践清单使用有意义的节点 ID 描述其拓扑作用如Task Keeper、Result Filter、Router、FINAL。仓库中的 yaml_instance/ChatDev_v1.yamlUSER/PSEUDO/FINAL和 yaml_instance/subgraphs/reflexion_loop.yamlTask都遵循这一命名惯例让图的结构意图一目了然作为入口节点时出边配置keep_message: true保留上下文让所有下游 Agent 始终能看到用户的原始任务在循环后使用过滤掉冗余的中间输出让循环外的节点只接收最终结果避免上下文膨胀需要传递全部消息时显式设置only_last_message: false不要在配置上依赖空 config 即传全部的错误假设默认值始终是true把 Passthrough 当作拓扑工具而非数据工具它的价值在理线与控流不要试图让它承担任何内容处理职责——那是边处理器process如正则提取或 Agent 节点的职责参考 runtime/edge/processors/base.py 中的EdgePayloadProcessor。小结Passthrough 节点用零处理换来了工作流图结构上的极大灵活性作为入口节点配合keep_message保留初始上下文作为循环出口过滤冗余中间结果作为路由中心理清条件分支。它的实现只有二十余行runtime/node/executor/passthrough_executor.py配置面只有一个布尔开关却出现在 yaml_instance/ChatDev_v1.yaml、yaml_instance/MACNet_v1.yaml、yaml_instance/deep_research_v1.yaml 等多个真实工作流中——这本身就是它在多 Agent 协作编排中不可替代价值的最好证明。【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/GitHub_Trending/ch/ChatDev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考