1、客服agnet上下文太大怎么进行管理
在智能客服里，多轮对话的上下文处理，我不会简单地把所有历史消息都传给大模型，而是会做分层的 Context Management。
首先是短期上下文，也就是当前会话最近 N 轮对话。它主要保证当前对话的连续性，比如用户先问"iPhone 16 多少钱"，下一轮说"这个还能退吗"，模型需要通过最近的上下文知道"这个"指的是 iPhone 16。这里一般会按照 session_id 管理，并设置窗口大小或者 Token 上限。
如果对话轮次比较长，我不会单纯依赖 Summary。因为 Summary 本身也可能出现信息丢失或者事实漂移。所以历史对话可以通过 Summary 做压缩，Summary 主要保留用户需求、当前任务、已经确认的信息和未解决的问题。
对于比较重要的业务事实，比如当前商品、订单状态、售后状态、用户偏好等，我会单独通过 Memory Extractor 提取成结构化信息，而不是完全依赖 Summary。
这些结构化事实也不是简单地一直追加，而是会有时间、来源、置信度和状态。例如用户原来使用 NVR-A，后来明确说已经换成 NVR-C，那么 NVR-A 可以标记为历史状态，NVR-C 成为当前 active 状态。这样可以避免长期对话中出现多个互相冲突的信息。
对于事实冲突，我一般会优先相信用户明确表达的信息和业务系统的真实数据，再参考模型推断，同时结合时间和 confidence 做判断。
在真正进行 LLM 推理的时候，也不会把所有历史记忆全部放进 Context，而是根据当前 Query 做相关记忆召回，只把和当前问题相关的信息放进去。
另外，客服场景经常存在指代问题，所以我会增加 Query Rewrite 或指代消解。例如用户先问"iPhone 16 多少钱"，然后问"这个还能退吗"，系统可以结合历史上下文把它改写成"iPhone 16 还能退吗"，然后再进入意图识别、RAG 或 Tool Calling。这样后面的检索和 Agent 执行会更准确。
所以一次请求最终给 LLM 的 Context，我一般会动态组装成：
System Prompt
-
用户相关画像
-
当前会话 Summary
-
最近 N 轮对话
-
当前 Query
-
必要的业务状态
-
RAG 检索结果
-
Agent 当前 State
而不是把整个聊天记录全部塞进去。
所以我理解企业级多轮客服的核心不是保存尽可能多的历史，而是把不同类型的信息分开管理：
原始历史负责可追溯，
Summary 负责上下文压缩，
Structured Memory 负责保存关键事实，
Memory Retrieval 负责召回相关信息，
当前 State 负责保证任务连续性。
这样即使一个会话达到几百甚至上千轮，也不需要把所有历史全部发送给 LLM，同时能够尽量避免因为上下文过长、摘要丢失或者事实冲突导致模型理解错误。
最终目标就是：在控制 Token、延迟和成本的同时，让模型在当前这一轮拿到真正相关的信息。
近 → 最近 N 轮
摘 → Summary 摘要
事 → 关键业务事实
召 → 相关记忆召回
改 → Query Rewrite
组 → 动态 Context 组装