AI 长期记忆系统：HKSoka 的架构设计与工程细节

四层记忆架构、命题级切块、双语嵌入到对话生命周期管理——完整的工程拆解

大型语言模型的对话有一个常见限制：每次开新对话，上下文就重置，用户需要重新交代背景。HKSoka 是一个支持繁体中文、简体中文与英文的 AI 平台，把「记忆」当成核心工程问题拆解：不只是「记不记得」，而是什么时候记、记什么、记了之后怎样取回、用户能否亲手修正。以下逐层拆解这套系统的设计，由概念到实现细节。

一、记忆系统：四个组成部分

记忆分成四个部分，各自负责不同的时间尺度，用户可以逐项掌控。

1.1 种子记忆（Seed Memory）

用户主动放入的长期背景。可以把任何文字粘贴成一个具名的「种子」，也可以上传长文件（25 页以上）一并整合，无需额外创建Project。

创建与切换：每个种子内容会完整保存，同时另外切块、嵌入向量供检索使用——保存的是完整版本，检索取回的是切片。每个种子都能逐一开关，按不同对话的需要决定是否带入，互不干扰，用户可以同时管理多份背景而无需整批启用或停用。

编辑即重新索引：修改一个种子的内容后，系统会先清除这个种子旧有的检索片段，再用新内容重新切块与嵌入。完整内容与可检索片段因此保持同步，不会出现「保存了新版本，但检索仍取回旧版本」的落差。

删除即连带清除：删除一个种子，连带的检索片段会一并移除。

1.2 学习记忆（Learned Memory）

在对话闲置一段时间后自动产生，系统从对话中提取稳定、与用户相关的事实，逐条记录。

触发时机分两种：一般对话在闲置一段时间后才处理；如果用户账号完全未有任何学习记忆，闲置门槛会大幅缩短，让新用户较快感受到系统记住了之前说过的内容。后台处理本身采用小批次、分批执行的方式，避免单次处理量暴增拖慢整体系统。

提取原则严格：只提取稳定、属于用户个人的事实，略过临时性或单次对话才有意义的内容；同一件事只记一次，新一轮提取会先比对已有记忆，避免重复累积近乎相同的条目；用字尽量贴近用户原话，不做主观诠释或过度推论。

遗忘会被尊重：用户删除一条学习记忆后，那个主题会被加入排除清单；之后的自动提取会被明确告知不要再记录类似内容。换言之删除不是一次性的移除，而是一条持续生效的指示，避免同一件事在下一次对话又被重新提取出来。

1.3 关键记忆（Critical Memory）

每日定时把学习记忆整理成一份精简摘要，并在每次对话中固定带入，不经过筛选步骤。

筛选标准明确：判断一条信息是否值得提升为关键记忆，依据三个准则——用户会否因为 AI 忘记这件事而受到实质影响、这是否属于稳定的事实而非一时的意见、忘记了会否导致 AI 给出错误或不合宜的回应。只有同时符合的内容才会被纳入。

执行时机刻意错开：整理工作安排在固定的低流量时段执行，每次只处理学习记忆在过去一日内有更新、但尚未在最近一小时内处理过的用户，避免同一用户在短时间内被重复整理。

注入方式有别于其他记忆：种子记忆与学习记忆要靠检索按相关度取回，未必每次都命中；关键记忆完全不经检索筛选，每次对话都直接带入。这是用固定的少量 token 成本，换取最重要信息的稳定可用性。

1.4 自定义指令（Custom Instruction）

一段用户亲自撰写、持久生效的设定（上限 500 字），用来定义 AI 的语气、角色或回应方式。

直接定义身份与语气，不靠累积学习：种子记忆与学习记忆同样由用户掌控内容，但学习记忆要靠系统慢慢从对话中归纳；自定义指令则是用户一开始就直接写明 AI 应该用什么身份、什么语气回应，不必等待系统累积足够对话才推断出来。三者的分别在于内容的性质与运作方式：种子记忆是按相关度检索的知识内容，自定义指令是持续生效的行为设定，两者同样完全由用户主导，只是用途不同。

新手引导即自动生成：首次使用时，系统会用几个简短问题了解用户——想被怎样称呼、想补充的背景、想要的回复风格、惯用语言——并把答案组合成一段自定义指令。多数用户因此不需要自己动手写，就已经有一份起点。

位置安排考虑缓存成本：自定义指令甚少在对话中途改变，因此被放在系统提示中「稳定不变」的部分，与每次提问才变化的记忆片段分开处理。稳定部分可以被重复使用（prompt caching），不必每条消息都重新计算成本，这是直接影响每次对话成本的设计选择。

二、检索引擎：写入时做工，查询时受惠

检索的准确度比存储量更重要。HKSoka 的做法是把处理成本放在数据写入的一刻，让查询时的命中率更高。

2.1 命题级切块

长内容不会整段存储，而是拆解成一个个独立、自足的「命题」。

先分段、后提取：较长的文件会先按长度切成多个区段，每个区段独立送去做命题提取，确保每次处理的内容量在可靠范围内，不会因为一次处理过多内容而降低提取质量。

