Agent记忆与上下文工程#

1. 三层记忆架构#

2. Token 预算分配（以 4K 窗口为例）#

System Prompt:  ~500 token（角色+规则+工具描述）
记忆上下文:     ~500 token（历史摘要/检索的长期记忆）
检索文档:       ~2000 token（RAG 召回内容）
用户输入:       ~100 token
预留生成:       ~500 token
─────────────────────────
合计:           ~3600 token

3. 上下文压缩策略#

4. 长期记忆写回策略#

• 写入什么：事实性结论、用户偏好、任务模板（不写入过程性对话）
• 衰减机制：访问频率衰减（LRU）或时间衰减（TTL）
• 冲突处理：新信息覆盖旧信息 + 版本记录

5. 渐进式披露#

Agent 启动时只加载核心工具描述，根据用户意图动态加载相关工具/规则，避免 System Prompt 膨胀。

Agent记忆系统我理解为三层架构。工作记忆就是Context Window，存放当前对话历史和工具结果，生命周期是单轮推理。短期记忆用Redis存储，保存会话级别的对话摘要和已完成步骤，支持多轮连续交互。长期记忆用向量库加数据库持久化，存储跨会话的用户偏好和知识积累。上下文工程的核心是Token预算管理，以4K窗口为例：System Prompt约500token，记忆上下文500，检索文档2000，用户输入100，预留生成500，总共约3600token。当对话变长时需要压缩策略：最简单是滑动窗口只保留最近N轮，更好的是摘要压缩用LLM把历史对话压缩成摘要，知识密集场景可以用检索式按需加载相关历史片段。长期记忆的写回要谨慎，只持久化事实性结论和用户偏好，过程性对话不写入，还需要衰减机制防止噪声累积。渐进式披露也很重要，不一次性把所有工具和规则塞进System Prompt，根据用户意图动态加载相关的工具描述。

追问方向：

• token 预算怎么动态分配？不同场景分配不一样怎么办？ → 按优先级动态调整：System Prompt 固定 → 用户输入固定 → 剩余空间按比例分给检索文档和记忆。简单 QA 多给检索，多轮对话多给记忆
• 长期记忆的衰减策略怎么设计？怎么防止噪声累积？ → LRU（访问频率衰减）+ TTL（时间衰减）+ 定期清洗（低访问量 + 久远 → 删除）。写入时过滤过程性对话，只持久化事实结论和用户偏好
• 多轮对话越聊越脏（上下文污染）怎么办？ → 用摘要压缩定期”清洗”对话历史（每 5-10 轮压缩一次），保留关键信息丢弃细节。标记”不可压缩”的关键事实
• 渐进式披露在工程上怎么实现？ → 意图分类后按类别加载对应工具描述，不一次性塞所有工具。DocMind 的 RetrievalPlanner 按信号动态选择工具子集，System Prompt 只装当前需要的

易错点：

• ❌ “把所有对话历史塞进 Context” → token 爆炸，成本激增，注意力稀释
• ❌ “长期记忆只做 append” → 噪声累积导致检索质量下降，需要衰减和清洗
• ❌ “摘要压缩不会丢信息” → 摘要必然损失细节，关键信息需要标记为”不可压缩”

项目实践（DocMind）： 语义缓存（SemanticCacheService, 209 行）：query embedding 余弦相似度 + KB version 校验，频率阈值从 3 调到 2 后命中率从 30% 提升到 45%（+15%），命中时模拟流式播放（30 chars/push）保持体验一致。39 个动态配参（rag/llm/cache/safety/功能开关/agent 六组）存 sys_ai_config 表，ConcurrentHashMap + AtomicReference 热加载，修改参数零重启——现有请求持旧引用，新请求取新引用。