字节跳动旗下AI Agent平台Coze近期选择开源，采用Apache-2.0协议，允许商业使用。此举旨在构建开发者生态，提升Agent能力。然而，开源版本（0.2）功能受限，插件数量锐减，本地部署存在授权和文档上传解析等问题。与Dify、N8N等竞品相比，Coze在开源协议上更开放，但功能尚需完善。其微服务架构和Go语言后端，对团队技术栈和人员配置提出了较高要求，目前更适合有高并发和测试资源的大型团队，或具备Go语言开发能力的企业。对于中小企业和AI科研团队，Dify仍是更易于接入和快速开发的选项。Coze的开源策略是其在Agent领域战略布局的关键一步，未来发展有待观察。

🌐 Coze 开源旨在构建开发者生态，提升AI Agent能力，采用Apache-2.0协议允许商业使用。开源后，其生态内的插件数量从上千个锐减至18个，且本地化部署用户发现大部分插件需要授权才能使用，限制了其即时能力。

📝 在知识库创建方面，开源的Coze版本目前仅支持本地文档上传，而不支持在线文档或公众号等数据源，并且存在本地解析问题，给开发者带来困境。GitHub上已有较多关于知识库向量化失败的求助issue。

🚀 Coze的开源是字节跳动在Agent搭建领域的战略布局，旨在吸引开发者共同建设标准Agent生态，以期获得更多商业化机会。与京东JoyAgent等竞品相比，Coze在开源协议上最为开放，但目前功能相对较少。

💻 Coze采用微服务架构和Go语言作为后端，这虽然带来了高性能和并发优势，但也对团队的技术栈和招聘成本提出了挑战。Go语言开发工程师相对稀缺，使得Coze更适合拥有高并发需求和相关技术资源的大型企业，而非普通中小企业或AI科研团队，后者可能更倾向于Dify的单体应用架构。

📊 在AI模型管理平台的竞争中，N8N的搜索指数已超过Dify，成为领先者。Coze若想吸引更多开发者，需考虑支持解绑火山引擎，允许接入腾讯云、阿里云等其他云服务，以满足更广泛的市场需求，并提升其在国内云服务厂商的竞争力。

就在上周，国内AI agent的第一平台coze选择开源了，开源了AI模型管理工具，并且选择了开源协议是Apache-2.0 ，允许商业使用。

前段时间我就写到，现在从底层的模型厂商PK，到现在的agentPK，其实大家都在卷的不是用户，还有就是AI上下游生态。

一个好的agent，就可以得到非常多的开发者支持，通过插件的形式让agent有更多的能力。

比如字节跳动的coze在没有开源之前，自己生态里有上千个插件，不仅是智能表格还是公众号文章数据获取，可以极大的方便提取知识库。在而开源后，因为本地授权限制，就导致了coze只有18个插件可以使用，从GitHub上看现在目前开源的版本是0.2，就得到以后势必还会继续更新。

有用户本地化部署了之后，得到了 coze的插件页面，可以看到几乎都需要授权，否则不能使用。

如下图是用户在选择知识库创建的时候，用户现在只能选择本地文档上传，而不支持其他在线文档、公众号等数据上传。

现在知识库文档上传文件后还存在本地解析的问题，也是开发者们所面临的困境，在 coze可以看到有相关的issue就是在关注这个问题的解决情况，并且有用户自发发帖在解决。

在GitHub上，有较多针对知识库向量化失败的求助

coze开源，也是为了开发者生态

相比阿里、腾讯，字节的开发者生态可能是做的最差的，因为大部分的系统都是闭源，同时又没有流量入口，自己的产品都是依靠推荐算法，几乎不像腾讯、阿里的产品会有社交场景与天然渠道入口，所以也就无法有吸引开发者的天然优势。

在开发者生态上，开源 coze也是字节在agent搭建的一个战略，相比前几天开源的京东joyagent，如何让开发者搭建agent的上下游，并且从而建设标准agent生态，这才能让 coze这个产品有更多商业化的机会。

有网友做了现在几个AI agent平台的竞品对比，可以看到相比DIFY以及N8N， coze在开源协议上最开放，但是现在的功能却较少。

本次开源了COZE的任务流与agent的底座，因为本身是微服务架构，所以 coze的开源也变成了类似的社交裂变的方式，通过逐步开放新的微服务单元功能模块，从而吸引更多开发者加入，并且随时缩放。

在AI模型管理平台的竞争下，Coze搜索指数排名在后

现在来看N8N的搜索指数超过了DIFY，成为agent工具三者最高的，而 coze要想获得更多开发者，就要支持解绑火山引擎，从而允许开发部署其他云服务，比如腾讯云、阿里云服务。

这也极大满足了市场的需求，毕竟火山引擎不是开发者唯一的归属，虽然现在价格比阿里云便宜不少。但是配套设施与服务阿里云仍然是国内云服务厂商第一梯队。

AI产品经理会用COZE吗

从现在开源的版本来看，COZE要想得到AI产品经理研发团队青睐还有一定距离，如下图是COZE的产品架构图，因为字节跳动的大厂技术架构，COZE选择了分布式架构服务，并且基于DDD架构设计，由2个平台组成，分别是AI BOT开放平台，一个是提供运营策略的平台。

Coze Studio：定位为“一站式 AI Bot 开发平台”，专注于提供可视化的、无代码/低代码的应用构建体验。它是一个面向最终用户的、用于生产 AI 应用的“工厂”。 Cozeloop：定位为“面向开发者的平台级解决方案”，专注于 AI Agent 的运营环节，覆盖从提示词开发、系统化评估到全链路观测（监控/追踪）的完整生命周期。

比如之前MANUS的创始人就提到，他们核心的工作不是做模型训练而是做提示词上下文工程，而上下提示工程就是COZEloop做的事情，不断去调试 、检测、追踪，从而得到最佳AIagent的用户体验。

微服务的好处就是可以介入部分功能模块使用，而不是要一整套使用对方系统，比如 例如，一个团队可以使用 Coze Studio 来构建应用，但将其对接到自有的观测系统中，而不是使用 Cozeloop。

所以，Coze适合有高并发、以及有测试资源的团队接入。

而Dify就更加适合AI科研团队与中小企业

如下是DIFY的产品架构图，基于单体应用架构设计，接入后就必须要整个系统数据流都介入，要进行二次改造和开发就会更加费时间。

在开发语言上，COZE采取的是GO语言作为后端，而DIFY采取的是后段，从团队研发人员配置来说，现在招聘人员的成本与难度，Java＜Python＜Go语言，选择GO语言，就注定了几乎很少有团队可以维护他。

因为高性能与并发，并不是每个企业都有资格去体验

同时科技企业为了考虑到自己应用的跨平台与兼容适配性，招聘Java就是最为主流的，最多再招聘几个Python人员来完成AI功能需求来建设。

所以现在COZE的开源，还只能是部分个人开发者使用，如果要有一定规模的开发者团队使用，那么现在的开放能力以及技术栈对团队都是挑战，反而DIFY更加合适中小企业。

较为大型的企业可能就会选择COZE，但是这对团队的人员研发资源要求提出了新的技术规范，毕竟我作为产品经理很少有见过那个团队会招聘GO语言开发工程师的。

最后做一个调研，你有和GO语言开发工程师协助过吗？

本文来自微信公众号“Kevin改变世界的点滴”（ID：Kevingbsjddd），作者：Kevin那些事儿，36氪经授权发布。