​

为什么和 AI 说话总是很累？

你有没有发现，和老朋友聊天只需一个眼神，而和 AI 聊天却需要写小作文？

这背后的差距只有一个词：熵（Entropy）。 在信息论中，熵代表了不确定性。老朋友拥有与你的共享记忆，能自动补全你话语中的空白（低熵）；而 AI 缺乏这层语境，导致每一个简单的词汇背后都隐藏着巨大的歧义（高熵）。

Context Engineering（上下文工程）的本质，就是帮机器完成这场“填空题”，弥补机器与人类认知的巨大鸿沟。

我们不再只是机械地存储对话，而是通过构建分层的 Memory（记忆） 系统，主动捕捉那些丢失的情境信息。本文将结合腾讯云 Memory 的实战案例，探讨如何通过技术手段为机器“减熵”，让你的 AI 应用从“人工智障”般的反复确认，转变为“心有灵犀”的精准执行。

一、 什么是 Context Engineering 的“熵减”：从公式到直觉

1.1 什么是熵？先看一个“小李”的例子

在深入技术定义之前，我们先看一个极简的生活场景。

你正在忙手头的工作，头也不回地对身边的老搭档说了一句：“叫上小李，到时老地方见。”

老搭档点了点头，立刻去做了。哪怕你什么细节都没交代。

但如果你对 AI 助手说同样的话，它大概率会产生幻觉（或者开始胡言乱语）：

● “小李”是谁？ 是通讯录里的李经理？隔壁部门的老李？还是这周新来的实习生小李？

● “到时”是什么时候？晚上九点？十点？还是明天早上？

● “老地方”是哪里？ 是一间饭店？公园的池塘旁边？还是办公休息区？

这就是 熵（Entropy） 的差异。

（熵，代表不确定性。可能性越多、结果越难预测，熵就越高。越有序、越清晰，熵就越低）

在人类的默契中，“那个东西” 和 “老王” 的具体指向，已经被共享的记忆、当前的情境和过往的习惯瞬间坍缩为唯一确定的事实——这是一个极低熵的交互。

但在机器看来，这一句话背后对应着成千上万种可能性的组合——这是一个极高熵的指令。

Context Engineering（上下文工程），本质上就是我们在充当翻译官，把人类习惯的高熵表达，转化为机器能理解的低熵指令。

1.2 上下文工程：在改“模型”之前，先改“输入”

如果把大模型拆解到最抽象的数学核心，它其实是一件非常冷冰冰的事情：

● 用户当前的问题 / 指令；

● 系统提示词（System Prompt）：告诉模型“你是谁、在干什么”；

● Memory（跨会话记忆）：以前发生过什么；

● 可用的工具列表（Tools）及调用方式；

● 外部知识库（RAG）的检索片段。

把这些东西怎么选、怎么排布、怎么取舍和压缩，就是 Context Engineering。

在 Context Engineering 2.0 这篇论文中，作者给出了一个更具哲学意味的定义：

Context Engineering 是设计与优化上下文的收集、存储、管理与使用的系统性过程，旨在弥合人类（碳基智能）与机器（硅基智能）之间的认知差距（Cognitive Gap）。

当你随口一说，它能不能听懂“你到底想要啥”；当业务系统把一堆日志塞给模型，它能不能抓住关键。这不只是“模型大小”的问题，而是“我们有没有把上下文准备好”的问题。

1.3 熵减视角：把“乱度”降下来

Context Engineering 2.0 提出了一个核心观点：上下文工程本质上是一个“熵减过程”。

这里的“熵”不是物理课本上的热力学公式，而是指信息的“不确定性”：

● 人类是高熵的：情绪、暗示、省略、背景知识、语气的停顿……很多信息你没说出来，因为你默认对方会“脑补”。

● 机器是低熵需求的：它无法自动“脑补”，它看到的只是一串 Token。如果我们把现实世界原封不动地丢给它，信息太多、太杂、结构太差，它很难从中找出“这次任务真正要用的那点东西”。

