prompt engineer，context engineer

Prompt Engineering提示工程和 Context Engineering上下文工程是 LLM 应用开发中两个紧密相关但层次不同的学科Prompt Engineering关注如何表达——如何设计输入指令以获得高质量输出。它是上下文工程的基础层。Context Engineering关注模型需要访问哪些信息——如何像操作系统管理内存一样科学地管理和编排 LLM 上下文窗口中的所有信息。两者的演进路径为Prompt Engineering → RAG → 智能体与工具调用从单轮指令设计逐步发展到多轮、多源、多智能体的上下文编排。Prompt Engineering1. Prompt 定义在大规模语言模型领域Prompt 是一种结构化的输入序列用于引导预训练语言模型生成预期的输出。它通常包括明确的任务要求、背景信息、格式规定以及示例以充分利用模型的能力在特定任务中生成高质量的响应。2. Prompt 的运行过程2.1 接收输入用户或系统向语言模型提供一个 Prompt这个 Prompt 包含任务指令、背景信息、示例以及格式说明。2.2 文本处理与编码模型首先对输入的 Prompt 进行预处理包括分词Tokenization和编码。预处理过程将文本转换为一系列的词汇 ID这些 ID 会传递到 Embedding 层进行进一步处理。2.3 模型计算编码后的文本输入到基于 Transformer 架构的神经网络中。自注意力机制层模型能够考虑输入序列中每个词汇与其他词汇的关系计算注意力权重从而捕捉远距离依赖关系。前馈神经网络层对自注意力层的输出进行非线性变换以生成新的表示。多层堆叠多个 Transformer 层堆叠在一起使模型逐步构建对输入 Prompt 的深层理解。位置编码补充位置信息使模型理解 token 的顺序。2.4 生成输出模型根据计算结果从生成的概率分布中采样下一个词汇。每个生成的词汇会迭代地输入回模型以生成后续词汇。这个过程持续进行直到满足输出条件。这一过程称为解码可以使用贪心搜索、束搜索、Top-k 采样、Top-p采样等方法以生成最优的文本输出。2.5 格式调整与后处理生成的输出文本可能需要进一步的格式调整和后处理以确保符合 Prompt 要求的输出格式和风格。例如如果 Prompt 要求生成不超过 200 字的摘要可以在后处理步骤中对生成文本进行截取同时确保摘要完整和连贯。3. Prompt 设计原则3.1 明确的目标和任务具体而清晰地阐明你的预期结果和要求明确 Prompt 的整体目标和具体希望进行的任务。通过使用清晰、简洁和准确的语言有助于缩小模型的输出范围减少误解和生成不相关内容的风险从而提高生成内容的质量和相关性。3.2 上下文和背景信息提供充分的上下文和背景信息包括具体的任务目标、预期输出、必要的细节、限制条件和目标读者或用户群体角色和身份明确任务请求者的角色有助于定制答案的专业性和语调。任务的具体目标明确需要完成的任务或回答的问题包含具体的细节和预期输出。相关历史和现状提供与任务相关的背景历史例如之前的研究、项目进度或市场状况涉及当前的环境或条件。特定要求和条件明确任务的具体要求和条件说明任何必须满足的约束条件。读者或受众阐明回答的目标受众调整回答的复杂性和语言风格以适应特定读者。3.3 System Prompt 与 User Prompt 的职责划分在具备 System Prompt 能力的模型中建议将不同性质的信息分层放置层级定位应包含的内容System Prompt持久性宪法角色定义、行为准则、输出格式规范、安全限制、持久性约束User Prompt随需变化的任务单当前具体任务、待处理数据、本轮特定要求最佳实践使用 XML 标签如instructions、context、format、examples结构化 System Prompt提高模型对指令各部分的注意力精度。User Prompt 中可包含input、data等标签标注动态内容。3.4 角色扮演提示Role Prompting角色扮演是引导模型行为最有效的手段之一。通过为模型分配一个明确的角色如你是一位资深 Python 代码审查专家可以锚定专业领域让模型调用特定领域的知识和术语约束行为边界明确模型应该做什么和不应该做什么设定语调和风格从学术严谨到通俗易懂取决于角色设定示例 你是一位拥有 15 年经验的风控算法工程师。你的回答应当 - 使用金融风控领域的专业术语 - 在给出方案时附上关键指标的预期影响 - 如果涉及不确定性明确指出假设前提3.5 详细的衡量标准或考评维度明确提供与目标和任务直接相关的衡量标准或考评维度。衡量标准或考评维度应全面覆盖所有必要的评估方面不遗漏任何关键内容。每个衡量标准或考评维度应有对应的衡量指标以支持其评估过程。衡量标准或考评维度的定义应清晰明确便于理解和执行。3.6 明确的输入输出格式指定清晰的输入输出格式是确保模型输出可用性的关键。推荐做法使用 JSON / Markdown / XML 结构化输出格式用示例展示期望的输入-输出配对对关键字段提供类型说明和约束范围指定空值/异常值的处理方式4. 核心提示技术Prompting Techniques4.1 Zero-shot / One-shot / Few-shotZero-shot零样本不提供任何示例直接给出任务指令。适用于模型已有充分预训练知识的简单任务。One-shot单样本提供单个输入输出配对示例帮助模型理解任务要求和期望的输出格式。适用场景模型已有一定基础知识只需要一个示例来了解具体格式和期望输出。Few-shot少样本提供多个通常是 2-5 个输入输出配对示例进一步明确任务细节和复杂性。适用场景任务较复杂或者模型对任务不够熟悉需要通过多个示例来学习任务特征。Few-shot 示例选择策略多样性覆盖不同的输入类型、边界情况和难度层级代表性选取最典型的任务实例作为示例难易梯度从简单到复杂排列示例帮助模型渐进理解标签平衡在分类任务中保持各类别示例数量均衡4.2 Chain-of-ThoughtCoT思维链思维链提示是提升 LLM 推理能力最关键的突破性技术。通过在提示中引导模型展示中间推理步骤显著提升在数学、逻辑、常识推理等复杂任务上的准确率。Few-shot CoT在示例中展示完整的推理过程问小明有 5 个苹果给了小红 2 个又买了 3 个现在有几个 推理小明初始有 5 个苹果 → 给了小红 2 个后剩 3 个 → 又买了 3 个共 6 个。 答6 个苹果。Zero-shot CoT无需示例仅添加一句让我们一步一步思考Lets think step by step即可触发模型的逐步推理能力。实验表明这一简单方法在数学推理等任务上有显著提升。CoT 适用场景算术推理、常识推理、符号推理、多步骤逻辑问题。不适用于简单的事实查询或单步任务。4.3 自洽性Self-Consistency自洽性是 CoT 的增强技术对同一问题执行多次采样使用较高 temperature收集多条推理路径然后通过多数投票选择最一致的答案。适用场景推理路径可能存在分叉的复杂问题如数学证明、逻辑推理优势弥补单条 CoT 可能产生的随机错误代价推理成本成倍增加通常 5-10 次采样4.4 ReActReasoning ActingReAct 将推理Reasoning与行动Acting交织进行是构建智能体的基础范式循环 Thought: 我需要检索 X 信息来回答这个问题... Action: search(X 的最新数据) Observation: [返回搜索结果] Thought: 根据搜索结果我还需要 Y 来补充... Action: search(Y 定义) Observation: [返回结果] Thought: 现在我有足够信息来回答了... Answer: [最终回答]ReAct 模式将 LLM 从一次性推理提升为交互式探索使其能够动态获取信息、验证假设、调整策略是现代 Agent 设计的核心范式。5. Prompt 优化5.1 样本和示例样本的意义增强模型理解明确任务要求、减少歧义。提高模型性能提供样本快速学习提升准确性。适应多样场景适应不同领域任务要求帮助模型应对简单到复杂的任务需求。样本和衡量标准的关系当提示中有明确的衡量标准或考评维度时样本的作用不只是示范和引导还能辅助评估和优化模型的输出。5.2 负面示例除了告诉模型应该怎么做提供不应做的示例同样重要尤其是在以下场景安全敏感任务展示什么是不可接受的输出格式严格的任务展示不符合格式的样例减少格式偏差歧义性高的任务用反例界定边界帮助模型更精准地理解要求5.3 简洁直接避免不必要的背景信息和复杂措辞明确指令、内容精简、直达要点以便模型能够迅速聚焦任务、准确生成内容。5.4 避免歧义通过明确和详细描述语句或提示内容确保信息传达清晰、准确并且能够被准确理解和执行。注意多义词、模糊短语、明确指代对象等常见歧义来源。5.5 分步骤和层次化的指导将复杂任务分解成多个简单且明确的步骤每一个步骤都清晰表述。对于多步骤任务按逻辑顺序排列指令必要时使用编号或清单格式。5.6 考虑多种可能性和边界条件充分考虑可能出现的各种输入情况和极端条件从而确保模型在面对各种非理想输入时仍能产生合理的输出。包括但不限于正例和反例、数据稀缺、极端值、格式错误和冲突信息等情况。5.7 纠错与自我修正常见错误处理考虑到可能出现的常见错误并设置相应的检测和修正机制以提高模型输出的正确性和可靠性。包括自动检测输入错误、设置默认应对措施、请求用户确认等。自我修正技术Self-Refine让模型对自己的输出进行审视-批评-修正的迭代循环生成初始输出自我审视让模型以批评者角色审视自己的输出指出问题修正基于反馈改进输出可迭代多轮直至满意ReflexionReflexion 将自我修正扩展到长期记忆模型不仅反思当前输出还将经验教训持久化存储在后续交互中自动调用。论文Reflexion: Language Agents with Verbal Reinforcement Learning。5.8 语言和文化敏感性多语言适配考虑目标语言的文化语境和表达习惯避免直译导致的生硬或误解。伦理考虑避免冒犯性内容、注重隐私保护、消除偏见、保持透明度和知情同意。5.9 约束对提示内容施加的特定限制或要求。合理设置约束是提示设计中的关键步骤约束类型说明内容约束对生成内容的主题、信息点或观点的具体要求确保输出内容围绕特定主题展开格式约束对输出内容的结构或排版形式的要求确保生成内容符合预期的布局和组织方式风格约束对生成内容的写作风格或语气的要求确保输出内容符合预期的文化和情感语境长度约束对生成内容的字数、段落数或字符数的要求确保输出内容在预定的长度范围内技术约束对生成内容使用特定专业术语或技术语言的要求确保输出内容在专业领域内的准确性时间约束对生成内容涉及特定时间节点或历史事件的要求确保输出内容与特定时间背景相关目标受众约束对生成内容的受众人群设定特定要求确保输出内容适合预期的阅读或使用群体语境约束对生成内容与前后文逻辑关系的要求确保输出的连贯性和一致性5.10 使用外部工具基于嵌入的搜索实现高效的知识检索RAG。代码执行进行更精确的计算或调用外部 API。函数/工具调用赋予模型访问特定功能的权限Function Calling / Tool Use。6. Prompt 安全6.1 Prompt Injection 防护提示注入是指攻击者通过构造恶意输入覆盖或绕过原始 Prompt 中的指令。防护策略包括指令优先级标记用明确的不可覆盖标记划定 System Prompt 的优先级输入隔离将用户输入放在 XML 标签内并明确不执行标签内的指令仅作为数据处理输入校验检测用户输入中是否包含试图覆盖系统指令的模式输出验证对模型输出进行二次审核防止执行恶意内容最小权限原则限制模型可调用的工具和可访问的数据范围6.2 数据隐私和安全性避免在 Prompt 中包含敏感个人信息PII对于涉及用户数据的生产环境建立数据脱敏流水线注意第三方 API 服务的数据传输和存储合规性定期审计 Prompt 日志中的潜在隐私泄露7. Prompt 工程化7.1 Prompt 版本管理企业级 Prompt 应纳入版本控制使用 Git 管理 Prompt 模板文件记录每次修改的原因和效果保留历史版本以便回滚和对比将 Prompt 与代码分离便于非开发人员维护7.2 A/B 测试与评估离线评估使用标注数据集量化评估 Prompt 变体的准确率、召回率等指标在线 A/B 测试在生产环境中分流测试不同 Prompt 的实际效果LLM-as-Judge使用更强的模型作为评判者对输出质量打分关键指标任务完成率、幻觉率、格式合规率、用户满意度7.3 自动提示优化DSPy传统 Prompt Engineering 依赖人工反复试错。DSPy 等框架将 Prompt 优化转化为可编程的优化问题定义任务签名输入输出结构提供少量训练样例框架自动搜索最优的提示结构和 Few-shot 示例组合这代表了 Prompt Engineering 从手工艺走向工业化的趋势。Context Engineering1. 什么是上下文工程Context Engineering核心理念上下文工程是一门更广泛的学科旨在管理和维护 LLM 推理过程中最佳的词元集。如果说 Prompt Engineering 关注的是我应该如何表达那么上下文工程关注的是模型现在需要访问哪些信息LLM 即操作系统类比LLM大型语言模型就像一种新型操作系统LLM CPU负责计算和推理上下文窗口Context Window RAM代表模型的工作内存上下文可以通过多种方式进入 LLM包括提示Prompt如用户指令检索Retrieval如外部文档工具调用Tool Calls如 API 返回结果然而和 RAM 一样LLM 的上下文窗口有带宽和容量限制无法无限制加载信息。因此如何像操作系统管理内存一样科学地打包和管理上下文成为智能体开发的关键——这就是上下文工程。2. 上下文的核心挑战2.1 Lost in the Middle 问题研究表明LLM 对上下文信息的利用效率不是均匀分布的开头信息注意力权重高利用率最好末尾信息注意力权重较高利用率次之中间信息利用率显著下降即使关键信息放在中间也可能被模型忽略应对策略将最重要的信息放在上下文的开头或结尾对长上下文进行分段处理使用检索而非全量加载。2.2 上下文窗口的限制挑战影响容量限制即使 200K token 的窗口大量工具调用反馈仍可能溢出成本递增上下文越长每次推理的 API 费用越高呈超线性增长延迟增加更长的上下文意味着更慢的响应时间注意力稀释过长上下文可能导致模型无法聚焦关键信息2.3 过度上下文的负面影响过长的上下文不仅增加成本和延迟还可能导致性能下降关键信息被无关噪声淹没幻觉增加模型在大量信息中更容易产生混淆指令遗忘早期的约束和要求被后续内容稀释3. 上下文工程的三大发展阶段Prompt Engineering随着聊天机器人的兴起提示工程成为引导 LLM 行为的首要手段。RAG检索增强生成为了让 LLM 连接外部数据源RAG 作为第二阶段应运而生。智能体与工具调用Agent Tool CallsLLM 工具调用能力提升后智能体通过 LLM 与工具的反复交互推动上下文工程进入第三阶段。4. 三大核心策略智能体上下文由工具调用的反馈填充这些反馈可能超过上下文窗口的大小导致成本和延迟激增。过长的上下文还可能降低智能体性能。应对策略分为三类筛选Curate、持久化Persist和隔离Isolate。4.1 筛选上下文Curating Context筛选上下文涉及管理每一轮智能体可见的 token 数量避免上下文膨胀。上下文摘要Context Summarization智能体交互可能持续数百轮还可能有大量 token 的工具调用。上下文摘要是常见的管理方式之一。例如 Claude Code 在上下文窗口超 95% 时自动压缩。摘要可以用在不同地方工具调用反馈摘要对大量 token 的搜索结果进行摘要特定步骤摘要如 Anthropic 的多智能体研究系统会对已完成的工作阶段应用摘要递归/分层摘要对整个智能体轨迹进行多层级摘要精细摘要设计摘要若需保留特定事件或决策需更细致的设计。例如 Cognition 在 Devin 中用微调模型专门处理摘要确保关键信息不丢失。其他筛选策略设定每轮最大 token 预算对历史消息按重要性剪枝使用滑动窗口仅保留最近 N 轮交互4.2 持久化上下文Persisting Context持久化上下文涉及建立系统长期存储、保存和检索上下文支撑智能体记忆。存储上下文文件是存储上下文的简单方式。许多主流智能体采用了这种方式Claude Code使用CLAUDE.md文件Cursor / Windsurf使用规则文件.cursorrules、.windsurfrulesMemory Bank 插件 / MCP Server管理一系列内存文件向量数据库方案Letta、Mem0 和 LangGraph / Mem 支持嵌入文档的存储和检索保存上下文手动保存Claude Code 允许用户手动创建或更新记忆如#快捷键自动保存Reflexion 论文提出的自动记忆生成已被 ChatGPT、Cursor、Windsurf 等产品采纳基于反馈更新记忆可在特定节点根据用户反馈更新。例如人工审核工具调用结果并结合记忆更新可以让智能体持续学习检索上下文全量加载最简单的方式是把所有记忆加载进上下文窗口。例如 Claude Code 每次会读取所有CLAUDE.md文件到上下文。选择性检索当记忆量大时需选择性检索语义检索Embedding Search基于向量相似度检索相关记忆图谱检索Graph Retrieval利用知识图谱的结构化关系检索混合检索结合关键词BM25和语义检索确保召回率4.3 隔离上下文Isolating Context隔离上下文涉及将上下文在不同智能体/环境间分区优化 token 使用和任务协作。上下文模式Schema常见做法是用消息结构化智能体上下文。工具反馈会附加到消息列表完整列表每轮传递给 LLM。问题是列表可能因大量 token 的工具调用而膨胀。用结构化的运行时状态往往更高效可以更好地控制每轮 LLM 可见内容。例如深度研究智能体用 Schema 将messages每轮传递与sectionstoken 多按需加载分离。多智能体Multi-agent在多智能体系统中一种常见做法是将任务拆分给多个子智能体各自有独立上下文和指令。挑战Token 消耗激增可能比单智能体多 15 倍子智能体规划的提示和上下文设置复杂子智能体协调难度高折中策略确保任务易于并行。Anthropic 的深度研究多智能体系统就是把并行应用在研究上容易并行而不是写作上需要整体结构连贯。基于环境的上下文隔离HuggingFace 的深度研究智能体是上下文隔离的又一例证。大多数智能体用工具调用 APIAPI 返回 JSON参数传递给工具如搜索 API获取反馈如搜索结果。HuggingFace 用CodeAgent输出代码来调用工具。代码在沙盒Sandbox中运行执行反馈再传递给 LLM。沙盒会存储执行过程中生成的对象例如图片将其与 LLM 上下文窗口隔离但智能体可以用变量随时引用。这种方式将状态管理从 LLM 上下文转移到执行环境大幅节省 token。5. 关键技术5.1 Prompt Caching提示缓存Anthropic 的 Prompt Caching 是上下文工程中最重要的成本优化手段。原理是对重复使用的 System Prompt、Few-shot 示例、工具定义等前缀内容进行缓存后续请求中若前缀未变跳过计算直接复用缓存结果可节省高达90%的 API 成本同时降低延迟最佳实践将不变的内容角色定义、格式规范、工具 Schema放在前缀位置将动态内容用户输入、检索结果放在末尾缓存断点设置在内容边界明显的位置5.2 MCPModel Context ProtocolMCP 是 Anthropic 发布的开放协议旨在标准化 LLM 与外部工具/数据源的连接方式统一接口所有工具和数据源通过同一协议接入减少上下文管理碎片化工具发现LLM 可以动态发现和调用已连接的 MCP Server上下文标准化工具定义和反馈格式统一降低上下文工程复杂度5.3 RAG 深入RAG检索增强生成是连接 LLM 与外部知识的关键技术与上下文工程紧密相关环节关键技术上下文工程考量文档分块固定大小、语义分块、递归分块块太大浪费 token太小缺失语境嵌入模型text-embedding-3、bge-large 等不同模型对多语言和领域覆盖不同检索策略语义搜索、关键词搜索BM25、混合搜索召回率和精度的权衡重排序Cohere Rerank、Cross-encoder过滤低质量结果提升上下文密度5.4 上下文压缩与结构化上下文压缩使用提取式或生成式方法将长文档压缩为关键信息结构化格式XML、JSON、Markdown 等结构化格式帮助模型更好地解析和利用上下文信息密度优化删除冗余描述、合并重复信息、优先保留高信息量内容6. 评估与优化6.1 上下文工程的评估指标指标定义目标Token 效率单位任务的 token 消耗持续降低任务完成率在上下文限制内成功完成任务的比率接近 100%幻觉率输出中包含不实信息的频率持续降低首字延迟TTFT从请求到第一个 token 的时间越小越好上下文利用率上下文中被模型实际关注的信息比例越高越好成本/Task单次任务的平均 API 成本持续降低6.2 成本与性能的权衡上下文工程的核心难题是三角权衡准确性 -- 成本 -- 延迟更多上下文 → 更高准确性上限 → 但成本和延迟同步上升更精简的上下文 → 更低的成本和延迟 → 但可能丢失关键信息目标在给定延迟和成本预算下最大化准确性附录Prompt Engineering 检查清单设计和优化 Prompt 时逐项核验目标是否清晰具体不含歧义是否提供了必要的背景和上下文是否通过角色设定锚定了专业领域和语调输入输出格式是否明确复杂推理任务是否使用了 CoT 或 ReAct是否提供了足够的示例示例是否覆盖了边界情况是否包含了负面示例来划定边界是否明确了约束条件长度/风格/内容/受众是否考虑了边界条件和异常输入是否建立了输出验证/纠错机制是否排查了 Prompt Injection 风险是否避免在 Prompt 中包含敏感数据Prompt 是否已纳入版本管理Context Engineering 检查清单设计智能体上下文时逐项核验上下文窗口是否在模型限制内最重要的信息是否放在开头或结尾是否使用了 Prompt Caching 优化成本和延迟是否有上下文摘要/压缩机制应对长对话记忆是否正确持久化和检索多智能体是否合理隔离了上下文RAG 检索质量是否达标工具调用反馈是否经过筛选再进入上下文是否评估了 Token 效率和任务完成率是否考虑了多模态内容在上下文中的组织方式