从 Hermes Agent 的⻓期记忆结构出发⽤基础⽂件系统、TriggerFlow、agent direct request 和最后的 Workspace 综合案例搭⼀个可解释的⾃进化闭环。Workspace在本地创建一个文件区域存放、读取对应文件。模型本身没有记忆模型能够多轮对话依赖我们给它提供上下文最简单的上下文就是把所有的会话记录都传递给它模型有上下文限制大prompt超长上下文模型有惩罚机制要花更多钱以及时间更长简单粗暴的方式直接使用模型的超长上下文模型记忆的由来超过1M的内容就没有在当前上下文内如图所示第-4轮有后续任务执行的规则但是它的内容没办法在模型上下文内所以模型不知道因此导致模型前3轮输出是正常第4轮开始模型输出就会出现幻觉。哪些场景适合用超长上下文核心选型逻辑一次性处理、单文档为主、低更新频率核心诉求是“读全量原文拒绝碎片化理解”。法律/合同/审计文档审阅一次性审核数十页合同、审计报告需逐字核对风险全量投喂无需搭建检索系统开发成本最低代码/PR逻辑Review审阅大型函数、复杂配置或完整PR避免切分导致逻辑断裂适配一次性精读需求静态长文档问答产品说明书、历史白皮书、归档项目报告等一次解析长期可用无需高频维护架构。关键优势架构极简不用维护向量数据库、理解完整无信息丢失、成本可控降低开发运维复杂度。大家对超长上下文感兴趣的可以阅读我之前写的文章 百万token时代来临为什么90%的企业仍需RAG架构。案例小李做了一个旅行规划 Agent。6 月中旬用户让它排北京三日亲子游初版把故宫和环球影城排进了同一天路线检查工具报了失败修正成同区域聚合、远距离大项单独占一整天之后检查通过。用户临走前还特意交代了一句“以后给我这种结果把检查结论一起附上。”一周后同一个用户来排西安两日游。Agent 把兵马俑和回民街塞进了同一天——兵马俑在临潼区距市区约 40 公里这和上周北京那次是同一类错误。用户的附检查结论交代它也像没听过一样。这不是模型能力问题。 Agent并没有记住用户提出的要求会话结束时上下文被丢弃上一次的失败证据、修正方案、用户交代全都留在了那段再也不会被读到的聊天记录里。要解决它第一反应往往是上 RAG——但先看一下 RAG 和记忆系统各自覆盖什么。记忆系统有四个动作RAG 只覆盖其中一个RAG 回答的问题是从一批资料里找相关片段。资料本身是静态的不管任务成败它都不会变。对于RAG来讲它更多得解决问题一批相对静态得资料通过向量库来进行查找与读取。我们的记忆系统会比我们讨论的更多一点除了写以外随着往前去推动对话轮次随着可能我们会需要得大会话得场景需要需要对记忆进行写入、修正、遗忘、召回操作。记忆系统内修正与遗忘也是非常关键得步骤记忆系统面对的是不断产生的经历至少要回答四个问题动作要回答的问题常见工程实现写入ingestion什么经历进入记忆系统事件流、工具结果、用户偏好、决策记录修正revision旧记忆怎样被改写摘要重写、同义合并、证据重链遗忘forgetting什么不再进入候选上下文过期、降权、归档、删除召回retrieval新任务取回哪些记忆文本检索、规则过滤、上下文打包简而言之记忆系数与RAG之间还是有一定区别得向量库负责存进去还能读出来记忆系统要负责这条记录在未来该不该影响行为。记忆系数是一套管理规则不是存储库就能解决问题。四层记忆理论先分清放在哪里直接写代码之前先把长期记忆分层。CoALA把语言 Agent 的记忆分成working、episodic、semantic、procedural 四类工作记忆、情景记忆、语义记忆、程序记忆。本文把它落到工程上分成四层其中 episodic 按治理需要拆成原始和整理后两层procedural 收窄为可召回的规则避免LLM思考不跑偏用直接的范式表达案例范式表达的prompt拼接层放什么默认是否进 promptWorking Memory当前任务必要信息是Raw Episodic原始事件、工具输出、对话否Consolidated Episodic任务摘要、决策、失败原因候选Semantic / Policy稳定规则、偏好、长期事实高优先候选分层不是为了名称好看而是为了三件事只把少量稳定信息放进上下文需要证据时能回读原始记录记忆变旧或冲突时能定位并修正。每一层的治理属性都不一样——raw 层只追加、不修饰semantic 层少而稳定、每条都要有晋升理由。分层治理也不等于堆数据库。Hermes Agent 的实际结构很值得参考因为它把长期记忆拆得很克制小而常驻的稳定记忆、可检索的完整会话历史、以及可选外部 Memory Provider。Hermes Agent小稳定层 大历史层 外部附加层Hermes Agent 实际结构本文四层里的位置本文的落地方式MEMORY.md/USER.mdSemantic / Policy 的稳定规则与用户偏好semantic_rules.jsonl规则少而稳定带证据和晋升理由会话启动场景判定 - 优先读取MEMORY.md/USER.md的文本 - 取出和场景对应的部分SQLite按需使用冷数据 session_searchRaw Episodic 的完整事件流raw_events.jsonl原始对话和工具结果只追加当我在某一个任务进行到一定程度的时候我会根据一些后面的MEMORY.md提供的数据指向了某个冷数据我还需要解读看一看当时发生了什么事情这个时间冷数据才会被读取会话结束抽取 / 后台 reviewRaw → Consolidated → Semantic 的整理动作心跳定时触发文件整理步骤和 checkpoint记忆整理Memory Provider语义检索与外部记忆扩展可选的向量库扩展ChromaDB / LanceDB不作为主存储Skills 自改进Procedural memory收窄为 Semantic / Policy 层的可召回规则技能生成与修补不属于记忆管线对会话做进一步加工我们不是照搬 Hermes 的文件格式而是复现它背后的系统分工稳定层小而可信历史层完整可查附加检索层可换后台整理负责把经历压成可复用经验。四层记忆怎么抽取来源、压缩和输出有了四层理论之后再回到素材。下图是一段仿真长对话三个会话、36 个事件就是第一节小李那个 Agent 的完整流水。原始事件层的信息会话内容埋了什么s_0614_beijing18 轮北京三日亲子游路线检查失败→修正、用户偏好午睡、别塞满、显式交代以后附检查结论、天气闲聊s_0621_xian14 轮西安两日游同一类跨区失败第二次出现、重点排上午偏好、口误噪声s_0622_expense4 轮出租车发票报销另一个项目的显式交代以后小额票直接预审用来验证记忆的项目隔离每个事件带四类字段身份event_id/project_id/session_id/turn角色user / assistant / tool内容text工具事件特有的结构化结果tool/status留意status这个字段路线检查的failed / passed是工具返回的结构化事实后面它会成为代码可以直接核对的证据。数据清理成人类理解的信息 第一组北京三日亲子游 1. user: 帮我规划一个北京三日亲子游6月20号出发带着5岁的女儿。最后要给我一份能真正走得通的行程。 2. assistant: 好的。先确认两件事你们住在哪个区域有没有一定要去的景点 3. user: 住王府井附近。故宫肯定要去孩子一直念叨环球影城。对了北京最近热不热 4. assistant: 六月下旬白天气温30度上下早晚舒服一些记得给孩子备防晒和水壶。景点方面我来排一版初稿。 5. user: 孩子才5岁走不了太多路下午两点到四点最好能回酒店午睡。 6. assistant: 记下了。初版行程第一天上午天安门广场下午国家博物馆第二天上午故宫下午环球影城第三天上午景山公园下午王府井步行街。 7. tool route_checker:failed: 路线检查失败第二天下午从故宫东城区到环球影城通州区单程通勤约1.5小时加上入园排队对5岁儿童的下午时段不可执行。 8. assistant: 检查没通过问题出在把跨区的大项目塞进了半天。调整思路同区域景点聚合到同一天环球影城这种远距离大项单独占一整天。 9. user: 对另外我不想要那种网红打卡式的安排一天别塞太满。 10. assistant: 修改后行程 v2第一天 天安门-故宫-景山同区域步行可达下午两点回酒店午睡第二天 环球影城一整天第三天上午自然博物馆下午机动。 11. tool route_checker:passed: 修正后路线检查通过三天行程内跨区移动仅一次每日步行量与午休窗口符合学龄前儿童条件。 12. user: 这版可以。以后给我这种结果的时候把检查结论一起附上我不想只看一段漂亮介绍。 13. assistant: 好的以后输出行程会附上路线检查的结论和依据。 14. user: 顺便问一下故宫门票是不是要提前预约 15. assistant: 是的故宫需要提前在官方渠道实名预约暑期旺季建议提前七天蹲点当天基本没票。 16. user: 好第一天上午就定故宫票我今晚约。 17. assistant: 已调整第一天上午故宫、下午景山午休窗口保留。最终版行程和检查结论已经打包给你。 18. user: 今天先到这谢谢。 第二组西安两日游 1. user: 上次北京的行程走得很顺利。这周末想带娃去西安两天还是那个原则别太累。 2. assistant: 好的。初版第一天上午兵马俑下午回城逛回民街和钟楼第二天上午陕西历史博物馆下午大雁塔。 3. tool route_checker:failed: 路线检查失败兵马俑位于临潼区距市区约40公里往返加游览至少6小时下午回城遇高峰第一天行程超时不可执行。 4. assistant: 又是同一类问题远距离大项被排进了半天。调整兵马俑单独占一整天市区景点聚合到第二天。 5. user: 对了娃上午精神最好重要的景点尽量排上午。 6. assistant: 收到。v2第一天兵马俑一整天上午看核心俑坑第二天上午陕西历史博物馆下午大雁塔北广场喷泉晚饭回民街。 7. tool route_checker:passed: 修正后路线检查通过两天行程跨区移动一次每日行程量符合学龄前儿童条件午休窗口已预留。 8. user: 陕历博的票好约吗 9. assistant: 陕西历史博物馆免费不免票旺季名额紧张建议提前五天在官方公众号预约。 10. user: 行。对了你们这个报销流程……哦不对说错了那是工作群的事。 11. assistant: 没关系。西安这边还有什么要调整的吗 12. user: 这次也记得把检查结论附上。 13. assistant: 附上了route_checker 通过两天行程跨区一次午休窗口已预留重点景点都在上午。 14. user: 完美就这么定。 第三组出租车发票报销 1. user: 帮我看看这张出租车发票能不能走差旅报销金额86块。 2. assistant: 可以先确认两点是否在出差期间产生、发票抬头是否为公司全称。这两条满足就能提交。 3. user: 是出差期间的抬头也对。以后这种小额交通票你直接按新版差旅制度帮我预审别每次都问。 4. assistant: 好的以后小额交通票默认按新版差旅制度先做预审再给你确认结果。四层记忆的抽取方式四层记忆不是同一个时间点生成的。raw / consolidated / semantic主要由整理管线生成和治理working memory是新任务进来时按任务目标和项目范围动态构建的。记忆层来源放什么抽取方式压缩方式默认是否进入上下文Raw Episodic对话事件、工具调用、工具结果原始事件、工具输出、对话代码原样写入不做语义判断不压缩只保留原始事件否Consolidated Episodic同一会话内的 raw 事件会话摘要、候选记忆、过程记忆agent direct request 读取事件流抽取 episode 摘要和候选记忆多轮对话压成会话摘要、失败原因、候选经验候选Semantic / Policy多个 episode 的候选记忆稳定规则、偏好、长期事实、能力方法agent 判断同义候选代码按证据决定晋升候选句压成稳定规则并保留晋升理由和证据链接按任务召回Working Memory当前任务 可召回的长期记忆当前任务必要信息读取 semantic 和 consolidated 文件规则、经验、证据按相关性打包成任务简报是分层是为了三件事只把少量稳定信息放进上下文需要证据时能回读原始记录记忆变旧或冲突时能定位并修正。raw 层只追加、不修饰semantic 层少而稳定每条都要有升格理由working memory 是临时产物用完可以重建。心跳整理只是定时触发前三层的抽取和晋升新任务唤起时系统再把前三层里相关的内容压成 working memory。Hermes Agent 的实际结构可以对进这张表MEMORY.md/USER.md对应稳定规则与用户偏好semantic 层SQLite session_search对应完整会话历史raw 层会话结束抽取和后台 review 对应整理动作Skills 自改进对应能力/方法记忆。这套实现不照搬它的文件格式只沿用分工稳定层小而可信历史层完整可查后台整理负责把经历压成可复用经验。先只写 raw 层看没有自进化整理的召回长什么样这个实验故意只做一半把 36 个事件原样写进raw_events.jsonl不做任何整理然后用最朴素的文件检索看新任务能拿回什么。# 只保存 raw 事件然后用朴素文本重叠做一次召回ifDEMO_ROOT.exists():shutil.rmtree(DEMO_ROOT)MEMORY_DIR.mkdir(parentsTrue,exist_okTrue)NEW_TASK给一家三口规划上海两天家庭游最终路线要可执行。RAW_PATHMEMORY_DIR/raw_events.jsonlwrite_jsonl(RAW_PATH,events)defscore_raw_event(event:dict[str,Any],query:str)-int:textstr(event.get(text,))query_tokensset(re.findall(r[一-鿿]{2}|[a-zA-Z0-9],query))returnsum(1fortokeninquery_tokensiftokenintext)travel_events[eventforeventineventsifevent[project_id]travel-agent]ranked_raw_eventssorted(travel_events,keylambdaevent:(score_raw_event(event,NEW_TASK),-int(event[turn])),reverseTrue,)show({raw_file:str(RAW_PATH.relative_to(LESSON_ROOT)),raw_event_count:len(events),new_task:NEW_TASK,raw_recall_items:[{event_id:event[event_id],session_id:event[session_id],role:event[role],text:event[text],}foreventinranked_raw_events[:5]],}){raw_file:.demo_runs/notebook_inline/memory/raw_events.jsonl,raw_event_count:36,new_task:给一家三口规划上海两天家庭游最终路线要可执行。,raw_recall_items:[{event_id:evt_b03,session_id:s_0621_xian,role:tool,text:路线检查失败兵马俑位于临潼区距市区约40公里往返加游览至少6小时下午回城遇高峰第一天行程超时不可执行。},{event_id:evt_a07,session_id:s_0614_beijing,role:tool,text:路线检查失败第二天下午从故宫东城区到环球影城通州区单程通勤约1.5小时加上入园排队对5岁儿童的下午时段不可执行。},{event_id:evt_b07,session_id:s_0621_xian,role:tool,text:修正后路线检查通过两天行程跨区移动一次每日行程量符合学龄前儿童条件午休窗口已预留。},{event_id:evt_a11,session_id:s_0614_beijing,role:tool,text:修正后路线检查通过三天行程内跨区移动仅一次每日步行量与午休窗口符合学龄前儿童条件。},{event_id:evt_a13,session_id:s_0614_beijing,role:assistant,text:好的以后输出行程会附上路线检查的结论和依据。}]}召回拿到的全是流水片段两条失败报错、两条修正后的检查通过、一句以后会附上结论的应答。看起来条条沾边但没有一条能直接遵守——“远距离大项单独占一整天这条最值钱的教训分散在失败报错、修正方案、用户确认三四个事件里任何逐条检索都拼不回完整的它。问题不在检索算法在于 raw 层里根本不存在这条整理后的记录”。这就是分层要解决的具体问题值得留下的信息需要先被抽取和整理成独立的记录才谈得上被召回。分步整理每一层都有暂存产物分步整理分两步raw 事件 ↓ 第一步压缩每个会话一次 会话摘要 候选记忆 过程记忆 ← session_memory ↓ 第二步压缩升格宁紧勿松 长期记忆含能力/方法 ← long_term_memory / capability_memory第一步压缩有两个字段约束值得停一下statement要求脱离本次对话也能读懂——记忆是给未来的任务读的用户说下午要午睡到了下个月就没人知道指的是谁evidence_event_ids强制每条候选挂上支撑它的事件——没有证据的记忆后面既没法核对也不该升格。下面不把四层整理挤进一个大脚本而是分成几段可以单独观察的代码raw 只保存consolidated 负责会话压缩semantic 负责规则晋升working memory 负责新任务临时打包。抽取脚本给每条候选记忆定了两个字段约束值得停一下。第一statement记忆陈述要求脱离本次对话也能读懂——记忆是给未来的任务读的用户说下午要午睡到了下个月就没人知道指的是谁、哪次行程。第二supported_event_ids强制每条候选挂上支撑它的事件——没有证据的记忆后面既不能核对也不能晋升。跑完后打开 记忆文件 可以验证天气闲聊、口误都没被抽进来。语义层输出同义合并与三条晋升通道上面只压了一个会话的 4 条事件。历史一多不能把所有 raw 事件一次塞给模型——上下文装不下失败也没法重跑。更稳的做法是拆成 Map-Reduce阶段模型看到什么输出什么为什么这样切Map一个会话或一个时间片会话摘要、候选记忆、过程记忆上下文短证据完整失败可重跑Reduce多批候选记忆合并后的长期记忆同义合并、跨会话重复、证据核对Checkpoint已处理批次和 session断点文件中断后从未完成批次继续升格时候选的四类kind各归各位user_preference → user_preference用户偏好 fact → stable_fact稳定事实 lesson → project_rule项目规则 skill → capability_method能力/方法下一小节单独展开还有一个字段要注意recall_keywords由模型根据语义生成是这条记忆自带的检索词。召回不会用代码写死的词表——固定关键词列表换个场景就失效检索词应该从记忆本身和当前任务里长出来。session_memory.json还不是长期规则。下一步先让模型合并同义候选再由代码按证据决定是否晋升跨会话重复、工具失败证据、用户显式长期指令满足任一条才进入long_term_memory.json。任务经验层能力/方法记忆把会做的事沉淀成方法卡长期记忆不只有用户喜欢什么和项目规则是什么。系统长期运行还会积累一种更值钱的内容能力/方法记忆——它可以视作长期记忆的一类上一步的capability_method接近 CoALA 里的 procedural memory。它记录的是可复用做法不是某一次任务的结论字段含义applies_when什么场景下适用method具体步骤validation怎么确认做对了failure_signals什么现象说明这个方法失效evidence来自哪些事件比如亲子旅行不是只记用户要午休更值得留下的是一套方法按地理区域聚合景点、远距离大项单独成天、重要景点放上午、生成草案后跑路线检查、输出里附检查结论。这套方法以后不只服务同一个用户也能服务同一类任务。上一步 skill 候选只有一句话下面把它展开成完整的方法卡。心跳整理定时触发第三节的抽取管线到这里四层记忆的来源、压缩和输出已经讲清楚了。心跳机制做的事就简单很多它不是新的记忆理论而是一个后台定时任务负责在系统空闲时扫描新 raw 事件然后触发抽取、合并、晋升和 checkpoint 流程。整理不适合放在对话进行中做——用户还在等回复没人愿意每轮多花几秒钟等 Agent记笔记。更合理的位置是后台对话结束后、系统空闲时由一个定时唤醒的整理器扫描新事件、抽取值得留下的信息。这里沿用 OpenClaw 一类个人 Agent 里的叫法把这个后台触发器称为 heartbeat心跳。管线一次心跳做四件事分工原则在这条管线里落得很具体。模型负责的判断这段对话里哪几句值得长期记住两条措辞不同的候选是不是同一件事用户是不是显式说了以后都这样这些都是理解自然语言代码里写if 失败 in text这类关键词匹配是靠不住的——换个说法就漏。代码负责的判断工具返回的status是不是 failed一条候选被几个会话独立支持处理到哪条了这些是可核对的结构化事实交给模型反而引入不确定性。触发一每轮对话完成后检测。一轮对话结束时输入、模型输出、工具结果都齐了做一次轻量检测满足条件就投递整理任务。检测看的都是可计算信号不需要模型信号怎么检测新事件数当前 session 的事件数是否超过上次整理的位置上下文压力会话记录的 token 估算是否接近窗口阈值过程变化是否出现 failed tool、人工修正、用户明确说以后都这样写入锁这个 session 是否已经有整理任务在跑避免重复触发触发二定时触发。低频会话、离线导入的历史不经过对话钩子靠系统定时任务兜底。# macOS / Linux 用 crontab ,打开定时任务编辑器crontab-e# 每 15 分钟激活一次先做会话压缩再做升格。*/15 * * * *cd/path/to/Memory/.../long_term_memory.pyWindows 用 schtasks任务计划程序的命令行schtasks /Create /TNmemory_consolidation/SC MINUTE /MO15/TRcmd /c cd /d C:\path\to\Memory/.../long_term_memory.py也可以打开图形界面的任务计划程序新建任务设成每 15 分钟重复执行同一条命令。两条触发线不是二选一对话钩子抓即时信号用户修正、工具失败、上下文将满定时任务兜底低频会话和漏跑。安全提醒后台自动写记忆要留三根钉子——来源标记这条记忆从哪来、证据链接evidence 能追回原事件、可回滚写错了能定位撤销。没有这三样“自动整理会变成自动污染”心跳本体扫描 checkpoint触发文件整理步骤有了前面的整理函数之后心跳本体就简单了它不负责抽取逻辑只负责醒来、检查有没有新 raw 事件、有新事件时触发同一套整理函数、最后写回heartbeat_state.json。值得注意的是没晋升的那批“住王府井附近这类信息只出现过一次、没有失败证据、用户也没说以后都这样”——它留在 episode 里等下次证据而不是急着变成规则。晋升门槛宁紧勿松semantic 层进 prompt 的优先级最高进去一条错的以后每个任务都要为它买单。模型输出每次运行会有措辞差异但结构应该稳定跨区失败的教训走 repeated_across_sessions 或 tool_failure_evidence 通道“附检查结论”小额票直接预审这类显式交代走explicit_user_instruction 通道。心跳的安全边界自动整理不能变成自动污染心跳是后台进程它读到的内容不只有用户对话——邮件、消息、网页、仓库都可能流进来。后台写记忆这条通道如果没有治理会出安全问题而且已经有测量数据后台执行静默污染记忆的测量对 Claw 系个人 Agent 的共同架构heartbeat 后台执行和前台对话共用同一个会话与记忆通道形式化了一条 E→M→B 路径后台接触的不可信内容Exposure进入会话上下文、被例行的随手存记忆写成长期记忆Memory再在之后的前台任务里改变行为Behavior。测量结果带社交可信度包装的误导内容行为误导率最高 61%例行记忆保存把短期污染固化进长期记忆的比例最高 91%跨会话行为影响最高 76%。关键的一点不需要提示注入普通的社交谣言就够了问题出在架构不在某条恶意 prompt。后台写入必须有独立治理来源标记、证据链接、置信度、可回滚。这里管线里 source / supported_event_ids / promotion_reason 这些字段就是在给每条记忆留它凭什么在这里的答案。注意边界实验对象是个人助理形态的 Claw 生态含修复前版本数字不能直接外推到所有 Agent 架构它证明的是后台通道缺治理时污染是常态不是心跳机制不可用。心跳不是越主动越好。没有来源、没有证据、没有回滚路径的后台记忆写入会把自动整理变成自动污染新任务唤起从文件记忆构建 working memory召回记忆这个词太宽了。新任务刚开始时要召回的内容和一个任务正在执行时要召回的内容应该分开。更完整的工程实现里Workspace 可以作为主存储和上下文打包层最小实现先用文件记忆库完成召回换成 Workspace 或向量库时变的是检索后端不变的是按当前任务打包上下文这件事。新会话召回发生在新任务第一次请求模型之前回答这个新任务开始时哪些长期记忆应该进入初始上下文召回什么例子用户长期偏好带 5 岁孩子旅行下午要留午休窗口项目规则远距离大项不要和市区景点塞进同一天能力/方法记忆亲子行程先按区域聚合再跑路线检查少量相关会话摘要上次类似任务怎么失败、怎么修正它不召回整段原始聊天记录——新会话需要的是干净的上下文包不是历史流水。过程记忆召回发生在会话进行中通常被一个工具失败触发回答当前执行卡住了刚才发生过哪些状态、失败、待办需要继续带着。它的范围是当前这个会话自己的过程笔记不翻别的历史会话——跨会话的教训已经升格成长期记忆归新会话召回管。文件版实现不需要复杂 API先按project_id做项目隔离再按任务目标挑选相关 episode最后把稳定规则和候选经验打包成一个任务简报。重点在路由和边界而不是某个存储后端。文件产物让进化后的记忆能被新任务找到文件版的记忆库一共就这几个产物raw_events.jsonl保存完整事件流consolidated_sessions.jsonl保存会话摘要和候选数量candidate_memories.jsonl保存模型抽取出的候选记忆semantic_rules.jsonl保存被代码按证据晋升的稳定规则task_brief.json保存当前新任务要带入上下文的 working memory。这些文件在 notebook 里写到.demo_runs/notebook_inline/memory/。文件版的召回已经能说明问题稳定规则整批带入episode 按项目和相关性挑选raw 只在需要证据时回读。向量库解决的是“自然语言近义匹配”这一层增强extensions/chromadb_hybrid_retrieval.py给了原生 ChromaDB 示例主事实仍然留在 JSON/JSONL 文件里。模型先看当前情况生成检索关键词代码再拿关键词去匹配。过程记忆召回只取当前执行需要的状态现在换到会话进行中的场景上海行程做到一半路线检查工具又报了失败。这时候需要的不是重新加载所有长期规则而是把当前会话刚攒下的状态找回来刚失败的工具、待确认的点、刚修正过的做法。带记忆的输出应该能看出三处差异午休窗口被排进了日程、迪士尼单独占了一整天、输出附带里有检查结论的位置。验收标准很简单同一个任务带记忆和不带记忆输出有看得见的差异。上海亲子游的记忆增强对比综合案例输出同一个任务的两版草案不带记忆的draft_without_memory和带task_brief的draft_with_memory。输出 schema 里专门留了一个规则遵守字段两侧共用不带记忆的版本没有规则可遵守这个字段自然是空的带记忆的版本要逐条交代 stable_rules 怎么落实。把遵守情况做成结构化字段而不是散在文字里验收就从人眼扫一遍变成逐条核对。观察点集中在三条规则有没有生效迪士尼远距离大项有没有独占一整天而不是和市区景点混排有没有留出午休窗口、行程不塞满重点安排放在上午规则遵守字段里有没有附路线检查结论这一条的落实方式。有一点要提醒模型输出每次运行有差异个别规则靠通识也可能撞对——迪士尼独占一天就属于通识给得出的。稳定的差异来自通识给不出的那部分不带记忆的版本不会主动留午休窗口更不会知道这个用户要看检查结论。这组对照就是整条管线的验收——行为差异来自记忆而不是来自模型通识。工程边界谁负责什么谁不负责什么角色负责什么不负责什么Session当前会话历史、窗口裁剪跨任务的长期记忆治理文件记忆库raw、consolidated、semantic、task_brief 等中间产物工程级权限、索引、并发和查询优化Workspace综合案例里的工程化持久化、scope 隔离、ContextPackage四层记忆理论本身、判定某条记忆一定为真向量库扩展语义近义召回加速主事实存储、证据链、权限心跳整理器定时触发抽取、合并、晋升、checkpoint自己决定记忆理论和业务规则模型抽取、同义判断、摘要、表达独立完成记忆治理边界分开之后整套系统变成一组可替换的模块将来增加 Workspace 或向量库不影响文件产物格式换抽取模型不影响 checkpoint 和证据链调整晋升门槛不影响任务接口加安全策略不用重写业务 Agent。工程再往下走还有两个可选扩展Workspace负责持久化记录、scope 隔离和上下文包生成向量库负责语义近义召回加速。它们都不改变记忆文件格式和分工边界。记忆系统管理总结记忆不是只存起来RAG 只覆盖召回写入、修正、遗忘这三个动作决定这条记录未来该不该影响行为记忆的最小原理模型不记事记忆就是拼进这一次请求的文字整套记忆系统做的事就是自动生产和挑选这段文字Hermes 给了一个可落地参照稳定记忆小而常驻历史会话完整可查外部 Memory Provider 只做附加增强本文用文件产物把这套分工拆成四层先用文件系统跑通记忆闭环raw 只追加、consolidated 带证据、semantic 少而稳定每层治理方式不同Workspace 是工程化后端向量库只是可重建的召回副本生产靠两步压缩会话压缩摘要候选过程记忆、升格长期记忆三条通道宁紧勿松能力/方法是长期记忆的一类把会做的事沉淀成方法卡抽取靠模型治理靠代码验收看行为理解自然语言的判断交给模型可核对的结构化判断留在代码最终看同一个任务在带记忆和不带记忆时有没有可观察的行为差异。输出契约要长在.output()里字段含义、枚举范围、证据要求写进字段注释Agently 会把它们渲染进实际 prompt需要观察时可以先get_prompt_text()再执行触发分两种每轮对话完成后的轻量检测抓即时信号crontab / 任务计划程序兜底低频和漏跑激活的都是同一套压缩管线召回分两条新会话召回取跨会话的长期记忆过程召回取当前会话的临时状态两条管线都是模型生成关键词、代码稳定执行匹配