所以，Context Engineering 做的事情可以粗暴概括为三步熵减：

1. 收集（Collect）：从人类和环境那里捕获所有潜在信息，不漏掉关键线索。

2. 整理/抽象（Organize/Abstract）：把这些信息结构化、压缩、过滤掉噪声。

3. 使用（Use）：在具体任务前，从上述材料中只挑出和这次任务最相关（Relevant）的一小撮，精准送进模型。

从这个角度看，刚才那个简单的函数就可以画成一条更长的链路：

1.4 ContextEngineering(CE) 2.0 里的核心公式：

为了更科学地描述这个过程，Context Engineering 2.0 提供了一组形式化定义，我们可以这样通俗地理解：

1.5 Memory 在其中的地位：人类侧的“减熵器”

在这个庞大的 CE 框架里，Context 包含了很多东西：系统指令、工具输出、知识库文档……那么 Memory 到底是干嘛的？

如果说 Knowledge Base（知识库）是在帮模型“搞懂世界”（世界通识熵减），那么 Memory 更像是在帮模型“搞懂这个具体的人、这次具体的长期任务”。

Memory 是 Context Engineering 管道里专门面向“人 + 时间”的熵减工具。它的核心使命，就是把关于“这个人、这段关系、这条任务线”的海量高熵碎片，在漫长的时间维度上，压缩成少量、有序、可复用的结构化语境。

没有 Memory，AI 永远活在“现在”，每一次对话都是高熵的冷启动；

有了 Memory，AI 才拥有了“过去”，从而能以极低的熵值，理解你那个简单的“好”字背后，究竟意味着什么。

二、 Memory 是什么：一套“意图识别 + 信息补充”的熵减工具

如果说大模型是那个智商超群但只有 7 秒记忆的“超级大脑”，那 Memory 就是我们给它外挂的“记事本”。但在 Context Engineering（上下文工程）的精密流水线里，Memory 绝不仅仅是简单地“存几条聊天记录”。

2.1 从 CE 视角重定义 Memory：不只是存储，而是“预判”

在传统的认知里，Memory 像是一个仓库，把用户说过的话堆进去，需要的时候翻出来。但在 Context Engineering 的管道（Pipeline）中，Memory 是一个动态的、专门面向“人 + 长期任务”的上下文层。

它的核心目的非常单纯，就是做两件事来降低交互的熵：

1. 意图熵减（Intent Reduction）：让模型更快听懂你

这就好比你楼下的便利店老板。

 ● **没有 Memory（高熵状态）**：你每次去都要说：“老板，我要一包红软，不要硬的，要打火机。”

 ● **有 Memory（熵减状态）**：你只要进门点个头（Token 输入极少），老板就把烟和火机递过来了。

Memory 在这里的作用，是利用历史数据将模糊的“点头”瞬间坍缩为精准的“买烟”意图。

2. 知识熵减（Information Supplementation）：克制的背景补充

当你在聊“这一版代码怎么改”时，Memory 不需要把整个项目的 10 万行代码都塞进 Prompt（那是上下文污染），它只需要在关键时刻，像身边的老员工一样递上一张纸条：“注意，这个模块之前的鉴权逻辑是 OAuth 2.0，别改坏了。”

关键在于“克制”：只补当前决策最缺的那一点高价值背景，多给一分都是噪声。

2.2 从需求侧看：我们到底想要什么样的 Memory？

如果去问用户或业务方“你们想要什么记忆功能”，他们的回答通常很散乱。当我们把这些需求像剥洋葱一样剥开，会发现它们对应着 5 种不同维度的熵减渴望：

1. 角色扮演不掉皮，指令不失忆

● 痛点：很多 Agent 聊着聊着就忘了自己是“苏格拉底”还是“猫娘”，或者在第 20 轮对话后把用户最开始强调的“请只用 JSON 格式回复”抛诸脑后。

