Context Engineering：机器如何学会“理解“人类意图的熵减史

最新推荐文章于 2025-11-23 17:56:55 发布

原创最新推荐文章于 2025-11-23 17:56:55 发布 · 755 阅读

CC 4.0 BY-SA版权

文章标签：

#transformer #深度学习 #人工智能 #自然语言处理 #语言模型 #神经网络 #机器学习

上下文工程并非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为例，当用户输入"搜索相关文档"时，相关实体集包括：用户（输入Prompt）、应用（系统指令、配置）、终端环境（工作目录）、外部工具（插件、搜索工具）、记忆模块（会话历史、存储知识）以及后端模型服务（能力范围、响应格式）。每个实体的特征化结果共同构成了总上下文。

上下文工程则被定义为：

这个形式化定义看似学术,实则深刻。它告诉我们:

上下文不是"额外信息",而是"情境的全息投影"。用户的一句话只是冰山一角,水面下是终端状态、项目历史、工具权限、模型能力的整体交织。传统软件工程关注"输入→处理→输出",上下文工程关注的是"情境→理解→行动"——这是维度的跃迁。

这就是为什么我们要回顾20年前的理论——它们触及了超越具体技术的本质。

熵减视角:揭示上下文工程的第一性原理

现在,让我们触及这个领域最深刻的洞察——它解释了过去20年的所有变化,也预示了未来20年的所有可能。

人类交流的秘密,藏在一个信息论概念中:熵。

当你的朋友说"老地方见",你瞬间理解——不需要完整地址,不需要时间确认,甚至不需要说明是哪个"老地方"。因为你的大脑自动做了一件事:降低信息熵。

你调取了共享的历史(上周去过的咖啡馆)、时间惯例(通常下午3点)、当前情境(正在聊周末计划)。大脑将这些高熵的碎片信息,压缩成一个低熵的确定答案。这个过程,信息论称之为"熵减"。

机器做不到。

至少,在Era 1.0时代完全做不到,Era 2.0时代只能部分做到。当你对1990年代的电脑说"老地方见",它会无助地闪烁着光标。即使在2025年,当你对Claude说"继续之前的思路",它虽然能勉强理解,但远不如人类那样轻松自如。

这就是上下文工程存在的根本原因:机器的熵盲。

让我们用公式精确地定义这个过程(不用担心,这个公式比你想象的简单):

人类说"老地方见"(高熵,信息不完整,依赖背景),上下文工程要把它转化为"2025年11月9日15:00,上海市徐汇区某某路123号星巴克"(低熵,信息完整,无需背景)。

但这里有一个关键洞察:

这个熵减工作,不一定由人类来做。它的承担者,取决于机器的智能水平:

Era 1.0:100%由人类承担(机器完全熵盲,需要完全结构化的输入)
Era 2.0:50%由人类,50%由机器(LLM能理解自然语言,但仍需Prompt工程)
Era 3.0:20%由人类,80%由机器(人类级智能,接近人类的"填空"能力)
Era 4.0:0%由人类,甚至反过来(超人类智能,主动构建上下文)

这就是为什么机器越智能,上下文工程的"成本"越低——不是上下文工程消失了,而是它的执行主体从人类转移到了机器。

这个视角解释了:

为什么GPT-3是分水岭:它第一次让机器具备了in-context learning,即部分熵减能力
为什么Prompt工程如此重要:在Era 2.0,人类仍需承担一半的熵减工作
为什么Era 3.0会彻底改变游戏规则:熵减主体的转移,意味着人机关系的重构

现在,这个理论框架已经建立。接下来,让我们看看它如何在20年的历史中得到验证。

上下文工程演进概览

两大设计原则

最小充分性原则（Minimal Sufficiency Principle）强调，系统应收集和存储仅任务所需的信息，价值在于充分性而非容量。盲目追求"越多越好"的反模式会导致噪音掩盖信号。

在实践中的体现是：不应收集"用户的所有浏览历史"，而应仅收集"与当前任务相关的浏览模式"。例如，代码助手无需知道用户昨天看了哪些新闻，但需要知道用户最近查阅了哪些API文档。实践指导包括不断追问：这个上下文对任务是必要的吗？移除它会影响任务完成吗？若答案为否，则不应收集或存储。

语义连续性原则（Semantic Continuity Principle）指出，上下文的目的是维持意义的连续，而非数据的连续。系统不必保存所有原始数据，但必须保持语义的可追溯性。

这意味着：保存完整的10万行对话原文不如保存经过抽象的"用户在数据处理项目中持续关注性能优化"这一语义核心。压缩和抽象是必要的，只要核心语义不丢失。这一原则为后续将详述的"self-baking"（上下文抽象）机制提供了理论正当性。

这两大原则共同塑造了上下文在智能系统中应被收集、保存和利用的方式，为后续实践提供了哲学指引。

历史演进：二十年的智能跨越

理论已经建立,洞察已经揭示。但你可能会问:这真的不是事后诸葛亮式的总结吗?熵减视角真的能解释历史,还是只是一个优美的叙事?

让我们用历史来检验理论。

如果理论正确,那么:

1. Era 1.0到Era 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的架构智慧超越了具体技术的生命周期：关注点分离、模块化复用、可扩展性——这些原则至今依然有效。尽管今天我们使用LLM而非传感器融合，使用向量数据库而非Widget接口，但"如何将异构信息源转化为统一语义表示"这一核心挑战并未改变。

本质特征

Era 1.0的上下文可被概括为"Context as Translation"（上下文即翻译）。人类意图需要被"翻译"为机器可读格式，翻译者是人类设计师，机器是被动接收者。交互模式是Human-Computer Interaction（人机交互），人类主动提供所有必要信息，机器严格按预定义规则响应，无真正的"理解"和"协作"。智能水平停留在Passive Executor（被动执行者），机器智能极低，上下文处理能力仅限结构化低熵信号，人机交互成本极高。

为什么今天的我们应该关心这段20年前的历史?

因为Era 1.0留下了三个至今仍被低估的遗产:

遗产一:Context Toolkit的模块化智慧在今天仍然适用。看看你熟悉的现代系统:

RAG中的embedding模型 = Context Widgets(封装异构数据源)
Chunk的语义切分 = Interpreters(提取高层语义)
向量数据库的检索 = Aggregators(整合多源信息)
Agent的memory接口 = Services(提供标准访问)

同样的问题,不同的技术,相同的架构原则。当你在设计Agent的记忆系统时,Context Toolkit的五大抽象仍然是最佳实践。不是因为技术复古,而是因为它们触及了"异构信息如何统一"这个超越时代的本质挑战。

