1. 项目概述：一次对Claude Code源码的深度“解剖”

最近，我花了相当长的一段时间，沉浸在对Claude Code开源项目源码的研读中。这并非一次简单的代码浏览，而更像是一次技术“考古”和“逆向工程”。我的目标很明确：弄清楚像Claude这样的AI助手，其“记忆”功能究竟是如何在底层实现的，以及为什么我们时常感觉它“记不住事”，或者记忆得“支离破碎”。这个项目标题——“我们研究了Claude Code的源码。以下是Anthropic的AI如何真正实现记忆，以及为何它是‘坏的’”——精准地概括了这次探索的核心：从源码出发，理解机制，并诊断问题。

对于任何与大型语言模型（LLM）打交道的人，无论是开发者、研究者还是深度用户，“记忆”都是一个既迷人又令人沮丧的话题。我们惊叹于AI能记住几分钟甚至几小时前对话的细节，但也常常为它突然“失忆”、混淆上下文或产生“幻觉”而抓狂。这种不一致性背后，是技术原理、工程实现与用户期望之间的巨大鸿沟。通过直接分析Claude Code（作为理解Claude/Anthropic技术栈的一个窗口）的源码，我们可以越过营销术语和表面现象，直击其记忆系统的设计哲学、核心数据结构和运行时的状态管理逻辑。

这次分析不仅对技术极客有吸引力，对于任何希望更高效利用AI、理解其能力边界，甚至是在自己项目中设计类似“记忆”系统的开发者，都具有直接的参考价值。你会发现，AI的记忆远非一个简单的“存储-读取”数据库，而是一系列复杂权衡下的精巧（有时也是笨拙）的工程解决方案。接下来，我将带你一起，沿着源码的线索，拆解这个“记忆黑盒”。

2. 记忆系统的核心架构与设计哲学

2.1 上下文窗口：记忆的物理边界与“滑动窗口”机制

几乎所有现代LLM的“记忆”都始于一个最根本的限制： 上下文窗口（Context Window） 。在Claude Code的源码中（具体体现在模型调用和上下文管理的相关模块里），这个窗口大小是一个硬编码或配置决定的参数，比如常见的4K、8K、16K、100K甚至200K tokens。

注意 ：Token是文本的基本处理单元，一个英文单词大约等于1-2个tokens，一个中文字符通常为1-2个tokens。因此，一个100K的上下文窗口，大约能容纳7-8万英文单词或5-6万中文字符的文本量。

这个窗口就是AI短期记忆的“工作台”。所有输入（你的问题、历史对话、系统指令、检索到的文档）和模型即将生成的输出，都必须被塞进这个有限的窗口里。源码中最核心的记忆管理逻辑，都围绕着如何高效、合理地利用这块“宝贵的内存”展开。

“滑动窗口”是默认且基础的策略 。当对话轮次增加，新的输入和模型生成的回答不断追加到上下文末尾，导致总tokens数超过窗口限制时，最古老的消息就会被从窗口的“头部”移除，为新的内容腾出空间。这就像是一个固定长度的传送带，新的内容从一端加入，最旧的内容就从另一端掉下去。

在Claude Code的对话状态管理类（可能命名为 ConversationHistory 或 ContextManager ）中，你可以清晰地看到类似 trim_messages_from_start(max_tokens) 这样的方法。它的逻辑通常是：

1. 计算当前所有消息（messages）的tokens总数。
2. 如果总数超过 max_context_tokens （最大上下文tokens数），则从消息列表的开头移除最旧的一条或几条消息（通常是用户和AI的对话对），直到总tokens数低于某个安全阈值（例如 max_context_tokens - reserved_for_completion ，为生成答案预留空间）。

为什么这是“坏”的？ 问题显而易见： 记忆是“失忆式”的，而非“总结式”的 。被移出窗口的信息就彻底消失了，模型无法再引用或回忆起它们。一场漫长的对话进行到后半段，AI可能已经完全忘记了最初你们讨论的目标和关键约束条件。这对于需要长期连贯性的任务（如编写一个完整的软件模块、进行多步骤的复杂分析）是致命的。

