上下文工程：让AI Agent不再"胡言乱语"的系统方法

为什么模型会"乱说话"

想象一块写满了字的白板，如果你还硬往上贴新内容，会发生什么？重点被挤到角落，关键信息被覆盖，看的人根本抓不住要点。大语言模型（LLM）的上下文窗口正是这样一块白板——历史对话、工具调用结果、参考文档全部堆在有限的空间里，当窗口被塞满，真正重要的信息就被挤掉，模型也就开始"胡言乱语"。

上下文窗口（Context Window）是大语言模型在单次推理中能够"看到"的最大token数量。 Token并非简单等同于字符，通常一个英文单词约为1-2个token，一个中文汉字约为1-2个token。早期GPT-3的上下文窗口仅有4096个token，而现代模型如GPT-4 Turbo、Claude 3已扩展至128K甚至百万token级别。然而，窗口变大并不意味着问题消失——斯坦福大学2023年的研究论文《Lost in the Middle》通过实验证实，当相关信息被放置在长上下文的中间位置时，模型的准确率会显著下降，而位于开头和结尾的信息则被优先编码。

这一现象源于Transformer架构中注意力机制的工作原理——位置编码和注意力权重的分布并非均匀，模型对序列边界的信息天然更敏感。值得一提的是，位置编码本身也在持续演进：早期使用正弦余弦固定编码，现代长上下文模型普遍采用RoPE（旋转位置编码）或ALiBi等相对位置编码方案，以更好地外推到训练时未见过的超长序列。RoPE通过在复数空间中对查询和键向量施加旋转变换来编码位置信息，其相对距离天然融入注意力得分计算，使模型在处理超长序列时表现出更好的外推性；ALiBi则采用更为激进的线性惩罚方案，直接在注意力得分上叠加与位置距离成比例的负偏置，无需任何可学习的位置参数，在推理阶段对训练长度以外序列的泛化能力尤为突出。尽管如此，注意力权重的"边界偏好"在各类架构中依然普遍存在，成为长上下文工程中必须正视的结构性约束。这也解释了为何即便拥有超长窗口，在实际工程中仍需精心设计信息的放置顺序：最关键的指令和参考资料应优先放在提示的开头，总结性约束放在末尾，以最大化模型的有效注意力。这一特性使得上下文的排列顺序和信息密度管理变得尤为重要。

很多时候，我们误以为模型"笨"，但真相往往是：它和你的世界断开了连接。模型不知道你的私有文档，也不知道昨天发生了什么。当缺乏足够上下文时，它就容易自信满满地编造答案——这就是所谓的"幻觉"。

大语言模型的"幻觉"（Hallucination）并非随机错误，而是有其深层的统计机制根源。LLM本质上是一个概率预测器，在训练阶段通过海量文本学习"下一个词最可能是什么"。当模型缺乏相关上下文时，它仍会基于训练数据中的统计规律生成听起来合理的内容——即使这些内容与事实不符。幻觉可分为两类：一是"内在幻觉"，模型生成的内容与提供的参考资料矛盾；二是"外在幻觉"，模型生成的内容无法被任何资料核实。从信息论角度理解，幻觉本质上是模型在知识空白处进行的"最大似然外推"——模型倾向于生成在训练语料中高频共现的词序列，而非承认自身知识边界。这一机制导致模型的幻觉往往具有极强的表面说服力：行文流畅、格式规范，却在事实层面完全失真，使其比明显的错误更难被发现和纠正。研究表明，提供高质量、精准的上下文信息是目前减少幻觉最有效的工程手段之一，这也是RAG（检索增强生成）技术兴起的核心驱动力。

