发帖
雷达卡
上下文工程并非LLM时代的新兴创造，其理论基础可追溯至20年前。本文基于上海交通大学等机构的最新研究，系统回顾了从Era 1.0到Era 4.0的发展历程，揭示其实质为熵减少过程：机器越智能化，人机交互成本越低。文章提供了收集、管理、使用的全面方法论，并前瞻地讨论了终身上下文与语义操作系统的未来。
今天为大家介绍一篇来自 上海交通大学、上海人工智能实验室（SII）和通用人工智能研究院（GAIR）联合发表的研究论文——《Context Engineering 2.0: The Context of Context Engineering》。
当你对ChatGPT说“继续上次的话题”，机器如何“记忆”并“理解”？当代码助手在数万行项目中精确定位问题，它如何从大量信息中筛选出真正相关的上下文？这些看似简单的互动背后，隐藏着一个被严重误解的领域—— 上下文工程（Context Engineering） 。
在我深入研读这篇论文后发现，大多数人对这个领域存在严重的误解。上下文工程不是Prompt技巧的集合，不是RAG的花样应用，更不是“如何榨干200K窗口”的优化手册。其本质远比这些深刻，其历史远比我们想象的久远，它塑造AI未来的方式远比表面看起来更加根本。
许多人认为上下文工程是LLM时代的新创造，将其视为Prompt设计或对话历史管理的代名词。然而，研究表明，上下文工程的理论基础可追溯至20多年前的普适计算时代。早在1990年代，学者们就开始探索如何使机器理解人类所处的情境。从1990年代的Context Toolkit到2025年的Claude Code，从被动的传感器融合到主动的智能协作，这场跨越二十年的演变，本质上是机器智能提升带来的人机交互成本持续降低的故事。更重要的是，我从论文中看到了一个深刻的洞见：上下文工程的本质是熵减少过程——将高熵的人类意图转化为低熵的机器表示。机器越智能化，人类需要做的“翻译”工作就越少。
从更深层次的哲学角度看，人类在交流时能够通过共享知识、情感线索和情境意识主动降低信息熵，推测出对方省略的背景。但机器缺乏这种脑补式的“填补空白”的能力，必须依赖人类将高熵的意图转化为低熵的、机器可理解的表示。这种转化所需的“努力”程度，恰恰与机器智能水平成反比：机器越智能化，人类需要做的预处理就越少。
每次智能飞跃都引发范式转变，这一过程遵循清晰的循环模式：技术突破带来上下文同化能力的激增，推动界面革命，最终导致范式转变。这不是渐进改善，而是一系列质的飞跃，每次飞跃都从根本上重新定义了人机交互的方式。
这篇文章将基于研究论文，带你系统回顾上下文工程的理论框架、历史脉络和实践方法论，并展望Era 3.0（人类级智能）和Era 4.0（超人类智能）的未来图景。让我们一起重新认识这个塑造AI未来的关键领域。
上下文工程演进过程
上图可以看到，技术突破带来上下文同化能力的激增，推动界面革命，最终导致范式转变。这不是渐进改善，而是一系列质的飞跃，每次飞跃都从根本上重新定义了人机交互的方式。
理论基石：形式化定义与哲学内核
你可能会问：既然上下文工程如此重要，那么它的“第一性原理”是什么？如果我们不想只是照搬现有实践，而是想真正理解其本质，甚至预测其未来，我们需要什么样的理论框架？
答案是：上下文工程的本质，是一个 熵减少过程 。
这一洞见解释了为什么人类能用“老地方见”三个字完成约定，而机器需要完整的地址；解释了为什么GPT-3的出现是分水岭，因为它首次让机器具备了部分“填补空白”的能力；也预示了为什么Era 3.0的到来将彻底改变人机关系——当机器的熵减少能力接近人类，我们将不再需要“翻译”自己的意图。
但在深入这一哲学内核前，我们需要一套精确的语言来描述上下文。数学，恰好提供了这种精确性。
形式化构造
上下文工程的严谨理论始于对基本概念的形式化。研究者首先定义了实体空间 E （包括用户、应用、对象、环境等）和特征空间 F （所有可能的表征信息），并通过特征化函数 Char：E -> P(F) 将每个实体映射到其特征集合。这里 P(F) 表示特征空间的幂集，意味着可以捕捉特征的任意组合。
交互被定义为用户与应用间的可观察互动，包含显性行为（如点击、命令）和隐性行为（如注意力模式、环境调整）。基于此，上下文 C 被形式化为：
其中
是与交互相关的实体集合。这一定义源自2001年Anind K. Dey的经典表述：“上下文是任何可用于刻画实体情境的信息，实体指人、地点或对象，这些实体被认为与用户和应用之间的交互相关，包括用户和应用本身。”
以Gemini CLI为例，当用户提出“查找关联文档”时，涉及的相关实体集合包括：用户（输入提示）、应用程序（系统指令、设置）、终端环境（工作目录）、外部工具（插件、搜索工具）、记忆模块（会话历史、知识存储）以及后端模型服务（功能范围、响应格式）。各个实体的特性化结果共同构成了总体上下文。
上下文工程则被界定为：
这种形式化定义看似学究，实际上非常深刻。它揭示了：
上下文不是“附加信息”，而是“情景的全面映射”。用户的一句话只是冰山一角，水面下是终端状态、项目历史、工具权限、模型能力的全方位交织。传统软件工程关注“输入→处理→输出”，而上下文工程关注的是“情境→理解→行动”——这是一个维度上的飞跃。
这就是为何我们要回顾20年前的理论——它们触及了超越特定技术的核心。
熵减少视角：揭示上下文工程的基本原理
现在，让我们深入探讨该领域的最深刻见解——它不仅解释了过去20年的所有变迁，还预示了未来20年的各种可能性。
人类交流的秘密，隐藏在一个信息理论的概念中：熵。
当你的朋友说“老地方见”，你立刻明白——无需完整地址，无需时间确认，甚至无需说明是哪个“老地方”。因为你的大脑自动完成了一项任务：减少信息熵。
你检索了共有的历史（上周去过的咖啡馆）、时间惯例（通常是下午3点）、当前情景（正在讨论周末计划）。大脑将这些高熵的信息片段，压缩成一个低熵的确切答案。这个过程，在信息理论中称为“熵减少”。
机器却无法做到这一点。
至少，在1.0时代完全无法实现，在2.0时代也只能部分实现。如果你在1990年代对计算机说“老地方见”，它只会无助地闪烁光标。即使在2025年，当你对Claude说“继续之前的思路”，尽管它能够勉强理解，但远不及人类那般自如。
这正是上下文工程存在的根本原因：机器的熵盲。
让我们用公式精确地定义这个过程（别担心，这个公式比你想象的简单得多）：
人类说“老地方见”（高熵，信息不完整，依赖背景），上下文工程的目标是将其转换为“2025年11月9日15:00，上海市徐汇区某某路123号星巴克”（低熵，信息完整，无需背景）。
但这里有一个关键洞见：
这项熵减少工作，不一定由人类完成。它的执行者，取决于机器的智能水平：
Era 1.0: 100%由人类承担（机器完全熵盲，需要完全结构化的输入）
Era 2.0: 50%由人类，50%由机器（LLM能理解自然语言，但仍需提示工程）
Era 3.0: 20%由人类，80%由机器（人类级别的智能，接近人类的“填空”能力）
Era 4.0: 0%由人类，甚至反过来（超人类智能，主动构建上下文）
这就是为什么机器越智能，上下文工程的“成本”越低——不是上下文工程消失了，而是其执行主体从人类转移到了机器。
这个视角解释了：
为什么GPT-3是一个转折点：它首次使机器具备了in-context learning，即部分熵减少能力
为什么提示工程如此重要：在2.0时代，人类仍需承担一半的熵减少工作
为什么3.0时代将彻底改变游戏规则：熵减少主体的转移，意味着人机关系的重塑
现在，这个理论框架已经建立。接下来，让我们看看它如何在20年的历史中得到验证。
上下文工程演进概览
两大设计原则
最小充分性原则（Minimal Sufficiency Principle）强调，系统应收集和存储仅任务所需的信息，价值在于充分性而非容量。盲目追求“越多越好”的反模式会导致噪音掩盖信号。
在实践中的体现是：不应收集“用户的所有浏览历史”，而应仅收集“与当前任务相关的浏览模式”。例如，代码助手无需知道用户昨天查看了哪些新闻，但需要了解用户最近查阅了哪些API文档。实践指导包括不断提问：这个上下文对任务是必需的吗？移除它会影响任务完成吗？如果答案是否定的，则不应收集或存储。
语义连续性原则（Semantic Continuity Principle）指出，上下文的目的是维持意义的连贯，而非数据的连贯。系统不必保存所有原始数据，但必须保持语义的可追溯性。
这意味着：保存完整的10万行对话原文不如保存经过抽象的“用户在数据处理项目中持续关注性能优化”这一语义核心。压缩和抽象是必要的，只要核心语义不丢失。这一原则为后续将详述的“自我烘焙”（上下文抽象）机制提供了理论依据。
这两大原则共同决定了上下文在智能系统中应如何被收集、保存和利用，为后续实践提供了哲学指导。
历史演进：二十年的智能跨越
理论已经建立，洞见已经揭示。但你可能会问：这真的是事后诸葛亮式的总结吗？熵减少视角真的能解释历史，还是只是一个美好的叙述？
让我们用历史来检验理论。
如果理论正确，那么：
1. 从1.0到2.0的转变，应该是机器熵减少能力的质变
2. 每个时代的架构设计，都应反映当时机器智能水平下的最佳熵减少策略
3. 当前的实践难题，可以用“熵减少能力不足”来解释
让我们来看看实际情况是否如此。但首先，看这张对比表——这不仅是一份信息的汇总，更是两个时代根本差异的全面概述：
上下文工程1.0与2.0对比
这张对比表揭示了关键的转变：技术背景从传感器融合转向语言理解，上下文模式从结构化信号转变为token序列，核心机制从规则驱动转向智能推理。更重要的是，上下文的容忍度和人性化水平的提高，标志着机器智能的重大变化。
这张表还隐含了一个深刻的趋势：每一项变化，都代表着机器智能水平的一次飞跃。让我们逐一深入探讨...
Era 1.0：被动执行者时代（1990年代-2020年）
技术与理论背景
Era 1.0的技术图景定格在从命令行界面（CLI）向图形界面（GUI）过渡的时期。虽然计算机普及到大众，但认知负担并未减轻，只是被重新分配。机器的能力界限显而易见：只能执行预设的程序逻辑，无法理解自然语言的语义，缺乏问题推理能力，错误处理能力较弱。
1991年，Mark Weiser提出了普适计算（Ubiquitous Computing）的概念，设想计算能够无缝融入日常生活，设备无需主动输入即可提供服务。1994年，上下文感知计算（Context-Aware Computing）框架进一步探索：系统能否感知用户状态、环境和任务，并动态适应？这些问题催生了核心议题——什么是“上下文”？如何定义、处理并使其机器可用？
2001年Dey的定义成为里程碑，强调了上下文的多维度（不是单一变量，而是多方面的信息集合）、关联性（相关性由互动决定，而非预先固定）和包容性（用户和应用程序本身也是上下文的一部分）。这一时期的理论研究广泛且深入，强调整体性和系统性的视角，与当前专注于对话历史的狭义趋势形成鲜明对比。
Context Toolkit的架构智慧
在实践中，Context Toolkit提供了从传统输入设备（键盘、鼠标）向分布式传感器网络转变的架构范式。该工具包围绕五个主要抽象组件构建：
- Context Widgets：封装传感器并提供标准化接口，类似于硬件抽象层，隔离底层传感器的复杂性和异构性。
- Interpreters：从原始上下文数据中派生高级语义，例如将GPS坐标转换为“在办公室”或“在通勤”。
- Aggregators：整合多个上下文源，融合位置、日程和时间信息推断出“在开会”的完整情境。
- Services：为应用提供上下文功能的API层，明确定义访问路径。
- Discoverers：支持上下文组件的动态注册与发现，类似于服务注册中心，实现运行时的灵活性和可扩展性。
以位置上下文为例，整个流程是：GPS传感器（Widget）提供原始坐标，解释器（Interpreter）将坐标转换为“在办公室”或“在通勤”，聚合器（Aggregator）结合位置、日程和时间推断出“在开会”，服务（Service）通过API将此情境提供给应用，应用据此触发“手机静音”操作。这种模块化设计使传感器、解释逻辑和应用逻辑各自独立发展。
这种关注点分离的架构——感知、解释、聚合、服务各司其职——以及模块化复用的设计理念，在Era 2.0中仍然适用，尽管具体技术已经更新。Context Toolkit的架构智慧超越了具体技术的生命周期：关注点分离、模块化复用、可扩展性——这些原则至今仍然有效。尽管今天我们使用大型语言模型而非传感器融合，使用向量数据库而非Widget接口，但“如何将异构信息源转化为统一语义表示”这一核心挑战并未改变。
本质特征
Era 1.0的上下文可以概括为“Context as Translation”（上下文即翻译）。人类意图需要被“翻译”成机器可读格式，翻译者是人类设计师，机器是被动接受者。交互模式是人机交互（Human-Computer Interaction），人类主动提供所有必要信息，机器严格按预设规则响应，没有真正的“理解”和“协作”。智能水平停留在被动执行者（Passive Executor），机器智能较低，上下文处理能力仅限于结构化的低熵信号，人机交互成本较高。
为什么今天的我们应关注这段20年前的历史？
因为Era 1.0留下了三个至今仍被低估的遗产：
- 遗产一：Context Toolkit的模块化智慧在今天仍然适用。看看你熟悉的现代系统：
RAG中的嵌入模型 = Context Widgets（封装异构数据源）
Chunk的语义切分 = Interpreters（提取高级语义）
向量数据库的检索 = Aggregators（整合多源信息）
Agent的记忆接口 = Services（提供标准访问）
相同的问题，不同的技术，相同的架构原则。当你在设计Agent的记忆系统时，Context Toolkit的五大抽象仍然是最佳实践。不是因为技术复古，而是因为它们触及了“如何将异构信息统一”这一超越时代的根本挑战。 - 遗产二：Era 1.0的“整体性视角”恰恰是Era 2.0最缺乏的。
1990年代的研究人员将上下文视为“用户-应用-环境-工具-状态”的整体。然而，现在我们通常狭义地认为上下文等于对话历史，这是一种显著的退步。
Claude Code的GEMINI.md、Windsurf的代码库理解和Cursor的项目背景——这些优秀实践，实际上都在重新探索Era 1.0的整体视角。不同之处在于：1990年代使用传感器收集环境信息，而2025年则利用大型语言模型来理解代码和文档。
遗产三：Era 1.0失败的原因，明确指出Era 3.0必须克服的方向。
为什么Context Toolkit没有得到广泛应用？问题不在于架构设计，而是机器智能不足——无论你如何巧妙地组织传感器数据，如果机器只能执行“IF-THEN”规则，所有努力都是低效的。
这预示着：Era 3.0的到来，不是依赖更精细的上下文组织技巧，而是依靠机器智能的根本变革。当机器真正具备人类级别的理解能力时，Era 1.0的许多理念将焕发新生——但执行者将从人类设计师变为AI本身。
历史不是负担，而是望远镜。它帮助我们明白：什么在变化，什么不变，什么即将来临。
Era 2.0：主动智能体时代（2020年至今）
范式转变的动力
GPT-3在2020年的发布标志着Era 2.0的开始。这不仅是参数量（1750亿）的突破，更是能力的质变：自然语言理解使机器能够处理“显示所有成年用户”这样的非结构化请求，而不仅仅是SQL这样的结构化命令；上下文内学习让模型可以从上下文中的示例中学习新任务，无需重新训练，上下文成为“临时程序”；推理能力的提升使机器能够逐步推理复杂问题，具备初步填补逻辑空白的能力，尽管仍与人类有差距。
上下文内学习的意义不仅在于无需重新训练，更在于它改变了上下文的性质：上下文不再是单纯的“数据”，而成为“临时程序”。通过精心设计的少量示例，人类实际上是在用自然语言为大型语言模型编写临时的任务规范。这预示了Era 2.0的核心特点——“上下文作为指令”。
上下文获取的革新
Era 2.0的传感器技术不仅在数量上激增，而且在多样性和覆盖面方面实现了飞跃。以下表格展示了按类别划分的代表性多模态上下文采集器：
按类别划分的代表性多模态上下文采集器
智能手机收集文本、图像、音频、位置和触摸信息（消息、照片、语音）；智能眼镜捕捉视频、注视、语音和场景上下文（眼动追踪、环境视频）；脑机接口记录神经信号和情绪状态（EEG、唤醒度、认知负荷）；车载系统监测位置、注视和驾驶行为（驾驶风格、视线方向）。这张表详细列出了个人计算设备、沉浸式技术、生理感知和环境系统等类别的代表性采集器。
关键洞察在于，Era 2.0不仅追求传感器数量的增长，更强调从每个传感器提取多样化的上下文信号。例如，智能手机不仅是通信设备，更是多模态上下文源，能够同时提供文本、图像、音频、位置和触摸等多种维度的信息。
更重要的转变在于原始上下文容忍度的提升。Era 1.0仅能处理结构化的低熵信号，如GPS坐标（37.7749, -122.4194）、时间戳（2024-01-15T10:30:00Z）和预定义状态（{"user_status": "active"}）。Era 2.0接受类似人类的表达：自由文本（“我想找一家适合约会的餐厅，预算200元左右”）、图像（直接上传照片询问“这是什么”）、视频（多帧时序信息的理解）。这意味着预处理需求大大减少，但并未完全消除——机器仍需上下文工程的支持。
从感知到协作的质变
Era 1.0的系统是“上下文感知”，被动感知并根据条件-动作规则触发响应。例如，“IF 位置 == ‘办公室’ THEN 手机静音”，这种响应基于“在哪里”而不是“在做什么”，无法理解用户意图或协作完成任务。
Era 2.0进化为“上下文协作”，主动理解意图并协作实现目标。当用户正在撰写研究论文时，系统分析已有的内容（已完成的段落）、当前写作意图（引言、方法、结果？）和论文结构惯例，主动建议下一段落的结构和要点。系统不仅感知环境，更理解任务，主动融入工作流程，成为协作伙伴。这种突破在于：不仅感知环境，更理解任务；主动融入工作流程；成为协作伙伴。
关键技术实践
Prompt工程成为用自然语言“编程”大型语言模型的艺术，通过系统提示定义角色和能力范围，通过少量示例提示引导行为，通过链式思维显式化逐步推理过程。其本质是用自然语言“编程”大型语言模型。
RAG（检索增强生成）克服了LLM训练数据截止日期的局限。其工作原理是在查询时检索相关的外部文档，并将这些文档注入到上下文中，从而基于增强后的上下文生成答案。这使得静态知识变得动态且可更新。
工具调用机制打破了LLM自身计算和访问的限制。由于LLM本身无法执行计算、访问数据库或联网等操作，工具调用机制使LLM能够识别需要工具的场景，生成工具调用参数，执行工具获取结果，并将结果作为新的上下文继续推理。例如，当用户询问“北京明天天气如何”时，LLM会调用天气API("北京", "2025-11-10")，API返回结果后，LLM整合这些结果生成自然语言回答。
长期记忆机制通过向量数据库存储历史对话的语义嵌入，在新对话时检索相关的历史上下文，从而实现跨会话的“记住”用户偏好和过往讨论。代表系统如Letta（MemGPT）展示了这种能力。
本质特征
Era 2.0的上下文是“上下文即指令”，上下文不仅是数据，更是引导模型行为的“程序”。Prompt工程的兴起证明了这一点。交互模式转变为人类-智能体交互，智能体具有主动性，能够规划、执行和反思，人类可以用自然语言表达高层次的意图，双向协作取代了单向指令。智能水平达到主动智能体，机器智能中等，接近或部分超越某些人类任务，上下文处理能力可以处理自然语言和部分多模态，人机交互成本降至中等水平，但仍需Prompt工程等人工介入。
Era 3.0与4.0：未来的跨越
Era 3.0对应人类级智能，推理与理解能力接近人类水平，标志着真正的通用人工智能（AGI）的萌芽。上下文能力将扩展到更丰富的维度：社交线索（微表情、肢体语言、说话方式）、情感状态（从语调、停顿、用词推断情绪）、复杂环境动态（多实体交互的理解）。AI将具备类似人类的推断能力，填补对话中的省略，理解隐含意图，从不完整的信息中构建完整的情境。此时，上下文表达为“上下文即场景”，不再是离散的信息片段，而是完整、动态的情境模型，机器可以在“场景”中推理和行动。人机关系演变为无缝协作，AI作为真正的知识伙伴——不再是工具，而是协作者，可以进行深度讨论、头脑风暴，提供洞察而不仅仅是执行指令。自然且流畅的交互无需刻意“翻译”意图。AI作为可靠的协作者，人机交互成本接近极低。
Era 4.0是超人类智能的愿景阶段。机器理解人类意图比人类自己更深刻，拥有“上帝视角”。范式根本反转：不再是人类定义上下文、机器适应人类，而是机器主动为人类构建新的上下文框架，揭示人类未明确意识到的需求，引导人类思考新的可能性。
围棋AI已经展现了这一点——职业棋手从AlphaGo等围棋AI学习全新的、超越人类传统的策略。AI不仅理解人类的棋路，还创造了人类未曾想象的棋路。这是Era 4.0的缩影。应用前景包括：科学发现（AI提出人类未想到的研究假设）、创意产业（AI启发全新的艺术形式）、决策支持（AI揭示隐藏的风险或机遇）、教育（AI为每个学习者构建最优化的认知路径）。哲学意义在于：人类不再是唯一的“意义制造者”，AI成为洞察与灵感的源泉，人机关系的深刻变革从工具→伙伴→导师。
此时，上下文表达为“上下文即世界”，上下文不是局部信息，而是完整的世界模型，AI在这个世界模型中模拟、推演、创造。交互模式是AI引导人类，主客体关系反转，人类向AI学习而非相反。智能水平为善解人意的大师，机器智能超人类，上下文处理能力远超人类，人机交互成本接近零（AI主动理解并引导）。
Era 3.0与4.0的根本区别在于主动权的归属。Era 3.0中，AI理解人类构建的上下文并在其中协作，人类仍是上下文的定义者。Era 4.0则反转了这一关系：AI不仅理解人类提供的上下文，还能为人类构建新的上下文框架，揭示人类未曾意识到的需求。围棋AI的例子生动说明了这一点——职业棋手从AlphaGo学到的不是如何在人类定义的棋理中下得更好，而是全新的、超越人类传统认知的策略体系。
回顾这二十年的跨越，我们看到上下文工程始终围绕同一核心：如何让机器更好地理解人类情境。Era 1.0教会我们上下文需要结构化；Era 2.0展示了智能提升如何降低熵减负担；Era 3.0和4.0则预示着人机关系的根本性重构。然而，理解历史只是第一步。接下来的问题是：在当前的Era 2.0，如何系统地收集、管理和使用上下文？这正是后续章节的重点。
上下文收集与存储：构建信息基础设施
理解了上下文工程的理论基础和历史演变后，一个自然的问题是：如何将这些理念转化为实际的系统设计？这需要从上下文的整个生命周期着手——从最初的收集与存储开始。
Era 1.0与2.0的存储模式对比
Era 1.0的上下文收集主要在单一装置（桌面电脑或早期智能手机）上进行，利用有限的传感器（GPS、时钟、键盘鼠标事件）或应用日志记录使用模式。存储实践以本地为主：日志文件、本地文件系统、简单的数据库存储结构化文档、临时状态保存在内存缓存或临时文件夹（关机即丢失）。尽管部分系统尝试上传到集中服务器，但受限于高延迟和不稳定的网络。这一时期的存储策略特点为孤立、非持久、以单机为中心。
Era 2.0实现了分布式多端协作。上下文来源扩展至多设备（智能手机、可穿戴设备、家庭传感器、云服务、第三方API）和多模态信号（文本、语音、图像、视频、传感器数据）。代理整合这些信号为连续的上下文流。存储策略采用分层架构，根据数据使用目的确定层级。
分层存储架构
短期存储（Short-term Storage）用于快速访问、频繁使用的临时数据，特点是速度非常快（内存级）、容量有限、持久性低（会话级或更短）。技术实现包括内存缓存（RAM）、边缘节点缓存和会话状态。典型数据包括当前对话历史、即时工具输出和临时推理状态。
中期存储（Medium-term Storage）用于需要中等时长保留的数据，特点是速度快、容量适中、持久性中等（天级、周级）。技术实现包括嵌入式数据库（如SQLite、LevelDB、RocksDB）、本地文件系统的结构化存储、安全存储模块（涉及敏感数据时）和硬件安全模块（高安全需求时）。典型数据包括活动记录、用户偏好和项目级上下文。
长期存储（Long-term Storage）用于需要长期保留、跨设备同步的数据，特点是速度相对较慢但可接受、容量大且可扩展、持久性高（永久或长期）。技术实现包括云存储平台、远程服务器数据库和分布式存储系统。典型数据包括历史对话归档、用户画像、知识库和跨设备同步的状态。
决策树逻辑明确：若需要极低延迟访问且会话级生命周期，选择短期存储；若需要跨会话保留且以本地设备为主，选择中期存储；若需要长期保留或跨设备同步，选择长期存储。
代码代理的特殊需求
代码任务通常周期较长、跨越多个会话，仅依赖单一上下文窗口并不现实（即使100k tokens也不足以应对复杂任务）。会话中断后如何恢复？解决方法是周期性的状态持久化：定期将任务状态和进度写入长期记忆，中断后从长期记忆恢复相关上下文。
Claude Code的结构化笔记机制是一个典型案例。系统维护外部结构化笔记文件，周期性地将关键信息从上下文窗口写入笔记，需要时从笔记检索信息注入上下文。笔记结构包括：总体目标、关键知识点、文件系统状态、最近的操作和当前计划。这种轻便但持久的机制支持长时间活动，防止上下文丢失。其价值在于轻便但持久、支持长时间活动、防止上下文丢失。
极端案例如管理数千步的Pokémon游戏策略，挑战在于管理如此庞大的游戏策略。解决方法是外部记忆系统追踪进度，重置后能无缝恢复。意义在于：外部结构化记忆将代理的规划视野扩展到远超上下文窗口的限制。
Era 3.0展望
Era 3.0的人类级上下文生态系统将在感知维度实现突破。触觉信息再现人类触觉体验（质感、压力、温度），嗅觉与味觉解释环境状况（烟雾=危险）或评估食物的新鲜度，细腻的社交信号捕捉声调、停顿、眼神接触甚至沉默的意义。
个人数字记忆的统一不再是“数据保存”，而是动态的认知基础设施：自主组织、精炼上下文以支持持续推理和跨场景互动、类似人类的“遗忘”与“回忆”能力。数据在本地与云端安全流动，用户对敏感信息保持绝对控制，同时受益于全局的知识和计算资源。记忆不再是技术细节，而是AI的“认知基础”，支持真正自然的长期人机共生，迈向人机自然共生。
上下文管理：从原始数据到可用知识
文本上下文处理的五种范式
时间戳标记法
为每条信息附加时间戳以保持生成顺序。实现示例显示每条消息都带有时间戳（如[2025-11-09 10:00] User: 帮我写一个Python排序函数）。优点在于实现简单、维护成本低、时序信息保留完整。但局限性明显：缺乏语义结构（时间戳不反映内容关系）、长程依赖困难（难以捕捉跨越多条消息的主题）、扩展性问题（存储线性增长，随序列变长模型难以聚焦关键信息）。适用场景包括简单的聊天机器人、用户活动监控和无需复杂推理的日志系统。
功能语义标签法
为每条信息添加功能角色标签和多维度标注。标签维度示例涵盖功能角色（目标、决定、行动、观察）、优先级（高、中、低）和来源（用户输入、工具输出、代理推理、外部知识）。实现示例展示结构化的JSON格式，包括内容、标签（角色、优先级、来源、时间戳）。优点在于结构化（便于检索和分析）、多维度（支持复杂筛选，例如“查找所有高优先级的目标”）和可解释（标签提供额外的语义信息）。缺点是略微僵硬（预定义标签可能不够灵活）、维护成本（需要可靠的人工或自动标注机制）和可能限制创造性合成（结构化可能妨碍自由组合）。适用场合包括复杂的代理系统（需要明确的角色分配）、需要可审计的应用（如医疗、金融）和多步骤工作流程管理。
QA对压缩方法
将上下文重组为问答对，每个QA对是一个独立的知识单位。实现示例展示了原始对话被转化为独立的问答对（如Q: Python有哪些排序算法？ A: Python内置Timsort，常用还包括快速排序、归并排序...）。优点在于检索友好（每个QA对都是独立单元，可以精确匹配）、适合FAQ系统和知识库、压缩率高（去除冗余对话）。缺点是破坏了思维流（原始对话的连续性丧失）、不适合需要全面理解的任务（如总结、深度推理）和生成QA对的质量取决于算法。适用场合包括FAQ机器人、知识库检索和客户服务系统。
层次化笔记方法
使用树状结构来组织信息，从宽泛的概念到具体的细节。实现示例展示了markdown格式的层次结构（如1 用户任务：优化Python代码性能 2 当前代码分析 3 优化方向 4 算法替换）。优点在于清晰地展现信息分组、易于导航和浏览、层次关系显而易见。缺点是仅反映分组而不反映逻辑关系（因果关系、证据关系、对比关系）、不捕捉时间演变（新见解如何产生、旧想法如何修正）和静态结构导致动态性不足。适用场合包括知识整理、文档生成和项目管理（任务分解）。代表性系统包括Claude Code和Gemini CLI的笔记系统以及各种笔记应用程序的代理化。
选择决策树清晰：如果任务需要精确的事实检索（如FAQ），选择QA对压缩方法；如果任务需要复杂的工作流管理，选择功能标签方法；如果任务需要知识整理和展示，选择层次笔记方法；如果只需要简单的记录和时间序列，选择时间戳标记方法。混合策略的可能性包括不同层级采用不同的范式，例如短期记忆使用时间戳，长期记忆使用层次笔记。
多模态上下文融合的三大策略
多模态上下文处理工作流
上下文在基于LLM的系统中变得越来越多样化，包含文本、图像、音频、视频、代码、传感器数据甚至是环境状态。随着机器与真实或模拟环境的互动，它们必须能够将跨模态信息整合成连贯统一的表示，而不是单独处理每个模态。核心挑战在于这些模态的异质性：它们在结构、信息密度和时间动态上存在差异。例如，文本是离散且有序的；图像是高维且空间分布的；音频是连续且随时间发展的；视频是时空的、多帧的且复杂。如何将这些异质模态联合编码、比较并推理？
共享向量空间映射
将不同的模态（文本、图像、视频）转换为共享的向量空间，使它们的意义可以直接对比。每个模态首先由各自的编码器处理（文本使用BERT、GPT等Transformer编码器；图像使用ResNet、ViT等视觉编码器；音频使用Wav2Vec等音频编码器）。由于这些向量最初位于具有不同统计特性的独立表示空间中，因此每个向量都通过学习的投影层传递，该投影层将其映射到固定维度的共享空间。在这个共享空间中，来自不同模态的相关语义内容位置彼此靠近，而不相关的内容则被推开。技术细节包括损失函数采用对比学习（如CLIP），共享空间特性使得文本"猫"的向量≈猫图像的向量，支持跨模态检索（文本查图像，图像查文本）。优点在于模态间可以直接对比、支持零样本跨模态任务和架构灵活。缺点是浅层对齐（仅在向量空间层面，没有深度融合）和细粒度对应困难（"猫在沙发上"→图像的哪个区域？）。适用场合包括跨模态检索（图搜图、文搜图）、零样本分类和多模态嵌入应用。
统一自注意力机制
将不同的模态转换为token序列（文本为word tokens；图像是patch tokens，采用ViT方法；音频为frame tokens），连接所有token，并输入到统一的Transformer中，通过自注意力机制使所有token相互关联。主要的创新点在于细致的跨模态交互：文本token可以关注到图像的特定patch，而图像patch也可以关注到文本的特定词汇，在每一层都进行了深入的融合。与浅层拼接相比：浅层拼接是对各模态分别编码→拼接向量→进一步处理；而统一自注意力则是从第一层开始就进行跨模态交互。这种做法的优点在于深入的融合（所有层都参与到跨模态的理解中）、灵活性（能够处理任何模态组合）以及端到端的学习。缺点是计算成本较高（自注意力O(N)，多模态token数量较大）并且需要大规模的预训练。代表系统包括GPT-4和Claude 4等现代多模态LLM。应用场景涵盖需要细致理解的任务（如图像描述、VQA，即视觉问答）和复杂的推理（需要文本和视觉信息协同作用）。
跨模态交叉注意力机制
使一种模态作为Query，另一种模态作为Key和Value，通过交叉注意力机制使Query集中于Key/Value的相关部分。机制解析以文本查询图像为例：Q = 文本特征（query），K, V = 图像特征（key, value），交叉注意力：Attention(Q, K, V) = softmax(Q·K^T / √d) · V，结果是文本特征得到增强（融入了相关的图像信息）。架构的灵活性体现在它可以作为一个独立的模块（位于Transformer之前）、可以嵌入到Transformer块内部以及可以双向（文本查询图像 + 图像查询文本）。优点在于明确的方向性（一个模态专注于另一个）、可控性（可以设计哪些模态间互动）和参数效率（不需要完全融合）。缺点是需要预先设定交互方向且不如统一自注意力灵活。代表性系统包括Qwen2-VL和Flamingo等。适用场合包括具有明确主次关系的任务（如图像描述：文本为主，图像为辅）和需要可解释性的应用（可以看到哪个文本token关注哪个图像区域）。
这三种策略代表了从浅到深的融合理念：共享空间映射实现了“可比较”，统一自注意力实现了“深入交互”，而交叉注意力则在这两者之间提供了“可控的定向融合”。选择哪种策略取决于具体任务对融合深度、计算资源和可解释性的平衡考虑。人类大脑的启示在于：大脑不必事先指定“视觉查询听觉”，多种感官信息能够自然地融合。未来的发展方向应该是开发更加自然、更加灵活的融合机制，比如动态路由、稀疏专家混合（MoE，Mixture of Experts）和层次融合。
上下文组织：构建认知框架
分层记忆结构
Andrej Karpathy的OS类比阐明了核心问题：大型语言模型如同CPU（计算核心），上下文窗口类似于RAM（工作内存，快速但容量有限），需要类似磁盘的长期存储。上下文工程就像操作系统（决定加载什么到内存）。人类认知的启示是工作记忆容量约为7±2项、持续时间为几秒到几分钟；短期记忆持续时间为几小时到几天；长期记忆持续时间为几天到终身。
转移触发条件包括重复频率（在短期记忆中频繁出现）、情感显著性（与用户的情绪、偏好相关）和知识关联（与现有的长期记忆有强烈联系）。记忆转移机制类似于人类：情景记忆（短期）→语义记忆（长期）。巩固过程包括识别短期记忆中的高价值信息、概括、去噪、压缩、写入长期存储并建立索引以便检索。
实际应用案例，例如LeadResearcher处理超长上下文任务（超过200k tokens）时，问题在于研究计划的关键信息可能超出上下文窗口。解决方案是将研究计划存储在持久化内存（长期记忆）中，防止因窗口限制而丢失关键信息，新任务时从长期记忆中检索相关计划。
当扩展到多层架构时，双层模型是一种简化（为了清晰），实际上系统通常包含更多层次：L0（当前token，即时）、L1（工作记忆，活跃推理状态）、L2（情景缓冲区，最近事件）、L3（短期记忆，会话级别）、L4（中期记忆，日/周级别）、L5（长期记忆，持久）、L6（语义知识，高度抽象、跨任务）。
上下文隔离
Subagent模式
这是Claude Code实践的一个例子。其核心机制是每个subagent都是独立的AI助手，拥有自己的上下文窗口、自己的系统提示和有限的工具权限。功能隔离按照功能维度划分：分析Subagent专注于代码分析和问题诊断，执行Subagent专注于代码编写和文件操作，验证Subagent专注于测试和质量检查。每个子任务被分配给相应的Subagent，Subagent在隔离的环境中运行。
层级隔离涵盖规划层（高层策略设定）、实施层（具体任务操作）和审核层（结果检验）。最小权限原则保证每个Subagent仅拥有其职责所需最少的工具集合，降低误用可能性，增强系统的稳定性和透明度。价值总结包括防止主环境污染、提高模块化和易维护性、扩展总token使用能力（每个Subagent具备独立窗口）。
LeadResearcher的并行子任务机制是：LeadResearcher首先制定方案，若信息不充分→启动查询，构建多个并行子任务（每个为独立Subagent），各子任务独立运行互不影响，LeadResearcher整合中期成果并决定后续步骤。反馈循环用于调整关键词、修正搜索策略直至得出高质量解答。优点在于比静态RAG更加灵活，能够动态调整而非一次性搜索。
轻量级引用技术适用于处理大量输出的情况。问题场景是一些工具产生极大数据输出（例如大型文件内容、长时间日志），直接嵌入上下文将消耗大量tokens。沙盒方法（如HuggingFace CodeAgent）将大量数据存储于外部沙盒，在上下文中仅保存轻量级引用（如文件ID、片段索引），必要时按需检索。基于Schema的状态对象将重量级元素（文件、日志）保持在外存，上下文仅展示schema的选择字段（实例：仅含文件路径、大小、修改日期，不含具体内容），需要内容时通过工具调用获取。其价值在于显著降低token消耗、维持完整上下文的可访问性并加快响应速度。
上下文抽象（自我烘焙）的哲学含义
自我烘焙的主要区别在于记忆存储与知识学习。记忆存储是指保存原始数据，回顾时重新查看，类似视频回放。知识学习则是提取抽象知识，形成可重复使用的模式，类似于从经历中提炼规则。
自我烘焙的定义是Agent有选择性地将其上下文转化为持久的知识结构，这不仅是简单的存储，而是一个学习过程。人类认知的比喻包括：情景记忆→语义记忆（情景：昨天在餐馆吃了四川菜；语义：四川菜通常很辣）和行为→习惯（行为：每天早上刷牙；习惯：自动化的早晨例行程序）。
自我烘焙的本质是将记忆存储转变为学习的关键机制。没有自我烘焙，Agent只能回忆；有了自我烘焙，Agent能积累知识、形成智慧。
四种实现方式
自我烘焙的典型设计
模式A：原始+自然语言摘要
保留所有原始上下文（对话、工具输出等），定期生成自然语言摘要。实现方式包括保留所有原始上下文和定期生成自然语言摘要（频率：每N轮对话、每M个token、或任务节点；生成方式：手动或由LLM自动生成）。
摘要内容结构（以Claude Code为例）包括：当前任务概述（总体目标：用户希望优化一个Python数据处理脚本的性能；关键知识：原脚本利用pandas处理百万行数据，主要障碍在于join操作的O(n?)复杂度，用户对numpy和polars有一定了解）、文件系统状态（已修改、新添、待处理）、最近活动（1. 分析了原代码的性能障碍 2. 建议使用哈希表优化join 3. 实现了优化版 4. 执行benchmark测试）和当前规划。
多层次摘要构成分级抽象（当摘要自身增长→摘要的摘要）。废弃策略基于时间（旧摘要的重要性减弱）或相关性（不那么重要的主题可删除）。
优点在于简便灵活（易于实施和调整）、人可读（有助于调试和理解）和LLM友好（自然语言便于模型理解）。缺点是没有结构（难以精确查询，如“所有与性能相关的活动”）、推理难（难以捕捉事件间的因果关系和进行复杂逻辑推理）和一致性挑战（多次摘要可能产生矛盾）。适合场景包括通用对话Agent、代码辅助工具（Claude Code、Gemini CLI）和需要人类监督和干预的系统。
模式B：直接结构化存储
将信息直接写入结构化格式（而不是先存原始再摘要），短期和长期记忆明确分层。存储结构示例显示JSON格式包含short_term_memory（current_session_id、active_context、working_state）和long_term_memory（user_preferences、learned_patterns、project_context）。
生命周期管理包括：短期记忆在会话结束时评估（重要的→转移至长期记忆；不重要的→抛弃）；长期记忆持久化，定期清除过期信息。
优点在于明确的生命周期（清晰的短期/长期界限）、易于管理（结构化方便查询和更新）和快速访问（数据库式查询）。缺点是需要预先定义结构（灵活性不及自然语言）、迁移成本（结构变化时需要数据迁移）和维护复杂度（schema设计和进化需要工程投入）。适用场景包括需要明确生命周期管理的系统、对查询性能有高要求的应用和多Agent系统（共享结构化记忆）。代表性系统如UI-TARS（任务型Agent）。
模式C：向量化逐步压缩
将上下文编码为语义向量（embeddings），分层抽象。实现机制包括：将上下文编码为语义向量，分层抽象（L1：初始embedding；L2：通过pooling，平均、最大等，压缩L1；L3：进一步压缩L2；...），每层代表不同抽象程度。Self-baking过程是旧embedding定期汇总（pooling）或与现有长期状态融合，重新编码形成更抽象、更稳定的语义记忆。
层次化记忆示例显示：L1（初始对话）包含[vec_1] "分析性能瓶颈"、[vec_2] "join操作慢"、[vec_3] "建议用哈希表"；L2（会话级摘要）通过[vec_A] = pool([vec_1, vec_2, vec_3])得到语义为"性能优化相关的一次讨论"；L3（主题级知识）通过[vec_X] = pool([vec_A, vec_B, vec_C, ...])得到语义为"用户关心数据处理性能优化的长期模式"。
优势在于紧凑（向量表示比文本节省空间）、语义搜索友好（相似度计算高效）、可扩展（可无限层抽象）和跨语言（向量是语言无关的）。局限是不可读（人类无法直接理解向量）、难以编辑（无法手动修正某个"记忆"）、黑盒性（缺乏可解释性）和需要ML模型（编码和检索都依赖模型）。适用场景包括大规模记忆系统（百万级以上条目）、语义搜索为主的应用和不需要人类干预的自动化系统。代表系统如H-MEM（层次化内存管理）。
模式D：原始上下文+固定Schema提取
保留原始上下文（备查），使用固定schema提取关键信息到结构化格式。实现机制包括保留原始上下文和使用固定schema提取关键信息到结构化格式。
Schema类型包括：类型1实体图谱（Entity Map），显示JSON结构包含entities数组，每个entity有id、type、name、properties、state和relationships；类型2事件记录模板（Event Records），包含event_id、timestamp、type、actor、object、action、context和outcome；类型3任务树（Task Tree），显示层次化结构包含task_id、goal、status和subtasks。
实际案例如CodeRabbit的代码审查，场景是PR（Pull Request）代码审查，挑战包括跨文件依赖理解、历史PR信息和团队特定规则。Schema设计包括：文件依赖图（哪些文件互相调用）、PR历史图（相关的过往PR和讨论）和规则库（团队编码规范、常见陷阱）。价值在于AI能在完整系统上下文中推理，而非仅看孤立的文件变化，提供更深入、更准确的审查意见。
优势在于结构化推理（支持复杂查询，如"所有失败的测试事件"）、精确检索（基于schema字段的精确匹配）、关系建模（图谱可表达复杂关系）和可审计（清晰的事件和状态记录）。局限是维护一致性困难（多层数据，原始+schema，可能不同步，需要严格的更新机制）、提取器设计挑战（如何可靠地从原始上下文提取schema？基于规则？基于ML？）和Schema演进（需求变化时schema需要调整，历史数据迁移成本高）。适用场景包括需要复杂推理的领域（代码理解、知识图谱）、审计和合规要求高的应用和多步骤工作流（任务树）。代表系统包括ChatSchema和CodeRabbit（代码审查）。
选择指南与混合策略
在实际系统设计中，可遵循以下决策流程：
第一步，评估人类参与度需求——若需频繁人工审核和调整，选择模式A（原始+摘要）；若希望完全自动化，考虑模式B/C/D。
第二步，评估查询模式——若主要是精确事实查询（"哪个文件定义了X函数"），选择模式D（Schema）或模式C（向量）；若需要理解完整思维流程，选择模式A。
第三步，评估规模——若记忆条目<10万，模式A/B/D均可；若>100万，模式C（向量）成为必需。
第四步，评估可解释性要求——若需要审计和调试，优先模式A或D；若仅需检索效果，模式C可行。
混合策略示例包括：
策略1层级混合：L1（短期记忆）用模式A（原始+摘要）→灵活、易修改；L2（长期记忆）用模式D（Schema）→结构化、易查询；L3（深度知识）用模式C（向量）→紧凑、语义搜索。
策略2任务混合：对话理解任务用模式A；代码分析任务用模式D；跨任务检索用模式C。
策略3渐进转换：初始用模式A（摘要）快速积累；阈值触发：当某主题的信息足够多，转换为模式D（Schema）；最终高度抽象为模式C（向量）。
工程实践建议包括：从简单开始（模式A），验证价值；根据痛点逐步引入结构化（模式B/D）；大规模后考虑向量化（模式C）；始终保留原始数据（备查和重新提取）。
上下文使用：让知识发挥价值
上下文利用涉及多个重要决策点，从系统内部共享到跨系统合作，从策略选择到积极推测。以下为全面的设计考量框架：
上下文工程设计考量因素
此图系统地展现了上下文工程在收集、存储、管理及运用三大核心维度上的设计考量，为实践提供了详尽的指导蓝图。
系统内部上下文共享
跨代理上下文共享模式
现代大型语言模型应用通常由多个代理构成，每个代理负责部分推理工作流程。其实质价值在于多代理扩展了总的令牌消耗能力。主要挑战在于如何在代理之间传递信息，以及如何确保信息的准确性、可解释性和实用性。
提示嵌入模式
直接将先前的上下文纳入下一个代理的输入提示中，通常结合格式重组（如摘要、结构重组）。一个实现示例是代理A完成分析任务后输出分析结果，代理B的输入提示包含“前序分析结果：[代理A的输出] 请依据以上分析，编写优化后的代码。”变体是格式重组，将代理A的长篇输出（例如3页分析报告）重组为结构化摘要（例如5点列表），以便代理B迅速理解。
优点在于实现简便（无需额外基础设施）、灵活（可根据需求调整传递的信息）和透明（信息流动清晰可见）。缺点是上下文膨胀（随着代理链的增长，提示变得越来越长）、信息冗余（可能重复传递不相关信息）和格式不一致（不同代理可能对格式有不同的理解）。适用场合包括顺序工作流（A→B→C）、代理数量较少（<5个）和快速原型。代表性系统包括AutoGPT（早期版本）和ChatDev（多代理软件开发）。
结构化消息交换
通过固定模式的消息通信，类似于微服务之间的API调用。消息模式示例展示JSON格式包含message_id、from、to、timestamp、task_type、input_data、output_requirements和reasoning_context。模式设计原则包括明确的任务类型字段、结构化的输入数据、清晰的输出要求和可选的推理上下文（帮助接收代理理解背景）。
优点在于清晰且一致（所有代理遵循相同的协议）、可验证（可以自动检查消息格式的正确性）、可扩展（新的代理只需遵循模式即可接入）和易于调试（消息可以被记录、重放）。缺点是设计成本（需要前期投入设计模式）、灵活性降低（模式更改需要所有代理更新）和冗余字段（某些代理可能不需要所有字段）。适用场合包括复杂的多代理系统（>5个代理）、需要可靠性和可维护性的生产环境和多团队合作（模式作为接口契约）。代表性系统包括Letta和MemOS。
共享记忆模式的核心理念是代理不直接通信，而是通过读写共享记忆空间间接协作，类似于黑板系统（Blackboard System）。
子类型1 记忆块池采用集中的记忆池，每个代理可读写记忆块。记忆块结构包含block_id、author、timestamp、type、content、tags、access_count和last_accessed_by。工作流程显示：代理A完成分析→写入记忆块；代理B检查记忆池→找到相关块→读取；代理B完成任务→写入新块（标记依赖于代理A的块）。优点在于解耦（代理间无直接依赖）、异步（无需等待对方完成）和灵活（支持多对多通信）。缺点是竞争条件（多代理同时写入可能导致冲突）和垃圾回收（需要策略清理过时块）。
子类型2 结构化黑板将记忆池按主题/任务分割，每个代理监控相关部分。黑板结构按segment组织，例如“performance_issues”段包含Entry 1和Entry 2，“optimization_proposals”段包含Entry 1和Entry 2，“implementation_status”段包含Entry 1和Entry 2。代理的行为是仅监控与其专业相关的segment，发现新信息→处理→将结果写入相关segment。优点在于模块化（减少信息过载）、专业化（代理专注于其领域）和可扩展（新segment和代理可以动态加入）。缺点是需要预先定义segment结构和跨segment协调较为复杂。
子类型3 图形结构记忆的动机在于线性记忆块无法表示复杂关系，图形更适合建模依赖、因果和推理链。
任务记忆引擎（TME，Task Memory Engine）中，节点=推理步骤（属性：输入、输出、执行状态、置信度），边=依赖关系（类型：depends_on, contradicts, supports）。示例图显示[分析性能] --depends_on--> [获取profiling数据]，[分析性能] --produces--> [瓶颈报告]，[实现优化] --depends_on--> [瓶颈报告]，[实现优化] --produces--> [优化代码]，[测试代码] --depends_on--> [优化代码]。其价值在于追踪多步推理的完整依赖链、支持推理的复用和恢复、可解释（可视化推理路径）。
G-Memory（Semantic Graph Memory）的节点类型包括Insight（洞察）、UserQuery（用户查询）和IntermediateResult（中间结果）。边类型包括follow_up（跟进）、refine（精化）和causality（因果）。示例显示[用户查询: 如何优化?] --引发--> [洞察: join是瓶颈]，[洞察: join是瓶颈] --因果--> [中间结果: 分析了代码]，[中间结果: 分析了代码] --精化--> [洞察: 使用hash join]。其优势在于表达力强（复杂关系建模）、语义丰富（不仅存储事实，还存储关系）和支持图推理（如路径查询、子图匹配）。局限是构建和维护成本高和图查询性能（大规模时）。
在多Agent环境的背景下，系统可以视为任何独立的平台、模型或应用，这些实体维护自己的上下文或状态以执行任务。尽管不同系统在规模和能力上可能存在差异，但它们各自在其边界内管理信息。跨系统共享上下文允许这些不同的实体访问或交换相关信息，从而实现更高效的协调或推理。例如，在Cursor和ChatGPT之间共享上下文就展示了这种跨系统交互。
当上下文在单一系统内共享时，通常较为容易，因为组件被设计为互操作——它们大多使用兼容的数据格式、遵循类似的规则并期望类似类型的输入和输出。因此，上下文通常可以在无需大量转换的情况下交换。相反，当跨不同系统共享上下文时，每个系统可能使用自己的格式、结构和逻辑。在一个系统中有意义的内容对另一个系统来说可能完全陌生。在这种情况下，挑战在于使共享的上下文在边界之间可解释。
适配器转换模式是指每个系统保持自有格式，系统间通过专用适配器转换。架构示意显示System A（Cursor）与System B（ChatGPT）之间通过Adapter_AB连接，System A（Cursor）与System C（Notion）之间通过Adapter_AC连接，System B（ChatGPT）与System C（Notion）之间通过Adapter_BC连接。适配器职责包括读取源系统格式、转换为目标系统格式和处理语义差异。示例展示了cursor_to_chatgpt_adapter函数，将Cursor格式（包含project_root、open_files、cursor_position、recent_edits）转换为ChatGPT格式（包含messages数组）。
其优势在于系统独立性（每个系统可自由演化格式）和灵活性（可定制化转换逻辑）。劣势是N×N复杂度（N个系统需要N(N-1)/2个适配器）、维护负担（每个系统升级可能破坏多个适配器）和一致性难（不同适配器可能产生不一致的转换）。适用场景包括系统数量少（2-3个）、临时集成和无法改变系统格式时。
共享表示模式的核心思想是所有系统采用统一的中间表示，系统只需实现自有格式?共享表示的双向转换。架构优势是系统数量N仅需N个转换器（而非N×(N-1)/2个适配器）。架构显示System A、System B和System C都与中央的Shared Representation连接。
共享表示的三种形式包括：形式1统一数据格式（JSON Schema/API），机制是定义标准schema，所有系统遵循。Schema示例显示JSON Schema格式定义context_type、timestamp、entities和relationships。优势在于精确性高（强类型约束）、可验证（自动检查格式正确性）和工具支持（JSON Schema有成熟工具链）。劣势是需要严格协调（所有系统必须遵循）、灵活性降低（schema变更影响所有系统）和设计难度（需要平衡各系统需求）。代表系统包括Langroid（多Agent框架）。
形式2自然语言摘要，机制是以自然语言文本形式共享上下文，利用LLM的语言理解能力。示例展示了Cursor生成摘要，ChatGPT读取并理解后基于此上下文继续对话。其优点在于高度灵活（无需预设结构）、易于阅读（便于调试和理解）、适合LLM（现代LLM擅长处理自然语言）和跨语言（可以翻译成不同的自然语言）。缺点是解析不稳定（歧义可能导致同一描述有多种解读，信息缺失：摘要可能忽略关键细节）、一致性较差（同一上下文的不同摘要可能不一致）和难以精准查询（无法像结构化数据那样进行查询）。适用场景包括对精度要求不高的协作、快速原型制作和实验、人机混合场景（人类也参与理解）。
形式3语义向量（Semantic Embeddings），机制是将上下文编码为高维语义向量，系统间通过传递向量进行交流。工作流程展示：System A将上下文编码为向量（使用嵌入模型），向量传递给System B，System B利用向量进行语义搜索或作为上下文输入。示例代码展示了cursor_context编码为嵌入（形状: (768,)），将向量传递至ChatGPT系统，ChatGPT解码或直接利用相关记忆。
优点在于紧凑（向量比文本小，通常几百到几千维）、系统无关（向量是通用表示）、语义搜索（高效的相似度计算）和可扩展（支持大型记忆库）。缺点是不可读（人类无法理解向量内容）、需要模型（编码和解码依赖机器学习模型）、模型依赖（不同模型的向量不兼容，需使用同一嵌入模型）和信息压缩损失（向量可能丢失细节）。代表性系统包括Sharedrop（跨平台文件和上下文共享）。
选择指南明确：系统数量较少（2-3个）推荐适配器模式；系统数量较多（>3个）推荐共享表示模式；需要精确性推荐统一JSON Schema；需要灵活性推荐自然语言摘要；需要大规模语义搜索推荐语义向量；人类也参与理解推荐自然语言摘要；完全自动化推荐JSON Schema或向量。
上下文选择的五大维度
扩展上下文窗口的悖论是能力提升但效果下降。经验观察表明，当窗口填充度超过50%时性能下降，原因包括噪音掩盖信号、模型注意力分散和“迷失在中间”现象（Lost in the Middle）。
实验发现：上下文开头和结尾的信息容易被记住，而中间部分容易被忽略。当关键信息位于中间时，性能显著降低。这并非偶然，而是Transformer注意力机制的内在特征——位置编码使模型对序列两端更加敏感。这也解释了为何单靠扩大窗口无法解决长上下文问题。
上下文选择的核心比喻是“注意力前的注意力”——模型的自注意力选择关注什么，而上下文选择决定了什么值得被关注，这是元层次的注意力机制。
语义相关性的定义是与当前查询或目标在语义上最接近的上下文。技术实现方式是将查询和候选上下文都编码为向量，计算余弦相似度，排序并选取Top-K。代码示例展示了整个流程。
RAG中的应用通过向量数据库（如FAISS）加速相似度搜索，即使没有关键词匹配也能找到语义相关的资料。优点在于无需精确匹配（模糊搜索）和跨语言（多语言嵌入可以跨语言检索）。局限是可能检索到语义相似但逻辑无关的内容（例如：查询“如何优化join”可能检索到“如何debug join”，语义相似但目的不同）。
逻辑依赖的定义是当前任务直接依赖的前置上下文，超越表面语义关注推理链。MEM1系统的实现是在执行步骤时记录依赖：Step 1分析代码生成[瓶颈报告]，Step 2设计优化方案依赖[瓶颈报告]生成[优化建议]，Step 3实现优化依赖[瓶颈报告, 优化建议]生成[优化代码]。对于新查询“测试优化效果”时遍历依赖图，检索[瓶颈报告, 优化建议, 优化代码]而不是仅仅基于语义相似度。
依赖图的构建显示每个记忆槽记录内容、生成者和依赖的其他槽，形成有向无环图（DAG）。其价值在于反映真实的推理过程、避免遗漏关键前提和支持推理的可追溯性。
时间性和频率（Recency & Frequency）包括时间性（Recency）：最近使用的上下文更可能再次相关，实现上采用时间衰减函数；频率（Frequency）：经常访问的上下文更重要，实现上采用访问计数权重。组合策略代码示例显示综合考虑语义相似度、时间衰减权重和频率权重，使用加权组合（0.5×语义相似度 + 0.3×时间权重 + 0.2×频率权重）。
冗余消除应对的问题是：多个上下文可能传达相同或类似的信息，保留全部会浪费窗口空间。被动去重通过检测语义重叠（嵌入相似度>阈值），保留最新或最详细版本。
积极的内存管理不仅监测更加积极地采取措施：整合（两个相似的上下文→一个综合版本）、更新（用新的信息更新旧条目）、清除（明确过时的信息）。示例显示旧信息"用户偏好使用pandas"与新信息"用户现在更倾向于polars"，积极管理后更新旧条目为"用户曾偏好pandas，现转向polars"，而不是保留两个矛盾的条目。
用户偏好学习（User Preference Learning）通过自我进化记忆跟踪用户与上下文的互动，了解用户重视哪类信息。学习信号包括正面信号（用户重视）：详细阅读（停留时间较长）、追问相关问题、采纳建议、明确标记"有用"；负面信号（用户不重视）：迅速跳过、明确标记"无关"、从不采纳类似建议。
权重调整代码示例展示根据用户反馈动态调整上下文重要性权重（正面反馈×1.2，负面反馈×0.8）。个性化检索使得相同的查询不同用户获得不同的上下文，基于历史偏好调整排序。
主要考虑的因素是相关性，可以通过几个方面评估，包括语义相似度、逻辑依赖、时效性（信息的新鲜度）和频率。例如，许多系统使用相似度得分将当前输入与存储内容对比，为相似度更高的信息赋予更高的相关性。或者，可以整合显式的标签或元数据来指示特定数据的重要性或功能，比如将某些事件标记为里程碑或突出关键事实。除了相关性，重要的是最小化冗余信息并适应用户的习惯。通过整合这些标准，系统能够保留最相关的信息、减少不必要的干扰并提高上下文选择的效率。
RAG工程实践
分段（Chunking）包括固定窗口（机制：按固定的行数或token数切分；优势：简单、统一；劣势：可能破坏语义完整性，如一个函数被分成两部分、一句话被截断）和基于语义边界的分段（AST-based）（机制：根据代码结构切分，如Python按函数、类、模块，Markdown按标题层级；优势：保持语义完整性；劣势：段落大小不均，某些函数很长）。混合策略是以语义分段为主，过长段落再细分，确保每段在合理的大小范围内。
检索方式
包括语义检索（主流），步骤显示：查询嵌入，向量数据库搜索，返回相似段落。非语义检索包括Grep/正则（精确字符串匹配，适用场景：查找特定的函数名、变量名）和全文搜索（倒排索引，ElasticSearch等，适用场景：关键词搜索）。结构化检索包括知识图谱（实体-关系查询，示例："找出所有调用函数X的函数"）和函数调用图（代码依赖分析，示例："这个文件依赖哪些模块？"）。
选择建议明确：如果查询是概念性的（如"如何优化性能"）选择语义检索；如果查询是精确匹配（如"find_user_by_id函数在哪"）选择非语义检索（Grep）；如果查询涉及代码结构（如"哪些函数调用了这个API"）选择结构化检索（调用图）。
重排序（Reranking）
重排序的动机是初步筛选（向量检索）速度快但准确性有限，精排（LLM评分）准确但慢，两阶段结合实现效率与质量。实现显示：第一阶段向量检索（从100k候选中筛选出100个），第二阶段LLM重排序（精排这100个，对每个候选生成相关性评分提示，输出仅数字）。
权衡包括：准确性提升10-30%（经验值）；延迟增加0.5-2秒；成本增加（每个候选一次LLM调用）。不同系统的选型如Windsurf使用重排序（优先质量），某些实时系统跳过重排序（优先速度）。
主动需求推断
从被动到主动的转变显示：1.0-2.0早期AI被动响应，2.0后期-3.0 AI主动推断需求。类比是助手不仅执行命令更能提前准备。
学习用户偏好
的数据来源包括对话历史分析、用户文档笔记和过往交互模式。提取模式包括：观察用户总是要求"详细解释"→学习用户偏好详细而非简略；观察用户经常在晚上进行头脑风暴→学习晚上的对话更开放；观察用户从不采纳涉及X库的建议→学习用户可能不熟悉或不喜欢X库。
用户画像构建显示JSON结构包含user_id、preferences（communication_style、interests、decision_style、time_patterns）和learned_patterns（pattern及confidence）。间接信号学习包括响应模式（用户是否追问→说明信息不足；用户是否立即采纳→说明建议合适）、连续性（话题转换快→可能失去兴趣；深入讨论→说明非常重视）和满意度推断（感谢表达、正面评价→满意；重新提问、修正→不满意）。
隐藏目标推断
通过查询序列分析实现。示例显示用户查询序列Q1"Python的装饰器是什么？"Q2"装饰器如何用于性能监控？"Q3"有没有现成的性能分析库？"推断隐藏目标：用户可能在开发需要性能监控的系统，真正目标是实现高效的性能监控方案，而不仅仅是了解装饰器的概念。
LLM驱动的需求预测通过分析用户的查询序列，考虑查询的逻辑关联、逐步深入的知识递进和潜在的应用场景，输出用户可能的真实目标（1-2句话）。Chain-of-Thought多步推理显示：Step 1 用户问装饰器→可能需要使用装饰器；Step 2 用户问性能监控→可能是装饰器的应用场景；Step 3 用户问现成库→可能希望快速实现而非从头开始；结论：用户想迅速为项目添加性能监控，偏好使用成熟的方案。
主动引导的价值体现在不主动时用户会继续逐一询问相关问题，而主动引导后，AI直接说“看起来您是想为项目添加性能监控？我建议直接使用cProfile或line_profiler，比自己编写装饰器更可靠。需要我提供集成指南吗？”
基于困境的主动援助检测用户卡顿的信号包括犹豫（多次编辑同一查询）、重复尝试（从不同角度问同一问题）、沉默（长时间无新输入）和负面情绪词（表达困惑、沮丧）。主动提供工具如检测到用户多次尝试理解复杂数据关系后主动提供“您似乎在分析复杂的数据关系。我可以为您：1. 生成可视化图表 2. 创建交互式表格 3. 提供分步检查清单 您需要哪种帮助？”
无需显式请求的价值注入可以降低用户认知负担。传统模式下，用户必须知道并请求工具，而在主动模式下，AI识别需求并主动建议。
终身上下文保存与更新的核心转变是从短期（会话级上下文）到终身（跨天、跨月、跨年的持续记忆）。四大系统性挑战包括：存储瓶颈（如何高效存储大量上下文）、处理退化（长上下文下的性能和质量下降）、系统不稳定（错误的累积和放大）和评估困难（如何验证长期记忆的正确性）。
挑战I：存储瓶颈的问题是如何在严格的资源限制下保留尽可能多的相关上下文。目前缺乏统一解决方案：如何保留最大化的上下文确保不丢失？需要什么样的基础设施或接口以便最大程度记录我们的上下文？如何同时支持高压缩、高精度检索和规模化的低延迟访问？
挑战II：处理退化源于注意力机制在规模化时的崩溃。大多数基于Transformer的模型依赖全局注意力，其O(N^2)复杂度导致推理延迟快速增长、GPU内存使用高和I/O吞吐量慢。这些资源瓶颈使得实时处理大型上下文变得不切实际。同时推理质量退化：随着注意力在更长输入上变稀疏，模型难以维持对相关信息的关注，难以捕捉长距离依赖。此外，检索系统被许多语义相似但无关的信息片段淹没，通常返回干扰而非有用证据。此外，随着上下文量增长，检测和调和检索片段之间的不一致和冲突变得更加困难。所有这些问题导致在处理非常大的上下文时推理变得脆弱。
挑战III：系统不稳定是随着记忆随时间积累，即使是小错误也可能影响系统的更多部分。曾经影响有限的错误现在可能广泛传播，导致意外或不稳定的行为。如果没有清晰的边界或验证机制，系统变得更难管理，尤其是在长时间运行或需要高安全性的任务中。在这种情况下，它可能使系统更加脆弱而不是增加可靠性。
挑战IV：评估困难是随着记忆积累，判断系统推理是否正确变得更加困难。当今大多数基准测试只测试系统是否能检索信息，但不检查信息是否仍然相关、准确或有用。系统很少包含检查矛盾、撤销错误更新或追溯导致结论的推理步骤的功能。随着越来越多的决策依赖于更长的记忆链，检查系统如何得出特定答案变得越来越困难。这种可见性的缺乏使得信任或改进系统变得困难，特别是对于终身上下文工程。
迈向语义操作系统的必要性在于终身上下文工程的挑战不能再通过简单地“扩展上下文窗口”或“改进检索准确性”来解决。它要求构建一个能够随时间增长的语义操作系统，就像人类的思维一样。一方面，这样的系统必须支持大规模、高效的语义存储作为自己的记忆库，并表现出真正类似人类的记忆管理能力：主动添加、修改和遗忘知识。另一方面，它需要新型架构来替代Transformer的平坦时序建模，从而实现更强大的长程上下文推理和动态适应。关键是，系统应该能够通过追踪、纠正和解释其推理链中的每一步来解释自己，从而提高实际和安全关键场景中的信任和可靠性。这种方法突出了上下文工程的基本原则，并反映了范式转变：上下文不再被动积累，而是作为认知的核心元素被主动管理和演化。
语义操作系统的愿景核心理念是上下文不再被动积累，而是主动管理和演化的认知核心。
必要能力一是大规模语义存储。传统数据库存储数据并基于索引查询，语义存储则存储意义、理解语义关联并支持概念推理。技术要素包括语义图谱（节点为概念、事实、事件，边为关系如因果、支持、矛盾、时序）、多级索引（文本索引用于全文搜索、向量索引用于语义相似度、图索引用于关系查询）和分布式架构（支持PB级数据、毫秒级查询延迟、高可用性）。
必要能力之二是类似人类的记忆管理。人类的记忆机制提供了灵感，包括主动选择（不是被动接受所有信息，而是基于重要性、情感和关联度主动选择记住什么）、主动调整（记忆不是静态的，会随着新经历更新、重组，整合矛盾信息）和主动遗忘（传统观点认为遗忘是一种缺陷，但新视角认为遗忘是一种功能，其优势包括释放存储空间、减少无关信息干扰、维持认知灵活性）。
实现机制包括重要性评分（结合访问频率、时间衰减、用户反馈、关联度和情感显著性，定期清除评分较低的记忆，如果重要性评分低于设定值，则将其归档而非删除，以便恢复）和记忆整合（将多个相关记忆合并成一个概括性的记忆，例如记忆A“2025年1月，用户询问Python性能优化”、记忆B“2025年3月，用户询问Python性能优化”、记忆C“2025年5月，用户询问Python性能优化”整合后变为“用户持续关注Python性能优化（2025年1-5月，3次）”，原始记忆降级至“归档”状态）。
必要能力之三是新型推理框架。Transformer的主要限制在于平铺式的时序建模（所有标记被视为同等重要）、无法自然表达层次结构和远距离依赖的注意力分散。层次化推理架构包括L1抽象层（宏观理解：“这是一个性能优化任务”“涉及算法和数据结构”）、L2概念层（概念识别：“瓶颈在于join操作”“候选解决方案：哈希表、排序归并”）和L3细节层（具体推理：“哈希表空间复杂度O(n)”“时间复杂度从O(n?)降低到O(n)”）。推理流程遵循从L1→L2→L3（从抽象到具体）和L3→L2→L1（从具体到抽象，验证一致性）的模式。
动态上下文路由根据查询动态决定关注哪些上下文，而不是均匀关注所有上下文。其实现包括第一阶段粗选（粗选：相关性评分，候选项=top_k(相关性评分, k=100)）、第二阶段精选考虑逻辑依赖（依赖图=构建依赖图(候选项)，关键路径=查找关键路径(查询, 依赖图)）和第三阶段自适应加载（关注的上下文=关键路径，若推理停滞：关注的上下文+=探索附近(关键路径)）。
因果推理集成从传统的关联性（correlation）提升到因果性（causation）。示例表明：观察“更改算法后，性能提高”，关联性推理“算法与性能有关”，因果性推理“算法变更导致性能提高”（更强大的推断）。技术包括因果图模型（Causal Graph）、反事实推理（Counterfactual Reasoning）和干预实验模拟。
必要能力之四是全程可解释性。推理链追溯的ReasoningTrace类包含steps数组，每个step包含step_id、action、input_contexts、reasoning、output和confidence。explain方法追踪如何得出特定结论，展示完整的推理路径。
纠错机制的ErrorCorrection类包含detect_error方法（检查逻辑一致性和事实准确性）和correct方法（回滚到错误步骤前并重新推理）。透明度仪表板在用户界面展示结论、总体置信度、依赖的关键上下文、推理步骤和潜在风险，提供查看完整推理路径、验证事实基础和提出疑问的功能。
语义操作系统的哲学意义涵盖：从“数据连续性”到“语义连续性”（过去保持所有数据连续可访问，未来保持意义的连续可理解，即使数据丢失，只要语义已被抽象保留即可）；从“被动响应”到“主动理解”（过去等待用户指令，未来预见用户需求、主动构建上下文）；从“工具”到“伙伴”（过去AI是完成任务的工具，未来AI是共同成长的认知伙伴，上下文成为共享的“记忆空间”）；数字化存在（卡尔·马克思曾写道“人的本质是社会关系的总和”，在AI时代，这一观念获得了新的计算意义：“人的数字化本质是上下文的总和”，终身上下文=数字化的“自我”，可以持续存在、不断进化、甚至可以在物理身体之外延续）。
涌现的工程智慧
KV缓存优化
KV缓存的工作原理是在Transformer生成token时存储过去的tokens的Key和Value，当新token生成时，只需计算新token的Query，复用已存储的Key和Value，避免重新计算整个序列。缓存命中率极为重要，因为缓存未命中会导致重新计算，增加几百毫秒到几秒的延迟、消耗GPU资源并损害用户体验（响应慢→体验差）。
三大最佳实践包括：
实践1保持前缀稳定性。问题场景显示不当做法是在系统Prompt中包含时间戳（每次调用时间不同→前缀变化→缓存失效）。解决方案是良好的做法是固定系统Prompt，将时间戳置于用户消息中。原理是KV缓存通常从Prompt的开头开始，开头变化→整个缓存失效、保持开头稳定→最大化缓存复用。
实践2仅追加且确定性更新。问题场景显示不当做法是修改历史消息导致后续所有缓存失效。解决方案显示良好做法是只追加不修改，需要更正时追加新消息说明更正。原理是KV缓存按序列位置索引，修改中间部分→后续位置的缓存全部失效、仅追加→保持现有缓存。
实践3手动缓存检查点（必要时）。场景是某些框架不支持自动递增前缀缓存、长对话中有明确的“阶段”。实现显示在关键节点手动标注缓存点、保存当前KV状态、后续阶段可从检查点恢复。
缓存预热（Cache Warm-up）涵盖预测性加载（Prefetch，用户启动项目→即时加载项目上下文到缓存，用户发起查询时缓存已准备就绪）和投机性加载（Speculative Loading，预测用户下一步可能的查询方向，如果当前查询主题是性能优化则预加载相关性能的上下文到缓存）。技术启示是效率不仅取决于算法也在于缓存管理，上下文的“组织方式”直接影响系统性能。
工具设计
两大核心要素是描述的精确性和规模控制。描述的精确性问题表明不当做法模糊描述“搜索物品”导致LLM无法判断何时使用此工具。解决方案表明良好做法清晰描述包括何时使用、输入输出和注意事项。
LLM作为Prompt工程师是有趣的自举（Bootstrapping）：利用LLM生成工具描述、用LLM评估描述质量、迭代改进，形成自我提升的闭环。
规模控制的问题2是工具越多LLM选择越难，经验阈值显示对DeepSeek-v3：30工具后性能下降，100工具几乎必然失败。原因分析包括重叠描述（多个工具功能类似，LLM混淆）、选择复杂度（选项过多，决策质量下降）和上下文污染（所有工具定义都占用上下文空间）。
错误做法表明不当做法动态加载工具（每次加载不同的工具→破坏KV缓存的一致性）。推荐做法表明良好做法稳定工具列表+解码级约束（固定工具列表，根据上下文决定哪些工具“可用”，解码时屏蔽不可用工具的logits）。解码级约束的价值在于保持工具列表稳定（对KV缓存友好）、通过logit屏蔽限制选择（降低错误率）和动态控制而无需更改输入。技术启示是清晰优于数量、约束而非自由放任、工具设计是Prompt工程的延续。
上下文内容策略
策略1 保留错误促进学习。传统做法表明不当做法隐藏错误（仅告知Agent“任务失败，请重试”）。推荐做法表明良好做法保留错误详情（包括失败的操作、错误消息、堆栈跟踪和可能原因）。价值在于LLM能从错误中学习、观察失败→调整策略→避免重复错误，类似于人类从错误中成长。
策略2 打破Few-shot的重复陷阱。问题表明上下文中多个相似的动作-观察对导致LLM倾向于继续run_benchmark()，陷入重复循环。Manus的创新是结构化变异，引入小的、有意的变化。变化1模板变异（“Action: X” → “执行操作: X”，“Observation: Y” → “结果: Y”）；变化2措辞变异（“run_benchmark()” → “运行性能测试”，“Time: 3.2s” → “耗时3.2秒”）；变化3顺序和格式（有时先Observation再Action，有时用JSON格式有时用自然语言）。原理是打破模式识别、迫使LLM关注语义而非形式、重新聚焦模型注意力。技术启示是上下文不是越“干净”越好、错误是有价值的信息、过于一致的模式可能有害。
多Agent系统
经验1 清晰的任务分解。问题表明不当做法模糊指令“请帮我优化这个项目”导致LeadAgent不知如何分配子任务。解决办法表明良好做法结构化任务包含主任务和多个子任务，每个子任务有Goal、Output、Tools和Boundary。
经验2 工作量评估规则。问题是Agent难以判断任务需要多少资源。启发式规则根据查询复杂度估计subagents需求，更细致的判断基于多个因素（需要多源信息+2、涉及多模块代码+3、需要实验验证+2、有严格截止日期-1，结果是base_count + sum(factors.values())）。在Prompt中指导包含根据查询复杂度分配SubAgent的规则。
经验3 搜索策略演进。初期宽泛探索显示Query“量子计算的应用”→广泛搜索。中期聚焦分析显示发现金融领域应用最成熟→深入搜索。原理是先广后深逐步收敛、避免过早锁定方向（可能错过重要信息），类似于人类的研究过程。
经验4 扩展思考模式（Extended Thinking）。机制是要求Agent显式写下推理过程，不直接跳到结论。示例显示Without Extended Thinking时直接回答“用哈希表”，With Extended Thinking时详细展示推理过程。价值在于提高准确性（逐步推理减少跳跃）、提高效率（减少回头重做）和可解释性（人类能理解推理路径）。
实用技巧
技巧1 维护todo.md文件。机制显示markdown格式文件包含In Progress、Completed和Pending三部分。更新策略是每完成一个子任务→标记为Completed，发现新需求→添加到Pending。
技巧2 定期复述目标（长任务）。 问题是长任务中模型可能“忽视”最初目标，沉溺于细节而偏离主线。解决办法是每N步操作后插入目标摘要。其价值在于将目标重新引入近期上下文窗口，维持模型注意力集中在主线任务上，防止在分支细节中迷失。技术启示是简单的工程手段往往非常有效，人类的任务管理智慧（如待办事项列表、定期回顾）同样适用于人工智能，显式优于隐式。
应用案例
Gemini CLI
当利用人工智能代理时，开发人员通常需要持续的、面向项目的上下文支持。谷歌的Gemini CLI提供了一个关于如何设计上下文的典型实例。核心机制是GEMINI.md文件，这是一种Markdown格式的标准，记录了项目背景、角色定义、所需工具和依赖项、编码惯例等。
上下文通过文件系统层级结构组织：GEMINI.md文件可以位于用户的主目录、项目根目录或子目录中，实现信息的继承与隔离。继承与覆盖规则是子目录继承父目录的GEMINI.md，相同字段子覆盖父，不同字段则合并。
上下文生命周期包括启动时（静态加载）：自动加载静态信息，例如系统提示、当前项目环境及祖先或后代GEMINI.md文件；交互中（动态积累）：逐步积累来自持续对话历史的动态上下文。
对于管理，CLI采用压缩与摘要策略。触发条件是窗口填充度超过阈值（如70%）。摘要生成是调用大型语言模型将长历史压缩为结构化摘要，这些摘要遵循预定义格式以确保一致性。格式示例包括压缩摘要（生成时间）、总体目标、关键知识、文件系统状态和当前计划。
社区讨论还提议通过人工精炼扩展此流程以支持上下文的协作管理。建议机制是AI生成初版GEMINI.md、人类审查和精炼、版本控制（Git）。其价值在于结合AI效率与人类判断力。技术启示包括文件系统作为轻量级数据库、层次化上下文组织和自动+人工的混合管理。
Tongyi DeepResearch
深度研究代理旨在协助用户处理开放性、知识密集型查询，如涉及多个事件和交织关系的推理任务。一个典型案例是Tongyi DeepResearch，它通过四个主要步骤运行：根据用户查询在网络上搜索，从相关页面提取关键信息，生成新的子问题以指导进一步搜索，最后将多个来源的证据整合为连贯的答案。
这个循环通常持续多轮，直至不确定性降低并形成完整的证据链。与短期对话代理不同，深度研究面临极长交互历史的挑战：直接追加所有观察、思考和行动会迅速超出上下文窗口。为克服这一限制，Tongyi DeepResearch采用了系统化的上下文工程。
在探索过程中，代理定期调用专门的摘要模型将累积的历史压缩为紧凑的推理状态，不仅保留关键证据，还突出缺失的信息和下一步的方向。后续的搜索和推理基于这些压缩的“上下文快照”，而非完整的原始历史。
快照内容包括summary_id、timestamp、original_query、key_evidence（如IBM和Google在量子硬件上的进展）、missing_information（具体的商业案例和投资回报率数据等）、next_steps（搜索量子计算商业案例研究等）和confidence_level。后续推理基于快照而非完整原始历史，显著减少了token消耗。
通过这种方式，系统建立了清晰的上下文生命周期：从收集和积累信息，到定期压缩和抽象，再到基于摘要进行推理和复用，使其能够突破上下文限制并实现可扩展的长期研究能力。技术启示包括长期任务必须有上下文压缩机制、摘要不仅是简单的截断而是智能提炼、分层记忆（原始历史归档+快照活跃）。
脑机接口
脑机接口（BCI）为上下文工程开辟了一条新途径，使得更先进的上下文收集成为可能。与依赖语言输入的传统方法不同，BCI可以直接捕捉神经信号，这带来了两大独特优势。
首先，它们允许收集更丰富的上下文维度，如注意力水平、情绪状态或认知负荷——这些因素通常难以仅通过外部行为观察。其次，它们提供了更方便的上下文收集方式，减少了对显式用户动作的需求，并通过神经活动实现更即时的输入。
当前局限包括粗糙的理解（只能识别大致状态如专注/分心，无法读取具体思维内容）、噪声问题（神经信号容易受到干扰，信噪比低）、不稳定性（个体差异大，同一个人在不同时间点也有波动）和侵入性（某些BCI，高精度BCI需要植入电极，涉及伦理和安全问题）。
尽管当前技术仅能提供对大脑信号的粗略理解，噪声和不稳定性等问题仍是重大挑战，但BCI指出了上下文工程可能的发展方向：将上下文收集从外部环境扩展到用户的内部认知状态。未来方向包括非侵入式BCI精度提高、从外部环境到用户内部认知状态的上下文采集、真正的“意念交互”和与大型语言模型结合（神经信号→语义解释）。技术启示是上下文工程的范围不断扩展，从外部观察到内部感知，是3.0时代的一个重要特征。
总结：站在演进的十字路口
此篇研究指出，上下文工程并非LLM时代突然出现的创新，而是一个历经超过20年演变的领域。从1990年代的普遍计算和情境感知系统，发展至今日的智能代理和LLM，上下文工程始终聚焦于一个核心难题：如何使机器更准确地理解人类的情境与意图。
这一演变过程呈现出明确的趋势：每次机器智能的跃升都会带来范式的转变。Era 1.0的被动执行者需人类将其意图转换为低熵的结构化指令。Era 2.0的主动智能体能理解自然语言并进行部分推断，但仍然需要Prompt工程等人机互动。Era 3.0的人类级别智能将实现近乎自然的人机协作，而Era 4.0的超人类智能或许会逆转主体与客体的关系，AI将成为洞察与创意的源泉。
现有的实践揭示了一系列系统化的方法论：层级存储架构确保性能与持久性的平衡；多样化的文本处理模式和多模态融合策略应对异构信息；层级记忆、情境隔离和自我烘焙机制构建认知框架；语义关联性、逻辑依赖、时间频率等多维度指导情境选择；KV缓存优化、工具设计、内容策略等工程技术提升系统效率。
然而，重大挑战依旧存在。存储限制、处理退化、系统不稳和评估难度等问题提醒我们，“扩展窗口”的线性思维无法满足终身情境的系统性挑战。未来所需的是质的变化而非量的增加——一个能够主动管理和演进情境的语义操作系统，具备大规模语义存储、类似人类的记忆管理、新推理架构和全过程的可解释性。
正如卡尔·马克思所说“人的本质是一切社会关系的总和”，在AI时代，这一观点获得了新的计算层面的意义：人的数字本质是情境的总和。上下文工程不仅是技术问题，更是涉及意义构建、知识演进和人机共生的哲学议题。我们正处于Era 2.0向3.0过渡的关键时期，理解历史才能掌握现在、预测未来，当前的工程实践应为下一阶段的飞跃做足准备。
上下文工程之旅，亦即人机协同演化的旅程。在这条道路上，我们不仅在优化系统，更在探索智能的本质、意义的构建，以及人类与AI共生的可能性。让我们以开放的态度、严谨的方法、前瞻的视角，共同书写上下文工程的下一章节。
阅读完本文后，我对超出模型静态参数的世界（情境）有了更加深刻的理解。以往从应用工程、数据工程、模型底层的角度理解Context，但未像论文作者那样，系统化地梳理甚至用哲学视角来解读上下文工程。这激发了我对基于Transformer架构模型的AI浪潮的思考。自从开始接触Transformer架构模型以来，我便认定未来的学习和工作必然围绕AI展开。我认为互联网对我来说，在三年前遭遇这场AI变革之后，已经成为过去。它是我的旧友，互联网人士或许正经历自我转型。随着模型的不断进步，以及行业对模型认知的深化，结合当前我们正经历的百年未有之大变局，以及十多年前那场未竟的任务。此刻的我，心中涌起一种使命感，驱使我想要穿越时空，用现在的AI能力重新书写十多年前的互联网逻辑。虽然这充满挑战，但我渴望尝试，并且迫不及待想要立即行动。互联网人士，应具备与生俱来的韧性，沙漠中没有树木，就种植树木；种植树木没有水源，就挖掘水井；挖掘水井没有工具，就手工制造工具，逢山开路遇水搭桥……
如何学习大模型？学习AI大模型是一个渐进的过程，需从基础起步，逐步深入到更高阶的技术。
这里为大家精心整理了一份详尽的AI大模型学习资源，涵盖：AI大模型完整学习路径（从入门到实战）、精选AI大模型学习书籍手册、视频教程、实战学习、面试题等，资料免费提供！
这是一份从零基础到进阶的大模型学习路径大纲概览，小伙伴们记得收藏！
100套AI大模型商业实施方案
大模型完整视频教程
200本大模型PDF图书
????学会后的收获：????
? 基于大模型的全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过该课程可以获得不同的技能；
? 能够运用大模型解决实际项目需求：大数据时代，越来越多的企业和机构需要处理大量数据，利用大模型技术可以更高效地处理这些数据，提高数据分析和决策的精准度。因此，掌握大模型应用开发技能，可以使程序员更好地应对实际项目需求；
? 基于大模型和企业数据的AI应用开发，实现大模型理论、掌握GPU计算能力、硬件、LangChain开发框架和项目实战技能，学会Fine-tuning垂直训练大模型（数据准备、数据精炼、大模型部署）一站式掌握；
? 能够完成当前热门大模型垂直领域的模型训练，提高程序员的编程能力：大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提升程序员的编程能力和分析能力，使程序员更加熟练地编写高质量的代码。
LLM面试题集合
大模型产品经理资源集合
大模型项目实战集合
????需要的小伙伴们，可以通过扫描下方二维码免费获取【确保100%免费】????
京公网安备 11010802022788号
