当前位置：首页 > news >正文

解决大模型长对话致命悖论：滚动摘要架构让你的Agent永不卡顿，建议程序员收藏学习！

news 2026/8/4 22:26:58

随着对话进行，messages会不断累积，很快就超出大语言模型（LLM）的上下文限制。

在不依赖外部存储（如数据库）的前提下，我尝试用一个总结节点（summarizer node）来压缩上下文。然而，这引出了一个致命的悖论。

致命悖论：用“长上下文”解决“长上下文问题”

你可能遇到过 Agent 聊着聊着就“卡住”的情况，比如打印---SUMMARIZER---后没反应。这源于一个根本性错误：我们让一个“摘要员”去解决对话太长的问题，但它自己却先被“太长”的对话累垮了。

举个例子：即使我们设定 LangGraph 每 5 轮对话总结一次，或当 Token 长度超过 1500 时总结。但问题依然存在：

卡在阈值：假设当前 1490 Token，新消息进来变 1510。此时触发总结，summarizer依然要处理这超长的 1510 Token，极易超时或卡死。
累积盲区：在总结触发前（比如第 1-4 轮），消息仍在累积。如果某轮出现超长内容，Agent 依然会“爆掉”。

简言之，当对话过长，系统把全部的、超长的对话历史（比如 6000+ Token）交给summarizer，summarizer再把它塞给 LLM。LLM 处理巨大请求耗时过久，导致请求“卡住”。

本质是：我们试图用一个本身需要大量上下文的 LLM 调用，去解决上下文过长的问题。这在逻辑上是行不不通的。

破局之道：引入“滚动摘要（Rolling Summary）”架构

要彻底解决这个问题，我们需要升级 Agent 的记忆管理：引入滚动摘要机制。

核心思想：Agent 的任何部分，永远不处理完整的、超长的原始对话历史。我们只关注增量信息。就像你不断更新的笔记，每次只记录最新内容，并定期将旧的零散笔记整理成一个精炼的总结。

如何实现“滚动摘要”？——技术细节与伪代码

1. 升级 Agent 的“状态蓝图”（AgentState）

将 Agent 的对话状态拆分为两部分：

•summary: 迄今为止所有对话的精炼总结。
•messages: 自上次总结以来，最新的几条消息。

伪代码：

class AgentState { summary: string; // 滚动摘要 messages: Array<string>; // 最新消息列表 // ... 其他状态 }

2. 重构“摘要员”（Summarizer）的逻辑

summarizer不再处理全部历史，只接收旧摘要和最新消息。它的任务是：合并两者，生成新的、更新后的摘要。完成后，清空messages数组。

伪代码：

function summarize(state: AgentState): AgentState { // 准备LLM输入：旧摘要 + 最新消息 prompt = build_summarizer_prompt(state.summary, state.messages); // 调用LLM，获取新摘要和更新的记忆 llm_response = LLM_CALL(prompt); new_summary, updated_memory = parse_llm_response(llm_response); // 更新状态： return { summary: new_summary, memory: update_memory(state.memory, updated_memory), messages: [] // 清空最新消息 }; }

3. 升级“协调器”（Orchestrator）的提示词

orchestrator（Agent 的“大脑”）的决策依据不再是超长原始对话，而是：

•summary: 历史背景和长期记忆。
•messages: 用户最新的输入。

这样，orchestrator总是能基于精炼、关键的信息做出判断。

伪代码：

function orchestrate(state: AgentState): Action { // 构造LLM决策提示：基于总结和最新消息 decision_prompt = build_orchestrator_prompt(state.summary, state.messages.last()); // 调用LLM，获取决策 llm_decision = LLM_CALL(decision_prompt); // 解析决策并执行 return parse_decision_and_execute(llm_decision); }