微信扫码
添加专属顾问
我要投稿
AI应用进阶的关键:从提示工程到上下文工程,揭秘如何构建有记忆的智能系统。 核心内容: 1. 提示工程的局限性与上下文工程的核心理念 2. 真实案例解析(以Cursor为例)展示上下文工程四大组件 3. 不同任务类型中示例数量的黄金平衡点实践指南
去年,提示工程(Prompt Engineering)的风很大。
各种Prompt范式层出不穷,但一圈实践下来,真正好用的,还是结构化提示词、零样本(Zero-shot)、少样本(Few-shot)、思维链(Chain-of-Thought)这几样。
提示工程有它的价值,但它的本质,是一问一答,用完即忘。
这种“无状态”的交互,没法处理需要长线记忆的多轮对话,也很难搞定需要持续跟进的复杂工作流。
当我们对大模型应用的效果和稳定性要求越来越高,单靠提示工程, 很难实现预期的效果。
为此,AI大神Andrej Karpathy提出了一个新理念:上下文工程(Context Engineering)。
他把大模型比作新时代的操作系统,那上下文窗口,就是它的内存(RAM)。
我的理解更直接一点:上下文工程,就是精心设计和管理模型推理时所处的整个信息环境。它的核心不再是像提示工程一样琢磨“怎么问”,而是要构建“提问时,模型应该知道什么”。
今天这篇文章,就从我的实践出发,聊聊上下文工程到底有什么,以及我们该如何设计它。
拿我们常用的Cursor举例。
当我们在聊天框里提个需求,Cursor为了精准生成代码,背后其实有一套完整的上下文工程在运作:
@
主动引用的上下文、会话中的其它信息等。可以看到,提示工程只是上下文工程里的一环。
而上下文工程,代表的是一种架构层面的理念转变:从“写好单条指令”,到“编排一个有状态、有记忆的智能信息系统”
接下来,就来详细聊聊完整上下文工程中的一些细节问题。
在Prompt里加几个例子(Few-shot),能让模型输出更稳定,这是咱们的共识。但这里面其实也有不少门道。
首先,例子不是越多越好。有人做过实验,随着示例数量增加,模型效果的提升会进入一个明显的“收益递减”区间。加例子要消耗token,但带来的性能改进却越来越小。
因此,在实际应用中,我们要找到一个“性价比”最高的平衡点。对于大多数任务来说,存在一个平衡输出质量和token消耗的实践:
除了数量,例子的多样性、是否覆盖边缘场景、甚至是例子的排序,都会影响最终效果。
所以,还有一种更高级的玩法是:准备一个“示例库”,根据用户的每次输入,动态地从库里挑出最相关的几个例子,塞进Prompt里。
除了添加示例样本之外,Prompt模版格式也是一个高性价比的,能提升模型输出质量的技巧。
比如我们熟知的ReAct Prompting,它模仿人解决问题的思路:思考 -> 行动 -> 观察 -> 调整。这个循环在需要多步推理的复杂任务上,表现非常出色。
受ReAct启发,还有一种递归提示,在要求高稳定性的场景很常用。
def recursive_prompt(question, model, iterations=2):
"""Apply recursive prompting to improve responses."""
# Initial response
response = model.generate(f"Question: {question}\nAnswer:")
for i in range(iterations):
# Self-reflection prompt
reflection_prompt = f"""
Question: {question}
Your previous answer:
{response}
Please reflect on your answer:
1. What information might be missing?
2. Are there any assumptions that should be questioned?
3. How could the explanation be clearer or more accurate?
Now, provide an improved answer:
"""
# Generate improved response
response = model.generate(reflection_prompt)
return response
可以看到,它的精髓在于,通过不断地自我审视和批判,让模型自己完善答案,显著提高输出质量。
总之,提示工程的技巧很多,关键是因地制宜,选择最合适的。
想让大模型从一个只会预测下一个词的“组件”,进化成一个真正的“智能体”,记忆是很关键的能力。
一个智能体在执行一个长期目标时,必须能够记住它的总体规划、当前所处的步骤以及它通过工具(比如搜索引擎、代码执行器
)观察到的世界状态。没有记忆,任何形式的长期规划都无从谈起。
但模型的上下文窗口终归是有限的,对话一长就满了。所以,必须要有一套记忆管理策略。
通常情况下,我们会采取以下几种策略来优化有限的上下文窗口的使用。
顾名思义,这种方式很简单,就是仅保存最近的对话轮次,缺点也很明显,会忘记之前提到的关键信息。
这种方式稍微负载点,核心是每次都将旧的对话记录压缩成一个历史摘要。摘要可以保留关键信息,同时减少token的消耗。
为了更好的控制,我们还可以结构化提取和存储历史对话中重要的事实。这比单纯对历史对话进行摘要化压缩,能更精确的控制需要保留的信息。
面对更复杂的应用场景,比如一个产品级AI应用,我们通常需要一个完整的状态管理模块,用来:
以上方法还是受限于单次交互。终极方案是把对话信息存入外部数据库(比如向量数据库)。每次新对话开始时,再把最相关的信息检索出来,放进当前上下文。
这本质上就是RAG的一种应用,非常考验检索的精准度。
以上就是为大模型添加记忆的一些常用方式,我们在不同的场景选择合适的,具有性价比的方式即可。
单个智能体处理复杂任务,好比让一个人同时扮演多个角色,很容易精力分散、顾此失彼。认知负担太重,导致结果跑偏。
更好的方式是任务分解。
让一个“总指挥”Agent理解最终目标,把任务拆解,然后分发给不同工种的“执行”Agent。每个执行Agent只用关心自己那一小块上下文,自然能做得更专注、更出色。
关于多智能体的应用,我在之前的文章:《搭建一个AI研究团队:我对Claude多智能体研究系统的思考与实践》做过详细分析,例如,在最后的实践环节,我将一个基于公域数据的深度研究系统拆解成一个多智能架构:Lead Agent:、平台研究员、信息提取与分析师、事实核查员、报告撰写师。
这里要注意,每个Agent有自己的小上下文,但必须有一个全局上下文来同步整体进度,确保大家最终能合力完成任务。这依然离不开前面讲的记忆模块。
理论说了不少,我们用一个“AI深度研究助理”的案例,把上下文工程的各个环节串起来看看。
import json
class ResearchAssistant:
"""一个用于综合来自多个信息源的系统。"""
def __init__(self, llm_service, retrieval_service):
self.llm = llm_service
self.retrieval = retrieval_service
self.research_state = {
"topic": "",
"query_results": [],
"extracted_concepts": {},
"concept_relationships": [],
"synthesis": "",
"knowledge_gaps": []
}
def set_research_topic(self, topic):
"""设置研究主题并生成初始查询。"""
self.research_state["topic"] = topic
# 使用一个提示程序(prompt program)生成结构化的查询
query_prompt = f"""任务:为研究主题 “{topic}” 生成有效的搜索查询
流程:
1. 将主题分解为其核心组成部分
2. 为每个组成部分生成具体的搜索查询
3. 包含针对该主题不同视角的查询
4. 添加用于获取背景/基础信息的查询
格式:
核心组成部分:
- [组成部分1]
- [组成部分2]
推荐查询:
1. [具体查询1]
2. [具体查询2]
3. [具体查询3]
视角查询:
1. [视角1的查询]
2. [视角2的查询]
背景查询:
1. [背景1的查询]
2. [背景2的查询]
"""
query_suggestions = self.llm.generate(query_prompt)
# 在实际应用中,你需要解析这个结构化的输出
# 在本示例中,我们使用占位符查询
return ["query1", "query2", "query3"]
def retrieve_information(self, queries):
"""使用生成的查询来检索信息。"""
# 在真实的实现中,这里会调用一个实际的检索服务
# 在本示例中,我们使用占位符结果
for query in queries:
# 模拟检索结果
results = [
{"title": f"关于 {query} 的结果1", "content": "示例内容1", "source": "来源A"},
{"title": f"关于 {query} 的结果2", "content": "示例内容2", "source": "来源B"}
]
self.research_state["query_results"].extend(results)
return self.research_state["query_results"]
def extract_concepts(self):
"""从检索到的信息中提取关键概念。"""
# 从检索结果构建上下文
context = self._build_retrieval_context()
# 使用基于模式(schema)的提示来提取概念
concept_prompt = f"""任务:从以下研究信息中提取关键概念。
研究主题:{self.research_state["topic"]}
信息来源:
{context}
流程:
1. 识别在多个来源中都提到的关键概念
2. 为每个概念提取相关的细节和定义
3. 注意不同来源在描述概念时的差异或分歧
4. 为每个概念分配一个相关性分数(1-10)
格式:
概念:[概念名称1]
定义:[综合定义]
关键属性:
- [属性1]
- [属性2]
来源差异:
- [来源A]:[该来源的描述方式]
- [来源B]:[该来源的描述方式]
相关性分数:[1-10]
概念:[概念名称2]
...
"""
extraction_results = self.llm.generate(concept_prompt)
# 在实际应用中,你需要解析这个结构化的输出
# 在本示例中,我们使用占位符概念
self.research_state["extracted_concepts"] = {
"概念1": {
"definition": "概念1的定义",
"properties": ["属性1", "属性2"],
"source_variations": {
"来源A": "来自A的描述",
"来源B": "来自B的描述"
},
"relevance": 8
},
"概念2": {
"definition": "概念2的定义",
"properties": ["属性1", "属性2"],
"source_variations": {
"来源A": "来自A的描述",
"来源B": "来自B的描述"
},
"relevance": 7
}
}
return self.research_state["extracted_concepts"]
def _build_retrieval_context(self):
"""从检索结果构建上下文。"""
ifnot self.research_state["query_results"]:
return"尚未检索到任何信息。"
# 包含一部分检索到的信息样本
# 在实际应用中,由于token限制,你可能需要进行摘要或筛选
context = ""
for i, result in enumerate(self.research_state["query_results"][:5]):
context += f"来源 {i+1}: {result['title']}\n"
context += f"内容: {result['content'][:200]}...\n"
context += f"出处: {result['source']}\n\n"
return context
def analyze_relationships(self):
"""分析已提取概念之间的关系。"""
ifnot self.research_state["extracted_concepts"]:
return"尚未提取任何概念。"
# 获取概念名称的列表
concepts = list(self.research_state["extracted_concepts"].keys())
# 使用一个比较矩阵模板进行关系分析
relationship_prompt = f"""任务:分析研究主题中关键概念之间的关系。
研究主题:{self.research_state["topic"]}
待分析的概念:
{", ".join(concepts)}
流程:
1. 创建所有概念间的关系矩阵
2. 为每一对概念确定其关系类型
3. 标注每种关系的强度(1-5)
4. 识别任何冲突或互补的关系
格式:
关系矩阵:
| 概念 | {" | ".join(concepts)} |
|---------|{"-|" * len(concepts)} """
# 为每个概念添加行
for concept in concepts:
relationship_prompt += f"| {concept} |"
for other in concepts:
if concept == other:
relationship_prompt += " X |"
else:
relationship_prompt += " ? |"
relationship_prompt += "\n"
relationship_prompt += """
详细关系:
[概念A] → [概念B]
类型:[因果/层级/相关/等]
强度:[1-5]
描述:[简要描述它们如何关联]
[继续分析其他相关组合...]
"""
relationship_results = self.llm.generate(relationship_prompt)
# 在实际应用中,你需要解析这个结构化的输出
# 在本示例中,我们使用占位符关系
self.research_state["concept_relationships"] = [
{
"source": "概念1",
"target": "概念2",
"type": "因果关系",
"strength": 4,
"description": "概念1直接影响概念2"
}
]
return self.research_state["concept_relationships"]
def synthesize_research(self):
"""综合生成一份全面的研究摘要。"""
# 确保我们已经提取了概念和关系
ifnot self.research_state["extracted_concepts"]:
self.extract_concepts()
ifnot self.research_state["concept_relationships"]:
self.analyze_relationships()
# 从概念和关系中构建上下文
concepts_str = json.dumps(self.research_state["extracted_concepts"], indent=2, ensure_ascii=False)
relationships_str = json.dumps(self.research_state["concept_relationships"], indent=2, ensure_ascii=False)
synthesis_prompt = f"""任务:就该主题综合生成一份全面的研究摘要。
研究主题:{self.research_state["topic"]}
关键概念:
{concepts_str}
概念关系:
{relationships_str}
流程:
1. 创建一个连贯的叙述,将关键概念整合起来
2. 突出不同来源达成共识的领域
3. 指出重要的分歧或矛盾之处
4. 识别知识空白或需要进一步研究的领域
5. 总结最重要的发现
格式:
# 研究综述:[主题]
## 核心发现
[最重要见解的摘要]
## 概念整合
[连接概念及其关系的叙述]
## 共识领域
[各来源达成一致的观点]
## 分歧领域
[各来源存在分歧或矛盾的观点]
## 知识空白
[需要更多研究的领域]
## 结论
[对当前知识状况的总体评估]
"""
synthesis = self.llm.generate(synthesis_prompt)
self.research_state["synthesis"] = synthesis
# 提取知识空白(在实际应用中,你会从综述中解析这些内容)
self.research_state["knowledge_gaps"] = [
"空白1:需要对X进行更多研究",
"空白2:Y和Z之间的关系尚不清楚"
]
return synthesis
def complete_research_cycle(self, topic):
"""运行一个从主题到综述的完整研究周期。"""
# 设置研究主题并生成查询
queries = self.set_research_topic(topic)
# 检索信息
self.retrieve_information(queries)
# 提取并分析概念
self.extract_concepts()
self.analyze_relationships()
# 综合研究发现
synthesis = self.synthesize_research()
return {
"topic": topic,
"synthesis": synthesis,
"concepts": self.research_state["extracted_concepts"],
"relationships": self.research_state["concept_relationships"],
"knowledge_gaps": self.research_state["knowledge_gaps"]
}
在这个深度研究助理的实例中,我们应用了多种上下文工程的模式:
..._prompt
都是一个为特定子任务设计的、可复用的提示模板。这些都是在实践中被证明行之有效的模式,可以在咱们的项目中灵活运用。
从提示工程到上下文工程,这不仅仅是一个技术名词的升级,更像是一种思维模式的跃迁。
在上下文工程中,有记忆,有工具,有结构化的知识,有多样的智能体协同。它为模型提供了一个稳定、可靠且信息丰富的工作环境。
希望今天的分享,能让你在构建自己的AI应用时,不止于打磨那一句精妙的Prompt,而是能退后一步,从系统和架构的视角,去思考如何为你的AI,构建一个真正强大的“上下文”。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2025-08-12
看大神在Claude Code里的全局配置文件来定义他的个人品味,可参考
2025-08-12
GPT-5 不是技术新范式,是 OpenAI 加速产品化的战略拐点
2025-08-12
GPT-5 vs Claude Opus 4.1:编程能力测评
2025-08-12
刚刚,Claude 推出记忆功能,比ChatGPT 好用
2025-08-12
大模型背后的“新搜索”生意,水有多深
2025-08-12
在Claude Code使用子agent的最优解
2025-08-12
好未来基于大模型 RAG+CoT 技术辅助故障定位
2025-08-12
好未来 × Milvus落地实践
2025-05-29
2025-05-23
2025-06-01
2025-06-07
2025-06-21
2025-05-20
2025-06-12
2025-06-19
2025-06-13
2025-05-28
2025-08-11
2025-08-11
2025-08-11
2025-08-11
2025-08-11
2025-08-11
2025-08-10
2025-08-09