学习笔记——大模型Context Engineering：LLM 时代的输入优化哲学

💡

Context Engineering（上下文工程）是近年来人工智能领域兴起的一个关键概念，它不关注模型本身的训练，而是专注于如何优化提供给大型语言模型（LLM）的输入内容，以实现更高的效率、准确性和更低的成本。

基础概念：Context 与 Context Window

要理解上下文工程，首先需要明确其核心对象：上下文（Context）和 上下文窗口（Context Window）。

Context（上下文）的定义

Context 指的是大型模型的输入内容。

这些输入内容范围广泛，包括但不限于：

用户的提问

背景信息和相关资料

可用的工具列表

工具执行的结果

历史对话记录等

模型会将这些输入作为上下文，并基于这些内容来生成最终的答案。

Context Window（上下文窗口）及其限制

Context Window 是指模型输入中最多能够包含的 token 数量限制。

Token 的理解： Token 可以理解为文本被拆分成的最小单位，它可能是一个字、一个词，或是一个标点符号。

Token 与字符/单词的换算： 一个 token 大概相当于 0.75 个单词或 1.5 个汉字。

一旦输入的 token 数量超过 Context Window 的限制，模型会丢弃前面的内容，只保留最后的一部分（例如，保留最后的 100 万个 token）。

主流模型的 Context Window 大小示例：

模型名称	Context Window 大小	备注
Gemini 2.5 Pro	100 万 token	容量巨大，接近七本书的长度。
GPT-5	40 万 token	相对较大的容量。
Cloud 4	20 万 token	属于优秀模型容量。
Deep V3	12.8 万 token	中等规模容量。
小型模型	几万 token	许多时候为了节约成本会使用，容量非常有限，可能装不下一本产品手册。

Context Engineering 产生的背景：三个现实问题

尽管如 Gemini Pro 这样的大模型拥有百万级的 Context Window，但事实证明，直接将所有资料不加筛选地丢给模型是 行不通的。

为了让模型能够稳定、高效、准确地输出内容，我们必须解决以下三个现实存在的挑战：

Context Window 限制是常态

虽然市面上有容量惊人的大模型，但大多数模型的 Context Window 仍然非常有限。

出于成本考量，许多产品化应用会使用 Context Window 只有几万 token 的小型模型。

这些小模型可能连一本产品使用手册都无法完整装入。

输入杂乱影响模型理解

即使我们使用的模型拥有非常大的 Context Window，并且输入量没有超过上限，也最好不要将所有资料不加筛选地全部丢给模型。

问题所在： 未经筛选的输入内容可能会非常杂乱、冗余，甚至相互矛盾。

结果： 模型容易混淆重点，最终输出含糊不清的回答。

优化目标： 应该通过精心的设计和组织，确保模型看到的是准确、有结构、重点突出的内容。

输入越多，成本越高

大语言模型的调用成本基本是按照 token 计费的。

成本消耗： token 数量越多，消耗就越大。

优化必要性： 如果不加控制地塞入大量上下文内容，即使效果尚可，也会带来不必要的开销。

核心理念： 优化输入就是优化成本，这在产品化和大规模使用时尤其重要。

Context Engineering 的核心理念与兴起原因

Context Engineering 的定义与目标

Context Engineering 翻译成中文就是上下文工程。

关注点： 它关注的不是如何训练模型，而是如何精心设计给模型的输入内容。

核心目标： 不改变模型结构，只改变模型看到什么（即优化模型的输入）。目的是让模型在有限的 Context Window 里面，尽可能地实现 理解得更准、答得更好、花得更少。

Context Engineering 兴起的两大驱动力

Context（上下文）的概念一直都存在，但 Context Engineering 这个词汇近来才活跃起来，主要是由以下两点原因驱动：

现有模型的强大性

现在的模型已经足够强大。在大部分情况下，如果模型回答不满意，并非是模型不够强，而是用户没有给到模型足够清晰和完整的输入信息。

这进一步证实了对输入信息进行工程化设计（即 Context Engineering）的必要性。

Agent（智能体）的兴起

Agent 是一种结合了大模型和工具的技术，能够让模型独立感知和影响环境。

