# 设备页批量操作设计方案

## 目标

在新的后台信息架构下，为多设备统一运维提供一个清晰、低干扰、可追踪的入口。

这次设计不新增一级导航，不再引入新的独立“批量操作页面”，而是把多设备统一操作收纳到 `设备` 模块内部，作为设备总览页的一种工作模式。

设计目标有三条：

1. 让用户在设备总览页就能完成常见的多设备统一操作
2. 不破坏当前已经收敛好的四个一级模块结构
3. 保证“发起操作”和“查看执行结果”仍然职责分离

## 为什么不放进主菜单

多设备统一操作当然重要，但它不是一个独立业务域。

它本质上仍然属于“设备运维动作”，只是作用对象从一台设备变成多台设备。如果把它单独提成一级菜单，会立刻带来两个问题：

- 主菜单又开始按“动作类型”膨胀，而不是按“业务对象”组织
- 用户会在“设备”“批量操作”“操作审计”之间反复跳转，心智重新变乱

因此，这个能力不应该进入主菜单。

最合理的位置，是把它作为 `设备总览` 页中的批量工作模式：先看设备，再选设备，再执行统一操作。

## 入口定位

入口放在 `设备` 页主列表上方，以“按需浮现”的方式出现。

默认状态下：

- 设备总览保持简洁
- 不显示任何批量操作条
- 用户只看到设备状态和单设备快捷入口

当用户勾选 1 台或多台设备后：

- 页面顶部出现批量操作条
- 操作条显示已选设备数量
- 只展示当前阶段最重要的批量动作

这种模式的核心价值是：

- 不勾选时，页面完全是总览页
- 勾选后，页面自然切换到“批量运维模式”
- 入口不冗余，也不会占据主导航资源

## 页面结构

`设备` 页继续保持现有主结构：

1. 顶部摘要区
2. 设备列表

在此基础上，加入一个新的中间层：

3. 批量操作条

最终结构如下：

1. 顶部摘要区  
   用于整体状态判断和快速筛选

2. 批量操作条  
   仅在用户选择设备后出现

3. 设备列表  
   负责设备选择、状态查看、进入单设备详情和控制页

这样可以保证页面仍然只回答一个核心问题：  
“当前有哪些设备，我要不要对其中几台一起做操作”

## 批量操作条设计

批量操作条应该是一条紧凑、稳定、图标优先的操作带，而不是新的大页面。

它至少包含以下元素：

- 已选设备数量
- 清空选择
- 服务操作组
- 配置操作组
- 发起后查看任务结果的入口

### 服务操作组

第一版只放最常用、风险最可控的统一操作：

- 启动服务
- 重启服务
- 停止服务
- 重载服务

这些动作直接对应 agent 已有的多设备任务能力，概念清楚，用户也容易理解。

### 配置操作组

配置相关动作也放在这条操作带里，但第一版要严格收边界，不把它做成复杂的发布系统。

第一版建议只支持：

- 统一下发候选配置
- 统一应用候选配置
- 统一回滚到上一份配置

这里的“统一下发候选配置”不是让用户在设备总览页直接编辑大段 JSON，而是进入一个轻量的批量配置面板，在里面完成配置选择与确认。

## 批量配置面板

从设备总览页点击“统一下发候选配置”后，打开批量配置面板。

这个面板不是一级页面，也不是长期停留的工作区，它更适合作为抽屉或模态层，承接一次明确的配置发布动作。

面板只回答三个问题：

1. 要发给哪些设备
2. 这次配置从哪里来
3. 是否立即创建任务

### 第一版支持的配置来源

为了和当前的模板化配置体系保持一致，第一版只允许以下来源：

- 选择模板
- 选择 profile
- 选择一个或多个 overlay

必要时允许展示生成后的配置摘要，但不在这个面板里默认展开完整 JSON。

### 面板默认展示内容

默认只显示运维真正需要确认的摘要：

- 目标设备数量
- 目标设备名称列表摘要
- 模板名
- profile 名
- overlay 列表
- 生成后的 `config_id`
- 生成后的 `config_version`
- 配置摘要 SHA

### 面板收纳规则

以下内容不在主视图大面积展开：

- 完整 JSON
- 原始文件路径
- 渲染细节
- 原始响应体

