Agent 状态栏解决什么问题？
- 现象: Agent 执行复杂任务时容易陷入无限循环、状态遗忘、目标偏离;
- 根源: 缺乏对环境当前状态的感知和对任务进展的跟踪;
- 定义: Agent 状态栏（Agent Status Bar） 是 Agent 框架把动态信息整理成结构化摘要并注入上下文的机制;
- 内容例子: “你已经打了 3 次电话”、“当前时间是 10:30”、“TODO 还剩 2 项未完成”;
- 定位: 不是对话主体内容（不属于用户消息、模型输出或工具结果），而是框架持续注入的状态摘要;
- 类比: 手机屏幕顶部始终显示时间、电量、信号、通知数量——不是 App 主界面内容，但随时可瞥一眼掌握设备状态;
- 区别于提示工程: 提示工程给的是静态指令，状态栏补的是运行过程中的动态自我感知;
状态栏为什么有效——核心机制是什么？
- 本质特性: 上下文学习更像检索而非推理——模型擅长从已有内容中查找信息，但不擅长主动归纳与总结;
- 边界: 这里说的是单次前向传播中如何处理已在上下文里的信息，并不否定模型可通过生成思维链完成多步思考;
- 比喻: 上下文窗口是一台只有一半的检索引擎;
- 强的一半: 检索能力极强——问什么，注意力就能从成千上万个 token 里把相关原始记录捞出来，相当于把 RAG 内置进每次前向传播;
- 缺的一半: 没有“提炼层”——上下文里的东西不会被自动数一遍、建索引或就地总结成结论;
- 代价: 任何“关于这些内容的结论”都要从原始记录现算一遍，代价随上下文内容量 N 增长;
- 实例: 系统要求拨打每个商家不超过 3 次，但打了 3 次后 Agent 经常数不清，又打第 4 次甚至陷入循环;
- 归因: “已打几次”的知识没有被提炼出来，而是以原始通话记录形式分散在 KV Cache 的向量表示中;
- 解法: 在工具调用结果中直接标明累计次数（“本次是第 3 次呼叫该商家”），模型立即发现已达限制;
- 机制总结: 把分散在上下文各处的隐式状态提炼为可直接使用的显式知识，以极低 token 成本呈现原本需扫描数千 token 才能获得的信息;
状态栏如何操纵注意力分配？
- 问题: 长上下文中注意力资源有限，关键信息可能得不到足够权重;
- 淹没效应: 早期设定的任务目标与关键约束容易被后续大量工具结果淹没;
- 衰减现象: 模型过度关注最近内容，对上下文中部信息产生注意力衰减;
- 解法: 把关键元信息以结构化形式放在上下文末尾，空间上更接近即将生成的新 token，因而获得更高注意力权重;
- 名称: 这是一种“强制性的注意力引导”;
- 呼应: 与 位置偏好 中“开头和结尾注意力更高”的结论一致;
验证状态栏效果的实验观察到什么？
- 场景: 客服 Agent 已拨打 Xfinity 3 次电话，中间穿插网络搜索，用户追问“能不能再打电话催促一下？”;
- 对照组 A（无状态栏）: 热力图显示注意力高度分散，在三次电话调用区域形成聚焦点，思考 token 体现出数数和统计的过程;
- 对照组 B（有状态栏）: 在轨迹末尾添加
<agent_status> 块，列出工具调用次数（Xfinity: 3 次）与约束检查（已达 3/3 上限）;
- 结果 B: 注意力高度集中到状态栏信息上，思考过程直接使用已提炼好的信息，不再从原始数据统计;
- 小模型差异: 对 Qwen3-0.6B 这样的小模型，对照组 A 经常违反约束继续拨打，对照组 B 则能稳定遵从;
- 核心结论: 提供一条提前算好的状态栏后，较小开源模型的准确率可以接近前沿大模型;
- 效率结论: 状态栏让每次迭代的思考 token 量、延迟和花费均降低约一个数量级;
- 增长曲线: 不带状态栏时每次查询的思考量随上下文变长而持续增长；带上后变得基本恒定;