---
tags: [ai/agent, rag, context-engineering, memory-management, prompt-compression]
create time: 2026-08-08 18:43
update time: 2026-08-08 18:43
---

# 上下文工程与记忆管理

## 概述

LLM 本身是无状态的，它的"知识"完全依赖每次请求时注入的 Prompt Context。上下文工程的本质是在有限的 token 预算内，最大化信息密度和相关性。记忆管理则是跨会话持久化用户偏好和事实，让 Agent 具备成长能力。

## 详解

### RAG 流程：从文档到可检索的向量

RAG（Retrieval-Augmented Generation）将外部知识库与生成式模型结合，解决 LLM 知识截止和幻觉问题。完整链路如下：

```mermaid
graph LR
    A["原始文档"] --> B["Chunking\n分块处理"]
    B --> C["Embedding\n向量化"]
    C --> D["向量数据库"]
    D --> E["Top-K 相似度检索"]
    E --> F["Prompt Context 组装"]
    F --> G["LLM 生成答案"]
```

#### Chunking 分块策略

把长文档切分为适合 Embedding 的片段是关键，直接影响检索精度：

| 策略 | 实现方式 | 优缺点 |
|------|---------|--------|
| 固定长度 | 按字符数 N 切割，重叠 M | 简单快速；可能截断语义 |
| 语义边界 | 在标题、段落间切割 | 保持结构完整；需启发式规则 |
| 递归分块 | Markdown 级别逐层深入 | Hierarchy-aware；实现复杂 |
| 文档感知 | 基于 PDF/Docx 解析的结构信息 | 最精准；依赖文档格式质量 |

实际项目中推荐**递归分块 + 重叠**：先按 Markdown 层级分，同一块超过阈值再按句子切，相邻块保留 10-15% 重叠区避免关键句被拆分。

#### Embedding → 向量存储

将文本映射为高维稠密向量（通常 768-1536 维），然后存入向量数据库：

```go
// Go 示例：Embedding + 存储到 pgvector
func StoreDocument(ctx context.Context, db *sql.DB, doc string) error {
    // 1. 调用 Embedding API 获取向量
    vec, err := embeddingClient.Embed(ctx, doc)
    if err != nil {
        return err
    }
    // 2. 存入 PostgreSQL + pgvector
    _, err = db.ExecContext(ctx,
        `INSERT INTO documents (title, content, embedding)
         VALUES ($1, $2, $3::vector)`,
        doc.Title, doc.Content, pq.Array(vec))
    return err
}
```

> [!NOTE]
> 向量维度选择是权衡：768 维够用且快，1536 维更精细但消耗更多内存和计算资源。国内常用的 text-embedding-v3 默认 1536 维。

#### Top-K 检索与重排

检索不是终点——召回 Top-K 后还需要精排：

```
检索阶段（召回）: BM25 / 向量相似度 → 取 Top 50
              ↓
重排阶段（精排）: Cross-Encoder 对 50 条打分 → 取 Top 5
              ↓
过滤阶段: 关键词匹配校验 + 去重 → 最终 Top 3 注入 Prompt
```

Cross-Encoder 比 Single-Encoder 精度高约 10-15%，但速度慢 20 倍，所以只做二次筛选而非全量检索。

#### Prompt Context 组装策略

组装顺序和内容直接影响生成质量：

1. **系统提示**（固定，不可变）：定义 Agent 角色和行为准则
2. **事实上下文**（动态检索）：从向量库查得的 Top-K 文档片段
3. **对话历史**（滑动窗口）：最近 N 轮消息
4. **用户最新提问**

组装优先级：**系统提示 > 事实上下文 > 历史对话**

> [!WARNING]
> 不要盲目把全部 Top-K 塞进 Prompt。token 预算有限，超出的部分会触发 truncation 丢失重要信息。建议按相关度降序填充，直到触及 token 上限为止。

### Prompt 压缩方法

当检索结果过多或对话历史过长时，需要压缩上下文以节省 token：

| 方法 | 原理 | 效果 |
|------|------|------|
| 信息密度排序 | 按每 token 包含的事实数量排序，保留高密度片段 | 保留核心信息，丢弃废话 |
| 摘要浓缩 | 用 LLM 将多个片段合并为一句话摘要 | 显著缩减长度，但有信息损失 |
| Token 池修剪 | 计算每个片段的 Self-Influence Score，剔除冗余 | 理论最优，需额外推理开销 |
| 滑动窗口 | 只保留最近 N 轮对话 | 最简单但丢弃早期关键信息 |

