用途：解决多轮对话中检索器只见当前问题、无法理解指代的问题。例如用户先问“Q3 收入多少”，再问“那和去年比呢”，直接检索“那和去年比呢”匹配不到内容，需先把问题改写为可独立理解的查询。
主要能力与流程：管线为“历史+当前问题→压缩 LLM 改写为独立问题→检索器→回答 LLM（历史、改写问题、文档）”。每轮两次 LLM 调用，改写用 Haiku 等轻量模型，合成用标准模型。配套能力包括：轮次分类（follow_up、new_query、chit_chat、meta）决定是否需要检索；历史压缩策略（全量记录、滑动窗口、摘要缓冲、向量记忆、分层摘要）；会话级向量记忆，recall 时用 session_id 过滤；消息历史存储（Redis 带 TTL、Postgres 便于查询审计、LangGraph PostgresSaver 检查点）；系统提示词缓存降低重复输入成本。
用法要点：改写提示词要求把最新消息重写为无需前文即可理解的独立问题，并解析代词与省略引用；改写时只保留最近约 8 轮历史以控制成本。轮次分类可用结构化输出实现，chit_chat 与 meta 无需检索。滑动窗口默认保留最近 N 轮；摘要缓冲在超过约 20 条消息后触发，将较早消息汇总为摘要并移除原文。LangChain 0.3+ 中 ConversationalRetrievalChain 已弃用，推荐 create_history_aware_retriever 配合 create_retrieval_chain。LlamaIndex 可用 CondensePlusContextChatEngine，模式包括 condense_plus_context、context、condense_question、react。存储方面，Redis 需设置 TTL；Postgres 用于需要查询历史的场景；智能体式流程可用 LangGraph 检查点。TypeScript 可用 Vercel AI SDK 的 streamText 与 convertToCoreMessages。
适用场景：需要连续追问的问答机器人、客服、数据分析对话、长期会话与回访用户等。
限制与反模式：不要在原始最新消息上直接检索；不要把完整历史当作检索查询字符串；避免无界历史、用 Sonnet/Opus 做改写、向量记忆缺少会话隔离、生产中仅用内存历史、闲聊也触发检索、不处理指代、永久保存含 PII 的历史、每轮原样转储检索上下文。生产需配置 TTL、删除权与逐轮追踪。资料未提供具体收费与平台信息。