RAG由Meta AI于2020年在论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中正式提出，其核心思想是将参数化知识（存储在模型权重中）与非参数化知识（外部文档库）解耦：模型权重负责推理能力，外部知识库负责事实准确性。这一架构使知识更新成本从昂贵的全量微调降低为文档库的增量更新，同时提供了可溯源的引用依据，极大缓解了幻觉问题，已成为企业级AI应用的标准范式。从技术演进角度看，RAG已从早期的朴素单轮检索（Naive RAG）发展为高级RAG（Advanced RAG）和模块化RAG（Modular RAG）。高级RAG引入了预检索优化（如查询增强）和后检索优化（如重排与上下文压缩）；模块化RAG则进一步将各检索组件解耦，支持灵活组合，并引入迭代式检索（Iterative RAG）和自适应检索机制，使系统能够根据问题复杂度动态决定检索策略，代表了当前RAG工程化的最前沿方向。

上下文工程（Context Engineering）就是整理这块白板的系统方法。 它不是某个单点技巧，而是一套完整的组件体系，决定了信息如何进入、如何组织、如何被模型高效利用。

上下文工程的核心组件

上下文工程是一个由多个协同组件构成的系统，可以大致分为三层职责：Agent负责决策，查询增强与检索负责找信息，提示、记忆与工具负责组织行动。

Agent：系统的交通调度员

Agent在整个体系中扮演着交通调度员的角色。它决定信息往哪个方向流动，也决定在什么时机调用哪个工具。在执行复杂任务的过程中，Agent还需要持续维护任务状态——记录已完成了什么、当前进行到哪一步。

更关键的是它的容错能力：当某条执行路线失败时，Agent必须能够重新规划路径，而不是卡死或直接放弃。这种动态调度与自我修复能力，是Agent区别于简单调用链的本质特征。现代Agent架构通常基于ReAct（Reasoning + Acting）框架，由谷歌DeepMind于2022年提出，并发表于ICLR 2023。其核心思想是将推理过程（Thought）与外部工具调用（Action）交替执行，每次行动后通过观察（Observation）反馈更新推理状态，形成Think→Act→Observe的迭代循环。这一设计的关键突破在于：推理过程本身也被显式写入上下文，使模型能够在复杂多步骤任务中保持连贯的决策逻辑。相比早期仅依赖单步提示的Agent方案，ReAct的显式推理链大幅降低了模型在长程任务中"忘记目标"的概率，并使调试和可解释性成为可能——开发者可以直接审阅模型的推理轨迹，定位决策失误的具体环节。

在实际工程中，ReAct的挑战在于推理链会持续消耗上下文token——一个执行20步操作的Agent，其历史推理链可能消耗数万token。为此，工程师通常采用滑动窗口（只保留最近N步推理历史）或层次化摘要（将早期推理链压缩为简洁摘要）等策略。Plan-and-Execute架构作为ReAct的演进方向，将规划阶段与执行阶段分离，以减少单次推理的上下文负担，适用于步骤数量较多的长程任务。如何压缩历史推理轨迹、只保留对当前决策有用的信息，始终是Agent开发中的关键工程问题。

查询增强：把口语问题翻译清楚

用户提出的问题往往是杂乱的、口语化的。查询增强（Query Enhancement）就像一个翻译柜台，先把模糊的口语问题重写成清晰规范的表达，再进行扩展——统一术语、补充关键词。

面对复杂问题时，它还会进一步拆解，将一个大问题分解为多个可独立处理的子查询（Sub-query）。这样一来，后续的检索环节才能精准命中相关信息，而不是被一个含糊的提问带偏。常见的查询增强技术还包括HyDE（假设性文档嵌入）——由卡内基梅隆大学提出，其核心洞察来自语义空间的不对称性：用户的原始问题通常是简短的疑问句，而相关文档则是陈述性的长文本，两者在向量空间中的距离往往远大于两篇相关文档之间的距离。HyDE先让模型生成一段假设性的答案文档，再用该答案的向量去检索真实文档，利用了"答案在语义空间中更接近答案"的几何特性，显著提升了知识密集型查询的召回质量。另一类重要的查询增强技术是多查询检索（Multi-Query Retrieval）：针对同一个用户问题，使用LLM自动生成3-5个语义等价但表述各异的变体查询，分别检索后取并集。这一策略的价值在于对冲了单一查询在语义空间中的"方向偏差"——当用户原始问题的措辞恰好与文档中的关键表述存在语义漂移时，多查询可以从不同角度覆盖相关内容，显著提升召回率，是简单易实现但效果稳定的工程实践。

