AI Harness 上下文工程：你可能只看到了冰山一角

人们总把 prompt 理解成日常那种给模型的一段任务描述——那是把一件复杂的事严重轻描淡写了，真正在工业级的应用里，你是在精心地构建上下文，让模型去解决你的定制任务。

提示词工程 ⊂ 上下文工程 ⊂ Harness 工程，逐层递进，而上下文工程，依然是AI Harness 工程里最容易被忽略、却最要命的一层。

当 OpenAI 联合创始人 Andrej Karpathy 公开表示：上下文工程优先于提示工程时，他不是在做名词上的争论，他指出的是我们思考大模型时的根本性转变。

正如他所说，上下文工程是：用恰到好处的信息，填满上下文窗口的精妙艺术和科学，以便下一步行动。

AI Agent 上下文工程，是一套系统性的开发方法论，它要做的，不是给 AI 丢一句提示就完事，而是围绕一个目标，搭起一群各司其职的代理，有的负责把该用的信息检索进来，有的负责组装成清晰的上下文，有的负责让上下文随时保持干净。

这些 AI Agent 一刻不停地消费信息、修正信息、再依据结构化的上下文行动，最终产出的是能上生产、可复现的稳定结果。

上下文工程的实际含义

先厘清一个最容易被混淆的点。

提示工程，是写一个巧妙的问题，上下文工程，是设计一整个信息系统，决定模型在生成每一个 token 之前，究竟看到什么。

Anthropic 的工程团队发布过一篇堪称这个领域权威的指南，它给上下文下了一个精确的定义：上下文是从大模型采样时被包含的 token（词元）集合；

而工程挑战，则是在 LLM 的固有限制下，优化这些 token 的效用。

这个定义，一下子把视角从怎么写话，拉到了怎么管信息。

更直白一点：提示工程关注的是单个请求里的那几个词，上下文工程塑造的是围绕这些词的一切。

一个是在写一道好考题，另一个是在考试开始之前，就把完整的学习指南、参考文献、工具全部准备好——甚至还要决定，哪些资料不允许带进考场。

上下文窗口里的每一个 token，都在争夺模型的注意力，token 越多，模型反而越容易走神——它会迷失在中间，忘掉关键信息，输出质量不升反降。

Anthropic 把这种现象叫作上下文腐烂（context rot）：随着 token 增加，模型准确召回信息的能力在下降。

所以上下文工程的第一性原理是：不是把窗口填满，而是用最少的、最高信号的 token，换来最稳的输出。

提示词工程写的是题目，上下文工程设计的是考场——包括考场上放什么资料、不放什么资料。

上下文工程 VS 提示词工程

两者的区别，用一张表就能看清：

最关键的差异，在失败模式这一行，提示工程失效，顶多是输出不对

而上下文工程失效，是整个系统崩掉，业界把后者的失败归纳成四种

提示词工程是术，上下文工程是道，前者在单个请求里较劲，后者在设计整个信息环境

上下文工程的三大核心能力：检索、组装、管理

上下文工程拆开看就是三件事：检索、组装、管理，它们分别回答三个问题。

第一，检索（Retrieval）——决定把什么拉进来。 

上下文窗口是有限的，所以不能什么都放。

检索解决的是此刻最该有哪些信息：按相关性捞取文档、只加载当前任务需要的工具、按需取用外部数据，核心原则是宁缺毋滥，只把真正相关、真正高信号的内容拉进来。

第二，组装（Assembly）——决定这些东西怎么排。

信息拉进来了，还要排好。

顺序、结构、分隔，都直接影响模型的理解，关键信息放在注意力最强的地方（开头和结尾）；

用 XML 标签或 Markdown 标题把指令和数据隔离；工具定义、历史记录、检索结果各归其位。

组装的目标，是让模型一眼就能分清什么是任务、什么是资料、什么是约束。

第三，管理（Management）——决定什么该留、什么该走。 

上下文是活的，会随着多轮交互不断膨胀。

