为什么“又一篇记忆型AI”值得你花时间看最近这几年AI圈每隔几天就会冒出一个新概念长上下文、RAG、Agent记忆、上下文工程、状态记忆……如果你和多数开发者一样第一反应是“这又是个包装出来的新词”那这篇文章恰恰是为你写的。这次讨论的主题是标题里提到的MIRaS——一类围绕 memory-based AI基于记忆的人工智能构建的系统方案。从材料看它在本周被公开发布或公示名字本身还没有被统一翻译成中文但这并不妨碍我们把它当做一个值得拆解的技术信号来看。真正重要的不是“MIRaS”这个缩写本身而是它背后代表的一整类技术路线把记忆从模型的“隐式能力”中拆出来变成显式的、可配置的、可检索的、可评估的工程组件。如果你正在做 AI 应用开发、Agent 开发、RAG 系统集成或者你只是被“AI 老是忘事”折磨过那么这一篇会告诉你三层东西第一MIRaS 这类 memory-based AI 到底改变了什么第二它和现有方案上下文窗口、RAG、长期记忆、向量库是什么关系第三你自己动手做一个最小可用的记忆系统要分几步哪些环节最容易翻车。1. 这篇文章真正要解决的问题1.1 为什么“AI 没有记忆”会成为工程瓶颈先抛一个判断当前大模型应用的最大瓶颈不是模型不够聪明而是模型没有稳定的记忆。你可能已经注意到了现在的模型在单轮对话里表现得非常惊艳但一旦进入多轮、跨天的复杂任务问题就密集出现上午和用户确认了数据库表结构下午再问同一个问题时模型已经“忘了”。Agent 在执行一个多步骤任务时前一步的结果没有传给下一步导致流程断裂。每次对话都重复解释需求用户耐心被耗尽。长文档明明截断后也能生成但生成结果经常前后矛盾。传统解法是“把上下文塞进提示词”。上下文窗口不够就拼 RAGRAG 不够就再上向量库。但这条路在工程上有一个明显的天花板token 成本越来越高检索噪声越来越多用户真正关心的历史决策、偏好、业务约束却被淹没在海量文本里。1.2 MIRaS 代表的是一种架构转向MIRaS 这类的 memory-based AI 方案核心转变在于不再把“记忆”当成模型内部的一个隐藏功能而是把它当成系统的显式组成部分。你可以把它理解为模型还是那个会思考的“大脑”但 MIRaS 给大脑配了一个“笔记本”——这个笔记本可以写入、检索、更新、过期并且每次生成都先翻笔记本再开口说话。这个转向意味着三件开发者会非常关心的事情记忆可以被审计哪条记忆被用到了哪条没用到不再黑盒。记忆可以被治理可以设置生命周期、权限、去重策略、优先级。记忆可以脱离模型升级底层模型换了记忆资产不用重建。1.3 谁最需要读这篇文章正在做 AI 应用开发的工程师需要了解记忆组件的架构选型边界。对 Agent 开发感兴趣的技术人需要理解记忆系统与工具调用、任务规划的关系。架构师和技术负责人需要判断“要不要把记忆层当成独立服务来建设”。初学者可以从一个最小原型里理解“记忆检索-注入-生成”到底是怎么回事。2. MIRaS 这类记忆型 AI 的核心概念2.1 什么是 MIRaS先做术语澄清。MIRaS 在标题语境中代表某种“memory-based AI”的新方案但我们目前看到的信息里它还没有形成像“Transformer”那样明确的公开定义。更稳妥的理解是MIRaS 是一种概括性指代用来描述近期出现的、以显式记忆为系统核心的 AI 架构方案。不同团队的实现方式可能不同但共同点都是——把记忆从模型的隐层参数中抽离出来放到一个可操作的外部存储和调度层中。这也意味着当你和别人讨论 MIRaS 时讨论的其实不是“某个模型有多强”而是“这个系统怎么处理记忆的写入、存储、检索和刷新”。2.2 Memory-based AI 的五个组成模块一个典型的 memory-based AI 系统通常包含以下模块模块作用类比记忆写入层从对话、操作记录、外部数据中提取需要记住的信息人脑的编码过程记忆存储层保存结构化或非结构化的历史信息笔记本/档案柜记忆检索层根据当前上下文召回最相关的记忆片段翻笔记本找关键页记忆排序与过滤层去掉噪声、重复、过期信息整理笔记生成注入层将筛选后的记忆拼装进上下文供模型生成拿着笔记开口说话这里有一个很多教程没点透的关键点记忆系统的质量很大程度上取决于“写入层”和“过滤层”而不是“检索层”。如果你把大量无意义对话全部写入记忆库再强大的检索算法也无法从垃圾里捞到金矿。MIRaS 这类系统真正的门槛在于如何决定什么值得记住什么应该遗忘。2.3 容易混淆的概念对比上下文窗口Context Window模型每次生成时能看到的 token 上限属于“短期工作台”。RAG检索增强生成从外部知识库检索文本块注入上下文。但通常只解决“知识缺失”问题不解决“历史状态问题”。Agent Memory通常指 Agent 在多步操作中记录中间状态和工作结果更偏任务临时状态。Memory-based AIMIRaS 所在类别把长期记忆、用户偏好、历史决策作为一等公民建立独立的记忆生命周期管理体系。可以这样理解RAG 是“查资料”Agent Memory 是“便利贴”Memory-based AI 是“个人档案系统”。这四者未来大概率会融合但当前阶段架构上的分工仍然清晰。3. 传统方案与 Memory-based 方案的关键差异如果用一句话概括差异传统方案把“记忆”当成本文里的上下文来“塞”Memory-based 方案把“记忆”当成系统中的“状态”来“管”。可以用一个表格做对比维度上下文窗口方案传统 RAG 方案MIRaS 类 Memory-based AI记忆载体模型输入 token外部文档块独立记忆条目记忆粒度无差别文本文本块事件、事实、偏好、状态更新机制每次重新拼接建库后定期更新实时写入持续刷新可追溯性弱中强成本随长度线性增长中等前期较高但可分层典型场景单轮高质量回复文档问答长期用户代理、复杂 Agent从工程视角看MIRaS 类方案真正改变的是“状态管理”这件事。传统的大模型应用没有状态层所以开发者只能用会话 ID、Redis、临时变量硬凑。而记忆型 AI 把状态集中化地交给记忆系统模型每次只负责“读 写 生成”这在架构上是一个清晰的解耦。但这里必须说明边界RAG 不会因为记忆型 AI 的出现而消失。知识问答、企业文档检索、非结构化信息召回依然是 RAG 的强项。MIRaS 更适合的是“人设一致性”、“用户偏好记忆”、“长期任务推进”这类场景。二者不是替代关系而是互补关系。4. 自己动手前要先理解记忆系统的分层设计在写代码之前先建立一个分层心智模型。一个可落地的记忆系统从底到上大致是四层原始记忆层保存原始对话、事件、文档。这层不追求结构化只保证不丢原始信息。精炼记忆层把原始记忆提炼成结构化条目比如“用户偏好-对数据库索引设计有较强要求”。工作记忆层当前会话需要立即使用的记忆片段通常是调度器从精炼层里临时取出来的。记忆策略层决定何时写入、何时检索、何时合并、何时过期。很多团队做记忆系统失败不是因为向量数据库选得不对而是直接把一坨原始文本扔进去检索时再把一堆噪声文本灌给模型。这既有成本问题也有生成质量问题。更合理的路径是在写入时做信息抽取和去重在检索时做过滤和排序在生成时做注入量控制。接下来我们用 Python 实践一个最小可验证的 memory-based 流程。为避免引入过重依赖这里只使用标准库和一些轻量处理方式重点演示链路。5. 最小实现从一段对话到可检索记忆我们先实现第一个功能把一段对话文本写入一个 JSON 记忆库并支持按关键词和标签检索。5.1 先约定“记忆条目”的结构记忆条目不要设计成一段纯文本。一次对话可能包含多个可记忆的元素比如用户提出的约束、确认过的方案、待办事项。可以用一个简单结构来定义# memory_item.py from dataclasses import dataclass, asdict from datetime import datetime, timezone import uuid dataclass class MemoryItem: memory_id: str content: str # 记忆正文比如“用户要求使用 PostgreSQL 15” category: str # fact / preference / task / status tags: list[str] # 用于快速检索 created_at: str updated_at: str staticmethod def create(content: str, category: str fact, tags: list[str] | None None): now datetime.now(timezone.utc).isoformat() return MemoryItem( memory_iduuid.uuid4().hex, contentcontent, categorycategory, tagstags or [], created_atnow, updated_atnow, ) def to_dict(self): return asdict(self)这段代码定义了一个最小的记忆条目模型。content是记忆本身category用来区分事实、偏好、任务、状态tags给检索提供一个轻量索引。这里不需要复杂的 ORM一个 dataclass 足够说明问题。5.2 实现一个轻量记忆仓库接下来是记忆存储与检索能力。为了保持演示可运行这里用 JSON 文件存储核心逻辑是写入、读取、按标签检索、简单关键词匹配。生产环境可以替换为向量数据库或关系数据库但接口逻辑是相通的。# memory_store.py import json from pathlib import Path from typing import Optional from memory_item import MemoryItem class MemoryStore: 一个极简的 JSON 记忆仓库用于演示 memory-based AI 的基本链路。 def __init__(self, path: str memory.json): self.path Path(path) if not self.path.exists(): self._save({items: []}) def _load(self) - dict: with open(self.path, r, encodingutf-8) as f: return json.load(f) def _save(self, data: dict): with open(self.path, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def add(self, item: MemoryItem): data self._load() data[items].append(item.to_dict()) self._save(data) def get_by_id(self, memory_id: str) - Optional[dict]: data self._load() for item in data[items]: if item[memory_id] memory_id: return item return None def search(self, keyword: str , category: str , tags: list[str] | None None): data self._load() tags tags or [] results [] for item in data[items]: if category and item[category] ! category: continue if tags and not set(tags).issubset(set(item[tags])): continue if keyword and keyword.lower() not in item[content].lower(): continue results.append(item) return results这段代码几乎是“没有技术含量”的存储代码但它构成了记忆系统的基础。关键点不是存储本身而是在写入之前你要决定存什么。5.3 演示写入几条记忆并检索python -c from memory_item import MemoryItem from memory_store import MemoryStore store MemoryStore(demo_memory.json) store.add(MemoryItem.create( 用户要求所有新项目默认使用 PostgreSQL并且需要启用行级安全策略, categorypreference, tags[database, postgres, security] )) store.add(MemoryItem.create( 项目 Alpha 预计在月底发布当前处于接口联调阶段, categorystatus, tags[project-alpha, release] )) results store.search(keywordPostgreSQL) for r in results: print(r[content]) print(---) results store.search(tags[release]) for r in results: print(r[content]) 预期输出是用户要求所有新项目默认使用 PostgreSQL并且需要启用行级安全策略 --- 项目 Alpha 预计在月底发布当前处于接口联调阶段如果你能跑出这些结果说明你已经完成了一个最原始的“写入—存储—检索”记忆闭环。虽然它还非常简陋但后续所有复杂功能——向量召回、记忆合并、记忆过期——都可以在这个结构上生长出来。6. 完整链路检索 → 注入 → 生成 → 更新现在把记忆系统接入 LLM 调用链路。这个过程是 MIRaS 类方案中最核心的工程模式我称之为“先翻笔记再开口”。6.1 设计一个记忆增强的生成函数# memory_llm.py import os from memory_item import MemoryItem from memory_store import MemoryStore def build_prompt_with_memory(query: str, memory_items: list[dict]) - str: if not memory_items: return f用户问题{query}\n\n请直接回答。 memory_block \n.join( f- [{item[category]}] {item[content]} for item in memory_items ) prompt f以下是这个用户已知的历史信息和偏好请基于这些信息回答当前问题。 历史记忆 {memory_block} 用户问题{query} return prompt def generate_with_memory( query: str, store: MemoryStore, llm_callNone, top_k: int 3, ): # 第 1 步检索相关记忆 memory_items store.search(keywordquery)[:top_k] # 第 2 步生成带记忆的 prompt prompt build_prompt_with_memory(query, memory_items) # 第 3 步调用底层模型这里用回调函数抽象不绑定具体厂商 if llm_call is None: print([未配置真实 LLM以下是将要发送的 Prompt]) print(prompt) return prompt response llm_call(prompt) # 第 4 步将新的对话内容写入记忆真实项目中需要信息抽取 new_memory MemoryItem.create( contentf用户询问{query}系统给出的答复已基于历史偏好。, categoryfact, tags[conversation-log], ) store.add(new_memory) return response关键逻辑在build_prompt_with_memory里我们不是把全部记忆塞进提示词而是先做检索只取top_k条相关记忆。这一步直接决定了 token 成本和生成质量。6.2 用模拟回调验证链路# run_demo.py from memory_item import MemoryItem from memory_store import MemoryStore from memory_llm import generate_with_memory store MemoryStore(demo2_memory.json) # 先写入测试记忆 store.add(MemoryItem.create( 用户当前项目使用 Java 17 和 Spring Boot 3.x, categoryfact, tags[java, spring-boot], )) store.add(MemoryItem.create( 用户不太喜欢过度设计的架构更倾向简单清晰的方案, categorypreference, tags[architecture, style], )) # 模拟一次带记忆的询问 def fake_llm(prompt: str) - str: return [模拟回复] 会推荐使用 Spring Boot 3 的标准结构并结合简单清晰的设计思路。 response generate_with_memory( query我应该怎么给我的 Spring Boot 项目做架构设计, storestore, llm_callfake_llm, top_k2, ) print(最终生成, response)运行这个脚本你会看到模型这里是模拟的在生成回复前已经拿到了两条关于用户技术栈和架构偏好的记忆。这就是 memory-based AI 和普通上下文填充的本质区别生成质量不是靠模型“想起什么”而是靠记忆系统“给到了什么”。6.3 为什么不直接拼接全部历史直接拼接全部历史的问题在于成本高。长对话窗口每次都要重复计费。噪声多。大量无关记忆会稀释模型对重点信息的注意力。冲突多。旧记忆和新状态同时出现模型优先采信哪一条不可控。MIRaS 类方案要在前面的检索和过滤阶段解决问题而不是把难题留给模型。7. 运行验证怎么确认记忆系统真的生效代码能跑通不等于记忆系统在真实业务中生效。需要一个验证清单。7.1 正确性验证检查项测试方式通过标准记忆写入调用 add 后查看 JSON 文件新条目以结构化格式落盘记忆检索用关键词/标签搜索能返回预期条目且排除不相关条目记忆注入检查 build_prompt 生成的 prompt历史记忆出现在提示词中且顺序稳定生成引用查看模型回复是否体现记忆中的信息回复中包含用户的偏好、约束或事实记忆更新修改条目后再次检索查询结果返回的是最新版本7.2 效果验证效果层面建议观察两个指标记忆命中率在 100 次真实用户请求中有多少次检索层返回了相关记忆。命中率低说明写入层提取的信息质量不高或者用户的询问与历史记录表达差异太大。信息一致性表现对比关掉记忆系统和开启记忆系统时模型对“用户偏好”类问题的回复是否保持一致。如果模型仍然频繁遗忘用户之前说过的关键约束第一个要检查的不是模型参数而是写入层有没有把约束转成可检索的记忆条目。这是 MIRaS 类系统最容易踩的坑。8. 常见问题与排查思路问题现象可能原因排查方式解决方案检索结果与当前问题无关写入层缺少信息抽取原始文本噪声大打印检索命中的原始文本增加信息抽取与记忆精炼环节prompt 过长导致生成变慢注入的记忆过多统计单次注入的记忆条数和 token 量调低 top_k增加相关度阈值旧记忆覆盖新记忆更新策略未定义版本检查 memory_id 是否复用保留历史版本增加 updated_at 时间戳比较重复记录大量相同偏好写入层没有做去重打印同 content 的记忆数量写入前先按相似度检索合并或跳过多轮对话后记忆混乱工作记忆和长期记忆混用检查会话隔离逻辑区分会话级记忆和用户级长期记忆模型忽略记忆中的约束记忆放在 prompt 尾部被注意力稀释检查组卷顺序把关键约束放在更靠近问题处或增加显式提示9. 工程实践从 Demo 到生产落地很多人跑通 Demo 之后会误以为“记忆系统已经搞定了”。实际上从 Demo 到生产环境之间还有几道明显的坎。9.1 先分清记忆的层级生产级系统至少需要区分三类记忆用户级长期记忆用户的身份、偏好、领域背景跨会话保留。会话级工作记忆当前会话中的临时状态比如正在处理的步骤、用户刚刚给出的指令。任务级执行记忆Agent 在执行多步任务时产生的中间结果。不要把三类记忆存到同一个桶里。否则会出现一个很尴尬的场景用户只是换了个话题系统却把上一次任务里的中间结果当成了长期偏好。9.2 记忆需要治理而不是只增不减在真实项目中记忆库是持续膨胀的。需要有记忆去重同一信息反复出现时合并成一条而不是重复记录。记忆过期策略TTL有些状态型记忆有明确生命周期比如“项目 Alpha 月底发布”发布后就该归档。记忆优先级事实型记忆和偏好型记忆的权重应该不同。用户明确说“我不喜欢 X”可能比“曾经用过 X”的优先级更高。记忆审计记录哪条记忆影响过哪次回复方便排错和合规追溯。9.3 安全与权限边界记忆系统存的是用户敏感数据必须注意对记忆内容做脱敏处理不保存明文密码、令牌、银行卡信息。设置记忆的访问控制不同角色只能读取授权范围内的记忆。提供“查看我的记忆”和“删除我的记忆”入口这是隐私合规的基本要求。在生产环境启用审计日志记录谁在什么时候读取了哪条记忆。这里特别提醒任何涉及用户数据的记忆系统上线前都必须经过安全评估确保有合法授权和完整的数据管理流程。9.4 成本与性能优化检索阶段可以用便宜的嵌入模型生成阶段再用更强的模型分层降低成本。给记忆按时间窗口分片定期把冷数据从高成本存储归档到低成本存储。对高频查询做缓存不必每次刷新都从记忆库全量检索。用成熟观测工具跟踪每次生成的“记忆命中率”和“记忆注入 token 数”。9.5 团队协作流程记忆条目结构定义好之后团队内部要当作接口契约来维护。新增记忆类别时走评审流程避免每个人自由定义 tags。每次升级底层 LLM 时单独跑一轮记忆系统回归测试确认模型在带记忆时不会产生新的冲突。10. 总结与后续可以继续深入的方向MIRaS 这周被推出背后传递的技术信号其实很清晰大模型应用已经开始从“看上下文生长”切换到“主动管理状态”的阶段。对开发者来说这不是一个需要立刻追的噱头而是一个值得马上着手理解并实验的架构方向。本文真正想讲清楚的是memory-based AI 不是“多了一个记忆功能”而是“增加了一个显式的记忆管理层”。它把模型的上下文能力、外部存储的持久化能力和业务的状态管理能力拆开了。拆开之后每部分都能独立优化、独立测试、独立维护。这件事放到工程上价值是非常大的。如果你是第一次接触这个方向不用急着搭建一个庞大的向量记忆平台。先把你手里的一个简单对话应用改造一下加入一个“先检索——再注入——后生成”的流程再看看效果是否有提升。任何复杂的记忆系统起点都是这一条链路。后续值得深入研究的方向包括记忆条目的自动抽取与更新、记忆冲突检测、长期记忆与多 Agent 之间的共享与隔离、记忆系统的评估基准设计。这四个方向都有很强的研究空间和工程应用价值也正好是很多团队明年会遇到的核心问题。建议收藏备用等真正做 AI 应用的状态管理时翻出来对照着用。