本地部署 Coze 还是 n8n 还是 Dify？个人自用

[sxszzhrrt]

RT ，问以下各位大佬，个人用着玩，想要在自己的服务器上部署，是部署 Coze 还是 n8n 还是 Dify ？哪个功能强大且支持接入不同的模型？求一波推荐。谢谢

[sxszzhrrt]

求大神指导

[fishlium]

都支持，个人觉得 dify 方便一些，更新也快

[rockddd]

dify 呗

[gitnot]

个人觉得 n8n 好用， 轻量。

[BeautifulSoap]

n8n 自己部署非常简单。Dify 那部署需要的各种服务容器的数量我看得都头大，实在不想碰

[BeautifulSoap]

对 dify 部署涉及多少参数、要多少个容器没概念的，给你们点小小的震撼。相比之下 coze 都算可爱的了

https://github.com/langgenius/dify/blob/main/docker/docker-compose.yaml

[fishlium]

@BeautifulSoap 您好，可以问下 n8n 怎么对 ai 输出的结构化数据做解析然后给后续节点使用了，我用 n8n 使用起来遇到这种场景感觉很折腾，谢谢

[bsder]

请问你们都用 n8n 和 dify 干什么？ 感觉没有应用场景。

[BeautifulSoap]

@fishlium 要用到 AI Agent 这个类型的节点，拖进去后节点右下角是定义 outout parser 的，里面写 json 结构。然后解析结果会作为 input 传下一个节点。下一个节点通过 $json.output.字段名 的形式获取对应字段值

反正这种拖拽 work flow 处理这种都挺麻烦的

[BeautifulSoap]

@bsder 这种低代码的拖拽平台对会写代码的人来说没多少用。数据处理束手束脚，学习成本高，实现一个 workflow 往往没有直接写代码块。优点。。。可能就以 api 提供功能的时候方便点，用不着自己考虑 deploy 建服务器这些了

[PerFectTime]

不要碰 dify 就是了：
1. 每次升级的时候 docker compose 各种配置调整就够你喝一壶
2. 相关的服务容器太多了
3. 工作流的 api 稀烂，不按文档里面写的返回，经常返回预期之外的非标准 json 参数（ 1.0 前的刻板印象）曾经尝试维护一个 sdk ，发现压根没法维护
4. 工作流中调试不方便，入参出参类型不好调试

n8n 我用起来也不爽，它自带的那个智能体，在我配置了 deepseek 以后，依然还是请求 openai 的接口，看了下 issue ，这个问题上半年就有人提了，但没人修复

我建议使用 windmill ，你可以用 claude code 让他帮你写你所有需要的脚本，我用起来很爽

[sxszzhrrt]

@fishlium 功能上有哪个更好？

[sxszzhrrt]

@BeautifulSoap 功能上哪个更好呢？

[fishlium]

@BeautifulSoap 嗯嗯，谢谢，我使用感觉 n8n 比 dify 好像麻烦一点，不知道是不是自己使用得不对，我也是觉得没有写代码方便

[fishlium]

@sxszzhrrt 功能上我觉得 dify 好一点，dify 更新也频繁，但是 dify 部署重，另外更新频繁也会导致一些问题

[BeautifulSoap]

@fishlium dify 没碰过，要是谁看了我 6L 贴的部署 docker compose 还想用 dify 也是挺厉害的了。。。

[n1sv]

n8n 吧，配置很简单

[fishlium]

@BeautifulSoap 还好吧，反正 docker compose 启动，每次升级也是拉代码、备份、升级，从 1.0 之前的版本一直用到 1.10.0,也没出过很严重的问题

[visper]

第一次用 dify 的时候，感觉很顺手，什么配置怎样点开感觉很直观。不知道是不是比较全自己的理念。然后用 n8n 的时候，不知道是不是设计理念上的不同，想配置个大模型工作流跑起来感觉用得不顺手，不知道是不是没理解它的概念。dify 的镜像确实多。不过直接 docker compose 跑起来好像也没什么，升级基本就是拉镜像重启就行。硬盘占用不少，内存 cpu 这些占用不算大。

[Elliota]

复杂需求这些都没用