🗨️ LLM 应用中的消息管理

众所周知，在 LLM 中，对话是最核心的交互方式。无论是 RAG还是 Agent，都离不开对话，而对话管理的关键就是 messages参数的管理**。**

在LLM开发中通常会区分为短期记忆，长期记忆。我这里简化为，

• 长期记忆就是开一个新对话窗口，仍然有之前对话的一些信息，
• 短期记忆就是当前对话窗口的信息，换一个就没有了。

消息类型与机制

• System 消息
  • 作用：设置对话边界、策略、安全规范、角色扮演、工具提示等。
  • 机制：system是系统级Prompt，出现在提交给LLM的第一部分，该消息若频繁修改会导致前缀缓存失效，成本和推理速度大大增加。
• User 消息
  • 作用：用户需求与上下文。
  • 机制：用户输入的内容，RAG检索到的内容、长期记忆等，也会拼接到这里。
• Assistant 消息
  • 作用：回答、触发工具调用。
  • 机制：由模型生成，如果触发工具调用，通常会在tool_call(openai格式)字段里面
• Tool消息
  • 原因：工具调用结果，通常是重要的信息。
  • 机制：工具调用完成后，通常结果会被回调给LLM，由LLM做最后的回答。

消息管理的矛盾

在消息管理中，面临一个取舍：

• 完整：信息越多，模型答案更加的全面，但也可能引入噪音，使模型不确定性增加，同时占用有限的上下文窗口。
• 精炼：能够回答用户问题，但是多样性会降低。

尤其对于工具调用消息，如何保存与利用，是最棘手的部分：

• 保留完整调用步骤 → 方便追溯、复现、改进。
• 只保留最终结果 → 节省 Token，但可能丢失可复用的信息。

常见的消息管理方案

方案 1 保留全部

将完整的对话历史进行保留，包括工具调用，工具结果，错误信息等

好处：模型能完整追溯上下文，保证一致性。

坏处：历史消息会快速膨胀，带宽和 token 成本高

方案 2 抽象化存储

将工具调用和结果，在对话历史中“压缩”后保存。如

压缩前

{
  "role": "tool",
  "content": '":\"北京市气象局\",\"content\":\"##### 精细化预报（2025-09-25 13:39:35北京市气象台发布） 晴 28℃风向：西南 风力：1级 晴 27℃风向：南 风力：1级 晴 27℃风向：南 风力：1级 ###### 36小时天气预报（2025-09-25 13:39:35北京市气象台发布） *   今天夜间 最低气温17℃ 晴转多云 1、2级 南转北风  09-25 下午 晴间多云 28℃偏南风 2、3级 夜间 阴转多云 16℃南转北风 1、2级 09-28 白天 多云转晴 27℃偏北风 2、3级 09-30 白天 阴转多云 27℃北转南风 2、3级 #### 2024年08月06日11时未来24小时全国预报[查看更多](http://bj.cma.gov.cn/fzlm/qgyb/) *   上海 晴 37℃～29℃ 景区 天气 气温 昌平十三陵 晴 27/15 门头沟百花山 晴 24/11 "'
},
{
  "role": "assistant",
  "content": "根据搜索结果，今天北京的天气情况如下：\n 天气状况：晴，部分地区晴间多云\n 气温：最高气温约28℃，最低气温约16-17℃\n 风力：偏南风1-2级，夜间转为北风1-2级\n 空气质量：优至良（根据历史数据推测）"
}

压缩后

{
  "role": "assistant",
  "content": "用户查询天气 → 调用 tavily_search(北京今天天气)，结果是晴天28℃"
}

好处：上下文简化，避免无用 token 消耗。

坏处：丢失调用细节，可能不能重复利用工具调用的信息，如果工具调用错误，被修正后，后续还是调用错误了。

方案 3 分层存储

将对话历史分为用户历史和系统历史分开存储，

• 用户历史：保留对用户有意义的消息（一般采用 用户问题 + 助手总结性回复）。
• 系统历史：完整的历史信息，包括工具调用的原始消息，工具调用结果，工具调用发生的错误等，只在需要的时候才拼接进对话历史。

full_messages: List[Dict[str, str]] = []  # 完整对话历史，可用于回溯
user_messages: List[Dict[str, str]] = [] # 用户对话历史

好处：节省Token，成本较低

坏处：增加了开发复杂度。

方案 4 知识库化

将工具调用的结果抽取成知识点，存入数据库/知识库（比如天气、行情、检索结果），后续如果需要再通过RAG的方式补充进来。

好处：对长对话极其节省 token

坏处：增加了RAG能力，复杂度上升。

实践案例

案例 1 客服机器人

场景：用户会话长、工具频繁调用多、需要复现检查或改进。

策略：抽象存储+分层存储。

要点：

• 系统层：保留完整的对话历史，包括原始请求，RAG结果，工具调用/调用结果。
• 用户层：只保留用户可见的回答并存入数据库，不关心具体的工具调用。

案例 2 金融/投顾应用

场景：事实信息多，必须可完整回溯，严谨性高。

策略：分层存储+知识库化。

要点：

• 完整可追溯的过程。
• 事实明确，方便检索。

消息管理是 LLM 应用的关键，所谓AI应用开发，除了Prompt，最关键的就是消息管理了。