Coze开源48小时即冲6k星，却被Dify嘲讽“阉割版”：插件只剩18个、日志调试全砍、私有化难赚钱。本文深扒字节真实意图——醉翁之意不在Agent，而在生态位与智能体棋局；也提醒2B市场：别被Stars冲昏头，生态完整度才是护城河。
我是发现DeepSeek和Manus开了一个很不好的头，所以在前天晚上，7.25凌晨，Coze开源了！一时间AI圈又热闹起来了，他们总是这样整活，我都麻了…
Coze是字节旗下一款Agent开发平台（低代码/零代码平台），他们非常适合简单的个人助手类AI应用，之前我们对常见的几个Agent平台做过对比：
其实，现阶段正儿八经分庭抗礼的要数Coze和Dify，原因很简单：他们的生态最好，并且从迭代节奏来说，都后劲十足！
Coze得益于飞书体系的加持以及本身产品体验过硬，牢牢占据着2C的市场；而Dify由于其开源的生态位，在2B私有化部署这块一直占据第一的身位。
当前Dify破10万Stars，Coze Studio刚开源2天Stars近6千。Coze（之前闭源版本）插件巨多（貌似3000多）；Dify这块要差点，但常见插件几乎都能找到。
如果Coze将插件生态一并移植过来，对Dify威胁很大。
所以，难道Coze开源的目的就是为了与Dify争夺市场？
有很多朋友都认为：Coze选择开源，也许是面临竞品压力，但我认为更多是想要构建一个完整的生态。
以另一个角度来说：国内C端本来Coze就一家独大，那么他要侵入的领域就更多是2B，那么之前是什么样的公司在用Dify呢，Dify对他们来说又是一个什么样的生态位？
因为我去年的AI+管理经验，也会用到Agent平台，这里能分享一批片面的数据：
浅度服务36家，深度服务15家客户，在我进入公司体系前，80%不知道什么是Coze，剩下的20%也只会很简单的用Coze，并且他们压根就不在乎数据安全，没有真实的私有化部署需求。
我们对这批数据简单做下划分：
1）50%的不明真相“群众”
以成都为例，很多电销的公司，内部都是用Excel飞来飞去，他们连在线表格都没玩明白，团队根本没有产研团队，而这种公司在国内巨多！
我甚至认为数据样例增多，比例会超过60%。
2）30%不痛不痒
然后就是0-50以上团队，他们有一定工程能力，但是多数业务场景不会使用Agent平台，少数使用也只是在做一些不痛不痒的业务，比如内部提效，只不过这些公司老板非常不重视内部降本增效。
他们连最常见的财务系统都没有，遑论Coze提效？
3）20%不屑于用
剩下的团队就是50+的产研团队了，他们研发实力较强，对于Agent平台这种低代码平台更多是个无所谓的态度，生产上基本不会用，内部提效是有可能的，但这个会进一步与办公软件相关，比如钉钉体系的公司绝不会选飞书的Coze。
综上，我觉得Coze开源更多是一场生态之争，不仅是与钉钉的生态，还包括了其背后的云服务生态。
这里分享个可能相关的案例：前几天腾讯云的哥们（中层干部）找到我，我以为他又要给我推坑爹的产品，却不曾他在忽悠我用火山引擎，一问才知道他去字节了…
同时，之前做文心的一些销售，最近联系下来居然也去了字节，工作是推广字节的AI产品！
最后，如果将视野在拉大，4月的时候字节推出了对标Manus的智能体扣子空间。
这种智能体的核心在于工具链，工具链的话暂时又可以具象化到各个MCP服务，从这个角度字节可能需要吸引足够的开发者进入生态才玩得起来！
要知道智能体是个大得多的赛道，Coze对于他似乎不值一提了
所以，开源Coze可能不是一个仓促的决定，如果其目标是要反哺上层的智能体应用的，那么对生态的要求就高了。
最后，再大胆猜测一下：Coze不开源，也赚不到钱！
依旧是之前做AI+管理时候的事，有2家公司使用的是飞书的私有化Coze部署版本：Hi Agent。
但企业方反馈并不好，原因是跟线上的版本差距太大！
我私下咨询内部人员得到了一个信息是：Hi Agent与Coze是两个团队做的，可能销售蹭了Coze的热度，于是我进一步咨询了下这种SaaS私有化部署赚不赚钱，答案是否定的！
SaaS最大的敌人是定制化，定制化需要员工驻场开发，如果要做大就要维护一个庞大的实施团队，管理是一个问题，更大的是版本问题！
比如年初部署一个公司赚了500万，但年底企业如果要求升级，直接的结果就是这一年所有已经做好的应用可能全部要修改。
因为版本很难做到无痛升级，并且年初部署人员有可能离职了，新的同学根本不了解业务，实际执行下去就是一笔烂账，最后都是成本问题，总结下来：如果企业要赚钱那就要败口碑！
从这个角度来说，Dify的做法是对的：我是开源的，我又不赚你钱，那使用最新版本导致的问题就该你们公司自己消化。
大家能理解Dify，毕竟是白嫖，但大家不会理解字节，因为真的很贵…
基于此，如果本来也赚不到撒钱，那不如开源算了，只不过让下面同学（AITech实验室）实际部署测试了一波后发现：当前是阉割版本…
大家部署比较简单，飞书产品文档一直很好，直接照着官方的来就行：
获取源码
git clone https://github.com/coze-dev/coze-studio.git
配置模型
cd coze-studio
# 复制模型配置模版
cp backend/conf/model/template/model_template_ark_doubao-seed-1.6.yaml backend/conf/model/ark_doubao-seed-1.6.yaml
#编辑文件
vim backend/conf/model/ark_doubao-seed-1.6.yaml
这里要修改配置：
1）id 全局唯一，每个模型都要不一样
2）meta.conn_config
修改拉取源
修改Docker镜像地址为国内源：
vim /etc/docker/daemon.json
# 修改为如下内容
{
“registry-mirrors”: [
“http://hub-mirror.c.163.com”,
“https://docker.mirrors.ustc.edu.cn”,
“https://registry.docker-cn.com”
]
}
部署并启动服务
cd docker
cp .env.example .env
docker compose –profile “*” up -d
接下来就可以体验了，这里先说结论：
这个可能比较重要，Coze开源版是阉割版。
初步体验下来，主要缺少的是海量插件都不能用，只有18款内置插件，并且很多还需要授权；调试方面不支持回溯历史版本、不支持查看历史运行日志、不支持查看运行关系图；
然后对比Dify的话，开发体验方面要稍好，但生态方面其实并不占优势，甚至由于没有很好的支持MCP还有可能落下风(COZE内部是插件机制，有自己的一套规范)
简单来说：只是现在这个版本的话，真不足以让Dify慌，最后还是给一个案例，方便大家进一步了解…
我们用智能体实现一个简单的天气查询功能：
具体步骤如下：
用户问系统”上海天气如何？”
系统加工后转发给模型
{
“用户问题”：”上海天气如何？”,
“可用工具列表”: [{
“tool_name”: “weather”,
“tool_desc”:”查询某地的天气”,
“tool_params”:[{
“param_name”: “location”,
“param_desc”: “城市名称，如：上海”,
“param_type”: “String”
}]
}]
}
大模型收到后回复：
{
“tool_name”: “weather”,
“tool_params”: “location=上海”
}
系统根据大模型的指令实际调用服务：
https://your_service.com/api/weather?location=上海
系统把外部服务查询结果给大模型：
{
“用户问题”:”上海天气怎么样？”
“Weather查询结果”: {
“location”: “上海”,
“weather”: “多云，25度”
}
}
大模型根据数据回答问题并返回：
上海今天多云，25度，温度很舒服，适合户外运动
工作流核心思路比较简单：
1）外层需要包装一个循环，通过Status判断当前是什么状态，应该怎么处理，是否需要继续循环
2）每个步骤完成后，需要手动修改Status的值，让循环进行下一个步骤。
3）循环过程中的临时数据，需要存储在”循环变量”中，方便下次调用
最后，将提示词给想要偷懒的同学…
# 角色
任务处理大师
# 任务
1. 根据用户输入解决用户问题
2. 如果你判断解决问题需要使用工具，请返回调用工具的信息
3. 如果你判断不需要调用工具，则根据输出示例直接返回答案
4. 不要额外输出其他内容，也不要格式化输出
5. 如果缺少必要的参数信息，则根据输出示例提示用户补充
# 可使用的工具列表
[{
“url”: “http://youer_service.com/api/weather”,
“tool_name”: “weather”,
“tool_desc”:”查询某地的天气”,
“tool_params”:[{
“param_name”: “location”,
“param_desc”: “城市名称，如：上海”,
“param_type”: “String”
}]
}]
如果我们只站在Agent平台的角度思考问题，为什么他会存在？其实原因无非一点：给不想/不会写代码的人用！
在几年前有个很冷的笑话，老板让下面有2年没写代码的总监去开发一个东西，2天后老板在群里问搞得怎么样了？
该总监回了一句：有日子没写代码了，昨天搞了一天的环境，现在正在做？
老板这里就很疑惑了，打趣道：搞什么环境，要香薰的吗？
这让那个总监很烦躁，你别说他很烦躁，你突然让我写代码，想起那个环境问题，我也很烦躁…
而Agent平台这种低代码平台，在解决环境烦躁这点是很优秀的，只不过最近Cursor、Trae等AI编程助手貌似也能解决这类问题了。
所以，逻辑上来说，低代码平台的生存空间会被AI压缩，Coze与Dify也不例外。所以，低代码平台的优劣，比较重要的还是得看其插件生态，这个短时间AI够不着。
而从插件生态再看这次的开源版本，Coze根本不是Dify的对手；另一方面，Dify正在和一些公司洽谈进一步的融资，这场战役还有的玩。
所以，Coze想要更进一步，是需要进一步开源的，毕竟现在N8N有水土不服、Dify身上还有一些商业限制，这些都是机会…
最后，其实之前也说了：就我的实际经历，各个团队重要系统都不会用Agent平台，不论是Coze还是Dify天花板挺低的，特别是AICoding已经足够提效了…
综上，这波Coze开源的意义依旧是字节办公体系生态位的事，其实对各个公司可能没什么影响，只不过Dify团队的背后貌似跟腾讯渊源颇深，不知道腾讯这个玩家是不是真的想完全错过这次AI办公了？
本文由人人都是产品经理作者【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。