检索：像在图书馆找书

检索（Retrieval）环节的本质，就像在图书馆里找书。这个过程有几个关键步骤：

首先要把文档清洗干净，去除噪声和无关格式；然后将文档切分成合适大小的小块（Chunking）——切得太大浪费上下文空间，切得太小又会丢失语义完整性；接着由向量数据库负责快速找到与查询最相关的片段。

向量数据库（Vector Database）是现代RAG系统的核心基础设施。 其工作原理是：通过嵌入模型（Embedding Model）将文本片段转化为高维向量（通常为768维或1536维的浮点数数组），这些向量在几何空间中的距离代表了语义的相似程度。检索时，用户查询同样被转化为向量，系统通过近似最近邻（ANN）算法快速找到语义最相近的文档片段。其中HNSW（分层可导航小世界图）是工业界最广泛采用的ANN算法，其原理是构建多层图结构，上层稀疏、下层密集，检索时从上层快速定位大致区域，再在下层精细查找，兼顾了O(log n)级别的查询速度和高召回率；Meta开源的FAISS则提供了多种索引结构选择，适合大规模离线批处理场景。除此之外，ScaNN（Google研究）通过各向异性量化进一步平衡了检索精度与内存占用，代表了ANN算法的另一演进方向。

在Chunking策略上，固定大小分块之外，语义分块（Semantic Chunking）通过检测相邻句子嵌入向量的相似度骤降点来确定切分位置，保留了更完整的语义单元；父子分块（Parent-Child Chunking）则采用小块检索、大块输入的策略，兼顾检索精度与上下文完整性。Chunk大小的选择本质上是一个精度-召回率的权衡问题：较小的chunk（如128 token）提高了向量表示的语义纯度，使检索更精准，但上下文信息密度较低，可能导致答案生成时缺乏必要背景；较大的chunk（如512 token）保留了更完整的语义连贯性，但向量表示会被多个主题稀释，降低检索精度。主流向量数据库产品包括Pinecone、Weaviate、Chroma和pgvector等。值得注意的是，向量检索擅长语义相似性匹配，但对精确关键词匹配有时不如传统全文检索（BM25）——BM25基于词频-逆文档频率原理，对包含精确术语、产品型号、专有名词的查询具有天然优势。因此，生产级系统通常采用混合检索策略，将两路结果通过倒数排名融合（RRF）算法合并后再进行重排。RRF以其无需参数调优、对不同检索系统评分尺度天然鲁棒的特点，成为混合检索中事实上的标准融合方法。

值得强调的是，检索出来的结果并不能直接使用，还需要经过重排（Rerank），将真正相关度最高的内容排在前面，再放进上下文。重排采用的Cross-Encoder与向量检索中使用的Bi-Encoder在架构上存在根本差异：Bi-Encoder将查询和文档分别独立编码，检索速度极快但精度有限；Cross-Encoder则将查询与候选文档拼接后联合输入模型，通过全量注意力机制捕捉二者之间的细粒度语义交互，输出更精确的相关性分数。实践中通常先用向量检索召回Top-50到Top-100的候选片段，再用重排模型精选出Top-5到Top-10放入上下文。这种"粗召回+精排序"的两阶段架构的核心价值在于：用少量精排计算换取整体检索质量的大幅提升，已成为工业界标准做法。这个"清洗—切块—检索—重排"的流程，直接决定了模型能否拿到高质量的参考信息。

提示与记忆：组织行动的基础

提示：一张清晰的工作单

提示（Prompt）技巧就像给模型递上一张工作单，上面写清了任务是什么、有哪些约束条件、期望的输出格式是怎样的。

