「Regnexe 实战系列」第 7 篇共 10 篇对应仓库ExampleReadme07ThreeLayerMemoryTest。上一篇06. Marketplace 换成数据库只需一个接口。一个容易混淆的概念Agent 记忆这个词在很多教程里是个筐什么都往里装历史对话、执行过程、工具调用轨迹……结果就是写代码的时候一个MapString, Object存了三种完全不同生命周期的数据排查问题的时候根本分不清是哪一层出的 bug。Regnexe 这套 harness 把记忆拆成了三个独立的层互相之间没有继承关系谁出问题只查一层Session 记忆 这个用户之前的任务里说过什么 Task 执行账本 这次 execute()/resume() 每一轮发生了什么 Agent 执行上下文 单次工具调用循环带多少历史第一层Session 记忆——跨任务的长期记忆解决的问题用户这次问根据刚才的天气建议我穿什么Agent 怎么知道刚才指的是什么。RegnexeAgentagentregnexeAgentBuilder.withTool(weatherTool()).withSessionStorage(newInMemoryConversationStorage())// 第一层跨任务会话历史.build();TaskRequestfirstnewTaskRequest();first.setSessionId(sessionId);first.setGoal(Check todays weather in Beijing.);agent.execute(first);TaskRequestsecondnewTaskRequest();second.setSessionId(sessionId);// 同一个 sessionIdsecond.setGoal(Based on that weather, what should I wear today?);agent.execute(second);// 不用重新查天气直接复用上一轮结果回答关键是sessionId相同——两次execute()通过它串联起来第二次任务能直接拿到第一次的结论不需要重新调用工具。默认实现是InMemoryConversationStorage生产环境想跨实例共享就换成自己的ConversationStorage实现跟上一篇的Marketplace是一个套路。第二层Task 执行账本——这一次任务到底经历了什么解决的问题一次execute()内部跑了几轮 Search/Plan/Execute/Reflect每一轮选了什么能力、执行结果是什么、要不要继续——这些过程数据需要持久化用于审计和断点恢复下一篇细讲。InMemoryTaskStoretaskStorenewInMemoryTaskStore();RegnexeAgentagentregnexeAgentBuilder.withTool(weatherTool()).withTaskStore(taskStore).build();AgentResultresultagent.execute(Check todays weather in Beijing. Is it good for running?);TaskExecutionStateledgertaskStore.load(result.getTaskId()).orElseThrow();ledger.getRounds().forEach(r-System.out.println(r.getRoundNumber() | search(r.getSearch()!null) | plan(r.getPlan()!null) | execution(r.getExecutionResult()!null) | reflection(r.getReflection()!null)));跑完之后能看到这次任务每一轮具体做了什么——这是排查为什么这次任务选错了能力最直接的数据来源比翻日志方便得多。第三层Agent 执行上下文——单轮内部的工具调用历史解决的问题Execute 阶段内部如果要连续调用好几次工具比如先查景点、再查餐厅、再生成行程这些中间过程的历史要不要全部带给模型带多了拖慢推理、费 token带少了模型会失忆重复调用。RegnexeAgentagentregnexeAgentBuilder.withTool(weatherTool()).withAgentContext(SlidingWindowContext.builder().windowSize(5).build())// 第三层滑动窗口策略.build();默认是FullContext——不压缩全量带上。工具调用轨迹一旦变长换成SlidingWindowContext之类的有界策略只保留最近若干步超出部分可选择性摘要压缩。为什么一定要拆开混在一起会怎样设想一下如果这三层揉成一个记忆模块Session 记忆要长期保留跨多次任务Task 账本只服务于当前这一次任务生命周期完全不同——混在一起要么 Session 记忆被随手清空要么 Task 账本永久膨胀。Agent 上下文是单轮内部的临时数据跟前两层根本不是一个维度的东西——混进去之后想单独换一个上下文压缩策略会牵连到不该被影响的 Session/Task 数据。拆成三层之后每一层都可以独立替换、独立排查互不传染。这才是分层设计真正要解决的问题不是为了显得架构复杂。 上一篇06. Marketplace 换成数据库只需一个接口 下一篇08. 说停就停说续就续 项目地址https://github.com/flower-trees/regnexe-agent