首页
/
行业洞察
/
正文
INDUSTRY INSIGHT · 深度
AI Harness 上下文工程:你可能只看到了冰山一角
📅 2026/9/14 22:41:40
✍️ 爱科研究院
👁 阅读 3,247
人们总把 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 提示词工程两者的区别用一张表就能看清维度提示词工程上下文工程关注焦点单个请求里的措辞模型每一步看到的全部 token首要目标设计巧妙的妙语设计动态组装上下文的系统作用范围单轮、一次性任务多轮、长程 Agent适用场景一次性任务、简单问答长程 Agent、生产系统核心技能语言精确度系统设计 token 预算管理技术手段few-shot、思维链、角色设定RAG、工具调用、记忆管理失败模式输出不对上下文腐烂、中毒、分心、混淆、冲突模型敏感度高低最关键的差异在失败模式这一行提示工程失效顶多是输出不对而上下文工程失效是整个系统崩掉业界把后者的失败归纳成四种上下文中毒错误信息被当成事实一路传下去。上下文分心关键信息被噪声淹没。上下文混淆无关数据让模型失去焦点。上下文冲突自相矛盾的指令导致行为错乱。提示词工程是术上下文工程是道前者在单个请求里较劲后者在设计整个信息环境上下文工程的三大核心能力检索、组装、管理上下文工程拆开看就是三件事检索、组装、管理它们分别回答三个问题。第一检索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大模型资料清单的话在评论区回复「清单」即可我会根据大家的问题继续补充对应的实战内容。
📌 标签:
工业官网
设计趋势
AI 建站
SEO
获取完整报告 →
RELATED ARTICLES
推荐阅读
2026/9/14 22:41:40
AIGC毕业:从开题到定稿,一个学术写作平台的完整叙事
2026/9/14 22:41:40
Flutter与OpenHarmony开发图片滤镜应用实践
2026/9/14 22:36:40
2026 陕西成人学历机构排名怎么看?排名之外更该看什么
2026/9/14 23:26:45
Cursor 提示机器码上限?TaoToken 的 Key 这样配
2026/9/14 23:26:45
sherpa-onnx 中 Whisper tiny.en 的 ONNX 模型张量接口详解:从 Encoder/Decoder 拆分的 I/O 契约到 RKNN 端侧部署
2026/9/14 23:26:45
Telegraf JOSE 密钥存储插件(secretstores.jose)完整指南:基于 JOSE 加密的文件型密钥管理方案
2026/9/14 23:26:45
WTF Solidity 极简教程:第 40 讲 ERC1155 多代币标准与 BAYC1155 实战
2026/9/14 23:26:45
基于SpringBoot + Vue的桂林景区导游预约平台 毕业设计 -附源码
2026/9/14 23:21:45
欧姆龙PLC与威纶通HMI在铝壳电池自动入壳系统中的应用
2026/9/14 0:03:40
KCF目标跟踪算法与OTB工程实现:毕业设计实战解析
2026/9/14 0:03:40
Megatron-LM 推理实战指南:基于 Megatron Core 高层 API 的离线推理与 OpenAI 兼容服务
2026/9/14 0:03:40
语音情感识别实战:Keras实现LSTM、CNN、SVM与MLP多模型对比
2026/9/14 7:37:16
拯救者Y7000黑屏故障排查与维修实战指南
2026/9/14 2:50:57
AI SDK Harness 依赖更新指南:掌握 harness 包 SDK 依赖的升级、桥接同步与一致性校验
2026/9/14 11:25:37
Refine v5 Ant Design NumberField 组件实战:基于 Intl 的本地化数字格式化