Dify 工作流历史对话记忆 token 超限主要通过调整 LLM 节点中的“最大历史轮数”或启用“对话摘要”功能优化。适用场景为长对话导致上下文超出模型限制，风险边界是截断可能导致关键早期信息丢失。
先说结论：优先在 LLM 节点上下文设置中限制历史轮数，必要时引入摘要节点压缩信息。
- 先定位：确认当前 LLM 节点引用的上下文变量及 token 消耗。
- 先做：调整“最大历史轮数”或配置摘要策略。
- 再验证：通过调试模式观察实际传入模型的 token 数量。
快速处理思路
Dify 平台无命令行操作，需通过可视化编排界面调整配置。进入应用编排页面，找到负责生成回复的 LLM 节点，检查上下文设置中的历史记忆选项。若使用 Chatflow 模式，可在开始节点或全局设置中调整记忆轮数；若使用纯 Workflow 模式，需检查传入的历史消息变量数组长度。
为什么会这样
LLM 模型本身存在上下文窗口限制，超出限制会导致请求失败或报错。Dify 默认会尝试将所有历史消息拼接到提示词中，当累计 token 数超过模型上限或用户设定阈值时，必须截断或压缩历史数据。公开资料中没有看到可靠的量化数据说明具体截断算法对准确率的影响，但通常保留最近 N 轮是通用做法。
分步处理
第一步，区分应用类型。如果是聊天机器人，确认使用的是 Chatflow 而非纯 Workflow，因为 Chatflow 原生支持会话记忆管理。第二步，调整记忆轮数。在 LLM 节点的上下文设置中，找到“最大历史轮数”（Max History Turns），将其设置为模型上下文窗口允许范围内的数值。第三步，启用摘要策略。如果历史轮数限制导致信息丢失，增加一个 LLM 节点专门用于总结之前的对话内容，并将总结结果作为上下文传入主节点。
怎么验证是否生效
在 Dify 编排页面点击右上角“预览”或“调试”，输入超过设定轮数的对话内容。观察右侧运行日志中的“Token 消耗”或“上下文长度”指标，确认传入 Prompt 的 token 数量不再随对话轮数无限增长。检查模型返回是否报错，确保没有触发“context length exceeded”类错误。
常见坑
一是误将系统提示词计入历史记忆，导致可用空间减少，需确认系统指令与历史消息分开配置。二是摘要节点本身消耗额外 Token 和耗时，可能影响响应速度，需评估业务对延迟的容忍度。三是纯 Workflow 模式下没有自动记忆，必须手动通过变量传递历史消息数组，否则每次运行都是无状态请求。
常见问题
Dify 工作流和 Chatflow 在记忆处理上有什么区别？
Chatflow 原生支持会话级记忆自动管理，Workflow 通常需要手动传递变量。建议对话类应用优先选择 Chatflow 模式以减少编排复杂度。
调整最大历史轮数后需要重启服务吗？
不需要重启服务，保存编排配置后新产生的对话会立即生效，已存在的历史会话不受影响。
开启对话摘要会增加多少成本？
公开资料中没有看到可靠的量化数据，成本取决于摘要频率和所用模型单价，每次摘要都会产生额外的 Token 消耗。
参考来源
- Dify 官方文档 - Orchestrate a Chatflow - https://docs.dify.ai/guides/orchestrate-a-chatflow
- Dify 官方文档 - Context Management - https://docs.dify.ai/