做AI开发的朋友，可能都有过这样的经历：为了调出一个满意的结果，反复改提示词，今天加一句“用专业口吻”，明天又改成“说人话”，来回折腾。

但现在风向变了。大家还在研究提示词怎么写的时候，一个更底层的概念已经冒出来了——上下文工程。

说白了，我们不再只琢磨“怎么说AI才听得懂”，而是开始想：给AI一个什么样的环境，它才能干出好活？

尤其是现在AI Agent越来越多，任务也越来越复杂，想让AI自己搞定一件事，上下文工程的重要性就更加明显了。

Anthropic最近发了篇长文讲这个，有兴趣的可以去看看原文。懒得看的，往下看我的总结。

01 为什么上下文这么重要

你可能碰到过这种情况：让AI帮你重构一个代码库，刚开始它答得不错，但做到第三步就开始犯糊涂——不是忘了之前的改动，就是把不相关的东西混在一起。

这不光是模型变笨了，更多是上下文出了问题。

Agent的特殊性：信息会越积越多

对于一问一答这种简单场景，管理上下文还好说。但Agent不是这样的——一个任务往往要经过几十轮甚至上百轮的推理。

Anthropic的Claude Code在处理复杂任务时，平均要调用50次工具。Manus团队的数据也显示，一个典型任务平均也要调用50次工具。这意味着什么？

每一轮都会产生三种信息：

• 工具调用的参数：模型决定调用什么工具、传什么参数

• 工具返回的结果：代码片段、报错信息、文件内容、网络请求结果

• 中间推理过程：模型的思考步骤、做决定的依据

这些信息会不断堆在上下文里。50轮下来，上下文可能膨胀到几万个token——而这还只是一个普通任务的大小。

上下文窗口大不等于没问题

你可能会说：现在的模型上下文窗口不是已经到百万token了吗？

窗口大不代表问题就解决了。虽然前沿模型的上下文窗口越来越大，但随着上下文变长，模型的表现会明显下降。这不是因为容量不够，而是因为废话太多，关键信息被淹没了，模型的注意力被分散了。

这就是Agent开发的核心难题：上下文窗口有限，但运行中产生的信息却不断增长。

有研究专门测过这个现象，叫“大海捞针”测试——在一大堆无关信息里找关键细节。结果发现，随着token数量增加，模型找到准确信息的几率会持续下降。研究人员把这种现象叫做上下文衰减。

大模型看着很厉害，但它其实有个注意力预算——就像人的工作记忆一样，能同时处理的信息量是有限的。每多一个token都在消耗这个预算。

这说明啥？

不做上下文工程，一个普通的多步骤任务就能把模型搞崩。哪怕窗口有一百万token也白搭，上下文衰减是架构层面的硬伤，不是光扩大窗口就能解决的。

02 它和提示词工程到底有啥不同

先搞清楚一个常见的误解：上下文工程不是替代提示词工程，而是它的自然延伸。

关注点变了

提示词工程关心的是“怎么说话”——怎么组织语言、怎么写指令、怎么给例子、怎么设计思考链条。它的核心问题是：“用什么词能让模型听懂？”

上下文工程关心的是“给什么信息”——系统指令、工具定义、外部配置、额外数据、对话历史、动态加载策略……它的核心问题是：“什么样的信息环境最能让模型做出我想要的行为？”

上下文工程包含了一个以前被忽略的关键问题：信息的选择和动态管理。

工作方式完全不同

这两者的区别，不只是范围大小的问题，更是工作方式的根本不同：

• 提示词工程：一次性写好就行，是个静态的活儿

• 上下文工程：每次推理都要重新决定，是个动态的过程

提示词工程是“写好一个提示词，完事”。上下文工程是“每做一次推理，都要想往上下文里放什么”。

一个是静态的措辞优化，一个是动态的信息策展。

为什么这个区别很重要

在早期的LLM应用开发中，大多数场景都是一次性的：情感分析、文本总结、代码生成。这时候提示词工程确实够用了。