遗产二:Era 1.0的"整体性视角"恰恰是Era 2.0最缺失的。1990年代的研究者将上下文视为"用户-应用-环境-工具-状态"的整体。而今天,我们常常狭义地认为上下文=对话历史,这是严重的倒退。

Claude Code的GEMINI.md、Windsurf的codebase理解、Cursor的项目上下文——这些优秀实践,本质上都在重新发现Era 1.0的整体性视角。区别只是:1990年代用传感器采集环境信息,2025年用LLM理解代码和文档。

遗产三: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这样的结构化命令；In-Context Learning（上下文内学习）让模型能从上下文中的示例学习新任务，无需重新训练，上下文成为"临时程序"；推理能力的提升让机器能够通过Chain-of-Thought逐步推理复杂问题，具备了填补逻辑空白的初步能力，尽管仍与人类存在差距。

In-Context Learning的意义不仅在于无需重新训练，更在于它改变了上下文的性质：上下文不再仅是"数据"，而成为"临时程序"。通过精心设计的Few-shot示例，人类实质上是在用自然语言为LLM编写临时的任务规范。这预示了Era 2.0的核心特征——"Context as Instruction"。

上下文获取的革命

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的系统是"Context-Aware"（上下文感知），被动感知并基于条件-动作规则触发响应。例如"IF 位置 == '办公室' THEN 手机静音"，这种响应基于"在哪里"而非"在做什么"，无法理解用户意图或协作完成任务。

Era 2.0进化为"Context-Cooperative"（上下文协作），主动理解意图并协作实现目标。当用户正在撰写研究论文时，系统分析前文内容（已完成的段落）、当前写作意图（引言、方法、结果？）和论文结构惯例，主动建议下一段落的结构和要点。系统不仅感知环境，更理解任务，主动融入工作流，成为协作伙伴。这种突破在于：不仅感知环境，更理解任务；主动融入工作流；成为协作伙伴。

关键技术实践

Prompt工程成为用自然语言"编程"LLM的艺术，通过System Prompt定义角色和能力边界，通过Few-shot Prompting提供示例引导行为，通过Chain-of-Thought显式化逐步推理过程。本质是用自然语言"编程"LLM。

RAG（Retrieval-Augmented Generation，检索增强生成）解决了LLM训练数据截止日期的限制。其机制是：查询时检索相关外部文档，将文档注入上下文，基于增强的上下文生成回答。这将静态知识变为动态可更新。

工具调用（Tool Calling）突破了LLM自身的计算和访问限制。LLM本身的局限是无法执行计算、访问数据库、联网等。工具调用机制让LLM识别需要工具的场景，生成工具调用参数，执行工具获得结果，将结果作为新上下文继续推理。例如，当用户询问"北京明天天气如何"时，LLM调用天气API("北京", "2025-11-10")，API返回结果后LLM整合结果生成自然语言回答。

长期记忆机制通过向量数据库存储历史对话的语义embedding，新对话时检索相关历史上下文，实现跨会话的"记住"用户偏好和过往讨论。代表系统如Letta（MemGPT）展示了这一能力。

本质特征

Era 2.0的上下文是"Context as Instruction"（上下文即指令），上下文不仅是数据，更是引导模型行为的"程序"。Prompt工程的兴起证明了这一点。交互模式转变为Human-Agent Interaction（人-智能体交互），Agent具有主动性，能够规划、执行和反思，人类可用自然语言表达高层意图，双向协作取代单向指令。智能水平达到Initiative Agent（主动智能体），机器智能中等，接近或部分超越某些人类任务，上下文处理能力可处理自然语言和部分多模态，人机交互成本降至中等水平，仍需Prompt工程等人工介入。

Era 3.0与4.0：未来的跨越

Era 3.0对应Human-Level Intelligence（人类级智能），推理与理解能力接近人类水平，标志着真正的通用人工智能（AGI）萌芽。上下文能力将扩展至更丰富维度：社交线索（微表情、肢体语言、说话方式）、情感状态（从语调、停顿、用词推断情绪）、复杂环境动态（多实体交互的理解）。AI将具备类人的推断能力，填补对话省略，理解隐含意图，从不完整信息构建完整情境。此时，上下文表达为"Context as Scenario"（上下文即场景），不再是离散信息片段，而是完整、动态的情境模型，机器能在"场景"中推理和行动。人机关系演变为无缝协作，AI作为真正的知识伙伴——不再是工具，而是协作者，可进行深度讨论、头脑风暴，提供洞察而非仅执行指令。自然且流畅的交互无需刻意"翻译"意图。AI作为可靠协作者（Reliable Collaborator），人机交互成本接近极低。

Era 4.0是Superhuman Intelligence（超人类智能）的愿景阶段。机器理解人类意图比人类自己更深刻，拥有"上帝视角"。范式根本反转：不再是人类定义上下文、机器适应人类，而是机器主动为人类构建新的上下文框架，揭示人类未明确意识到的需求，引导人类思考新的可能性。

围棋AI已展现这一缩影——职业棋手从AlphaGo等围棋AI学习全新的、超越人类传统的策略。AI不仅理解人类的棋路，更创造人类未曾想象的棋路。这是Era 4.0的缩影。应用前景包括：科学发现（AI提出人类未想到的研究假设）、创意产业（AI启发全新的艺术形式）、决策支持（AI揭示隐藏的风险或机遇）、教育（AI为每个学习者构建最优认知路径）。哲学意义在于：人类不再是唯一的"意义制造者"，AI成为洞察与灵感的源泉，人机关系的深刻变革从工具→伙伴→导师。

此时，上下文表达为"Context as World"（上下文即世界），上下文不是局部信息，而是完整的世界模型，AI在这个世界模型中模拟、推演、创造。交互模式是AI引导人类，主客体关系反转，人类向AI学习而非相反。智能水平为Considerate Master（善解人意的大师），机器智能超人类，上下文处理能力远超人类，人机交互成本接近零（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）和多模态信号（文本、语音、图像、视频、传感器数据）。Agent整合这些信号为连续上下文流。存储策略采用分层架构，根据数据使用意图决定层级。

分层存储架构

短期存储（Short-term Storage）用于快速访问、频繁使用的临时数据，特征是速度极快（内存级）、容量有限、持久性低（会话级或更短）。技术实现包括内存缓存（RAM）、边缘节点缓存和会话状态。典型数据包括当前对话历史、即时工具输出和临时推理状态。