● 需求本质：用户希望“人格设定（Persona）”和“关键约束（Constraints）”成为一种长期持有的低熵语境。不应该让用户每隔几轮就手动重启一次“嘿，别忘了你现在的身份”。

2. 个性化与用户画像：越用越懂你

● 痛点：千人一面的 AI，像流水线工人，没有温度。

● 需求本质：

 ○ **教育场景**：希望 AI 老师不是只看到“这道题错了”，而是调出记忆——“小明，你在这个知识点上已经错了三次，且都是因为正负号混淆”。这就是“千人千面”的教学。

 ○ **营销/服务**：不是生硬的推销，而是基于记忆——“上次您买的那款猫粮快吃完了吧？”。但这需要极高的可解释性，既要懂用户，又不能让用户觉得被“过分偷窥”。

3. 上下文连贯：长任务不割裂

● 痛点：在长达几小时的 Coding Session 或复杂的售后流程中，用户最怕那种“换个客服就要从头解释一遍”的割裂感。

● 需求本质：这是一个“收集 → 压缩抽象 → 基于摘要复用”的接力赛。Memory 需要像接力棒一样，承载上一轮任务的动量和状态（State），传递给下一轮，让用户感觉不到“断档”。

4. 信息的存储与挖掘：把互动变成“可再利用资产”

● 痛点：对话是流逝的，聊完就没了。

● 需求本质：B 端客户非常看重这一点。对话、文件修改、点击行为，这些都是高价值资产。

 ○ Memory 的作用类似于推荐系统里的“打标签”，但更高级。推荐系统处理的是结构化点击流，Memory 处理的是非结构化的文本。

○ 我们不仅要利用已有的记忆服务用户，还要从服务过程中反向挖掘（Mining）出新的画像信息，形成数据闭环。

5. 让 AI 更有“人味”：记住关系，而非只记事实

● 痛点：AI 记得住“你叫 Bob”，但记不住“Bob 最近工作压力很大，需要鼓励”。

● 需求本质：人类关系的建立依赖于情感共鸣的积累。Memory 需要记录的不仅仅是 Fact（事实），更是 Relationship（关系）。它要记住你的立场、你的情绪曲线、你未表达的隐忧，让互动从“一问一答”升级为“持续的人际关系”。

2.3 小结：Memory 在 CE 里的角色

一句话总结：Memory 是 Context Engineering 管道里的“人类侧减熵器”。

它的使命，就是把关于“这个人、这段关系、这条任务线”的海量高熵碎片，实时压缩成少量、有序、可被复用的结构化语境，在 AI 还没开口之前，就已经帮它铺好了理解用户的路。

三、 Claude 的秘密：从 Chat & Code 看“记忆的熵减侧重”

为什么在众多模型参数差异不大的情况下，很多开发者和用户觉得 Claude 在处理复杂上下文时显得“更聪明”？

秘密除了模型本身的推理能力（IQ），还在 Context Engineering 的策略上。如果我们仔细拆解 Anthropic在Chatbot 和 ClaudeCode 两种应用下的设计，会发现它在做两件截然不同的“熵减运动”。这给我们的 Memory 设计提供了极佳的参照系。

3.1 Chat 模式：以“人和对话”为中心的熵减

在 Chatbot 场景里，Claude 的记忆设计明显是围绕“人 + 长期对话”做熵减的。

从官方说明和近期升级可以看出，Claude 的 Memory 默认记的不是一堆零散句子，而是围绕几类稳定信息做摘要：用户的身份和角色、偏好的语言/写作风格、正在进行的项目、客户需求和团队工作流等。

这些记忆被组织成不同的“空间”：个人空间、工作区（workspace）、项目空间，每个空间单独维护自己的记忆，避免把 A 项目的上下文带到 B 项目里。 用户可以在设置页统一开关 memory，也可以在对话中显式让 Claude 记住 / 忘记某条信息，甚至开启类似“隐身模式”的无记忆会话。

