linux.do

dify 使用小指南

在大家的印象里可能类似dify、fastgpt、n8n这种拖拽式的workflow工作平台是低代码的，大部分操作节点其实挺直白，不过我个人用起来其实更像是一个框架而已，虽然说是低代码，但没有代码思维写起来会很烂很烦。
特此开个贴来记录一下我在工作中使用dify一点点经验。而且dify的迭代和循环不能放在一起，有时候还真有点麻烦。

本地部署

本地部署如果是在大陆的机器，我是非常建议用qwen和doubao的，因为这两家首字速度非常非常快，而且无论账户多少钱都有高并发，模型在日常使用例如客服、视觉上都是够用的。（不够用就并行多几个qwen plus来验证，反正便宜）。

如果是香港的机子访问qwen和doubao慢了一点点但感觉还是很快的，而且这里可以解锁openrouter中的vertex中的gemini（速度很快不过不知道为什么会出现速率限制，明明是收费的），但依旧用不了claude和openai

如果是其他地方的机器，qwen和doubao的访问速度就会明显下降，如果选择使用百炼国际节点来使用qwen，我只能说非常贵，大概是国内的3倍，不如直接用gemini 3 flash解决一切，我试了我的场景（客服和教育），claude不好用；openai大杯模型都不错（贵），mini那些不行。

并发量

如果是本地部署，在我的使用场景里很容易碰到迭代并发量不够的导致执行这个节点速度很慢，默认是10，所以需要去env设置一个参数（不记得什么参数了，把env文件喂给ai问问就行）

变量合聚合器

变量聚合器这个节点可以把相同类型的变量聚合在一起，这个节点可以节省很多功夫，例如客人想咨询还是购买，我设置了不同的回复，但后续节点是一致的，就可以把不同的回复聚合在一起，不用写两个甚至更多一模一样的后续流程。

环境变量

环境变量在chatflow和workflow都很好用，因为可以定义一个公共的变量，无论是很重复的prompt或者定义一个标记变量都可以用这个，例如设置了一个prompt是定义所有llm的角色，或者所有llm都需要遵循的规则，如果后续有变动可以直接改变量而不是一个个改（烦死）。

自定义分流

我觉得dify自带的问题分类器不好用，不如写一个llm节点来执行执行分流，例如客人是想咨询还是购买。

json schema（非常重要）

llm节点里面有一个结构化输出，也就是json schema，这个可以卸载llm的参数设置里（gemini、openai等插件），也可以写在这里。主要功能是限制llm输出json格式且对应字段，在很多情况非常好用。现在的模型基本上都有这个功能，最近的模型只有doubao seed 1.6有时候不太遵守。

自定义记忆

在某些场景下，我们需要对用户输入进行分流或信息提取。此时，不应使用 LLM 节点自带的记忆功能。

原因在于：我们通常会在 system prompt 中明确定义分流规则，例如“情况1输出A，请求2输出B”，并要求模型仅输出 A 或 B。然而，如果启用了记忆功能，LLM 会将此前多轮 user/assistant 的对话历史一并带入当前请求。这相当于在补全上下文，但其中混杂了大量与当前任务无关的对话内容，会严重干扰 system prompt 中设定的严格输出规则。

举个例子：

● 上一个节点是通用对话 LLM，用户说“你好”，LLM 回复：“你好，我是AI客服，有什么可以帮到您？”
● 下一个节点切换为分流 LLM，其 system prompt 要求只输出 A 或 B。
● 但如果启用了记忆功能，上述对话历史（包括 assistant 的回复）会被作为上下文传入分流 LLM。
● 结果，分流 LLM 可能受历史回复影响，不再严格遵守“仅输出 A 或 B”的指令，导致行为偏离预期。

因此，我个人的做法是：通过插件或自定义 workflow，将整个对话历史收集并整合为一条完整的 user 输入，再一次性发送给 LLM。这样既能保留必要上下文，又避免了多轮对话中 assistant 回复对分流逻辑的干扰，确保 system prompt 的规则被准确执行。

就先记到这里吧，之后我遇到了什么问题再补充，也欢迎大家给出自己的经验。

5 posts - 3 participants

Read full topic

via LINUX DO - 最新话题 (author: 爱吃桃子的土狗一号)

Invalid media:
image
image
image
image

14 views05:02