2.2 键值缓存（KV Cache）：注意力机制下的“记忆痕迹”

比滑动窗口更底层的是模型推理过程中的 键值缓存（Key-Value Cache, KV Cache） 。要理解这一点，需要一点Transformer架构的基础知识。Transformer的注意力机制在计算某个位置的输出时，需要查看序列中所有之前位置的“键（Key）”和“值（Value）”向量。

在生成式任务中（比如AI逐字生成回答），如果每次生成新token都重新计算整个历史序列的Key和Value，计算量将极其庞大。因此， KV Cache应运而生 。在Claude Code的模型推理代码（通常涉及 transformers 库或自定义的CUDA内核）中，你会看到一个缓存对象，它存储了之前所有已处理tokens的Key和Value向量。

当生成下一个token时，模型只需要计算当前新token的Key和Value，并将其追加到缓存中，然后基于整个缓存（历史+当前）计算注意力。这样， KV Cache在技术上实现了对历史序列的“记忆” ，它使得模型在生成时能“感知”到整个上文。

为什么这依然是“坏”的？ KV Cache的“记忆”是 完全线性、原始且未加工的 。

1. 它缓存的是原始向量，而非语义 ：缓存的是数学向量，而不是“用户三分钟前想要一个蓝色主题”这样的抽象概念。模型需要每次通过注意力机制重新“解读”这些向量。
2. 它受限于上下文窗口 ：KV Cache的大小与上下文窗口严格绑定。窗口满了，最早的KV对同样会被丢弃。它只是滑动窗口机制在计算层面的体现，并没有提供超越窗口的长期记忆能力。
3. 它是计算优化，而非记忆优化 ：KV Cache的首要目的是加速生成，而非增强记忆的保真度或持久性。它不能主动选择记住什么、忘记什么，也不能对记忆进行压缩或提炼。

2.3 系统提示词（System Prompt）：静态的“背景记忆”

在Claude Code的消息处理流水线中，通常会在用户消息（User Message）和AI助手消息（Assistant Message）之外，发现一个或多个 系统提示词（System Prompt） 。这些提示词在对话开始时被注入上下文窗口的最前端，并（在滑动窗口机制下）尽可能长时间地保留。

系统提示词定义了AI的“角色”、“行为准则”、“能力范围”和“对话目标”。例如，“你是一个乐于助人的编程助手，代码要简洁高效。” 这构成了AI一种 静态的、背景式的长期记忆 。只要系统提示词还在上下文窗口内，AI就会持续受到它的影响。

为什么这不够好？ 系统提示词的记忆作用非常有限：

1. 容量极小 ：它只占上下文窗口的一小部分，无法记录具体的对话细节。
2. 内容静态 ：它通常在对话开始后就不再改变，无法动态更新以反映对话中产生的新的重要共识或决策。
3. 优先级冲突 ：当上下文窗口紧张时，为了容纳更多具体对话内容，系统提示词也有可能被部分截断，导致AI“忘记”自己的基本人设或规则。

3. 超越基础架构：工程上的记忆增强策略

基于上述核心架构，Claude Code的源码中还会体现出一些工程上的策略，试图缓解“失忆”问题。但这些策略往往引入了新的复杂性和问题。

3.1 摘要生成（Summarization）：有损压缩的尝试

一种常见的策略是 主动摘要（Active Summarization） 。当对话历史即将超出上下文窗口时，不是简单地丢弃最老的几条消息，而是调用模型自身（或一个更小的摘要模型），将窗口中最旧的一部分对话内容（比如前10轮问答）压缩成一段简短的摘要。

在源码中，你可能会发现一个独立的 Summarizer 模块或一个 create_summary_of_history() 函数。这个摘要随后会作为一个特殊的“系统消息”或“用户消息”被插入到上下文窗口中（通常放在剩余原始历史的前面），替代被移除的原始文本。

实操要点与陷阱 ：