从「减熵」的角度看，ClaudeChat memory 主要在减这三类不确定性：

● 谁在说话：我是哪个用户、处在什么角色（学生 / PM / 开发 / 客户），知识背景大概如何。

● 我们在聊哪条长期话题线：当前属于哪个项目、哪门课、哪组 OKR、之前已经达成了哪些共识。

● 这次回答应该沿用什么风格和立场：要不要列表、要不要代码、是科普口吻还是正式方案。

实际表现出来就是：项目空间 + 历史对话摘要 + 可编辑的 memory，一起构成一个相对稳定的“对话壳”。哪怕你隔几天再回来问“上次我们说到哪了？”，“帮我按之前的风格继续写”，模型也能在这个壳里延续同一个“你”和同一条叙事线，而不需要你从头再介绍自己。

换句话说，Chat 场景下的记忆，更像是在对“人物与故事线”做熵减，把“这个人是谁、这段关系的历史是什么”压成少量持久标签和摘要，降低每次意图识别的成本

3.2 Code 模式：以“仓库和任务”为中心的熵减

到了 Claude Code，这套记忆的重心就完全换了位置：从“记住你这个人”，转向“记住这条任务线”。

Claude Code 的文档和实战经验大致能总结出几层记忆来源：

● 项目内的持久说明文件：模型的“小本子”，例如 CLAUDE.md，里面写清楚项目结构、开发规则、“不该碰”的目录、质量标准等，作为长期记忆骨架。

● Claude Code 自身的跨会话记忆：可以记住常用命令、偏好的代码风格、固定的工作流提示等，但这些更多是“工作环境习惯”，而不是 Chat 那种“整个人生画像”。

在 Coding 场景下，记忆在减的熵，主要是三件事：

1. 当前 repo 的结构和边界：重要模块在哪里、依赖关系如何、哪些目录是生成物不能改。

2. 当前任务的进度和上下文：这次重构 / debug 已经做了哪些步骤、尝试过哪些方案、当前假设是什么。

3. 约束和红线：必须遵守的架构原则、测试要求、安全/合规限制等，通常写在 CLAUDE.md 或项目配置里。

为了防止“上下文污染”和“越写越糊”，Claude Code 还强调上下文隔离：通过 MCP 配置、子代理（sub-agents）和 slash 命令，把不同工具、不同子任务放在各自的子上下文里，用需要的时候再拉进主会话，避免所有东西都挤在一个 20k token 的大对话里。 这本质上也是一种熵减：让每个子任务只面对自己那一小块“世界”，而不是整个仓库的混沌态。

3.3 这对我们设计 Memory 的启发

通过对比可以看出，Memory 绝不是一套通用的“记下来就完事”的功能，而是一个高度场景化的命题：

● Chatbot场景：需要的是 Intent Memory（意图记忆），对抗的是人格与话题连续性的熵增。

● Coding场景：需要的是 State Memory（状态记忆），对抗的是系统复杂度和任务进度的熵增。

Memory 设计的黄金法则，不是“记多一点就更聪明”，而是要精准识别“当前场景下，哪种不确定性（熵）是最致命的”。

是怕它忘了“我是谁”？还是怕它搞乱了“代码依赖”？

基于这种“分场景、分层级”的熵减思考，才能构建出更高效的 Memory 框架。

四、 “Attention before Attention”：Memory 设计中的两大熵减挑战

是一节从“战壕”里带回来的实战总结。

在开发腾讯云数据库 Memory 产品的过程中，我们发现理论上的 Context Engineering 2.0 到了工程落地阶段，会撞上无数具体的“墙”。这些墙逼迫我们承认一个事实：Memory 不仅仅是数据库的读写，而是一场在有限算力和时延预算下的“注意力保卫战”。

LLM 的核心机制是 Self-Attention（自注意力），它决定了模型把算力聚焦在上下文的哪里。但 Memory 系统要做的事，是在 Token 进入模型之前，先进行一轮筛选。