自足性是硬性要求：每条命题必须单独阅读也能理解，不可以依赖前后文才能解读。这是因为一条命题日后会被独立取回、插入一个完全不同的对话语境，没有机会连同原本的邻近内容一并出现。

解析失败有后备方案：如果模型输出未能完整解析成结构化格式，系统会尝试从输出中抢救出可用的部分命题，而不是整段内容直接舍弃。

2.2 双语嵌入

用户多数用中文记录，但查询时中英夹杂的情况常见。

写入时一并生成翻译：每条命题在提取的同时，会额外生成一个对应的英文版本；最终用来计算向量的文字是原文加翻译一并处理，但存储与显示给用户的内容，仍然保持原文语言不变。

成本只在写入时付一次：翻译的运算只在记忆写入的一刻发生，所以双语检索带来的好处不会反映在每次提问的延迟或成本上。

效果取决于翻译质量：这个设计的代价是翻译质量直接影响向量准确度，翻译一旦偏移，检索的命中率也会跟着受影响。

2.3 混合检索与分层配额

查询时，系统同时用语义向量与关键字两种方式比对。

向量负责语义，关键字负责精确：纯语义比对在用词差异大时容易失准；纯关键字比对在用户用近义词表达时容易漏掉。两种方式合并使用，提高命中的稳定性。

候选池与实际注入的数量分开计算：系统会先取出一个较大的候选池，再各自限定种子记忆与学习记忆实际注入对话的数量上限。这样设计是因为重度上传文件的用户，种子记忆片段数量可能远超学习记忆，如果不分开限额，学习记忆有机会完全被挤出检索结果之外；分层配额确保两类记忆都有机会出现。

写入端有节流与去重机制：大量内容一次性写入时，嵌入请求会分批执行并加入间隔，避免短时间内对外部服务发出过多请求；数据库写入采用防重复设计，同一条事实即使被重复提取，也不会在数据库中产生多于一条向量记录。

三、对话生命周期管理

3.1 长对话的上下文压缩

对话内容累积到一定长度后，系统用两层机制控制成本与稳定度。

硬上限作为安全网：当预估的 token 用量超过一个固定门槛，较旧的内容会被移出当前处理范围，确保任何情况下都不会无限累积。

摘要压缩作为主要手段：另外有后台任务持续为长对话维护一份精简摘要，取代直接舍弃旧内容。每次更新摘要时，只处理上次整理之后新增的部分，与既有摘要合并，借此控制随对话变长而持续上升的成本。

摘要存在时优先采用：一旦某段对话已经有摘要，往后的对话会用「摘要 + 最近几条消息」取代完整历史记录，既保留语境，亦让每次对话需要处理的内容量维持稳定。

3.2 编辑消息即分支，不覆写历史

修改一条已发送的消息并重新提问，不会覆写原本的对话记录。

原对话完整保留：编辑动作会在该条消息的位置另外开立一个新的对话分支，原本的对话连同 AI 原本的回复维持不变。用户可以同时保留「原本问法的回复」与「修改后问法的回复」，方便比较。

分支由服务器端生成：分支的内容是由服务器根据原对话记录截取至指定位置后，创建成一条新的对话记录，而不是单靠前端拼接，确保分支内容与数据库状态一致。

3.3 删除与遗忘联动

删除一段对话，不只是把它从画面隐藏。

对话本身采用软删除：被删除的对话会标记为隐藏，不再出现在列表中，界面上设有双击确认的设计，避免误触删除。

连带清除该对话产生的记忆：删除动作同时会找出哪些学习记忆是由这段对话提取出来，把对应的记忆条目与检索片段一并移除。换言之，删除一段对话不会留下「对话已从画面隐藏，但 AI 仍然保留该段内容」的落差，而其他对话产生的记忆不受影响，删除是针对性的，不是整批清空。

3.4 无痕模式

开启无痕模式后，系统会完全略过记忆检索与注入的步骤，对话结束后也不会被保存，亦不会进入学习记忆的处理流程——是彻底的旁路，不是事后才隐藏。

四、Artifact 工作区：对话中即时修改

需要产出一份文件、一段代码、一篇文章或短篇创作时，可以开启 Artifact 模式，内容显示在侧边的独立面板，与对话并排。

4.1 编辑策略：局部修改优先于整篇重写

系统默认用「定位 + 替换」的方式做修改，只在内容是全新或多数内容都需要改动时，才整篇重写。

精确比对才算数：局部修改要求待修改的文字必须与面板内容完全一致才会生效，这个限制逼使每次修改都是可验证的精准操作。

对用户的实际好处：对一份正在反复打磨的长文件或长代码而言，只需描述要改的地方，不必每次重新整篇输出，往来修改的效率因此提高。

4.2 版本与还原

版本记录可回溯：同一个 Artifact 在一次对话中如果经历多次修改，每个版本都会保留，用户可以在面板中切换查看之前的版本。

服务器端独立解析，确保数据一致：每次修改的结果，服务器会独立解析一次并写入数据库，不单纯信任前端回报的状态，确保保存下来的版本，跟实际产生的内容一致，即使前端界面出现显示问题，数据库中的版本仍然准确。