中期存储（Medium-term Storage）用于需要中等时长保留的数据，特征是速度快、容量中等、持久性中（天级、周级）。技术实现包括嵌入式数据库（如SQLite、LevelDB、RocksDB）、本地文件系统的结构化存储、安全存储模块（涉及敏感数据时）和硬件安全模块（高安全需求时）。典型数据包括活动记录、用户偏好和项目级上下文。

长期存储（Long-term Storage）用于需要长期保留、跨设备同步的数据，特征是速度相对慢但可接受、容量大且可扩展、持久性高（永久或长期）。技术实现包括云存储平台、远程服务器数据库和分布式存储系统。典型数据包括历史对话归档、用户画像、知识库和跨设备同步的状态。

决策树逻辑清晰：若需要极低延迟访问且会话级生命周期，选择短期存储；若需要跨会话保留且本地设备为主，选择中期存储；若需要长期保留或跨设备同步，选择长期存储。

代码Agent的特殊需求

代码任务往往长周期、跨多会话，依赖单一上下文窗口不现实（即使100k tokens也不够复杂任务）。会话中断后如何恢复？解决方案是周期性状态持久化：定期将任务状态和进度写入长期记忆，中断后从长期记忆恢复相关上下文。

Claude Code的结构化笔记机制是典型案例。系统维护外部结构化笔记文件，周期性将关键信息从上下文窗口写入笔记，需要时从笔记检索信息注入上下文。笔记结构包括：整体目标、关键知识点、文件系统状态、最近的动作和当前计划。这种轻量但持久的机制支持长周期活动，避免上下文丢失。价值在于轻量但持久、支持长周期活动、避免上下文丢失。

极端案例如管理数千个步骤的Pokémon游戏策略，挑战是管理数千个步骤的游戏策略。解决方案是外部记忆系统跟踪进度，重置后无缝恢复。意义在于：外部结构化记忆将Agent的规划视野扩展到远超上下文窗口的限制。

Era 3.0展望

Era 3.0的人类级上下文生态系统将在感知维度实现飞跃。触觉信息重现人类触觉体验（质地、压力、温度），嗅觉与味觉解释环境条件（烟雾=危险）或评估食物新鲜度，细腻的社交信号捕捉声调、停顿、眼神接触甚至沉默的含义。

统一个人数字记忆不再是"数据保存"，而是动态认知基础设施：自主组织、精炼上下文以支持持续推理和跨场景交互、类人的"遗忘"与"回忆"能力。数据在本地与云端安全流动，用户对敏感信息保持绝对控制，同时受益于全局知识和计算资源。记忆不再是技术细节，而是AI的"认知基础"，支持真正自然的长期人机共生，迈向人机自然共生。

上下文管理：从原始数据到可用知识

文本上下文处理的五种范式

时间戳标记法为每条信息附加时间戳以保持生成顺序。实现示例显示每条消息都带有时间戳（如[2025-11-09 10:00] User: 帮我写一个Python排序函数）。优势在于实现简单、维护成本低、时序信息保留完整。但局限明显：无语义结构（时间戳不反映内容关系）、长程依赖困难（难以捕捉跨越多条消息的主题）、扩展性问题（存储线性增长，随序列变长模型难以聚焦关键信息）。适用场景包括简单聊天机器人、用户活动监控和不需复杂推理的日志系统。

功能语义标签法为每条信息附加功能角色标签和多维度标注。标签维度示例包括功能角色（goal、decision、action、observation）、优先级（high、medium、low）和来源（user_input、tool_output、agent_reasoning、external_knowledge）。实现示例显示结构化的JSON格式，包含content、tags（role、priority、source、timestamp）。优势在于结构化（易于检索和分析）、多维度（支持复杂筛选，如"找所有高优先级的目标"）和可解释（标签提供额外语义信息）。局限是略显僵化（预定义标签可能不够灵活）、维护成本（需要可靠的标注机制，人工或自动）和可能限制创造性合成（结构化可能阻碍自由组合）。适用场景包括复杂Agent系统（需要明确角色分工）、需要可审计性的应用（如医疗、金融）和多步骤工作流管理。

QA对压缩法将上下文重构为问答对，每个QA对是独立的知识单元。实现示例显示原始对话被转换为独立的问答对（如Q: Python有哪些排序算法？ A: Python内置Timsort，常用的还有快速排序、归并排序...）。优势在于检索友好（每个QA对是独立单元，可精确匹配）、适合FAQ系统和知识库、压缩比高（去除冗余对话）。局限是破坏思维流（原始对话的连续性丢失）、不适合需要整体理解的任务（如总结、深度推理）和生成QA对的质量依赖算法。适用场景包括FAQ机器人、知识库检索和客服系统。

层次化笔记法采用树状结构组织信息，从广泛概念到具体细节。实现示例显示markdown格式的层次结构（如1 用户任务：优化Python代码性能 2 当前代码分析 3 优化方向 4 算法替换）。优势在于清晰呈现信息分组、易于导航和浏览、层次关系显性化。局限是仅反映分组而不反映逻辑关系（因果关系、证据关系、对比关系）、不捕捉时间演化（新洞察如何产生、旧想法如何被修正）和静态结构导致动态性不足。适用场景包括知识整理、文档生成和项目管理（任务分解）。代表系统包括Claude Code和Gemini CLI的笔记系统以及各种笔记应用的Agent化。

选择决策树清晰：若任务需要精确事实检索（如FAQ），选择QA对压缩法；若任务需要复杂工作流管理，选择功能标签法；若任务需要知识整理和呈现，选择层次笔记法；若仅需简单记录和时序，选择时间戳标记法。混合策略的可能性包括不同层级采用不同范式，示例是短期记忆用时间戳，长期记忆用层次笔记。

多模态上下文融合的三大策略

多模态上下文处理工作流

上下文在LLM-based系统中变得越来越多模态，包含文本、图像、音频、视频、代码、传感器数据甚至环境状态。随着机器与真实或模拟环境的交互，它们必须能够将跨模态信息整合为连贯统一的表示，而非孤立处理每个模态。核心挑战在于这些模态的异构性：它们在结构、信息密度和时间动态上存在差异。例如，文本是离散和顺序的；图像是高维和空间的；音频是连续的并随时间展开；视频是时空的、多帧的和复杂的。如何将这些异构模态联合编码、比较并推理？