• 触发时机 ：摘要的触发需要精心设计。是在历史tokens达到窗口的80%时触发？还是每固定轮次触发一次？过早触发浪费算力，过晚触发可能导致在摘要生成前就因超限而报错。
• 摘要质量 ：摘要的保真度是关键。一个糟糕的摘要可能会丢失关键细节（如具体的数字、名称、否定词“不”），甚至引入错误。源码中需要处理摘要模型的可能失败或产生无意义内容的情况。
• 上下文污染 ：摘要文本作为一条新消息加入，其本身的角色（是系统、用户还是助手？）需要谨慎设定。错误的角色可能导致模型对摘要内容的解读出现偏差。

为什么这依然是“坏”的？ 摘要是一种 有损压缩 。信息必然丢失，且丢失什么是不可控的，取决于摘要模型的能力和倾向。更严重的是， 摘要的摘要 问题：在多轮摘要之后，信息可能失真到面目全非。此外，生成摘要本身需要额外的计算开销和延迟。

3.2 向量检索与外部记忆体：引入“第二大脑”

更先进的策略是引入 外部记忆体 。Claude Code的架构中可能包含与向量数据库（如Chroma、Pinecone、Weaviate）交互的模块。其工作流程通常是：

1. 记忆写入 ：将对话中的每一轮（或每一段有意义的文本）通过嵌入模型（Embedding Model）转换为向量，并存储到向量数据库中，同时关联原始文本和一些元数据（如时间戳、对话ID）。
2. 记忆读取 ：当用户提出新问题或模型需要生成回答时，首先将当前查询（或最近的对话上下文）也转换为向量，然后在向量数据库中进行相似性搜索，召回最相关的若干条“历史记忆片段”。
3. 上下文注入 ：将这些召回的记忆片段，以某种格式（如“相关背景：...”）插入到当前上下文窗口的合适位置（通常是系统提示词之后，最新对话之前），供模型参考。

在源码中，你会看到 VectorStoreClient 、 embed_text 、 search_similar 等类和方法。这是目前实现“长期记忆”最主流的技术路径。

核心实现细节与挑战 ：

• 嵌入模型的选择 ：嵌入模型的质量直接决定了检索的准确性。是使用与主模型同系列的嵌入模型，还是专门优化的模型（如OpenAI的text-embedding-ada-002）？源码中需要配置嵌入模型的端点、API密钥或本地路径。
• 分块（Chunking）策略 ：如何将对话流切分成有意义的片段进行存储？是按句子、按段落、按完整的Q-A对，还是按语义边界？分块大小直接影响检索的粒度。
• 检索时机与策略 ：是每次用户提问都检索？还是定时检索？检索多少条记忆（top-k）？相关性阈值设多少？召回的记忆如何排序和去重？
• 记忆注入格式 ：如何将召回的记忆文本格式化后插入上下文？直接拼接可能导致模型混淆。常见的做法是使用明确的标记，如 [相关记忆 1]: ... ，并可能附带置信度分数。

为什么这看起来很好，但实际也“坏”？

1. 相关性不等于连贯性 ：向量检索基于语义相似性，它能找到“相关”的历史片段，但无法保证这些片段能拼凑出一个 连贯、完整、时序正确 的故事线。模型可能同时看到来自对话不同阶段、甚至相互矛盾的记忆片段。
2. 上下文窗口的二次竞争 ：检索回来的记忆本身要占用宝贵的上下文窗口空间。如果检索过多，会挤占当前对话的空间；检索过少，可能遗漏关键信息。这需要动态的、权衡的算法。
3. “冷启动”与“记忆洪水” ：对话初期，记忆库是空的或内容很少，检索帮助不大。对话后期，记忆库庞大，检索可能返回大量内容，造成“信息过载”。
4. 更新与遗忘问题 ：外部记忆体通常只增不删。错误的、过时的信息会一直存在，并在未来被检索到，污染当前判断。实现一个有效的“记忆遗忘”或“记忆更新”机制非常复杂。

3.3 函数调用与状态持久化：将记忆“卸载”到外部系统

对于一些结构化的信息，Claude Code可能通过 函数调用（Function Calling） 能力，将记忆任务“卸载”给外部系统。例如，在编程对话中，AI可以调用一个 update_project_specification(document) 的函数，将用户提到的项目需求写入一个外部的项目管理系统或数据库。当后续需要时，再通过 get_project_specification() 函数读取。

