上下文工程

早期提示工程（Prompt Engineering），即如何巧妙地向模型提问，迅速转向一个更进阶的领域——上下文工程（Context Engineering）。

资料

LangChain 官方博客文章《The Rise of “context engineering”》
【2025-6-24】解读 LangChain官方分享LLM的“上下文工程”技巧
【2025-7-16】图解+详解：上下文工程

上下文负责铺路，而提示工程教你怎么走，提示工程是上下文工程的子集。

背景

使用LLM 智能体（Agent）时，常常遇到棘手问题：

为什么智能体表现如此不稳定？

习惯性归咎于模型本身不够强大。

然而，问题根源：未能向模型提供恰当上下文。

当一个智能体无法可靠地执行任务时，其根本原因通常是未能以正确的格式向模型传递正确的信息、指令和工具。

随着LLM应用从单一提示词演变为复杂的、动态的智能体系统，“上下文工程”（Context Engineering）正迅速成为AI工程师需要掌握的重要技能。

Cognition 团队核心观点

“再聪明的模型，若不知上下文，也无法做出正确判断。”

LLM 失败

智能体系统的失误，本质是 LLM 失误。

从第一性原理分析，LLM 失败主要源于两个方面：

底层模型能力不足，无法正确推理或执行。
模型缺少正确判断所需的上下文。

随着模型能力的飞速发展，第二点正成为更普遍的瓶颈。

上下文供给不足主要体现在：

信息缺失：模型完成任务所依赖的关键信息未被提供。
格式混乱：信息虽然存在，但其组织和呈现方式不佳，阻碍了模型的有效理解。

提示词 → 上下文

大模型应用技术从“提示词艺术”迈向“上下文科学”。

最近爆品，如Cursor，Manus等产品都表明

一个卓越的大模型产品，背后必然是精心设计的上下文工程系统。

未来的核心竞争力，不再是精妙的提示词，更是高质量、高效率的上下文。

通过精心组织，为模型提供事实依据、注入持久记忆、并扩展其行动能力，有可能释放大模型的潜力，构建出新的有价值AI产品。

定义

上下文工程

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

上下文工程

上下文工程（Context Engineering）核心定义：

构建一个动态系统，以正确格式提供正确的信息和工具，从而使大语言模型（LLM）能够可靠地完成指定任务。

深入理解：

系统工程：复杂智能体从多个来源获取上下文，包括开发者预设、用户输入、历史交互、工具调用结果以及外部数据。将这些信息源有机地整合起来，本身就是一个复杂的系统工程。
动态变化：上下文组成部分很多是实时生成。最终输入给模型的提示（Prompt）也必须是动态构建的，而非静态的模板。
信息精准：智能体系统失败的原因之一是上下文信息缺失。LLM 无法“读心”，必须为其提供完成任务所需的全部信息。所谓“垃圾进，垃圾出”，信息质量直接决定输出质量。
工具适用：很多任务无法仅靠初始信息完成。为 LLM 配备合适的工具就变得至关重要，用于信息检索、执行动作或与其他系统交互。提供正确的工具与提供正确的信息同等重要。
强调格式规范：与 LLM 的“沟通方式”跟人一样关键。简洁明了的错误信息远胜于一个庞杂 JSON 数据块。工具的参数设计、数据的呈现格式，都会显著影响 LLM 的理解和使用效率。
任务可行性：设计系统时，应反复自问：“在当前提供的上下文和工具下，LLM 是否真的有可能完成任务？” 便于归因分析，上下文不足，还是模型本身的执行失误，从而采取不同的优化策略。

图解

提示工程 vs 上下文工程

为什么从“提示工程”（Prompt Engineering）转向“上下文工程”？

LLM应用早期，开发者专注于通过巧妙措辞诱导模型给出更好的答案。

但随着应用变得越来越复杂，共识逐渐形成：

向AI提供完整和结构化的上下文，远比任何“魔法般”的措辞都重要。