这些挑战被称为 "Attention before Attention"。这一过程极其凶险：做得好是“神助攻”，做得不好，Memory 本身就会成为最大的噪声源。

4.1 储存层的挑战：数据完整性与结构化约束

在 Memory 系统设计中，我们追求极致的个性化，理论上应存储所有用户相关的轨迹。然而，工程实践证明，如果存储阶段缺乏结构化（Schema），单纯地增加存储量，本身就是在引入高熵（High Entropy），即制造系统不确定性。

我们必须在保留原始细节（避免稀疏信号）与防止关键信息丢失（避免暴力压缩）之间取得平衡。实战中存在三种关键的存储陷阱：

陷阱一：数据碎片化（Over-Sparsity）

类别	描述
现象/故障模式	系统机械性地记录每一轮对话的原始文本（Event），但丢失了高层次的任务结构（Task Schema）。
系统影响	记忆成为无结构的短文本集。在召回（Retrieval）阶段，检索引擎必须处理成千上万条低关联度的短文本。由于缺乏完整的语境链条，LLM 无法拼凑出完整的上下文，无法理解事情的来龙去脉。
设计原则	存储必须包含结构化 Schema。没有“结构”的存储，只是数据的堆砌，而非可用的记忆沉淀。

类别	描述
现象/故障模式	单一记忆 Event 缺乏情境背景，未挂载至具体的 Scene ID 或 Task ID 上。
系统影响	导致 语境错位（Context Mismatch）。例如，在“做饭”的场景下错误召回“写代码”时的偏好。这种典型的熵增直接导致 Agent 人格偏移和用户体验中断。
设计原则	记忆必须有“锚点”。Memory 的隔离性（Isolation）是召回准确性的底线，应将零散的对话聚合为“有情境边界的块”来对抗“记忆孤岛”。

如果说存储是打地基，召回就是走钢丝。我们在落地中收到的最激烈的业务反馈往往聚焦于此，实践中的召回往往存在着“效果-速度-泛化能力”的不可能三角。

挑战一 ：拒绝上下文污染

挑战名称	宁缺毋滥：业务方对“过召”的恐惧
关键矛盾	业务方，尤其是 B 端客户，普遍强调 “宁可少召，也不能把整个情境污染掉。”
后果分析	如果召回了错误的历史信息（例如，将旧的错误价格带入新的报价单），这不仅无法减熵，反而会成为严重的 误导。这是一种典型的熵增效应。
设计结论	高可用 Memory 的召回结果，不仅要具备相关性（Relevant），更要保证 低歧义性（Unambiguous）。召回策略必须以防止污染为最高优先级。

4.3 “Attention before Attention” 的深层含义

● LLM 的 Attention：是在一屋子人里，决定盯着谁看。

● Memory 的 Attention：是决定放哪几个人进屋子。

好的 Memory 产品，核心工作就是做好这道“门卫”：把模型真正需要的那点东西，在 500ms 内准备好，挡住噪声，放进信号。 这就是 Context Engineering 在工程侧最极致的减熵体现。

五、 Memory 的分层记忆，如何工程化落地熵减

在上一章，我们列举了 Memory 设计中的“不可能三角”：要存得全又要召得准，要理解深又要速度快。面对这些矛盾，单纯堆砌向量数据库（Vector DB）是无法解决问题的。

我们最近探索的解法，是利用信息的“层级性”。我们参考人类大脑的运作机制，设计了一套“三层存储 + 三层召回”的架构，兼顾信息留存和使用效率，将 Context Engineering 的熵减过程工程化。

5.1 三层存储：从 Event → Scene → Record

不是简单地把对话“扔进库里”，而是像图书管理员一样，对信息进行三级“提纯”。Event 保底不丢细节，MemoryBook 保证任务有情境，Record 把长期认知抽成高密度标签。三层协作，将“原本混沌的数据流”逐级清洗为低熵的上下文。

