上下文工程：产品级AI应用的核心技术深度解析_AI热点日报

从提示工程到上下文工程的跃迁是AI应用进阶的关键。上下文工程通过记忆、工具调用、RAG、提示工程和多智能体协同等组件，构建有状态、有记忆的智能系统，突破无状态交互的局限，实现复杂任务的长线处理与稳定输出。

从提示工程到上下文工程：构建有记忆的智能系统

AI应用进阶的关键在于理解如何从“无状态”的提示工程跃迁到“有状态”的上下文工程。本文将从理念、核心组件到实践案例，为你揭开构建真正智能、能记住上下文的系统的完整路径。

1. 提示工程的局限与上下文工程的崛起

去年，提示工程（Prompt Engineering）风头无两。各类Prompt范式层出不穷，但真正在实践中站稳脚跟的，还是结构化提示词、零样本（Zero-shot）、少样本（Few-shot）、思维链（Chain-of-Thought）等几种。提示工程自有价值，但其本质是一问一答、用完即忘的“无状态”交互。这种模式无法处理需要长线记忆的多轮对话，也难以应对需要持续跟进的复杂工作流。

当我们对AI应用的效果和稳定性要求越来越高，单靠提示工程很难达到预期。为此，AI大神Andrej Karpathy提出了一个新理念：上下文工程（Context Engineering）。他将大模型比作新时代的操作系统，上下文窗口就是它的内存（RAM）。更直白地说：上下文工程就是精心设计和管理模型推理时所处的整个信息环境。它的核心不再是像提示工程那样琢磨“怎么问”，而是要构建“提问时，模型应该知道什么”。

提示工程是上下文工程中的一个环节，但上下文工程代表架构层面的理念跃迁：从“写好单条指令”到“编排一个有状态、有记忆的智能信息系统”。

2. 上下文工程的四大核心组件——以Cursor为例

拿我们常用的Cursor来说，当你在聊天框里提出需求时，背后运作的是一套完整的上下文工程体系：

记忆：翻阅之前的聊天记录，明确你的真实意图。
工具调用：调用命令行工具，查看你的项目文件结构。
RAG：提取和你需求最相关的代码（如当前文件、你通过@主动引用的上下文、会话中的其他信息等）。
提示工程：把收集到的所有信息和你提出的需求，打包成一个高质量的Prompt，再发给大模型。
Multi-Agent：可能不止一个Agent在干活：一个负责理解与执行，另一个在旁边监工、审查结果，决定是否返工或优化。

可见，提示工程只是上下文工程里的一环。上下文工程代表的是一种架构级别的思路转变。

3. 上下文工程各环节的实践指南

3.1 提示工程——少样本示例的黄金平衡点

在Prompt里加入几个例子（Few-shot）能让模型输出更稳定，这是共识。但例子并非越多越好——随着示例数量增加，模型效果提升会进入“收益递减”区间。加例子消耗token，但收益却越来越小。因此，实际应用中要找到“性价比”最高的平衡点。以下是针对不同任务的实践建议：

分类任务：每类给1-3个例子就够。
生成任务：2-5个例子效果最好。
结构化提取：2-4个例子，尽量覆盖所有要提取的字段。
推理任务：2-3个带思考步骤的例子。
翻译任务：3-5个不同复杂度的例子。

除了数量，例子的多样性、是否覆盖边缘场景、甚至例子的排序都会影响最终效果。更高级的玩法是：准备一个“示例库”，根据用户的每次输入动态挑选最相关的几个例子塞进Prompt。

另外，Prompt模板格式也是一项高性价比的技巧。例如ReAct Prompting模仿人类解决问题的思路：思考 → 行动 → 观察 → 调整。这个循环在多步推理的复杂任务上表现出色。还有一种递归提示，在高稳定性场景中很常用：

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

它的精髓在于通过不断的自我审视和批判，让模型自己完善答案，显著提高输出质量。

小提示：提示工程的技巧很多，关键是因地制宜，选择最适合当前任务的组合，而不是盲目堆砌例子或模板。

3.2 对话记忆——让模型拥有“长期规划”的能力

想让大模型从“预测下一个词”进化成真正的“智能体”，记忆是关键能力。一个智能体在执行长期目标时，必须记住总体规划、当前步骤以及通过工具（如搜索引擎、代码执行器）观察到的世界状态。没有记忆，任何形式的长期规划都无从谈起。

但模型的上下文窗口有限，对话一长就满了。因此必须有一套记忆管理策略。以下是五种常用方式：

3.2.1 滑动窗口

仅保存最近的对话轮次，简单但会遗忘之前的关键信息。

