dify 好用吗，还是直接用 mcp 手撸更靠谱

两个不是一个东西

@ration 搭建 ai agent 的两种方法，用低代码和不用

手撸，dify 这东西根本没发直接上生产用，他只能编排完之后用它的平台运行，调用它的接口。
加上整个后端都是 python ，太重了，而且所有流畅只能在它自己的框架/ui 内设定，没法自己改代码的细节，如果是用代码写，就方便很多。
如果前期测试用用可能还行，但是后期要放到生产里的时候还是要自己重新用代码实现。
还有就是如果你用了话，后面有新模型新参数（比如 reason model 的 think 字段，vllm 都花了很长实现才支持），你还需要等它更新。

不能高可用部署，除非花钱

@pureGirl 一楼说的没错 不是一个东西。
MCP 只是一个调用标准协议。
而 dify 是完整的低代码开发平台。
实际去做 agent 的时候，你会发现 交互、切片、参数、解析、展示等等等，每一处都是非常复杂的。
包括 dify 本身也没有做到六边形。特别是在 RAG 部分，其实还是非常弱鸡，我们使用的时候基本上还是后端套一个 ragflow 来补充他的能力。
但毋庸置疑，dify 是体验、交互上最好的。甚至说 是最接近六边形的。
另外 其实还有一个非常好的方法，dify 做好之后，你可以在上层套一个 newapi 把做好的 agent 又变成一个 openai 兼容的接口 你就可以随便用了。

另外就是 其实不要迷信大语言模型以及 MCP ，有这功夫不如直接调用 API 实在。
大语言模型聊天交互，就是给什么都不会的人使用的。

@DefoliationM 但自己要去实现一整套 ai 应用编排的功能，也是相当大的成本啊，加上市场变化快，可能自己的产品还没出来，就又有概念新方向了。

dify 挺好用的，手撸完全没必要

@pureGirl 应该是类似 langchain 这一类框架手撸。一般应用 dify 还是挺好用的，手撸我觉得挺麻烦

如果你需要方便的可视化编排调试的话，用 dify 吧。很方便，占用资源也不多。如果你只是想做个特别的功能实现一点 ai 应用，直接手写调用 api 就行。现在 ai 时代叫它化你写代码都很快。

若依整了个架子，右侧窗口打开 dify 的对话，调整投喂文档格式版式这种工作花了 99%的时间，模型全部使用的是付费的 api ，公司内使用者说好，我也不知道是不是真的好

@8820670 #5
你好，上层套一个 newapi 变成一个 openai 兼容的接口，这个怎么做呢

@8820670 你就是典型的只知道定义理解不了精髓的人

换个角度 有些同事不会写代码的 我培训 1 小时后他就直接用 dify 搭建自己的助手了

dify 之前存在不少的问题,现在不知道怎么样了,但 dify 这种形式是非常好的,谁都可以去编排 AI 应用

dify 支持 mcp ，理论上 dify 应该能验证绝大多数 AI 的应用方案。并且小公司（没有啥大压力的调用场景）也可以直接用到生产环境，改起来不要太方便。后期怕出问题，再把 dify 当流程图自己写就是。

@zhoudaiyu 你用户名后面显示 pro ，花钱了吗？

可以了解一下 langchain ，我看过很多 low code 框架(dify maxkb)，都是 depend on langchain 的

@pureGirl mcp 意义不大，建议直接 API

@gibber 不用实现一整套，按照自己的业务流程来，llm 和向量数据库基本都有现在成的 sdk 能用，大部分时间依旧是写业务的代码，并不会在实现 sdk 上花费实现，模型也可以直接用 vllm 这种运行。而且就是因为市场变化快，自己的代码调整起来更方便，随时可以更新 sdk 改动，等第三方实现，他会不会跟进都是问题，到时候迁移成自己的代码又是成本。

@neutrino mcp 就是直接用 api

@csfreshman #17 小支持了一下 v2 doge

@ration #1 dify 是和 n8n 一个东西吗

MCP 是为了降低 LLM 到工具集成的 MxN 复杂度的数据交换协议。
Dify 和 n8n 类似，主要是 UI 化模型工作流的编排

