 |
1
ration 23 天前 via Android
两个不是一个东西
|
 |
3
DefoliationM 23 天前
手撸，dify 这东西根本没发直接上生产用，他只能编排完之后用它的平台运行，调用它的接口。
加上整个后端都是 python ，太重了，而且所有流畅只能在它自己的框架/ui 内设定，没法自己改代码的细节，如果是用代码写，就方便很多。 如果前期测试用用可能还行，但是后期要放到生产里的时候还是要自己重新用代码实现。 还有就是如果你用了话，后面有新模型新参数（比如 reason model 的 think 字段，vllm 都花了很长实现才支持），你还需要等它更新。 |
 |
4
zhoudaiyu PRO 不能高可用部署，除非花钱
|
 |
5
8820670 22 天前  5
@pureGirl 一楼说的没错 不是一个东西。
MCP 只是一个调用标准协议。 而 dify 是完整的低代码开发平台。 实际去做 agent 的时候，你会发现 交互、切片、参数、解析、展示等等等，每一处都是非常复杂的。 包括 dify 本身也没有做到六边形。特别是在 RAG 部分，其实还是非常弱鸡，我们使用的时候基本上还是后端套一个 ragflow 来补充他的能力。 但毋庸置疑，dify 是体验、交互上最好的。甚至说 是最接近六边形的。 另外 其实还有一个非常好的方法，dify 做好之后，你可以在上层套一个 newapi 把做好的 agent 又变成一个 openai 兼容的接口 你就可以随便用了。 |
|
6
8820670 22 天前 1
另外就是 其实不要迷信大语言模型以及 MCP ，有这功夫不如直接调用 API 实在。
大语言模型聊天交互，就是给什么都不会的人使用的。 |
 |
7
gibber 22 天前
@DefoliationM 但自己要去实现一整套 ai 应用编排的功能，也是相当大的成本啊，加上市场变化快，可能自己的产品还没出来，就又有概念新方向了。
|
 |
8
burnsby 22 天前
dify 挺好用的，手撸完全没必要
|
 |
10
visper 22 天前
如果你需要方便的可视化编排调试的话，用 dify 吧。很方便，占用资源也不多。如果你只是想做个特别的功能实现一点 ai 应用，直接手写调用 api 就行。现在 ai 时代叫它化你写代码都很快。
|
 |
11
alienx717 22 天前
若依整了个架子，右侧窗口打开 dify 的对话，调整投喂文档格式版式这种工作花了 99%的时间，模型全部使用的是付费的 api ，公司内使用者说好，我也不知道是不是真的好
|
 |
14
Mzs 22 天前
换个角度 有些同事不会写代码的 我培训 1 小时后他就直接用 dify 搭建自己的助手了
|
 |
15
unco020511 22 天前
dify 之前存在不少的问题,现在不知道怎么样了,但 dify 这种形式是非常好的,谁都可以去编排 AI 应用
|
 |
16
kuonkuon 22 天前
dify 支持 mcp ，理论上 dify 应该能验证绝大多数 AI 的应用方案。并且小公司（没有啥大压力的调用场景）也可以直接用到生产环境，改起来不要太方便。后期怕出问题，再把 dify 当流程图自己写就是。
|
 |
17
csfreshman 22 天前
@zhoudaiyu 你用户名后面显示 pro ，花钱了吗？
|
 |
18
johnnyyeen 22 天前
可以了解一下 langchain ，我看过很多 low code 框架(dify maxkb)，都是 depend on langchain 的
|
|
20
DefoliationM 22 天前 via Android
@gibber 不用实现一整套，按照自己的业务流程来，llm 和向量数据库基本都有现在成的 sdk 能用，大部分时间依旧是写业务的代码，并不会在实现 sdk 上花费实现，模型也可以直接用 vllm 这种运行。而且就是因为市场变化快，自己的代码调整起来更方便，随时可以更新 sdk 改动，等第三方实现，他会不会跟进都是问题，到时候迁移成自己的代码又是成本。
|
|
22
zhoudaiyu PRO @csfreshman #17 小支持了一下 v2 doge
|
 |