管理解决的是生命周期问题：什么时候压缩历史、什么时候清理过期的工具结果、什么状态该外置到窗口之外，管理的目标，是让上下文始终保持在最精简的高信号状态。

三根支柱合起来，一句话：检索决定进什么，组装决定怎么摆，管理决定留多久。

上下文工程的压缩策略

上下文是有限的，但多轮交互会不断往里塞东西——工具返回、中间结论、失败记录，越堆越多，压缩策略解决的，就是怎么把膨胀的上下文，重新压回高信号状态。

在 AI Harness 的实现里，压缩不是一刀切，我们设计四种如下策略。

策略一，不压缩（none）。 

什么都不做，原样返回，适合短会话、或你确定上下文不会超的场景。

策略二，滑动窗口（sliding_window）。 

默认策略，它维护一个压力值，一旦上下文超载（压力超过 1.0），就从最旧的、没被固定的消息开始，一条条丢掉，直到压力回到安全线以内。

策略三，摘要（summarize）。 

不丢消息，而是调用 LLM，把最旧的那批消息（大约前 40%）压成一段摘要，替换成一条系统消息放在对话最前头，既省了 token，又保住了之前发生了什么的线索。

策略四，混合（hybrid）。

平时走滑动窗口，压力一旦超过阈值（默认 80%），就升级到摘要，兼顾了滑动窗口的轻量，和摘要的信息保留。

三种策略的核心逻辑，用语言无关的伪代码表示，大致是这样，先约定两个前提：messages 是按时间先后排好的列表，越靠前越旧；pinned 是被固定、不能丢弃的消息，比如身份和关键规则。

# 滑动窗口：超载时，从列表最前面（最旧）开始，丢掉第一条未被固定的消息
compact_sliding(messages, pinned, pressure):
while pressure > 1.0:
oldest = messages 里第一条未被 pinned 的消息
if 找不到: break
移除 oldest
return messages

# 摘要：把最旧的一批消息压成一条摘要
compact_summarize(messages, pinned):
old = 最旧 40% 里未被 pinned 的消息
summary = LLM.summarize(old)
return [系统消息(summary)] + 剩余消息

# 混合：低于阈值走滑动窗口，超过阈值走摘要
compact_hybrid(messages, pinned, pressure, threshold):
if pressure < threshold:
return compact_sliding(messages, pinned, pressure)
else:
return compact_summarize(messages, pinned)

这里有两个细节值得单独说。

第一个，固定消息（pinned）。 

不是所有消息都能丢，身份、关键规则、未解决的决策，这些必须被固定住，压缩时跳过。

滑动窗口丢的、摘要压缩的，都只针对非固定消息——所以最核心的东西，永远不会被压缩掉。

第二个，阈值与压力。

压缩不是随便触发的，压力超过 1.0，才是真正该动手的信号；而混合策略里的阈值（默认 80%），决定的是什么时候从滑动窗口升级到摘要。

阈值和压力分开，是为了避免过早压缩（浪费）和过晚压缩（溢出）。

四种策略，守的是同一条原则：压缩掉的永远是过程，留下的是结论；丢弃的是噪音，保住的是信号。

压缩不是一刀切，而是四种策略——不压缩、滑动窗口、摘要、混合，各有各的适用场景。

顺带一提，别的框架也在走同样的路，LangChain 的 Deep Agents 用了三层压缩：先把超大的工具结果外置到文件系统，只留一个路径引用；

上下文快到 85% 时，再把旧的写入参数外置出去；最后才用 LLM 做结构化摘要——把会话意图、产物、下一步提炼成一段，同时把完整历史存盘留底。

它的检索侧还有个 ContextualCompressionRetriever，检索文档时只抽出和当前问题相关的那几句，而不是整段塞进来。思路和我们一致：能外置的先外置，能摘要的再摘要，把上下文压到最小、只保最关键。

上下文工程的模式一：分层记忆

首先，必须明确一点：LLM是无状态的，这点从Function Calling就有进一步的清晰体现。

