后面我想将目前做的这个RAG智能体系统通过Django框架做成一个网站部署，但是在将这个系统上Django之前，还需要做一步会话级状态管理（Session-based chat state），这样做的原因在于：希望未来登录到系统的用户，他们之间的会话不会互相污染。咱们原来写到RAGSystem类中的那些会话操作，咱们现在都给拆出来放到了会话管理类中了，实现了解耦，这样咱们就可以用同一个RAGSys

总测试问题数：4重新排序回退计数：0 / 4重新排序解析成功次数：4次/4次LLM相关性门返回“否”：3/4LLM相关性门返回“是”：1/4被相关性门拦截的不相关问题案例：1/1。

总测试问题数：4重新排序回退计数：0 / 4重新排序解析成功次数：4次/4次LLM相关性门返回“否”：3/4LLM相关性门返回“是”：1/4被相关性门拦截的不相关问题案例：1/1。

昨天系统已经实现了基本的问答，不过这个问答功能咱们原来的智能体系统已经实现了该功能，同时通过Django壳层进行了展示，今天的目标是将问答结果向更产品化的方向去完善，今天咱们要做的功能有：记录历史有哪些会话、查看会话列表和查看某个会话的详情。简单来说，从级联外键的多端访问关连模型的“一”端称为正向访问，而从“一”端访问“多”端，那么就称为反向访问。Django将对数据库的操作都封装成了数据库模型，

为什么要做配置管理，咱们再代码中写死API KEY、BASE URL、DATA路径以及模型名字，刚开始代码肯定能跑，但是有可能在日后出现问题，因为系统有可能会遇到换模型、换平台、上传服务器部署以及上Django这种情况，如果遇到，代码量又比较大，那么就得一个个改，很麻烦，所以咱们做一个配置管理，以后想要换的话，只需要修改配置文件就可以了。前面的代码默认我们的每一步都成功，但是在做工程项目的时候，我

说到模版需要简单提一嘴Django的工作模式，Django属于MVT架构的web框架，M代表model他负责在后端定义数据模型，这种模型将来会涉及到数据库的操作，V代表view视图层，虽然说是视图层，但是我个人感觉view和咱们看到的网站页面没有半毛钱关系，在这里view当中，我们主要写业务逻辑，逻辑写好后相关的的返回结果会传递给模版Template层，模版才是咱们最终能看到的页面。文件，将访问请

调整后的检索上下文比最早的版本文段更长，基于检索到的信息可以帮助用户回忆以往的研究内容，同时这样的内容让用户看到后能感觉心里放心，知道模型回答的结果是有依据的。但是这些信息还需要在Django中的页面中反馈给用户才可以，这样用户能清楚的知道系统是如果工作的，以及判断给出的问答结果是否可靠。经过调整后，页面有了更为完整的 Agent Trace 信息，这样用户可以判断智能体的工作是否可靠。需要修改的

前面已经将FastAPI封装的AI能力接入Django形成了一个比较基本的用户UI界面，但是这个用户界面就好像毛坯房，所以这篇博客的主要工作是对“毛坯房”进行简装，过程中将会优化页面的UI增加会话列表增加文档上传和数据库重建功能以及增加系统的可解释性。

图7 最终的ChatflowDify 在 AI 应用开发里的位置是什么它和手写智能体项目的区别是什么哪些问题适合靠平台快速验证哪些问题最终还是得靠自己手写逻辑去解决AI 应用平台能帮你把流程搭得很快，但真正决定效果上限的，仍然是知识源、检索、上下文和工作流设计。这也是为什么，这次补 Dify 对我来说不是在“换路线”，而是在补齐自己对智能体开发这条路的理解。

总体来看，通过这次升级我感觉 FAISS 知识向量数据库更像是一种内存级的知识向量数据库，Milvus 像是更像是一种存在文件系统里面的数据库，可能用传统数据库打比方，FAISS 更像是 Redis ，Milvus像是Mysql。当前的 Paper-RAG-Agent-with-LangGraph 系统使用的 FAISS 知识向量数据库，但是和落地场景下的实际项目还有差距，这次升级主要目的是把这个