跨设备可接续编辑：如果前端本地没有保存目前内容（例如换了设备或重新刷新页面），系统会自动从数据库取回最后保存的版本，让编辑可以接续下去，不必重新开始。

4.3 落地动作

完成的内容支持一键复制，亦可以指定文件名下载成文本文件，方便直接用于其他工具或交付流程。

五、其他实用功能

网上搜索：需要实时信息时可开启搜索，回应会根据查到的资料作答；往后追问时，系统会清楚标示这部分内容来自先前的实时搜索结果，而不是训练数据，确保用户与系统都清楚信息的来源与时效。搜索流程设有上限，避免一次提问触发过多轮搜索导致等候时间过长。

PDF 与图片上传：可直接上传 PDF 或图片提问，亦支持直接粘贴剪贴板中的图片，不一定要先存档再选取文件。多个文件中如果其中一个读取失败，系统只会略过该文件，不会令整个请求失败。

对话与记忆导出：对话记录与学习记忆都可以一键下载成文本文件，方便保存或搬到其他地方使用。

三语界面：繁体中文、简体中文与英文。

六、架构决策背后的考量

异步处理：文件切块、命题提取与嵌入是运算较重的步骤，因此从主要对话流程中拆分出来，交由独立流程异步处理，让用户实时的对话体验保持流畅；代价是新上传的内容需要短暂时间才能被检索到。

分层模型与缓存：后台性、重复性高的工作（事实提取、摘要整理）使用较轻量的模型处理，主对话则保留质量较高的模型；系统提示中稳定不变的部分（基本设定、自定义指令、关键记忆）与每次提问才变化的部分（检索片段）分开处理，前者可以被重复使用而省却部分成本，这是 token 成本与回应质量之间的具体取舍。

排程式而非实时式处理：学习记忆不需要即时生效，用排程定时处理换取更低的系统复杂度；但同时对新用户采用较短的处理门槛，让记忆功能能够较快被用户感知到，在系统简洁与使用体验之间取得平衡。

七、诚实面对限制

关于 HKSoka 与顾问服务

HKSoka 在香港开发，支持繁体中文、简体中文与英文三语，把记忆、Artifact 工作区、网上搜索与文件上传整合在同一个界面。平台网址：www.hksoka.com

同一套记忆与检索架构的思路，也适用于企业场景：把分散的文件、对话与知识，整合成一层可检索、可控制、可审视的记忆。如果你的团队正在评估如何把 LLM 落地到实际业务流程，欢迎通过 LinkedIn 交流（linkedin.com/in/levi-innovation），或来信 smartai.hk+ai.consulting@proton.me。

常见问题

中小企未必有自己的技术团队，导入需要工程资源吗？

平台本身以对话界面操作，不需要额外开发或部署。记忆、文件上传、Artifact 工作区都是内置功能，打开界面即可使用。如果想把同一套记忆架构应用在企业自己的内部系统（例如连接公司既有的文件或工具），这部分才需要额外的工程资源进行整合。

HKSoka 的记忆系统，实际上提供什么不同之处？

分别主要在于记忆的结构与可控性。系统把记忆拆分成种子、学习、关键三层，各自负责不同角色——用户主动提供的背景、系统自动归纳的事实、以及每日整理出的重点摘要；每一条记录都可以单独检视、编辑或删除。记忆写入时亦会一并处理中英双语检索，配合繁体中文、简体中文与英文三语界面，适合中英夹杂的查询习惯。

系统记录的资料，会不会与其他用户混在一起？

不会。每位用户的记忆与检索片段都是独立存储，互不重叠，一位用户的记忆内容不会出现在另一位用户的检索结果之中。

如果系统记错了内容，可以删除吗？

可以。每一条学习记忆都能单独检视、编辑或删除；删除之后，系统会记住这类内容不应再被记录，避免同一件事下次又被重新提取。种子记忆同样可以随时开关或删除，控制权在用户手上。

上传的文件会如何处理？是否可以立即查询？

文件上传后，系统会在后台进行切块与建立索引，过程需要一定时间，完成后才能在对话中被检索到。文件愈长，准备时间相对愈长，这部分属于后台处理，不会卡住正在进行的对话。

这套记忆架构，可以用在我们公司自己的系统，还是只限这个平台？

HKSoka 本身运作中的版本，相当于这套分层记忆与混合检索设计的实际验证——证明这套架构具备生产环境的可行性。这类分层记忆与检索设计，过往亦曾实际应用于客户项目。企业实际的需求通常和这个平台不完全一样：既有的系统、文件格式、数据来源、使用场景都各有差异，直接套用一个现成平台未必是最合适的做法。同一套设计思路可以根据企业自己的情况重新拆解与构建——哪些记忆层级是必要的、检索逻辑如何配合既有系统、什么数据需要优先处理，都因应实际使用场景而有不同答案。如果想了解这套架构怎样配合贵公司的使用场景，欢迎直接交流，从了解需求开始，再决定如何构建。

如果想了解这套记忆与检索架构，可以怎样配合你的实际业务场景，欢迎通过 LinkedIn（linkedin.com/in/levi-innovation）或 smartai.hk+ai.consulting@proton.me 直接交流。