Agent 上下文怎么管？4 个循环动作 + 6 个常见坑
Agent 上下文不是越大越好，本质是在有限窗口里做信号密度管理。
- 4 个循环动作 ：select 选相关 / structure 结构化分区 / compact 压缩 / persist 外部沉淀，每轮对话都要走一遍。
- Context 是工作台，Memory 是后台仓库——工作记忆有限又金贵，跨轮次靠检索联动。
- 压缩不是写总结，是写交接文档，保留目标 / 进度 / 决策 / 约束 / 教训。
- 多 Agent 隔离：子 Agent 只拿必要信息，结构化结果回传主 Agent 整合。
- 6 个常见坑：上下文腐烂、压缩失真、工具结果膨胀、多 Agent 串扰、成本与延迟、难以评估。
- 评估四指标：任务成功率、事实准确率、token 成本、响应延迟。
Context 是什么：模型的工作记忆，不是仓库
每轮模型决策时能看到的所有信息，就是上下文（context）——也就是它的工作记忆。
打个比方：模型是 CPU，上下文是内存条，外头的存储才是硬盘。内存有限又金贵，CPU 干活得先从内存拿数据，实在拿不到才去翻硬盘。
所以上下文从来不是越大越好。对话跑了几十上百轮，全量塞进去，最早那几句话早被埋在最底下，模型想看都看不清。
还有两个现象更要命：
- Lost in the middle：模型对长段文字的中间部分注意力天生就弱。
- Context rot（上下文腐烂）：窗口还没塞满，无关信息一多，回答质量就开始往下掉。
本质就一句话：管理信号密度。窗口不是仓库，是工作台。让模型每次开工，台面上摆的全是眼下真正用得上的信息。
Context vs Memory：两码事
开始之前先交代个前提——context 和 memory 是两码事：
- Context（上下文）：模型这一轮真正看到的，是眼前的工作台。
- Memory（记忆）：跨轮次存下来的，是后台的仓库。
中间靠检索联动。Memory 本身也分层：
| 层 | 存什么 | 变速度 |
|---|---|---|
| 情景记忆（episodic） | 发生过的事：历史对话、做过的任务、当时的决策 | 慢变量，几乎不动 |
| 语义记忆（semantic） | 用户的事实和偏好：风格喜好、业务规则、项目背景 | 慢变量 |
| 工作记忆（working） | 当前任务：最近几轮对话、正在跑的工具调用 | 快变量，每轮都在换 |
底层是慢变量，顶层是快变量——搞混这两层是常见的设计错误。
4 个循环动作
业界把玩法收敛成四个动作，每一轮对话都要走一遍。
Select：选相关
信息不能全端上桌。RAG 检索、重排序、时间衰减，都是干这个的——相关的才放进来。
Structure：结构化分区
挑进来的不能落成一堆。得分区、摆好：
- 系统指令放一块
- 工具定义放一块
- 记忆放一块
- 用户输入放一块
模型一眼就能分清哪是规矩、哪是事实、哪是任务。
Compact：压缩
历史不能全留，得压缩。这个最有讲究，下一节单独讲。
Persist：沉淀到外部
眼下用不上、以后一定用得上的，别占窗口——存到外部，要用再捞回来。
记住这四个动作不是做一遍就完，而是每一轮对话都在循环。
压缩的坑：不是写总结，是写交接文档
好多人以为压缩就是让模型把对话总结一下。真这么干，迟早翻车。
那种总结是叙事式的，像写日记——把故事讲完整就完。可 Agent 要的不是故事，是状态。
所以业界讲究的是 compaction——提炼保留的不是聊了啥，是这 6 样东西：
- 当前目标：解决啥问题、成功标准是啥。
- 已完成：做了啥、结果咋样。
- 未完成：下一步干啥、卡在哪。
- 关键决策：为啥选这套方案。
- 约束：哪些不能碰。
- 失败教训：哪条路走不通，别再走。
还有常被忽略的安全停点：别等窗口满了才压，要挑任务的自然停点——一次工具调用结束、一个子任务完成——趁剧情告一段落，压一次交接好状态，开新窗口接着干。
你看压缩前是流水账，压缩后是交接文档。Agent 能不能长时间稳定干活，就看这份交接文档写得好不好。
多 Agent 系统的上下文隔离
把视角往上拉，从单个 Agent 看到整个系统。核心一句话：让 Agent 按需取用，别全量携带——别指望模型自己记住一切，那既不靠谱又费钱。
架构上分三部分：
- 左边检索层：向量检索、重排序、时间衰减都在这层干活，从记忆仓库里捞相关的东西。
- 中间编排器：每 收一次请求，就按当前任务动态组装上下文——系统指令放多少、记忆放多少、工具结果放多少，比例随任务变。
- 右边隔离层：专管多 Agent 的协作。
最常见的错是把主 Agent 的全量上下文复制给子 Agent——又贵又乱。正确的做法是：子 Agent 只拿干活必要的那点信息，干完活把结论用结构化结果交回来，由主 Agent 整合。
6 个常见坑
盘六个坑，踩中任何一个 Agent 都会越跑越笨。
一、上下文腐烂——窗口没满，垃圾一多，质量就开始掉。管理动作得前置，别等问题出来再补救。
二、压缩保真度——压得越狠越省钱，但细节丢得越多，搞不好把关键事实压歪。保真和长度永远在拔河。
三、工具结果膨胀——真实系统里工具调用才是 token 的大头。一次返回上千行，太常见。这块不管，前面全白干。
四、多 Agent 串扰——隔离做不好，子 Agent 互相污染。传多了是灾难，传少了干不成活，这个度真难拿捏。
五、成本与延迟——系统指令、工具定义这些万年不变的内容，每轮全量重发，钱包扛不住。生产上得配缓存。
六、不好评估——一般就看四个数：任务成功率 / 事实准确率 / token 成本 / 响应延迟。想改方案，先拉基线，用数据说话。
怎么回答「上下文怎么管」这道题
绕回这道题，一个漂亮的回答长啥样？
第一步讲本质——一句定调：在有限窗口里做信号密度管理，让模型每次决策都拿到眼下用得上的信息。
第二步讲方案——四个动作展开：select 选相关、structure 结构化分区、compact 在安全停点提炼、persist 沉淀到外部记忆，每轮循环。
第三步讲权衡——任何方案都有代价：压太狠丢细节，留太多费钱费时间。得结合具体任务，在质量 / 成本 / 延迟 / 一致性之间取舍，再用指标验证。
制定方向方案显功力，权衡见成熟。三步下来，这道题就答完整了。
References
- Agent 系统上下文管理详解：解决上下文膨胀、信息丢失、token 超限，架构设计与实战方案 —— AI大模型原理, 哔哩哔哩, 2026-09-07