AI Agent - Prompt OR Context 了解
Prompt OR Context
定义
一个提示(Prompt)远不止一个简单的问题,它是一个结构化的输入,可包含多个组成部分。这些组件共同构成了与模型沟通的完整指令:
- 指令(Instructions):对模型的核心任务指令,明确告知模型需要执行什么操作。
- 主要内容/输入数据(Primary Content/Input Data):模型需要处理的文本或数据,是分析、转换或生成任务的对象。
- 示例(Examples/Shots):演示期望的输入-输出行为,为模型提供“上下文学习”(In-Context Learning)的基础。
- 线索/输出指示器(Cues/Output Indicators):启动模型输出的引导性词语,或对输出格式(如JSON、Markdown)的明确要求。
- 支持性内容(Supporting Content/Context):为模型提供的额外背景信息,帮助其更好地理解任务情境。正是这一组件,构成了 Context Engineering 发展的概念萌芽。
随着大语言模型的出现,针对 Prompt 的设计与优化逐渐发展为一个垂直领域,并衍生出一个专门的岗位——Prompt Engineer。 这一领域的重点在于研究如何为不同的大语言模型设计最佳的 Prompt 格式,使模型的回答效果达到最优。
Prompt设计六要素
Prompt = 角色(Role) + 上下文(Context) + SOP(Workflow) + 边界(Boundary) + 回答约束(Constraints) + 示例(Examples) 
优质提示词原则
- 清晰的指令
- 提供上下文和例子
- 善用符号与语法
- 让模型一步一步的思考
- 激励模型反思和给出思路
- 给容错空间
- 让模型给出信息来源
### 角色:
你是一名资深资深的Java高级开发工程师,精通Java 8的集合操作和流式处理,擅长处理空指针和边界情况的防护。
### 背景说明:
我目前有一批店铺对象`List<ShopModel>`,每个`ShopModel`对象包含字段`shopId`(店铺ID)和`shopName`(店铺名称)。我希望将这批店铺对象转换为`Map<String, String>`,其中键(key)为`shopId`,值(value)为`shopName`。在处理过程中,我希望确保代码健壮且无空指针异常
### 任务:
请帮我编写一个Java方法,满足以下要求:
1. 方法输入为`List<ShopModel>`,输出为`Map<String, String>`。
2. 如果输入的`List<ShopModel>`为空或为`null`,返回空的`Map`对象。
3. 如果`List<ShopModel>`中包含`null`对象,跳过该对象,不做处理。
4. 使用Java 8流式处理,确保代码简洁、可读性强,并处理好所有空指针异常情况。
### 输出格式:
直接提供Java代码,包含注释说明。请同时提供一个简单的示例或单元测试代码,展示如何使用这个方法。这条消息已经在编辑器中准备就绪。你想如何调整这篇文档?请随时告诉我。
不同模型在Prompt细节上可能存在差异,因此需要结合模型的特点调整设计
除了 Prompt 的结构设计外,还可以通过特定的思维模式让大语言模型遵循更具体的指令,进而优化任务的执行过程。
- 思维链(Chain of Thought, CoT): CoT 是一种引导模型按照逻辑链条逐步完成任务的思维模式。通过 CoT,模型能够将复杂的任务拆解为多个子任务,并对每个子任务的可执行性进行验证。这种模式确保了模型在解决问题时能够逻辑清晰,并对任务有更强的理解和执行能力。
- 反应式行动(ReAct): ReAct 是另一种思维模式,适用于让模型面对复杂问题时将其分解为具体的行动步骤。模型可以基于问题拆分出每个行动(Action),观察每个行动执行的结果,并根据结果确定下一步要执行的任务。通过这种模式,模型能够自主完成任务拆分,并有效执行外部任务,增强其对复杂问题的处理能力。
Prompt Engineering 的核心技术
- 零样本提示(Zero-Shot Prompting):在不提供任何示例的情况下直接向模型下达任务,完全依赖其在预训练阶段获得的知识和推理能力。
- 少样本提示(Few-Shot Prompting):在提示中提供少量(通常为 1 到 5 个)高质量的示例,以引导模型的行为。对于复杂任务,这种“上下文学习”方法被证明极为有效。
- 思维链提示(Chain-of-Thought Prompting, CoT):引导模型将复杂问题分解为一系列中间推理步骤,显著增强了其在逻辑、数学和推理任务上的表现。
- 高级推理技术: 在 CoT 的基础上,研究人员还开发了更为复杂的变体,如思维树(Tree-of-Thought)、苏格拉底式提示(Maieutic Prompting)和由简到繁提示(Least-to-Most Prompting),以探索更多样化的解决方案路径。
Prompt Engineering 对于构建稳健、可用于生产环境的系统而言,存在固有的局限性
- 脆弱性&不可复现性:提示中微小的措辞变化可能导致输出结果的巨大差异,使得这一过程更像是一种依赖反复试错的“艺术”,而非可复现的“科学”。
- 扩展性差:手动、迭代地优化提示的过程,在面对大量用户、多样化用例和不断出现的边缘情况时,难以有效扩展。
- 用户负担:这种方法将精心构建一套详尽指令的负担完全压在了用户身上,对于需要自主运行、或处理高并发请求的系统而言是不切实际的。
- 无状态性:Prompt Engineering 本质上是为单轮、“一次性”的交互而设计的,难以处理需要记忆和状态管理的长对话或多步骤任务。
Context Engineering
Context Engineering是一门设计、构建并优化动态自动化系统的学科,旨在为大型语言模型在正确的时间、以正确的格式,提供正确的信息和工具,从而可靠、可扩展的完成复杂任务。 其并非要取代 Prompt Engineering,而是一个更高阶、更侧重于系统设计的必要学科。prompt 告诉模型如何思考,而 Context 则赋予模型完成工作所需的知识和工具。
“Context”涵盖了LLM在做出响应前所能看到的索引信息生态系统:
- 系统级指令和角色设定
- 对话历史(短期记忆)
- 持久化的用户偏好和事实(长期记忆)
- 动态检索的外部数据(例如来自RAG)。
- 可用的工具(API、函数)及其定义
- 期望的输出格式(JSON等)
Prompt Engineering 是 Context Engineering 的一个子集。
- Context Engineering 决定用什么内容填充 Context Window,
- Prompt Engineering 则负责优化窗口内的具体指令。
Context Engineering 的基石:RAG
检索增强生成(RAG)作为实现 Context Engineering 的主要架构模式。
组织在选择向量数据库时必须考虑以下主要因素:
- 模型:选择完全托管的云服务(如 Pinecone),还是可自托管的开源方案(如 Milvus、Weaviate)。
- 扩展性:是否能处理数十亿级别的向量数据和高查询负载(Milvus)。
- 功能集: 是否支持混合搜索(关键词+向量)、高级 meta 过滤以及多模态数据处理(Weaviate)。
- 易用性与灵活性:是倾向于API简单、设置最少的方案(Pinecone),还是需要多种索引算法和深度配置选项的方案(Milvus)。