1. Event 原文层：降低“原始语境丢失”的熵

● 角色：最底层的“黑盒录音机”。它按时间顺序，完整记录谁（Source）在何时（Time）说了什么、做了什么。

● 熵减逻辑：

  ○ **对抗“过度抽象”**：上一章我们提到，过度总结会导致信息丢失。Event 层不做任何有损压缩，只保证“不丢原话”。它是所有上层记忆的 Source of Truth（事实之源），确保当模型需要追溯细节时，有据可查。

2. Scene 情境层：降低“任务碎片化”的熵

● 角色：这是我们对抗“记忆孤岛”的核心设计。我们按照任务（Task）或场景（Scene），把散落在时间线上的 Events 聚合成一册册 MemoryBook。

● 结构：每本 MemoryBook 包含多个 Scene（例如“2025-03-01 数学课：分数加减”）。每个 Scene 挂载了该场景下的关键原文片段，以及从中提取的阶段性结论。

● 熵减逻辑：

 ○ **对抗“语境错位”**：它把零散的对话压缩成了“有情境边界的块”。未来召回时，模型拿到的不是凭空的一句话，而是连同“这是哪次课、哪轮项目讨论”的背景一起拿回来，彻底解决了“聊代码时突然跳出做饭建议”的串味问题。

3. Record 记录层：降低“长期认知模糊”的熵

● 角色：这是信息密度最高的一层，类似于“档案卡”。我们从海量 MemoryBook 中跨场景抽取高价值信息：用户画像、稳定偏好、关键时间线事件。

● 灵活性：Schema 支持业务定制（教育版存学习进度，电商版存品牌偏好）。

● 熵减逻辑：

   ○ 对抗“意图识别的高熵”：把用户一生的混沌交互，压成了一张几十 KB 的结构化卡片。在对话开始的毫秒级瞬间，模型就能通过这张卡片完成“意图校准”。

5.2 三层召回：在 500ms 内完成“注意力路由”

存得好是为了用得好。在召回侧，我们针对“时延”与“准确性”的矛盾，设计了一套从近到远、从快到深的路由机制。

1. 当前对话层：直接使用 Event 上下文

● 策略：优先将最近几轮 Event 原文直接拼接进 Context window。

● 解决痛点：解决“金鱼记忆”问题。保证模型对“上一句说了什么”有绝对精准的短期记忆，避免用户在十几轮内反复重复需求。

2. 任务情境层：唤醒 MemoryBook，跨时间“接力”

● 策略：当对话跨越了轮次、甚至跨越了天数时，系统根据 Session ID 或 Task ID 唤醒沉睡的 MemoryBook。

● 解决痛点：解决“长任务割裂”问题。

● 关键工程创新：异步预召回（Async Pre-fetch）

  ○ 为了对抗 500ms 的时延死线，MemoryBook 具备“预判”能力。它始终“盯着当前任务”，在用户真正开口提问之前，后台可能已经根据当前场景（如“进入小明的期末复习模式”），预先拉取了相关的错题记录。

  ○ 这是真正的 Attention before Attention：用空间换时间，让实时召回更轻快，但模型依然“有备而来”。

3. 长期档案层：快速检索 + Agentic Search 深挖

● 策略 A（快速路）：在极短时间内，通过向量 + 关键字双路检索，从 Record 层提取与当前 Query 最相关的长期记忆（如用户称呼、忌口）。

● 策略 B（深思路 - Agentic Search）：

○ 针对“我去年今天在干什么？”或“总结我过去一个月的代码风格”这种复杂问题，单纯的 RAG 会陷入“信息茧房”。

○ 此时触发 Agentic Search：让一个小型的内部 Agent 进行多轮检索 + 逻辑推理。虽然耗时稍长，但能解决多跳逻辑问题，充当 MemoryBook 的“幕后智囊”。

5.3 指标与现象：熵减设计的实战回响

这套“三层存、三层用”的架构，在实际落地的内部评测中，带来了显著的体验质变：

