Agent 架构综述：从 Prompt 到 Context

原创

于 2025-08-26 10:27:37 发布 · 933 阅读

背景

在观察去年以来对于“Prompt Engineering”的解构时，我们可以观察到一个微妙但重要的分歧。

一方面，专注于构建可扩展系统的前沿实践者们（如 Andrej Karpathy 等），积极倡导用 “Context Engineering” 来描述工作，认为 “Prompt Engineering” 这个词不足以涵盖复杂性，认为它只是 “Coming up with a laughably pretentious name for typing in the chat box（给在聊天框里打字起的一个可笑的自命不凡的名字）” 。因为他们构建 Agent 系统的核心挑战并非仅仅是 Prompt，而是设计整个数据流以动态生成最终提示的架构。
另一方面，近年来学术和正式文献倾向用 “Prompt Engineering” 作为一个广义的 umbrella term（伞形术语），其定义包括了 “Supporting content” 或 “Context”，把所有在不改变模型权重的前提下操纵模型输入的技术归为同一类型。
术语上的分歧可以反映该领域的成熟过程：随着 AI 应用从简单的单次交互发展到复杂的、有状态的智能体系统，优化静态指令已经无法满足需求。因此，“Context Engineering” 的出现，是为了区分两种不同层次的活动：一是编写指令的 skill，二是构建自动化系统以为该指令提供成功所需信息的科学。
（本文明确，尽管在学术上 Prompt Engineering 可能涵盖上下文，但在工程实践中，Context Engineering 是专注于如何动态构建和管理上下文的专门学科）
重新定义 Agent 数据流：Context is All Aou Need
本部分旨在建立 Prompt Engineering 与 Context Engineering 的基础概念，清晰地界定二者之间的区别与联系。
从前者到后者的转变，代表了人工智能应用开发领域一次关键的演进——从业界最初关注的战术性指令构建，转向由可扩展、高可靠性系统需求驱动的战略性架构设计。
Prompt Engineering - the Art of Instructions
Prompt Engineering 是与大型语言模型（LLM）交互的基础，其核心在于精心设计输入内容，以引导模型生成期望的输出。这一实践为理解 Context Engineering 的必要性提供了基准。
定义
一个提示（Prompt）远不止一个简单的问题，它是一个结构化的输入，可包含多个组成部分。这些组件共同构成了与模型沟通的完整指令：

指令（Instructions）：对模型的核心任务指令，明确告知模型需要执行什么操作。
主要内容/输入数据（Primary Content/Input Data）：模型需要处理的文本或数据，是分析、转换或生成任务的对象。
示例（Examples/Shots）：演示期望的输入-输出行为，为模型提供“上下文学习”（In-Context Learning）的基础。
线索/输出指示器（Cues/Output Indicators）：启动模型输出的引导性词语，或对输出格式（如JSON、Markdown）的明确要求。
支持性内容（Supporting Content/Context）：为模型提供的额外背景信息，帮助其更好地理解任务情境。正是这一组件，构成了 Context Engineering 发展的概念萌芽。

Prompt Engineering 的核心技术
Prompt Engineer 使用一系列技术来优化模型输出，这些技术可按复杂性进行分类：

零样本提示（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，而是一个更高阶、更侧重于系统设计的必要学科。
定义 Context Engineering
Context Engineering 是一门设计、构建并优化动态自动化系统的学科，旨在为大型语言模型在正确的时间、以正确的格式，提供正确的信息和工具，从而可靠、可扩展地完成复杂任务。
prompt 告诉模型如何思考，而 Context 则赋予模型完成工作所需的知识和工具。
“Context”的范畴
“Context”的定义已远超用户单次的即时提示，它涵盖了 LLM 在做出响应前所能看到的所有信息生态系统：