但当你做Agent时，情况完全不同。Agent在循环里跑，每一轮都会产生新数据，这些信息“可能”和下一轮推理有关。你需要不断决定：哪些留着、哪些扔掉、哪些需要临时加载。

这就像开一家图书馆：提示词工程关心的是怎么写借书规则，而上下文工程关心的是图书馆里放什么书、怎么分类、怎么根据读者需求随时推荐。

Agent越复杂，后者的重要性就越高。

03 到底什么是上下文工程

定义：管理大模型的工作记忆

上下文工程，简单说就是管理大模型工作记忆的一套方法。

要理解这点，先要搞清楚大模型的信息来源。模型在推理时能用的信息只有两个：

• 参数知识：训练时学到的，推理时没法改

• 上下文窗口：当前输入的内容，这是我们唯一能控制的

上下文工程本质上是在搭建大模型的工作记忆——它决定了模型能“看到”什么、靠什么做决定。

你可以把上下文想象成一块黑板：

• 黑板上写的是各种信息（指令、数据、历史记录）

• 黑板空间有限（上下文窗口限制）

• 写得太满，重点就被淹没了（注意力稀释）

所以上下文工程的核心问题不是“这句话怎么写”，而是“哪些信息值得放进去”。

核心原则：最小的高信噪比集合

Anthropic给过一个精炼的定义：上下文工程的目标是找到最小的高信噪比token集合，让结果最有可能达到预期。

拆开看：

• 最小：不是越多越好，而是够用就行

• 高信噪比：信息密度高，废话少

• token集合：以token为单位衡量，因为模型的注意力预算就是按token算的

一个具体例子

假设你要让AI重构一个复杂的代码库：

错误做法：把几百个文件的代码片段全塞进去。结果？模型被细节淹没了，抓不住重点。

正确做法：只放三个关键信息：

• 当前遇到的核心问题是什么

• 重构的目标是什么

• 有什么限制条件（不能动的接口、依赖关系等）

模型反而能给出更清楚、更有针对性的方案。

这就是上下文工程的基本道理：少就是多。

04 到底怎么做？四大核心技术

理论说了一堆，来看怎么落地。我结合Anthropic的文章和业界的做法，总结了四个技术方向。

一、基础层：上下文组件设计

在谈高级技术之前，先确保基础组件设计合理。

1. 系统提示

写系统提示就像调收音机，要找到那个“刚刚好”的位置：

• 调太低（过于具体）：硬写一堆if-else逻辑，提示词又臭又长。稍微变个场景就不好使，维护起来想死。

• 调太高（过于笼统）：说什么“请专业地完成任务”，模型听完一脸懵——到底啥叫“专业”？

• 刚刚好：给清楚目标和限制，但别把每一步都规定死。让模型有发挥空间，又能按你期望的方向走

实践建议：

• 用XML标签或Markdown标题组织不同部分（<背景>、<指令>、## 工具使用指引等）

• 从最简单的提示开始测，根据哪里出错再逐步加指令和例子

• 最小不等于最短，要提供足够的前置信息确保行为正确

2. 工具设计

工具是Agent与环境的契约，设计原则：

• 功能聚焦：每个工具职责清楚，功能重叠越小越好

• 自包含：像设计好的代码函数一样，稳定、明确

• 参数描述：输入参数要描述清楚、没有歧义，发挥模型本身的优势

常见问题：工具集太臃肿，覆盖太多功能或者让模型不知道该选哪个。如果人类工程师都判断不了该用哪个工具，AI也不行。

3. 示例选择

少样本示例仍然是很推荐的做法，但要注意：

• 不要：塞一堆特殊情况，试图覆盖所有规则

• 要：挑多样、典型的例子，清楚展示想要的行为

• 对LLM来说，示例就是“胜过千言”的图片

二、运行时层：动态上下文检索

核心思想：不要一开始就把所有数据加载进去，让Agent按需获取。

即时加载

与其事先把所有相关数据塞进上下文，不如让Agent只保留轻量级的标识符（文件路径、查询语句、网络链接等），在运行时通过工具动态加载。