核心问题 - Lost in the Middle
当前LLM存在一个根本性认知局限,这一局限使得简单的上下文堆砌变得无效,并催生了后续的优化技术。
- 定义:LLM 在处理长上下文时表现出一种独特的 U 型 性能曲线。当关键信息位于上下文窗口的开头(首因效应)或结尾(近因效应)时,模型能够高效地利用这些信息。然而,当关键信息被 “hidden”在长篇上下文的中间位置时,模型的性能会显著下降。
- 实验: 在多文档问答任务时,即使检索器召回了更多相关的文档,模型的性能提升也很快达到饱和。这意味着简单地增加上下文长度(即添加更多文档)不仅无益,甚至因为关键信息被淹没而损害性能。
- “知道但说不出来”: 并非模型“找不到”信息。通过探测模型的内部表征发现,模型通常能够准确地编码关键信息的位置,但在生成最终答案时却未能有效利用这些信息。这表明在模型内部,信息检索和信息利用(或沟通)之间存在脱节。

上下文丰富性与窗口局限性之间的考量
一方面,提供丰富、全面的上下文是获得高质量响应的关键。另一方面,LLM 的上下文窗口是有限的,并且由于 Lost in the Middle、contextual distraction 等问题,过长的上下文反而会导致性能下降。
因此产生了一个核心的优化问题:如何在固定的Token预算内,最大化“信号”(真正相关的信息),同时最小化“噪声”(不相关或分散注意力的信息),并充分考虑到模型存在的认知偏差?
Context Engineering 领域所有的高级技术——无论是语义分块、重排序,还是后续将讨论的压缩、摘要和智能体隔离——都是为了有效管理这一权衡而设计的。 因此,Context Engineering 不仅是关于提供上下文,更是关于如何策划和塑造上下文,使其对一个认知能力有限的处理单元(LLM)最为有效。
优化上下文窗口:压缩与摘要
缩短检索到的文档列表/精简单个文档的内容,只讲关键信息传递给LLM。这样能有效降低API调用成本、减少延迟,并缓解Lost in the Middle的问题。
压缩方法
- 过滤式压缩:决定是保留还是丢弃整个检索到的文档
- LLMChainFilter:利用一个 LLM 对每个文档的相关性做出简单的“是/否”判断。
- EmbeddingsFilter:更经济快速的方法,根据文档嵌入与查询嵌入的余弦相似度来过滤文档。
- 内容提取式压缩:直接修改文档内容
- LLMChainExtractor:遍历每个文档,并使用 LLM 从中提取仅与查询相关的句子或陈述。
- 用TOP N代替压缩:像 LLMListwiseRerank 这样的技术,使用 LLM 对检索到的文档进行重排序,并只返回排名最高的 N 个,从而起到高质量过滤器的作用。
对于非常长的文档或冗长的对话历史,可以利用 LLM 生成摘要。这些摘要随后被注入上下文,既保留了关键信息,又大幅减少了 Token 数量。这是在长时程运行的智能体中管理上下文的关键技术。
智能体系统的上下文管理
Prompt Engineering 本质上是一个手动的、Human-in-the-Loop 的试错过程。而 Context Engineering,尤其是在其智能体形式中,则是关于构建一个自动化的 System-in-the-Loop,这个系统在LLM看到提示之前就为其准备好上下文。
一个人类提示工程师需要手动收集信息、组织语言并进行测试。而一个 Context Engineering 化的系统则将此过程自动化:RAG 流程本身就是一个自动收集信息的系统; 路由器是一个自动决定收集哪些信息的系统;记忆模块是一个自动持久化和检索历史信息的系统。
正是这种自动化,使得 AI 系统能够变得“智能体化”(Agentic)——即能够在没有人类为每一步微观管理上下文的情况下,进行自主的、多步骤的推理。 因此,Context Engineering 的目标是构建一个可靠、可重复的上下文组装机器。这台机器取代了提示工程师的临时性、手工劳动,从而使创建真正自主和可扩展的 AI 智能体成为可能。 焦点从单个提示的“技艺”转向了生成该提示的“系统工程”。
LangChain提出的四个关键策略
- Write-持久化上下文:
- Scratchpads:供智能体在执行复杂任务时使用的临时、会话内记忆,用于记录中间步骤。
- Memory:长期、持久化的存储,记录关键事实、用户偏好或对话摘要,可在不同会话间调用。
- Select-检索上下文:根据当前的子任务,使用 RAG 技术动态地从记忆、工具库或知识库中选择相关上下文。这甚至包括对工具描述本身应用 RAG,以避免向智能体提供过多无关的工具选项。
- Compress-优化上下文:利用摘要或修剪技术来管理智能体在长时程任务中不断增长的上下文,防止上下文窗口溢出和“ Lost in the Middle ”问题。
- Isolate-分割上下文:
- 多智能体系统:将一个复杂问题分解,并将子任务分配给专门的子智能体,每个子智能体都拥有自己独立的、更聚焦的上下文窗口。
- 沙盒环境:在一个隔离的环境中执行工具调用,只将必要的执行结果返回给 LLM,从而将包含大量 Token 的复杂对象隔离在主上下文窗口之外。
多智能体架构中的 Context 数据流与工作流编排
当一个智能体不再是简单地“输入-输出”,而是需要调用工具、访问数据库、与用户进行多轮交互时,其内部的数据是如何流动和管理的?如何进行技术选型?
工作流(Workflow) vs. 智能体(Agent)
工作流(Workflow)
指的是 LLM 和工具通过预定义的代码路径进行编排的系统。在这种模式下,数据流动的路径是固定的、由开发者明确设计的,类似于上世纪流行的“专家系统”。 例如,“第一步:分析用户邮件;第二步:根据分析结果在日历中查找空闲时段;第三步:起草会议邀请邮件”。 这种模式确定性高,易于调试和控制,非常适合有明确业务流程的场景(如风控需求高、数据敏感、安全等级要求)。
智能体(Agent)
指的是 LLM 动态地指导自己的流程和工具使用,自主控制如何完成任务的系统。在这种模式下,数据流动的路径不是预先固定的,而是由LLM在每一步根据当前情况和目标动态决定的。 这种模式灵活性高,能处理开放式问题,但可控性和可预测性较低。
复杂的智能体通常是这两种模式的混合体,在宏观层面遵循一个预定义的工作流,但在某些节点内部,又赋予 LLM 一定的自主决策权。 管理这一切的核心,我们称之为编排层(Orchestration Layer)。
多 Agent 编排的核心架构:预定义数据流的实现
链式工作流(Prompt Chaining)(GPT-3.5 时期的工作原理)
- 数据流:输入 -> 模块 A -> 输出 A -> 模块 B -> 输出 B ->... -> 最终输出
- 工作原理:每个模块(LLM 调用)只负责一个定义明确的子任务。

