从 DDD 到 Workflow Runtime:拆解 Coze Studio 的全栈技术架构

简介: 从 AI Agent 平台定位、DDD 分层与 crossdomain 设计出发,重点剖析 Coze Studio 基于 Eino 的智能体与工作流运行机制、事件驱动的资源与搜索体系及会话关键路径,并简要展望多模型协同和基础设施可插拔的演进方向。

此篇文档 AI 内容占比约 70% ,阅读耗时约 11 分钟。内容核准:管鑫荣


Coze Studio 是一个面向 AI Agent 全生命周期的一体化开发平台,其开源版本不仅提供了从模型管理、知识库、插件到可视化工作流的完整能力,更将这些能力沉淀为一套可二次开发的工程化底座。后端基于 Golang 与 CloudWeGo Hertz,采用典型的 DDD 分层架构与事件驱动机制;前端采用 React + TypeScript 的 monorepo 架构,围绕 Agent IDE 与工作流画布提供高度模块化的 UI 与运行时配套。得益于对 Eino 智能体/工作流运行时、FlowGram 工作流画布等基础能力的整合,Coze Studio 既能支持拖拽式低代码构建,又为复杂业务中的定制逻辑预留了足够的扩展空间。对于希望在企业场景中落地多智能体系统、知识增强对话和复杂流程编排的团队而言,这个项目本身就是一套工程实践模板。



01

项目定位与技术背景



从定位上看,Coze Studio 并不是单一的聊天机器人框架,而是「AI Agent 开发平台 + 可视化工作流编排引擎 + 资源中心」的组合体。它源自长期服务企业与开发者的商业平台,将核心引擎以 Apache 2.0 方式开源,目标是降低 Agent 开发门槛、统一研发体验、沉淀最佳实践。



技术背景上,后端选择 Go 及 Hertz 作为高性能 HTTP 内核,结合 DDD 分层构建出清晰的领域边界与演化路线。智能体与工作流执行侧引入 CloudWeGo Eino 作为运行时基座,在此之上整合模型调用、工具调用、检索增强(RAG)、混合向量检索等能力。前端则基于 React 18 + Rsbuild + Rush + PNPM 搭建大前端工程体系,通过 apps + packages 的拆分承载 Agent IDE、工作流引擎、数据层与通用组件库。



02

系统架构



下图从浏览器到前端、后端各分层以及外部基础设施与模型服务,展示了 Coze Studio 的端到端系统结构。



文中涉及的目录结构与文件路径为基于公开资料与典型工程实践的示意抽象,用于说明系统职责划分,真实结构请以官方仓库为准。


后端架构


后端整体形态是「单体内的微服务化模块」,按 DDD 思路划分为:


  • API 层(backend/api)  

    基于 Hertz 的 HTTP 入口,包含路由、Handler、Middleware 和 API 模型转换。main.go 中配置 CORS、日志、鉴权、国际化等中间件链,并注册自动生成的路由。


  • 应用层(backend/application)  

将基础设施与领域服务组装成可被 API 直接调用的「用例服务」。application.go 中通过 Init 分别构建 basic/primary/complex 三类 ApplicationService,并注册到各个 crossdomain 门面,例如 crossworkflow.SetDefaultSVC(...)crossagent.SetDefaultSVC(...)。这一层负责事务边界、编排多领域交互。


  • 领域层(backend/domain)  

承载核心业务逻辑,包括 agentworkflowconversationknowledgememoryplugin 等子域。智能体编排与工作流执行均在此层落地:

  • domain/agent/singleagent/internal/agentflow 使用 Eino 的 composeflow/agent/react 实现 Agent Flow。
  • domain/workflow/internal/compose 使用 Eino Workflow 构建节点图与状态机。


  • 跨域防腐层(backend/crossdomain)  

为各子域提供稳定的交互接口,避免应用层或其他域直接依赖领域实现。以 crossdomain/workflowcrossdomain/agentcrossdomain/conversation 等为代表,通过 impl 包适配领域服务与跨域接口,形成 Anti-Corruption Layer。


  • 基础设施层(backend/infra)  

