人工智能行业又来造次（词）｜从"提示词工程"到"上下文工程"

这篇是 《科技慢半拍》EP95：人工智能行业又来造次（词）｜从”提示词工程”到”上下文工程” 的文字稿整理版。

前言

AI界每天都在涌现新产品、新理念，当然也包括新名词。这次我们要聊一个最近火爆的新词——上下文工程（Context Engineering）。这些年大家已经熟悉了自大模型诞生以来的一个术语：提示词工程（Prompt Engineering），即构建或设计指令的过程，以便从生成式AI模型中产生最佳输出。这一概念在传统的以编码为基础的软件工程领域投下了一块重石。

2018年，研究人员首次提出，自然语言处理（NLP）中所有此前各自独立的任务，都可以转化为基于语境的问答问题。在2022年ChatGPT发布后，提示词工程迅速成为一项重要的商业技能，催生了Cursor、Codeium等一批基于提示词工程的开发工具，也诞生了提示词工程师这一新职业。

那么，既然已经有了提示词工程，为什么还要定义一个新术语——上下文工程呢？

什么是Context？上下文、语境还是情景？

要理解上下文工程，首先要搞清楚Context是什么。这是一个跨越多个领域的多义词。

在语言学领域，Context代表语境。一个人的讲话涉及语法、语义和语境三个层面。语境决定了同一句话在不同情境下，可能因为多义词、轻重音、情感和语气的不同，产生截然不同的理解。现代社交媒体上常见的”断章取义”现象，正是将某人的讲话脱离原有语境单独播放，导致严重误解。

从神经科学角度看，语境是实现人类大脑间同步的关键机制。《神经元》杂志发表的研究表明，我们可以通过对话中的词语及其语境来模拟脑-脑同步过程。普林斯顿大学的神经科学家发现：“在说话者真正开口前，语言内容已在其大脑中形成；当听者接收到这些信息后，同样的语言内容也会在其大脑中迅速重现。”

在计算机科学领域，Context早已作为”上下文”的概念存在。它指任务（进程、线程或纤程）使用的最小数据集，用于在任务中断后从相同点恢复执行。上下文越小，延迟越低。它也可视为一种允许程序状态在组件间传递的机制。

Context还有”情景”的含义，如”Context awareness”（情景感知）——计算机能感知环境并做出相应反应的能力，由Schilit于1994年在普适计算领域提出。

在当今大模型和AI领域，Context的理解更为综合，既包含计算机领域的关联任务和数据概念，也融合了语言学中的语境概念，配合提示词的相关语境信息表达，使这一术语含义更加丰富全面。

Context Engineering的发酵过程

Ankur Goyal：率先提出

2025年4月20日，Braintrust Data公司的CEO Ankur Goyal在X上发布了一条关于”上下文工程”的推文。他指出，随着模型规模不断扩大，他发现需要将更多精力集中在上下文工程上——也就是如何向大模型提供正确的背景信息。

他的核心观点：

• 提供过少的上下文会导致大模型无法准确理解任务
• 优质的上下文工程能够有效缓存数据并高效处理信息
• 低质量的上下文工程则会导致系统运行缓慢且成本高昂

虽然Goyal可能不是首个提出这一术语的人，但他的讨论使这个概念从日常交流中的随意表述转变为一个正式的专业术语。

Tobias Lütke：大佬背书

这个词汇的广泛传播离不开Shopify联合创始人兼CEO托比亚斯·吕特克（Tobias Lütke）。他在2025年6月19日在X平台上发文：

“我真的非常喜欢’上下文工程’这个术语，而非’提示词工程’。‘上下文工程’更准确地描述了我们使用大模型的核心技术能力——为大模型提供合适的背景信息，使其能够更好地解决任务的艺术。”

有了这位业界大佬的背书，“上下文工程”这一概念获得了极大的认可和推广力度。

Walden Yan：系统阐述Agent上下文原则

Cognition公司创始人Walden Yan（开发了首个智能程序员Agent Devin）在2025年6月12日发表了文章《Don’t Build Multi-Agents》（不要构建多智能体），在文章中系统阐述了上下文工程的核心原则。

Yan分析了两种智能体协作模式：

并行模式：将任务分配给不同Agent独立处理后再整合结果。问题在于，各Agent对同一任务的理解可能存在差异，导致最终结果无法有效合并。

串行模式：一个Agent完成后将结果连同完整上下文传递给下一个Agent。优势在于能保持上下文连贯性。