如果需要使用少样本示例（Few-shot Examples），这些示例一定要贴近你的实际业务场景，泛泛的通用例子帮助有限。少样本学习的有效性源于LLM在预训练阶段习得的"上下文学习"（In-Context Learning，ICL）能力——模型能够从提示中提供的少量示例中识别任务模式，并将其泛化到新的输入上，而无需更新任何模型权重。关于ICL的机制，主流假说认为其本质上是一种隐式的梯度下降：模型在前向传播过程中通过注意力机制对示例进行"软权重更新"，这一能力在参数量超过约100亿后才会显著涌现，与大模型"能力涌现"（Emergent Abilities）现象密切相关。

在工程应用中，KATE（K-nearest Neighbor Augmented in-context Tuning Examples）等动态示例选择方法通过检索与当前输入语义最相近的示例，相比随机固定示例可带来5-15%的性能提升。与目标最相似的示例应放在紧邻任务描述的位置（利用近因效应），充分利用模型对序列末尾的注意力偏好。对于格式高度敏感的任务（如结构化数据提取、代码生成），少样本示例的价值往往超过详细的文字说明。同时，推理过程的引导也要精简——思维链提示（Chain-of-Thought, CoT）虽然能显著提升复杂推理任务的表现，但详细的推理链会占用大量上下文token。在CoT的演进路径上，Zero-shot CoT（仅凭"Let's think step by step"触发推理）揭示了大模型推理能力的可激活性；而Tree-of-Thoughts（ToT）则进一步将线性推理链扩展为树状搜索结构，允许模型在多个推理分支之间评估和回溯，在需要系统性探索解空间的规划类任务中表现尤为出色，但代价是更高的token消耗和延迟，需根据任务复杂度权衡使用。因为提示本身也占用上下文空间，如果提示写得又长又啰嗦，反而会把白板占满，得不偿失。

记忆：办公桌与档案柜

记忆系统可以类比为办公桌和档案柜的组合，分为三个层次：

• 短期记忆：像办公桌上正在处理的文件，存放当前任务相关的即时信息，直接存储在模型的上下文窗口中，随会话结束而消失；
• 长期记忆：像档案柜，保存用户的事实信息和偏好设置，可以跨会话复用，通常通过外部数据库实现持久化存储，可分为结构化存储（SQL数据库）和向量存储两类；
• 工作记忆：保存多步骤任务的中间状态，确保复杂流程不会"断片"，技术上通常通过Scratchpad（草稿本）机制实现，让模型将中间推理结果写入可读写的临时存储区域。

值得关注的是，记忆的"遗忘机制"同样重要——借鉴操作系统虚拟内存管理的思想，通过动态策略决定哪些记忆留在"主存"（上下文），哪些归档到"外存"（持久化存储）。在实际工程中，记忆写入通常需要设置明确的触发条件而非被动接收所有信息：例如仅在用户明确表达偏好、完成关键任务节点或对话出现实质性主题转变时触发写入操作。MemGPT等研究项目将操作系统的分页内存管理思想移植到LLM记忆系统，通过显式定义"主上下文"（对应内存）与"外部存储"（对应磁盘）之间的换入换出机制，赋予模型自主管理记忆的能力，代表了记忆系统架构的前沿探索方向。关键原则是：什么值得存必须有门槛。 不加筛选地把所有信息都存下来，只会让记忆系统变得臃肿低效，反而拖累后续的检索与利用。

工具：给模型行动的能力

工具（Tool）赋予了模型真正与外部世界交互的能力。但需要清醒认识到：给了工具，不等于模型就能用好工具。

模型使用工具是一个完整的闭环流程：先要发现工具（知道有哪些工具可用），再选择工具（判断当前任务该用哪个），然后填写参数（正确构造调用输入），当结果返回后，还要观察和反思——判断这次调用是否达到了预期，是否需要调整策略。