共享向量空间映射将不同模态（文本、图像、视频）转换为共享向量空间，使其含义可以直接比较。每个模态首先由自己的编码器处理（文本用BERT、GPT等Transformer编码器；图像用ResNet、ViT等视觉编码器；音频用Wav2Vec等音频编码器）。由于这些向量最初位于具有不同统计属性的独立表示空间中，因此每个向量都通过学习的投影层传递，该投影层将其映射到固定维度的共享空间。在这个共享空间中，来自不同模态的语义相关内容位置彼此接近，而不相关的内容则被推远。技术细节包括损失函数采用对比学习（Contrastive Learning，例如CLIP），共享空间特性使得文本"猫"的向量≈猫图片的向量，支持跨模态检索（文本查图片，图片查文本）。优势在于模态间可直接比较、支持零样本跨模态任务和架构灵活。局限是浅层对齐（仅在向量空间层面，未深度融合）和细粒度对应困难（"猫在沙发上"→图片的哪个区域？）。适用场景包括跨模态检索（图搜图、文搜图）、零样本分类和多模态embedding应用。

统一自注意力机制将不同模态转为token序列（文本为word tokens；图像为patch tokens，ViT方式；音频为frame tokens），拼接所有token，送入统一的Transformer，自注意力机制让所有token相互attend。关键创新在于细粒度跨模态交互：文本token可attend到图像的特定patch，图像patch可attend到文本的特定词，每一层都进行深度融合。与浅层拼接的对比在于：浅层拼接是各模态独立编码→拼接向量→后续处理；统一自注意力是从第一层就开始跨模态交互。优势在于深度融合（所有层都参与跨模态理解）、灵活（可处理任意模态组合）和端到端学习。局限是计算成本高（自注意力O(N2)，多模态token数量大）和需要大规模预训练。代表系统包括GPT-4和Claude 4等现代多模态LLM。适用场景包括需要细粒度理解的任务（图像描述、VQA，Visual Question Answering）和复杂推理（需要文本和视觉信息协同）。

跨模态交叉注意力让一个模态作为Query，另一个模态作为Key和Value，通过交叉注意力机制让Query聚焦到Key/Value的相关部分。机制详解假设文本query图像：Q = 文本特征（query），K, V = 图像特征（key, value），交叉注意力：Attention(Q, K, V) = softmax(Q·K^T / √d) · V，结果是文本特征增强（融合了相关图像信息）。架构灵活性包括可作为独立模块（Transformer前）、可嵌入Transformer块内部和可双向（文本query图像 + 图像query文本）。优势在于明确的方向性（一个模态聚焦另一个）、可控（可设计哪些模态交互）和参数效率（不需要完全融合）。局限是需要预先指定交互方向和不如统一自注意力灵活。代表系统包括Qwen2-VL和Flamingo等。适用场景包括有明确主从关系的任务（图像描述：文本为主，图像为辅）和需要可解释性的应用（能看到哪个文本token关注哪个图像区域）。

三种策略代表了从浅到深的融合思路：共享空间映射实现了"可比较"，统一自注意力实现了"深交互"，交叉注意力则在两者之间提供了"可控的定向融合"。选择哪种策略，取决于具体任务对融合深度、计算资源和可解释性的权衡。人脑的启示在于：人脑无需预先指定"视觉query听觉"，多感官信息自然融合。未来方向应发展更自然、更灵活的融合机制，如动态路由、稀疏专家混合（MoE，Mixture of Experts）和层次化融合。

上下文组织：构建认知架构

分层记忆架构

Andrej Karpathy的OS类比阐明了核心问题：LLM如同CPU（计算核心），上下文窗口如同RAM（工作内存，快但容量有限），需要类似磁盘的长期存储。上下文工程如OS（决定加载什么到内存）。人类认知的启示是工作记忆容量7±2项、持续秒级到分钟级；短期记忆持续小时级到天级；长期记忆持续天级到终身。

转移触发条件包括重复频率（短期记忆中多次出现）、情感显著性（与用户情绪、偏好相关）和知识关联（与已有长期记忆有强关联）。记忆转移机制类比人类：情景记忆（短期）→语义记忆（长期）。巩固过程包括识别短期记忆中的高价值信息、抽象、去噪、压缩、写入长期存储和建立索引以便检索。

实际应用案例如LeadResearcher处理超长上下文任务（>200k tokens）时，问题是研究计划的关键信息可能超出上下文窗口。解决方案是将研究计划存入持久化内存（长期记忆），避免因窗口限制丢失关键信息，新任务时从长期记忆检索相关计划。

扩展至多层架构时，二层模型是简化（为clarity），实际系统常有更多层：L0（当前token，即时）、L1（工作记忆，活跃推理状态）、L2（情景缓冲，最近事件）、L3（短期记忆，会话级）、L4（中期记忆，天/周级）、L5（长期记忆，持久）、L6（语义知识，高度抽象、跨任务）。

上下文隔离

Subagent模式是Claude Code实践的案例。核心机制是每个subagent是独立的AI助手，拥有自己的上下文窗口、自己的系统Prompt和受限的工具权限。功能隔离按功能维度分割：分析Subagent专注代码分析和问题诊断，执行Subagent专注代码编写和文件操作，验证Subagent专注测试和质量检查。每个子任务委派给匹配的Subagent，Subagent在隔离环境中操作。

层级隔离包括规划层（高层策略制定）、实现层（具体任务执行）和审查层（结果验证）。最小权限原则确保每个Subagent仅获得其职责所需的最小工具集，减少误用风险，提升系统可靠性和可解释性。价值总结包括避免主上下文污染、提升模块性和可维护性、扩展总token消费能力（每个Subagent有自己的窗口）。

LeadResearcher的并行子任务机制是：LeadResearcher先制定计划，如果可用信息不足→发起搜索，创建多个并行子任务（每个是独立Subagent），子任务独立工作互不干扰，LeadResearcher汇总中期结果并决策下一步。反馈循环调整关键词、修正搜索策略并收敛到高质量答案。优势在于相比静态RAG更灵活，动态调整而非一次性检索。

轻量级引用技术应对大块输出的场景。问题场景是某些工具输出极大（如大文件内容、长日志），直接放入上下文会消耗大量tokens。沙盒方法（HuggingFace CodeAgent）将大块输出存储在外部沙盒，上下文中仅保留轻量引用（如文件ID、片段索引），需要时按需检索。基于Schema的状态对象将重元素（文件、日志）保留在外部存储，上下文中仅暴露schema的选定字段（示例：仅包含文件路径、大小、修改时间，不含内容），需要内容时通过工具调用获取。价值在于大幅减少token开销、保持完整上下文的可访问性和提升响应速度。

