微信扫码
添加专属顾问
 
                        我要投稿
上下文工程正重塑AI系统架构,从传统提示工程升级为结构化信息流管理,带来系统性突破。 核心内容: 1. 上下文工程的核心框架与六大组件解析 2. 解决LLM三大限制(扩展性/成本/可靠性)的创新方案 3. 从数学定义到工程实践的完整方法论体系
 
                                本文基于下面的论文解读为锚点,加入自己的解读和补充可落地的github。
在使用ClaudeCode解读论文的时候,Context engineering一瞥:
想象一下,如果把LLM比作一位才华横溢的学者,传统的“提示工程”就像是递给他一张写着问题的便条。而“上下文工程”则是为他打造一个完整的智能工作环境——包括一个动态更新的图书馆、一个高效的助理团队、一套连接现实世界的工具,以及一部记录着所有过往交流的备忘录。
随着AI应用的复杂化,我们面临着一系列严峻的挑战,传统的提示工程修修补补已无力应对。上下文工程的出现,正是为了系统性地解决这些问题。
图1:上下文工程的核心框架,展示了从基础组件到系统实现的完整体系。
| 扩展性问题 | • 长文档分析能力受限 • 代码库理解困难 | • 分层注意力机制 • 智能分块与重组策略 | |
| 成本问题 | • 商业应用延迟增加 • 重复上下文处理浪费 | • 动态压缩技术 • 智能信息过滤 | |
| 可靠性问题 | • 忽略或曲解源材料 • 微小输入变化导致输出剧变 • 语法正确但语义浅薄 | • 多层质量控制 • 鲁棒性工程设计 | 
从数学角度看,上下文工程的核心是从将上下文视为单一字符串(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)
这种方法让AI从“关键词匹配机器”进化为“智能推理助手”。例如,一个智能客服在收到“我的订单怎么还没到?”的查询时:
通过这种方式,上下文工程为构建更智能、更可靠的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系统也依赖于三大基础组件。
这是信息流的源头,决定了模型“能看到什么”。
1. 推理框架的进化:从链式思维到图状思维
2. 外部知识检索:为AI打开通往现实世界的大门
获取原始信息后,必须对其进行"精加工",以适应模型的处理能力。
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通过选择性移除低效用推理步骤对逻辑图进行结构感知剪枝。
上下文窗口是宝贵且有限的资源,如何高效管理是关键。
1. 解决“迷失在中间”的问题研究发现,LLM对位于上下文开头和结尾的信息记忆最深,而中间的信息则容易“失忆”。
基础组件如同乐高积木,它们可以组合搭建成功能强大的真实世界系统。
RAG已从简单的信息注入器,进化为复杂的智能系统。
图2:RAG系统的演进,从模块化到智能体化,再到图增强。
| 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 | 
| 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的转换性能。
为了让AI能进行连贯的长时程对话和持续学习,必须为其构建记忆系统。商业AI助手在长时间交互中准确率会下降30%,凸显了记忆系统的重要性。
图3:受人类认知科学启发的AI记忆系统层次结构。
| 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 代表了操作系统级记忆管理的新方向。为了让AI能查询实时天气、预定机票或执行代码,它需要使用工具。
图4:工具集成推理框架,使LLM能够调用外部API并与现实世界交互。
| 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 | 
如果说单个带工具的AI是一个“超级个体”,那么多智能体系统就是一个“超级团队”。
图5:多智能体系统,其中多个专业化的AI智能体通过标准化协议进行协作。
| 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 | 
我们如何衡量这些复杂系统的性能?传统的NLP指标(如BLEU)已然失效。我们需要全新的、多维度的评估体系。
| WebArena | ||
| GAIA | ||
| LongMemEval | ||
| BFCL | 
| 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%的成功率。
关键发现:
上下文工程不仅仅是提示工程的延伸,它是一个全新的、独立的工程学科。它为我们提供了一套系统性的方法论,用以构建更强大、更可靠、更智能的AI系统。它将我们从对LLM的“感性”调教,带入了“理性”设计的时代。
本文内容基于上述论文解读而来,借助claudeCode和Gemini 2.5 Pro联合解读,使用了大约50+ prompts,历时4个小时。输出过程中,prompt产生的结果不符合高质量输出的比例大约15%,需要多次修改尝试。
Claude Code的Agent调度能力和拆解任务能力,非常强。
Gemini 2.5 Pro 理解能力非常强,“有点科研大脑”的味道。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-10-30
Cursor 2.0的一些有趣的新特性
2025-10-30
Anthropic 发布最新研究:LLM 展现初步自省迹象
2025-10-30
让Agent系统更聪明之前,先让它能被信任
2025-10-30
Rag不行?谷歌DeepMind同款,文档阅读新助手:ReadAgent
2025-10-29
4大阶段,10个步骤,助你高效构建企业级智能体(Agent)
2025-10-29
DocReward:让智能体“写得更专业”的文档奖励模型
2025-10-29
沃尔沃RAG实战:企业级知识库,早就该放弃小分块策略
2025-10-29
大模型的Funcation Calling是什么?
 
            2025-08-21
2025-08-21
2025-08-19
2025-09-16
2025-10-02
2025-09-08
2025-09-17
2025-08-19
2025-09-29
2025-08-20
2025-10-29
2025-10-29
2025-10-28
2025-10-28
2025-10-27
2025-10-26
2025-10-25
2025-10-23