提示工程是上下文工程的子集。

即使有全部上下文信息，提示词组织、编排方式，仍然至关重要——提示工程范畴。

核心区别：

上下文工程：设计架构，动态地收集、筛选和整合来自多源的数据，构建出完整的上下文。
提示工程：已有上下文的基础上，设计格式化和指令，以最优方式与LLM沟通。

不同于传统 Prompt Engineering，Context Engineering 更关注系统级的动态上下文构建。

强调：在复杂交互和多智能体协作中，如何为每个 Agent 构建精准、独立、可持续的任务背景，是系统能否稳定运行的关键。

维度	提示词工程(Prompting engineering)	上下文工程(Context engineering)
目标	写出清晰、明确的指令	准备好一切AI该知道的信息
本质	提示词本质是布置任务的指令，让AI按预期方式回答问题、执行任务	告诉AI当前的「需要什么」、「能做什么」，就像游戏的任务设定一样，提供所需要的信息、工具和历史记忆，然后交给AI来思考和执行
比喻	怎么走路	铺路
图解

总结：

提示词工程依赖精细指令，不仅难以复用，还容易因措辞差异导致结果波动，对写Prompts的人要求也更高
上下文工程让AI具备持续理解和应变能力，不仅能适应新任务，还能保持输出稳定、不易“翻车”

漫画来自: 小红书博主“机器坏人（AI版）”

更多对比

构成

上下文系统由多个关键部分组成

上下文工程 = 提示词 + 用户画像 + 记忆 + 检索信息 + RAG信息 + MCP信息

上下文工程是一个动态系统

复杂的智能体系统从多个来源获取上下文：

应用开发者：预设的系统指令和行为准则。
用户：当前任务的直接输入和要求。
历史交互：先前对话的记忆或摘要。
工具调用：通过API或函数调用获取的外部信息。
外部数据：从数据库或知识库中检索的文档。

将所有这些信息整合在一起，需要一个复杂的系统。

提供正确的信息与工具
格式化至关重要
自检：反复确认信息是否充分

而且必须动态，因为许多上下文信息是实时变化的。

因此，最终交付给LLM的提示词（Prompt）不是静态模板，而是由动态逻辑实时构建的。

好的上下文工程应该包括：

工具使用：当一个智能体访问外部信息时，需要拥有能够访问这些信息的工具。当工具返回信息时，需要以 LLM 最容易理解的方式对其进行格式化。
短期记忆：如果对话持续一段时间，可以创建对话摘要，并在未来使用该摘要。
长期记忆：如果用户在之前的对话中表达了偏好，需要获取这些信息。
提示工程：在提示中清楚地列举智能体应该如何操作的说明。
检索：动态地获取信息，并在调用 LLM 之前将其插入到提示中。

正确的信息与工具

LLM 应用失败常见原因：上下文缺失。

LLM无法读取用户思想，如果不提供完成任务所需的关键信息，不可能知道这些信息的存在。

“垃圾进，垃圾出”（Garbage in, garbage out）原则。

同样，仅有信息可能还不够。

在很多场景下，LLM需要借助工具来查询更多信息或执行某些动作。为LLM提供正确的工具，与提供正确的信息同等重要。

格式化至关重要

与人类沟通类似，如何向LLM传递信息，其格式会极大地影响结果。

一个简短但描述清晰的错误信息，远比一个庞大而杂乱的JSON数据块更容易让LLM理解和处理。这一点同样适用于工具的设计，工具的输入参数是否清晰、易于理解，直接决定了LLM能否有效使用。

自检

进行上下文工程时，反复确认：

“以当前提供的上下文，LLM真的能合理地完成任务吗？”

这个问题能保持清醒，认识到LLM不是万能的，要为创造条件。同时，有助于区分两种主要的失败模式：

失败模式一：没有提供足够或正确的信息/工具，导致LLM失败。
失败模式二：提供了所有必要的信息和工具，但LLM自身出现了推理错误。