上下文抽象（Self-baking）

哲学意义

Self-baking的核心区分在于记忆存储与知识学习。记忆存储是保留原始数据、回溯时重新阅读，类比录像回放。知识学习是提炼抽象知识、形成可复用的模式，类比从经验中总结规律。

Self-baking的定义是Agent选择性地将自己的上下文消化为持久知识结构，不是简单存储，而是学习的过程。人类认知的类比包括：情景记忆→语义记忆（情景：昨天在餐厅吃了川菜；语义：川菜通常很辣）和行动→习惯（行动：每天早上刷牙；习惯：自动化的早晨routine）。

Self-baking的本质是将记忆存储转化为学习的关键机制。没有Self-baking，Agent仅仅回忆；有Self-baking，Agent积累知识、形成智慧。

四种实现模式

Self-baking的代表性设计

模式A：原始+自然语言摘要保留所有原始上下文（对话、工具输出等），周期性生成自然语言摘要。实现机制包括保留所有原始上下文和周期性生成自然语言摘要（频率：每N轮对话、每M个token、或任务节点；生成方式：人工或LLM自动生成）。

摘要内容结构（以Claude Code为例）包括：当前任务总结（整体目标：用户希望优化一个Python数据处理脚本的性能；关键知识：原脚本使用pandas处理100万行数据，主要瓶颈在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）；始终保留原始数据（备查和重新提取）。

上下文使用：让知识发挥价值

上下文使用涵盖多个关键决策点，从系统内共享到跨系统协作，从选择策略到主动推断。以下是完整的设计考虑框架：

上下文工程设计考虑因素

这张图系统展示了上下文工程在收集存储、管理和使用三个核心维度上的设计考虑，为实践提供了完整的导览地图。

系统内上下文共享

跨Agent上下文共享模式

现代LLM应用常由多个Agent组成，每个Agent负责部分推理工作流。实际价值在于多Agent扩展了总token消费能力。核心挑战是如何在Agent间传递信息，如何保证信息的准确性、可解释性、可用性。

Prompt嵌入模式直接将前置上下文包含在下一个Agent的输入Prompt中，常配合格式化重构（摘要、结构调整）。实现示例是Agent A完成分析任务后输出分析结果，Agent B的输入Prompt包含"前序分析结果：[Agent A的输出] 请根据上述分析，编写优化后的代码。"变体是格式化重构，将Agent A的长篇输出（如3页分析报告）重构为结构化摘要（如5点bullet list），便于Agent B快速理解。

优势在于实现简单（不需要额外基础设施）、灵活（可根据需要调整传递的信息）和透明（信息流清晰可见）。局限是上下文膨胀（随Agent链增长，Prompt越来越长）、信息冗余（可能重复传递无关信息）和格式不一致（不同Agent可能对格式有不同理解）。适用场景包括顺序型工作流（A→B→C）、Agent数量少（<5个）和快速原型。代表系统包括AutoGPT（早期版本）和ChatDev（多Agent软件开发）。

结构化消息交换通过固定schema的消息通信，类似微服务间的API调用。消息Schema示例显示JSON格式包含message_id、from、to、timestamp、task_type、input_data、output_requirements和reasoning_context。Schema设计原则包括明确的任务类型字段、结构化的输入数据、清晰的输出要求和可选的推理上下文（帮助接收Agent理解背景）。

优势在于清晰且一致（所有Agent遵循同一协议）、可验证（可自动检查消息格式正确性）、可扩展（新Agent只需遵循schema即可接入）和易于调试（消息可记录、重放）。局限是设计成本（需要前期投入设计schema）、灵活性降低（schema变更需要所有Agent更新）和冗余字段（某些Agent可能不需要所有字段）。适用场景包括复杂多Agent系统（>5个Agent）、需要可靠性和可维护性的生产环境和多团队协作（schema作为接口契约）。代表系统包括Letta和MemOS。

共享记忆模式的核心思想是Agent不直接通信，而是通过读写共享记忆空间间接协作，类比黑板系统（Blackboard System）。

子类型1记忆块池（Memory Block Pool）采用中心化的记忆池，每个Agent可读写记忆块。记忆块结构包含block_id、author、timestamp、type、content、tags、access_count和last_accessed_by。工作流程显示：Agent A完成分析→写入记忆块；Agent B检查记忆池→发现相关块→读取；Agent B完成任务→写入新块（标记依赖于Agent A的块）。优势在于解耦（Agent间无直接依赖）、异步（无需等待对方完成）和灵活（可多对多通信）。局限是竞态条件（多Agent同时写入可能冲突）和垃圾收集（需要策略清理过时块）。

子类型2结构化黑板（Structured Blackboard）将记忆池按主题/任务分段，每个Agent监控相关段。黑板结构按segment组织，如"performance_issues"段包含Entry 1和Entry 2，"optimization_proposals"段包含Entry 1和Entry 2，"implementation_status"段包含Entry 1和Entry 2。Agent行为是只监控与自己专长相关的segment，发现新信息→处理→写入结果到相关segment。优势在于模块化（减少信息过载）、专业化（Agent专注其领域）和可扩展（新segment和Agent可动态加入）。局限是需要预定义segment结构和跨segment协调较复杂。

子类型3图结构记忆（Graph-based Memory）的动机是线性记忆块无法表达复杂关系，图更适合建模依赖、因果、推理链。

任务记忆引擎（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将上下文编码为向量（使用embedding模型），向量传递给System B，System B使用向量进行语义搜索或作为上下文输入。示例代码显示cursor_context编码为embedding（shape: (768,)），传递向量到ChatGPT系统，ChatGPT解码或直接使用相关记忆。

优势在于紧凑（向量比文本小，通常几百到几千维）、系统无关（向量是通用表示）、语义搜索（高效的相似度计算）和可扩展（支持大规模记忆库）。劣势是不可读（人类无法理解向量内容）、需要模型（编码和解码依赖ML模型）、模型依赖（不同模型的向量不兼容，需要同一embedding模型）和信息压缩损失（向量可能丢失细节）。代表系统包括Sharedrop（跨平台文件和上下文共享）。

选择指南清晰：系统数量少（2-3个）推荐适配器模式；系统数量多（>3个）推荐共享表示模式；需要精确性推荐统一JSON Schema；需要灵活性推荐自然语言摘要；需要大规模语义搜索推荐语义向量；人类也参与理解推荐自然语言摘要；完全自动化推荐JSON Schema或向量。

上下文选择的五大维度

