一、背景问题
当前 WebUI 顶部的“背景信息卡片”严重干扰了主界面的布局节奏与视觉重心，信息层级明显放错了位置，需要进行重构。
当前问题主要体现在：
- 它占据了首屏最核心的位置与较大高度
-
直接挤压了对话内容、结果内容的展示空间
-
用户进入页面后，首先看到的是系统状态，而不是任务内容本身
- 它的视觉重量过高
-
边框、子卡片、指标块、数字信息过多
-
视觉噪音明显高于用户真正关心的消息与结果
-
导致“辅助信息”反而成为主视觉焦点
- 它承载的信息类型不属于主内容
-
当前展示内容本质上是：
-
背景信息
-
运行态
-
预算健康
-
上下文占用
-
工作快照 / 结果对象统计
-
这些都更接近“系统状态 / 调试信息 / 执行上下文”
-
它们不应该以主内容模块的形式长期占据主舞台
- 它在产品定位上更像辅助面板，而不是主模块
-
它应该被降级为“可感知、可查看、但不打扰”的辅助状态系统
-
而不是当前这种高存在感的大卡片展示
一句话概括：现在的背景信息卡片像“主角”，但它实际应该是“辅助状态”。
------
二、改造目标
请将当前顶部大面积“背景信息卡片”重构为一个嵌入输入框区域的上下文状态指示器，以更轻量、更克制的方式表达上下文占用情况，并提供按需展开的详情界面。
-
目标是把当前“纯数字 + 大卡片”的展示方式，升级为：
-
默认态：低干扰状态感知
-
Hover 态：快速理解
-
Click 态：深入查看
即：
-
默认只显示一个小型环形状态控件，不直接展示数字
-
通过环形进度表达当前上下文使用情况
-
Hover 时显示简要上下文信息
-
Click 时打开独立详情界面，承载完整上下文结构信息
------
三、核心设计原则
- 信息层级重构
这次改造不是简单“换一个样式”，而是要重新定义信息层级：
-
主内容：用户消息、Agent 输出、结果内容
-
辅助状态：上下文占用、运行预算、压缩状态、快照统计
辅助状态应退出首屏主舞台，进入输入区附近，以低干扰方式存在。
- 默认态克制
默认状态只解决“让用户知道系统还健康、上下文还可用”这个问题，不做过度展示。
- 渐进式披露
采用分层信息暴露方式：
-
默认：只看见状态存在
-
Hover：看见摘要
-
Click：看见详细结构
- 视觉角色降级
要让“上下文状态”从当前的主模块，降级为一个轻量但可靠的系统状态入口。
- 风格参考
整体风格参考：
-
现代 IDE Assistant
-
工具型 AI 工作台
关键词：
-
克制
-
轻量
-
专业
-
可扩展
-
不抢主内容注意力
------
四、具体交互需求
A. 默认态：输入框中的状态圆圈
请在输入框区域或其右下 / 右上附近，增加一个小型“上下文状态指示器”。
形式要求
-
使用环形进度圈作为主体视觉
-
默认不显示百分比数字
-
不展示大段文字
-
尺寸小，视觉低干扰
-
需要能与输入框自然融合，不破坏发送区布局
状态要求
-
环形进度与当前上下文占用比例实时同步
-
用户能通过视觉感知：
-
当前上下文仍然充足
-
正在逐步累积
-
接近阈值时需要注意
表达目标
- 默认态只做一件事：让用户“感知状态”，而不是“阅读数据”。
B. Hover 态：上下文摘要浮层
当鼠标悬停在状态圆圈上时，显示一个轻量信息浮层，交互形式参考你提供的图一。
浮层建议展示信息
- 背景信息窗口使用率
例如：11% 已用（剩余 89%）
- 已使用 token
例如：29k
- 总 token 容量
例如：258k
- 自动压缩状态
例如：系统正在自动压缩背景信息
文案要求
-
文字偏产品化
-
少用生硬技术词
-
信息要短、直观、易扫读
-
能让用户快速理解“现在状态是否健康”
UI 要求
-
浮层信息紧凑，但不拥挤
-
与整体暗色 / 浅色主题兼容
-
风格要与输入框、消息区一致
-
不做过重边框，不做复杂卡片嵌套
Hover 的目标
- Hover 只解决：“我想快速知道当前上下文是不是正常、用了多少、系统有没有在处理。”
C. Click 态：上下文详情面板
当用户点击该状态圆圈时，弹出一个独立详情界面，用于展示完整的上下文内部结构。
可以采用以下任一种形式：
-
Popover
-
Drawer
-
Modal
-
侧边详情面板
但要求这个界面足够承载更多结构化信息，适合作为后续扩展入口。
------
五、详情界面内容要求
详情面板至少包含以下三个核心模块：
- 工作快照
用于展示当前线程 / 当前轮次的工作状态摘要，例如：
-
快照版本
-
最近一次同步时间
-
当前工作阶段
-
已保留的核心上下文片段摘要
- 原文尾部
用于展示被保留在上下文尾部的原始文本内容或摘要内容，例如：
-
最近保留的消息尾部
-
最近拼接进入上下文的原文片段
-
可滚动查看
- 结果对象
用于展示当前上下文中已保留的结构化结果对象，例如：
-
已同步结果数
-
当前结果对象摘要
-
JSON / 结构化数据预览
-
可展开查看详情
------
六、详情界面设计要求
布局要求
-
三个模块要有明确分区与标题
-
支持滚动
-
支持后续扩展更多模块
-
信息密度可以高于 hover 浮层，但层级必须清晰
视觉要求
-
不要再做成“首页大卡片”的感觉
-
更像“系统状态详情 / 上下文检查器”
-
可参考 IDE 中的 inspector / debug panel 风格
使用目标
这个界面不是给所有用户持续盯着看的，而是给“有需要的时候”查看的，所以：
-
默认隐藏
-
一键展开
-
信息完整
-
阅读路径清晰
------
七、推荐的交互分层
请严格按照以下三层结构组织体验：
第 1 层：默认可见
一个小型环形状态指示器
作用：存在感提示
第 2 层：Hover
一个轻量摘要浮层
作用：快速理解当前上下文状态
第 3 层：Click
一个独立详情面板
作用：深入查看上下文内部结构
------
八、UI 改造方向
请基于现有页面结构做如下方向的调整：
- 删除 / 降级顶部大背景信息卡片
-
不再让其占据首屏主要高度
-
不再以大面积主卡片形式出现
-
其信息能力迁移到输入框附近的状态入口与详情面板中
- 保证主内容重新成为视觉中心
改造后，页面首屏注意力应重新聚焦到：
-
当前任务标题
-
对话内容
-
执行结果
-
用户输入区
而不是系统状态卡片。
- 让输入区承担“轻状态入口”角色
输入区除了输入与发送，还应承担“线程上下文状态入口”的角色，但必须保持轻量。
------
九、最终目标
这次改造的最终目标不是“把背景信息换个地方展示”，而是：
把一个错误占据主舞台的系统状态模块，重构成一个低干扰、可感知、可展开、符合现代 AI 工作台体验的辅助状态入口。
请围绕这个目标输出最终方案与代码。
------
十一、给 Coding Agent 的执行要求
请直接产出以下内容：
-
重构方案说明
-
组件结构图或组件列表
-
状态设计
-
交互流程
-
可运行前端代码
-
如何替换现有顶部背景信息卡片的接入说明
不要停留在概念建议层面，请直接给出可以落地实现的版本。
------