这在源码中体现为工具调用（Tool Calling）或函数调用（Function Calling）的处理模块。AI模型输出一个结构化的调用请求，后端代码执行该调用并返回结果，再将结果注入上下文。

这种方式的局限性 ：

• 适用范围窄 ：只适用于高度结构化的、可定义的信息（如项目规格、待办列表、用户偏好设置）。对于自由文本对话中丰富的、非结构化的细节，难以用固定的schema来捕获。
• 依赖精确的指令理解 ：需要模型非常准确地理解何时该调用函数、调用哪个函数、以及如何构建调用参数。这本身就是一个容易出错的环节。
• 增加了系统复杂性 ：需要维护一套完整的外部状态存储和API系统。

4. “记忆”为何是“坏的”：系统性瓶颈与根本矛盾

通过对Claude Code源码的剖析，我们可以看到，AI记忆的“坏”并非某个单一模块的bug，而是一系列 根本性架构限制和工程权衡 下的必然结果。

4.1 核心矛盾：无限记忆需求 vs. 有限上下文窗口

这是最根本的矛盾。人类的对话记忆是近乎无限的（长期记忆），并且我们拥有强大的信息检索（回忆）和压缩（总结）能力。而当前LLM的上下文窗口，即使扩展到100万tokens，相对于人类一生可能接收的信息量，也是极其有限的。所有技术手段（滑动窗口、摘要、检索）都是在用有限资源应对无限需求，注定是捉襟见肘的妥协。

4.2 注意力机制的“平等主义”与记忆的“重要性分层”

Transformer的注意力机制本质上是“民主”的。在计算当前token时，它会考虑上下文中所有历史token，但其“关注度”（注意力权重）是基于即时计算的相关性，而非基于该信息本身的重要性。一个至关重要的任务目标（在对话开头提出）和一个无关紧要的寒暄（刚刚发生），在注意力机制面前是“平等”的候选者，谁更能影响当前输出，只取决于其向量表示与当前查询的匹配程度。

然而，有效的记忆需要 “重要性分层” 和 “主动管理” 。我们需要系统能识别出哪些信息是核心约束（“必须用Python写”），哪些是临时偏好（“暂时用这个变量名”），并对核心信息给予更高的持久性和可访问性。当前的架构缺乏这种显式的、基于语义的重要性评估和记忆生命周期管理机制。

4.3 符号与连接的割裂：难以处理精确指代和逻辑关联

LLM的记忆是基于高维向量空间的 连接主义 模式。它擅长捕捉语义相似性和统计规律。但对于需要 符号逻辑 精确处理的记忆任务，则非常吃力。

• 精确指代问题 ：当用户说“用我们刚才讨论的第一个方案”，AI需要准确地绑定“第一个方案”这个符号，指向之前对话中某个具体的、离散的提案。向量检索可能找到谈论“方案”的段落，但很难精确绑定到“第一个”。这需要更复杂的指代消解（Coreference Resolution）能力，而这不是当前LLM原生擅长的。
• 逻辑关联与推理链 ：记忆不仅是存储事实，还包括事实之间的逻辑关系。例如，“因为A，所以我们决定B，然后导致了C”。这种因果、条件、转折关系，在向量化的记忆片段中很容易丢失。当检索到A和C时，模型可能无法重建中间的推理链B。

4.4 幻觉与记忆混淆：当“想象”混入“回忆”

这是最危险的问题。LLM的生成本质是“基于概率的续写”，它并不严格区分“从训练数据中学到的知识”、“从本次对话历史中看到的事实”和“自己根据模式推断/编造的内容”。当上下文窗口内的信息不足或模糊时，模型会倾向于用其参数化知识（训练记忆）来填补空白，这就产生了 幻觉 。