扩展上下文窗口的悖论是能力上升但效果下降。经验观察显示窗口填充度超50%时性能下降，原因是噪音掩盖信号、模型注意力分散和"迷失在中间"现象（Lost in the Middle）。

实验发现：上下文开头和结尾的信息容易被记住，中间部分容易被遗漏。当关键信息位于中间时，性能显著下降。这不是偶然现象，而是Transformer注意力机制的固有特性——位置编码使得模型对序列两端更敏感。这也解释了为什么单纯扩展窗口无法解决长上下文问题。

上下文选择的核心隐喻是"注意力之前的注意力"——模型的self-attention选择关注什么，但上下文选择决定什么值得被关注，这是元层面的注意力机制。

语义相关性（Semantic Relevance）的定义是与当前查询或目标在语义上最相似的上下文。技术实现显示查询和候选上下文都编码为向量，计算余弦相似度，排序并选择Top-K。代码示例展示完整流程。

RAG中的应用通过向量数据库（如FAISS）加速相似度搜索，即使没有关键词匹配也能找到语义相关内容。优势在于无需精确匹配（模糊搜索）和跨语言（多语言embedding可跨语言检索）。局限是可能检索到语义相似但逻辑无关的内容（示例：查询"如何优化join"可能检索到"如何debug join"，语义相似但意图不同）。

逻辑依赖（Logical Dependency）的定义是当前任务直接依赖的前序上下文，超越表面语义关注推理链。MEM1系统的实现显示执行步骤时记录依赖：Step 1分析代码产生[瓶颈报告]，Step 2设计优化方案依赖[瓶颈报告]产生[优化建议]，Step 3实现优化依赖[瓶颈报告, 优化建议]产生[优化代码]。新查询"测试优化效果"时遍历依赖图，检索[瓶颈报告, 优化建议, 优化代码]而非仅基于语义相似度。

依赖图构建显示每个记忆槽记录内容、产生者和依赖的其他槽，形成有向无环图（DAG）。价值在于反映真实的推理流程、避免遗漏关键前提和支持推理的可追溯性。

时间性与频率（Recency & Frequency）包括时间性（Recency）：新近使用的上下文更可能再次相关，实现采用时间衰减函数；频率（Frequency）：频繁访问的上下文更重要，实现采用访问计数权重。组合策略代码示例显示综合语义相似度、时间衰减权重和频率权重，使用加权组合（0.5×语义相似度 + 0.3×时间权重 + 0.2×频率权重）。

冗余消除（Redundancy Elimination）应对问题：多个上下文可能表达相同或相似的信息，保留所有会浪费窗口空间。被动去重检测语义重叠（embedding相似度>阈值），保留最新或最详细的版本。

主动内存管理不仅检测更主动采取行动：合并（两个相似上下文→一个综合版）、更新（用新信息更新旧条目）、删除（明确过时的信息）。示例显示旧信息"用户偏好使用pandas"与新信息"用户现在更倾向于polars"，主动管理后更新旧条目为"用户曾偏好pandas，现转向polars"，而非保留两个矛盾的条目。

用户偏好学习（User Preference Learning）通过Self-Evolution Memory跟踪用户与上下文的交互，学习哪些类型的信息用户重视。学习信号包括正信号（用户重视）：详细阅读（停留时间长）、追问相关问题、采纳建议、明确标记"有用"；负信号（用户不重视）：快速跳过、明确标记"无关"、从不采纳类似建议。

权重调整代码示例显示根据用户反馈动态调整上下文重要性权重（positive反馈×1.2，negative反馈×0.8）。个性化检索使相同查询不同用户得到不同上下文，基于历史偏好调整排序。

主要考虑因素是相关性，可以通过几个因素评估，包括语义相似度、逻辑依赖、时间性（信息的时效性）和频率。例如，许多系统使用相似度分数将当前输入与存储内容进行比较，为相似度更高的信息分配更高的相关性。或者，可以合并显式标签或元数据来指示特定数据的重要性或功能，例如将某些事件标记为里程碑或突出关键事实。除了相关性，重要的是最小化冗余信息并适应用户习惯。通过整合这些标准，系统能够保留最相关的数据、减少不必要的噪音并提高上下文选择的效率。

RAG工程实践

分段（Chunking）包括固定窗口（机制：按固定行数或token数切分；优势：简单、统一；劣势：可能破坏语义完整性，如一个函数被切成两段、一句话被腰斩）和语义边界分段（AST-based）（机制：根据代码结构切分，如Python按函数、类、模块，Markdown按标题层级；优势：保持语义完整性；劣势：段大小不均，某些函数很长）。混合策略是语义分段为主，过长段再细分，保证每段在合理大小范围。

检索方式包括语义检索（主流），步骤显示：查询embedding，向量数据库搜索，返回相似段落。非语义检索包括Grep/正则（精确字符串匹配，适用场景：查找特定函数名、变量名）和全文搜索（倒排索引，ElasticSearch等，适用场景：关键词搜索）。结构化检索包括知识图谱（实体-关系查询，示例："找出所有调用函数X的函数"）和函数调用图（代码依赖分析，示例："这个文件依赖哪些模块？"）。

选择建议清晰：若查询是概念性的（如"如何优化性能"）选择语义检索；若查询是精确匹配（如"find_user_by_id函数在哪"）选择非语义检索（Grep）；若查询涉及代码结构（如"哪些函数调用了这个API"）选择结构化检索（调用图）。

重排序（Reranking）的动机是初筛（向量检索）速度快但准确度有限，精排（LLM评分）准确但慢，两阶段结合实现效率+质量。实现显示：阶段1向量检索（从100k候选中筛出100个），阶段2 LLM重排序（精排这100个，对每个候选生成relevance评分Prompt，输出仅数字）。

权衡包括：准确性提升10-30%（经验值）；延迟增加+0.5-2秒；成本增加（每个候选一次LLM调用）。不同系统的选择如Windsurf使用重排序（优先质量），某些实时系统跳过重排序（优先速度）。

主动需求推断

从被动到主动的转变显示：Era 1.0-2.0前期AI被动响应，Era 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(N2)复杂度导致推理延迟快速增长、GPU内存使用高和I/O吞吐量慢。这些资源瓶颈使得实时处理大型上下文变得不切实际。同时推理质量退化：随着注意力在更长输入上变薄，模型难以维持对相关信息的焦点，难以捕捉长距离依赖。此外，检索系统被许多语义相似但无关的信息片段淹没，通常返回干扰而非有用证据。此外，随着上下文量增长，检测和调和检索片段之间的不一致和冲突变得更加困难。所有这些问题导致在处理非常大的上下文时推理变得脆弱。

