很多人以为上下文窗口越大 Agent 越聪明,工程里的实际经验正好相反——窗口越大,信号越稀薄,模型对细节的召回与推理能力反而下降。Anthropic 2025 年 9 月发布的”Effective context engineering for AI agents”把这件事实锤钉死:context rot(上下文腐烂)随 token 增加而恶化,这是 Agent 工程质量曲线极陡的拐点。下面把”上下文窗口是什么、它如何成为约束、应该怎么管理”三件事拆开讲清。
一、上下文窗口的物理意义
上下文窗口(Context Window)指模型在一次推理中能”看到”的最大 token 数,包含 system prompt、工具描述、用户消息、模型历史回复、工具结果、外部检索片段等所有内容。Transformer 的注意力机制决定了窗口内每两个 token 之间都要算一对关系——窗口 N 对应 O(N²) 的注意力对,token 增加一倍,注意力计算量增加三倍多。这是窗口不可能无限制扩大的物理根因。
但”窗口够大”≠”装得下有效信号”。公开研究显示:
- ChromaDB 在 12 个模型上做压力测试,11 个模型在 32K token 时召回准确率掉到 50% 以下;
- 微软一项研究指出,在更长对话里模型准确率从 90% 降到 51%;
- “Lost in the middle”现象表明,处于上下文中间位置的信息被检索到的概率明显低于首尾两端。
这些不是”理论担忧”,而是任何在生产 Agent 上跑过数百轮对话的团队都会遇到的现象。结论:上下文不是”越多越好”,而是一个有显著边际收益递减的有限资源。
二、它为什么是 Agent 工程里极关键的约束
Agent 和”一次性问答”明显的区别在于:它要在多轮、长时间、跨工具调用中持续工作。每次工具调用都会把结果塞回上下文,每次反思都会生成新的思考 token,长链路任务很容易把窗口推到上限。窗口一旦满了或接近满了,会同时出现 3 类故障:
- 指令漂移——系统提示里强调的约束在长对话中被”稀释”,模型开始忽略早先规则;
- 工具错用——工具描述被挤压到中间位置,模型挑错工具、漏掉必填参数;
- 幻觉上升——模型为了”接上话”开始编造不存在的工具返回或事实。
这 3 类故障不是”模型不够强”造成的,而是注意力预算被低信号 token 消耗后的必然结果。在 200+ 轮的客服 Agent 调试中,前几次翻车几乎都是”上下文快满了 + 用户突然改了话题”,模型直接忽略了 30 轮之前的退款政策。窗口管理不是优化项,而是 Agent 工程的”地基”。
三、上下文管理的 5 大技术
把上下文当有限资源管理,工程上有 5 类常用技术:
| 技术 | 核心思路 | 适合场景 | 主要代价 |
|---|---|---|---|
| 精简 system prompt | “恰好的高度”——不过细不过粗 | 所有 Agent | 调优需要观察失败样本 |
| 工具瘦身 | 砍掉功能重叠、描述模糊的工具 | 工具集超过 10 个时 | 短期要重新评估 Agent 行为 |
| 即时检索(JIT) | 不预加载,用到时再拉 | 知识库 / 文档问答 | 引入检索延迟 |
| 压缩(Compaction) | 对话过长时总结,丢弃冗余 | 长任务、多轮反思 | 摘要本身有损 |
| 子 Agent 隔离 | 子任务交给独立窗口的子 Agent | 并行研究、复杂探索 | 子 Agent 也有自己的窗口上限 |
5 种技术不是二选一,而是组合拳。Anthropic 在 Claude Code 中就把它们都用了:system prompt 极简、工具集刻意收敛、长任务用子 Agent 隔离、上下文快满时做压缩、关键信息落到外部 NOTES.md。
四、压缩与子 Agent 隔离:落地的两个核心模式
4.1 压缩(Compaction)
压缩的原理是:当上下文接近窗口上限时,把早先的多轮对话总结成高保真摘要,保留关键决策、未解问题、关键参数,丢弃重复的 tool output 与中间推理,然后用”系统提示 + 摘要 + 近期消息”重启一个等价上下文。
实现这一模式的关键是”什么保留、什么丢弃”的策略。一种稳妥做法:
- 保留系统提示、用户原始目标、关键决策点、未解决的错误;
- 丢弃原始 tool output、重复的中间思考、被回滚的尝试;
- 摘要使用同一 LLM,但要求”按原意压缩、不引入新事实”。
# compaction.py —— 最小化压缩触发
from typing import List, Dict
TOKEN_LIMIT = 100_000 # 视模型而定
def should_compact(messages: List[Dict]) -> bool:
return sum(len(m["content"]) for m in messages) > TOKEN_LIMIT * 0.8
def compact(messages: List[Dict], summarizer) -> List[Dict]:
system, head, recent = messages[0], messages[1:-10], messages[-10:]
summary = summarizer.summarize(head)
return [system, {"role": "system", "content": f"对话摘要:{summary}"}] + recent这段代码展示”系统提示 + 摘要 + 近期消息”的最小骨架,实际工程里要再做失败回滚、摘要质量评估、关键参数注入。
4.2 子 Agent 隔离
子 Agent 隔离的原理是:把检索密集、上下文消耗大的子任务交给独立窗口的子 Agent,主 Agent 只接收子 Agent 返回的 1~2K token 摘要。这样做有两个收益:主 Agent 的窗口不被”探索阶段”的噪声污染;子 Agent 可以放心地大范围探索、读大量文件,因为它有自己的窗口配额。
子 Agent 隔离在 Anthropic 的工程实践中被反复验证:Claude Code 在执行复杂研究任务时,会派生多个子 Agent 并行探索,每个子 Agent 用数万 token 做”现场工作”,最终回给主 Agent 的只是结论。设计这一模式时,关键是划清”主 Agent 看什么、子 Agent 看什么”的边界——子 Agent 不应把探索过程的中间结果写回主 Agent,否则窗口压力原封不动地回来了。
五、上下文工程的 4 条原则
把上面的技术抽象成可执行的工程原则,核心是这 4 条:
- 最小高信号 token 集——”最小可生成期望结果的高信号 token 集合”才是目标,体积是手段;
- 即时优于预加载——用到时再拉,不要”以防万一”塞进全文;
- 系统提示”恰好的高度”——不写死的 if-else,不写过于抽象的”请好好回答”;
- 工具少而清晰——一个工具对应一个明确意图,功能重叠的工具集是模型选错的根源。
这 4 条不是”风格偏好”,而是任何在生产里跑过 Agent 的团队都会反复得出的经验。Anthropic 的指导原则原文是:find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome——把它翻译成工程语言就是”信号密度最大化,体积最小化”。
六、落地步骤与避坑
把上下文工程落进项目,可以按下面 5 步走:
- 测量基线:在真实任务样本上记录 token 占用、模型准确率、错误模式;
- 精简 system prompt:用结构化标签(背景 / 指令 / 工具指南 / 输出规范)分块,删掉重复规则;
- 砍工具:把功能重叠的工具合并,描述从一行扩到能让人明确选用的程度;
- 接入压缩:在窗口占用到 70%~80% 触发压缩,留出 20% 给后续推理;
- 引入子 Agent:对检索密集、并行可分的子任务,优先走子 Agent 隔离。
常见避坑点:
- 预加载整库——一次性把整个文档库塞进上下文,模型被噪声淹没,反而找不到答案;
- 保留所有 tool output——长 tool output 应在 Agent 读取后做摘要,原始数据落外部存储;
- 忽略”lost in the middle”——关键指令放 system prompt(头部)与最近消息(尾部),不要塞中段;
- 没有硬上限——不设 max turns / max tokens / max calls,Agent 跑到 200 轮后必然失控。
到这里,上下文窗口是什么、它为什么是 Agent 工程里极关键的约束、怎么管理就讲完了。模型再强,也救不了一个”窗口无策略”的设计——把上下文当有限资源管理,Agent 才能从 demo 走向稳定生产。
常见问题(FAQ)
Q1：上下文窗口是不是越大越好？
不是。窗口越大,信号越稀薄,模型对细节的召回与推理能力反而下降。
Q2：Agent 多长对话算”危险区”？
经验上 30~50 轮之后注意力质量明显下降,需要压缩或子 Agent 介入。
Q3：上下文压缩会丢关键信息吗？
会。压缩要保留决策、参数、未解决问题,丢弃重复输出,并对摘要做质量评估。
