Dify内心：Coze开源只是太监版本，我一点都不慌！

我是发现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要开源

有很多朋友都认为：Coze选择开源，也许是面临竞品压力，但我认为更多是想要构建一个完整的生态。

以另一个角度来说：国内C端本来Coze就一家独大，那么他要侵入的领域就更多是2B，那么之前是什么样的公司在用Dify呢，Dify对他们来说又是一个什么样的生态位？

因为我去年的AI+管理经验，也会用到Agent平台，这里能分享一批片面的数据：

浅度服务36家，深度服务15家客户，在我进入公司体系前，80%不知道什么是Coze，剩下的20%也只会很简单的用Coze，并且他们压根就不在乎数据安全，没有真实的私有化部署需求。

我们对这批数据简单做下划分：

一、50%的不明真相“群众”

以成都为例，很多电销的公司，内部都是用Excel飞来飞去，他们连在线表格都没玩明白，团队根本没有产研团队，而这种公司在国内巨多！

我甚至认为数据样例增多，比例会超过60%。

二、30%不痛不痒

然后就是0-50以上团队，他们有一定工程能力，但是多数业务场景不会使用Agent平台，少数使用也只是在做一些不痛不痒的业务，比如内部提效，只不过这些公司老板非常不重视内部降本增效。

他们连最常见的财务系统都没有，遑论Coze提效？

三、20%不屑于用

剩下的团队就是50+的产研团队了，他们研发实力较强，对于Agent平台这种低代码平台更多是个无所谓的态度，生产上基本不会用，内部提效是有可能的，但这个会进一步与办公软件相关，比如钉钉体系的公司绝不会选飞书的Coze。

开源->生态之争

综上，我觉得Coze开源更多是一场生态之争，不仅是与钉钉的生态，还包括了其背后的云服务生态。

这里分享个可能相关的案例：前几天腾讯云的哥们（中层干部）找到我，我以为他又要给我推坑爹的产品，却不曾他在忽悠我用火山引擎，一问才知道他去字节了...

同时，之前做文心的一些销售，最近联系下来居然也去了字节，工作是推广字节的AI产品！

最后，如果将视野在拉大，4月的时候字节推出了对标Manus的智能体扣子空间。

这种智能体的核心在于工具链，工具链的话暂时又可以具象化到各个MCP服务，从这个角度字节可能需要吸引足够的开发者进入生态才玩得起来！

要知道智能体是个大得多的赛道，Coze对于他似乎不值一提了

所以，开源Coze可能不是一个仓促的决定，如果其目标是要反哺上层的智能体应用的，那么对生态的要求就高了。

最后，再大胆猜测一下：Coze不开源，也赚不到钱！

Hi Agent

依旧是之前做AI+管理时候的事，有2家公司使用的是飞书的私有化Coze部署版本：Hi Agent。

但企业方反馈并不好，原因是跟线上的版本差距太大！

我私下咨询内部人员得到了一个信息是：Hi Agent与Coze是两个团队做的，可能销售蹭了Coze的热度，于是我进一步咨询了下这种SaaS私有化部署赚不赚钱，答案是否定的！

SaaS最大的敌人是定制化，定制化需要员工驻场开发，如果要做大就要维护一个庞大的实施团队，管理是一个问题，更大的是版本问题！

比如年初部署一个公司赚了500万，但年底企业如果要求升级，直接的结果就是这一年所有已经做好的应用可能全部要修改。

因为版本很难做到无痛升级，并且年初部署人员有可能离职了，新的同学根本不了解业务，实际执行下去就是一笔烂账，最后都是成本问题，总结下来：如果企业要赚钱那就要败口碑！

从这个角度来说，Dify的做法是对的：我是开源的，我又不赚你钱，那使用最新版本导致的问题就该你们公司自己消化。

大家能理解Dify，毕竟是白嫖，但大家不会理解字节，因为真的很贵...

基于此，如果本来也赚不到撒钱，那不如开源算了，只不过让下面同学（AITech实验室）实际部署测试了一波后发现：当前是阉割版本...

阉割Coze

大家部署比较简单，飞书产品文档一直很好，直接照着官方的来就行：

获取源码

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

• api_key 获取方式
• model 获取方式

修改拉取源

修改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是阉割版

这个可能比较重要，Coze开源版是阉割版。初步体验下来，主要缺少的是

1. 海量插件都不能用，只有18款内置插件，并且很多还需要授权；
2. 调试方面不支持回溯历史版本、不支持查看历史运行日志、不支持查看运行关系图；

然后对比Dify的话，开发体验方面要稍好，但生态方面其实并不占优势，甚至由于没有很好的支持MCP还有可能落下风(COZE内部是插件机制，有自己的一套规范)

简单来说：只是现在这个版本的话，真不足以让Dify慌，最后还是给一个案例，方便大家进一步了解...

简单案例

我们用智能体实现一个简单的天气查询功能：

具体步骤如下：

1. 用户问系统"上海天气如何？"
2. 系统加工后转发给模型

{
  "用户问题"："上海天气如何？",
  "可用工具列表": [{ 
      "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判断当前是什么状态，应该怎么处理，是否需要继续循环
1. Status=0 代表新请求
2. Status=1 代表需要调用外部服务
3. Status=2 代表外部服务请求完成
4. Status=3 代表调用结束
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办公了