企业官网建设流程全解析

这周公开的 MIRaS，被直接定义成“A new class of memory-based AI”。看到这个标题时，我刚好结束一个连续问答服务的调优，脑子里全是“模型又忘了上次怎么说”的抱怨。过去几周，我们一直在为“让AI记住项目背景”这件事做各种尝试，试过把上下文拼长、试过临时查向量库、试过把关键信息塞进提示词，最后发现这些办法都只解决了一半问题：它们能短暂记住，但没法持续形成记忆。MIRaS 这个新成果让“memory-based AI”这个方向又一次回到我的工作台。我更愿意把它看作一个信号：记忆正在从AI系统的附属功能，变成真正值得单独设计的核心机制。

1. 先搞清楚MIRaS解决的是哪一类问题

1.1 不是“更大的上下文”，而是“跨会话的记忆”

很多人第一次看到“记忆型AI”，第一反应是“这不就是上下文更长的聊天机器人吗”。实际差别很大。上下文窗口解决的是“一次对话里能容纳多少信息”，记忆系统解决的是“这次聊完，下次还能不能想起来”。

MIRaS 被归入 memory-based AI 这个类别，核心指向就是后者。它关心的是跨会话、跨任务、甚至跨天的状态保持。举个例子：你让AI帮你整理一份月度复盘，过程中提到了几个关键口径，比如“收入按回款口径计算”“增长率只看同比”。如果只是普通聊天，第二轮对话一关，这些信息就没了。下次再问，AI又会问“收入口径是什么”。这不是能力不行，而是它没有“记下来”的机制。

上下文窗口更像一张临时便签，对话结束就作废。记忆系统像一本可以长期保存的笔记本，不只是能写，还能翻。MIRaS 这类方案想做的，就是把这本笔记本变成AI工作流里的一等公民，而不是每次临时拼凑。

1.2 记忆型AI的核心能力：写入、读取、更新、遗忘

如果把“记忆”当成一个系统来拆，它的能力可以分成四块：

• 写入：从当前对话或任务中，提取值得保存的信息。
• 读取：在后续任务中，按需找到相关记忆。
• 更新：当新信息与旧记忆冲突时，合并、覆盖或修正。
• 遗忘：对于过期、错误、敏感的记忆，能主动淘汰或删除。

这四件事看起来简单，真正做到位却很难。写入太激进，会把无关信息都存下来，导致记忆噪声很大；读取不准，反而会把一段错误记忆捞出来干扰模型；更新不及时，用户改了口，系统还在沿用旧偏好；遗忘做不到，用户隐私和记忆污染问题就不可避免。

MIRaS 作为一类新方案，真正的挑战不是“存得多”，而是把这四个动作组织成一个稳定循环。它不能只是“能存能取”，还要知道什么时候该记、什么时候该忘，以及用哪条记忆来生成当前回答。

1.3 为什么它被称为“新一类”

传统做法里，记忆往往是“外挂”的：模型先回答问题，对话结束后把中间内容存到数据库，下次再用检索工具翻回来。这种模式的问题在于，记忆和推理是两条线，记忆最多是个参考资料。

记忆型AI 的设计思路则更激进：把记忆作为模型推理过程的一部分，甚至让记忆决定“模型应该先看什么、再看什么”。在这个模式下，模型不再是每次从零开始理解问题，而是先调用一段连续的状态，再基于这段状态作答。MIRaS 之所以被说成“new class”，大概率就是因为它在机制上不再把记忆当作缓存或日志，而是当作系统判断的依据。

这个转变听起来抽象，落到产品上非常具体：未来一个AI助手是否好用，可能不取决于它调用的模型有多大，而取决于它能不能准确记住“你是谁、你做过什么、你接下来打算怎么做”。

2. 为什么“记忆”成为AI系统的关键瓶颈

2.1 固定上下文窗口的边界

这些年上下文窗口一直在变长，从几千 token 到几十万、上百万。但窗口变大不等于记忆变好。工程上，把大量历史内容直接塞进提示词，会带来三个问题：成本上升、延迟变高、噪声增多。

