06-Agent状态栏与上下文压缩策略：分层压缩、隔离优于压缩

《深入理解AI Agent：设计原理与工程实践》系列读书笔记 第6篇
关键词：Agent Status Bar、轨迹管理、上下文压缩、KV Cache、子Agent隔离

先讲一个我们线上真实翻过的车。无人售货柜客服 Agent 凌晨两点收到用户反馈"柜机扫码没反应"，用户着急赶早班机想马上退款。Agent 回复：“您好，请问您是现在遇到这个问题吗？”——因为它根本不知道现在几点。模型对执行环境（时间、地点、设备状态）是天生失明的，上下文里没有的信息，再聪明的模型也变不出来。这一篇讲两个解决上下文"感知"与"膨胀"问题的机制：Agent 状态栏与上下文压缩。

一、Agent 状态栏：让 Agent 瞥一眼就知道现状

1.1 为什么需要状态栏

Agent 的上下文主体是轨迹（Trajectory）——用户消息、模型回复、工具结果不断追加的消息历史。轨迹是"过去"的记录，但 Agent 需要感知的是"现在"：现在几点、用户在哪、当前任务进行到哪一步、系统还有什么资源可用。

书里给了一个极好的类比：手机顶部的状态栏。时间、电量、信号强度、通知数量——这些不是任何 App 的主界面内容，但你随时瞥一眼就掌握设备状态。Agent 状态栏（Agent Status Bar）就是在上下文中嵌入一段结构化元信息，让模型"瞥一眼"就知道运行状态，从而具备自我感知与自我调节能力。

1.2 状态栏的构成

一个实用的状态栏通常包含四类信息：

[当前时间] 2026-04-12 02:47 周六（凌晨，用户可能着急）
[环境信息] 生产环境 | 客服Agent v3.2 | 可用工具: 查订单/退款/开运维工单
[任务状态] 当前会话: 处理 VD-0231 柜机扫码失败投诉 | 已完成: 查询订单(成功) | 待办: 确认退款路径
[系统提示] 凌晨无人工客服，优先自助处理；退款超过5元需留待早班审核

看到了吗？凌晨两点这个信息进入上下文后，Agent 的行为逻辑自然改变：不再问"您现在遇到吗"，而是直接推进自助退款流程，并主动告知"人工客服 8:00 上线"。

1.3 状态更新两种实现与缓存代价

状态栏的实现有个关键工程细节：状态信息是动态的，每次调用都要更新，但它又必须出现在上下文里，这会不会打爆 KV Cache？

两种实现方式：

1. 置于系统提示词（前缀）中：每次刷新状态都要修改前缀 → 前缀一变，整个 KV Cache 失效重算，代价惨重。这就是"上下文可变，但缓存收益还在"难题的直接体现。
2. 置于上下文末尾（轨迹尾部）注入：把状态栏作为最新一条消息拼在对话末尾。前缀保持稳定、缓存命中保留，每轮只在尾部追加新状态。代价是历史轮次的状态栏消息会堆积在轨迹里——需要配合后文的压缩策略定期清理。

结论很清晰：动态信息放尾部，静态信息放前缀。状态栏放在轨迹末尾注入，是缓存友好型的标准做法。

另外提醒一句安全边界：状态栏信息被模型高度信任，一旦其中的摘要来自可被外部污染的数据源（比如直接把外部网页片段写进状态栏），这种信任就会被反向利用——状态栏也是提示注入的潜在入口，喂给它的数据必须来自可信计算路径。

二、上下文压缩：不只是长度问题

2.1 为什么要压缩

直觉上，压缩是因为上下文窗口装不下。但书里指出更本质的原因：无关信息过多会稀释模型的注意力。上下文学习（In-context Learning）的内部机制，学界的主流解释是"检索而非推理"——模型更像是在上下文里做模式匹配和内容定位，而不是沿着长链条做逻辑推演。这意味着：

• 上下文里塞了 50 轮无关对话，模型找到关键信息的难度剧增，输出质量随噪声上升而下降；
• 即使窗口是 1M token，也不应该把所有历史原文塞进去——长而不准，不如短而精。

所以压缩的目标有两个：控制长度（省钱、提速）和保信噪比（保准确率）。

2.2 压缩与 KV Cache：看似矛盾，实则互补

KV Cache 是推理优化的核心：前缀算过一次的注意力键值缓存起来，后续请求直接复用。压缩呢？压缩要改写历史消息，一改，对应位置的缓存全部作废。看起来压缩是缓存的敌人。