上下文工程里最精妙的模式之一，是分层记忆，它的核心思想一句话：不是所有信息都平等，所以不该用同一种方式装载。

具体分四层，每层对应不同的装载策略：

第一层，身份层（identity）——总是满载。 

这一层装着代理的身份、任务、领域所有权，以及那些永远不能违反的硬规则，它是代理的底色，每一次推理都必须完整在场，没了它，代理就不是这个代理了。

第二层，工作层（working）——总是满载。 

这是短期记忆，装着当前这次运行的最新状态：正在做什么、已经做到哪一步、手头有哪些中间产物。它每次运行都会更新，永远保持新鲜。

第三层，长期层（long-term）——按需加载。

这是长期记忆， 这一层装着经过验证的模式、历史教训、沉淀下来的经验，它平时不在上下文里，只有当agent需要参考过去的决策时，才按需拉进来，这样既省 token，又不会让无关的旧经验干扰当前判断。

第四层，事件层（events）——从不装载。 

这是一份只增不改（append-only）的审计记录，Agent会往里写——记录每一步发生了什么，但从不把完整日志读回上下文，它是事后可查的账本，不是随时在场的记忆。

四层的本质，是给不同信息分配不同的装载预算：身份层和工作层（短期记忆）永远在场，长期层（长期记忆）按需来，事件层只写不读。

这样确保上下文窗口里常驻的，永远只有身份 + 当前状态这两块最小的核心，而把海量的经验、历史、日志都挡在了窗口之外。

分层记忆的具体细节，我们有必要另开单篇文章详细讲解。

上下文工程的模式二：可复用模块 Skills

如果说分层记忆解决的是记忆怎么分装，那 Skills 解决的是能力怎么复用。

Skills 是上下文工程的可复用模块，它把一段可复用的上下文——做某件事的方法、要用到的工具、相关的约束——打包成一个独立的 skill，平时它不在上下文里，只有当任务需要时，才按需加载。

这背后的思想叫渐进式披露（progressive disclosure）：不把全部能力一次性塞进上下文，而是让代理在需要时，才把对应的 skill 拉进来。

好处是双重的——既省 token（不用永远背着一堆用不上的能力），又降噪（当前上下文里只有跟当前任务相关的东西）。

举个例子：一个会写代码的Agent，不需要把所有编程范式、所有框架的最佳实践都常驻在上下文里，它只需要在要写 Go 代码时，加载 Go 开发这个 skill；在要写测试时，加载测试规范这个 skill。

能力还是那些能力，但上下文里永远只装着当前要用的那一小块。

上下文工程的模式三：宪法

上下文里最特殊的一类信息，是契约。

宪法（constitution）、agent.md，就是这种契约，它们是身份层的载体——定义了Agent是谁、要遵守哪些不可动摇的规则、领域的边界在哪。

为什么叫契约而不叫提示词？因为它们的性质不一样，普通提示词是请求，可以被上下文里的其他内容稀释、覆盖；

而契约是宪法，是Agent每次推理都必须在场、必须遵守的硬约束，它不跟其他信息讨价还价，它是其他信息的上位法。

写契约有个关键的分寸，Anthropic 叫它正确的高度（right altitude）：不能太具体——太具体就变成了脆弱的、堆满 if-else 的硬编码逻辑，一改就崩；

也不能太笼统——太笼统就是一句正确的废话，代理不知道到底该怎么做。好的契约，是具体到能指导行为，又灵活到能提供启发。

上下文工程的架构原则

前面几节，我们把上下文工程的各个构件单独拆开看了一遍，现在把它们合起来，看一座完整的一个上下文系统怎么搭，有四条架构原则。

第一，身份与状态分离。 

Agent的身份，我是谁、我拥有什么——和它此刻的工作状态，是两回事，要分开存。

身份是稳定的，状态是流动的；混在一起，状态一变，身份就跟着乱。

第二，记忆分层。 

