Coze Studio 技术架构与源码分析一句话概括Coze Studio 不是 Coze 平台的简单开源复刻而是一套以“领域驱动设计DDD 整洁架构”为骨架、以“编译时-运行时双阶段工作流引擎”为心脏、以“可视化画布即源代码”为编程范式的生产级 AI Agent 开发平台——让复杂的 AI 工作流从“拖拽连线”变成“可编译、可中断、可恢复、可流式传输的确定性系统”。一、引言如果你用过 AI 工作流工具你一定见过类似这样的界面左侧是节点面板中间是画布右侧是配置栏——拖拽一个“大模型”节点、拖拽一个“知识库检索”节点、用线连起来、点击运行。看起来很简单对吧但当你的工作流需要等待用户输入才能继续执行时当你的工作流运行到第 15 步突然崩溃一切从头再来时当你需要精确理解一个节点为什么输出了一个错误结果时——你发现画布背后的“黑盒”完全没有给你任何解释。字节跳动的 Coze 平台在 2023 年推出后迅速成为国内最受欢迎的 AI Bot 开发平台之一。2025 年 7 月 25 日字节跳动正式将 Coze 的两大核心项目开源。其中Coze Studio是一站式 AI Agent 开发工具提供从开发到部署的完整工具链。开源版本包含了完整的工作流引擎、Agent 系统、知识库管理和插件框架。那么这套“把可视化画布变成可执行系统”的架构到底是如何设计的它的“编译时 运行时”双阶段工作流引擎背后是什么原理为什么一个工作流能在等待用户输入时优雅暂停、在服务器重启后从断点恢复我们从源码出发一步步拆解。二、整体架构与设计哲学2.1 架构总览DDD 分层 微服务Coze Studio 建立在一个现代、可扩展的架构上旨在支持大规模的 AI 代理开发。从高层次来看系统分为前端和后端组件通过明确定义的 API 进行通信。┌──────────────────────────────────────────────────────────────────────┐ │ 前端层Frontend │ │ React 18 TypeScript Semi Design │ │ 可视化画布 · 节点拖拽 · 实时预览 │ │ Rush.js Monorepo135 前端包 │ └───────────────────────────────┬──────────────────────────────────────┘ │ APIHertz HTTP ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ API 层API Layer │ │ 路由 · 认证 · 中间件 · 请求/响应序列化 │ │ /api/* · /v1/*OpenAPI· /v3/* │ └───────────────────────────────┬──────────────────────────────────────┘ │ ┌───────────────────────────────▼──────────────────────────────────────┐ │ 应用层Application Layer │ │ 用例编排 · 事务管理 · 跨领域协调 │ │ 应用服务协调各领域 │ └───────────────────────────────┬──────────────────────────────────────┘ │ ┌───────────────────────────────▼──────────────────────────────────────┐ │ 领域层Domain Layer │ │ Agent · Workflow · Knowledge · Plugin · Conversation · Memory │ │ 核心业务模型与规则 · 领域服务 │ └───────────────────────────────┬──────────────────────────────────────┘ │ ┌───────────────────────────────▼──────────────────────────────────────┐ │ 基础设施层Infrastructure Layer │ │ MySQL · ElasticSearch · Redis · 消息队列 · RPC Client │ └──────────────────────────────────────────────────────────────────────┘图Coze Studio 的四层架构。前端负责可视化编排API 层处理 HTTP 请求应用层协调用例领域层承载核心业务逻辑基础设施层提供技术支撑。各层职责层级职责关键目录API 层处理 HTTP 请求、路由、认证以及请求/响应序列化backend/api/应用层编排领域对象以执行特定用例管理事务backend/application/{domain}领域层包含核心业务模型和规则backend/domain/{domain}基础设施层提供技术能力如数据库访问backend/infra/看到这里你可能会问为什么 Coze Studio 要用 DDD 分层架构而不是简单的 MVC因为 Coze Studio 不是一个简单的 CRUD 应用——它需要处理 Agent 创建、工作流编排、知识库检索、插件集成等多个复杂领域。DDD 的分层架构让每个领域可以独立演进核心业务逻辑不依赖技术细节。应用层作为“协调器”编排领域对象领域层作为“承重墙”承载核心规则基础设施层作为“可插拔的适配器”提供技术能力。技术架构特点层次技术选型说明后端语言Golang高性能、高并发微服务框架CloudWeGo字节跳动开源微服务治理框架HTTP 框架Hertz字节开源的高性能 HTTP 框架LLM 接入层Eino字节开源的 LLM 应用框架前端框架React 18 TypeScript现代化组件化 UI前端包管理Rush.js135 前端包 Monorepo 管理UI 组件库Semi Design字节开源的企业级设计系统2.2 设计哲学DDD 是骨架工作流是心脏Coze Studio 的设计围绕几个核心哲学展开哲学一领域驱动设计DDD是骨架。后端使用 Golang 开发并遵循微服务架构中的领域驱动设计方法。代码围绕业务领域组织并将不同关注点分离到不同的层次中。每个业务领域都遵循 API → 应用 → 领域 → 基础设施的分层架构。哲学二工作流引擎是心脏。Coze Studio 开源的核心是完整的工作流引擎——这是扣子团队投入最大精力构建的核心组件。工作流引擎基于 DAG 的编排运行时它将可视化画布设计转化为可执行、可恢复且可流式传输的计算图。哲学三编译时 运行时双阶段执行。工作流引擎遵循清晰的编译时Compile Time和运行时Runtime阶段划分。编译时将画布 JSON 编译为可执行的 Runnable运行时由 WorkflowRunner 驱动执行。2.3 包结构与代码规模Coze Studio 整体采用 Monorepo 架构项目结构如下coze-studio/ ├── backend/ # 后端服务Go │ ├── api/ # API 路由与处理器 │ ├── application/ # 应用服务层 │ │ ├── agent/ # Agent 应用服务 │ │ ├── conversation/ # 对话应用服务 │ │ ├── knowledge/ # 知识库应用服务 │ │ └── workflow/ # 工作流应用服务 │ ├── domain/ # 领域层 │ │ ├── agent/ # Agent 领域 │ │ ├── workflow/ # 工作流领域 │ │ │ ├── internal/ # 内部实现 │ │ │ │ ├── canvas/ # 画布解析与适配 │ │ │ │ └── compose/ # 编译与执行引擎 │ │ ├── knowledge/ # 知识库领域 │ │ ├── plugin/ # 插件领域 │ │ └── conversation/ # 对话领域 │ └── infra/ # 基础设施层 ├── web/ # 前端应用React TypeScript └── docker/ # Docker 部署配置三、核心抽象与编程模型3.1 领域层——DDD 的“承重墙”Coze Studio 的架构围绕几个核心领域组织领域职责源码位置代理系统Agent创建能够理解自然语言、执行任务并与用户互动的智能 AI 代理backend/domain/agent工作流引擎Workflow通过可视化工作流设计实现复杂业务逻辑的编排backend/domain/workflow知识管理Knowledge通过 RAG 技术将外部知识与 LLMs 集成backend/domain/knowledge插件架构Plugin通过外部服务和 API 集成扩展代理能力backend/domain/plugin对话系统Conversation管理用户与 AI 代理之间的互动backend/domain/conversation内存系统Memory为代理提供持久化能力backend/domain/memory每个领域内部都遵循 DDD 的分层结构领域服务位于backend/domain/{domain}/service实现核心业务逻辑和领域规则应用服务位于backend/application/{domain}协调各领域并向 API 层暴露功能3.2 工作流引擎——从可视化画布到可执行代码Coze 工作流引擎是整个平台最核心的模块。它回答了三个关键问题一个可视化的画布定义JSON是如何被翻译成机器可以理解和执行的代码的当一个需要用户输入的节点出现时工作流是如何优雅地暂停、等待然后从断点处无缝恢复的复杂的循环、分支和嵌套逻辑又是如何在后端被精确调度和执行的工作流的生命周期分为两个核心阶段┌─────────────────────────────────────────────────────────────────────┐ │ 编译时Compile Time │ │ │ │ vo.Canvas前端画布 JSON │ │ ↓ CanvasToWorkflowSchema() │ │ compose.WorkflowSchema纯净逻辑结构 │ │ ↓ 实例化节点、解析依赖 │ │ compose.Workflow中间状态“装配台” │ │ ↓ 构建 DAG │ │ compose.Runnable可执行实例无状态、可复用 │ ├─────────────────────────────────────────────────────────────────────┤ │ 运行时Runtime │ │ │ │ compose.WorkflowRunner“总指挥” │ │ ↓ 注入上下文、事件回调、中断恢复状态 │ │ 执行 → 产生输出/事件节点开始/结束、等待用户输入等 │ └─────────────────────────────────────────────────────────────────────┘图Coze 工作流的双阶段生命周期。编译时将画布 JSON 转化为无状态可复用的 Runnable运行时由 WorkflowRunner 注入上下文驱动执行。核心数据结构数据结构职责vo.Canvas前端画布的原始 JSON 定义包含节点、边、位置等可视化信息compose.WorkflowSchema剥离可视化细节后的纯净逻辑结构compose.NodeSchema单个节点的详细定义InputSources字段精确定义每个输入参数的来源compose.Workflow中间状态的“装配台”负责实例化节点、解析依赖compose.Runnable编译的最终产物——真正“可执行”的实例无状态、可复用compose.WorkflowRunner运行时的“总指挥”为 Runnable 注入本次运行的上下文3.3 API 架构——Hertz 驱动的分层路由Coze Studio 的 API 基于分层架构使用Hertz网络框架构建。API 路由组织API 基础路径描述版本状态/api/*核心内部 API 端点当前/v1/*OpenAPI 兼容的 RESTful 端点稳定/v3/*最新一代端点最新核心 API 组API 组职责/api/conversation管理聊天交互、消息和对话历史/api/knowledge处理知识库、文档和数据检索/api/memory管理数据库连接和变量存储/api/plugin_api集成和管理外部插件和 API/api/workflow_api创建、执行和管理代理工作流认证机制基于会话的认证网页界面用户个人访问令牌PAT用于 API 集成OAuth用于第三方集成四、核心模块源码解析4.1 服务层——三层服务架构Coze Studio 采用分层服务架构将服务组织成三个层级层级职责依赖基础服务仅依赖于基础设施组件数据库、缓存、外部客户端基础设施层主要服务基于基础服务构建提供更复杂功能基础服务复杂服务协调主要服务以实现最终用户功能主要服务每个服务使用ServiceComponents结构体来清晰管理依赖使依赖关系明确通过依赖注入实现清晰的测试。领域服务与应用服务的区分服务类型位置职责领域服务/backend/domain/{domain}/service实现核心业务逻辑和领域规则应用服务/backend/application/{domain}协调各领域并向 API 层暴露功能跨领域服务通信通过跨领域服务注册表实现跨领域契约定义在/backend/crossdomain/contract跨领域实现位于/backend/crossdomain/impl全局注册表在初始化期间注册默认实现4.2 工作流编译引擎——从 Canvas 到 Runnable编译阶段的核心任务是将一份静态的、描述性的WorkflowSchema转变为一个动态的、包含了所有执行逻辑的Runnable对象。第一步从 Canvas 到 Schema// 文件路径backend/domain/workflow/internal/canvas/adaptor/to_schema.gofuncCanvasToWorkflowSchema(ctx context.Context,s*vo.Canvas)(sc*compose.WorkflowSchema,errerror,){// 1. 裁剪孤立节点移除任何没有连接的节点connectedNodes,_:...// 2. 构建节点列表和连接关系// 3. 解析层级关系用于循环等复合节点// 4. 返回纯净的 WorkflowSchema}InputSources是NodeSchema中最重要的字段。它精确定义了当前节点的每个输入参数分别来自哪里上游节点的哪个输出、一个固定的静态值、还是全局变量是后续依赖解析的基石。设计模式解读CanvasToWorkflowSchema是适配器模式Adapter Pattern的应用——它将前端画布的“可视化格式”适配为后端引擎的“逻辑格式”剥离了所有与执行无关的 UI 信息。4.3 工作流运行时引擎——可中断、可恢复的执行Coze 工作流引擎最令人着迷的特性之一是可中断、可恢复的执行能力。当一个需要用户输入的节点如“问答”节点出现时工作流会优雅地暂停保存当前执行状态等待用户输入释放计算资源从断点无缝恢复用户输入到达后从保存的状态继续执行工作流引擎构建于Eino 组合框架之上支持35 种以上的节点类型。执行引擎基于DAG 的编排运行时支持流式传输。设计模式解读这种机制是状态模式State Pattern和备忘录模式Memento Pattern的结合——工作流执行状态被保存为“备忘录”恢复时从备忘录重建状态机。4.4 插件架构——OpenAPI 3.0 驱动的可扩展系统Coze Studio 的插件架构提供了一个灵活且可扩展的框架用于将外部工具和服务集成到代理和工作流程中。核心组件插件注册表插件的集中存储和管理插件执行引擎处理插件操作的调用插件开发框架用于创建新插件的工具和 API集成点插件如何与代理和工作流程连接每个插件都遵循OpenAPI 3.0 规范使其与标准 API 文档和工具兼容。五、核心执行流程与运行时机制5.1 完整执行流程——从画布点击到结果返回当用户在 Coze Studio 画布上点击“运行”时底层发生了什么┌─────────────────────────────────────────────────────────────────────┐ │ 1. 用户在前端画布拖拽节点定义数据流向 │ │ ↓ │ │ 2. 前端将画布状态序列化为 Canvas JSON │ │ ↓ │ │ 3. 前端通过 HTTP API 将 Canvas 提交到后端 │ │ ↓ │ │ 4. API 层Hertz接收请求 → 认证 → 路由到工作流处理器 │ │ ↓ │ │ 5. 编译阶段 │ │ ├── CanvasToWorkflowSchema()裁剪孤立节点、构建 Schema │ │ ├── 构建 Workflow装配台实例化节点、解析依赖 │ │ └── 编译为 Runnable可执行实例无状态 │ │ ↓ │ │ 6. 运行时创建 WorkflowRunner │ │ ├── 注入本次运行的上下文输入参数、事件回调 │ │ └── 按拓扑序调度节点执行 │ │ ↓ │ │ 7. 节点执行 │ │ ├── 遇到需要用户输入的节点 → 暂停 → 保存状态 → 等待恢复 │ │ ├── 普通节点 → 执行 → 产生事件节点开始/结束 │ │ └── 所有节点完成 → 返回结果 │ │ ↓ │ │ 8. 结果通过流式方式返回前端 │ └─────────────────────────────────────────────────────────────────────┘图Coze Studio 工作流的完整执行流程。从画布拖拽到结果返回经历前端序列化、API 路由、编译阶段Canvas → Schema → Workflow → Runnable和运行时阶段Runner 执行的全链路。关键设计编译时与运行时分离使得工作流定义可以提前验证和优化Runnable 无状态可复用支持高并发执行。5.2 请求流转——Handler → Application → Domain请求在Handler → Application → Domain三层之间清晰流转API 处理程序接收 HTTP 请求调用应用服务方法应用服务使用多个领域服务实现功能领域服务操作领域实体CreateConversation方法的实现路径展示了清晰的分层——API 层收到请求后调用应用服务应用服务协调多个领域服务完成创建领域服务操作各自的领域实体。5.3 运行时关键决策的权衡分析决策方案收益代价后端语言Golang vs Python高并发、低内存、静态类型、性能优异AI/ML 生态不如 Python 丰富架构风格微服务 vs 单体灵活扩展、模块替换部署运维复杂度高工作流引擎自研基于 Einovs 使用开源引擎轻量、低延迟、支持流式需要自行维护引擎演进执行模型编译时 运行时分离提前验证、可复用 Runnable首次执行有编译延迟中断恢复状态持久化 断点续传长运行任务可恢复存储和序列化开销六、工程化实践6.1 快速接入环境要求2 Core、4 GB 最低配置Docker 和 Docker Compose部署步骤# 1. 克隆代码gitclone https://github.com/coze-dev/coze-studio.git# 2. 配置模型# 从模板目录复制模型配置文件# 3. 启动服务docker-composeup-d6.2 自定义插件开发Coze Studio 的插件遵循 OpenAPI 3.0 规范。开发一个新插件的核心步骤定义 OpenAPI 3.0 规范的 API 文档通过插件注册表注册插件插件执行引擎处理调用6.3 可观测性与调试Coze Studio 提供了多层次的可观测性能力API 中间件认证、日志、追踪事件系统工作流执行过程中的节点开始/结束事件OpenAPI 兼容端点标准化的 API 访问6.4 常见工程陷阱与解决方案陷阱 1工作流循环导致无限执行现象工作流在循环节点中无限执行永不停止。原因循环节点缺少正确的退出条件配置。解决方案Coze 工作流引擎通过Hierarchy层级关系来表达循环等复合节点的父子结构。在循环节点中配置最大迭代次数或条件退出表达式。陷阱 2编译阶段失败导致工作流无法运行现象画布保存成功但运行时提示“工作流编译失败”。原因画布中存在孤立节点或循环依赖。解决方案CanvasToWorkflowSchema函数会自动裁剪孤立节点但循环依赖需要通过 DAG 环检测在编译阶段捕获。七、总结与展望7.1 关键版本里程碑版本/事件时间核心变化Coze 平台发布2023 年字节跳动推出 AI Bot 开发平台Coze Studio 开源2025 年 7 月 25 日字节跳动将核心项目开源v0.2.52026 年 6 月开源版本持续迭代7.2 横向对比Coze Studio vs Dify vs Flowise7.2.1 可比性说明Coze Studio、Dify、Flowise 均定位于LLM 应用开发平台或工具都提供可视化工作流编排能力。三者在功能定位上有重叠但各自的技术栈、设计哲学和部署方式不同。7.2.2 横向对比表对比维度Coze StudioDifyFlowise核心定位字节跳动开源 AI Agent 开发平台开源 LLM 应用开发平台开源低代码 LLM 工具后端语言GolangPythonFlaskTypeScriptNode.js架构风格微服务 DDD模块化单体单体工作流引擎自研 DAG Eino自研 DAG Worker Pool基础 DAG前端技术React TypeScript Semi DesignNext.js ReactReact部署方式Docker ComposeDocker Compose7 容器Docker开源协议待确认Apache 2.0MIT商业版本Coze 平台SaaSDify Cloud无7.2.3 差异来源分析框架/平台核心判断架构推论Coze StudioAI 应用平台需要高性能、高并发的底层支撑用 Golang 微服务 DDD 构建企业级平台DifyLLM 应用开发需要完整平台——不只是代码库用 Python 模块化单体构建完整产品Flowise非开发者需要低代码构建 AI 应用用 Node.js 可视化拖拽降低门槛7.2.4 结论性建议场景推荐选择核心理由需要高性能、高并发的工作流引擎Coze StudioGolang 微服务 Eino 框架需要 Python 技术栈的完整平台DifyPython 生态最丰富需要轻量级、快速原型验证FlowiseNode.js 生态部署简单7.3 设计哲学提炼Coze Studio 的设计哲学可以提炼为三个关键词DDD 是骨架围绕业务领域组织代码将复杂系统拆解为可独立演进的领域模块工作流是心脏编译时 运行时双阶段引擎让可视化画布变成可执行、可恢复的系统微服务是血脉基于 CloudWeGo 技术栈的微服务架构提供高性能和高扩展性7.4 核心架构亮点亮点说明DDD 分层架构API → 应用 → 领域 → 基础设施四层清晰分离编译时 运行时双阶段引擎Canvas → Schema → Workflow → Runnable → Runner可中断可恢复执行工作流可在用户交互节点暂停从断点无缝恢复Eino 框架集成字节开源 LLM 应用框架支持 35 节点类型Hertz HTTP 框架字节开源高性能 HTTP 框架OpenAPI 3.0 插件标准任何符合 OpenAPI 规范的外部服务都可接入7.5 对开发者的启示与适用场景Coze Studio 的本质不是 Coze 平台的简单开源复刻而是一套以“领域驱动设计DDD 整洁架构”为骨架、以“编译时-运行时双阶段工作流引擎”为心脏、以“可视化画布即源代码”为编程范式的生产级 AI Agent 开发平台——让复杂的 AI 工作流从“拖拽连线”变成“可编译、可中断、可恢复、可流式传输的确定性系统”。适用场景需要可视化编排复杂 AI 工作流的团队需要工作流可中断、可恢复的长运行任务场景采用Go 技术栈、追求高并发高性能的企业需要Agent 全生命周期管理开发 → 部署的系统希望基于 OpenAPI 3.0 标准接入外部工具的集成场景不适用场景简单的单次 LLM 调用直接用模型 SDK 即可Python 技术栈为主、对 Go 不熟悉的团队对部署运维复杂度敏感的小型团队需要深度定制工作流引擎的场景本文数据来源Coze Studio 官方 GitHub 仓库、开源 Coze 源码分析系列文章、CSDN 技术博客、53AI 技术文章、掘金技术文章截至 2026 年 8 月如您所在的企业正面临数字化难题或有 AI 落地、系统集成相关需求欢迎进一步沟通。我们可提供针对贵企业具体场景的定制化方案和现场调研服务。 Coze Studio 技术架构与源码分析
Coze Studio 技术架构与源码分析一句话概括Coze Studio 不是 Coze 平台的简单开源复刻而是一套以“领域驱动设计DDD 整洁架构”为骨架、以“编译时-运行时双阶段工作流引擎”为心脏、以“可视化画布即源代码”为编程范式的生产级 AI Agent 开发平台——让复杂的 AI 工作流从“拖拽连线”变成“可编译、可中断、可恢复、可流式传输的确定性系统”。一、引言如果你用过 AI 工作流工具你一定见过类似这样的界面左侧是节点面板中间是画布右侧是配置栏——拖拽一个“大模型”节点、拖拽一个“知识库检索”节点、用线连起来、点击运行。看起来很简单对吧但当你的工作流需要等待用户输入才能继续执行时当你的工作流运行到第 15 步突然崩溃一切从头再来时当你需要精确理解一个节点为什么输出了一个错误结果时——你发现画布背后的“黑盒”完全没有给你任何解释。字节跳动的 Coze 平台在 2023 年推出后迅速成为国内最受欢迎的 AI Bot 开发平台之一。2025 年 7 月 25 日字节跳动正式将 Coze 的两大核心项目开源。其中Coze Studio是一站式 AI Agent 开发工具提供从开发到部署的完整工具链。开源版本包含了完整的工作流引擎、Agent 系统、知识库管理和插件框架。那么这套“把可视化画布变成可执行系统”的架构到底是如何设计的它的“编译时 运行时”双阶段工作流引擎背后是什么原理为什么一个工作流能在等待用户输入时优雅暂停、在服务器重启后从断点恢复我们从源码出发一步步拆解。二、整体架构与设计哲学2.1 架构总览DDD 分层 微服务Coze Studio 建立在一个现代、可扩展的架构上旨在支持大规模的 AI 代理开发。从高层次来看系统分为前端和后端组件通过明确定义的 API 进行通信。┌──────────────────────────────────────────────────────────────────────┐ │ 前端层Frontend │ │ React 18 TypeScript Semi Design │ │ 可视化画布 · 节点拖拽 · 实时预览 │ │ Rush.js Monorepo135 前端包 │ └───────────────────────────────┬──────────────────────────────────────┘ │ APIHertz HTTP ▼ ┌──────────────────────────────────────────────────────────────────────┐ │ API 层API Layer │ │ 路由 · 认证 · 中间件 · 请求/响应序列化 │ │ /api/* · /v1/*OpenAPI· /v3/* │ └───────────────────────────────┬──────────────────────────────────────┘ │ ┌───────────────────────────────▼──────────────────────────────────────┐ │ 应用层Application Layer │ │ 用例编排 · 事务管理 · 跨领域协调 │ │ 应用服务协调各领域 │ └───────────────────────────────┬──────────────────────────────────────┘ │ ┌───────────────────────────────▼──────────────────────────────────────┐ │ 领域层Domain Layer │ │ Agent · Workflow · Knowledge · Plugin · Conversation · Memory │ │ 核心业务模型与规则 · 领域服务 │ └───────────────────────────────┬──────────────────────────────────────┘ │ ┌───────────────────────────────▼──────────────────────────────────────┐ │ 基础设施层Infrastructure Layer │ │ MySQL · ElasticSearch · Redis · 消息队列 · RPC Client │ └──────────────────────────────────────────────────────────────────────┘图Coze Studio 的四层架构。前端负责可视化编排API 层处理 HTTP 请求应用层协调用例领域层承载核心业务逻辑基础设施层提供技术支撑。各层职责层级职责关键目录API 层处理 HTTP 请求、路由、认证以及请求/响应序列化backend/api/应用层编排领域对象以执行特定用例管理事务backend/application/{domain}领域层包含核心业务模型和规则backend/domain/{domain}基础设施层提供技术能力如数据库访问backend/infra/看到这里你可能会问为什么 Coze Studio 要用 DDD 分层架构而不是简单的 MVC因为 Coze Studio 不是一个简单的 CRUD 应用——它需要处理 Agent 创建、工作流编排、知识库检索、插件集成等多个复杂领域。DDD 的分层架构让每个领域可以独立演进核心业务逻辑不依赖技术细节。应用层作为“协调器”编排领域对象领域层作为“承重墙”承载核心规则基础设施层作为“可插拔的适配器”提供技术能力。技术架构特点层次技术选型说明后端语言Golang高性能、高并发微服务框架CloudWeGo字节跳动开源微服务治理框架HTTP 框架Hertz字节开源的高性能 HTTP 框架LLM 接入层Eino字节开源的 LLM 应用框架前端框架React 18 TypeScript现代化组件化 UI前端包管理Rush.js135 前端包 Monorepo 管理UI 组件库Semi Design字节开源的企业级设计系统2.2 设计哲学DDD 是骨架工作流是心脏Coze Studio 的设计围绕几个核心哲学展开哲学一领域驱动设计DDD是骨架。后端使用 Golang 开发并遵循微服务架构中的领域驱动设计方法。代码围绕业务领域组织并将不同关注点分离到不同的层次中。每个业务领域都遵循 API → 应用 → 领域 → 基础设施的分层架构。哲学二工作流引擎是心脏。Coze Studio 开源的核心是完整的工作流引擎——这是扣子团队投入最大精力构建的核心组件。工作流引擎基于 DAG 的编排运行时它将可视化画布设计转化为可执行、可恢复且可流式传输的计算图。哲学三编译时 运行时双阶段执行。工作流引擎遵循清晰的编译时Compile Time和运行时Runtime阶段划分。编译时将画布 JSON 编译为可执行的 Runnable运行时由 WorkflowRunner 驱动执行。2.3 包结构与代码规模Coze Studio 整体采用 Monorepo 架构项目结构如下coze-studio/ ├── backend/ # 后端服务Go │ ├── api/ # API 路由与处理器 │ ├── application/ # 应用服务层 │ │ ├── agent/ # Agent 应用服务 │ │ ├── conversation/ # 对话应用服务 │ │ ├── knowledge/ # 知识库应用服务 │ │ └── workflow/ # 工作流应用服务 │ ├── domain/ # 领域层 │ │ ├── agent/ # Agent 领域 │ │ ├── workflow/ # 工作流领域 │ │ │ ├── internal/ # 内部实现 │ │ │ │ ├── canvas/ # 画布解析与适配 │ │ │ │ └── compose/ # 编译与执行引擎 │ │ ├── knowledge/ # 知识库领域 │ │ ├── plugin/ # 插件领域 │ │ └── conversation/ # 对话领域 │ └── infra/ # 基础设施层 ├── web/ # 前端应用React TypeScript └── docker/ # Docker 部署配置三、核心抽象与编程模型3.1 领域层——DDD 的“承重墙”Coze Studio 的架构围绕几个核心领域组织领域职责源码位置代理系统Agent创建能够理解自然语言、执行任务并与用户互动的智能 AI 代理backend/domain/agent工作流引擎Workflow通过可视化工作流设计实现复杂业务逻辑的编排backend/domain/workflow知识管理Knowledge通过 RAG 技术将外部知识与 LLMs 集成backend/domain/knowledge插件架构Plugin通过外部服务和 API 集成扩展代理能力backend/domain/plugin对话系统Conversation管理用户与 AI 代理之间的互动backend/domain/conversation内存系统Memory为代理提供持久化能力backend/domain/memory每个领域内部都遵循 DDD 的分层结构领域服务位于backend/domain/{domain}/service实现核心业务逻辑和领域规则应用服务位于backend/application/{domain}协调各领域并向 API 层暴露功能3.2 工作流引擎——从可视化画布到可执行代码Coze 工作流引擎是整个平台最核心的模块。它回答了三个关键问题一个可视化的画布定义JSON是如何被翻译成机器可以理解和执行的代码的当一个需要用户输入的节点出现时工作流是如何优雅地暂停、等待然后从断点处无缝恢复的复杂的循环、分支和嵌套逻辑又是如何在后端被精确调度和执行的工作流的生命周期分为两个核心阶段┌─────────────────────────────────────────────────────────────────────┐ │ 编译时Compile Time │ │ │ │ vo.Canvas前端画布 JSON │ │ ↓ CanvasToWorkflowSchema() │ │ compose.WorkflowSchema纯净逻辑结构 │ │ ↓ 实例化节点、解析依赖 │ │ compose.Workflow中间状态“装配台” │ │ ↓ 构建 DAG │ │ compose.Runnable可执行实例无状态、可复用 │ ├─────────────────────────────────────────────────────────────────────┤ │ 运行时Runtime │ │ │ │ compose.WorkflowRunner“总指挥” │ │ ↓ 注入上下文、事件回调、中断恢复状态 │ │ 执行 → 产生输出/事件节点开始/结束、等待用户输入等 │ └─────────────────────────────────────────────────────────────────────┘图Coze 工作流的双阶段生命周期。编译时将画布 JSON 转化为无状态可复用的 Runnable运行时由 WorkflowRunner 注入上下文驱动执行。核心数据结构数据结构职责vo.Canvas前端画布的原始 JSON 定义包含节点、边、位置等可视化信息compose.WorkflowSchema剥离可视化细节后的纯净逻辑结构compose.NodeSchema单个节点的详细定义InputSources字段精确定义每个输入参数的来源compose.Workflow中间状态的“装配台”负责实例化节点、解析依赖compose.Runnable编译的最终产物——真正“可执行”的实例无状态、可复用compose.WorkflowRunner运行时的“总指挥”为 Runnable 注入本次运行的上下文3.3 API 架构——Hertz 驱动的分层路由Coze Studio 的 API 基于分层架构使用Hertz网络框架构建。API 路由组织API 基础路径描述版本状态/api/*核心内部 API 端点当前/v1/*OpenAPI 兼容的 RESTful 端点稳定/v3/*最新一代端点最新核心 API 组API 组职责/api/conversation管理聊天交互、消息和对话历史/api/knowledge处理知识库、文档和数据检索/api/memory管理数据库连接和变量存储/api/plugin_api集成和管理外部插件和 API/api/workflow_api创建、执行和管理代理工作流认证机制基于会话的认证网页界面用户个人访问令牌PAT用于 API 集成OAuth用于第三方集成四、核心模块源码解析4.1 服务层——三层服务架构Coze Studio 采用分层服务架构将服务组织成三个层级层级职责依赖基础服务仅依赖于基础设施组件数据库、缓存、外部客户端基础设施层主要服务基于基础服务构建提供更复杂功能基础服务复杂服务协调主要服务以实现最终用户功能主要服务每个服务使用ServiceComponents结构体来清晰管理依赖使依赖关系明确通过依赖注入实现清晰的测试。领域服务与应用服务的区分服务类型位置职责领域服务/backend/domain/{domain}/service实现核心业务逻辑和领域规则应用服务/backend/application/{domain}协调各领域并向 API 层暴露功能跨领域服务通信通过跨领域服务注册表实现跨领域契约定义在/backend/crossdomain/contract跨领域实现位于/backend/crossdomain/impl全局注册表在初始化期间注册默认实现4.2 工作流编译引擎——从 Canvas 到 Runnable编译阶段的核心任务是将一份静态的、描述性的WorkflowSchema转变为一个动态的、包含了所有执行逻辑的Runnable对象。第一步从 Canvas 到 Schema// 文件路径backend/domain/workflow/internal/canvas/adaptor/to_schema.gofuncCanvasToWorkflowSchema(ctx context.Context,s*vo.Canvas)(sc*compose.WorkflowSchema,errerror,){// 1. 裁剪孤立节点移除任何没有连接的节点connectedNodes,_:...// 2. 构建节点列表和连接关系// 3. 解析层级关系用于循环等复合节点// 4. 返回纯净的 WorkflowSchema}InputSources是NodeSchema中最重要的字段。它精确定义了当前节点的每个输入参数分别来自哪里上游节点的哪个输出、一个固定的静态值、还是全局变量是后续依赖解析的基石。设计模式解读CanvasToWorkflowSchema是适配器模式Adapter Pattern的应用——它将前端画布的“可视化格式”适配为后端引擎的“逻辑格式”剥离了所有与执行无关的 UI 信息。4.3 工作流运行时引擎——可中断、可恢复的执行Coze 工作流引擎最令人着迷的特性之一是可中断、可恢复的执行能力。当一个需要用户输入的节点如“问答”节点出现时工作流会优雅地暂停保存当前执行状态等待用户输入释放计算资源从断点无缝恢复用户输入到达后从保存的状态继续执行工作流引擎构建于Eino 组合框架之上支持35 种以上的节点类型。执行引擎基于DAG 的编排运行时支持流式传输。设计模式解读这种机制是状态模式State Pattern和备忘录模式Memento Pattern的结合——工作流执行状态被保存为“备忘录”恢复时从备忘录重建状态机。4.4 插件架构——OpenAPI 3.0 驱动的可扩展系统Coze Studio 的插件架构提供了一个灵活且可扩展的框架用于将外部工具和服务集成到代理和工作流程中。核心组件插件注册表插件的集中存储和管理插件执行引擎处理插件操作的调用插件开发框架用于创建新插件的工具和 API集成点插件如何与代理和工作流程连接每个插件都遵循OpenAPI 3.0 规范使其与标准 API 文档和工具兼容。五、核心执行流程与运行时机制5.1 完整执行流程——从画布点击到结果返回当用户在 Coze Studio 画布上点击“运行”时底层发生了什么┌─────────────────────────────────────────────────────────────────────┐ │ 1. 用户在前端画布拖拽节点定义数据流向 │ │ ↓ │ │ 2. 前端将画布状态序列化为 Canvas JSON │ │ ↓ │ │ 3. 前端通过 HTTP API 将 Canvas 提交到后端 │ │ ↓ │ │ 4. API 层Hertz接收请求 → 认证 → 路由到工作流处理器 │ │ ↓ │ │ 5. 编译阶段 │ │ ├── CanvasToWorkflowSchema()裁剪孤立节点、构建 Schema │ │ ├── 构建 Workflow装配台实例化节点、解析依赖 │ │ └── 编译为 Runnable可执行实例无状态 │ │ ↓ │ │ 6. 运行时创建 WorkflowRunner │ │ ├── 注入本次运行的上下文输入参数、事件回调 │ │ └── 按拓扑序调度节点执行 │ │ ↓ │ │ 7. 节点执行 │ │ ├── 遇到需要用户输入的节点 → 暂停 → 保存状态 → 等待恢复 │ │ ├── 普通节点 → 执行 → 产生事件节点开始/结束 │ │ └── 所有节点完成 → 返回结果 │ │ ↓ │ │ 8. 结果通过流式方式返回前端 │ └─────────────────────────────────────────────────────────────────────┘图Coze Studio 工作流的完整执行流程。从画布拖拽到结果返回经历前端序列化、API 路由、编译阶段Canvas → Schema → Workflow → Runnable和运行时阶段Runner 执行的全链路。关键设计编译时与运行时分离使得工作流定义可以提前验证和优化Runnable 无状态可复用支持高并发执行。5.2 请求流转——Handler → Application → Domain请求在Handler → Application → Domain三层之间清晰流转API 处理程序接收 HTTP 请求调用应用服务方法应用服务使用多个领域服务实现功能领域服务操作领域实体CreateConversation方法的实现路径展示了清晰的分层——API 层收到请求后调用应用服务应用服务协调多个领域服务完成创建领域服务操作各自的领域实体。5.3 运行时关键决策的权衡分析决策方案收益代价后端语言Golang vs Python高并发、低内存、静态类型、性能优异AI/ML 生态不如 Python 丰富架构风格微服务 vs 单体灵活扩展、模块替换部署运维复杂度高工作流引擎自研基于 Einovs 使用开源引擎轻量、低延迟、支持流式需要自行维护引擎演进执行模型编译时 运行时分离提前验证、可复用 Runnable首次执行有编译延迟中断恢复状态持久化 断点续传长运行任务可恢复存储和序列化开销六、工程化实践6.1 快速接入环境要求2 Core、4 GB 最低配置Docker 和 Docker Compose部署步骤# 1. 克隆代码gitclone https://github.com/coze-dev/coze-studio.git# 2. 配置模型# 从模板目录复制模型配置文件# 3. 启动服务docker-composeup-d6.2 自定义插件开发Coze Studio 的插件遵循 OpenAPI 3.0 规范。开发一个新插件的核心步骤定义 OpenAPI 3.0 规范的 API 文档通过插件注册表注册插件插件执行引擎处理调用6.3 可观测性与调试Coze Studio 提供了多层次的可观测性能力API 中间件认证、日志、追踪事件系统工作流执行过程中的节点开始/结束事件OpenAPI 兼容端点标准化的 API 访问6.4 常见工程陷阱与解决方案陷阱 1工作流循环导致无限执行现象工作流在循环节点中无限执行永不停止。原因循环节点缺少正确的退出条件配置。解决方案Coze 工作流引擎通过Hierarchy层级关系来表达循环等复合节点的父子结构。在循环节点中配置最大迭代次数或条件退出表达式。陷阱 2编译阶段失败导致工作流无法运行现象画布保存成功但运行时提示“工作流编译失败”。原因画布中存在孤立节点或循环依赖。解决方案CanvasToWorkflowSchema函数会自动裁剪孤立节点但循环依赖需要通过 DAG 环检测在编译阶段捕获。七、总结与展望7.1 关键版本里程碑版本/事件时间核心变化Coze 平台发布2023 年字节跳动推出 AI Bot 开发平台Coze Studio 开源2025 年 7 月 25 日字节跳动将核心项目开源v0.2.52026 年 6 月开源版本持续迭代7.2 横向对比Coze Studio vs Dify vs Flowise7.2.1 可比性说明Coze Studio、Dify、Flowise 均定位于LLM 应用开发平台或工具都提供可视化工作流编排能力。三者在功能定位上有重叠但各自的技术栈、设计哲学和部署方式不同。7.2.2 横向对比表对比维度Coze StudioDifyFlowise核心定位字节跳动开源 AI Agent 开发平台开源 LLM 应用开发平台开源低代码 LLM 工具后端语言GolangPythonFlaskTypeScriptNode.js架构风格微服务 DDD模块化单体单体工作流引擎自研 DAG Eino自研 DAG Worker Pool基础 DAG前端技术React TypeScript Semi DesignNext.js ReactReact部署方式Docker ComposeDocker Compose7 容器Docker开源协议待确认Apache 2.0MIT商业版本Coze 平台SaaSDify Cloud无7.2.3 差异来源分析框架/平台核心判断架构推论Coze StudioAI 应用平台需要高性能、高并发的底层支撑用 Golang 微服务 DDD 构建企业级平台DifyLLM 应用开发需要完整平台——不只是代码库用 Python 模块化单体构建完整产品Flowise非开发者需要低代码构建 AI 应用用 Node.js 可视化拖拽降低门槛7.2.4 结论性建议场景推荐选择核心理由需要高性能、高并发的工作流引擎Coze StudioGolang 微服务 Eino 框架需要 Python 技术栈的完整平台DifyPython 生态最丰富需要轻量级、快速原型验证FlowiseNode.js 生态部署简单7.3 设计哲学提炼Coze Studio 的设计哲学可以提炼为三个关键词DDD 是骨架围绕业务领域组织代码将复杂系统拆解为可独立演进的领域模块工作流是心脏编译时 运行时双阶段引擎让可视化画布变成可执行、可恢复的系统微服务是血脉基于 CloudWeGo 技术栈的微服务架构提供高性能和高扩展性7.4 核心架构亮点亮点说明DDD 分层架构API → 应用 → 领域 → 基础设施四层清晰分离编译时 运行时双阶段引擎Canvas → Schema → Workflow → Runnable → Runner可中断可恢复执行工作流可在用户交互节点暂停从断点无缝恢复Eino 框架集成字节开源 LLM 应用框架支持 35 节点类型Hertz HTTP 框架字节开源高性能 HTTP 框架OpenAPI 3.0 插件标准任何符合 OpenAPI 规范的外部服务都可接入7.5 对开发者的启示与适用场景Coze Studio 的本质不是 Coze 平台的简单开源复刻而是一套以“领域驱动设计DDD 整洁架构”为骨架、以“编译时-运行时双阶段工作流引擎”为心脏、以“可视化画布即源代码”为编程范式的生产级 AI Agent 开发平台——让复杂的 AI 工作流从“拖拽连线”变成“可编译、可中断、可恢复、可流式传输的确定性系统”。适用场景需要可视化编排复杂 AI 工作流的团队需要工作流可中断、可恢复的长运行任务场景采用Go 技术栈、追求高并发高性能的企业需要Agent 全生命周期管理开发 → 部署的系统希望基于 OpenAPI 3.0 标准接入外部工具的集成场景不适用场景简单的单次 LLM 调用直接用模型 SDK 即可Python 技术栈为主、对 Go 不熟悉的团队对部署运维复杂度敏感的小型团队需要深度定制工作流引擎的场景本文数据来源Coze Studio 官方 GitHub 仓库、开源 Coze 源码分析系列文章、CSDN 技术博客、53AI 技术文章、掘金技术文章截至 2026 年 8 月如您所在的企业正面临数字化难题或有 AI 落地、系统集成相关需求欢迎进一步沟通。我们可提供针对贵企业具体场景的定制化方案和现场调研服务。