微信扫码
添加专属顾问
我要投稿
上下文工程正重塑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-09-06
红杉资本:AI领域重塑工作和技术的五大投资趋势
2025-09-06
Claude 中国禁用后,阿里 1T 参数模型 Qwen3-Max 连夜发布,效果太强了
2025-09-06
Claude封杀?OpenAI官方Codex震撼登场!效率直接拉满!
2025-09-06
从万科“活下去”到AI转型,现在是所有企业面对“活下去”的抉择
2025-09-06
突破 1 万亿参数! 阿里巴巴发布 Qwen3 Max 预览版:迄今为止千问家族最大模型
2025-09-06
“浏览器,重新开机”:从 Dia 被收购到 Comet、Claude 与 Fellou,AI 正在重写入口之战
2025-09-06
当我们谈论“AI原生”时我们在谈论什么?
2025-09-05
当AI开始“懂你”:一文读懂上下文工程如何让AI助手更聪明
2025-08-21
2025-06-21
2025-08-21
2025-08-19
2025-06-12
2025-06-19
2025-06-13
2025-07-29
2025-06-15
2025-08-19
2025-09-06
2025-09-03
2025-09-03
2025-09-03
2025-09-03
2025-09-02
2025-08-28
2025-08-28