不是所有信息都配占用上下文窗口，给记忆分明确的层，每层定好装载规则：什么常驻、什么按需、什么只写不读。

第三，把可复用模式抽成 Skills。

两个 Agent 需要同样的能力，那它就该是一个 skill，而不是各自复制一份指令，重复，是架构的敌人。

第四，共享宪法。 

系统级的规则，只放一个地方，而不是复制粘贴到每个 Agent，规则改一处，处处生效。

四条合起来，就是上下文系统的骨架：身份归身份、状态归状态，记忆分层、技能成模块、规则单点管理。

上下文工程的质量检验

前面讲了怎么搭，最后讲讲怎么验，一套上下文工程做得好不好，可以从四个方面来检验。

第一，关键规则放顶层。

LLM 存在新近性和优先性偏差——它天然对开头和结尾记得更牢，唯独中间容易漏。所以重要指令要优先，放在最前面。

第二，分层限制尺寸。 

上下文腐烂是真实存在的——不设限，信息就会越堆越多、越堆越杂，所以要给每一层设定严格的界限，并通过修剪规则来执行：工作层不能无限膨胀，长期层不能无节制堆积，没有界限、或不执行的层，迟早把整个上下文拖垮。

第三，渐进式加载。

能力、经验、资料，都不该一次性全部塞进来，而应该按需加载。检验标准：当前上下文里，是不是只有当前任务真正需要的东西？如果常驻着一堆可能用上的能力，那就是没做到渐进式加载。

第四，交叉核对。 

上下文里的信息要能互相印证，检索到的资料，是否和身份规则一致？注入的约束，是否和对话历史冲突？检验标准：有没有一道机制，在信息进入上下文之前，先核对它和已有内容是否自洽、是否冲突。

四个方面里，最关键的是第一个——关键规则放顶层，因为模型迷失在中间是结构性的，不是靠调参能解决的，规则放不对位置，再好的规则也等于没有。

上下文工程的生产运维

上下文工程不是写完就完了，进了生产环境，它还需要一套运维——本质上，是把上下文当代码来管。

第一，版本化。 

指令、Skills、宪法，都是会变、会被改、需要回滚的东西，它们和代码没有区别。所以要纳入版本控制：改了什么、谁改的、能不能回退，都得有记录。

第二，跨 Agent 测试。 

一条宪法的改动，影响的不是某一个 Agent，而是所有依赖它的 Agent，改之前要像改公共库一样 review——这条规则动了，会波及到谁。

第三，监控窗口利用率。

每个 Agent 的上下文窗口用了多少、为什么用这么多，要有可见性，看不见的东西没法优化——窗口利用率，就是上下文工程的资源监控。

第四，把纠错沉淀进上下文。 

Agent 犯错，修复必须是永久的：不是这一次把 prompt 改对就完事，而是把教训写进宪法、写进规则，让同样的错不再犯第二次。

四条合起来，一句话：把上下文当代码管——版本化、测试、监控、沉淀，一样都不能少。

写在最后

回到 Karpathy 那句话。

他说，人们总把 prompt 理解成日常那种给模型的一段任务描述——那是把一件复杂的事严重轻描淡写了，真正在工业级的应用里，你是在精心地构建上下文，让模型去解决你的定制任务。

所以冰山一角上，水面之下，是检索、组装、管理、记忆分层、可复用模块、上下文契约、架构原则、质量检验、生产运维、动态组装上下文这一整套完全闭环的信息系统。

最后

我们整理出这套 AI 大模型 突围资料包：

    ✅ 从零到一的 AI 学习路径图
    ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
    ✅ 百度/阿里专家闭门录播课
    ✅ 大模型当下最新行业报告
    ✅ 真实大厂面试真题
    ✅ 2025 最新岗位需求图谱

所有资料 ⚡️ ，朋友们如果有需要 《 AI大模型 入门+进阶学习资源包》，下方扫码获取~

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

需要这份AI大模型资料清单的话，在评论区回复「清单」即可；我会根据大家的问题继续补充对应的实战内容。