更麻烦的是，模型在很长的上下文里容易出现“中间遗忘”现象。数据太多时，即使相关信息都在窗口里，模型也不一定能在合适的时机命中它们。换句话说，上下文窗口不是没有装下信息，而是缺少一个“主动翻笔记”的机制。记忆型AI 补的正是这个机制：不追求把所有历史都放进窗口，而是按当前问题，只把最相关的一小段记忆拿出来用。

2.2 大模型本身没有持久化记忆

很多人误以为大模型既然能回答问题，就一定有“记住”的能力。实际上，模型参数训练完之后就固定了，它不会因为你调用过一次而改变。对话中的“记住”只是临时上下文里的状态，会话结束就消失。模型本身是一个无状态的推理引擎。

无状态在单次问答里没问题，但一旦进入需要长期协作的场景，就非常难受。你可以把大模型想象成一个特别聪明、但每次都会被清空笔记的实习生：他很有能力，可每次都得重新交代背景。MIRaS 这类方案，本质上是给这个实习生配了一本可持续维护的笔记本，并且教会了他什么时候看哪一页。

2.3 从一次性问答到长期协作，记忆变成结构性需求

现在AI的使用方式正在从“问一个问题”变成“一起做一件事”。做个人助理，要记住用户偏好；做编程助手，要记住项目结构和历史决策；做客服，要记住用户过往的订单和投诉记录；做研究助手，要记住文献之间的联系和推理过程。

这些场景共同的特点是：单次回答是否精彩已经不是唯一标准，“不用重复交代”成了体验的关键。如果一个AI能记住昨天讨论过的方案，今天直接接着往下推理，用户会有非常强的省力感。反过来，如果每次都从头开始，用户很快就会失去耐心。

这不是一个锦上添花的功能，而是长期协作能否成立的基础设施。MIRaS 被当作一个新的类别来提，说明记忆问题已经被摆到了和“模型能力”“算法效果”同等重要的位置。

3. MIRaS与RAG、长上下文、向量数据库有什么本质区别

3.1 它更像系统设计，而不是检索工具

过去一提到给AI加记忆，很多人第一反应是RAG。RAG 解决的是“模型不知道某些知识时，从一个外部库里检索相关内容”。它的目标很明确：扩大模型的知识范围。但知识是相对静态的，文档写完之后不会自己变化。

记忆型AI 面对的不是静态知识，而是动态状态。它要存储“上一次我们讨论到哪一步了”“这个用户更偏好哪种表达方式”“这个项目为什么从方案A切到了方案C”。这些信息带有时间、来源、变化轨迹，不能简单当成一堆文档来检索。MIRaS 要处理的更像是系统里的状态管理：什么时候写入、什么时候覆盖、什么时候读取，都需要一个完整设计。

3.2 与RAG：从“查资料”到“调用经验”

RAG 和 memory-based AI 的关键区别，可以从一个例子看出来。假设你问：“为什么我们最终选了这套数据库方案？”RAG 能帮你检索到方案选型的文档，但它不知道你们当时讨论过哪些备选、中途因为成本调整过几次、最后是基于什么理由拍板的。这些是“经验”，不是“资料”。

记忆型AI 要保存的正是这段经验脉络。它不只是返回一份相关文档，而是把“当时怎么想、后来怎么改、下一步怎么办”组织起来，作为当前推理的背景。所以，RAG 更像“临时查资料”，MIRaS 这类方案更像“调用长期积累的经验”。

这里放一个对比表，方便理解：

当然，两者不是互斥的。实际产品里可以同时使用：RAG 负责补充知识，记忆系统负责维护状态。但设计时不能混为一谈，否则会把记忆问题简化成“加一个向量库”，最后发现只解决了一小半。

3.3 与长上下文：从“塞进窗口”到“按需组织”

把长上下文当成记忆工具，是最自然也最偷懒的思路。很多产品直接把历史对话全部拼进提示词，看起来像是“记住了”。但这种方式就像把一整年写的笔记全部摊在桌子上，而不是先翻到需要的那一页。

上下文越长，模型需要处理的信息越多，注意力就越容易被无关内容分散。即使相关记忆确实在窗口里，也可能因为排在很后面，被模型忽略了。这样不仅效果不好，成本也高。