工具的注册与描述质量同样至关重要——工具描述写得越清晰、边界越明确，模型在"发现"和"选择"阶段的准确率就越高；模糊或重叠的工具描述往往是Agent调用失败的主要根源之一。这一整套发现、选择、执行、反思的循环，才是工具能力真正落地的关键。在工具描述的工程实践中，每个工具的说明应包含四个核心要素：功能的精确边界（能做什么，不能做什么）、参数的类型与约束（有效值范围、必填与选填）、典型的调用示例（覆盖正常路径与边界情况）、以及与相似工具的区分说明（避免模型在功能重叠的工具间产生选择困惑）。研究表明，即便是同等能力的模型，配备高质量工具描述的Agent在复杂任务中的成功率可比描述模糊的方案高出20-40%，工具描述的工程投入往往被严重低估。

四个核心动作，管好上下文窗口

如果要用最凝练的方式概括上下文工程的操作原则，可以记住这四个动作：

1. Write（写入）：把重要信息写到外部存储，而不是全部堆在上下文窗口里；
2. Select（选择）：只挑选当前任务真正需要的信息进入上下文；
3. Compress（压缩）：把冗长的历史对话压缩成简洁的摘要。压缩技术目前主要有三种路线——摘要压缩、选择性token删减（如微软亚洲研究院开发的LLMLingua，通过小型语言模型评估每个token的信息熵：困惑度低的token意味着它可被高置信度预测，即信息冗余度高，可安全删除；研究表明可在压缩80%内容的情况下保持模型性能基本稳定；后续版本LongLLMLingua进一步针对长上下文场景优化，能够识别并优先保留与查询高度相关的关键段落），以及底层推理架构层面的KV缓存（Key-Value Cache）复用——对于重复出现的系统提示或固定文档，预先计算并缓存其注意力键值对，避免每次推理时重复计算；前缀KV缓存（Prefix Caching）将这一优化延伸到跨请求复用，对系统提示相同的高并发场景可降低30-50%的首token延迟（TTFT）和计算成本，在降低计算成本的同时实质上扩展了可用上下文容量。从信息论视角理解压缩的本质：有效的上下文压缩并非简单的长度缩减，而是在有限token预算内最大化信息熵密度。这意味着需要保留高信息量的关键事实、决策节点和约束条件，而删除高度可预测的冗余表述、过渡性措辞和已隐含于上下文的背景信息。
4. Isolate（隔离）：把噪声和潜在风险信息隔离开来，避免污染核心上下文。这一点在防范提示注入（Prompt Injection）攻击时尤为重要——恶意内容混入上下文可能劫持Agent的行为。提示注入由安全研究员Riley Goodside于2022年首次系统性记录，此后迅速成为AI安全领域的核心议题，OWASP已将其列为LLM应用Top 10安全风险之首。间接提示注入（Indirect Prompt Injection）尤为危险，因为攻击向量来自模型处理的外部数据（网页、PDF、邮件、数据库记录）而非用户输入本身，传统的输入过滤手段难以防御，且攻击意图对终端用户完全不透明。目前的缓解策略包括：指令层次化（Instruction Hierarchy）训练——在微调阶段明确教导模型区分可信系统指令与不可信外部数据；最小权限原则——Agent仅获得完成任务所需的最小工具权限；以及人机协同审核（Human-in-the-Loop）——在不可逆操作执行前强制引入人工确认节点。

这四个动作贯穿于上下文工程的每一个环节，是管理"白板空间"的黄金法则。

结语：整洁的白板，才有聪明的模型

上下文工程的核心洞察在于：模型的能力上限，很大程度上取决于我们如何为它组织信息。它不是单纯的Prompt调优技巧，而是一套涵盖决策调度、查询增强、信息检索、提示设计、记忆管理和工具调用的完整系统工程。

对于构建AI Agent的开发者而言，与其抱怨模型"不够聪明"，不如先审视：你是否给了它一块整洁、聚焦、信息充分的白板？做好Write、Select、Compress、Isolate这四件事，往往比更换更大的模型更能带来实质性的效果提升。

核心要点

核心要点

核心要点

核心要点