一、写这篇的动机
2026 年 8 月这一周,如果只看新闻头条,大家会以为企业 AI Agent 的卡点是模型不够聪明——Claude Opus 4.6 又把 SWE-Bench 推到 74.5%,Gemini 2.5 Pro 在 LMArena 又拿第一。但把视角从演示台移到生产机房,真相完全不同:2026 年 4 月一篇被业界反复引用的生产指南给出一个相当不吉利的数字——只有 9 分之 1 的企业 Agent 测试项目真正跑到了生产。换句话说,不是模型答得不对,而是 Agent 在生产里"做着做着就忘了自己在做什么",或者"做着做着成本爆表"。把这件事拆开,罪魁祸首十有八九不是模型本身,而是被严重低估的一道工程环节:上下文工程(Context Engineering)——也就是"喂什么给模型、以什么顺序、多久清一次、关键信息钉在哪里"这一整套。
2026 年 8 月恰好是上下文工程第一次从"边缘技巧"升格为"基础设施"的拐点:Microsoft Research 把 ACON(Agent Context Optimization)论文投进了 ICML 2026,在 AppWorld、OfficeBench、Multi-objective QA 三个长程任务上把峰值 token 用量压掉了 26–54%,并让小模型在长任务里获得了最多 46% 的性能提升;NVIDIA 把 KVpress 上 20 多个 KV-cache 压缩方法统一到一张排行榜,Google 在 3 月放出训练无关的 TurboQuant 把 KV-cache 内存砍 6 倍、注意力计算提速 8 倍;与此同时,Anthropic、OpenAI 都把 compaction API 写进了官方 SDK,Letta(原 MemGPT)、Observational Memory 等外部记忆架构正式进入生产案例库。这一切叠在一起意味着,2026 年下半年任何一家还在用"把全部历史塞进窗口"的 Agent 项目,都已经在结构上落后了。
更深一层的问题不是"省 token",而是"上下文腐烂"(context rot)——Chroma 对 18 个模型做的实证研究指出,几乎每一个 LLM 在长上下文里都会出现注意力扩散(attention diffusion)、近因偏差(recency bias)和"中间遗忘"(lost-in-the-middle)三种症状,而且这是一个跟窗口大小无关的退化规律:上下文越长,模型越分不清信号和噪声。RULER 基准对这件事给出过非常硬的数字——Gemini 1.5 Pro 从 4K 涨到 128K 只掉 2.3 分,GPT-4 掉 15.4 分,Llama 3.1-70B 掉 29.9 分,Mixtral-8x22B 掉 63.9 分。也就是说,"我换了个 1M 窗口的模型"这件事在生产里很可能让 Agent 表现更差而不是更好。
对企业落地而言,这件事最危险的地方在于它是"沉默失败"——Agent 不会报错,只会安静地越做越错、越做越贵。等到月底账单来的时候,大部分团队才会意识到:70% 的 token 都花在了"重复读历史 + 不必要地携带旧工具输出"上。Agent 落地三件事:模型选型、工具集成、可观测性,前两件已经被讲过太多遍了;第三件事目前主流叙事仍然停留在"接 Datadog / New Relic",而真正决定 Agent 在生产能不能跑超过 30 分钟的,是上下文工程这一层。
所以这一篇要把上下文工程这件事系统讲一遍:从为什么会腐烂,到 KV 缓存层、上下文层、外部记忆层三层各有什么生产级打法,再到今天就能落地的 7 层工程清单,最后落在美辰怎么帮企业把这套体系接进 Agent 项目里。
二、上下文腐烂:为什么更长不等于更好
先看一组会被反复印在生产事故复盘文档里的数据。Chroma 在 2025 年下半年对 18 个模型做了同一组对照实验:把上下文从 4K 起步逐级加到 128K,记录模型在多跳推理、实体追踪、检索类任务上的准确率变化。结果没有惊喜,只有一个非常稳定的"腐烂曲线"——准确率随上下文长度增加而下降,而且下降速度比窗口大小给出来的"预期"快得多。RULER 基准把这些数字整理成了可对比的格式:Gemini 1.5 Pro 从 4K 到 128K 只掉 2.3 分,是长上下文里最稳的;GPT-4 同区间掉 15.4 分;Llama 3.1-70B 掉 29.9 分;Mixtral-8x22B 直接掉 63.9 分。换成生产语言就是:一个本来在 4K 上下文里能 100% 答对的检索任务,在 128K 上下文里变成"每做 6 次大概有 1 次会拿错证据"——这不是 benchmark 脚注,这是生产可靠性事件。
腐烂的机制有三条,被独立的几篇研究分别坐实:第一条是注意力扩散,长序列里每个 token 分到的注意力权重被摊薄,模型没法像短序列那样精确锁定关键证据;第二条是近因偏差,模型会系统性偏向最近读到的内容,反过来压低对开头和中间内容的检索权重;第三条是"中间遗忘",也就是 Liu 等人在 2023 年就观察到的 lost-in-the-middle 现象——模型对长序列中段的检索精度显著低于对开头和结尾的精度。三条叠在一起,就出现了"shuffled 反而更好"这种反直觉的实验结果:打散顺序的文本反而让模型分布更均匀地关注每一段,准确率高于连贯文本。
这件事对企业 Agent 的实战意义非常具体。一个跑长程 ReAct 循环的 Agent(代码重构、调研报告、长流程审批)在第 15 步时,理论上能看到所有历史:用户初始意图、第 1 步到第 14 步的工具调用和输出、第 14 步的中间结论。但实际表现是:用户最初的关键约束大概率已经被近因偏差挤出有效注意力范围,而中间那些"已经合成过、不再需要"的搜索结果仍然在拖 token、抢预算、稀释注意力。换句话说,Agent 不是"忘了",而是"看不到"——而且越长的会话越看不到。
上下文腐烂在生产里还有一个特别隐蔽的变种:定价悬崖(pricing cliff)。Anthropic 和 Google 对超过 200K token 的请求按 2 倍价收费,而且加价的对象是"全部 token"而不是"超出部分"。一封 201K token 的请求比 199K 的请求贵整整一倍。这跟模型本身没关系,但跟上下文工程强相关——一个 Agent 项目如果没做压缩、没设上限,它在月底对账时会撞到一个非常难解释的"为什么我们的 Claude Opus 用量是这个数字"。在生产经济学层面,这意味着上下文工程不只是性能优化,更是预算可预测性的护城河。
三、ACON:从"被动压缩"到"失败驱动压缩"
过去一年,主流的上下文压缩做法都是"被动压缩"——窗口快满了,触发一次 LLM 摘要,把历史压缩成一段文字,然后继续跑。这种做法有两个根本问题:第一,它不知道什么信息重要,所以会无差别地丢掉细节;第二,它只能按 token 数触发,不看 Agent 当前的"健康状态",所以经常在最不该压缩的时候压缩(比如 Agent 正在做关键决策时)。Microsoft Research 在 2025 年 10 月发布、2026 年 6 月被 ICML 接收的 ACON 论文(arXiv:2510.00615)给出了一个被业界叫做"失败驱动压缩"的新范式。
ACON 的核心思路可以一句话讲完:在自然语言空间里优化压缩策略,根据 Agent 的失败轨迹迭代地改进压缩指南,然后把优化后的指南蒸馏到小模型上。具体地,它会观察 Agent 的失败案例——重复的工具调用、推理链中反复出现的不确定性 token、任务进度停滞——把这些信号当作"压缩该发生了"的触发器,而不是傻等窗口到 80%。这种 reactive 触发的代价是,压缩频率跟 Agent 状态绑定,跟 token 预算解耦,所以模型永远不会在错误的时间点丢上下文。
实验结果有三个数字值得企业 Agent 团队贴到墙上:第一,在 AppWorld、OfficeBench、Multi-objective QA 三个长程任务上,峰值 token 使用量降低了 26–54%;第二,任务成功率比现有压缩基线更高(不是"省 token 换质量",而是"省 token 同时质量更高");第三,把压缩器蒸馏到小模型后,小模型在长程任务上的性能提升最多达到 46%——这一点对企业特别重要,因为它意味着用 7B–13B 开源模型也能跑长任务,只要压缩策略对。
ACON 的另一个被低估的贡献是"无需模型微调"。过去做上下文压缩要么靠 RAG 检索(延迟 + 召回率问题),要么要微调模型(成本 + 数据问题),ACON 走的是自然语言层的策略优化,完全在提示词工程范围内。这意味着任何一家用 GPT-4.1 / Claude Opus 4.6 / Gemini 2.5 Pro 的企业,都可以在不动模型的前提下把压缩策略接进 Agent runtime。
四、生产级上下文工程的三大技术家族
把视角从单篇论文抬到整个 2026 年的生产生态,可以归纳出三个互补的技术家族。每一家都有自己的最优适用场景,真正的工程能力不是押宝某一族,而是把它们拼成一个组合。
第一族是 KV-cache 压缩,在推理层动刀,不改变发给模型的文本,而是改变模型内部存储注意力状态的方式。这一族里目前主流的子类有三种:token 剪枝(丢掉低注意力分数的 token,典型 40–65% 内存节省)、KV 量化(降精度,典型 2–4 倍节省)、结构化剪枝(剪掉整个注意力头或层,典型 3–8 倍节省,但有中度精度损失)。2026 年这一族最有影响力的两个开源项目是 NVIDIA 的 KVpress(把 20 多个剪枝方法聚到一个排行榜,新发布的 KVzip 用"复制粘贴"前置任务打分,目前在 KVpress 榜单上领先)和 Google 的 TurboQuant(2026 年 3 月开源,训练无关,6 倍 KV 内存减少 + 8 倍注意力计算加速)。这一族最关键的工程边界是:任何 KV 层的剪枝在 Agent 场景里都不可逆,所以在金融、医疗、法律这类审计要求高的场景,要谨慎使用,或者配合外部全量审计日志。
最贴 Agent 场景的 KV-cache 技术叫 SideQuest,2026 年 2 月发表。它的特殊之处是专门训练了一个 215 样本的小推理线程,去评估"哪些工具响应在 ReAct 循环里已经过时了"——不是按 token 分数剪,而是按"这个工具输出对当前决策还有没有用"剪。在 Agentic 任务上 SideQuest 把峰值 token 用量压掉了 56–65%,而且几乎不损失任务准确率。这一族还有一个对长文档 Agent 特别有用的变种叫 ChunkKV——不按 token 剪,按段落级语义块剪,因为剪掉半个句子比剪掉整个句子在长文档里更糟。
第二族是上下文滚动摘要,在应用层动刀,显式管理"下一次发给模型的提示里包含什么"。这一族里 2025–2026 年的最佳实践叫锚定迭代摘要(anchored iterative summarization):不要每次压缩都重新生成完整摘要,只把新掉出去的那一段做增量更新,锚定文档本身只在四个字段上变——intent(原始任务)、changes made(已完成项)、decisions taken(分支点 + 决策依据)、next steps(当前计划)。Factory.ai 是这个模式的企业代表,某个金融科技团队把它落地后把生产幻觉率砍掉了 60%——他们只是把 2400 token 的系统提示压到了 380 token,迫使 Agent 必须精确知道它需要什么。
这一族在 2026 年还有一个重大变化是 Anthropic 和 OpenAI 都在 SDK 里内置了 compaction API,可以直接调,把"窗口快满了就压缩"这件事产品化。ACON 是这条线上的研究前沿——失败驱动触发,而不是 token 数触发。对企业 Agent 团队的现实建议是,任何超过 20 步的 ReAct 循环都要配三层预算监控:per-request max_tokens(单次硬上限)、per-task budget(整次任务 70% 时触发压缩)、per-month cap(组织级预算,50%/80% 双阈值告警)。
第三族是外部记忆架构,把上下文窗口当 RAM,外部存储当 disk,只在需要时取回来。这一族里 2026 年最值得注意的进展叫 Observational Memory——两个后台 Agent 持续运行,Observer 负责把新上下文压缩成带日期的观察条目,Reflector 负责合并去重。压缩日志永久驻留上下文,替换原始转录。结果在文本密集型工作流上拿到 3–6 倍压缩,在工具密集型工作流上拿到 5–40 倍压缩。VentureBeat 报道的生产数据显示,Observational Memory 把 token 成本砍到了基线 RAG 的十分之一,而且在长上下文基准上召回率更高——因为观察是结构化摘要,不是原始片段。
Letta(原 MemGPT)走的是 OS 式分层:上下文窗口是 RAM(快、热、立即可访问),外部向量存储是 disk(慢、持久但比重新 LLM 便宜),Agent 通过 read/write/archive 显式控制什么留在 RAM 里。这种结构的好处是成本可预测,长会话不会指数级增长。1 月份还出现了两个研究阶段的框架值得长期跟踪:MAGMA(基于多图的智能体记忆架构,把记忆存成知识图谱而不是线性日志,适合跨任务实体关系管理)和 EverMemOS(自组织记忆操作系统,按访问频率和新鲜度自动升降级信息)。这两个都还没到生产规模,但它们给出了下一代外部记忆的形态——对企业 3–5 年的 Agent 路线规划很关键。
五、七层实战工程清单:今天就能落地的上下文工程
把上面三层技术家族映射成企业 Agent 团队今天就能动手的工程清单,可以拆成七层,从模型评估阶段一直到运行时监控。
第一层是上下文预算规划。在选型阶段就要决定每条业务线的 per-request max_tokens(单次上限)、per-task budget(整任务上限)、per-month cap(月度组织级上限)。这三个值不是"随便拍"的,要从业务目标反推:能接受每条任务的成本、能在多少 token 内完成目标、用户等待多久可接受。同时必须把"超 200K token 请求触发 2x 定价"这类供应商级定价悬崖写进预算模型,否则月度对账时一定会撞到"为什么我们的用量是这个数字"的尴尬。
第二层是 RULER 实测对比。任何对外宣传"支持 1M 上下文"的模型,都要在自家真实任务上跑一遍 RULER,不要相信 benchmark 榜单。Gemini 2.5 Pro 的 RULER 衰减是行业最稳,GPT-4.1 也不错但有中度衰减,Claude Opus 4.6 在 200K 以下稳但超过 200K 后要小心定价悬崖,Qwen Long 虽然是 10M 但 RULER 表现还有待观察。RULER 实测要包含三个场景:多跳推理、实体追踪、长文档检索,任何一个场景掉分超过 15 个点,该模型在该业务线就不应该被允许在长上下文里裸跑。
第三层是 sandwich 提示布局。Chroma 研究里那个反直觉但好用的发现:把关键指令同时放在上下文开头和结尾(经典 sandwich 布局)显著降低注意力扩散带来的衰退。Agent 系统提示里"任务目标、关键约束、禁做的事"必须出现在 system message 和每轮压缩后的最新摘要末尾,不能只放在开头等被近因偏差挤掉。
第四层是锚定迭代摘要落地。挑一个长程 Agent(比如"调研报告生成"、"代码仓库重构"、"长流程审批")作为试点,把它的压缩策略改成锚定四字段(intent/changes/decisions/next steps),而不是 naive 的"全文重摘要"。试点指标:幻觉率(目标是降 50% 以上)、峰值 token(目标是降 40% 以上)、任务成功率(不能降)。试点周期 2–4 周,数据出来后整个团队复用同一套锚定模板。
第五层是工具感知压缩。Hermes 在 2026 年 5 月开源了一份 staff-engineer 级的 context_compressor.py 实现,关键设计是三段分区:head 保留系统提示 + 开头几轮,middle 压缩,recent tail 按 token 预算保留。另一个核心设计是工具调用/结果对的卫生处理——压缩后必须把 tool call 和对应的 tool result 配对保持有效,不能给模型发一个"调用了一半"的消息历史。Hermes 这份代码可以直接 fork 到企业内部 Agent 框架里,把里面的 head/middle/tail 边界、锚定字段、失败回退 marker 改成业务自己的版本。
第六层是失败驱动触发。在锚定迭代摘要之上,再加一层 ACON 式的 reactive 触发——观察 Agent 的推理链,检测到重复工具调用、不确定性 token 增加、任务进度停滞时,主动触发压缩而不是等 token 到 80% 才触发。这一层需要一个轻量级监控 loop,可以是规则引擎(简单场景)也可以是一个小分类器(复杂场景)。对长程 Agent 来说,这一层往往是峰值 token 用量能再降 20–30% 的关键。
第七层是运行时可观测性与审计。上下文压缩是不可逆的——一旦剪掉,信息永久没了。所以任何在生产跑长程 Agent 的项目都必须有"压缩审计日志":每一次压缩的时间点、压缩前 token 数、压缩后 token 数、被丢弃内容的指纹(可以用哈希但保留原文引用)、压缩触发的依据(token 阈值 / 失败信号 / 显式调用)。监管类业务(金融、医疗、法律)还要保留全量原始上下文的离线存档,绝不只留压缩后版本。这一层同时是治理底层的取证基础——一旦 Agent 出了错,你能回溯到"它做这个决策时看到了什么",而不是"它做这个决策时没看到什么"。
六、对企业 Agent 落地的三条硬含义
第一条含义是上下文工程必须前置到选型阶段,不能再"先跑起来再说"。过去两年企业 Agent 项目的主流叙事是"先做个 demo 看看",然后选模型、接工具、写 system prompt、上线,最后撞墙时才开始想压缩和记忆。2026 年这个叙事已经过时——ACON、SideQuest、Observational Memory 这一波技术让"上下文工程"从边缘技巧升格为基础设施,任何在 PoC 阶段没规划上下文预算和压缩策略的项目,在生产阶段大概率会撞到 200K 定价悬崖、上下文腐烂和沉默失败这三个坑。建议是:在选型阶段就把 RULER 实测、token 预算、压缩策略、记忆架构作为评审 checklist,跟模型 benchmark、SWE-Bench 分数并列。
第二条含义是"长上下文模型"不是答案,是陷阱。Qwen Long 10M、Gemini 2.5 Pro 2M beta、GPT-4.1 1M、Claude Opus 4.6 1M beta——这些数字看上去很美,但 RULER 实测明确显示每一个模型在长上下文里都会腐烂。一个常见误区是把"窗口大"等同于"不需要压缩",实际上窗口越大,Agent 越容易把所有历史都塞进去,腐烂越严重。对长程 Agent 来说,"窗口大小"是一个反向指标——越大越要警惕,越大越要在工程上加压缩、加记忆、加锚定。
第三条含义是治理层要把"上下文策略"纳入采购评审。任何一次 Agent 采购评审都应该包含四个上下文相关问题:这个模型的 RULER 衰减是多少?它有没有 compaction API?它的 200K 定价悬崖怎么处理?它的工具调用压缩策略是什么?把这四个问题放进 RFP,供应商的回答会立刻揭示他们到底有没有在生产里跑过长程 Agent——只跑过 demo 的供应商只会说"我们支持 1M 上下文",跑过生产的供应商会立刻说"我们建议在 80K 触发压缩,在 200K 上 KV-cache 剪枝,在 1M 上切到外部记忆"。
七、美辰怎么帮企业把这套体系接进 Agent 项目里
美辰做的事情可以一句话讲清楚:帮企业接 Agent。具体到上下文工程这条线,我们现在能落地的服务分三块。
第一块是上下文工程评估,基于企业真实的业务数据(脱敏后的客户对话、调研报告、审批流),跑 RULER + Chroma 上下文腐烂测试 + 200K 定价悬崖审计,输出一份"上下文健康报告"——明确告诉企业在用模型上 RULER 衰减是多少、压缩潜力有多大、外部记忆该不该上、锚定摘要应该怎么写。这份报告可以作为后续 Agent 项目立项的输入,避免在选型阶段就埋雷。
第二块是上下文策略实施,把 ACON 风格的失败驱动触发、锚定四字段摘要、Hermes 风格的 head/middle/tail 三段压缩,封装成可配置的 Agent runtime 组件,接进企业已有的 LangGraph / AutoGen / CrewAI / 自研框架。具体配置包括锚定字段定义(企业业务特有的 intent / decisions / next steps 字段)、压缩触发阈值(token 数 + 失败信号双触发)、工具感知压缩规则(哪些工具输出可压缩、哪些必须保留全量)、压缩审计日志格式(对齐企业内部合规要求)。
第三块是外部记忆架构咨询,帮企业评估"该不该上 Letta / Observational Memory / RAG"这条决策线。基于业务 Agent 的会话长度、跨会话需求、召回精度要求、合规边界,给出"用 RAM-only / 用分层 / 用 RAG 增强"的具体建议,并实施对应的存储层(向量数据库选型、归档策略、访问控制)。对监管类业务,我们会额外配套一份"原始上下文离线存档 + 压缩日志"的双轨方案,确保任何一次 Agent 决策都可以被审计回溯。
八、企业 Agent 团队今天的行动清单
最后给一组可执行项,按"今天就能开始做"到"一个月内做完"排序。第一,本周内把企业目前在跑的所有长程 Agent 的平均 token 用量、峰值 token 用量、超 200K 请求占比这三个数抓出来,定一个 30 天内"超 200K 请求占比降一半"的目标。第二,两周内挑一条最长程的 Agent 业务线,跑一遍 RULER + Chroma 腐烂测试,把测试结果贴在项目页里,作为后续所有上下文工程的基线。第三,一个月内把锚定四字段摘要的模板做出来,在试点 Agent 上跑 2–4 周,对比压缩前后的幻觉率、峰值 token、任务成功率。第四,跟当前模型供应商要一份"超过 200K 的请求在我们 7×24 用量里的占比",如果超过 10%,立刻重新评估是否要加一层"超 200K 自动切小模型 + 外部记忆"的兜底逻辑。
九、结尾
上下文工程在 2026 年下半年,正在变成企业 Agent 落地最难、但也最少被认真对待的一道工程环节。模型 benchmark 在涨、协议层在标准化、Harness 层在成熟、可观测性产品在打单——所有这些加在一起,仍然绕不开一个朴素的事实:Agent 在生产里跑超过 30 分钟,99% 的概率会被上下文腐烂和定价悬崖这两件事之一打倒。ACON、SideQuest、KVpress、TurboQuant、Letta、Observational Memory 这一波技术的真正信号不是"又多了几个新工具",而是企业 Agent 的工程重心,正在从"模型选型"和"工具集成",正式下移到"上下文策略"。谁先把这层基建铺好,谁就拿到了 2026 下半年 Agent 生产的入场券。
美辰的定位始终没变:帮企业接 Agent。上下文工程这件事,我们跟企业一起把它从"工程团队的隐形成本"变成"采购清单上的明面指标"——这是 2026 下半年 Agent 落地最被低估的一道分水岭,也是我们接下来要帮一批客户系统补上的那一课。