1. 时序记忆的突破：

在面对 “我去年今天在做什么？” 这类强依赖时间线索的召回任务时，仅使用基础模型（Qwen3-coder）的准确率约为 45%（容易产生幻觉或遗忘）；接入分层 Memory 后，准确率提升至 88%。这证明了结构化存储对“时间熵”的有效抑制。

2.长链路任务的“减负”：

在复杂的 Coding 或教学场景中，用户被迫“重复说明需求与约束”的次数大幅下降。Memory 成功充当了“维持任务骨架”的角色，让 AI 的行为在跨越数天的会话中依然保持逻辑一致。

3. 人格稳定性：

“人格错乱”与“跨会话断档”问题显著缓解。Memory 不再是零散的回忆片段，而是支撑 Agent 维持长期“人设”的脊梁。

​

六、 结语：从减熵的 Memory，到我们的“数字存在”

当我们从代码与架构的细节中抽身，重新审视 Context Engineering（语境工程）的演进，会发现我们正在构建的不仅仅是一个更聪明的数据库，而是人类与机器在认知层面深度耦合的开端。

6.1 CE 的未来：熵减操作者将从“人”迁移至“机”

Context Engineering 2.0论文中曾预言，随着机器智能的提升，熵减的主力将逐步发生转移。

在当前的 CE 1.0 与 2.0 阶段，Memory、知识库（Knowledge Base）、工具集（Tools）本质上仍是人类工程师为模型搭建的“脚手架”。我们通过精密的 Prompt 设计和分层存储策略，手动帮助尚不具备完备心智的模型过滤噪声、提取意图。

而在未来的 CE 3.0 乃至 4.0 时代，随着模型本身推理能力与长窗口技术的突破，机器将具备自主感知、推断和构造上下文的能力。届时，Memory 系统将不再仅仅是被动的存储容器，而会演化为模型主动的“注意力器官”，能够自主地在海量数据中进行熵减，捕捉那些人类甚至未曾意识到的隐性关联。

6.2 Digital Presence：Memory 塑造的是“低熵的你”

有评论将极致的 Context Engineering 愿景称为一种“数字在场（Digital Presence）”。

当一个 Memory 系统经过充分的工程化设计，它所承载的便不再是冰冷的日志，而是用户知识结构、行为习惯、决策风格与情感偏好的完整映射。从这个意义上说，Memory 正在逐步形塑一个关于用户的“低熵模型”。

这个模型既是 AI 理解用户的基石，也是用户在数字世界中的投影。它不仅帮助 AI 在“此时此刻”提供精准服务，更在时间维度上沉淀了用户的“存在感”。Memory 让 AI 的交互不再是离散的计算，而变成了连续的陪伴；它让用户感到的不再是工具的冷漠，而是被理解的共鸣。

6.3 工作之余的一点思考

当我们今天严谨地设计 Memory 分层策略、致力于为机器做“熵减”时，我们一方面是在致力于让 AI 的交互更加平滑、高效；但从更深远的尺度来看，我们或许正在搭建一套可计算的“自我叙事（Self-Narrative）”。

也许若干年后，当我们回望今天的 Context Engineering，会发现我们并不只是在给模型提供上下文，也是在往外搭建一个关于“我是谁”的稳定刻画。

如何在“让机器更有用”和“保护人作为主体的开放性”之间寻找平衡，可能就是下一代 CE 3.0 时代真正的哲学命题。

​

七、 一些 Takeaway：如果你要自己做一个 Memory 系统，可以先想清楚这三个问题

以下清单旨在帮助您从“熵减”的视角，审视系统设计的合理性与必要性。

7.1 定位核心目标：您最想减少的是哪种“熵”？

Context Engineering 的本质是消除不确定性。但在资源有限的前提下，我们无法同时解决所有问题。请先明确您的业务痛点主要集中在以下哪一类：

1. 意图熵（Intent Entropy）

