ERP-Agent记忆系统优化：解决多轮对话信息丢失问题

1. ERP-Agent 记忆系统现状分析

作为一名长期从事企业级AI系统开发的工程师，我最近在优化ERP-Agent的记忆系统时遇到了一个典型问题：随着对话轮次增加，早期关键信息会被无情丢弃，导致后续对话质量下降。这就像和一个健忘的同事讨论项目，每次都要从头解释背景，效率极其低下。

1.1 当前架构的核心痛点

我们现有的MemoryManager模块采用简单的滑动窗口机制（window_size=100轮=200条消息），这种设计在初期确实简单有效，但随着业务场景复杂化，暴露出三个致命缺陷：

1. 信息丢失不可控：窗口外的对话直接被丢弃，没有任何摘要或压缩机制。在ERP场景中，用户可能在早期对话中定义了关键参数（如组织ID=86），后期查询时系统却"忘记"了这个核心条件。

2. Token管理粗放：仅按消息数量裁剪，不考虑实际token消耗。我曾遇到一个案例：10条长SQL查询就耗尽了8000token的上下文窗口，而系统还在傻等凑满100轮才触发裁剪。

3. 实体记忆孤立：虽然EntityMemory模块能提取项目名、模块名等实体，但这些信息与对话历史割裂。就像有了联系人名片却不知道之前的通话记录，LLM无法建立完整认知。

1.2 竞品方案对比研究

在寻找解决方案时，我重点分析了两个优秀的开源项目：

Nanobot的双层记忆架构：

• 长期记忆（MEMORY.md）：结构化存储关键事实
• 历史日志（HISTORY.md）：完整记录对话时间线
• 自动压缩机制：当token超限时调用LLM生成摘要

Claw-Code的项目上下文感知：

• 整合Git状态、配置文件等环境信息
• 精确的Token预算管理
• 多层配置系统适配不同场景

通过对比发现，我们的系统在架构完整性上存在明显差距。但直接照搬也不现实——Nanobot的自动压缩需要频繁调用LLM，成本激增；Claw-Code的Rust实现又与我们的技术栈不匹配。

2. 分阶段优化方案设计

基于"快速验证、渐进优化"的原则，我制定了三个阶段递进的改造计划。

2.1 阶段1：低成本高收益改造（1周）

2.1.1 Token预算精准管理

首先改造裁剪逻辑，从单纯计数改为双重判断：

python复制class MemoryManager:
    def _trim(self, session_id: str):
        current_tokens = calculate_token_usage(self.messages)
        while len(self.messages) > 0 and (
            len(self.messages) > self.w