1、最简单的一种会话管理
对于比较简单的agent开发，如果只是一次响应，上下文要求不高，可以将用户输入的多类型文件进行拆解和转化，注入大模型上下文。一次请求，一次响应，一次分析结果。
2、复杂的会话管理基本思路
对于较复杂，需要进行上下文管理的时候，用户不断上传的资料。我这里的策略是先统一收集这些文件到某个项目文件夹下。在大模型真正思考，需要使用到相关资料的时候才会尝试去读取这些文件中的相关信息。就类似使用claude code这样的工具，针对某个项目文件夹下的文件，是按需、使用时候采取读取的。
这里的开发思路有：
①渐进式披露。用户不断上传、补充待分析的资料。这些资料可能需要二次处理，不能直接注入上下文，只在需要使用的时候才会进行读取。
②工具即能力边界。agent能做什么完全由工具集决定。每一轮对话，不是依靠prompt注入告诉模型相关信息，而是依靠模型自主的使用工具，查询已有的资料获得信息。模型自主的拼接上下文，而非用户写好上下文。
这意味可能需要维持一个文件索引表，这个索引表是需要随时注入大模型的，索引表需要不断更新和维护，让大模型知道当前能够使用的信息有哪一些。
3、对于回话过程中的每次API请求，claude code采用的是这样的策略
图示表达的含义是：完整的上下文一次api请求的操作。
最后的AutoCompact一般是通过阈值实现的，也就是已经使用的上下文达到了模型对话窗口上下文的多少，会强制触发自动压缩功能。而在这之前，针对已有的上下文也会进行很多处理，这是我们经常使用claude code这类agent平时感知不到的。
claude code中使用的还是一些本地操作实现轻量压缩，具体的每个策略都是很值得研究的。这也是一个节约成本的策略，AutoCompact是调用大模型进行上下文压缩，所以会有token消耗。
AutoCompact是一次摧毁细粒度上下文的压缩，只提取、总结核心内容，这么做之后会丢弃很多的信息。所以在AutoCompact之前，这些低成本的压缩是更值得做的，这些低成本的操作是的上下文没有达到阈值，那么也就不会进行AutoCompact操作。
4、针对本人开发项目的使用场景
我的项目的一个特点是：用户需要不断的上传相关文件（图片、txt、log等等文件），AI需要综合这些文件信息来进行分析。除此以外，由于.txt文件可能非常的长，用户可能需要不断的补充信息，比如指出某份.txt文件的某个段落是关键信息。所以在我的开发项目中，需要实现针对已有资料的编辑/注释功能，来辅助AI分析。这一块也涉及到上下文该如何处理的问题。