这两种失败模式的修复方案截然不同，准确定位问题是优化的第一步。

应用

优秀的上下文工程实践：

工具使用（Tool Use）：确保必要时能访问外部信息，并为工具设计易于LLM理解的输入参数和输出格式。
短期记忆（Short-term Memory）：持续多轮对话中，动态创建对话摘要，并将其作为后续交互的上下文，防止信息丢失。
长期记忆（Long-term Memory）：当历史对话中包含用户特定偏好时，系统能够自动获取这些信息，并在新对话中加以利用。
提示工程（Prompt Engineering）：提示词清晰地列出智能体应遵循的行为准则和详细指令。
检索（Retrieval）：调用LLM之前，根据用户查询动态地从知识库（如向量数据库）中获取相关信息，并将其注入到提示词中。

两者却不约而同指出：要让多智能体系统稳定运行，有两个关键前提：

Context Engineering（上下文工程）是基础设施级能力
多智能体更适合“读”任务而非“写”任务

结语：别被“智能体数量”迷惑，关键是上下文控制力

Cognition 的告诫并非“多智能体无用”，而是警示其复杂性；
Anthropic 的成功并非“多智能体万能”，而是源于良好的任务拆解与上下文管理；构建多智能体系统不仅是技术挑战，更是“系统工程挑战”。

Cognition

Cognition 团队总结

多 Agent 写作风险: “行为背后是决策，冲突的决策会带来灾难。”
再聪明的模型，若不知上下文，也无法做出正确判断。

读 vs 写，本质区别在哪？

读（Research）型任务：如搜索信息、理解材料等，天然适合并行执行，多个 Agent 各自探索、协同处理即可。
写（Synthesis）型任务：如代码生成、内容撰写，需保持结构统一、语言风格一致，难以拆分并行，否则会产生冲突或碎片化。

Anthropic

Anthropic 实践：

长对话管理：对话可能长达数百轮，需要引入外部记忆与压缩机制，如在每阶段总结信息存储进记忆库、跨阶段切换时唤回关键信息。
任务描述精准化：子智能体需要被明确告知目标、输出格式、所用工具、边界约束，否则容易重复劳动或遗漏重要内容。

底层能力支持

✅ 完整控制 LLM 接收的上下文输入
✅ 无隐藏提示、无强加的“认知架构”
✅ 明确每一步执行顺序，实现灵活编排

Claude Research 系统中：

读取任务：由多智能体并行完成，每个 Agent 负责不同方向
写作任务：由主智能体统一汇总并输出，避免冲突与割裂

模糊指令导致多个 Agent 重复搜索 2025 年半导体供应链，有效的任务拆解机制是防止资源浪费的关键。

Agent 框架核心不是功能丰富，而是给开发者“上下文的完全控制权”。

多智能体系统适合任务：

✅ 高价值任务：计算成本可控，但任务本身价值高（如战略研究）
✅ 广度优先探索：适合多个 Agent 并行发散，如舆情分析、多角度政策解读
✅ 超长上下文任务：任务 token 超过单模型窗口上限时，可用 Agent 分工处理各部分

而在以下场景中，多智能体反而不如单体结构高效：

❌ 强依赖上下文同步、实时响应（如代码协作、系统集成）
❌ 子任务之间依赖复杂、无法并行（如多步骤推理题）

没有通用最佳结构，只有最合适的架构决策。

作者：AI小智

LangChain

LangChain 生态两个核心工具——LangGraph和LangSmith——为实践上下文工程提供了强大的支持。

LangGraph 用于构建可控智能体框架的库。设计理念与上下文工程完美契合，因为赋予了开发者完全的控制权。
LangSmith 是 LangChain 的 LLM应用可观测性（Observability）和评估解决方案。核心功能——调用链路追踪——是调试上下文工程问题的利器。

Cursor

待定

上下文工程指南

上下文工程

资料