这些内容如果要看，应进入折叠区或技术详情抽屉。

## 结果呈现与职责分离

批量操作发起后，不在设备总览页里展开每台设备的完整执行日志。

职责划分必须明确：

- `设备` 页负责发起批量动作
- `操作审计` 负责查看任务执行过程和结果

因此，批量操作后的结果呈现只分两层：

### 第一层：设备页即时反馈

用户发起操作后，设备页顶部给出简洁反馈：

- 任务已创建
- 任务类型
- 目标设备数
- 当前任务状态摘要

并提供一个明确入口进入任务详情或操作审计页。

### 第二层：审计页详细结果

详细结果统一在任务详情页或操作审计页中查看，包括：

- 每台设备是否执行成功
- 调用了哪个 agent 接口
- 返回了什么结果
- 哪台设备失败
- 失败原因是什么

这样可以避免总览页被“执行细节”淹没。

## 与现有能力接口的关系

这次设计建立在当前已经存在的多设备任务能力之上，不需要重新发明一套后端模型。

当前能力层已具备的统一操作包括：

- `media_start`
- `media_restart`
- `media_stop`
- `reload`
- `rollback`
- `config_apply`

因此这次实现重点不是重写任务系统，而是把这些能力纳入新的主线 UI：

- 让批量服务操作成为设备页的正式入口
- 让批量配置下发有明确的配置选择面板
- 让任务结果自然落到操作审计中

## 状态与可用性规则

批量操作必须遵守一套简单、稳定的可用性规则，避免页面显得“什么都能点”。

### 设备选择规则

- 未选择设备时，不显示批量操作条
- 只选择 1 台设备时，也允许使用批量操作条，但视觉上不强调“批量”，避免用户困惑
- 选择多台设备时，明确显示“已选 N 台”

### 动作可用性规则

- 服务类动作始终可见，但在无设备选中时不显示
- 配置“应用候选配置”和“回滚到上一份配置”允许直接发起
- “统一下发候选配置”必须先完成配置选择与确认

### 反馈规则

- 任务创建成功后，立即给出任务摘要
- 任务创建失败时，给出简洁错误，不直接把原始技术响应堆在主页面
- 技术细节进入折叠区或审计页

## 不做的事情

为了控制范围，第一版明确不做下面这些内容：

- 不新增一级菜单“批量操作”
- 不做独立的“大屏式任务调度中心”
- 不在设备总览页直接编辑完整 JSON
- 不在设备总览页展示每台设备的详细执行日志
- 不在第一版中加入复杂的发布审批、分批灰度、自动回滚策略

这些都可能以后再做，但不属于当前最短路径。

## 实现边界

这次实现建议分两步：

### 第一步：设备页批量服务操作正式化

包括：

- 设备列表支持稳定多选
- 出现批量操作条
- 接入统一的服务操作任务创建
- 操作后跳到任务详情或审计入口

### 第二步：批量配置下发正式化

包括：

- 新增批量配置面板
- 以模板 + profile + overlay 生成配置摘要
- 创建 `config_apply` 任务
- 在任务视图中查看各设备结果

这样能先把最稳的能力做出来，再接配置下发，不会把第一版拖得过大。

## 验证方式

本设计的验证分为两类：

### 本地验证

- `设备` 页在未选择设备时保持干净
- 选择设备后出现批量操作条
- 批量服务操作能成功创建任务
- 批量配置面板能正确展示模板 / profile / overlay 摘要
- 成功和失败反馈不会在总览页造成信息堆积

### 运行侧验证

需要在真实 agent 环境下确认：

- 多设备服务操作是否按预期逐台执行
- 批量配置下发到不同设备时是否正确到达 agent
- 任务结果与审计记录是否一致
- UI 摘要是否能正确反映各设备执行状态

## 最终结论

多设备统一操作应该是 `设备` 页里的批量工作模式，而不是主菜单一级页面。

这条设计路径有三个优点：

1. 不破坏已经稳定下来的四个一级模块
2. 让用户的操作路径保持自然：看设备、选设备、做操作
3. 保证总览、操作、审计三者边界清楚，不再到处重复显示类似信息

这也是当前最符合本项目规模和运维目标的方案。