在记忆的语境下，这表现为 记忆混淆 ：AI可能将不同对话中的细节混合在一起，或者将通用知识与本次对话的特定事实混淆。例如，用户之前提到他的狗叫“Max”，但后来在谈论宠物时，AI可能脱口而出一个更常见的狗名“Buddy”，因为它从训练数据中统计出“Buddy”是个常见的狗名，而“Max”这个特定记忆在向量空间中没有被足够强地激活。

5. 给开发者和用户的实用建议与避坑指南

理解了记忆为何“坏”，我们就能更有策略地使用它，并在自行开发类似系统时避开陷阱。

5.1 给开发者的架构设计建议

如果你正在基于LLM构建需要记忆功能的应用程序，从Claude Code的源码分析中，可以汲取以下经验：

1. 采用分层记忆系统 ：不要依赖单一机制。设计一个包含 “工作记忆”（短上下文窗口） 、 “外部向量记忆”（中长期语义记忆） 和 “结构化知识库”（关键事实、用户档案、系统状态） 的混合系统。让不同性质的记忆由不同的子系统负责。
2. 实现记忆的“读写分离”与“重要性标记” ：在存储记忆时，不仅存储文本和向量，尝试让模型（或一个分类器）为记忆片段打上重要性标签（如“关键约束”、“临时细节”、“背景信息”）。在检索时，优先检索高重要性的记忆，并在上下文紧张时优先保留它们。
3. 设计主动的记忆摘要与提问机制 ：不要被动地等待窗口满了才摘要。系统可以主动在对话的关键节点（如一个任务完成时）生成阶段性摘要。更高级的是，当检测到模型可能遗忘了关键信息时（例如，用户提到“像刚才那样”但检索不到明确指代），可以主动生成一个澄清性问题，让用户确认，而不是盲目猜测。
4. 为外部记忆实现“遗忘”策略 ：为向量记忆设计基于时间、使用频率或重要性的衰减机制。过时、低用的记忆可以归档或删除，避免污染检索池。
5. 严格测试记忆边界 ：构建系统的测试套件，必须包含长对话一致性测试、指代消解测试、关键信息持久性测试。模拟用户进行数十轮对话后，突然询问最初设定的目标，看系统能否正确回答。

5.2 给用户的对话策略与心理预期

作为最终用户，了解这些原理可以帮助你更有效地与AI协作：

1. 主动进行“记忆管理” ：不要把AI当作有完美记忆的伙伴。在长对话中，定期 主动地、显式地 重申关键信息和目标。例如，“让我们回顾一下，我们这个会话的目标是写出一个数据处理脚本，要求是A、B和C。”
2. 使用清晰的指代和结构化输入 ：避免使用模糊的指代，如“那个方法”、“上面的代码”。改用明确的标识，如“在步骤2中你提供的 calculate_score 函数”。将复杂需求分点、结构化地列出，便于AI理解和后续检索。
3. 接受“重启对话”作为一种工具 ：当对话变得冗长、混乱，AI开始出现明显记忆混淆或性能下降时，最有效的方法往往是 开启一个新对话 ，并将之前对话的核心结论以清晰、简洁的方式粘贴到新对话的开头作为系统提示或第一条用户消息。这相当于手动执行了一次高质量的记忆摘要和上下文重置。
4. 利用外部工具辅助 ：对于极其重要、不容有失的信息（如项目最终方案、核心数据），不要完全依赖AI的对话记忆。自己用笔记软件、代码注释或项目文档记录下来。你可以让AI帮你生成这些记录（“请将我们刚才确定的三点需求总结成一段项目说明”），但保存和管理的责任在你。

AI的记忆系统是一个在强大能力与固有局限之间不断挣扎的复杂工程造物。通过阅读Claude Code这样的源码，我们得以窥见其内部齿轮的转动方式。它既不神奇，也不愚蠢，只是在现有技术范式下做出的一系列务实而艰难的选择。认识到它的“坏”，不是为了否定其价值，而是为了更聪明地与之共舞，在它的能力边界内，创造出真正可靠和高效的人机协作体验。未来的突破，或许在于全新的模型架构（如状态空间模型、递归模型），或许在于更精巧的混合系统设计，但在此之前，理解并适应当前的“坏”记忆，是我们每个人的必修课。