化解矛盾的关键还是第一章的老结构：上下文 = 静态前缀 + 轨迹。原则如下：

• 前缀（系统提示词+核心工具定义）保持稳定不动，缓存收益最大化；
• 轨迹是唯一允许压缩的区域；
• 压缩批量、低频进行：不是每轮都压，而是接近 token 预算时才把一段旧消息成批压缩成摘要，避免高频小改导致缓存反复失效；
• 当前任务的关键状态放在轨迹尾部（状态栏），保证"决定下一步行动所需的信息"永远不被压掉。

一句话：前缀不动吃缓存，轨迹批量做压缩，尾部永远是最新状态。

2.3 生产级分层压缩机制

"压缩"不是一个动作，而是一套分层次流水线：

层次	手段	适用对象	特点
L1 摘要	用小模型把旧对话轮次压缩成摘要	早期闲聊、已完成的子任务	语义保留，细节丢失，成本中等
L2 结构化	把摘要进一步固化为结构化记录（工单字段、关键事实清单）	有业务形状的信息	可检索、可回填，丢叙事
L3 截断	直接丢弃最旧的消息	彻底无关的内容	零成本零保留，慎用

分层的原则：越早的信息压缩越狠，越新的信息保留越完整。我们售货柜客服的实盘配置：50 轮以内的原文全保留；50 轮外的工单类信息抽取为结构化字段（订单号、退款金额、处理结论）存库；纯寒暄直接截断。Agent 需要细节时用检索工具回查——原文不进上下文，不代表原文被删除。

2.4 压缩策略设计原则

三条红线，缺一不可：

1. 不能悄悄丢掉决策所需信息：压缩必须保守，宁可多保留。判断标准是"如果下次调用工具需要这个信息，它在不在？"
2. 压缩点选在任务边界：一个投诉处理完、一个工单关闭后做压缩，而不是在任务中途动刀——中途压缩最容易丢上下文依赖。
3. 压缩后校验：生产上压缩完做一次关键事实核对（订单号、金额、承诺时间是否保留），这是用小成本避免大事故。

三、隔离优于压缩：子Agent上下文隔离

压缩是把信息变少，隔离是让信息根本不进来。书里的判断很鲜明：隔离优于压缩——能不进主上下文的，就别进来再花力气压掉。

机制：子 Agent（Sub-agent）拥有独立上下文。主 Agent 把一个任务委托出去——“去把这 30 页的设备维修手册里关于电磁锁故障的部分找出来”——子 Agent 在自己的上下文里啃完 30 页文档，只把结论（三行故障判断步骤）返回主上下文。脏活累活在隔离区完成，主上下文始终干净。

这在售货柜长会话客服场景里是刚需。想象一个用户两小时内先后反馈：扫码失败、扣款异常、App 卡顿、发票问题，每个问题都要拉订单日志、支付流水、设备状态截图。如果全在单一上下文里处理，轨迹早就爆炸且相互干扰。正确架构：

主 Agent（会话层：用户画像 + 4个问题的结论卡片，始终干净）
 ├── 子Agent 1: 扫码失败排查（独立上下文，吃完整设备日志，返回3行结论）
 ├── 子Agent 2: 扣款差异核查（独立上下文，返回金额+原因）
 ├── 子Agent 3: App问题（返回建议+已提交反馈单号）
 └── 子Agent 4: 发票（返回开票链接）

主 Agent 拿着四张结论卡片统一回复用户、统一承诺时间线。主上下文全程只有几百 token 的结论，而不是几万 token 的原始日志。

隔离与压缩配合使用：子 Agent 内部可以随意用激进压缩甚至一次性丢弃（反正结论已返回），主上下文只做温和的分层压缩。

小结

• Agent 状态栏 = 注入轨迹末尾的动态元信息，解决模型对时间、环境、任务进度的失明；动态信息放尾部、静态信息放前缀，才能保住 KV Cache；
• 压缩的本质诉求是信噪比而非单纯长度，因为上下文学习更接近"检索"而非"推理"；
• 分层压缩三件套：摘要 → 结构化 → 截断，越旧越狠，任务边界处动手，压缩后校验关键事实；
• 隔离优于压缩：子 Agent 在独立上下文干脏活，只带回结论，主上下文天然瘦身。

状态栏管"现在"，压缩管"瘦身"，而用户是谁、过去发生过什么，就交给记忆系统了。