Agent 状态栏之所以有效，源于注意力机制的一个本质特性：上下文学习更像检索而非推理——模型擅长从已有内容中查找信息，但不擅长主动归纳和总结（这里说的是模型在单次前向传播中如何消费已经在上下文里的信息，并不否定模型可以通过生成思维链来完成多步思考）。 一个更形象的说法是：**上下文窗口是一台只有一半的检索引擎**。它“检索”的这一半非常强——你问什么，注意力就能从成千上万个 token 里把相关的原始记录捞出来，相当于把检索增强生成（RAG）内置进了每一次前向传播。但它缺了另一半：**没有“提炼层”**。上下文里的东西从来不会被自动数一遍、建个索引、或就地总结成一条结论；任何“关于这些内容的结论”——一共多少条、有没有超标、进展到哪一步——模型每次要用，都得从原始记录里现算一遍。而“现算一遍”的代价，会随上下文里堆积的内容量（记作 N）一起往上涨。 考虑一个实际场景：Agent 需要打电话处理业务，系统提示词要求拨打每个商家不超过 3 次。但打了 3 次之后，Agent 经常数不清到底打了几次，又打了第 4 次，甚至陷入循环反复拨打同一个电话。 问题的根源在于：关于“已经打了几次”的知识没有被自动提炼出来，而是以原始通话记录的形式分散在 KV Cache 的向量表示中。模型每次做决策都必须花费额外的思考 token 去扫描上下文重新统计，这个过程效率极低且错误率很高。 而当我们在每个电话的工具调用结果中直接加入重复呼叫次数（如“本次是第 3 次呼叫该商家”），模型就能立即发现已达到限制，不再继续呼叫，错误率大幅降低。 这种机制的本质是**把分散在上下文各处的隐式状态提炼为可直接使用的显式知识**。原始轨迹中的信息是高度冗余的——大量的 token 中只包含少量关键的状态信息。Agent 状态栏主动提取这些关键状态，以极低的额外 token 成本，呈现出原本需要扫描数千个 token 才能获得的信息。 此外，在长上下文场景中，模型的注意力资源是有限的。随着上下文长度的增加，模型必须在更多的候选内容之间分配注意力，导致关键信息可能无法获得足够的注意力权重。特别是在复杂的 Agent 轨迹中，早期设定的任务目标和关键约束容易被后续大量的工具调用结果所淹没。模型会过度关注最近的上下文内容，而对位于上下文中部的信息产生“注意力衰减”现象。 Agent 状态栏正是通过显式地操纵注意力分配来解决这一问题。当我们将关键的元信息以结构化的形式放置在上下文末尾时，这些信息在空间上更接近模型即将生成的新 token，因而能获得更高的注意力权重——这是一种“强制性的注意力引导”。