案例：Claude Code处理大型代码库时，不提前加载所有文件，而是提供grep、glob、read等工具。模型需要哪个文件，就现场搜、现场读。这样还能避免索引过时的问题。

渐进式披露

让Agent通过探索逐步发现相关上下文：

• 文件大小暗示复杂程度

• 命名规则暗示用途

• 时间戳可以代表相关性

Agent一层层构建理解，只在工作记忆里保留必要的内容。

混合策略

最有效的Agent往往采用混合策略：

• 预先拿一些数据保证速度（比如CLAUDE.md文件）

• 同时保留自己探索的能力（比如glob、grep工具）

• “正确”的自主程度取决于任务本身

三、长程任务层：突破上下文窗口限制

对于跨越几分钟到几小时的任务（比如大型代码库迁移、综合研究项目），需要专门技术来绕过上下文限制。

1. 压缩

当对话快接近上下文窗口限制时，总结内容并用摘要重新开始新窗口。

实现方式：

• 把对话历史传给模型，让它总结最关键的信息

• 保留：架构决定、没解决的bug、实现细节

• 丢掉：重复的工具输出、已经处理过的消息

案例：Claude Code会自动压缩历史对话，保留摘要加上最近访问的5个文件，用户完全感觉不到上下文已经“重启”了。

调优建议：

• 先保证召回率（确保抓到所有相关信息）

• 再反复提高精确率（去掉多余内容）

• 最安全的轻量级压缩：删掉历史深处的工具调用结果

2. 结构化笔记

Agent定期把笔记写下来，放到上下文窗口之外，需要的时候再拿回来。

案例：Claude玩宝可梦时，在几千步的游戏里保持精确计数——走了多少步、宝可梦升了几级、解锁了哪些成就、战斗策略笔记。上下文重置后读取笔记就能继续几个小时的训练过程。

本质：用最小的开销提供持久记忆，相当于给AI接了一个无限大的外存。

3. 子Agent架构

主Agent负责整体计划，子Agent用干净的上下文窗口处理专门的任务。

工作流程：

• 子Agent深入技术工作，可能用几万个token去探索

• 只返回压缩、提炼后的摘要（通常1000-2000 token）

• 详细的搜索上下文留在子Agent内部，不污染主上下文

案例：Manus采用规划器+知识管理器+执行器的架构，实现关注点分离。

三种技术的选择：

• 压缩：需要大量来回交互的任务，保持对话流畅

• 笔记：有明确节点的迭代开发

• 子Agent：复杂研究和分析，同时探索能带来好处

四、优化层：成本控制与性能

提示缓存

把稳定的系统指令和工具定义放在前缀位置，启用缓存重复利用KV表示。

效果：Anthropic数据显示，启用缓存后可以降低90%的输入成本。

做法：

• 稳定部分（系统提示、工具定义）放在最前面

• 变化部分（用户消息、历史记录）追加在后面

总结：如何选择

记住一个原则：怎么简单怎么来，管用就行。模型能力越来越强，需要的花活会越来越少。但不管技术怎么变，把上下文当成稀缺资源来看待，这个核心思想不会过时。

最后看下Anthropic的总结

上下文工程代表着做LLM应用的方式正在发生根本转变。模型能力越强，挑战越不是“怎么写提示词”，而是“怎么安排信息进入模型的注意力预算”。不管是压缩长任务上下文、设计省token的工具，还是让Agent即时探索环境，核心原则都一样：找到最小的高信息密度集合，让结果最有可能达到预期。

这些技术会随模型进化而改变。更聪明的模型需要更少的人为预设，Agent能跑得更自主。但不管模型多强，把上下文当稀缺资源对待，始终是做出可靠Agent的关键。

本文内容仅供个人学习、研究或参考使用，不构成任何形式的决策建议、专业指导或法律依据。未经授权，禁止任何单位或个人以商业售卖、虚假宣传、侵权传播等非学习研究目的使用本文内容。如需分享或转载，请保留原文来源信息，不得篡改、删减内容或侵犯相关权益。感谢您的理解与支持！

链接: https://fly63.com/article/detial/13517