agentic_huge_data_base / wiki
页面 jcode · 6 记忆与上下文管理·DeepWiki 中文全文译文
DeepWiki 中文译文 / jcode / 6

6 · 记忆与上下文管理（Memory and Context Management）

代理式研究运行时 · 聚焦本章的模块关系、源码依据与实现要点。

项目jcode 章节6 状态全文译文 模块记忆与上下文、界面与交互、系统架构、智能体运行时
项目要点页2.5 参考项目 项目章节目录jcode DeepWiki 原始章节Memory and Context Management 上一章5.2 下一章6.1
源码线索
  • docs/AMBIENT_MODE.md
  • docs/MEMORY_ARCHITECTURE.md
  • docs/MEMORY_BUDGET.md
  • docs/SAFETY_SYSTEM.md
  • src/compaction.rs
  • src/compaction_tests.rs
  • src/import_tests.rs
  • src/lib.rs
  • src/memory.rs
  • src/memory_agent.rs
模块标签
  • 记忆与上下文
  • 界面与交互
  • 系统架构
  • 智能体运行时
  • 测试、发布与运维

章节正文

记忆与上下文管理

原始 DeepWiki 页面https://deepwiki.com/1jehuang/jcode/6-memory-and-context-management

内存与上下文管理

相关源文件

以下文件为本 Wiki 页面的生成提供了上下文：

  • docs/AMBIENT_MODE.md
  • docs/MEMORY_ARCHITECTURE.md
  • docs/MEMORY_BUDGET.md
  • docs/SAFETY_SYSTEM.md
  • src/compaction.rs
  • src/compaction_tests.rs
  • src/import_tests.rs
  • src/lib.rs
  • src/memory.rs
  • src/memory_agent.rs
  • src/memory_tests.rs
  • src/sidecar.rs
  • src/tool/memory.rs
  • src/tui/app/conversation_state.rs
  • src/tui/info_widget_memory_render.rs

jcode 系统采用了一种精巧的双层内存架构，旨在同时应对大语言模型（LLM）上下文窗口的即时限制和跨会话学习的长期需求。该机制确保代理在长对话中保持高效，同时能无限期地保留关键的"事实"和"偏好"。

架构总览

内存系统分为短期上下文管理（压缩）和长期持久化内存（内存代理）两部分。

1. 短期：上下文压缩

随着对话的进行，Token 数量会逐渐接近模型限制（例如 Claude 的 20 万 Token）。CompactionManager 会监控这一预算，并在达到阈值时触发后台摘要生成，将较早的对话历史"压缩"成简洁摘要，从而在不丢失高层上下文的前提下为新轮次腾出空间。src/compaction.rs:1-17

2. 长期：持久化内存

跨会话内存由一个专用的异步内存代理管理。该代理结合了用于相似性搜索的向量嵌入（Embedding）和基于图的结构（MemoryGraph），以呈现相关的历史信息。它会在后台运行，仅当当前对话语义触发时，才通过 PENDING_MEMORY 管线将相关"记忆"注入主代理的提示词中。src/memory_agent.rs:1-10

内存子系统交互

jcode · 2. 长期：持久化内存 · 图 1
jcode · 2. 长期：持久化内存 · 图 1

来源：src/compaction.rs:1-17, src/memory_agent.rs:1-10, docs/MEMORY_ARCHITECTURE.md:22-58

压缩管理器

CompactionManager 负责确保对话不会超过 DEFAULT_TOKEN_BUDGET（默认为 200,000 Token）src/compaction.rs:99-100, src/compaction.rs:30-30。它会跟踪 compacted_count，以跳过已被摘要化的前置消息 src/compaction.rs:66-68。

模式描述
反应式在固定阈值（COMPACTION_THRESHOLD = 预算的 80%）触发 src/compaction.rs:13-13。
主动式使用 EWMA（指数加权移动平均）预测增长并提前压缩 src/compaction.rs:14-14。
语义式通过嵌入最后一条助手消息来检测主题转换，在自然过渡点进行压缩 src/compaction.rs:15-16, src/compaction.rs:126-130。

当达到 CRITICAL_THRESHOLD（95%）时，系统会执行 hard_compact_with 紧急回退，立即丢弃最旧的消息，以防止 API 调用失败 src/compaction.rs:30-30, src/tui/app/conversation_state.rs:76-78。

有关 Token 跟踪和摘要生成逻辑的更多细节，请参阅 压缩管理器。

来源：src/compaction.rs:11-56, src/compaction.rs:135-182, src/tui/app/conversation_state.rs:29-47

内存管理器与内存代理

长期内存被存储并组织为项目（目录特定）和全局（用户范围）两个作用域 src/memory.rs:3-6。

内存生命周期
  1. 提取：在会话结束时，或在环境模式下，Sidecar（一个使用 gpt-5.3-codex-spark 或 claude-haiku 的轻量级大语言模型调用）从对话记录中提取新的事实 src/memory_agent.rs:121-142, src/sidecar.rs:15-21。
  2. 存储：记忆以 MemoryEntry 对象的形式存储，包含内容、类别（事实/偏好/修正/实体）和元数据 src/memory.rs:32-35。
  3. 检索：MemoryAgent 执行级联检索。它首先进行嵌入向量相似性搜索（all-MiniLM-L6-v2），然后遍历 MemoryGraph，通过 HasTag 或 RelatesTo 边查找相关节点 docs/MEMORY_ARCHITECTURE.md:221-246, src/memory_agent.rs:21-25。
  4. 验证：在注入之前，Sidecar 会验证检索到的记忆是否确实与当前轮次相关，以避免"幻觉"上下文 src/memory_agent.rs:29-36。
内存图结构

系统使用 petgraph::graph::DiGraph 来建模记忆之间的关系 docs/MEMORY_ARCHITECTURE.md:127-134。

内存对象模型

jcode · 内存图结构 · 图 2
jcode · 内存图结构 · 图 2

来源：src/memory.rs:10-13, docs/MEMORY_ARCHITECTURE.md:66-83, docs/MEMORY_ARCHITECTURE.md:104-134, src/memory_agent.rs:22-25

有关嵌入向量管线和图遍历的详细信息，请参阅 内存管理器与内存代理。

环境"维护"

内存并非静态不变。在环境模式下，代理会执行"维护"周期，包括：

  • 合并：合并重复的记忆 docs/AMBIENT_MODE.md:125-125。
  • 修剪：移除过时或矛盾的事实 docs/AMBIENT_MODE.md:127-127。
  • 验证：使用 Sidecar 检查存储的事实是否仍与代码库的当前状态一致 docs/AMBIENT_MODE.md:128-129。

来源：docs/AMBIENT_MODE.md:10-15, docs/AMBIENT_MODE.md:124-131

子页面

  • 压缩管理器：深入探讨 CompactionManager 的 Token 预算跟踪、基于 EWMA 的预测以及紧急 hard_compact_with 逻辑。
  • 内存管理器与内存代理：MemoryEntry 生命周期、petgraph 图遍历、Sidecar 相关性验证以及异步 PENDING_MEMORY 管线的技术细节。