路由工作流(Routing)(o3 的早期工作原理)
- 数据流:输入 -> 路由器选择 => -> 输出
- 工作原理:一个充当“路由器”的 LLM 调用,其唯一任务就是决策。它会分析输入数据,然后输出一个指令,告诉编排系统接下来应该调用哪个具体的业务模块。
- 实现方式:LangGraph 使用 Conditional Edges 来实现这种逻辑,即一个节点的输出决定了图的下一跳走向何方。

编排器-工作者模式(Orchestrator-Workers)
- 对于极其复杂的任务,可以采用多智能体(Multi-agent)架构,也称为 Orchestrator-Workers 模式。一个中心 Orchestrator 智能体负责分解任务,并将子任务分配给多个专职的 Workers 智能体。
- 数据流:这是一个分层、协作的流动模式。 总任务 -> Orchestrator => -> 结果汇总 -> 最终输出
- 工作原理:每个工作者智能体都有自己独立的上下文和专用工具,专注于解决特定领域的问题。

决策与数据选择机制
智能体如何决定“需要什么数据”以及“下一步做什么”,主要依赖于内部的规划和推理能力。
ReAct 框架
ReAct(Reasoning and Acting)是一个基础且强大的框架,它通过模拟人类的“Reasoning-Acting”模式,使LLM能够动态地决定数据需求。 其核心是一个循环
- 思考(Thought):LLM 首先进行内部推理。它分析当前任务和已有信息,判断是否缺少完成任务所需的知识,并制定下一步的行动计划。
- 行动(Action): LLM 决定调用一个具体的工具,并生成调用该工具所需的参数。
- 观察(Observation):系统执行该行动(调用外部 API),并将返回的结果作为“观察”数据提供给LLM。
- 再次思考: LLM 接收到新的观察数据,再次进入思考环节,判断任务是否完成,或是否需要进一步的行动。
在这个循环中,数据流是根据 LLM 的“思考”结果动态生成的。当LLM判断需要外部数据时,它会主动触发一个“行动”来获取数据,然后将获取到的“观察”数据整合进自己的上下文中,用于下一步的决策。
Planning 和任务分解
对于更复杂的任务,智能体通常会先进行规划(Planning)。一个高阶的规划模块会将用户的宏大目标分解成一系列更小、更具体、可执行的子任务。
数据流向: 规划模块的输出是一份“计划清单”(Planning List),这份清单定义了后续一系列模块的调用顺序和数据依赖关系。Claude Code、Cursor v1.2、Gemini/GPT DeepResearch均属于这个架构。

