因为涉及到大预言模型，所以语言咱们还是选择python语言，而且python语言有很多可以调用的库，都是非常强大的工具，同时这些年随着python语言的迭代，这种语言多了越来越多方便的花式写法。语言模型还是选择Openai这里其实也可以用一些国产模型或者其他模型，但是有意思的是现在基本上所有模型都能兼容openai，什么意思，意思是如果你用了openai的基座，现在市面上所有的模型你都能直接拿来用

前面咱们写了很多的代码，但是代码本质上还是处于零散状态的学生脚本，这种东西和企业输出的工程师项目还是有很大差距的，今天咱们就开始把脚本一步步封装，暴露功能，RAG系统一点点开始有一点工程的味道。下面我们就一步步开始吧，第一步先创建一个RAG系统的类：有了类以后我们需要在类中封装一些核心的功能，包括存知识数据、相关知识检索以及提供可以完成询问功能的接口：有了这样一个类，咱们的系统再使用的时候只需要：

前面咱们做的系统使用的数据集是txt文件，这样做的目的是为了让系统暂时先跑通，今天咱们需要给系统再做一个升级，让系统真的可以阅读咱们平时可以看到的论文PDF文件。由于咱们搭建的是一个系统，目前只是测试一下系统能否跑通，保证功能可实现就好了，放两篇几页的小论文就好，千万不要放几十页的综述论文，文本数量太多了，需要消耗大量token，钱包扛不住的。紧接着，咱们需要安装一个可以解析PDF的库。

由于没有以往的对话记忆，那么系统就会胡言乱语，在上面的问题中，系统根本不知道its是什么，所以就引入到咱们今天的主题了，对话记忆功能。

咱们后面的功能将会迈进智能体，在这之前我感觉有必要对以前写的代码进行分层重构，这样当后面项目越来越大的时候，咱们维护代码的时候会很清晰。

基于LangGraph的开发与这类似，整个过程细节可调的地方非常多，所以做出来的东西比较专业，定制化也比较高。咱们前面的代码是通过手写Agent工作流程，实现了一个论文RAG问答系统，但是在实际生产环境中不会用这种纯手写工作逻辑项目，更多的是使用现有框架比如LangGraph和LangChain，LangChain是一种高级封装后的框架，更适合需要借助智能体完成固定任务的非专业用户，而LangGr

我在网上找到了一个关于编排层的解释案例，觉得能很好的帮助理解编排层的作用，从下面的案例可以看出来，让顾客去操作底层业务逻辑，比如指挥厨师1或厨师2完成某项工作是很不合适的，所以比较合理的方式是将上层请求与底层业务逻辑分开，加上编排层，那么系统分层后，日后维护（例如换厨师），那么就不需要修改大量的调用代码了。，这样系统能跑是没错，但是等于是FastAPI的上层请求，直接调用底层逻辑，系统没有分层的，

昨天的测试日志有暴露出问题：路由在选择工具和提取用户问题的时候回在半路就将用户的问题给回答了，所以今天要做的是给路由增加约束条件避免中途回答用户问题。通过上述一层在提示词上的约束，以及一层正则约束，路由系统不会再半路回答用户的问题。中增加两个小工具，这两个小工具一个负责给出更规范的。这三类，默认都把原始 query 继续传下去。字典，另一个负责给工具选择结果加强约束，如果是。

后面将会给现有的智能体做阶段的升级，完善系统功能，并修复漏洞。

其实经过Cursor的使用，我感觉系统的开发方式其实已经发生了系统性的改变，过去可能需要人来设计系统和纯手敲代码，但是今天的工作方式更多的应该是给ai写提示词，指挥ai工作，这可能才是未来工程师的工作，工程师与ai构成一个人机协同系统，完成项目的开发。接着Cursor遍开始按照前面制定的计划开始修改项目，每一个改动都可以在对话中被观测到，其实给我的最大感觉，这个Cursor和装了AI assist