---
title: "LLM 应用中的消息管理"
description: "在大模型（LLM）应用开发中，对话是最核心的交互方式，而消息管理则是实现高效对话的关键。本文系统梳理了 LLM 中常见的消息类型（System、User、Assistant、Tool）及其作用机制，深入分析了短期记忆与长期记忆的差异，并对比了四种典型的消息管理方案：完整保留、抽象化存储、分层存储、知识库化。通过客服机器人与金融投顾两类实际场景案例，文章探讨了不同方案的优劣与适用场景，帮助开发者在 Token 成本、上下文管理和可追溯性之间做出平衡。"
image: "https://wileyzhang.com/posts/cover/27c605ee-e889-80a2-8543-ce7e1a9af9b8_2bb9cca50012781d6d82a5db52c39034.jpg"
url: "https://wileyzhang.com/posts/llm"
date: "2025-09-28"
updated: "2025-09-28"
type: "blog-post"
tags: ["LLM", "LangGraph", "AI"]
reading_time_minutes: 5
estimated_tokens: 1936
---

# LLM 应用中的消息管理

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

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

- **长期记忆**就是开一个新对话窗口，仍然有之前对话的一些信息，

- **短期记忆**就是当前对话窗口的信息，换一个就没有了。

## 消息类型与机制

- System 消息

- **作用**：设置对话边界、策略、安全规范、角色扮演、工具提示等。

- **机制**：system是系统级Prompt，出现在提交给LLM的第一部分，该消息若频繁修改会导致前缀缓存失效，成本和推理速度大大增加。

- User 消息

- **作用**：用户需求与上下文。

- **机制**：用户输入的内容，RAG检索到的内容、长期记忆等，也会拼接到这里。

- Assistant 消息

- **作用**：回答、触发工具调用。

- **机制**：由模型生成，如果触发工具调用，通常会在tool_call(openai格式)字段里面

- Tool消息

- **原因**：工具调用结果，通常是重要的信息。

- **机制**：工具调用完成后，通常结果会被回调给LLM，由LLM做最后的回答。

## 消息管理的矛盾

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

- **完整**：信息越多，模型答案更加的全面，但也可能引入噪音，使模型不确定性增加，同时占用有限的上下文窗口。

- **精炼**：能够回答用户问题，但是多样性会降低。

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

- 保留完整调用步骤 → 方便追溯、复现、改进。

- 只保留最终结果 → 节省 Token，但可能丢失可复用的信息。

## 常见的消息管理方案

### 方案 1 保留全部

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

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

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

### 方案 2 抽象化存储

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

压缩前

```plain text
{
  "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 空气质量：优至良（根据历史数据推测）"
}
```

压缩后

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

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

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

### 方案 3 分层存储

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

- **用户历史**：保留对用户有意义的消息（一般采用 用户问题 + 助手总结性回复）。

- **系统历史**：完整的历史信息，包括工具调用的原始消息，工具调用结果，工具调用发生的错误等，只在需要的时候才拼接进对话历史。

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

好处：节省Token，成本较低

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

### 方案 4 知识库化

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

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

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

## 实践案例

### 案例 1 客服机器人

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

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

**要点**：

- 系统层：保留完整的对话历史，包括原始请求，RAG结果，工具调用/调用结果。

- 用户层：只保留用户可见的回答并存入数据库，不关心具体的工具调用。

### 案例 2 金融/投顾应用

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

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

**要点**：

- 完整可追溯的过程。

- 事实明确，方便检索。

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

---

> 本文由 WileyZhang 原创，首发于 [Wiley Blog](https://wileyzhang.com/posts/llm)。

```json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "LLM 应用中的消息管理",
  "datePublished": "2025-09-28T00:00:00.000Z",
  "dateModified": "2025-09-28T00:00:00.000Z",
  "author": [
    {
      "@type": "Person",
      "name": "WileyZhang",
      "url": "https://wileyzhang.com/about"
    }
  ],
  "image": "https://wileyzhang.com/posts/cover/27c605ee-e889-80a2-8543-ce7e1a9af9b8_2bb9cca50012781d6d82a5db52c39034.jpg",
  "description": "在大模型（LLM）应用开发中，对话是最核心的交互方式，而消息管理则是实现高效对话的关键。本文系统梳理了 LLM 中常见的消息类型（System、User、Assistant、Tool）及其作用机制，深入分析了短期记忆与长期记忆的差异，并对比了四种典型的消息管理方案：完整保留、抽象化存储、分层存储、知识库化。通过客服机器人与金融投顾两类实际场景案例，文章探讨了不同方案的优劣与适用场景，帮助开发者在 Token 成本、上下文管理和可追溯性之间做出平衡。",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://wileyzhang.com/posts/llm"
  }
}
```