基于这些分析，Yan提出了上下文工程的两个核心原则：

1. 共享上下文：分享完整的Agent轨迹（trace），而不仅仅是单个消息
2. 行动包含隐含的决策，而冲突的决策会带来不良后果

然而，持续传递和累积上下文会导致上下文窗口溢出。针对这一挑战，Cognition团队引入了一种技术解决方案：使用较小的大语言模型将一系列动作和对话历史压缩为关键细节、事件和决策，从而实现高效的上下文管理。

Dexter Horthy：梳理上下文的组成

HumanLayer创始人Dexter Horthy在X上给出了自己对Context Engineering的定义，并画图说明。他认为构建良好上下文应该包括：

• 给模型的提示和指令
• 检索的任何文档或外部数据（如RAG）
• 任何过去的状态、工具调用、结果或其他历史记录
• 来自相关但独立历史/对话的过去消息或事件（记忆）
• 关于应输出何种结构化数据的指示

Context Engineering被正式定义

LangChain的定义

2025年6月23日，LangChain官方发表文章《The rise of “context engineering”》，给出了权威定义：

上下文工程是构建动态系统，以提供正确的信息和工具，采用合适的格式，使LLM能够合理地完成任务。

这个定义的几个关键特征：

系统性：复杂的智能体通常从多个来源获取上下文——开发者、用户、之前的交互、工具调用或外部数据，将这些整合在一起需要一个复杂的系统。

动态性：许多上下文信息是动态生成的，构建最终提示的逻辑也必须是动态的，而非简单的静态模板。

准确性：LLM无法”读心”——你必须为它们提供准确的信息。输入垃圾，只会输出垃圾。

工具配合：并非在所有情况下LLM仅凭输入就能解决任务，提供合适的工具与提供正确信息同样重要。

为什么上下文工程如此重要？ 因为当具备智能体能力的系统出错时，很大程度上是因为LLM出错了。LLM出错有两个主要原因：一是底层模型本身有缺陷；二是模型没有被传递适当的上下文。随着模型性能不断提升，错误更多源于第二个原因。

关于提示词工程与上下文工程的关系：提示词工程是上下文工程的子集。即使拥有所有上下文，如何在提示中组织这些信息仍然至关重要。区别在于，你设计提示不再是为了与单一输入数据集良好配合，而是为了接受一组动态数据并正确格式化。

Lance Martin：上下文的三大工程策略

LangChain的Lance Martin在同日发表了《Context Engineering for Agents》，提出了一个影响力颇大的类比：

LLM就像CPU，而上下文就像RAM，代表模型的”工作记忆”。

他将上下文工程归纳为一个综合性学科，涵盖三类内容：

• 指令（Instructions）：类似提示词，可包含记忆和少量示例
• 知识（Knowledge）：通过检索或记忆扩展模型的世界知识（如RAG）
• 工具反馈（Tool feedback）：通过工具从环境中获取的上下文

针对上下文过长这一核心问题，他提出了三种策略：

压缩（Compressing Context）：在每个回合只保留价值最高的token。上下文总结是最常见的方法——当上下文超过窗口的95%时，自动运行压缩。工具边界是添加压缩的自然位置，可以用小型LLM对大量token的工具调用输出进行总结。

持久化（Persisting Context）：系统在一段时间内存储、保存和检索上下文，分为三个层面：

• 存储（Storing）：文件是最简单的方式，如Cursor和Windsurf的规则文件
• 保存（Saving）：让Agent自主创建/更新记忆，基于用户反馈进行更新
• 检索（Retrieving）：将记忆拉入上下文窗口，可通过嵌入搜索或图检索实现

隔离（Isolating Context）：在Agent或环境之间划分上下文，包括：

• 上下文模式（Context Schema）：用结构化的运行时状态替代简单消息列表，更好控制LLM在每个回合看到的内容
• 多智能体（Multi-agent）：将上下文拆分给子Agent，适用于可并行化的任务
• 沙箱环境隔离：代码在沙箱中运行，将大量工具反馈与LLM上下文窗口隔离

Martin还总结了一些实践经验教训：

• 先进行监测，始终关注你的token使用数据
• 设计合理的Agent状态（State Schema）
• 在工具边界处进行压缩
• 从简单记忆开始，避免过度工程化
• 只在任务易于并行且不需要严格协调时才考虑多Agent

Andrej Karpathy背书与概念升华

在这一系列传播之后，Andrej Karpathy于6月25日在X上表示”+1”支持”上下文工程”优于”提示词工程”的说法。

