Coze Studio 是什么?字节把扣子开源了,2.18 万星、11 个容器,最新版本停在 2 月(基础篇)

Coze Studio 是什么?字节把扣子开源了,2.18 万星、11 个容器,最新版本停在 2 月(基础篇)

2025 年 7 月底,字节把扣子的核心引擎开源,仓库叫 coze-dev/coze-studio。一年零三个月,它攒到 21,808 星、3,134 个 fork(11 月 7 日查的),Apache-2.0,能整包搬回自己机器。另一组数字就不太好看了:11 个 release,最后一个 v0.5.1 停在 2026 年 2 月 5 日,代码最后一次提交是 7 月 29 日,到今天 101 天没动。这篇不吹不黑,讲清它是什么、装起来什么样、现在还该不该上。

它到底是什么

云上扣子在国内是给非程序员用的一站式 Agent 平台,官方口径服务了数万家企业、数百万开发者。Coze Studio 干的事很直接:把同一套引擎开放出来——一个浏览器里拖拽的 Studio,加一个能自己跑的服务器。

技术栈写得比大多数开源项目老实:后端 Golang,前端 React + TypeScript,整体微服务加领域驱动设计(DDD)。Agent 和工作流的运行时用字节自家的 Eino(CloudWeGo),画布用 FlowGram,HTTP 层是 Hertz,三个名字在 README 致谢里都能找到。整个仓库 392 个提交。

能建的东西和云上扣子一一对应:Agent、应用、工作流(拖节点连线)、插件、知识库、数据库、Prompt。发布出去有 OpenAPI 和 Chat SDK,够把 Agent 塞进自家客服后台或者内部系统。

装起来是什么样

官方只给一条路:Docker Compose。README 写的最低配置是 2 核 4G,但 compose 文件里躺着 11 个容器——MySQL 8.4、Redis 8、Elasticsearch 8.18、MinIO、etcd、Milvus 2.5.10、NSQ 三件套(nsqd / nsqlookupd / nsqadmin),再加 coze-server 和 coze-web。

步骤本身不复杂:clone 仓库,进 docker 目录,把 .env.example 复制成 .env,然后 docker compose up -d。第一次要拉 MySQL、ES、Milvus 这一串镜像,好几个 G,慢是正常的。

对外只有一个口子:coze-web 里的 Nginx 监听 8888,托管前端并把 /api 反代给 coze-server;coze-server 在宿主机上不映射任何端口,只在内网被调。

Coze Studio 自部署架构:coze-web 对外 8888,coze-server 经内网连 9 个基础设施容器
Coze Studio 的 11 个容器:只有 coze-web 映射 8888,coze-server 在 coze-network 内网里连 9 个基础设施容器(按官方 docker-compose.yml 绘制)

第一次启动有两件事躲不开:注册账号(默认开放注册),然后进 http://localhost:8888/admin/ 配模型。不配模型,建 Agent 时下拉框是空的。

模型这块比想象中全:火山方舟、BytePlus ModelArk、OpenAI、DeepSeek、Claude、Ollama、通义千问、Gemini,还有硅基流动和任何 OpenAI 兼容中转。方舟走 ark 协议,base_url 填 https://ark.cn-beijing.volces.com/api/v3/;Ollama 有个坑——compose 用的是 bridge 网络,localhost 指的是容器自己,得写宿主机 IP 或 host.docker.internal:11434,api_key 留空。

顺带一句内存:官方写 2 核 4G,但 ES、Milvus、MySQL 都是吃内存的主,4G 只够把容器拉起来,真跑工作流建议 8G 以上——这条是我的经验值,不是官方指标。

实话

一、发版节奏停了 9 个月。 11 个 release 里,头六周连发 8 个(0.2.1 到 0.3.0),2025 年 10 月发 0.5.0,2026 年 2 月 5 日发 0.5.1,然后没了。代码最后一次提交是 7 月 29 日的 #2723,一个 K8s statefulset 的 service 名对齐修复。仓库没归档,issue 还在收(最新一条 11 月 5 日),583 个未关闭的 issue 和 PR——社区还在用,官方不再往前推。

二、默认配置是给内网写的。 README 自己列了公网部署的风险清单:开放注册、工作流代码节点里跑 Python、Coze Server 监听地址、SSRF、以及 API 上的水平越权。0.5.1 的 release notes 里就有一条「fix: api horizontal privilege」。所以别裸奔:关注册、前面套一层带鉴权的反代、8888 只对内网开。

三、二次开发门槛比 Dify 高。 Dify 主体是 Python,改起来像改一个 Flask 项目;Coze Studio 是 Go 微服务 + DDD 分层 + React/TS 前端,加一个工作流节点要前后端一起动(wiki 第 10、11 篇专门讲这个)。团队里没人写 Go,就别指望深度定制。

四、它适合谁。 要「扣子同款画布」、要私有化、能接受自己维护一个 11 容器的栈——合适。要长期跟着升级、要活跃社区、要现成集成——去看 Dify 1.19 和 Langflow 1.13;画布这条路 Flowise 已经归档,别再往那边走。

结语

Coze Studio 的价值不在「免费」,而在于它把字节内部跑了几年的 Agent 生产工具摊开了:Go 微服务、Eino 运行时、FlowGram 画布,还有一套从 Agent 到插件的资源模型。代价是它现在是个停更的、默认不安全的重栈。当底座可以,当产品得自己接一层。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注