产品级AI应用的核心：上下文工程

去年，提示工程（Prompt Engineering）的风很大。

各种Prompt范式层出不穷，但一圈实践下来，真正好用的，还是结构化提示词、零样本（Zero-shot）、少样本（Few-shot）、思维链（Chain-of-Thought）这几样。

提示工程有它的价值，但它的本质，是一问一答，用完即忘。

这种“无状态”的交互，没法处理需要长线记忆的多轮对话，也很难搞定需要持续跟进的复杂工作流。

当我们对大模型应用的效果和稳定性要求越来越高，单靠提示工程， 很难实现预期的效果。

为此，AI大神Andrej Karpathy提出了一个新理念：上下文工程（Context Engineering）。

他把大模型比作新时代的操作系统，那上下文窗口，就是它的内存（RAM）。

我的理解更直接一点：上下文工程，就是精心设计和管理模型推理时所处的整个信息环境。它的核心不再是像提示工程一样琢磨“怎么问”，而是要构建“提问时，模型应该知道什么”。

今天这篇文章，就从我的实践出发，聊聊上下文工程到底有什么，以及我们该如何设计它。

聊聊上下文工程

拿我们常用的Cursor举例。

当我们在聊天框里提个需求，Cursor为了精准生成代码，背后其实有一套完整的上下文工程在运作：

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

可以看到，提示工程只是上下文工程里的一环。

而上下文工程，代表的是一种架构层面的理念转变：从“写好单条指令”，到“编排一个有状态、有记忆的智能信息系统”

接下来，就来详细聊聊完整上下文工程中的一些细节问题。

提示工程

在Prompt里加几个例子（Few-shot），能让模型输出更稳定，这是咱们的共识。但这里面其实也有不少门道。

首先，例子不是越多越好。有人做过实验，随着示例数量增加，模型效果的提升会进入一个明显的“收益递减”区间。加例子要消耗token，但带来的性能改进却越来越小。

因此，在实际应用中，我们要找到一个“性价比”最高的平衡点。对于大多数任务来说，存在一个平衡输出质量和token消耗的实践：

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

除了数量，例子的多样性、是否覆盖边缘场景、甚至是例子的排序，都会影响最终效果。

所以，还有一种更高级的玩法是：准备一个“示例库”，根据用户的每次输入，动态地从库里挑出最相关的几个例子，塞进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"]
        }

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

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

这些都是在实践中被证明行之有效的模式，可以在咱们的项目中灵活运用。

结语

从提示工程到上下文工程，这不仅仅是一个技术名词的升级，更像是一种思维模式的跃迁。

在上下文工程中，有记忆，有工具，有结构化的知识，有多样的智能体协同。它为模型提供了一个稳定、可靠且信息丰富的工作环境。

希望今天的分享，能让你在构建自己的AI应用时，不止于打磨那一句精妙的Prompt，而是能退后一步，从系统和架构的视角，去思考如何为你的AI，构建一个真正强大的“上下文”。