ChatDev 配置 Schema API 契约全解基于 Breadcrumbs 的动态表单元数据服务【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/Dennis_Huang/ChatDev本文围绕 ChatDevDevAll的动态配置体系系统讲解/api/config/schema与/api/config/schema/validate两个核心接口的请求/响应契约、Breadcrumbs路径面包屑导航原理、CLI 辅助调试命令以及如何在前端/IDE 中基于这些元数据构建无需硬编码字段结构的配置表单。读完本文你将掌握如何按需获取任意配置节点的字段定义、如何对 YAML/JSON 文档做后端校验并定位错误路径以及 schema 注册与导出的底层实现链路。一、背景为什么需要动态 Schema 契约在 ChatDev 中一份工作流设计Design由DesignConfig → GraphConfig → NodeConfig → 各类型节点配置组成的多层配置树构成。节点类型多达十几种agent、human、python_runner、loop_counter 等每种节点又有各自的 config 结构且新增节点类型时 schema 可动态注册。如果前端表单硬编码字段结构任何新配置项都需要同步改代码。为此项目通过 server/config_schema_router.py 暴露了统一的 Schema API把配置类上声明的FIELD_SPECS、CONSTRAINTS、CHILD_ROUTES元数据序列化成 JSON 返回给前端使表单渲染、IDE 补全与 CLI 导出模板共用同一份字段说明书。两个接口的分工如下方法作用POST /api/config/schema根据 breadcrumbs 返回对应配置节点的字段定义。POST /api/config/schema/validate校验一份 YAML/JSON 文档并可回传局部 Schema。路由前缀在 server/config_schema_router.py 中定义为/api/config并在 server/bootstrap.py 中随应用一起挂载。二、请求体公共字段与 Breadcrumb 语义两个接口的请求体共享breadcrumbs公共字段SchemaRequest基类见 server/config_schema_router.py用于描述当前位于配置树哪一层{ breadcrumbs: [ {node: DesignConfig, field: graph}, {node: GraphConfig, field: nodes}, {node: NodeConfig, value: model} ] }每个 breadcrumb 条目的字段语义node必填当前所处的配置类名如DesignConfig、GraphConfig、NodeConfig。在 utils/schema_exporter.py 的Breadcrumb.from_mapping中缺省node会直接抛出SchemaResolutionError(breadcrumb entry missing node)。field可选要下钻的子字段名缺省表示仅断言仍在该node相当于锚定位置但不深入。value可选当子类由判别字段discriminator决定时填写典型如节点type、tooling 的type。value与 YAML 中的取值保持一致例如{node: NodeConfig, field: config, value: agent}表示进入 agent 节点的配置块。index可选 int预留用于列表遍历当前解析阶段以field/value为主。若传入且非 intBreadcrumb.from_mapping会报breadcrumb index must be integer when provided。解析与校验规则build_schema_response首先通过_normalize_breadcrumbs把原始 JSON 转成Breadcrumb列表再由_resolve_config_classutils/schema_exporter.py逐跳解析每跳的node必须与当前配置类的类名严格相等否则抛出breadcrumb node X does not match current config Y接口层转换为 HTTP 422。若field为空则继续下一跳。先调用当前类的resolve_child(field, value)从CHILD_ROUTES中匹配ChildKeyentity/configs/base.py 中定义了ChildKey(field, value)valueNone时按通配匹配若匹配不到子类则回退检查FIELD_SPECS[field].child仍无子类时抛出field name on node is not navigable。以NodeConfig为例其child_routes()并不是硬编码的而是遍历iter_node_schemas()动态生成config - 各类型配置类的路由见 entity/configs/node/node.py。这意味着新增一种节点类型并注册后Schema API 会自动获得通往该节点 config 的导航能力。三、POST /api/config/schema按需拉取字段定义响应示例以请求breadcrumbs[{node:NodeConfig}]为例典型响应如下{ schemaVersion: 0.1.0, node: NodeConfig, fields: [ {name: id, typeHint: str, required: true, description: Unique node identifier}, {name: type, typeHint: str, required: true, enum: [model,python,agent], enumOptions: [{value:model,label:LLM Node,description:Runs provider-backed models}] } ], constraints: [...], breadcrumbs: [...], cacheKey: f90d... }响应字段说明schemaVersion当前固定为0.1.0定义在 utils/schema_exporter.py 的SCHEMA_VERSION常量。node当前配置节点类名。fields由ConfigFieldSpec序列化而来to_json()见 entity/configs/base.py每个字段包含name、displayName、type、required、advance并按需携带default、enum、enumOptions、description、childNode。若有子配置会额外附加childRoutes数组每项形如{childKey: {field:config,value:agent}, childNode:AgentConfig}生成逻辑见 utils/schema_exporter.py。constraints由各配置类的collect_schema()汇总的互斥/组合约束RuntimeConstraint含when、require、message序列化见 entity/configs/base.py。breadcrumbs回显本次解析成功的 breadcrumbs。cacheKey基于{node, breadcrumbs}序列化后的 SHA-1 摘要utils/schema_exporter.py客户端可据此做本地缓存。字段排序与枚举的动态注入值得注意的两个实现细节必填字段优先_ordered_field_namesutils/schema_exporter.py会把requiredTrue的字段排在前面同时保持同类字段的相对声明顺序便于表单从上到下渲染。枚举动态化Node.field_specs()entity/configs/node/node.py在导出时会用注册表实时重写type字段的enum与enumOptionslabel/description 取自NodeSchemaSpec.summary。因此前端拿到的节点类型下拉列表永远与运行时注册的节点类型一致无需同步发布。顶层配置树的字段构成起点{ node: DesignConfig }返回的字段定义来自 entity/configs/graph.pyversion可选默认0.0.0advance配置版本号。vars可选默认{}全局变量可在文档内通过${VAR}引用。graph必填核心图定义childGraphDefinition。而GraphConfig即GraphDefinition的核心字段包括id必填、仅允许字母数字下划线连字符、description、log_level枚举LogLevel默认 DEBUGadvance、is_majority_votingbool默认 falseadvance、nodeslist[Node]、edgeslist[EdgeConfig]、memorylist[MemoryStoreConfig]以及start/end均标注 advance不建议手工编辑。四、POST /api/config/schema/validate文档校验 Schema 回传/schema/validate在breadcrumbs之外额外要求一个document字段SchemaValidateRequest见 server/config_schema_router.py内容是完整的 YAML/JSON 文档字符串{ breadcrumbs: [{node: DesignConfig}], document: name: demo\nversion: 0.4.0\nworkflow:\n nodes: []\n edges: []\n }三种响应形态1. 文档有效返回{ valid: true, schema: { ... } }schema为按 breadcrumbs 解析出的局部 Schema若 breadcrumbs 为空则为null可直接用于表单渲染。2. 配置语义错误HTTP 200 validfalse当文档能被 YAML 解析、但无法通过配置类的结构校验时返回{ valid: false, error: field nodes must not be empty, path: [workflow,nodes], schema: { ... } }这里的错误路径由ConfigError.path携带ConfigError定义见 entity/configs/base.py格式化消息时会把path拼进full_message。例如GraphDefinition.validate()对重复节点 id、引用不存在的 start 节点、边的 source/target 未定义等都会抛带路径的ConfigError见 entity/configs/graph.py。3. YAML 解析失败HTTP 400{ message: invalid_yaml, error: ... }对应 server/config_schema_router.py 中yaml.safe_load抛出的YAMLError。此外若解析结果不是 mapping如顶层是数组会返回 HTTP 422 的{ message: document_root_not_mapping }。校验的底层调用链/schema/validate的校验核心并不在路由层而是复用完整的配置加载链路utils/schema_exporter.py → entity/config_loader.pyyaml.safe_load(document) → load_design_from_mapping(parsed) → prepare_design_mapping() # 加载 .env、解析 ${VAR} 占位符 → DesignConfig.from_dict(pathroot) → GraphDefinition.from_dict(...) → Node.from_dict(...) → ... → 任一环节抛出 ConfigError → 路由捕获并返回 {valid:false, error, path, schema}也就是说validate 接口与工作流实际加载使用的校验逻辑是同一套前端保存前调用它等价于先试跑一遍配置解析可以最大程度避免保存后才在运行时暴露错误。五、Breadcrumb 使用提示起点固定为{ node: DesignConfig }。每一步的node必须与当前位置的类匹配否则返回 HTTP 422。用field进入子配置典型链路为graph → nodes → config等。判别式子类如节点type、toolingtype需在对应一跳填写value。不可导航的字段会返回field name on node is not navigable。一个从顶层下钻到具体 agent 节点配置的完整 breadcrumbs 示例[ {node: DesignConfig, field: graph}, {node: GraphConfig, field: nodes}, {node: NodeConfig, field: config, value: agent}, {node: AgentConfig} ]由于Node的child_routes是按注册表动态生成的这里第 3 跳的value可以是任意已注册的节点类型名agent、human、python_runner、loop_counter、loop_timer、literal、passthrough、subgraph、memory 等具体以 schema_registry/registry.py 中实际注册为准。六、CLI 辅助--inspect-schema在导出模板或排查FIELD_SPECS之前可以用 CLI 直接在命令行查看 Schema 输出无需启动 HTTP 服务python run.py --inspect-schema --schema-breadcrumbs [{node:DesignConfig,field:graph}]不带--schema-breadcrumbs时默认解析根节点DesignConfig。输出格式与/schema接口完全一致schemaVersion、node、fields、constraints、breadcrumbs、cacheKey。内部实现见 run.py--schema-breadcrumbs的值被json.loads解析后直接传给build_schema_response解析失败会以非零状态退出breadcrumbs 无法解析时打印Failed to resolve schema: ...。典型调试场景新增一个字段但发现前端没显示时先用该命令确认FIELD_SPECS是否正确导出、required/enum/childNode是否如预期。七、前端调用范式官方推荐的集成流程与 frontend/src 中FormGenerator.vue、DynamicFormField.vue等组件的思路一致以[{node:DesignConfig, field:graph}]拉取基础表单渲染 graph 层字段。用户展开子配置节点、tooling 等时在现有 breadcrumbs 上追加对应条目再取一次 Schema。用cacheKey breadcrumbs做客户端缓存避免重复请求cacheKey本身就是对{node, breadcrumbs}的哈希天然适合做缓存键。保存前调用/schema/validate将返回的errorpath映射到表单对应字段上展示path形如[workflow,nodes]可逐段定位到具体字段。结合enumOptions中的label/description前端可以渲染带说明的下拉选项结合childRoutes可以在用户选择了判别字段后动态切换表单子结构——整个过程不依赖任何硬编码字段名。八、错误参考HTTP场景Payload400YAML 解析失败{ message: invalid_yaml, error: ... }422Breadcrumb 解析失败{ message: breadcrumb node X... }422文档根节点不是 mapping{ message: document_root_not_mapping }200 validfalse后端ConfigError{ error: ..., path: [workflow, ...] }200 validtrue文档有效返回所请求的 Schema便于表单渲染。其中 422 的message内容直接来自SchemaResolutionError的异常文本如breadcrumb node X does not match current config DesignConfig、field foo on GraphConfig is not navigable路由层通过 server/config_schema_router.py 将异常转为HTTPException(status_code422)。九、扩展阅读Schema 注册与导出链路如果希望理解字段定义从哪来可以从以下文件顺藤摸瓜entity/configs/base.pyConfigFieldSpec、SchemaNode、RuntimeConstraint、ChildKey等 schema 元数据的数据结构定义。entity/configs/graph.pyDesignConfig/GraphDefinition的FIELD_SPECS与校验逻辑。entity/configs/node/node.pyNode的动态child_routes与type枚举注入。schema_registry/registry.py节点、边条件、边处理器、记忆存储、思考策略、模型供应商六类 schema 的注册中心重复注册同名不同类型会抛SchemaRegistrationError。utils/schema_exporter.pybuild_schema_response的核心导出逻辑所有接口与 CLI 都复用这一入口。server/config_schema_router.py两个 HTTP 端点的最终实现。run.py--inspect-schema与--schema-breadcrumbs参数解析。搭配FIELD_SPECS使用即可在前端/IDE 构建无需硬编码的配置体验新增配置字段只需要在对应配置类中补充FIELD_SPECS条目Schema API、CLI 与前端表单会自动同步生效。【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/Dennis_Huang/ChatDev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ChatDev 配置 Schema API 契约全解：基于 Breadcrumbs 的动态表单元数据服务
ChatDev 配置 Schema API 契约全解基于 Breadcrumbs 的动态表单元数据服务【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/Dennis_Huang/ChatDev本文围绕 ChatDevDevAll的动态配置体系系统讲解/api/config/schema与/api/config/schema/validate两个核心接口的请求/响应契约、Breadcrumbs路径面包屑导航原理、CLI 辅助调试命令以及如何在前端/IDE 中基于这些元数据构建无需硬编码字段结构的配置表单。读完本文你将掌握如何按需获取任意配置节点的字段定义、如何对 YAML/JSON 文档做后端校验并定位错误路径以及 schema 注册与导出的底层实现链路。一、背景为什么需要动态 Schema 契约在 ChatDev 中一份工作流设计Design由DesignConfig → GraphConfig → NodeConfig → 各类型节点配置组成的多层配置树构成。节点类型多达十几种agent、human、python_runner、loop_counter 等每种节点又有各自的 config 结构且新增节点类型时 schema 可动态注册。如果前端表单硬编码字段结构任何新配置项都需要同步改代码。为此项目通过 server/config_schema_router.py 暴露了统一的 Schema API把配置类上声明的FIELD_SPECS、CONSTRAINTS、CHILD_ROUTES元数据序列化成 JSON 返回给前端使表单渲染、IDE 补全与 CLI 导出模板共用同一份字段说明书。两个接口的分工如下方法作用POST /api/config/schema根据 breadcrumbs 返回对应配置节点的字段定义。POST /api/config/schema/validate校验一份 YAML/JSON 文档并可回传局部 Schema。路由前缀在 server/config_schema_router.py 中定义为/api/config并在 server/bootstrap.py 中随应用一起挂载。二、请求体公共字段与 Breadcrumb 语义两个接口的请求体共享breadcrumbs公共字段SchemaRequest基类见 server/config_schema_router.py用于描述当前位于配置树哪一层{ breadcrumbs: [ {node: DesignConfig, field: graph}, {node: GraphConfig, field: nodes}, {node: NodeConfig, value: model} ] }每个 breadcrumb 条目的字段语义node必填当前所处的配置类名如DesignConfig、GraphConfig、NodeConfig。在 utils/schema_exporter.py 的Breadcrumb.from_mapping中缺省node会直接抛出SchemaResolutionError(breadcrumb entry missing node)。field可选要下钻的子字段名缺省表示仅断言仍在该node相当于锚定位置但不深入。value可选当子类由判别字段discriminator决定时填写典型如节点type、tooling 的type。value与 YAML 中的取值保持一致例如{node: NodeConfig, field: config, value: agent}表示进入 agent 节点的配置块。index可选 int预留用于列表遍历当前解析阶段以field/value为主。若传入且非 intBreadcrumb.from_mapping会报breadcrumb index must be integer when provided。解析与校验规则build_schema_response首先通过_normalize_breadcrumbs把原始 JSON 转成Breadcrumb列表再由_resolve_config_classutils/schema_exporter.py逐跳解析每跳的node必须与当前配置类的类名严格相等否则抛出breadcrumb node X does not match current config Y接口层转换为 HTTP 422。若field为空则继续下一跳。先调用当前类的resolve_child(field, value)从CHILD_ROUTES中匹配ChildKeyentity/configs/base.py 中定义了ChildKey(field, value)valueNone时按通配匹配若匹配不到子类则回退检查FIELD_SPECS[field].child仍无子类时抛出field name on node is not navigable。以NodeConfig为例其child_routes()并不是硬编码的而是遍历iter_node_schemas()动态生成config - 各类型配置类的路由见 entity/configs/node/node.py。这意味着新增一种节点类型并注册后Schema API 会自动获得通往该节点 config 的导航能力。三、POST /api/config/schema按需拉取字段定义响应示例以请求breadcrumbs[{node:NodeConfig}]为例典型响应如下{ schemaVersion: 0.1.0, node: NodeConfig, fields: [ {name: id, typeHint: str, required: true, description: Unique node identifier}, {name: type, typeHint: str, required: true, enum: [model,python,agent], enumOptions: [{value:model,label:LLM Node,description:Runs provider-backed models}] } ], constraints: [...], breadcrumbs: [...], cacheKey: f90d... }响应字段说明schemaVersion当前固定为0.1.0定义在 utils/schema_exporter.py 的SCHEMA_VERSION常量。node当前配置节点类名。fields由ConfigFieldSpec序列化而来to_json()见 entity/configs/base.py每个字段包含name、displayName、type、required、advance并按需携带default、enum、enumOptions、description、childNode。若有子配置会额外附加childRoutes数组每项形如{childKey: {field:config,value:agent}, childNode:AgentConfig}生成逻辑见 utils/schema_exporter.py。constraints由各配置类的collect_schema()汇总的互斥/组合约束RuntimeConstraint含when、require、message序列化见 entity/configs/base.py。breadcrumbs回显本次解析成功的 breadcrumbs。cacheKey基于{node, breadcrumbs}序列化后的 SHA-1 摘要utils/schema_exporter.py客户端可据此做本地缓存。字段排序与枚举的动态注入值得注意的两个实现细节必填字段优先_ordered_field_namesutils/schema_exporter.py会把requiredTrue的字段排在前面同时保持同类字段的相对声明顺序便于表单从上到下渲染。枚举动态化Node.field_specs()entity/configs/node/node.py在导出时会用注册表实时重写type字段的enum与enumOptionslabel/description 取自NodeSchemaSpec.summary。因此前端拿到的节点类型下拉列表永远与运行时注册的节点类型一致无需同步发布。顶层配置树的字段构成起点{ node: DesignConfig }返回的字段定义来自 entity/configs/graph.pyversion可选默认0.0.0advance配置版本号。vars可选默认{}全局变量可在文档内通过${VAR}引用。graph必填核心图定义childGraphDefinition。而GraphConfig即GraphDefinition的核心字段包括id必填、仅允许字母数字下划线连字符、description、log_level枚举LogLevel默认 DEBUGadvance、is_majority_votingbool默认 falseadvance、nodeslist[Node]、edgeslist[EdgeConfig]、memorylist[MemoryStoreConfig]以及start/end均标注 advance不建议手工编辑。四、POST /api/config/schema/validate文档校验 Schema 回传/schema/validate在breadcrumbs之外额外要求一个document字段SchemaValidateRequest见 server/config_schema_router.py内容是完整的 YAML/JSON 文档字符串{ breadcrumbs: [{node: DesignConfig}], document: name: demo\nversion: 0.4.0\nworkflow:\n nodes: []\n edges: []\n }三种响应形态1. 文档有效返回{ valid: true, schema: { ... } }schema为按 breadcrumbs 解析出的局部 Schema若 breadcrumbs 为空则为null可直接用于表单渲染。2. 配置语义错误HTTP 200 validfalse当文档能被 YAML 解析、但无法通过配置类的结构校验时返回{ valid: false, error: field nodes must not be empty, path: [workflow,nodes], schema: { ... } }这里的错误路径由ConfigError.path携带ConfigError定义见 entity/configs/base.py格式化消息时会把path拼进full_message。例如GraphDefinition.validate()对重复节点 id、引用不存在的 start 节点、边的 source/target 未定义等都会抛带路径的ConfigError见 entity/configs/graph.py。3. YAML 解析失败HTTP 400{ message: invalid_yaml, error: ... }对应 server/config_schema_router.py 中yaml.safe_load抛出的YAMLError。此外若解析结果不是 mapping如顶层是数组会返回 HTTP 422 的{ message: document_root_not_mapping }。校验的底层调用链/schema/validate的校验核心并不在路由层而是复用完整的配置加载链路utils/schema_exporter.py → entity/config_loader.pyyaml.safe_load(document) → load_design_from_mapping(parsed) → prepare_design_mapping() # 加载 .env、解析 ${VAR} 占位符 → DesignConfig.from_dict(pathroot) → GraphDefinition.from_dict(...) → Node.from_dict(...) → ... → 任一环节抛出 ConfigError → 路由捕获并返回 {valid:false, error, path, schema}也就是说validate 接口与工作流实际加载使用的校验逻辑是同一套前端保存前调用它等价于先试跑一遍配置解析可以最大程度避免保存后才在运行时暴露错误。五、Breadcrumb 使用提示起点固定为{ node: DesignConfig }。每一步的node必须与当前位置的类匹配否则返回 HTTP 422。用field进入子配置典型链路为graph → nodes → config等。判别式子类如节点type、toolingtype需在对应一跳填写value。不可导航的字段会返回field name on node is not navigable。一个从顶层下钻到具体 agent 节点配置的完整 breadcrumbs 示例[ {node: DesignConfig, field: graph}, {node: GraphConfig, field: nodes}, {node: NodeConfig, field: config, value: agent}, {node: AgentConfig} ]由于Node的child_routes是按注册表动态生成的这里第 3 跳的value可以是任意已注册的节点类型名agent、human、python_runner、loop_counter、loop_timer、literal、passthrough、subgraph、memory 等具体以 schema_registry/registry.py 中实际注册为准。六、CLI 辅助--inspect-schema在导出模板或排查FIELD_SPECS之前可以用 CLI 直接在命令行查看 Schema 输出无需启动 HTTP 服务python run.py --inspect-schema --schema-breadcrumbs [{node:DesignConfig,field:graph}]不带--schema-breadcrumbs时默认解析根节点DesignConfig。输出格式与/schema接口完全一致schemaVersion、node、fields、constraints、breadcrumbs、cacheKey。内部实现见 run.py--schema-breadcrumbs的值被json.loads解析后直接传给build_schema_response解析失败会以非零状态退出breadcrumbs 无法解析时打印Failed to resolve schema: ...。典型调试场景新增一个字段但发现前端没显示时先用该命令确认FIELD_SPECS是否正确导出、required/enum/childNode是否如预期。七、前端调用范式官方推荐的集成流程与 frontend/src 中FormGenerator.vue、DynamicFormField.vue等组件的思路一致以[{node:DesignConfig, field:graph}]拉取基础表单渲染 graph 层字段。用户展开子配置节点、tooling 等时在现有 breadcrumbs 上追加对应条目再取一次 Schema。用cacheKey breadcrumbs做客户端缓存避免重复请求cacheKey本身就是对{node, breadcrumbs}的哈希天然适合做缓存键。保存前调用/schema/validate将返回的errorpath映射到表单对应字段上展示path形如[workflow,nodes]可逐段定位到具体字段。结合enumOptions中的label/description前端可以渲染带说明的下拉选项结合childRoutes可以在用户选择了判别字段后动态切换表单子结构——整个过程不依赖任何硬编码字段名。八、错误参考HTTP场景Payload400YAML 解析失败{ message: invalid_yaml, error: ... }422Breadcrumb 解析失败{ message: breadcrumb node X... }422文档根节点不是 mapping{ message: document_root_not_mapping }200 validfalse后端ConfigError{ error: ..., path: [workflow, ...] }200 validtrue文档有效返回所请求的 Schema便于表单渲染。其中 422 的message内容直接来自SchemaResolutionError的异常文本如breadcrumb node X does not match current config DesignConfig、field foo on GraphConfig is not navigable路由层通过 server/config_schema_router.py 将异常转为HTTPException(status_code422)。九、扩展阅读Schema 注册与导出链路如果希望理解字段定义从哪来可以从以下文件顺藤摸瓜entity/configs/base.pyConfigFieldSpec、SchemaNode、RuntimeConstraint、ChildKey等 schema 元数据的数据结构定义。entity/configs/graph.pyDesignConfig/GraphDefinition的FIELD_SPECS与校验逻辑。entity/configs/node/node.pyNode的动态child_routes与type枚举注入。schema_registry/registry.py节点、边条件、边处理器、记忆存储、思考策略、模型供应商六类 schema 的注册中心重复注册同名不同类型会抛SchemaRegistrationError。utils/schema_exporter.pybuild_schema_response的核心导出逻辑所有接口与 CLI 都复用这一入口。server/config_schema_router.py两个 HTTP 端点的最终实现。run.py--inspect-schema与--schema-breadcrumbs参数解析。搭配FIELD_SPECS使用即可在前端/IDE 构建无需硬编码的配置体验新增配置字段只需要在对应配置类中补充FIELD_SPECS条目Schema API、CLI 与前端表单会自动同步生效。【免费下载链接】ChatDevChatDev 2.0: Dev All through LLM-powered Multi-Agent Collaboration项目地址: https://gitcode.com/Dennis_Huang/ChatDev创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考