```go
// Go 示例：基于信息密度的 Context 压缩
type Compressor struct {
    model *llm.Client
}

func (c *Compressor) Compress(ctx context.Context, segments []Segment) []Segment {
    // 计算每个段落的「非停用词比例」作为密度评分
    scored := make([]ScoredSegment, len(segments))
    for i, seg := range segments {
        score := float64(len(stopWordFree(seg.Text))) / float64(len(seg.Text))
        scored[i] = ScoredSegment{Segment: seg, Score: score}
    }
    // 按密度降序排列，取前 K 个
    sort.Slice(scored, func(i, j int) bool {
        return scored[i].Score > scored[j].Score
    })
    return takeK(scored, MaxSegments)
}
```

### 记忆管理架构

Agent 的记忆分三层，对应不同的生命周期和查询方式：

```
短期记忆 ──────→ 当前会话内的对话历史 ──────→ 滑动窗口删除
     │                                          │
     ▼                                          ▼
长期记忆 ──────→ 跨会话的知识库 ───────────→ 定期增量更新
     │                                          │
     ▼                                          ▼
工作记忆 ──────→ 运行时临时状态 ───────────→ 任务结束后清空
```

#### 短期记忆 — 对话历史

维护最近 N 轮的用户-AI 交互记录。实现要点：

- **双端队列**：头部保留最近 N 轮，尾部超过时淘汰
- **Token 预算优先**：不是简单地固定轮数，而是累计 token 不超过配额
- **关键信息提取**：每轮结束时自动提取实体和意图摘要，追加到摘要缓冲区

```go
type ShortTermMemory struct {
    messages []*ChatMessage
    budget   int // token 预算
}

func (m *ShortTermMemory) Add(msg *ChatMessage) {
    m.messages = append(m.messages, msg)
    for totalTokens(m.messages) > m.budget {
        m.messages = m.messages[1:] // 移除最早的一条
    }
}
```

#### 长期记忆 — 知识库 + 向量检索

用户在交互中表达的偏好、事实陈述、决策记录会被抽取并持久化：

```
输入: "我偏好使用 Gin 框架，不喜欢 Echo"
       ↓
NLP 抽取: Entity="Gin", Relation="preferred over", Target="Echo"
       ↓
存储: INSERT INTO long_term_memory (type, entity, relation, target, created_at)
       ↓
检索时: 通过关键词搜索 + 向量相似度召回相关记忆片段
```

记忆类型包括：

| 类型 | 内容示例 | 保留策略 |
|------|---------|---------|
| UserPreference | 技术栈偏好、代码风格偏好 | 永久保留，定期去重 |
| FactStatement | "PostgreSQL 支持 JSONB" | 有效期 90 天，可续期 |
| DecisionRecord | "项目选择了 gRPC 而非 REST" | 永久保留 |
| TaskProgress | "已完成认证模块的开发" | 任务结束后归档 |

#### 记忆更新策略

记忆不是一次性写入的，需要考虑：

1. **新增**：新发现的信息插入知识库
2. **修正**：用户说"我之前说错了"，标记旧记忆为 obsolete
3. **合并**：多轮对话中提取到的碎片信息聚合为统一事实
4. **衰减**：随时间推移降低旧记忆的权重，`weight *= decay_factor`

> [!TIP]
> 面试常考点：为什么 RAG 不能替代记忆？答案是 RAG 面向的是外部知识（文档、手册），而记忆面向的是个性化数据（用户偏好、历史对话）。两者正交，互补而非互斥。

## 实践场景

**ThumbUP 项目的二级缓存设计** 就是上下文工程的典型应用：
1. 第一级缓存：本地 LRU，命中率最高（热点 query）
2. 第二级缓存：Redis + 向量检索，覆盖中长尾请求
3. HeavyKeeper 算法实时探测热点 key，避免缓存雪崩

这种分层思路同样适用于记忆管理——短期记忆（本地 LRU）+ 长期记忆（远程向量库）。

## 扩展阅读

- [[Eino DAG 工作流设计]]
- [[沙箱权限治理]]
- [[循环状态机在Agent中的应用]]