搞懂上下文工程（Context Engineering)，让你的LLM更聪明

我们可能早已习惯了“提示词工程”（Prompt Engineering）。不论是写摘要、代码生成，还是会议复盘，大家都想着如何写出一个高效的提示词，让LLM做出回答。但有时候大模型回答的结果并不是尽人意。

所以，最近有个新词开始频繁出现在圈内讨论中——“上下文工程”（Context Engineering）。

这个词乍一看和“提示词工程”貌似差不多，但如果你是在构建一个智能体（AI Agent）系统，特别是基于像 LlamaIndex、LlamaCloud 这样的工具时，你会发现：你写得再好的提示词，也比不上一次精心设计的上下文填充。

什么是上下文工程？它和提示词工程到底有什么不同？

我们都知道，大模型的“工作记忆”——也就是所谓的“上下文窗口”——是有限的。你想让它准确理解、判断和执行任务，必须把最相关、最有价值的信息放进这段上下文里。

这就是“上下文工程”的核心：不仅要喂信息，还要喂对的信息、喂得巧、喂得精。

而“提示词工程”更多是在设计指令的语言方式——比如你是说“请写一篇总结”，还是“像公众号一样写一篇总结”。它关注的是“怎么说”，而上下文工程则关注“说什么”和“说多少”。

来自 Andrey Karpathy 的一句话总结得很好：

“提示词只是你日常用来对大模型发出请求的文字描述，但在真正的工业级 LLM 应用中，上下文工程才是真正的艺术与科学。”

一个 Agent 的「上下文」到底包括什么？

这部分是重头戏。参考 Philipp Schmid 的观点，再结合 LlamaIndex 团队的实战经验，我们可以将一个 AI Agent 的上下文来源划分为以下几类：

1. 系统指令：为 Agent 定义角色和任务范畴；
2. 用户输入：用户的提问、请求、任务说明；
3. 短期记忆（对话历史）：让模型记住前面发生了什么；
4. 长期记忆：保存过去交互、知识点或关键信息，可随时检索；
5. 知识库检索信息：基于向量数据库、API 或其他来源抓取补充内容；
6. 工具及其定义：告诉大模型可以用哪些外部能力；
7. 工具调用结果：上一轮工具执行返回的具体内容；
8. 结构化输出：标准格式的数据结构，可作为输入或输出；
9. 全局状态/上下文：Agent 跨步骤共享的“草稿板”信息。

看到这里你可能会问：这不就是 Retrieval-Augmented Generation（RAG）吗？确实，RAG 是上下文工程的重要一环。但上下文工程不仅仅是“检索”，它关心的是：怎么选、怎么排、怎么裁剪这些上下文。

做好上下文工程，你得解决这3个关键问题

1️⃣ 如何选出“对”的上下文？

构建智能 Agent 时，很多人习惯一股脑把所有内容丢进去：知识库、文档、历史对话……然后让模型自己“看着办”。

但上下文窗口不是无底洞！你必须问自己两个问题：

• 现在这个任务，需要哪些信息？
• 哪些是“可选但冗余”的背景，能不放就不放？

比如，在多知识源场景下，我们不仅要考虑是否使用知识库，还要想清楚该用哪个库，是需要法律知识、用户FAQ，还是实时数据查询？甚至告诉模型“有哪些工具可用”本身也是一种上下文补充。

2️⃣ 如何压缩有限的上下文窗口？

LlamaIndex 中已经广泛采用了上下文压缩（Compression）策略，尤其体现在两点：

• 摘要化（Summarization）：检索结果太多？先用摘要技术压缩内容，再填入模型。
• 排序机制（Ordering）：信息太多？那就按时间、重要性、相关度排序，放前面的优先处理。

例如以下 Python 函数中，检索返回结果后会根据时间戳筛选和排序，确保先提供最新、最相关的内容：

def search_knowledge(query: str) -> str:
    nodes = retriever.retrieve(query)
    sorted_and_filtered_nodes = sorted(
        [item for item in data if datetime.strptime(item['date'], '%Y-%m-%d') > cutoff_date],
        key=lambda x: datetime.strptime(x['date'], '%Y-%m-%d')
    )
    return "\n----\n".join([n.text for n in sorted_and_filtered_nodes])

3️⃣ 如何管理长期记忆？

一个 Agent 想要持续“成长”，就不能是短期记忆金鱼。LlamaIndex 提供了多种可组合的记忆模块，比如：

• VectorMemoryBlock：用向量方式存储对话；
• FactExtractionMemoryBlock：提取对话中的事实；
• StaticMemoryBlock：写死的关键信息或配置项。

这让开发者可以根据不同任务自由组合记忆组件，打造更智能、更长效的 Agent。

Bonus：结构化输出与流程工程，也是上下文工程的好搭档

很多人容易忽略一点：结构化信息其实是上下文工程的“压缩利器”。

• 向模型请求结构化结果（如 JSON schema）时，相当于对输出设定边界和方向；
• 提供结构化输入时，也能极大减少噪声，让模型更聚焦。

LlamaCloud 推出的 LlamaExtract 工具，就是专为结构化提取而生。你可以从长文档中提取关键信息，然后作为“浓缩版上下文”提供给后续 Agent 使用。

另一方面，**Workflow Engineering（流程工程）**与上下文工程并驾齐驱。它允许我们把一个复杂任务拆分为多个步骤，每一步都可以设计独立的上下文输入，避免一次性灌入全部信息。

这背后的洞察是：大多数 AI Agent 其实就是流程编排器（Workflow Orchestrator）。只不过有的人清楚自己在编排，有的人还在靠直觉“堆料”。

写在最后：我们为什么要重视上下文工程？

原因很简单：这是你构建靠谱 Agent 的关键。

如果说提示词工程是艺术，那上下文工程就是建筑结构。如果你喂错了料，哪怕再聪明的模型也帮不了你；但如果你把该放的信息都放对地方，那模型甚至可以帮你搭出一整套自动化智能系统。

尤其是在 RAG 系统、Agent 应用、流程协作类任务越来越普及的今天，我们不仅要学会问“用哪个模型”，更要学会问“该放什么进模型”。

所以，下次再觉得模型“不懂你”的时候，不妨换个角度想：

它不是“笨”，只是你给它的上下文，错了。