挑战III：系统不稳定是随着记忆随时间积累，即使是小错误也可能影响系统的更多部分。曾经影响有限的错误现在可能广泛传播，导致意外或不稳定的行为。如果没有清晰的边界或验证机制，系统变得更难管理，特别是在长时间运行或需要高安全性的任务中。在这种情况下，它可能使系统更加脆弱而不是增加可靠性。

挑战IV：评估困难是随着记忆积累，判断系统推理是否正确变得更加困难。当今大多数基准测试只测试系统是否能检索信息，但不检查信息是否仍然相关、准确或有用。系统很少包含检查矛盾、撤销错误更新或追溯导致结论的推理步骤的功能。随着越来越多的决策依赖于更长的记忆链，检查系统如何得出特定答案变得越来越困难。这种可见性的缺乏使得信任或改进系统变得困难，特别是对于终身上下文工程。

迈向语义操作系统的必要性在于终身上下文工程的挑战不能再通过简单地"扩展上下文窗口"或"改进检索准确性"来解决。它要求构建一个能够随时间增长的语义操作系统，就像人类的思维一样。一方面，这样的系统必须支持大规模、高效的语义存储作为自己的记忆库，并表现出真正类似人类的记忆管理能力：主动添加、修改和遗忘知识。另一方面，它需要新型架构来替代Transformer的平坦时序建模，从而实现更强大的长程上下文推理和动态适应。关键是，系统应该能够通过追踪、纠正和解释其推理链中的每一步来解释自己，从而提高实际和安全关键场景中的信任和可靠性。这种方法突出了上下文工程的基本原则，并反映了范式转变：上下文不再被动积累，而是作为认知的核心元素被主动管理和演化。

语义操作系统的愿景核心理念是上下文不再被动积累，而是主动管理和演化的认知核心。

必要能力一是大规模语义存储。传统数据库存储数据并基于索引查询，语义存储则存储意义、理解语义关联并支持概念推理。技术要素包括语义图谱（节点为概念、事实、事件，边为关系如因果、支持、矛盾、时序）、多级索引（文本索引用于全文搜索、向量索引用于语义相似度、图索引用于关系查询）和分布式架构（支持PB级数据、毫秒级查询延迟、高可用性）。

必要能力二是类人记忆管理。人类的记忆机制启示包括主动添加（不是被动接收所有信息，而是主动选择记住什么，基于重要性、情感、关联度）、主动修改（记忆不是只读的，会随新经验更新、重组，整合矛盾信息）和主动遗忘（传统观点认为遗忘是bug，新视角认为遗忘是feature，好处包括释放存储空间、避免被无关信息干扰、保持认知敏捷性）。

实现机制包括重要性评分（综合访问频率、时间衰减、用户反馈、关联度和情感显著性，定期清理低分记忆，如果重要性评分低于阈值则归档而非删除以便可恢复）和记忆整合（将多个相关记忆整合为一个抽象记忆，例如记忆A"2025年1月，用户询问Python性能优化"、记忆B"2025年3月，用户询问Python性能优化"、记忆C"2025年5月，用户询问Python性能优化"整合后为"用户持续关注Python性能优化（2025年1-5月，3次）"，原始记忆降级为"归档"状态）。

必要能力三是新型推理架构。Transformer的根本局限是平坦的时序建模（所有token平等对待）、无法天然表达层次结构和长距离依赖的注意力稀释。层次化推理架构包括L1抽象层（宏观理解："这是一个性能优化任务""涉及算法和数据结构"）、L2概念层（概念识别："瓶颈在join操作""候选方案：哈希表、排序归并"）和L3细节层（具体推理："哈希表空间复杂度O(n)""时间复杂度从O(n²)降到O(n)"）。推理流程从L1→L2→L3（从抽象到具体）和L3→L2→L1（从具体到抽象，验证一致性）。

动态上下文路由根据查询动态决定关注哪些上下文，而非均匀attend所有上下文。实现包括第一阶段粗筛（粗筛：相关性评分，候选项=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是共同成长的认知伙伴，上下文成为共享的"记忆空间"）；数字化存在（Karl Marx曾写道"人的本质是社会关系的总和"，在AI时代这一观念获得了新的计算意义："人的数字化本质是上下文的总和"，终身上下文=数字化的"我"，可以持续存在、不断演化、甚至可以在物理身体之外延续）。

涌现的工程智慧

KV缓存优化

KV缓存工作原理是Transformer生成token时存储past 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缓存一致性）。推荐做法显示良好做法稳定工具列表+解码级约束（固定工具列表，根据上下文决定哪些工具"可用"，解码时mask掉不可用工具的logits）。解码级约束的价值在于保持工具列表稳定（KV缓存友好）、通过logit masking限制选择（降低错误率）和动态控制而无需改变输入。技术启示是清晰胜于数量、约束而非自由放任、工具设计是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、有严格deadline-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步操作后插入目标摘要。价值在于将目标重新注入近期上下文窗口、保持模型注意力聚焦在主线任务、避免在分支细节中迷失。技术启示是简单的工程技巧往往很有效、人类的任务管理智慧（todo list、定期回顾）同样适用于AI、显式>隐式。

应用案例

Gemini CLI

当使用AI agent时，开发者通常需要持续的、面向项目的上下文支持。Google的Gemini CLI提供了一个关于如何设计上下文的代表性案例。中心机制是GEMINI.md文件，这是一个Markdown格式的规范，记录项目背景、角色定义、所需工具和依赖项、编码约定等。

上下文通过文件系统层次结构组织：GEMINI.md文件可以存在于用户的主目录、项目根目录或子目录中，实现信息的继承和隔离。继承与覆盖规则是子目录继承父目录的GEMINI.md、同名字段子覆盖父、不同字段合并。

上下文生命周期包括启动时（静态加载）：自动加载静态信息如系统提示、当前项目环境以及祖先或后代GEMINI.md文件；交互中（动态积累）：增量积累来自持续对话历史的动态上下文。

对于管理，CLI采用压缩与摘要策略。触发条件是窗口填充度超过阈值（如70%）。摘要生成是调用LLM将长历史压缩为结构化摘要，这些摘要遵循预定义格式以保持一致性。格式示例包括压缩摘要（生成时间）、整体目标、关键知识、文件系统状态和当前计划。

