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

@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 基本满足了我们的需求了。我们的需求主要还是有交互的、智能体的这种噱头更重要哈哈哈哈。