● 痛点：模型难以记住用户的身份，或无法准确理解指令背后的隐性需求，导致交互反复确认。

● 优化目标：让模型更快、更少歧义地理解“用户是谁”、“偏好为何”以及“当下的潜台詞”。

● 适用场景：情感陪伴助手、私人助理、个性化推荐 Agent。

2. 知识熵（Knowledge Entropy）

● 痛点：业务数据庞杂（涵盖文档、日志、数据库），AI 在检索时容易迷失，或召回大量无关噪声。

● 优化目标：在海量的信息堆叠中，高效定位到“本次任务真正需要的那一片段”，实现高精度的信息供给。

● 适用场景：企业级搜索、法律与医疗文档问答、售后知识库。

3. 过程熵（Process Entropy）

● 痛点：在长链路任务中，AI 容易遗忘初始约束，或在多轮对话后逻辑崩塌，导致任务无法闭环。

● 优化目标：防止中途出现“状态混乱”和“结论反复摇摆”，确保任务进度如箭头般持续向前推进。

● 适用场景：编程辅助（Coding Copilot）、AI 教师、复杂工单处理系统。

7.2 产品与工程设计清单（Checklist）

在系统架构设计阶段，请检查您的方案是否回应了以下关键问题，以避免工程层面的熵增：

● 记忆层级（Hierarchy）

○ 思考点：系统是否区分了 Event（原始事实）、Session/Scene（当前任务语境）和 Profile（长期画像）？

○ 建议：避免将所有信息扁平化存储。缺乏层级的记忆库极易导致检索混乱，应建立分层存储与召回机制。

● 命名空间与隔离（Namespace & Isolation）

○ 思考点：不同项目、用户或业务线的记忆是否实现了严格隔离？

○ 建议：Memory 的隔离性是数据安全与召回准确性的底线，必须防止跨项目或跨用户的记忆污染。

● 存储与使用的策略（Storage vs. Usage）

○ 思考点：是否区分了“热记忆”与“冷记忆”？

○ 建议：高优先级信息（如核心人设、任务红线）应置于 System Prompt 或上下文头部，随取随用；低频信息（如历史闲聊细节）应存入 RAG 或 MemoryBook，按需调取。

● 熵增监控与反馈（Monitoring & Feedback）

○ 思考点：当 AI 产生错误回忆导致“幻觉”或“人设崩塌”时，是否有机制能捕捉并修正？

○ 建议：设计闭环反馈机制。如果用户指出记忆有误，系统需能捕获信号并触发修正，防止错误信息在系统中累积。

7.3 业务价值转译：如何传递 Memory 的价值

在思考 Memory 系统的价值时，我们不应仅仅停留在“开发一个很酷的功能”这一层面，而应将其转译为具体的场景价值：

● 与其说：“我们要上线一个向量存储功能。”

● 不如说：“我们要降低特定场景下的不确定性。” 例如：

○ 让教师无需重复记录每一位学生的历史学习情况；

○ 让客服在接手转单时，无需重新阅读冗长的历史工单；

○ 让用户无需每隔三轮对话，就必须再次强调自己的身份与需求。

当然，从零构建一套理想的“低熵”系统并非易事。如果您正在探索如何将上述分层设计高效落地，腾讯云数据库 Memory 产品或许能为您提供一种成熟的实践参考。

我们正在通过“短中长”三层架构来解构复杂记忆：利用中期 MemoryBook 辅助维护任务连贯性（应对过程熵），通过长期画像积累用户偏好（缓解意图熵），配合支持逻辑多跳的 Agentic Search 与快召回路径的极速响应，我们希望在知识熵的治理上为用户提供更精准的检索支持。愿这套基础设施能帮您省去底层的重复建设，让您能更专注于打磨上层的业务价值，如希望进一步了解产品，可点击产品官网页面了解更多：

https://cloud.tencent.com/document/product/1813/123054

​

文章来源于腾讯云开发者社区，点击查看原文