Reflection 机制
先进的智能体架构还包含反思(Reflection)机制 。智能体在执行完一个动作或完成一个子任务后,会评估其结果的质量和正确性。如果发现问题,它可以自我修正,重新规划路径。是目前各大主流deep research 平台使用的核心技术方案。
数据流向: 这是一个反馈循环。模块的输出不仅流向下一个任务模块,还会流向一个“评估器”模块。评估器的输出(如“成功”、“失败”、“信息不足”)会反过来影响规划模块,从而调整后续的数据流向。

Context Engineering 的未来
- Graph RAG 的兴起:标准的基于向量的 RAG 在处理高度互联的数据时存在局限。而利用知识图谱的图 RAG 不仅能检索离散的信息块,还能检索它们之间的显式关系。这使得模型能够进行更复杂的多跳推理,并提供上下文更准确的回答 。
- 智能体自主性的增强:像 Self-RAG 和 Agentic RAG 这样更自主的系统将成为趋势,LLM 将承担更多管理自身上下文的责任。这将模糊 Context Engineering 系统与 LLM 本身之间的界限。
- 超越固定上下文窗口:针对 Lost in the Middle 问题的研究正在进行中,包括探索新的模型架构(如改进的位置编码)和训练技术。这些研究的突破可能会从根本上改变当今 Context Engineering 师所面临的约束。
- 终极目标:Context Engineering 本质上是一座桥梁,它是一套复杂的补偿机制,用以弥补 LLM “don't read minds—they read tokens”的现实。人工智能研究的长期目标是创造出具有更强大内部世界模型的 AI,从而减少对此类庞大外部上下文支架的依赖。 Context Engineering 的演进,将是衡量我们朝此目标迈进的关键指标。
