文章开篇点题:过去几年,应用 AI 领域的焦点是提示词工程——研究如何措辞才能让模型给出最优输出。但随着我们从「单次分类/生成任务」走向「多轮推理、长时程运行的 agent」,关键问题已经变了。原文的问法是:
"What configuration of context is most likely to generate our model's desired behavior?"
(什么样的上下文配置,最有可能引导出模型的期望行为?)
文章给出两个概念的精确定义:提示词工程(prompt engineering)指「为获得最优结果而编写和组织 LLM 指令的方法」(methods for writing and organizing LLM instructions for optimal outcomes);上下文工程(context engineering)指「在 LLM 推理过程中,持续筛选和维护最优 token(信息)集合的策略」(strategies for curating and maintaining the optimal set of tokens during LLM inference)。
关键区别在于范围和时态:提示词主要指 system prompt 怎么写,是一次性的「离散任务」;而上下文涵盖推理时模型看到的一切——系统指令、工具定义、MCP、外部文档、消息历史、工具返回结果。文章配了一张对比图,图的结论是:提示词工程是写好一段话就结束,而上下文工程是迭代式的——「每一次决定要传什么给模型时,筛选(curation)阶段都会重新发生一遍」(the curation phase happens each time we decide what to pass to the model)。agent 每循环一轮,就产生一批新信息(工具输出、中间结论),你必须持续决定什么进窗口、什么被丢弃。可以说,上下文工程是提示词工程在 agent 时代的自然演进和超集。
这一节是全文的理论地基,回答「为什么不能把所有信息一股脑塞进上下文」。
文章引用「大海捞针(needle-in-a-haystack)」类基准测试的研究结果,提出上下文腐烂(context rot)这一现象:随着上下文窗口中 token 数量增加,模型准确回忆窗口内信息的能力会下降。也就是说,同一条信息,放在 5K token 的上下文里模型能精准利用,埋在 150K token 里就可能被「忘掉」或用错。这不是某个模型的 bug,而是所有 LLM 的共性,只是程度不同。
文章从三个层面解释了成因,这部分是理解一切上下文技巧的物理基础:
文章强调,这些因素叠加造成的是「性能梯度而非断崖」(a performance gradient rather than a hard cliff)——长上下文下模型仍然可用,只是精度渐进式滑坡,这也是为什么问题容易被忽视。
基于上述机制,文章提出一个核心隐喻:如同人类的工作记忆有限,LLM 在解析上下文时也有一个注意力预算(attention budget),每新增一个 token 都会消耗一部分预算。由此得出全文最重要的一句话:
"Context, therefore, must be treated as a finite resource with diminishing marginal returns."
(因此,上下文必须被视为一种边际收益递减的有限资源。)
而好的上下文工程的定义也随之导出:找到「能最大化期望结果概率的、尽可能小的高信号 token 集合」(the smallest possible set of high-signal tokens)。这一句是全文的纲领,后面所有技术都是它的推论。
这一节把「最小高信号集」原则落到上下文的三大组成部分上。
文章说好的 system prompt 处于两种常见失败模式之间的「金发姑娘区间」(the Goldilocks zone between two common failure modes):
最优点是:具体到足以有效引导行为,又灵活到只提供强启发式(strong heuristics)而非僵硬规则。文章配的第二张图展示了这个校准光谱,一端是「脆弱的 if-else 硬编码提示词」,另一端是过于空泛的提示词,好的 prompt 在中间。
操作层面的建议:
<background_information>、<instructions>、## Tool guidance、## Output description,用 XML 标签或 Markdown 标题分隔。不过文章也坦承,随着模型能力提升,确切格式「可能正变得不那么重要」。工具定义了 agent 与其信息空间、行动空间之间的「契约」。文章的要求是:
"Tools should be self-contained, robust to error, and extremely clear with respect to their intended use."
(工具应当自包含、能容错,并且用途极其清晰。)
就像设计良好的代码库中的函数:输入参数命名要描述性强、无歧义;返回的信息要 token 高效(不要把 10 万行原始数据当工具结果吐回来);同时要能鼓励高效的 agent 行为。最常见的失败模式是臃肿的工具集——工具太多、功能重叠,导致「该用哪个工具」的决策点模糊。文章给出一条非常好记的判断标准:
"If a human engineer can't definitively say which tool should be used in a given situation, an AI agent can't be expected to do better."
(如果一个人类工程师都无法明确说出某个场景该用哪个工具,就不能指望 AI agent 做得更好。)
此外,精选一个最小可行工具集,也让长对话中的上下文维护和修剪更容易。
Few-shot 示例仍是强烈推荐的最佳实践,但文章明确反对一种常见做法:把一大堆边缘案例(a laundry list of edge cases)塞进提示词、试图穷举每一条规则——「我们不推荐这样做」(We do not recommend this)。正确姿势是精选一组多样且典范的示例(diverse, canonical examples),让它们有效地「演示」agent 的预期行为。文章用了一个妙喻:
"For an LLM, examples are the 'pictures' worth a thousand words."
(对 LLM 而言,示例就是那张「胜过千言万语的图」。)
这一节先给了一个极简的 agent 定义——「在循环中自主使用工具的 LLM」(LLMs autonomously using tools in a loop),然后讨论 agent 如何获取信息。
传统 AI 应用普遍在推理前用 embedding 检索把相关内容预先塞进上下文(典型的 RAG 流水线)。文章指出,领域正在转向即时检索(just-in-time retrieval)策略:agent 不预载数据本体,只维护轻量级标识符——文件路径、存储的查询、网页链接等——在运行时按需通过工具把数据动态加载进上下文。
一个具体例子:Claude Code 分析大型数据文件时,并不把整个数据对象读入上下文,而是编写针对性的查询、把中间结果存下来、用 head、tail 这类 Bash 命令只看需要的片段。这与人类认知方式同构:我们不会背下整个语料库,而是靠文件系统、收件箱、书签这些外部索引系统按需取用。
即时检索的一个副产品是:元数据本身就携带信号。tests/ 文件夹里的 test_utils.py 和 src/core_logic/ 里的同名文件,用途暗示完全不同;文件大小暗示复杂度,命名约定暗示用途,时间戳可以作为「相关性」的代理指标。agent 通过一层层探索,渐进式(progressive disclosure)地组装起对任务的理解——每次探索的结果决定下一步看什么,始终只保留工作记忆中真正相关的部分。
文章诚实地给出局限:运行时探索比预取慢,且需要精心的工程设计——工具不好用时,agent 会误用工具、追死胡同、浪费上下文。所以实践中往往是混合策略:Claude Code 把 CLAUDE.md 文件「不加处理地直接放进上下文开头」(naively dropped into context up front),同时用 glob、grep 这类原语做即时检索——顺带绕开了向量索引会过期、语法树解析复杂的问题。文章的工程建议朴素而有力:「做能起作用的最简单的事」(do the simplest thing that works)。
当任务时长超出单个上下文窗口能容纳的范围(几十分钟到数小时的连续工作),就需要专门技术。文章给出三种,并各配了一手案例。
机制:当对话逼近上下文窗口上限时,让模型把消息历史总结压缩,然后用这份摘要开启一个新的上下文窗口继续工作。
Claude Code 的实现:压紧时保留「架构决策、未解决的 bug、实现细节」(architectural decisions, unresolved bugs, and implementation details),丢弃冗余的工具输出;然后 agent 带着压缩后的上下文、外加最近访问的五个文件继续干活——用户感知上对话没有断。
取舍的艺术:原文说「压紧的艺术在于选择保留什么、丢弃什么」(the art of compaction lies in the selection of what to keep versus what to discard)。过于激进的压缩会丢失「微妙但关键的上下文」(subtle but critical context)——其重要性往往事后才显现。调优路径:先最大化召回率(确保重要信息都留下),再迭代提升精确度(逐步剔除冗余)。文章还点出一个最安全、最轻量的压紧形式:清除旧的工具调用结果(tool result clearing)——一个工具几十轮前返回的原始输出,大概率不再需要,这一能力已在 Claude Developer Platform 上作为功能推出。
机制:agent 定期把笔记持久化到上下文窗口之外(写文件),需要时再拉回上下文——以极小的开销获得持久记忆。Claude Code 的 to-do 列表、自定义的 NOTES.md 都是这个模式。
Claude Plays Pokémon 的例子(全文最生动的案例):让 Claude 玩宝可梦游戏时,agent 在数千步游戏操作中依靠笔记维持精确状态——比如记录「过去 1,234 步我一直在 Route 1 训练宝可梦,皮卡丘已升 8 级,目标是 10 级」这样的进度。没有任何关于记忆结构的提示,它自行发展出了:绘制已探索区域的地图、记录已解锁的关键成就、维护对战策略笔记。上下文重置后,agent 读取自己的笔记,就能无缝继续长达数小时的训练序列或迷宫探索。这说明持久化笔记 + 上下文重置的组合,能把 agent 的有效工作时长从「一个窗口」扩展到「任意长」。
机制:主 agent 手持高层计划做协调,把聚焦的探索任务派给拥有全新干净上下文窗口的专门子代理。关键在于信息的不对称压缩:每个子代理探索时可能烧掉数万 token,但只向主代理返回一份压缩提炼的摘要,「通常 1,000–2,000 token」。这实现了关注点分离(separation of concerns):详细的搜索过程被隔离在子代理内部,主 agent 的上下文只装结论,专注于综合分析。文章提到,在复杂研究任务上,这种架构相比单 agent 系统有显著提升(可参见 Anthropic 的多代理研究系统一文)。
| 技术 | 适用场景 |
|---|---|
| 压紧(compaction) | 需要大量来回对话、必须保持对话连续流的任务 |
| 结构化笔记(note-taking) | 有清晰里程碑的迭代式开发(如长期编码任务) |
| 子代理(sub-agents) | 并行探索有回报的复杂研究与分析任务 |
文章的结论把主题拔高为一次范式转变:构建 LLM 应用的挑战,不再只是打磨一段完美的提示词,而是在每一步推理时,精心策划哪些信息进入模型有限的注意力预算。核心指导原则始终是那一句:「找到最大化期望结果概率的最小高信号 token 集」。
展望部分给了一个诚实的动态判断:随着模型变得更聪明,需要的「规定性工程」会越来越少——agent 将更自主地管理自己的上下文。但即使模型能力继续扩展:
"Treating context as a precious, finite resource will remain central to building reliable, effective agents."
(把上下文当作珍贵、有限的资源来对待,仍将是构建可靠、有效 agent 的核心。)
局限与注意:文章本身也承认了几处边界——即时检索比预取慢,工程不到位反而让 agent 浪费上下文;压紧激进了会丢关键信息;文中方法多来自 Anthropic 自家产品(Claude Code、Pokémon 实验、多代理研究系统)的经验,具体参数(如「最近五个文件」「1,000–2,000 token 摘要」)是经验值而非普适定律,迁移到你的场景时需要自己重新调优。