记忆型AI 的方法更接近“按需组织”：先根据当前问题，从记忆库里调出最相关的一批条目，再把这些条目组合成一段精简的上下文。关键不在“存得下”，而在“取得好”。如果检索准确，哪怕最终模型看到的上下文很短，效果也可能比塞一大堆历史更好。

3.4 与向量数据库：记忆不只是embedding，还有结构和生命周期

向量数据库解决了“相似内容怎么快速找到”的问题。你可以把记忆片段转成向量，用余弦相似度做召回。但记忆如果只被当成向量，会遇到几个问题：

• 时效性：昨天的记忆和去年的记忆，重要程度一样吗？向量相似度回答不了。
• 冲突：用户上个月说“喜欢简短回答”，这个月改成了“希望详细一点”。两条记忆都存着，召回哪一条？
• 来源：一条记忆是用户明确说的，还是模型自己推测的？它的可信度如何？

MIRaS 这类方案需要在这些维度上做更多设计。简单说，向量库只是记忆系统里的一个检索组件，真正的记忆还要带结构、带时间戳、带信任度、带更新规则。没有这些，“记忆”就只是一堆相似文本，反而会造成干扰。

4. 如果我要用这类方案，应该怎么落地和评估

4.1 一个可复用的五步评估框架

如果你是第一次接触 memory-based AI，不要急着把复杂架构堆上去。我建议先用一个五步框架来评估和验证：

如果现在只验证一个维度，我会优先选“检索”。因为记忆系统的价值最终体现在“该想起来的时候能想起来”。写入再完整，检索不到也白搭。检索准了，其他问题还可以后续慢慢补。

4.2 最小实验流程：从单条记忆到多轮对话

想快速验证一个记忆型AI流程，不用一上来就搭完整平台。可以做这样的最小实验：先让AI进入一段对话，从对话里提取一个明确事实，比如“用户偏好用列表回复”。把这个事实保存到外部存储。然后再发起一个新对话，先检索出这条事实，拼进提示词，再看模型输出会不会改变。

这里给一个伪代码结构，算是常见写法：

# 伪代码：最小记忆型AI流程 def build_memory_from_dialog(dialog): # 从对话中提取关键信息 facts = extract_facts(dialog) for fact in facts: memory_store.save(fact) def answer(user_id, question): # 先读取当前用户的相关记忆 memory = memory_store.retrieve(user_id, question) # 把记忆和当前问题一起组装成上下文 prompt = compose_prompt(memory, question) # 再调用模型生成 return model.generate(prompt)

这个流程虽然简单，但它把“写入记忆”和“读取记忆”两个动作拆开了。先跑通单条记忆，再扩展到多轮对话、多条记忆、记忆冲突处理。一上来就做复杂方案，很容易在调试时分不清是模型问题还是记忆问题。

4.3 常见坑点：记忆污染、陈旧记忆、权限问题

memory-based AI 的坑，往往不在“存”和“取”，而在“存错”和“取到不该取的”。

• 记忆污染：模型在提取记忆时，可能把一句随口玩笑当成确定偏好。一旦写入，后面每次都会按这个错误偏好回答。缓解思路是给记忆加置信度，低置信度不写入；或者定期要求用户确认。
• 陈旧记忆：用户已经改变了使用习惯，但系统还在沿用旧规则。比如用户以前喜欢简短回复，现在希望看到详细分析，旧记忆没有更新，导致新请求一直被干扰。缓解思路是给记忆加时间戳，检索时优先近期内容；同时提供用户手动删除入口。
• 权限问题：在多用户系统中，如果记忆是全局共享的，A用户的历史记录可能被B用户无意间触发。这是隐私层面最严重的问题。缓解思路很直接：按用户ID隔离，无特殊需求不查他人记忆；敏感信息单独加密。

这些问题不是模型能自己解决的，需要在系统设计层面做约束。记忆型AI 越强，“记错”的副作用就越大。这也是为什么我一直强调，不能只看记忆的准确性，还要看它的治理能力。