Agent 运行特点： Agent 的运行涉及到模型对工具的使用。可用工具信息和工具执行结果等一系列内容都会被放入模型的输入中。

Context 消耗： 随着 Agent 运行时间的增长和工具使用次数的增加，这些执行结果会迅速占满整个 Context Window，从而影响模型后续的回答效果。

重要性凸显： 因此，上下文（Context）的管理效果直接影响到 Agent 的执行结果。

Context Engineering 的四大实现方法体系

Context Engineering 并非某项单一的具体技术，而是由多种技术组成的方法体系。该体系可划分为四个核心类别：

保存 Context（信息持久化）

目标： 解决信息持久化的问题。

操作方式： 将上下文信息进行筛选、总结，并保存在内存或硬盘等存储介质中。在模型需要时，再将这些信息发送给模型。

典型例子： GPT 的记忆功能。系统可以将用户在聊天过程中提供的信息（如用户名称、频道内容等）存入记忆库中。

选择 Context（最核心技术）

目标： 从海量信息中精准选择出与用户问题最相关的内，放入模型的 Context Window。

重要性： 好的选择策略是整个系统高效准确运行的保障。

静态选择

定义： 将一些永远重要、必须遵守的信息，在每一次请求时都全部放入上下文。

特点： 它们类似于给 AI “焊在脑子里的系统指令或核心原则”。

策略： 对这类小但至关重要的信息，最有效的策略就是**“全都要”**，只要确保它们加起来不会撑爆 Context Window 即可。

例子： Cursor 的 rules 文件或 Cloud Code 的 cloud.md 文件，它们指定了项目信息和编码规范等至关重要的信息。

动态选择

定义： 像一个聪明的图书馆管理员，为用户精准地找到需要的特定信息。它选择与用户问题最相关的定制化内容。

例子：

GPT 从记忆库中挑选与用户问题最相关的记忆。
从包含数十个工具中挑选出最相关的少数工具扔给模型。

最有名实现方式： RAG (Retrieval-Augmented Generation)。

压缩 Context

目标： 解决历史消息（特别是 Agent 运行过程中产生的工具执行结果和模型输出文本）迅速占满 Context Window 的问题。

操作方式： 对历史消息进行总结（压缩），然后丢弃原来的冗余内容。

典型例子： Cloud Code 的 Auto-Context 程序。

当 Context Window 的使用量超过 95% 时，该程序便会对以往的上下文进行压缩（总结）。
用户甚至可以在 cloud.md 文件中指定压缩方案，例如重点保留输出和代码改动方面的内容。

隔离 Context

目标： 确保不同模块之间的上下文互相隔离、互不干扰。

典型应用场景： Multi-Agent（多智能体）系统。

典型例子： Anthropic 构建的 Multi-Agent 研究系统。

架构： 系统内有一个 Lead Agent 负责任务下发和归纳总结。
隔离性： 下发的 Sub-Agents（例如负责搜索 PDF、网络或图片的 Agent）拥有自己独立的工具、运行历史和记忆体系。这几个 Sub-Agent 的上下文是互相隔离、互不影响的。

总结

Context Engineering 是一门关于如何设计和管理模型输入的工程技术，它的核心在于通过“保存、选择、压缩、隔离”这四大手段，确保模型在有限的 Context Window 内获得最精准、简洁、高效的信息，从而达到更好的性能和更低的运行成本。

核心回顾：

概念	含义
Context	模型的输入内容
Context Window	模型输入容量上限（以 token 数量为单位）
Context Engineering	设计输入内容，实现理解更准、答得更好、花得更少

实现 Context Engineering 的四大角度：

保存 Context： 解决信息持久化。

选择 Context： 确保输入内容的精准和相关性（包含静态和动态选择，如 RAG）。

压缩 Context： 解决 Agent 历史消息导致的上下文溢出（如总结历史信息）。

隔离 Context： 确保多模块系统（如 Multi-Agent）中，不同 Agent 的上下文互不干扰。

Context Engineering 的本质，就像是给大模型的“消化系统”安装了一个高效的“信息过滤器”和“智能缓存系统”。它不是去增强模型本身的“消化能力”，而是确保送进去的“食物”是营养最丰富、最容易吸收、分量最合适的，从而让模型能够以最小的成本，产出最好的结果。