社区讨论还建议用人工精炼扩展此过程以支持上下文的协作管理。建议机制是AI生成初版GEMINI.md、人类审核和精炼、版本控制（Git）。价值在于结合AI效率与人类判断力。技术启示包括文件系统作为轻量级数据库、层次化上下文组织和自动+人工的混合管理。

Tongyi DeepResearch

深度研究agent旨在帮助用户处理开放式、知识密集型查询，如涉及多个事件和交织关系的推理任务。一个代表性例子是Tongyi DeepResearch，它以四个主要步骤运作：基于用户查询在web上搜索，从相关页面提取关键信息，生成新的子问题以指导进一步搜索，最终将多个来源的证据整合为连贯的答案。

这个循环通常持续多轮，直到不确定性降低并形成完整的证据链。与短回合对话agent不同，深度研究面临极长交互历史的挑战：直接追加所有观察、思考和动作会迅速超出上下文窗口。为了克服这一限制，Tongyi DeepResearch采用系统化的上下文工程。

在探索过程中，agent定期调用专门的摘要模型将累积的历史压缩为紧凑的推理状态，不仅保留关键证据，还突出缺失信息和下一步方向。后续的搜索和推理基于这些压缩的"上下文快照"而非完整的原始历史。

快照内容包括summary_id、timestamp、original_query、key_evidence（IBM和Google在量子硬件上取得突破等）、missing_information（具体的商业案例和ROI数据等）、next_steps（搜索量子计算商业案例研究等）和confidence_level。后续推理基于快照而非完整原始历史，大幅减少token消耗。

通过这种方式，系统建立了清晰的上下文生命周期：从收集和积累信息，到定期压缩和抽象，然后基于摘要进行推理和复用，使其能够突破上下文约束并实现可扩展的长周期研究能力。技术启示包括长周期任务必须有上下文压缩机制、摘要不是简单truncate而是智能提炼、分层记忆（原始历史归档+快照活跃）。

脑机接口

脑机接口（BCI）为上下文工程提供了一条新路径，使更先进的上下文收集成为可能。与依赖语言输入的传统方法不同，BCI可以直接捕获神经信号，这带来了两个独特的优势。

首先，它们允许收集更丰富的上下文维度，如注意力水平、情绪状态或认知负荷——这些因素通常难以仅通过外部行为观察。其次，它们提供了更便捷的上下文收集方式，减少了对显式用户动作的需求，并通过神经活动实现更即时的输入。

当前局限包括粗粒度理解（只能识别大致状态如注意/分神，无法读取具体思维内容）、噪音问题（神经信号易受干扰、信噪比低）、不稳定性（个体差异大、同一人不同时刻也有波动）和侵入性（某些BCI，高精度BCI需要植入电极、伦理和安全问题）。

虽然当前技术仅提供对大脑信号的粗略理解，噪音和不稳定性等问题仍是重大挑战，但BCI突出了上下文工程可能演化的方向：将上下文收集从外部环境扩展到用户的内部认知状态。未来方向包括非侵入式BCI精度提升、从外部环境到用户内部认知状态的上下文采集、真正的"意念交互"和与LLM结合（神经信号→语义解释）。技术启示是上下文工程的边界不断扩展、从外部观察到内部感知、Era 3.0的重要特征之一。

总结：站在演进的十字路口

这篇论文显示，上下文工程不是LLM时代的突然发明，而是一个持续演进超过20年的学科。从1990年代的普适计算和上下文感知系统，到今天的智能Agent和LLM，上下文工程始终围绕一个核心挑战：如何让机器更好地理解人类的情境和意图。

这一演进遵循清晰的规律：机器智能的每一次跃迁都引发范式转变。Era 1.0的被动执行者需要人类将意图翻译为低熵的结构化命令。Era 2.0的主动智能体能够理解自然语言并进行部分推理，但仍需Prompt工程等人工介入。Era 3.0的人类级智能将接近自然的人机协作，而Era 4.0的超人类智能可能反转主客体关系，AI成为洞察与灵感的源泉。

当前实践揭示了一系列系统化的方法论：分层存储架构平衡性能与持久性；多样化的文本处理范式和多模态融合策略应对异构信息；分层记忆、上下文隔离和Self-baking机制构建认知架构；语义相关性、逻辑依赖、时间频率等多维度指导上下文选择；KV缓存优化、工具设计、内容策略等工程智慧提升系统效能。

然而，重大挑战依然存在。存储瓶颈、处理退化、系统不稳定和评估困难等问题提醒我们，"扩展窗口"的线性思维不足以应对终身上下文的系统性挑战。未来需要的是质变而非量变——一个能够主动管理和演化上下文的语义操作系统，具备大规模语义存储、类人记忆管理、新型推理架构和全程可解释性。

正如Karl Marx所言"人的本质是社会关系的总和"，在AI时代，这一论断获得了新的计算意义：人的数字本质是上下文的总和。上下文工程不仅是技术问题，更是关于意义构建、知识演化和人机共生的哲学问题。我们正站在Era 2.0向3.0过渡的关键期，理解历史才能把握现在、预见未来，当前的工程实践应为下一阶段的飞跃做好准备。

上下文工程的旅程，就是人机协同演化的旅程。在这条路上，我们不仅在优化系统，更在探索智能的本质、意义的构建、以及人类与AI共生的可能性。让我们以开放的心态、严谨的方法、前瞻的视野，共同书写上下文工程的下一个篇章。

看完此文，我的感受是对模型静态参数以外的世界（上下文）有了更加清晰的认识，之前站在应用工程、数据工程、模型底层去理解Context，但却没有像论文作者这样，系统化梳理甚至用哲学思想来理解上下文工程。这也激发了我对这轮以 Transformer 架构模型为基础 AI 浪潮的思考。从我开始了解 transformer 架构模型开始，我就确定了以后的学习和工作必然会围绕着 AI 展开了。我认为互联网于我在 3 年前遇到这场 AI 变革以后，已是过去式。它是我过去的老朋友，20+ 年互联网人也许正经历自我的蜕变。随着模型的不断进化，以及行业对模型认知的加深，结合当下我们正在经历的百年变局，以及10多年前那场无疾而终的任务。此刻的我，内心忽然有种使命感，它在激发我想要穿越，用当下的 AI 能力去重写 10 多年前的互联网逻辑。我知道这充满挑战，但我很想尝试，并且现在、立刻就想行动。互联网人，应具有天生的韧劲，沙漠里没有树，那就种树，种树没有水，那就挖井，挖井没有工具，那就用手造工具，逢山开路遇水搭桥....