你有没有发现，和老朋友聊天只需一个眼神，而和 AI 聊天却需要写小作文？
这背后的差距只有一个词：熵（Entropy）。在信息论中，熵代表了不确定性。老朋友拥有与你的共享记忆，能自动补全你话语中的空白（低熵）；而 AI 缺乏这层语境，导致每一个简单的词汇背后都隐藏着巨大的歧义（高熵）。
Context Engineering（上下文工程）的本质，就是帮机器完成这场"填空题"，弥补机器与人类认知的巨大鸿沟。
我们不再只是机械地存储对话，而是通过构建分层的 Memory（记忆） 系统，主动捕捉那些丢失的情境信息。本文将结合腾讯云 Memory 的实战案例，探讨如何通过技术手段为机器"减熵"，让你的 AI 应用从"人工智障"般的反复确认，转变为"心有灵犀"的精准执行。
在深入技术定义之前，我们先看一个极简的生活场景。
你正在忙手头的工作，头也不回地对身边的老搭档说了一句："叫上小李，到时老地方见。"
老搭档点了点头，立刻去做了。哪怕你什么细节都没交代。
但如果你对 AI 助手说同样的话，它大概率会产生幻觉（或者开始胡言乱语）：
这就是 熵（Entropy） 的差异。
（熵，代表不确定性。可能性越多、结果越难预测，熵就越高。越有序、越清晰，熵就越低）
在人类的默契中，"那个东西"和"老王"的具体指向，已经被共享的记忆、当前的情境和过往的习惯瞬间坍缩为唯一确定的事实——这是一个极低熵的交互。
但在机器看来，这一句话背后对应着成千上万种可能性的组合——这是一个极高熵的指令。
Context Engineering（上下文工程），本质上就是我们在充当翻译官，把人类习惯的高熵表达，转化为机器能理解的低熵指令。
如果把大模型拆解到最抽象的数学核心，它其实是一件非常冷冰冰的事情：
把这些东西怎么选、怎么排布、怎么取舍和压缩，就是 Context Engineering。
在 Context Engineering 2.0 这篇论文中，作者给出了一个更具哲学意味的定义：
Context Engineering 是设计与优化上下文的收集、存储、管理与使用的系统性过程，旨在弥合人类（碳基智能）与机器（硅基智能）之间的认知差距（Cognitive Gap）。
当你随口一说，它能不能听懂"你到底想要啥"；当业务系统把一堆日志塞给模型，它能不能抓住关键。这不只是"模型大小"的问题，而是"我们有没有把上下文准备好"的问题。
Context Engineering 2.0 提出了一个核心观点：上下文工程本质上是一个"熵减过程"。
这里的"熵"不是物理课本上的热力学公式，而是指信息的"不确定性"：
所以，Context Engineering 做的事情可以粗暴概括为三步熵减：
从这个角度看，刚才那个简单的函数就可以画成一条更长的链路。
为了更科学地描述这个过程，Context Engineering 2.0 提供了一组形式化定义，我们可以这样通俗地理解。
在这个庞大的 CE 框架里，Context 包含了很多东西：系统指令、工具输出、知识库文档……那么 Memory 到底是干嘛的？
如果说 Knowledge Base（知识库） 是在帮模型"搞懂世界"（世界通识熵减），那么 Memory 更像是在帮模型"搞懂这个具体的人、这次具体的长期任务"。
Memory 是 Context Engineering 管道里专门面向"人 + 时间"的熵减工具。 它的核心使命，就是把关于"这个人、这段关系、这条任务线"的海量高熵碎片，在漫长的时间维度上，压缩成少量、有序、可复用的结构化语境。
如果说大模型是那个智商超群但只有 7 秒记忆的"超级大脑"，那 Memory 就是我们给它外挂的"记事本"。但在 Context Engineering（上下文工程）的精密流水线里，Memory 绝不仅仅是简单地"存几条聊天记录"。
在传统的认知里，Memory 像是一个仓库，把用户说过的话堆进去，需要的时候翻出来。但在 Context Engineering 的管道（Pipeline）中，Memory 是一个动态的、专门面向"人 + 长期任务"的上下文层。
它的核心目的非常单纯，就是做两件事来降低交互的熵：
这就好比你楼下的便利店老板。
Memory 在这里的作用，是利用历史数据将模糊的"点头"瞬间坍缩为精准的"买烟"意图。
当你在聊"这一版代码怎么改"时，Memory 不需要把整个项目的 10 万行代码都塞进 Prompt（那是上下文污染），它只需要在关键时刻，像身边的老员工一样递上一张纸条："注意，这个模块之前的鉴权逻辑是 OAuth 2.0，别改坏了。"
关键在于"克制"：只补当前决策最缺的那一点高价值背景，多给一分都是噪声。
如果去问用户或业务方"你们想要什么记忆功能"，他们的回答通常很散乱。当我们把这些需求像剥洋葱一样剥开，会发现它们对应着 5 种不同维度的熵减渴望：
一句话总结：Memory 是 Context Engineering 管道里的"人类侧减熵器"。
它的使命，就是把关于"这个人、这段关系、这条任务线"的海量高熵碎片，实时压缩成少量、有序、可被复用的结构化语境，在 AI 还没开口之前，就已经帮它铺好了理解用户的路。
为什么在众多模型参数差异不大的情况下，很多开发者和用户觉得 Claude 在处理复杂上下文时显得"更聪明"？
秘密除了模型本身的推理能力（IQ），还在 Context Engineering 的策略上。如果我们仔细拆解 Anthropic 在 Chatbot 和 Claude Code 两种应用下的设计，会发现它在做两件截然不同的"熵减运动"。这给我们的 Memory 设计提供了极佳的参照系。
在 Chatbot 场景里，Claude 的记忆设计明显是围绕"人 + 长期对话"做熵减的。
从官方说明和近期升级可以看出，Claude 的 Memory 默认记的不是一堆零散句子，而是围绕几类稳定信息做摘要：用户的身份和角色、偏好的语言 / 写作风格、正在进行的项目、客户需求和团队工作流等。
这些记忆被组织成不同的"空间"：个人空间、工作区（workspace）、项目空间，每个空间单独维护自己的记忆，避免把 A 项目的上下文带到 B 项目里。用户可以在设置页统一开关 memory，也可以在对话中显式让 Claude 记住 / 忘记某条信息，甚至开启类似"隐身模式"的无记忆会话。
从「减熵」的角度看，Claude Chat memory 主要在减这三类不确定性：
实际表现出来就是：项目空间 + 历史对话摘要 + 可编辑的 memory，一起构成一个相对稳定的"对话壳"。哪怕你隔几天再回来问"上次我们说到哪了？"、"帮我按之前的风格继续写"，模型也能在这个壳里延续同一个"你"和同一条叙事线，而不需要你从头再介绍自己。
换句话说，Chat 场景下的记忆，更像是在对"人物与故事线"做熵减，把"这个人是谁、这段关系的历史是什么"压成少量持久标签和摘要，降低每次意图识别的成本。
到了 Claude Code，这套记忆的重心就完全换了位置：从"记住你这个人"，转向"记住这条任务线"。
Claude Code 的文档和实战经验大致能总结出几层记忆来源：
CLAUDE.md，里面写清楚项目结构、开发规则、"不该碰"的目录、质量标准等，作为长期记忆骨架。在 Coding 场景下，记忆在减的熵，主要是三件事：
CLAUDE.md 或项目配置里。为了防止"上下文污染"和"越写越糊"，Claude Code 还强调上下文隔离：通过 MCP 配置、子代理（sub-agents）和 slash 命令，把不同工具、不同子任务放在各自的子上下文里，用需要的时候再拉进主会话，避免所有东西都挤在一个 20k token 的大对话里。这本质上也是一种熵减：让每个子任务只面对自己那一小块"世界"，而不是整个仓库的混沌态。
通过对比可以看出，Memory 绝不是一套通用的"记下来就完事"的功能，而是一个高度场景化的命题：
Memory 设计的黄金法则，不是"记多一点就更聪明"，而是要精准识别"当前场景下，哪种不确定性（熵）是最致命的"。
是怕它忘了"我是谁"？还是怕它搞乱了"代码依赖"？
基于这种"分场景、分层级"的熵减思考，才能构建出更高效的 Memory 框架。
是一节从"战壕"里带回来的实战总结。
在开发腾讯云数据库 Memory 产品的过程中，我们发现理论上的 Context Engineering 2.0 到了工程落地阶段，会撞上无数具体的"墙"。这些墙逼迫我们承认一个事实：Memory 不仅仅是数据库的读写，而是一场在有限算力和时延预算下的"注意力保卫战"。
LLM 的核心机制是 Self-Attention（自注意力），它决定了模型把算力聚焦在上下文的哪里。但 Memory 系统要做的事，是在 Token 进入模型之前，先进行一轮筛选。
这些挑战被称为 "Attention before Attention"。这一过程极其凶险：做得好是"神助攻"，做得不好，Memory 本身就会成为最大的噪声源。
在 Memory 系统设计中，我们追求极致的个性化，理论上应存储所有用户相关的轨迹。然而，工程实践证明，如果存储阶段缺乏结构化（Schema），单纯地增加存储量，本身就是在引入高熵（High Entropy），即制造系统不确定性。
我们必须在保留原始细节（避免稀疏信号）与防止关键信息丢失（避免暴力压缩）之间取得平衡。实战中存在三种关键的存储陷阱：
| 类别 | 描述 |
|---|---|
| 现象 / 故障模式 | 系统机械性地记录每一轮对话的原始文本（Event），但丢失了高层次的任务结构（Task Schema）。 |
| 系统影响 | 记忆成为无结构的短文本集。在召回（Retrieval）阶段，检索引擎必须处理成千上万条低关联度的短文本。由于缺乏完整的语境链条，LLM 无法拼凑出完整的上下文，无法理解事情的来龙去脉。 |
| 设计原则 | 存储必须包含结构化 Schema。没有"结构"的存储，只是数据的堆砌，而非可用的记忆沉淀。 |
| 类别 | 描述 |
|---|---|
| 现象 / 故障模式 | 为了节省 Token 和存储空间，Memory 系统实施暴力摘要压缩（Summarization），将大量互动（如 100 轮对话）压缩成结论。 |
| 系统影响 | 关键的中间状态信息被丢弃。例如，在 Coding 或教学等长时序任务中，"用户尝试过这种方法但失败了"的过程数据往往比最终结论更重要。信息丢失将导致 AI 建议用户重复已失败的方案，造成效能退化。 |
| 设计原则 | 摘要是减熵，但过度摘要是信息损耗。摘要粒度必须确保保留任务的中间过程颗粒度。 |
| 类别 | 描述 |
|---|---|
| 现象 / 故障模式 | 单一记忆 Event 缺乏情境背景，未挂载至具体的 Scene ID 或 Task ID 上。 |
| 系统影响 | 导致 语境错位（Context Mismatch）。例如，在"做饭"的场景下错误召回"写代码"时的偏好。这种典型的熵增直接导致 Agent 人格偏移和用户体验中断。 |
| 设计原则 | 记忆必须有"锚点"。Memory 的隔离性（Isolation）是召回准确性的底线，应将零散的对话聚合为"有情境边界的块"来对抗"记忆孤岛"。 |
如果说存储是打地基，召回就是走钢丝。我们在落地中收到的最激烈的业务反馈往往聚焦于此，实践中的召回往往存在着"效果-速度-泛化能力"的不可能三角。
| 项目 | 说明 |
|---|---|
| 挑战名称 | 宁缺毋滥：业务方对"过召"的恐惧 |
| 关键矛盾 | 业务方，尤其是 B 端客户，普遍强调 "宁可少召，也不能把整个情境污染掉。" |
| 后果分析 | 如果召回了错误的历史信息（例如，将旧的错误价格带入新的报价单），这不仅无法减熵，反而会成为严重的 误导。这是一种典型的熵增效应。 |
| 设计结论 | 高可用 Memory 的召回结果，不仅要具备相关性（Relevant），更要保证 低歧义性（Unambiguous）。召回策略必须以防止污染为最高优先级。 |
| 项目 | 说明 |
|---|---|
| 挑战名称 | 信息茧房：向量相似度陷阱 |
| 机制陷阱 | 如果 Memory 召回过度依赖 向量相似度，即只关注当前 Query 的字面相似度，系统很容易陷入局部最优解。 |
| 现象描述 | 当用户表达模糊的意图（如"还是以前那个老问题"）时，传统的检索只匹配"老问题"这三个字，而无法理解其指代的是"上周二讨论的数据库死锁"。 |
| 工程评价 | 这体现了 Memory 缺乏多跳逻辑推理的能力。记住了许多数据，但缺乏根据情境判断和深层关联的能力。 |
| 项目 | 说明 |
|---|---|
| 挑战名称 | "不可能三角"中的时延压力 |
| 工程难度 | 真正有价值的回忆往往是多步间接相关的（类似于多跳问答，Multi-hop QA）。 |
| 时延挑战 | 为了不拖慢整体对话的用户体验，我们必须在 500ms 的极短时延预算内，完成复杂的召回流程：粗排 → 精排 → 甚至小规模 Agentic Search。这不仅是算法的挑战，更是对工程架构的极致考验。 |
| 项目 | 说明 |
|---|---|
| 挑战名称 | 模型易理解的保证 |
| 核心要求 | 召回任务不只是将历史数据搬运出来，而是要确保搬运出来的形态是模型好消化的。 |
| 实践要求 | 召回的片段必须以清晰、简洁、带语境说明的形式拼接到上下文。模型接收到的不应该是"几句莫名其妙出现的旧话"，而必须是有背景的结构化的提示。 |
核心总结：召回阶段的任务，不是为了证明"我记住了"，而是"在极短时间内，选出那几条能对当前决策产生真实减熵效果的记忆"。
好的 Memory 产品，核心工作就是做好这道"门卫"：把模型真正需要的那点东西，在 500ms 内准备好，挡住噪声，放进信号。这就是 Context Engineering 在工程侧最极致的减熵体现。
在上一章，我们列举了 Memory 设计中的"不可能三角"：要存得全又要召得准，要理解深又要速度快。面对这些矛盾，单纯堆砌向量数据库（Vector DB）是无法解决问题的。
我们最近探索的解法，是利用信息的"层级性"。我们参考人类大脑的运作机制，设计了一套 "三层存储 + 三层召回" 的架构，兼顾信息留存和使用效率，将 Context Engineering 的熵减过程工程化。
不是简单地把对话"扔进库里"，而是像图书管理员一样，对信息进行三级"提纯"。Event 保底不丢细节，MemoryBook 保证任务有情境，Record 把长期认知抽成高密度标签。三层协作，将"原本混沌的数据流"逐级清洗为低熵的上下文。
存得好是为了用得好。在召回侧，我们针对"时延"与"准确性"的矛盾，设计了一套从近到远、从快到深的路由机制。
这套"三层存、三层用"的架构，在实际落地的内部评测中，带来了显著的体验质变：
时序记忆的突破：
在面对 "我去年今天在做什么？" 这类强依赖时间线索的召回任务时，仅使用基础模型（Qwen3-coder）的准确率约为 45%（容易产生幻觉或遗忘）；接入分层 Memory 后，准确率提升至 88%。这证明了结构化存储对"时间熵"的有效抑制。
长链路任务的"减负"：
在复杂的 Coding 或教学场景中，用户被迫"重复说明需求与约束"的次数大幅下降。Memory 成功充当了"维持任务骨架"的角色，让 AI 的行为在跨越数天的会话中依然保持逻辑一致。
人格稳定性：
"人格错乱"与"跨会话断档"问题显著缓解。Memory 不再是零散的回忆片段，而是支撑 Agent 维持长期"人设"的脊梁。
当我们从代码与架构的细节中抽身，重新审视 Context Engineering（语境工程）的演进，会发现我们正在构建的不仅仅是一个更聪明的数据库，而是 人类与机器在认知层面深度耦合的开端。
Context Engineering 2.0 论文中曾预言，随着机器智能的提升，熵减的主力将逐步发生转移。
在当前的 CE 1.0 与 2.0 阶段，Memory、知识库（Knowledge Base）、工具集（Tools）本质上仍是人类工程师为模型搭建的"脚手架"。我们通过精密的 Prompt 设计和分层存储策略，手动帮助尚不具备完备心智的模型过滤噪声、提取意图。
而在未来的 CE 3.0 乃至 4.0 时代，随着模型本身推理能力与长窗口技术的突破，机器将具备自主感知、推断和构造上下文的能力。届时，Memory 系统将不再仅仅是被动的存储容器，而会演化为模型主动的 "注意力器官"，能够自主地在海量数据中进行熵减，捕捉那些人类甚至未曾意识到的隐性关联。
有评论将极致的 Context Engineering 愿景称为一种 "数字在场（Digital Presence）"。
当一个 Memory 系统经过充分的工程化设计，它所承载的便不再是冰冷的日志，而是用户知识结构、行为习惯、决策风格与情感偏好的完整映射。从这个意义上说，Memory 正在逐步形塑一个关于用户的"低熵模型"。
这个模型既是 AI 理解用户的基石，也是用户在数字世界中的投影。它不仅帮助 AI 在"此时此刻"提供精准服务，更在时间维度上沉淀了用户的"存在感"。Memory 让 AI 的交互不再是离散的计算，而变成了连续的陪伴；它让用户感到的不再是工具的冷漠，而是被理解的共鸣。
当我们今天严谨地设计 Memory 分层策略、致力于为机器做"熵减"时，我们一方面是在致力于让 AI 的交互更加平滑、高效；但从更深远的尺度来看，我们或许正在搭建一套可计算的 "自我叙事（Self-Narrative）"。
也许若干年后，当我们回望今天的 Context Engineering，会发现我们并不只是在给模型提供上下文，也是在往外搭建一个关于"我是谁"的稳定刻画。
如何在"让机器更有用"和"保护人作为主体的开放性"之间寻找平衡，可能就是下一代 CE 3.0 时代真正的哲学命题。
以下清单旨在帮助您从"熵减"的视角，审视系统设计的合理性与必要性。
Context Engineering 的本质是消除不确定性。但在资源有限的前提下，我们无法同时解决所有问题。请先明确您的业务痛点主要集中在以下哪一类：
在系统架构设计阶段，请检查您的方案是否回应了以下关键问题，以避免工程层面的熵增：
记忆层级（Hierarchy）
命名空间与隔离（Namespace & Isolation）
存储与使用的策略（Storage vs. Usage）
熵增监控与反馈（Monitoring & Feedback）
在思考 Memory 系统的价值时，我们不应仅仅停留在"开发一个很酷的功能"这一层面，而应将其转译为具体的场景价值：
当然，从零构建一套理想的"低熵"系统并非易事。如果您正在探索如何将上述分层设计高效落地，腾讯云数据库 Memory 产品或许能为您提供一种成熟的实践参考。
我们正在通过"短中长"三层架构来解构复杂记忆：利用中期 MemoryBook 辅助维护任务连贯性（应对过程熵），通过长期画像积累用户偏好（缓解意图熵），配合支持逻辑多跳的 Agentic Search 与快召回路径的极速响应，我们希望在知识熵的治理上为用户提供更精准的检索支持。愿这套基础设施能帮您省去底层的重复建设，让您能更专注于打磨上层的业务价值。
如希望进一步了解产品，可点击产品官网页面了解更多：
产品官网：https://cloud.tencent.com/document/product/1813/123054