4.4 排查链路：输出不准时先查哪一层

如果已经接入了记忆型AI，但输出仍然不符合预期，不要马上调模型参数。按下面顺序逐层排查：

1. 写入层：原始信息有没有被正确提取并保存？检查日志里是否出现了一条完整、正确的记忆记录。
2. 检索层：相关记忆有没有被召回？排序是否合理？可以手动查看检索结果，确认命中的是不是真正相关的那条。
3. 组装层：记忆有没有被组装进最终提示词？措辞是否清晰？如果记忆和当前问题冲突，模型可能会犯错。
4. 模型层：在给定正确记忆的前提下，模型是否理解任务？可以临时把记忆写死在提示词里，看输出是否正常。
5. 更新层：训练数据或用户偏好是否已经变化，但记忆没有更新？检查记忆更新时间戳，确认是否有更近的新记录被覆盖。

这个顺序的核心是“先外部，后模型”。大多数情况下，问题出在记忆写入或检索环节，而不是模型不行。养成这个排查习惯，能让调试效率高很多。

5. 长期来看，记忆型AI会改变什么

5.1 从“通用助手”到“长期伙伴”

当AI真的能记住用户偏好、项目背景、历史决策，交互方式会发生本质变化。最明显的一点是：用户不再需要每次都解释“我是谁、我在做什么”，而是可以直接延续上次的讨论。这会让AI看起来更像一个长期参与工作的同事，而不是一个每次都失忆的工具。

这种变化带来的不仅是方便，还有信任。当用户发现AI记得自己上一次不喜欢某个方案、记得自己更倾向于哪种表达方式，会更容易把更重要的事情交给它。长期协作的价值，在于用户不需要每次重新建立上下文，这种积累本身就是效率。

5.2 记忆将成为产品差异化入口

模型能力会越来越趋同，底层模型的差距会缩小。那时候，真正拉开体验差距的，可能不是“谁的模型更强”，而是“谁更懂你”。记忆层会成为产品竞争力的重要来源。

两个产品用同一个模型，一个能记住用户的项目背景和偏好，另一个每次从零开始。用户会选择哪个，几乎不用犹豫。在这个意义上，MIRaS 这类 memory-based AI 不只是技术方案，也会成为产品设计的核心变量。谁能把记忆管理得又准又安全，谁就能沉淀出更强的用户粘性。

但这也意味着，记忆不是“存了就完事”。它需要配套的用户控制能力：查看AI记住了什么、删除某条记忆、关闭记忆功能。随着记忆能力增强，用户对透明度的要求也会同步提高。

5.3 需要警惕的边界：隐私、可控性、不透明

记忆型AI 最大的风险，不是模型能力不够，而是“记得太多、太深、太隐蔽”。如果系统长期保存用户对话，却没有清晰的使用边界，用户很容易产生不安。产品设计必须给用户明确的控制权：记忆能否被查看、被删除、被关闭；哪些信息会被写入记忆；记忆在什么场景下会被调用。

还要考虑可审计性。当模型基于某段记忆做出回答时，这段记忆应该是可追溯的。如果用户问“你为什么这么判断”，系统至少能解释自己调用了哪几条记忆。否则，AI 会变成一个“有记忆的黑箱”，越想帮忙，越难被信任。

MIRaS 这类新方案要走得更远，不仅要在记忆能力上做出突破，还要在记忆治理上提供答案。技术能力解决“能不能记住”，治理能力解决“该不该记住”。后者会决定这项技术最终能走多远。

回头看这周发布的 MIRaS，我不确定它内部用了什么样的具体架构，也不确定它是否能稳定超越现有方案。但从“A new class of memory-based AI”这个定位来看，它至少代表了一个明确的判断：记忆，不应该只是上下文窗口的附属品。它值得被当作一个独立的、有生命周期的系统来设计。

如果你也想在真实项目里引入类似能力，我建议从最小记忆闭环开始：先定义要记住什么，再写一个简单的提取和读取流程，跑通之后再考虑管理、安全和扩容。单次跑通只是起点，真正难的是让记忆在长期使用里保持准确、新鲜和安全。但这个方向，值得花时间。