prompt engineer，context engineer

Prompt Engineering（提示工程）和 Context Engineering（上下文工程）是 LLM 应用开发中两个紧密相关但层次不同的学科：

Prompt Engineering 关注"如何表达"------如何设计输入指令以获得高质量输出。它是上下文工程的基础层。
Context Engineering 关注"模型需要访问哪些信息"------如何像操作系统管理内存一样，科学地管理和编排 LLM 上下文窗口中的所有信息。

两者的演进路径为：Prompt Engineering → RAG → 智能体与工具调用，从单轮指令设计逐步发展到多轮、多源、多智能体的上下文编排。

Prompt Engineering

1. 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 Techniques）

4.1 Zero-shot / One-shot / Few-shot

Zero-shot（零样本）：不提供任何示例，直接给出任务指令。适用于模型已有充分预训练知识的简单任务。

One-shot（单样本）：

提供单个输入输出配对示例，帮助模型理解任务要求和期望的输出格式。
适用场景：模型已有一定基础知识，只需要一个示例来了解具体格式和期望输出。

Few-shot（少样本）：

提供多个（通常是 2-5 个）输入输出配对示例，进一步明确任务细节和复杂性。
适用场景：任务较复杂，或者模型对任务不够熟悉，需要通过多个示例来学习任务特征。

Few-shot 示例选择策略：

多样性：覆盖不同的输入类型、边界情况和难度层级
代表性：选取最典型的任务实例作为示例
难易梯度：从简单到复杂排列示例，帮助模型渐进理解
标签平衡：在分类任务中保持各类别示例数量均衡

4.2 Chain-of-Thought（CoT，思维链）

思维链提示是提升 LLM 推理能力最关键的突破性技术。通过在提示中引导模型展示中间推理步骤，显著提升在数学、逻辑、常识推理等复杂任务上的准确率。

Few-shot CoT：在示例中展示完整的推理过程：

复制代码

问：小明有 5 个苹果，给了小红 2 个，又买了 3 个，现在有几个？
推理：小明初始有 5 个苹果 → 给了小红 2 个后剩 3 个 → 又买了 3 个，共 6 个。
答：6 个苹果。

Zero-shot CoT：无需示例，仅添加一句"让我们一步一步思考（Let's think step by step）"，即可触发模型的逐步推理能力。实验表明这一简单方法在数学推理等任务上有显著提升。

CoT 适用场景：算术推理、常识推理、符号推理、多步骤逻辑问题。不适用于简单的事实查询或单步任务。

4.3 自洽性（Self-Consistency）

自洽性是 CoT 的增强技术：对同一问题执行多次采样 （使用较高 temperature），收集多条推理路径，然后通过多数投票选择最一致的答案。

适用场景：推理路径可能存在分叉的复杂问题（如数学证明、逻辑推理）
优势：弥补单条 CoT 可能产生的随机错误
代价：推理成本成倍增加（通常 5-10 次采样）

4.4 ReAct（Reasoning + Acting）

ReAct 将推理（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）

让模型对自己的输出进行"审视-批评-修正"的迭代循环：

生成初始输出
自我审视：让模型以批评者角色审视自己的输出，指出问题
修正：基于反馈改进输出
可迭代多轮直至满意

Reflexion

Reflexion 将自我修正扩展到长期记忆：模型不仅反思当前输出，还将经验教训持久化存储，在后续交互中自动调用。论文：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 Engineering

1. 什么是上下文工程（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 Calls）：LLM 工具调用能力提升后，智能体通过 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、.windsurfrules）
Memory 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（每轮传递）与 sections（token 多，按需加载）分离。

多智能体（Multi-agent）

在多智能体系统中，一种常见做法是将任务拆分给多个子智能体，各自有独立上下文和指令。

挑战：

Token 消耗激增（可能比单智能体多 15 倍）
子智能体规划的提示和上下文设置复杂
子智能体协调难度高

折中策略：确保任务易于并行。Anthropic 的深度研究多智能体系统就是把并行应用在"研究"上（容易并行），而不是"写作"上（需要整体结构连贯）。

基于环境的上下文隔离

HuggingFace 的深度研究智能体是上下文隔离的又一例证。大多数智能体用工具调用 API，API 返回 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 MCP（Model Context Protocol）

MCP 是 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 效率和任务完成率？
是否考虑了多模态内容在上下文中的组织方式？