@zhoudaiyu #22 好的，花钱哥

@pureGirl 但 API 不是 mcp

@VtoEXL NEW API 里边有一个 dify 的转发 你部署看一下就知道了 很简单 跟其他的转发一样的
https://github.com/QuantumNous/new-api

@pureGirl 一个 2K+人的公司 整个 AI 中台都是我负责的，并且对 DIFY 进行了深度二开，在理解上总比你还不知道 DIFY 好不好用深入吧。
单从你的表述来说，我说的没问题吧。
DIFY 跟 MCP 本来就不是一个可对比的东西。

@neutrino 调 API 就要写 mcp 啊又不能直接调用

@8820670 那你们会把 dify 和 mcp 结合在一起用了是吗

@pureGirl 首先 DIFY 在 1.0+版本后是支持 MCP 的。
然后 我们目前内部使用的 agent 并不使用 MCP ，原因有下：
1 系统作 MCP 改造需要少量成本及工作流。
2 我们作的智能体的作用都非常的明确，明确到说 我要作这么一件事情，那么我就去调用这个 API 即可，不需要 MCP 。最多加上意图识别、参数提取。 但是其实这种交互体验非常一般且浪费 token ，而且根本没有必要。
让内部使用为什么把他当成皇帝跟傻子让他用 MCP 。

@8820670 #27 看到了，谢谢，这块没注意，一直都是用 new api 做各种中转站的转发

dify 对应的的是 lang graph 手写代码做 workflow 。
dify 作为一个完整的 workflow 调度平台，做的事情还挺多的，包括 workflow execution 持久化，后台管理 UI ，运维什么的。
如果不需要管理执行记录，手撸没问题。
但是正常业务发展，应该是会持久化各种中间数据的，慢慢的会发展为 dify 这种类似的形态。

@8820670 我们的业务需求更复杂，必须用自然语言调用，没办法固定参数硬编码。

@pureGirl 其实复杂的 上到生产级别的 到底能不能交给大模型处理 其实这个可用程度还是存疑的
其实 dify 处理不了的 你手撸也一样没区别。
可能人家在工具意图识别上还可能优化的更加的准确。
先用 dify 试试呗 成本低。
反正最后都是一个聊天交互 人家做到还是可以的 top1 的

题主，既然是来问问题寻求帮助的，请先阅读，学会提问，这本好书。
你问的概念性问题，ai 就可以给你答案。
如果你想要寻求解决方案，就把你的需求脱敏后发出来。这样才能不浪费大家的时间和公共资源。
mcp 是标准协议。
dify 是 ai agent 概念的一个产品实现。

@yuxian 我不是来寻求帮助的，我是来讨论的，查缺补漏。别把自己太当回事，在论坛上你能帮出个啥？

@8820670 #5 和 n8n 比呢

@8820670 真实，是有落地过的

@summerLast 我们目前还没用 N8N 但是有大概了解。
N8N 老牌的工作流 新加了 LLM 节点。
个人理解上，其实对于标准的、重复的工作去结合 AI 做一些还是可以的。不过没真实部署使用，不敢确定。
目前 DIFY 基本满足了我们的需求了。我们的需求主要还是有交互的、智能体的这种噱头更重要哈哈哈哈。

@8820670 #40 我看 n8n 可以直接对外成 open ai 的接口，或 mcp

@8820670 #40 之前了解到的 n8n 可以直接对外成 open ai 的接口，或 mcp

dify 推荐自部署，托管小 bug 多（投入生产 2 个月）

珍爱生命，远离编排（包括 dify ）

社区版本，docker 启动一下试试看，我觉得好难用...

dify 我觉得还是差点意思，虽然现在没啥很好的选择。。。目前 dify 也是因为这么长时间以来各种需求逐渐把一些内容给抽象出来，套的 layer 已经很多了，然后有些时候碰到的问题就是有很多 hardcode ，要花费很大精力去 debug 。。。还有不少 workaround 的东西还得搭配着来，这还只是个人用，要是上了生产环境，捂脸。。。