提供对外部系统的统一抽象与实现:

  • infra/eventbus:定义 Producer / ConsumerService 接口及消息结构,由 impl 下的实现对接 RocketMQ / NATS / Pulsar 等。
  • infra/embedding:定义统一 Embedder 接口,支持稠密与稀疏混合向量。
  • 其它如 rdb(数据库访问)、cache(Redis)、storage(MinIO)、imagex(素材处理)、checkpoint(工作流 Checkpoint 存储)、sse(流式推送)等。


  • IDL 与工具层

idl/ 通过 Thrift 定义后端 API 契约;pkg/ 提供 logserrorxsafegoctxcache 等无外部依赖工具。


前端架构


前端采用 monorepo 模式(Rush + PNPM):


  • apps/coze-studio:主应用,承载完整的 Studio UI 与路由。


  • packages/ 核心能力拆分为多个包:
  • agent-ide:Agent 开发界面与交互逻辑。
  • workflow:工作流画布引擎(如 fabric-canvasnodessdkplayground),对接 FlowGram。
  • data:知识、记忆等数据访问层。
  • studioarchcomponentscommon:整体布局、基础设施与 UI 组件库。


这样的分层使前后端都围绕「Agent / Workflow / Resource」三个核心维度进行模块化拆分,形成清晰的技术骨架。



03

核心机制深度剖析


DDD分层与 crossdomain 防腐机制


application/application.go 体现了后端的核心装配流程:

  1. 通过 appinfra.Init 初始化数据库、缓存、存储、ID 生成器、事件总线、CheckPoint 存储等基础设施。
  2. 按依赖拓扑将服务分为:
  • basicServices:只依赖 infra,如用户、模板、模型管理、上传、权限。
  • primaryServices:依赖 basic,如插件、记忆、知识、工作流、快捷指令。
  • complexServices:在 primary 之上构建智能体、应用、搜索、会话。
  1. 构造完成后,通过
  • crossworkflow.SetDefaultSVC(workflowImpl.InitDomainService(...))
  • crossagent.SetDefaultSVC(singleagentImpl.InitDomainService(...))


这样,API 层只依赖 crossdomain 接口而非具体领域实现,领域之间的调用也通过 crossdomain 完成,既实现了隔离,又为今后重构或拆分服务预留空间。


基于 Eino 的智能体与工作流运行时


Coze Studio 的 Agent 与工作流执行能力建立在 Eino 之上:


  • 单智能体编排(SingleAgent)  

domain/agent/singleagent/internal/agentflow 中:

  • agent_flow_builder.go 使用 eino/composeflow/agent/react,将 Agent 的 Prompt、工具、变量、知识与工作流引用组合成一个可执行的 Eino Flow。
  • 通过 Config 注入 Agent 实体、用户身份、自定义变量、会话 ID 与 CheckPointStore,使 Agent 具备状态持久化与可追踪能力。
  • callback_reply_chunk.go 利用 Eino 的 callbacks 机制,将模型输出、工具调用中间状态以流式方式回传,用于前端增量渲染。


  • 工作流执行  

domain/workflow/internal/compose

  • workflow.gocompose.Workflow[map[string]any, map[string]any] 封装为领域中的 Workflow 类型,并维护节点集合、入口出口等上下文。
  • state.go 引入 Eino 的 components/modelschema,在执行前将画布配置映射为 Eino Workflow 的节点与边。
  • workflow_tool.go 把工作流节点中的工具配置(如插件、检索器)组合成 Eino tool 组件,并配合 callbacks 实现运行时观测。


  • 会话与 AgentRun  

domain/conversation/agentrun/internal 中,代码大量使用 eino/schema 与跨域的 workflow/agent 接口,将用户消息、历史上下文、工作流执行结果统一映射为对话消息流,支撑聊天和多轮任务执行。


整体来看,Eino 作为运行时基座提供了模型抽象、工具调用、检索与状态管理能力,而 Coze Studio 在其之上构建了一套「Agent + Workflow + Conversation」的领域模型。