Karpathy的贡献不只是背书，更是将概念升华到了一个更高层次。他写道：

“在每一个工业级的LLM应用中，上下文工程都是一门精妙的艺术和科学，它需要用恰当的信息填充上下文窗口，以便下一步操作。之所以说是科学，是因为正确地做到这一点需要任务描述和解释、一些示例、RAG、相关（可能是多模态）数据、工具、状态和历史记录、压缩……之所以说是艺术，是因为LLM的心理学指导着人们的精神世界。”

他进一步指出，上下文工程只是整个LLM工程栈的一小部分，还需要：

• 将问题分解为控制流
• 正确打包上下文窗口
• 向合适类型和能力的LLM发出请求
• 处理生成验证UI/UX流程
• 护栏、安全、评估、并行性、预取……

他还明确驳斥了”ChatGPT套壳”这种理解：“ChatGPT包装器”这个术语已经过时了，而且非常非常错误。 真正的工业级LLM应用需要系统化的上下文工程，而不是简单地在API外面加一层。

随后，Google DeepMind的Philipp（曾任Hugging Face技术负责人）在6月30日发表了《The New Skill in AI is Not Prompting, It’s Context Engineering》，进一步明确了上下文工程的范围，使这一概念完成了从X上的讨论到主流AI工程领域的破圈传播。

综合以上，我们可以给出一个最终定义：

上下文工程是一门设计和构建动态系统的学科，能够在正确的时间，以正确的格式，为大语言模型提供恰当的信息和工具，使其能够完成任务。

用一个类比来理解：提示词就像父母对孩子发出的单次指令（“去写作业”）；提示词工程是”科学育儿法”，通过系统迭代优化提高教育效果；而上下文工程则是父母综合考虑家庭环境、成长历程和外部资源，为孩子打造一个动态发展的家庭生态系统。

我们该如何看待AI行业的造词运动？

Karpathy最近像是个新词发明机器——vibe coding（氛围编程）、软件3.0，如今又背书了上下文工程。对于AI领域这种层出不穷的造词现象，我的态度是：既支持又反对。

支持的理由：

• 新领域确实需要新词来快速概括复杂现象。“元宇宙""区块链""内卷”，每个词背后都承载着难以用旧词描述的新现象
• 新词能映射当代专业领域和社会环境中的价值观变化，体现语言作为社会互动产物的生命力
• 网络语言中许多新词带有幽默、讽刺和创意，体现语言的游戏性

比较保守的替代方案是”版本号造词法”（Web 1.0/2.0/3.0，软件工程1.0/2.0/3.0）——在已有理解的基础上接受新理念，不必创造全新词汇。

反对的理由：

• 为”时髦”或”炒作”随意造词，可能冲击传统语言的逻辑性，形成语言泡沫
• 有些新词缺乏深层语义支撑，一旦热度过去便迅速消失
• 大量专业术语可能成为划分”我们”和”他们”的工具，限制沟通而非促进交流

判断一个新词是否值得认真对待的标准：它是否真的描述了一个用旧词难以描述的现象？上下文工程这个词，我认为是值得认真对待的——它确实指向了一个真实存在的工程挑战，而不只是对提示词工程的换壳重新包装。

语境对人类和AI沟通的深层意义

萧伯纳曾经说过：“沟通中最大的问题是误以为沟通已经发生。”

这句话放到人机交互的语境里同样成立。人类的沟通从来不只是词语和语法，还包含受语境影响的语义层。相同的话在不同情境下可能产生截然不同的效果——这也是为什么面对面交流和阅读文字存在差别，文字往往缺失了语调、情感和语气等元素。

从这个角度看，提示词工程是人机交互的”初识阶段”——简单问答，AI回答，这个阶段能做好已经不容易。随后发展出步骤化推理和示例引导，让AI更好地理解任务。而上下文工程，则是让AI真正”了解你”的系统化方法——了解你的工作环境、历史决策、偏好和约束。

当然，我们不能指望每个用户都花大量时间和AI”谈恋爱”式地建立深度上下文。这就是为什么需要工程化的方法——通过RAG、记忆系统、状态管理等技术手段，自动地为LLM提供恰当的上下文，而不是依赖用户每次手动填充。

最后，从中国的角度来看：大模型是科学，上下文和提示词是工程，而中国人更擅长工程。虽然国内团队在基础科学研究上可能相对落后，但在AI应用层面已有出色表现。上下文工程这个领域，中国企业有能力贡献真正有价值的实践。