此篇文档 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)
承载核心业务逻辑,包括 agent、workflow、conversation、knowledge、memory、plugin 等子域。智能体编排与工作流执行均在此层落地:
domain/agent/singleagent/internal/agentflow使用 Eino 的compose、flow/agent/react实现 Agent Flow。domain/workflow/internal/compose使用 Eino Workflow 构建节点图与状态机。
- 跨域防腐层(backend/crossdomain)
为各子域提供稳定的交互接口,避免应用层或其他域直接依赖领域实现。以 crossdomain/workflow、crossdomain/agent、crossdomain/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/ 提供 logs、errorx、safego、ctxcache 等无外部依赖工具。
前端架构
前端采用 monorepo 模式(Rush + PNPM):
apps/coze-studio:主应用,承载完整的 Studio UI 与路由。
packages/核心能力拆分为多个包:
agent-ide:Agent 开发界面与交互逻辑。workflow:工作流画布引擎(如fabric-canvas、nodes、sdk、playground),对接 FlowGram。data:知识、记忆等数据访问层。studio、arch、components、common:整体布局、基础设施与 UI 组件库。
这样的分层使前后端都围绕「Agent / Workflow / Resource」三个核心维度进行模块化拆分,形成清晰的技术骨架。
03
—
核心机制深度剖析
DDD分层与 crossdomain 防腐机制
application/application.go 体现了后端的核心装配流程:
- 通过
appinfra.Init初始化数据库、缓存、存储、ID 生成器、事件总线、CheckPoint 存储等基础设施。 - 按依赖拓扑将服务分为:
basicServices:只依赖 infra,如用户、模板、模型管理、上传、权限。primaryServices:依赖 basic,如插件、记忆、知识、工作流、快捷指令。complexServices:在 primary 之上构建智能体、应用、搜索、会话。
- 构造完成后,通过
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/compose与flow/agent/react,将 Agent 的 Prompt、工具、变量、知识与工作流引用组合成一个可执行的 Eino Flow。- 通过
Config注入Agent实体、用户身份、自定义变量、会话 ID 与 CheckPointStore,使 Agent 具备状态持久化与可追踪能力。 callback_reply_chunk.go利用 Eino 的callbacks机制,将模型输出、工具调用中间状态以流式方式回传,用于前端增量渲染。
- 工作流执行
在 domain/workflow/internal/compose:
workflow.go将compose.Workflow[map[string]any, map[string]any]封装为领域中的Workflow类型,并维护节点集合、入口出口等上下文。state.go引入 Eino 的components/model与schema,在执行前将画布配置映射为 Eino Workflow 的节点与边。workflow_tool.go把工作流节点中的工具配置(如插件、检索器)组合成 Einotool组件,并配合callbacks实现运行时观测。
- 会话与 AgentRun
在 domain/conversation/agentrun/internal 中,代码大量使用 eino/schema 与跨域的 workflow/agent 接口,将用户消息、历史上下文、工作流执行结果统一映射为对话消息流,支撑聊天和多轮任务执行。
整体来看,Eino 作为运行时基座提供了模型抽象、工具调用、检索与状态管理能力,而 Coze Studio 在其之上构建了一套「Agent + Workflow + Conversation」的领域模型。
上图显示从加载工作流定义、构建 Eino 工作流图、按节点类型执行、持久化中间状态,到输出终止计划和执行结果的完整流程。
知识与 Embedding 子系统
知识相关逻辑由 domain/knowledge 与 infra/embedding、infra/es 共同完成:
infra/embedding/embedding.go抽象出 Embedder 接口,并在 Eino components/embedding 之上扩展:
EmbedStringsHybrid支持同时生成稠密向量与稀疏向量,方便对接混合检索(向量 + BM25 等)。SupportStatus标明底层模型支持的能力(纯稠密 / 稠密+稀疏)。
- 应用层通过
knowledge.InitService和memory.InitService将 Embedding、存储与事件总线整合,形成知识入库、索引构建与查询的一整套闭环。
这使得 Coze Studio 的 RAG 能力既可以依赖默认的 embedding 实现,也可以通过替换 impl 实现对接自定义向量服务。
事件驱动的资源与搜索体系
事件总线是连接资源管理与搜索/推荐能力的关键纽带:
- 在
application.Init中:
initEventBus将infra.eventbus的 ConsumerService 初始化为具体实现,并基于infra.AppEventProducer、infra.ResourceEventProducer构造search.ResourceEventBus与search.ProjectEventBus。
knowledge.InitService、prompt.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-api、data/*与后端 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 执行路径
典型对话请求的关键路径为:
- 入口:Hertz 接收请求 → Middleware 链(ContextCache、RequestInspector、Host 注入、LogID、CORS、AccessLog、OpenAPI 鉴权、SessionAuth、I18n)。
- 应用编排:API Handler 调用
application/conversation与application/singleagent、application/workflow,根据会话类型选择具体执行策略(例如走单 Agent Flow 或工作流驱动的 ChatFlow)。 - 领域执行:
- 在
domain/conversation/agentrun中构造本次 AgentRun 的上下文(消息历史、用户身份、自定义变量等); - 调用
domain/agent/singleagent中的 agentflow,通过 Eino 执行模型推理、工具调用、知识检索; - 部分场景下调用
domain/workflow执行工作流节点。
- 模型与检索:
- 通过
bizpkg/llm/modelbuilder与 Eino 的 model 组件统一调用 OpenAI/火山引擎等模型; - 通过
infra/embedding和infra/es完成向量搜索和文本检索; - 使用缓存与数据库访问记录会话与运行结果。
- 回传与流式输出:Eino callbacks 将 token、tool step 以流式事件经
infra/sse推送前端,前端增量渲染。
在这一链路中,性能瓶颈主要在:模型调用、知识检索(ES/向量库)以及数据库写入。Hertz 提供高并发 HTTP 能力,Goroutine 实现业务层的并发流水,而事件总线与异步索引机制则避免了在主链路中做重计算。
工作流执行路径
工作流执行主要通过 domain/workflow/internal/compose:
- 应用层根据用户配置与输入调用 workflow domain 的
Executable.SyncExecute。 - Compose 层将画布配置转换为 Eino Workflow 图,构造节点、边与状态存储。
- 在执行过程中:
- 模型节点通过统一 model 抽象调用不同大模型;
- 工具节点通过
components/tool封装插件调用、变量替换与外部 API 访问; - CheckPoint 通过
infra/checkpoint落盘,支持长流程恢复与审计。
- 执行结果和中间状态传回 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