24
razertory 22 天前 1
MCP 是为了降低 LLM 到工具集成的 MxN 复杂度的数据交换协议。
Dify 和 n8n 类似，主要是 UI 化模型工作流的编排 |
|
25
csfreshman 22 天前
@zhoudaiyu #22 好的，花钱哥
 |
|
27
8820670 22 天前
|
|
28
8820670 22 天前
@pureGirl 一个 2K+人的公司 整个 AI 中台都是我负责的，并且对 DIFY 进行了深度二开，在理解上总比你还不知道 DIFY 好不好用深入吧。
单从你的表述来说，我说的没问题吧。 DIFY 跟 MCP 本来就不是一个可对比的东西。 |
|
31
8820670 22 天前
@pureGirl 首先 DIFY 在 1.0+版本后是支持 MCP 的。
然后 我们目前内部使用的 agent 并不使用 MCP ，原因有下： 1 系统作 MCP 改造需要少量成本及工作流。 2 我们作的智能体的作用都非常的明确，明确到说 我要作这么一件事情，那么我就去调用这个 API 即可，不需要 MCP 。最多加上意图识别、参数提取。 但是其实这种交互体验非常一般且浪费 token ，而且根本没有必要。 让内部使用为什么把他当成皇帝跟傻子让他用 MCP 。 |
 |
33
ZSeptember 22 天前
dify 对应的的是 lang graph 手写代码做 workflow 。
dify 作为一个完整的 workflow 调度平台，做的事情还挺多的，包括 workflow execution 持久化，后台管理 UI ，运维什么的。 如果不需要管理执行记录，手撸没问题。 但是正常业务发展，应该是会持久化各种中间数据的，慢慢的会发展为 dify 这种类似的形态。 |
|
35
8820670 22 天前
@pureGirl 其实复杂的 上到生产级别的 到底能不能交给大模型处理 其实这个可用程度还是存疑的🤔
其实 dify 处理不了的 你手撸也一样没区别。 可能人家在工具意图识别上还可能优化的更加的准确。 先用 dify 试试呗 成本低。 反正最后都是一个聊天交互 人家做到还是可以的 top1 的 |
 |
36
yuxian 21 天前
题主，既然是来问问题寻求帮助的，请先阅读，学会提问，这本好书。
你问的概念性问题，ai 就可以给你答案。 如果你想要寻求解决方案，就把你的需求脱敏后发出来。这样才能不浪费大家的时间和公共资源。 mcp 是标准协议。 dify 是 ai agent 概念的一个产品实现。 |
 |
38
summerLast 21 天前
@8820670 #5 和 n8n 比呢
|
|
40
8820670 21 天前
@summerLast 我们目前还没用 N8N 但是有大概了解。
N8N 老牌的工作流 新加了 LLM 节点。 个人理解上，其实对于标准的、重复的工作去结合 AI 做一些还是可以的。不过没真实部署使用，不敢确定。 目前 DIFY 基本满足了我们的需求了。我们的需求主要还是有交互的、智能体的这种噱头更重要哈哈哈哈。 |
|
41
summerLast 21 天前
@8820670 #40 我看 n8n 可以直接对外成 open ai 的接口，或 mcp
|
|
42
summerLast 21 天前
@8820670 #40 之前了解到的 n8n 可以直接对外成 open ai 的接口，或 mcp
|
 |
43
liu731 21 天前
dify 推荐自部署，托管小 bug 多（投入生产 2 个月）
|
 |
44
captain55 21 天前
珍爱生命，远离编排（包括 dify ）
|
 |
45
mmdsun 21 天前 via iPhone
社区版本，docker 启动一下试试看，我觉得好难用...
|
Select Language