上图显示从加载工作流定义、构建 Eino 工作流图、按节点类型执行、持久化中间状态,到输出终止计划和执行结果的完整流程。


知识与 Embedding 子系统


知识相关逻辑由 domain/knowledgeinfra/embeddinginfra/es 共同完成:


  • infra/embedding/embedding.go 抽象出 Embedder 接口,并在 Eino components/embedding 之上扩展:
  • EmbedStringsHybrid 支持同时生成稠密向量与稀疏向量,方便对接混合检索(向量 + BM25 等)。
  • SupportStatus 标明底层模型支持的能力(纯稠密 / 稠密+稀疏)。


  • 应用层通过 knowledge.InitServicememory.InitService 将 Embedding、存储与事件总线整合,形成知识入库、索引构建与查询的一整套闭环。


这使得 Coze Studio 的 RAG 能力既可以依赖默认的 embedding 实现,也可以通过替换 impl 实现对接自定义向量服务。


事件驱动的资源与搜索体系


事件总线是连接资源管理与搜索/推荐能力的关键纽带:


  • 在  application.Init 中:
  • initEventBusinfra.eventbus 的 ConsumerService 初始化为具体实现,并基于 infra.AppEventProducerinfra.ResourceEventProducer 构造 search.ResourceEventBussearch.ProjectEventBus


  • knowledge.InitServiceprompt.InitService 等在资源变更时向 eventbus 发送消息,由搜索服务的 Consumer 异步消费,更新 Elasticsearch 等索引。


  • infra/eventbus/eventbus.go 则提供统一接口:
  • 上游通过 Producer.Send/BatchSend 发送消息。
  • 下游使用 ConsumerService.RegisterConsumer 注册不同 topic/group 的消费逻辑。


这种设计将资源变更与搜索索引更新解耦,提高了系统的稳定性与扩展性:可以在不影响主业务链路的情况下扩展新的下游消费者(如审计、监控、分析)。


前端 Agent IDE 与工作流画布


