本文基于下面的论文解读为锚点,加入自己的解读和补充可落地的github。
在使用ClaudeCode解读论文的时候,Context engineering一瞥:
一、从混乱到有序:为什么我们需要上下文工程?
想象一下,如果把LLM比作一位才华横溢的学者,传统的“提示工程”就像是递给他一张写着问题的便条。而“上下文工程”则是为他打造一个完整的智能工作环境——包括一个动态更新的图书馆、一个高效的助理团队、一套连接现实世界的工具,以及一部记录着所有过往交流的备忘录。
随着AI应用的复杂化,我们面临着一系列严峻的挑战,传统的提示工程修修补补已无力应对。上下文工程的出现,正是为了系统性地解决这些问题。
图1:上下文工程的核心框架,展示了从基础组件到系统实现的完整体系。
LLM固有限制的系统性分析
| 扩展性问题 | • 长文档分析能力受限 • 代码库理解困难 | • 分层注意力机制 • 智能分块与重组策略 | |
| 成本问题 | • 商业应用延迟增加 • 重复上下文处理浪费 | • 动态压缩技术 • 智能信息过滤 | |
| 可靠性问题 | • 忽略或曲解源材料 • 微小输入变化导致输出剧变 • 语法正确但语义浅薄 | • 多层质量控制 • 鲁棒性工程设计 |
上下文工程的数学定义:从“艺术”到“科学”
从数学角度看,上下文工程的核心是从将上下文视为单一字符串(C = prompt)转变为一个动态组装的、结构化的信息集合。这个转变是理解其科学性的第一步。
C = A(c_instr, c_know, c_tools, c_mem, c_state, c_query)
这里的 A 代表一个编排函数(Orchestration Function),它就像一位指挥家,将各种不同来源的信息(c)智能地组合成一段连贯、高效的最终上下文,然后才送入大语言模型。
上下文的六大核心组件
为了更直观地理解这个动态组装过程,我们可以将其想象成一个信息装配流水线。下表详细解释了每个组件的含义和作用,这本身就是一幅结构图:
c) | |||
|---|---|---|---|
c_instr | 指令 (Instructions) | “你是一位专业的医疗助手。请使用通俗易懂的语言回答,并始终引用来源。” | |
c_know | 知识 (Knowledge) | ||
c_tools | 工具 (Tools) | {"name": "get_weather", "description": "获取指定城市的天气", ...} | |
c_mem | 记忆 (Memory) | “用户上次询问了关于Python的话题,并且偏好简洁的代码示例。” | |
c_state | 状态 (State) | “用户当前正在查看购物车页面,购物车中有3件商品。” | |
c_query | 查询 (Query) | “帮我把它翻译成英文” |
这种结构化方法使得上下文不再是一个混沌的信息团,而是一个经过精心设计、每个部分都承载特定功能的高效信息体。基于此,上下文工程的优化目标便浮出水面。
其最终目标是找到一套最优的上下文生成函数 F*,使得模型在所有可能的任务 T 上的期望奖励最大化:
F* = argmax_F E[Reward(P_θ(Y|C_F(τ)), Y*_τ)]
这个公式看起来复杂,但其核心思想很直观:寻找一套最佳的信息准备和组织方法,让AI在资源(如上下文窗口长度 L_max)有限的情况下,面对真实世界的各种复杂任务时,能做出最优质的响应。
让我们用一个类比来逐步拆解它。
🔍 逐步解读:上下文工程的数学本质
想象你是一位大厨,要为各种不同的客人(任务)准备最完美的菜肴(输出)。上下文工程就是要找到那个最佳的“食谱和工具箱组合”。
| F | |||
| argmax_F | |||
| E[...] | |||
| τ ~ T | |||
| C_F(τ) | |||
| P_θ(Y|C_F(τ)) | |||
| Reward(...) | |||
| |C| ≤ L_max |
这个数学框架将上下文工程从经验性的“艺术”转变为可量化、可优化的“科学”,并引入了更深层次的数学原理。
🔄 三层数学框架的深度剖析
1. 动态上下文编排 (Dynamic Context Orchestration)这就像总导演,决定信息如何组织呈现。它通过 Format 函数将原始信息(知识、工具、记忆等)处理成标准格式,再用 Concat 函数将它们拼接成最终的上下文。
2. 信息论最优检索 (Information-Theoretic Optimal Retrieval)当AI需要从海量知识库中检索信息时,它追求的是互信息量最大化。Retrieve* = argmax_Retrieve I(Y*; c_know | c_query)简单来说,就是找到那些“知道了它,就最可能知道答案”的知识。
3. 贝叶斯上下文推理 (Bayesian Contextual Inference)这是AI进行“智能猜测”的核心。面对不确定的情况,AI需要推断出最合适的上下文。
🕵️ 侦探破案类比想象AI是一位侦探,c_query 是案件,它需要找到最可信的证据组合 C 来破案。贝叶斯公式告诉我们:P(C | c_query) ∝ P(c_query | C) · P(C | History)
后验概率 P(C | c_query):这个证据组合对破案的帮助有多大?(目标) 似然函数 P(c_query | C):如果证据是真的,案件发生的可能性有多大?(匹配度) 先验概率 P(C | History):根据过往经验,这个证据组合本身有多可靠?(可靠性)
这种方法让AI从“关键词匹配机器”进化为“智能推理助手”。例如,一个智能客服在收到“我的订单怎么还没到?”的查询时:
传统方法:匹配“订单”,给出通用的物流查询链接。 贝叶斯方法:
评估匹配度:问题和“实时物流数据”这个上下文高度匹配。 评估可靠性:结合用户历史(先验概率),发现该用户是VIP客户且首次投诉。 做出推断:推断出最佳策略不是简单回复,而是“提供详细物流状态,并附上安抚性的补偿方案”。
通过这种方式,上下文工程为构建更智能、更可靠的AI系统提供了坚实的理论基础。
📊 提示工程与上下文工程范式对比表
| 模型 | C = prompt | C = A(c₁, c₂, ..., cₙ) |
| 目标 | argmax_prompt P_θ(Y | prompt) | F* = argmax_F E[Reward(P_θ(Y | C_F(τ)), Y*_τ)] |
| 复杂度 | F = {A, Retrieve, Select, ...} | |
| 信息处理 | |C| ≤ L_max下最大化任务相关信息 | |
| 状态管理 | c_mem和c_state组件 | |
| 可扩展性 | ||
| 错误分析 |
注:此表格清晰展示了上下文工程相比传统提示工程在系统性、科学性和可扩展性方面的根本性进步。上下文工程将信息处理从"艺术"提升为"科学",提供了构建复杂AI系统的正式框架。
二、上下文工程的核心:三大基础组件
如同建造一座大厦需要钢筋、水泥和玻璃,构建复杂的AI系统也依赖于三大基础组件。
组件一:上下文检索与生成 (Context Retrieval and Generation)
这是信息流的源头,决定了模型“能看到什么”。
1. 推理框架的进化:从链式思维到图状思维
链式思维 (CoT): 将复杂问题分解为中间推理步骤,在MultiArith任务上准确率从17.7%提升到78.7%。 树状思维 (ToT): 将推理组织为层次化结构,在"24点游戏"中成功率从4%提升到74%。 图状思维 (GoT): 以图结构建模推理,相比ToT质量提升62%,成本降低31%。
2. 外部知识检索:为AI打开通往现实世界的大门
检索增强生成 (RAG): 这是对抗模型幻觉、连接实时数据的核心技术。它在模型回答前,先从外部知识库中检索相关信息。 高级RAG:如今的RAG已演变为Self-RAG(模型自主决定何时检索并评估质量)、GraphRAG(利用社区检测的层次化索引)和LightRAG(整合图结构和向量表示)等更智能的形态。
组件二:上下文处理 (Context Processing)
获取原始信息后,必须对其进行"精加工",以适应模型的处理能力。
1. 应对超长上下文的挑战
处理超长上下文面临着O(n²)复杂度的挑战。将Mistral-7B的输入从4K增加到128K token需要122倍的计算增长。为了解决这个问题,研究者们开发了多种创新技术:
2. 自我精炼:让AI拥有"反思"能力
📊 长链推理方法详细对比表
| O1-Pruner | |||||
| InftyThink | |||||
| Long-CoT Survey | |||||
| PREMISE | |||||
| Prune-on-Logic |
注:O1-Pruner使用强化学习风格的微调来缩短推理链同时保持准确性。InftyThink采用迭代推理与中间摘要来减少计算复杂度。Long-CoT Survey探索通过效率改进和增强知识框架提升推理能力的长思维链特征。PREMISE通过梯度启发优化使用轨迹级诊断优化提示,实现87.5%的token减少。Prune-on-Logic通过选择性移除低效用推理步骤对逻辑图进行结构感知剪枝。
组件三:上下文管理 (Context Management)
上下文窗口是宝贵且有限的资源,如何高效管理是关键。
1. 解决“迷失在中间”的问题研究发现,LLM对位于上下文开头和结尾的信息记忆最深,而中间的信息则容易“失忆”。
操作系统级的内存管理 (MemGPT/Letta): 这一革命性方法将LLM的上下文窗口比作计算机的RAM,将外部数据库比作硬盘。它像一个操作系统,智能地在两者之间进行“页面调度”,赋予LLM近乎无限的记忆能力。 上下文压缩: ICAE(In-context Autoencoder)能将长上下文压缩成紧凑的“记忆槽”,实现了高达4倍的压缩率,同时还能增强模型的处理能力。
三、从组件到系统:四大前沿架构实现
基础组件如同乐高积木,它们可以组合搭建成功能强大的真实世界系统。
实现一:检索增强生成 (RAG) 的全面演进
RAG已从简单的信息注入器,进化为复杂的智能系统。
图2:RAG系统的演进,从模块化到智能体化,再到图增强。
模块化RAG: 现代RAG系统采用可插拔的模块设计,开发者可以像搭积木一样组合查询重写、智能路由、结果融合等模块。 智能体RAG (Agentic RAG): 将自主AI智能体嵌入RAG流程。智能体主动进行推理、规划、使用工具,甚至在检索失败时进行自我反思和调整。 图增强RAG (Graph-Enhanced RAG): 利用知识图谱的结构化优势,检索精确的实体和关系,进行复杂的多跳推理,并极大减少幻觉。
📊 RAG Systems GitHub项目热度排行榜
| RAGFlow | 63.7k | ||||
| Langchain-Chatchat | 36k | ||||
| LLM-App | 31.5k | ||||
| Microsoft GraphRAG | 27.9k | ||||
| STORM | 27.2k | ||||
| Haystack | 22.1k | ||||
| RAG Techniques | 20.6k | ||||
| LightRAG | 20.4k | ||||
| LLMWare | 14.4k | ||||
| txtai | 11.5k | ||||
| FlagEmbedding | 10.5k | ||||
| Verba | 7.3k | ||||
| R2R | 7.3k | ||||
| AutoRAG | 4.3k | ||||
| Cognita | 4.2k |
🔥 RAG系统发展趋势分析
多模态融合:MemVid等项目展示了将视频、音频等多模态数据融入RAG的创新 实时处理:LLM-App等强调与Sharepoint、Google Drive等实时数据源集成 图增强:LightRAG和GraphRAG引领知识图谱与向量检索的深度结合 中文生态:Langchain-Chatchat等项目在中文RAG应用中占据重要地位 企业级部署:RAGFlow、Haystack等注重生产环境的稳定性和可扩展性
📊 知识图谱集成方法详细对比表
| ODA | |||
| RAG-KG | |||
| KARPA | |||
| Faithful Reasoning |
注:ODA采用观察驱动智能体框架,通过递归观察和动作反思实现性能提升。RAG-KG通过历史问题知识图谱构建实现查询解析和子图检索。KARPA提供免训练的知识图谱适应方法,通过预规划关系路径达到最先进性能。Faithful Reasoning建立规划-检索-推理框架,实现LLM与知识图谱的协同工作。
📊 结构化数据集成方法详细对比表
| K-LAMP | ||||
| Pan et al. | ||||
| StructLM | ||||
| Shao et al. |
注:K-LAMP使用KAPING框架实现基于检索的知识图谱增强,专注于零样本问答任务。Pan等人的方法将知识图谱与LLM进行预训练和推理时的深度集成,支持多领域推理。StructLM通过110万样本的大规模指令调优数据集,在18个数据集上进行8种结构化知识生成任务的训练。Shao等人专注于线性化方法,通过模式链接和语法预测优化文本到SQL的转换性能。
实现二:记忆系统 (Memory Systems):赋予AI持久的认知能力
为了让AI能进行连贯的长时程对话和持续学习,必须为其构建记忆系统。商业AI助手在长时间交互中准确率会下降30%,凸显了记忆系统的重要性。
图3:受人类认知科学启发的AI记忆系统层次结构。
Memory Systems GitHub项目热度排行榜
| Mem0 | 39.4k | ||||
| Letta | 18.3k | ||||
| AGiXT | 3.1k | ||||
| MemOS | 2.4k | ||||
| Memobase | 2.1k | ||||
| MIRIX | 1.4k | ||||
| MemoryOS | 679 | ||||
| Memori | 506 |
📊 记忆系统实现模式详细对比表
| 核心记忆系统 | ||||||
| 智能体系统 | ||||||
| 高级记忆架构 | ||||||
| 新兴系统 | ||||||
注:✅ = 已采用,❌ = 未采用。此表展示了不同记忆系统在文本形式(完整、最新、检索、外部)和参数形式(微调、编辑)实现方式上的差异。
发展趋势洞察
标准化趋势: Mem0的高热度反映了对统一记忆层标准的需求。商业化成功: Letta(原MemGPT) 展示了从研究到产品的成功路径。系统级创新: MemOS代表了操作系统级记忆管理的新方向。生态整合: 支持MCP等标准协议成为重要竞争力。
实现三:工具集成推理 (TIR):赋予AI与现实世界交互的“双手”
为了让AI能查询实时天气、预定机票或执行代码,它需要使用工具。
图4:工具集成推理框架,使LLM能够调用外部API并与现实世界交互。
严峻的现实差距: GAIA基准测试显示,人类在通用助手任务上的准确率为92%,而GPT-4只有15%,凸显了当前工具使用能力的巨大鸿沟。 ReAct框架: 这是工具使用的核心思想,即“思考-行动-观察”的循环。 训练策略的突破: ReTool等框架通过强化学习,仅用400个训练步骤就在AIME2024上达到了67%的准确率。APIGen等数据生成系统能创建覆盖数千个API的高质量训练数据。
📊 Tool-Integrated Reasoning GitHub项目热度排行榜
| LangChain | 115k | ||||
| LlamaIndex | 44.1k | ||||
| LangGraph | 8.5k | ||||
| ToolLLaMA | 5.2k | ||||
| ReAct | 3.8k | ||||
| OpenInterpreter | 55.2k | ||||
| AgentGPT | 32.2k | ||||
| AutoGPT | 170k | ||||
| Semantic Kernel | 22.8k | ||||
| Instructor | 8.1k | ||||
| Marvin | 5.4k | ||||
| GPT Engineer | 52.7k | ||||
| Phidata | 15.1k | ||||
| LangFlow | 36.8k | ||||
| Composio | 10.5k |
📊 工具增强语言模型架构对比表
| ReAct | ||||||||
| Toolformer | ||||||||
| ToolkenGPT | ||||||||
| ToolLLM | ||||||||
| ToRA | ||||||||
| PAL | ||||||||
| HuggingGPT | ||||||||
| GPT4Tools | ||||||||
| CRITIC | ||||||||
| Chain of Code | ||||||||
| TRICE | ||||||||
| TP-LLaMA | ||||||||
| AlignToolLLaMA | ||||||||
| ReTool | ||||||||
| Tool-Star |
实现四:多智能体系统 (MAS):协作智能的最高形态
如果说单个带工具的AI是一个“超级个体”,那么多智能体系统就是一个“超级团队”。
图5:多智能体系统,其中多个专业化的AI智能体通过标准化协议进行协作。
标准化通信协议: 为了让不同来源的智能体能够顺畅协作,社区正在制定统一的通信标准,如MCP(模型上下文协议)(被誉为“AI的USB-C”)、A2A(点对点通信)和ANP(基于去中心化标识符的开放互联网协议)。 智能编排: AutoGen和CrewAI等框架允许我们定义不同角色的智能体(如"产品经理"、"程序员"、"测试工程师"),并编排它们的协作流程。
📊 Multi-Agent Systems GitHub项目热度排行榜
| MetaGPT | 58.3k | ||||
| CrewAI | 37.7k | ||||
| OpenAI Swarm | 20.4k | ||||
| TaskWeaver | 15.2k | ||||
| AutoGen | 14.8k | ||||
| ChatDev | 12.3k | ||||
| Camel-AI | 8.7k | ||||
| LangGraph | 8.5k | ||||
| XAgent | 8.2k | ||||
| Multi-Agent-GPT | 5.8k | ||||
| BabyAGI | 21.2k | ||||
| Agents | 3.1k | ||||
| AG2 | 3.5k | ||||
| AgentVerse | 3.9k | ||||
| Composio | 10.5k |
🚀 多智能体系统发展趋势洞察
生态系统成熟度:MetaGPT和CrewAI的高星数反映了产业级多智能体需求爆发 标准化进程:OpenAI Swarm代表了大厂对轻量级协调标准的探索 图状态管理:LangGraph展示了基于图的智能体状态管理新方向 开放治理:AG2从Microsoft分离展示了开源多智能体项目的治理创新
四、评估的挑战与未来展望
我们如何衡量这些复杂系统的性能?传统的NLP指标(如BLEU)已然失效。我们需要全新的、多维度的评估体系。
新一代评估基准
| WebArena | ||
| GAIA | ||
| LongMemEval | ||
| BFCL |
📊 WebArena基准测试排行榜详细对比
| IBM CUGA | 61.7 | |||
| OpenAI Operator | 58.1 | |||
| Jace.AI | 57.1 | |||
| ScribeAgent + GPT-4o | 53.0 | |||
| AgentSymbiotic | 52.1 | |||
| Learn-by-Interact | 48.0 | |||
| AgentOccam-Judge | 45.7 | |||
| WebPilot | 37.2 | |||
| GUI-API Hybrid Agent | 35.8 | |||
| Agent Workflow Memory | 35.5 | |||
| SteP | 33.5 | |||
| TTI | 26.1 | |||
| BrowserGym + GPT-4 | 23.5 |
注:WebArena是评估网页智能体在真实网站上执行复杂任务能力的基准测试。即使是最佳系统的成功率也只有61.7%,显示了网页自动化任务的巨大挑战。开源方案中AgentSymbiotic表现最佳,达到52.1%的成功率。
🔍 WebArena评估挑战分析
关键发现:
人机差距巨大:人类在类似任务上的成功率接近95%,而最好的AI系统仅达61.7% 开源vs闭源:开源系统最高52.1%,与闭源系统仍有显著差距 复杂度影响:涉及多步骤操作和上下文理解的任务成功率显著下降 可靠性问题:系统在处理动态网页内容和异常情况时表现不稳定
未来方向:机遇与挑战并存
统一理论的探寻:我们需要一个能解释所有上下文工程技术的底层理论,如信息论和计算复杂性理论,将“术”提升为“道”。 高级推理与多模态融合:AI需要从简单的信息检索,进化到能进行因果、反事实和时序推理,并无缝融合文本、图像、音频等多种信息。 安全、可靠与对齐:随着智能体越来越自主,如何确保其行为安全、可控,并始终与人类价值观对齐,是未来十年最核心的挑战。
结论:一个新学科的黎明
上下文工程不仅仅是提示工程的延伸,它是一个全新的、独立的工程学科。它为我们提供了一套系统性的方法论,用以构建更强大、更可靠、更智能的AI系统。它将我们从对LLM的“感性”调教,带入了“理性”设计的时代。
技术资源与深度学习
核心论文: 《A Survey of Context Engineering for Large Language Models》 代码库: GitHub - Awesome Context Engineering
本文内容基于上述论文解读而来,借助claudeCode和Gemini 2.5 Pro联合解读,使用了大约50+ prompts,历时4个小时。输出过程中,prompt产生的结果不符合高质量输出的比例大约15%,需要多次修改尝试。
Claude Code的Agent调度能力和拆解任务能力,非常强。
Gemini 2.5 Pro 理解能力非常强,“有点科研大脑”的味道。