3.2.2 压缩之前的对话

每次将旧对话记录压缩成一个历史摘要，保留关键信息的同时减少token消耗。

3.2.3 结构化提取之前的对话

比单纯摘要更精确，提取并存储历史对话中的重要事实，便于控制。

3.2.4 复杂应用状态管理

面对更复杂的应用场景（如产品级AI），需要一个完整的状态管理模块，用来：

记住对话中间出现的变量。
实时更新和维护这些变量。
跟踪多步骤任务的进度。
记住每一步的结果，供下一步使用。

3.2.5 持久化存储

以上方法仍受限于单次交互。终极方案是把对话信息存入外部数据库（如向量数据库），每次新对话开始时检索最相关信息，放入当前上下文。这本质上就是RAG的一种应用，非常考验检索精准度。

小提示：根据场景选择合适的记忆策略。简单聊天用滑动窗口即可；需要长期研究的应用建议使用持久化存储。

4. 多智能体协同——分解任务，专注上下文

单个智能体处理复杂任务，好比一人同时扮演多个角色，容易精力分散、顾此失彼。更好的方式是任务分解：让一个“总指挥”Agent理解最终目标，拆解任务，分发给不同工种的“执行”Agent。每个执行Agent只关心自己那一小块上下文，自然更专注、更出色。

在之前的文章《搭建一个AI研究团队：我对Claude多智能体研究系统的思考与实践》中，曾将一个基于公域数据的深度研究系统拆解成多智能体架构：Lead Agent、平台研究员、信息提取与分析师、事实核查员、报告撰写师。注意，每个Agent有自己的“小上下文”，但必须有一个“全局上下文”来同步整体进度，确保最终合力完成任务——这依然离不开前面讲的记忆模块。

5. 实战案例：AI深度研究助理

下面的Python代码展示了一个完整的“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):
        """从检索结果构建上下文。"""
        if not 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']}nn"
        
        return context
    
    def analyze_relationships(self):
        """分析已提取概念之间的关系。"""
        if not 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):
        """综合生成一份全面的研究摘要。"""
        # 确保我们已经提取了概念和关系
        if not self.research_state["extracted_concepts"]:
            self.extract_concepts()
        
        if not 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"]
        }

在这个深度研究助理中，我们应用了多种上下文工程模式：

状态管理：用research_state字典跟踪整个研究流程的状态。
渐进式上下文：一步步生成查询、检索信息、提取概念，上下文逐渐丰富和聚焦。
结构化模式：无论是生成查询还是提取概念，都使用结构化格式要求，确保输出稳定可用。
模板程序：每个..._prompt都是为特定子任务设计的可复用提示模板。
多步处理：将复杂研究任务拆分成了查询、检索、提取、分析、综合等多个阶段。

小提示：这些模式已经在实践中被证明行之有效，你可以在自己的项目中灵活运用，比如将状态管理、渐进式上下文、结构化提示组合起来构建不同的AI应用。

常见问题（FAQ）

Q：上下文工程和提示工程到底有什么区别？
A：提示工程聚焦于“怎么说”——设计单条指令的措辞。上下文工程则关注“模型在回答时应该知道什么”——管理整个信息环境，包括记忆、工具调用、RAG、多Agent协同等。提示工程是上下文工程的一个子环节。
Q：在少样本学习中，例子数量太少或太多会怎样？
A：例子太少（如0-1个）可能无法让模型理解任务模式，输出不稳定；例子太多（如超过10个）会浪费token且收益递减，甚至可能引入噪声。建议根据任务类型选择上面提到的黄金范围。
Q：对话记忆中的“压缩摘要”与“结构化提取”有什么区别？
A：压缩摘要是对历史对话的概括性描述，会丢失很多具体细节。结构化提取则保留重要事实（如变量值、用户偏好等），以键值对或结构化数据存储，更精确，但实现更复杂。
Q：多智能体系统中，如何避免Agent之间的上下文冲突？
A：需要设计一个全局上下文（共享状态）来同步整体进度。每个Agent的“小上下文”只包含自身任务所需的信息，而全局上下文记录任务分解、各Agent完成状态、关键结论等。可以采用类似“黑板模式”或事件总线的方式。

结语

从提示工程到上下文工程，这不仅是技术名词的升级，更是一种思维模式的跃迁。上下文工程中，有记忆、有工具、有结构化的知识、有多样的智能体协同。它为模型提供了一个稳定、可靠且信息丰富的工作环境。希望今天的分享能让你在构建自己的AI应用时，不止于打磨那一句精妙的Prompt，而是能从系统和架构的视角，去思考如何为你的AI构建一个真正强大的“上下文”。