前端围绕 Agent 与 Workflow 进行了深度抽象:


  • packages/agent-ide 负责智能体开发(Prompt 编辑、工具配置、知识关联、Debug 等),通过 arch/bot-apidata/* 与后端 crossdomain 接口交互。


  • packages/workflow 提供 fabric-canvas、nodes、sdk、playground 等模块:
  • 画布与节点视图由 FlowGram 驱动,与后端的 workflow schema 对应。
  • SDK 封装工作流的保存、发布、执行、调试调用链。


  • 应用 apps/coze-studio 将 Agent IDE、Workflow、Resource 管理统一集成,通过 React Router 构建一体化的 Studio 体验。


前端在工程上使用 Rsbuild + Vitest + ESLint/Stylelint/Tailwind 配置集中管理,使画布、IDE 与 Studio 可以独立演进、但在同一工程规范下协同。



04

性能关键路径分析



下图描述的「用户发起一次对话请求」的关键路径。



性能路径分析基于系统架构推断与通用工程实践,具体实现细节可能随版本演进有所调整。


会话与 Agent 执行路径


典型对话请求的关键路径为:

  1. 入口:Hertz 接收请求 → Middleware 链(ContextCache、RequestInspector、Host 注入、LogID、CORS、AccessLog、OpenAPI 鉴权、SessionAuth、I18n)。
  2. 应用编排:API Handler 调用 application/conversationapplication/singleagentapplication/workflow,根据会话类型选择具体执行策略(例如走单 Agent Flow 或工作流驱动的 ChatFlow)。
  3. 领域执行
  • domain/conversation/agentrun 中构造本次 AgentRun 的上下文(消息历史、用户身份、自定义变量等);
  • 调用 domain/agent/singleagent 中的 agentflow,通过 Eino 执行模型推理、工具调用、知识检索;
  • 部分场景下调用 domain/workflow 执行工作流节点。
  1. 模型与检索
  • 通过 bizpkg/llm/modelbuilder 与 Eino 的 model 组件统一调用 OpenAI/火山引擎等模型;
  • 通过 infra/embeddinginfra/es 完成向量搜索和文本检索;
  • 使用缓存与数据库访问记录会话与运行结果。
  1. 回传与流式输出:Eino callbacks 将 token、tool step 以流式事件经 infra/sse 推送前端,前端增量渲染。


在这一链路中,性能瓶颈主要在:模型调用、知识检索(ES/向量库)以及数据库写入。Hertz 提供高并发 HTTP 能力,Goroutine 实现业务层的并发流水,而事件总线与异步索引机制则避免了在主链路中做重计算。


工作流执行路径


工作流执行主要通过 domain/workflow/internal/compose

  1. 应用层根据用户配置与输入调用 workflow domain 的 Executable.SyncExecute
  2. Compose 层将画布配置转换为 Eino Workflow 图,构造节点、边与状态存储。
  3. 在执行过程中:
  • 模型节点通过统一 model 抽象调用不同大模型;
  • 工具节点通过 components/tool 封装插件调用、变量替换与外部 API 访问;
  • CheckPoint 通过 infra/checkpoint 落盘,支持长流程恢复与审计。
  1. 执行结果和中间状态传回 conversation/agent 子域,再统一回传前端。


这里的性能关键在于节点级别的 IO(外部 API / DB / MQ)与模型调用。通过 Eino Workflow 内建并发调度与 Goroutine 支持,可并发执行部分无依赖节点,从而缩短整体延迟。



05

演进路线分析



从当前架构可以看出,Coze Studio 为演进预留了多个关键扩展点:


  • 基础设施可插拔

eventbus、embedding、storage、sqlparser 等均通过接口 + impl 的模式解耦,实现层集中在 impl 目录。结合 docs 中 NATS/Pulsar/OceanBase 指南,可以预见未来将持续扩展更多 MQ、数据库、向量引擎的适配,进一步提升在不同基础设施栈上的落地能力。


  • 多模型与多 Agent 编排

依托 Eino 的模型抽象与 agent flow 能力,可以较为自然地扩展为多模型协同、多 Agent 协作(如 RouterAgent、Planner/Worker 模式),在领域层通过新增实体与服务即可支持更复杂的协作模式。


  • 工作流与画布能力升级

前端 workflow 包与后端 workflow compose 形成清晰协议,未来可扩展更丰富的节点类型(如长任务调度、异步回调节点、数据转换节点),以及更强的可观测性(节点级指标、Trace、回放)。


  • 生态与插件化

插件、连接器、数据库、知识、变量等统一归为「资源」,通过事件总线联动搜索与推荐。未来可以围绕这一抽象构建更完整的插件市场与生态规范,使第三方可以以较低成本接入。


  • 服务拆分与云原生化

当前是模块化单体,DDD 边界与 crossdomain 层已经为服务拆分提供了天然切分点。随着规模扩大,可以将 agent、workflow、conversation、search 等子域拆分为独立服务,通过 RPC 或消息队列通信,在 Kubernetes 等环境下实现弹性扩缩。


总体来看,Coze Studio 已经具备从「单体内微服务化」平滑演进到「多服务协同」的结构基础,同时也为在多模型、混合检索与复杂编排场景中的持续增强预留了充分空间。


以上演进分析基于当前架构设计与行业趋势的工程推断,请以官方实际路线图为准。



06

总结



综合来看,Coze Studio 不是简单的开源 Demo,而是一套具有代表性的 AI Agent 工程化实践案例。后端采用 DDD + Hertz + Eino,将 Agent、Workflow、Conversation、Knowledge 等核心概念抽象为清晰的领域模型,通过 crossdomain 防腐层与 pluggable infra 实现良好的可维护性与可扩展性;前端基于 React monorepo,围绕 Agent IDE 与工作流画布构建了高度模块化的交互与运行体验。事件驱动的资源与搜索体系、可插拔的 embedding 与存储实现,使其能够在不同基础设施栈与企业环境中适配落地。对于有意搭建自有 AI Agent 平台、沉淀企业知识与业务流程编排能力的团队,Coze Studio 既可作为直接使用的产品基础,也可以作为再造一套平台时的重要架构参考。



参考链接:

[1] 什么是 Coze Studio

[2] Github eino




🚀 🚀 阿里云 EDAS 也提供了一键部署 coze 的能力,快访问下方链接体验吧!

https://edasnext.console.aliyun.com/#/home?regionNo=cn-hangzhou&tab=marketplace&marketDetail=coze

目录
相关文章
|
23天前
|
数据采集 人工智能 运维
AgentRun 实战:快速构建 AI 舆情实时分析专家
搭建“舆情分析专家”,函数计算 AgentRun 快速实现从数据采集到报告生成全自动化 Agent。
731 56
|
3天前
|
机器学习/深度学习 人工智能 自然语言处理
Claude Cowork:当AI走出聊天框,成为你的"数字同事"
Anthropic 于 2026 年 1 月发布 Claude Cowork,定位为可执行任务的“数字同事”。该产品支持直接操作本地文件,并通过沙箱隔离与子代理协作机制,在文件管理等实际场景中展现出明显优势。
167 1
Claude Cowork:当AI走出聊天框,成为你的"数字同事"
|
11天前
|
人工智能 前端开发 Java
关于Agent框架,豆包,DeepSeek、Manus都选择了它
2025年被视为Agent元年,通过向Manus、豆包、DeepSeek提问“编程框架第一性原理”,发现三者不约而同推荐阿里巴巴开源的AgentScope。
225 2
关于Agent框架,豆包,DeepSeek、Manus都选择了它
|
人工智能 NoSQL 数据可视化
n8n:16万Star超明星项目的架构解读
n8n从单体架构逐步演进为企业级集成平台,具备AI集成能力,适用于自动化场景,成为iPaaS领域的优选方案。
167 0
n8n:16万Star超明星项目的架构解读
|
14天前
|
人工智能 测试技术 开发者
AI Coding后端开发实战:解锁AI辅助编程新范式
本文系统阐述了AI时代开发者如何高效协作AI Coding工具,强调破除认知误区、构建个人上下文管理体系,并精准判断AI输出质量。通过实战流程与案例,助力开发者实现从编码到架构思维的跃迁,成为人机协同的“超级开发者”。
1110 96
|
4天前
|
人工智能 安全 机器人
麻省理工科技评论发布2026年十大突破性技术,AI独占四席
《麻省理工科技评论》2026年“十大突破性技术”榜单发布,AI技术占据四席,涵盖超大规模数据中心、机制可解释性、AI陪伴与生成式编码,彰显其主导地位。榜单不仅反映技术从“能做”到“该做”的转向,更揭示AI正深度融入社会骨骼,推动算力、伦理与产业变革,开启智能新纪元。
159 6
|
16天前
|
人工智能 自然语言处理 API
n8n:流程自动化、智能化利器
流程自动化助你在重复的业务流程中节省时间,可通过自然语言直接创建工作流啦。
554 9
n8n:流程自动化、智能化利器
|
1天前
|
人工智能 数据可视化 Apache
Coze-Studio 还是 Dify?企业级 AI Agent 开发到底该选哪个“积木箱”?
大模型兴起推动AI Agent开发热潮,但开发者面临高门槛、技术栈复杂等挑战。本文介绍字节跳动开源平台Coze-Studio,其模块化设计、Apache 2.0协议和生产级架构提供高效灵活解决方案,为开发者和企业决策者提供选型参考。
64 1
Coze-Studio 还是 Dify?企业级 AI Agent 开发到底该选哪个“积木箱”?
|
负载均衡 网络协议 Dubbo
微服务架构 | 3. 注册中心与服务发现
注册中心用来集中管理微服务,实现服务的注册,发现,检查等功能;
3813 2
微服务架构 | 3. 注册中心与服务发现
|
10天前
|
人工智能 缓存 自然语言处理
AI网关可能是当下降低推理成本最经济的工程手段
网关成大模型降本关键:无需修改代码,即可节省达 70% 推理开销。
90 3