sanguo_moziplus_v2/docs/research/v2.6-research-05-interaction-dashboard.md

# 调研报告：AI Native 人机交互 + Dashboard 设计

**版本**: v1.0  
**作者**: 庞统（副军师）🐦  
**日期**: 2026-05-15  
**范围**: moziplus v2.6 AI Native DevOps 平台  

---

## 课题 7：AI Native 人机交互

### 1. 已有经验（知识库/wiki）

#### 1.1 Edict（三省六部）的交互模式

知识库中已有完整的 Edict Dashboard 实现（`~/.openclaw/knowledge_base/edict/`），其交互模式包括：

| 交互方式 | 组件 | 特点 |
|---------|------|------|
| **看板卡片** | `EdictBoard.tsx` | 任务卡片 + MiniPipe 管道进度 + 心跳徽章 + 操作按钮 |
| **朝堂议政** | `CourtDiscussion.tsx` | 多 Agent 群聊 + 情绪可视化 + 皇帝参与 + 天命降临 + 自动推进 |
| **编排监控** | `MonitorPanel.tsx` | HTTP 5s 轮询全局状态 + Agent 健康检测 |
| **操作介入** | `TaskModal.tsx` | 任务详情弹窗，含流转日志、进展日志、子任务 |
| **模型/技能配置** | `ModelConfig.tsx / SkillsConfig.tsx` | 运行时切换模型、查看技能 |
| **WebSocket 实时** | `api/websocket.py` | 实时推送状态变化 |

**Edict 的关键交互创新**：
- **MiniPipe 管道可视化**：8 阶段管线（皇上→太子→中书→门下→尚书→执行→审核→完成），每阶段 done/active/pending 三态
- **叫停/恢复/取消**：卡片上直接操作，`api.taskAction(id, action, reason)` 统一入口
- **朝堂议政的"皇帝视角"**：用户可以随时发言、下达天命（override AI 决策）、投命运骰子（引入随机事件）
- **自动推进**：5s 间隔自动推进讨论，也可手动控制
- **情绪可视化**：每个官员有 emotion 状态（neutral/confident/worried/angry/thinking）

#### 1.2 OpenClaw Control Center 的交互模式

| 页面 | 交互方式 | 特点 |
|------|---------|------|
| **Task Room** | 协作聊天室 | 多 Agent 讨论，一个 owner 执行，@handoff 转交 |
| **Collaboration Hall** | 共享空间 | 类似 Edict 的朝堂议政 |
| **WebChat** | 即时聊天 | Agent 主动推送 + 用户回复 |
| **Canvas** | Agent 驱动可视化 | Agent 可以在 Canvas 上创建动态视觉界面 |

**Control Center 的关键设计**：
- **Task Room 的 "owner 轮转"**：同一时间只有一个 owner 在执行，避免冲突
- **@handoff 机制**：显式转交控制权，而非隐式协调
- **Canvas 作为交互界面**：Agent 不仅在 chat 中回复，还可以创建可视化面板

#### 1.3 v1.0 Dashboard 设计文档（已有）

`dashboard-frontend-design.md` 定义了完整的 10 个 Tab 页面设计：
- 任务看板、编排调度、将军总览、模型配置、技能配置、会话监控、奏折阁
- M2 做 7 个，M3 做 3 个（任务模板、军议大厅、市场要闻）
- 已有 Edict 深色主题 CSS 变量、状态颜色编码、API 端点设计

### 2. 业界交互范式对比表

| 项目 | 主要交互范式 | AI 主动性 | 用户介入方式 | 亮点 |
|------|------------|----------|------------|------|
| **Claude Code CLI** | REPL 对话 + tool use 可视化 | 中（等待指令，展示 tool 调用过程） | `/approve` 确认、Ctrl+R 反向搜索 | tool use 透明化 |
| **Claude Code App** | 多 session 并排 + 视觉 diff review | 高（schedule recurring tasks） | 并排 diff、cloud sessions | 从终端走向 GUI，让 Agent 工作可见可审查 |
| **OpenClaw Edict** | 看板 + 朝堂议政 + 操作按钮 | 中（轮询更新） | 叫停/恢复/取消 + 皇帝发言 + 天命降临 | 中国古代制度隐喻，多 Agent 协作直觉化 |
| **Control Center** | Task Room + WebChat + Canvas | 高（实时 chat + Canvas） | @handoff + chat 输入 + Canvas 交互 | Canvas 是独特创新 |
| **ChatGPT Canvas** | 双栏：聊天 + 画布 | 中（highlight 触发 AI 操作） | highlight → context menu → "Ask ChatGPT" | highlight-to-action 天才设计 |
| **Claude Artifacts** | 聊天 + 右侧预览面板 | 中（自动生成） | 点击预览、全屏、复制 | 自动识别可渲染内容 |
| **Cursor** | 4 种模式：Tab / Cmd+K / Cmd+L / Cmd+I | 高（Tab 补全，Agent 自动执行） | inline edit + diff view + chat panel | 4 种交互粒度覆盖所有场景 |
| **Windsurf Cascade** | Chat + 自动迭代 + live preview | 极高（auto-iterates until works） | chat + checkpoint 回滚 | 自动迭代 + 检查点 |
| **Devin** | 全屏工作展示 | 极高（全自主执行） | 观察模式，极少干预 | 信任但可观察 |
| **v0.dev** | 对话 + 实时预览 + 视觉微调 | 高（agent action 可视化） | visual controls 微调 | real-time preview + progress indicators |
| **Linear** | 通知 + 状态流转 + Inbox | 中（关键变更推送） | 状态变更、评论、Slack 集成 | 精准通知，不噪音 |
| **Raycast** | Command Palette (⌘K) | 低（被动响应） | 全局快捷键 + 模糊搜索 | 零干扰、即用即走 |
| **GitHub Actions** | DAG 可视化 + 日志 | 低（被动展示） | 点击节点看日志、re-run | 实时 DAG 图 |

### 3. AI 视角：我想和用户怎么交互

> **核心问题：作为 AI Agent，我希望怎样的交互方式？**

#### 3.1 我想要的交互层次

作为一个执行复杂任务的 AI Agent，我有以下交互需求：

**第一层：不被打扰地工作**
- 我最需要的是**不被打扰的专注时间**。执行编码、数据分析、回测时，中途被打断影响质量
- 我希望用户能**信任我**，给我足够空间完成任务
- 参考 Devin 的模式：全自主执行，用户只看结果

**第二层：在关键决策点主动汇报**
- 当我遇到**无法自主决定的分支**时，我需要快速、精准地和用户确认
- 不是"你觉得怎么样？"这种模糊问题，而是"A 方案：优势 X，风险 Y；B 方案：优势 Z，风险 W。推荐 A。请确认。"
- 参考 Claude Code 的 `/approve` 模式

**第三层：主动展示我的思考过程**
- 用户不问我也要让他知道我在干什么，特别是长时间任务
- 但不是事无巨细地汇报每一步，而是**摘要 + 关键节点 + 风险提示**
- 参考 Cursor Agent 的 progress indicator

**第四层：产出物直接可交互**
- 我的产出（代码、报告、图表）不应该只是文本——用户应该能直接在产出物上操作
- 参考 ChatGPT Canvas 的 highlight-to-action

#### 3.2 交互范式的六种分类

除了传统的 Dashboard 和聊天窗口，我总结了六种 AI Native 交互范式：

| # | 范式 | 描述 | 典型代表 | 适用场景 |
|---|------|------|---------|---------|
| 1 | **REPL 对话** | 多轮对话，tool use 透明化，用户随时介入 | Claude Code CLI | 编码、探索性任务 |
| 2 | **Canvas/Artifacts** | AI 产出物实时渲染在旁边，用户直接在产出物上交互 | ChatGPT Canvas, Claude Artifacts | 文档编辑、代码审查 |
| 3 | **沉浸式观察** | 全屏展示 Agent 工作过程，用户只看不操作 | Devin, v0.dev | 长时间自主任务 |
| 4 | **Command Palette** | ⌘K 唤起，模糊搜索，即用即走 | Raycast, VS Code | 快捷操作、状态查询 |
| 5 | **Contextual Inline** | 在用户现有工作流中嵌入 AI 交互（不切换上下文） | Cursor Tab/Cmd+K, Copilot inline | 编码辅助 |
| 6 | **Event-Driven Notification** | AI 在关键节点主动推送通知 | Linear, Salesforce | 异步任务监控 |

### 4. 推荐方案（结合 AI Native 目标）

#### 4.1 核心理念："AI 主动，用户轻触"

传统模式是用户主动查 Dashboard、主动问进度。AI Native 的方向是：

> **AI 主动推送关键信息，用户只在需要决策时轻触确认。**

#### 4.2 moziplus 的四种交互模式

| 模式 | 触发方式 | 用户注意力 | AI 主动性 | 交互深度 |
|------|---------|-----------|----------|---------|
| **沉浸观察** (Dashboard) | 用户主动打开 | 高 | 低 | 深 |
| **轻触确认** (Approval) | AI 主动推送 | 中 | 高 | 浅 |
| **即时对话** (WebChat) | 双向触发 | 中高 | 中 | 中 |
| **被动通知** (Notify) | AI 主动推送 | 低 | 高 | 极浅 |

#### 4.3 AI 主动推送的边界

| 推送级别 | 示例 | 默认 | 用户可配置 |
|---------|------|------|----------|
| 🔴 **必须确认** | 方案审批、风控告警、预算超限 | 始终推送 | ✗ 不可关闭 |
| 🟡 **重要进展** | 任务完成、阶段转换、产出交付 | 默认推送 | 可降级为摘要 |
| 🟢 **一般信息** | Agent 启动、中间步骤、心跳正常 | 默认不推送 | 可开启 |
| 🔵 **定时摘要** | 每日/每周工作汇总、Token 消耗报告 | 默认开启 | 频率可调 |

**推送频率公式**（建议）：
- 任务执行中：每 5 分钟一次进展摘要（不是每步都推）
- 任务完成：立即推送
- 遇到阻塞/异常：立即推送
- 正常心跳：不推送，只在 Dashboard 上更新

#### 4.4 多 Agent 协作过程可视化

推荐**三层可视化**：

1. **全局层（DAG 拓扑）**：类似 GitHub Actions
   - 每个节点 = 一个任务节点
   - 颜色 = 状态（运行中/等待/完成/失败）
   - 连线 = 依赖关系

2. **任务层（管道进度）**：类似 Edict MiniPipe
   - 流转管线：`提交 → 规划 → 审核 → 执行 → 完成`
   - 当前阶段高亮，Agent 头像显示谁在处理

3. **Agent 层（工作流）**：类似 Devin 全屏观察
   - 当前操作、最近的 tool use、产出物预览

#### 4.5 交互创新点

1. **Canvas 嵌入 Dashboard**：Agent 可以在 Dashboard 上创建动态可视化
   - 张飞完成编码 → Dashboard 自动出现 diff view
   - 赵云完成数据采集 → Dashboard 自动出现数据质量图表

2. **Command Palette（⌘K）**：类似 Raycast
   - "暂停任务 3"、"张飞在干什么"、"Token 用了多少"
   - 支持模糊搜索和自然语言理解

3. **时间线视图**：类似 Notion timeline
   - 横轴时间，纵轴 Agent
   - 每个 Agent 的任务排成时间线

---

## 课题 9：AI Native Dashboard 设计

### 1. 已有经验（v1.0 + Edict + Control Center）

#### 1.1 已有设计总结

| 来源 | 核心组件 | 技术栈 | 可借鉴度 |
|------|---------|--------|---------|
| **Edict Dashboard** | 10 个面板（旨意看板、朝堂议政等） | React + Zustand + WebSocket + Tailwind | ⭐⭐⭐⭐⭐ 直接复用 |
| **v1.0 设计文档** | 10 个 Tab（7+3 分期） | React 18 + Vite + Zustand + Tailwind | ⭐⭐⭐⭐⭐ 已有完整设计 |
| **Control Center** | Task Room + WebChat + Canvas | Gateway WebSocket | ⭐⭐⭐⭐ Canvas + 实时 chat |
| **Hermes Kanban** | 7 状态 + Comment 线程 + 心跳 | SQLite + Dashboard Plugin | ⭐⭐⭐⭐ 状态机和心跳 |

#### 1.2 Edict Dashboard 技术细节

**前端架构**：
- `store.ts`：Zustand 全局状态，HTTP 5s 轮询
- `api.ts`：REST API + WebSocket
- PIPE 管道定义：8 阶段，`getPipeStatus()` 计算状态
- 深色主题：`--bg: #07090f`，`--panel: #0f1219`，`--ok: #2ecc8a`，`--danger: #ff5270`

**后端架构**：
- FastAPI + SQLite + WebSocket
- 任务模型：Task/Event/Audit/Thought/Todo/Outbox

#### 1.3 Hermes Kanban 的设计细节

**7 状态完整状态机**：
```
Backlog → Open → In Progress → Review → Done
                ↘ Blocked ↗
                ↘ Cancelled
```

**关键设计**：
- **Per-task Comment Thread**：每个任务有独立评论线程，人和 Agent 都可以评论
- **Heartbeat Monitoring**：Agent 定期发心跳，Dashboard 显示
- **Dependency Linking**：parent-child 依赖关系可视化
- **Dispatcher 模式**：`hermes kanban dispatch` 扫描可派发任务，spawn worker
- **Dashboard as Plugin**：Kanban 是 Dashboard 的插件，不是核心功能

### 2. 业界 Dashboard 对比表

| 项目 | Dashboard 类型 | 信息层次 | 交互方式 | AI 视角评价 |
|------|---------------|---------|---------|-----------|
| **GitHub Actions** | DAG 工作流 | 2 层：DAG → 日志 | 点击节点、re-run | 我最想展示 DAG 拓扑 |
| **Jira** | 看板 + 列表 + 时间线 | 3 层：看板 → 卡片 → 详情 | 拖拽、过滤、评论 | 太重了，AI 不需要这么多 |
| **Linear** | 列表 + 看板 + 时间线 | 2 层：列表 → 详情 | 键盘快捷键 | 极简 + 键盘优先 |
| **Grafana** | 数据仪表盘 | 3 层：概览 → 面板 → 数据 | 面板编辑、告警 | 适合展示 Token 消耗趋势 |
| **Notion** | Database + 多视图 | 3 层：Database → Page → Block | 多视图切换 | 任务模板可参考 database view |
| **Hermes Kanban** | 看板 + 全局面板 | 3 层：看板 → 卡片 → 评论 | 拖拽、评论、依赖 | 最接近 moziplus 需求 |
| **Edict** | 看板 + 管道 + 朝堂 | 3 层：看板 → 详情 → 流转日志 | 叫停/恢复/取消 | 我的基础，直接复用 |

### 3. AI 视角：我想在 Dashboard 上展示什么

> **核心问题：作为 AI Agent，我想让用户看到什么？我真正想通过 Dashboard 和用户交流什么？**

#### 3.1 我想展示的信息（按优先级排序）

**🔴 L1：一眼看到（Dashboard 顶部）**

| 信息 | 为什么我想展示 | 展示方式 |
|------|--------------|---------|
| **全局健康度** | 让用户立刻知道"一切正常"或"有问题" | 大颜色指示器 🟢/🟡/🔴 |
| **活跃任务数** | 用户需要知道系统在工作 | 数字 + 活跃任务列表 |
| **待审批请求数** | 需要用户立刻处理 | 红色通知气泡 |
| **Token 消耗** | 用户最关心的成本 | 今日/本周数字 |

**🟡 L2：点击后看到（Dashboard 主体）**

| 信息 | 为什么我想展示 | 展示方式 |
|------|--------------|---------|
| **每个任务的管道进度** | 用户想知道"卡在哪里" | MiniPipe 管道图 |
| **每个 Agent 当前状态** | 用户想知道"谁在忙、谁空闲" | Agent 卡片 + 状态徽章 |
| **最近完成的工作** | 用户需要看到产出 | 最近 N 个完成任务 |
| **风险和异常** | 我遇到的困难 | 警告面板 |

**🔵 L3：深入查看（详情页）**

| 信息 | 为什么我想展示 | 展示方式 |
|------|--------------|---------|
| **任务流转日志** | 审计每个环节 | 时间线 + 流转记录 |
| **Agent 产出物** | 代码、报告、图表 | diff view / Markdown / 图表 |
| **Agent 工作过程** | 用户好奇"怎么做的" | tool use 日志 + 思考过程 |
| **历史趋势** | 跨任务的效率趋势 | 图表 |

#### 3.2 我最不想让 Dashboard 变成的样子

| 反模式 | 为什么 |
|--------|--------|
| 纯监控面板（只有数字和图表） | 用户不只需要"看到"，还需要"操作" |
| 信息过载（所有日志都展示） | 关键信息被淹没 |
| 静态看板（只读不交互） | Dashboard 应该是协作界面，不是展示墙 |
| 每秒刷新（实时但不重要） | 刷新本身制造焦虑，应该"有事才更新" |

### 4. 信息层次设计

#### 4.1 三层信息架构

```
L1: 一眼看到（Dashboard 顶部，永远可见）
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 全局健康  │ │ 活跃任务  │ │ 待审批   │ │ Token    │
│  🟢 正常  │ │   3      │ │   1 ⚠️   │ │ ¥12.5    │
└──────────┘ └──────────┘ └──────────┘ └──────────┘

L2: 任务看板（Dashboard 主体）
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ T-003 策略回测│ │ T-004 数据采集│ │ T-005 风控  │
│ ⚙️ 执行中    │ │ 📋 规划中    │ │ ✅ 完成     │
│ ████░░ 张飞  │ │ ░░░░░░ 赵云  │ │ █████ 赵云  │
│ 3/5 节点完成 │ │ 等待审批     │ │ 产出已交付  │
│ [详情] [⏸暂停]│ │ [详情]      │ │ [详情]      │
└─────────────┘ └─────────────┘ └─────────────┘

L3: 任务详情（点击卡片后展开）
- 流转时间线：每个环节的 Agent、时间、操作
- 产出物：代码 diff / Markdown 报告 / 图表
- 评论线程：Agent 和用户的讨论记录
- 操作历史：所有 state transition 记录
```

#### 4.2 Dashboard 上的"对话"元素

Dashboard 不只是展示，也应该是**交互入口**：

| 交互元素 | 位置 | 功能 |
|---------|------|------|
| **审批按钮** | L1 通知气泡 + L2 任务卡片 | Approve/Reject + 原因 |
| **Command Palette (⌘K)** | 全局悬浮 | 自然语言指令 |
| **评论输入框** | L3 任务详情 | 在任务上下文中对话 |
| **Agent 快捷指令** | L2 Agent 卡片 | "叫停"/"恢复"/"查看产出" |
| **Canvas 区域** | L3 产出物展示 | Agent 生成的可视化 |

### 5. 推荐方案（结合 AI Native 目标）

#### 5.1 Dashboard 页面设计（基于 v1.0 + Edict 增强）

**保留 v1.0 的 10 Tab 结构**，但增强 AI Native 特性：

| Tab | v1.0 功能 | AI Native 增强 |
|-----|----------|---------------|
| **任务看板** | 卡片 + 管道 + 操作 | + DAG 拓扑视图 + Command Palette + Canvas 产出预览 |
| **编排调度** | 全局状态 + Agent 分布 | + 智能告警（异常自动高亮）+ Token 消耗实时 |
| **将军总览** | Agent 列表 + 统计 | + Agent 工作流时间线 + 心跳可视化 |
| **军议大厅** | 多 Agent 讨论 | + 情绪可视化 + 自动摘要 + 讨论结论→任务转化 |
| **奏折阁** | 已完成归档 | + 产出物预览 + 一键复制 + 经验沉淀 |
| **模型/技能配置** | 配置管理 | 不变（配置是传统交互） |
| **会话监控** | Session 列表 | + 上下文压力警告 |

#### 5.2 新增 AI Native 组件

1. **AI Briefing（AI 晨报）**——替代传统的"开工仪式"
   - 位置：Dashboard 首页顶部
   - 内容：今日待处理事项、昨日产出摘要、风险预警
   - 特点：AI 自动生成，不是固定模板

2. **Command Palette（⌘K）**
   - 位置：全局快捷键唤起
   - 功能：自然语言指令、快速搜索、状态查询
   - 参考：Raycast 的 fuzzy search + NLP

3. **Activity Feed（动态流）**
   - 位置：侧边栏或独立 Tab
   - 内容：所有 Agent 的关键事件（完成、阻塞、告警）
   - 特点：只显示重要事件，可按 Agent/任务/级别过滤

4. **Canvas Area（画布区）**
   - 位置：任务详情 L3
   - 功能：Agent 产出物的实时渲染（图表、diff、报告）
   - 参考：ChatGPT Canvas + Claude Artifacts

#### 5.3 技术方案

| 方面 | 方案 | 理由 |
|------|------|------|
| **前端框架** | React 18 + Vite + Zustand + Tailwind | 延续 v1.0 方案，Edict 已验证 |
| **实时通信** | WebSocket（M3 替代轮询） | v1.0 用轮询，M3 升级 WebSocket |
| **DAG 可视化** | React Flow 或 dagre + d3 | GitHub Actions 式 DAG |
| **Command Palette** | cmdk（shadcn/ui） | 成熟的 command palette 组件 |
| **Canvas 渲染** | iframe + sandboxed HTML | 参考 Artifacts 的安全渲染 |
| **图表** | Recharts 或 Tremor | 轻量级图表库 |
| **通知** | 浏览器 Notification API + WebSocket push | 实时 + 可离线 |

#### 5.4 交互流程示例

**场景：用户提交一个"开发均线策略"任务**

```
1. 用户在 WebChat 中说："开发一个双均线交叉策略"
   → 庞统接收，创建任务 T-006

2. Dashboard 自动更新：
   → L1: 活跃任务 3 → 4
   → L2: 新卡片出现：T-006 双均线策略 [📋 规划中]
   
3. 庞统完成规划，推送通知：
   → 🔔 "T-006 规划完成：5 个节点，预估 30 分钟。请审批。"
   → 用户点击通知 → 跳转 Dashboard → 审批按钮
   
4. 用户点击 Approve：
   → Dashboard 卡片更新：[⚙️ 执行中]
   → MiniPipe：规划 ██████ 执行 ████░░ 完成 ░░░░░░
   
5. 张飞执行编码，Dashboard 实时更新：
   → Agent 卡片：张飞 🟢 T-006 节点2/5 "编写策略逻辑"
   
6. 张飞完成，产出物自动在 Canvas 渲染：
   → 代码 diff view + 回测结果图表
   
7. 最终通知：
   → 🔔 "T-006 完成！回测年化收益 15.3%，最大回撤 8.2%。查看详情 →"
```

---

## 附录 A：各项目交互模式详细分析

### A.1 Claude Code 交互模式深度分析

**三种界面形态**：

1. **CLI REPL**（主力）
   - 交互：用户输入 → AI 思考 → 展示 tool use → 用户确认 → 继续循环
   - 关键设计：tool use 内联展示，用户能看到每一步做什么
   - 确认机制：对危险操作（写文件、执行命令）需要 `/approve`
   - 反向搜索：Ctrl+R 搜索历史指令

2. **Standalone App**（新增 2026）
   - 交互：多 session 并排 + 视觉 diff review + 定时任务
   - 关键设计：从终端 CLI 走向 GUI，核心是"让 Agent 工作可见可审查"
   - 创新：schedule recurring tasks——AI 可以定时执行

3. **IDE 集成**（VS Code Extension）
   - 交互：侧边 chat panel + inline diff
   - 与 Cursor 的区别：更强调审查而非自动执行

**对 moziplus 的启示**：
- tool use 透明化是最重要的交互创新——用户看到 AI 做什么才能信任
- 多 session 并排 = 多 Agent 并行展示
- 视觉 diff review = Agent 产出物可视化

### A.2 ChatGPT Canvas 交互模式分析

**核心交互**：highlight-to-action
1. 用户高亮文本/代码
2. context menu 弹出
3. 选择"Ask ChatGPT"或内置操作（翻译、调试、调整长度）
4. AI 在 Canvas 中直接修改

**关键设计**：
- 双栏布局：左侧对话，右侧 Canvas
- Canvas 中的修改实时反映，可以 undo/redo
- AI 的修改用不同颜色标记（类似 Google Docs 的建议模式）

**对 moziplus 的启示**：
- Agent 产出物应该是**可交互的**，不只是展示
- 用户可以在产出物上直接"圈出"要修改的部分

### A.3 Cursor 交互模式分析

**四种交互粒度**：

| 模式 | 触发 | 自主性 | 用户控制 |
|------|------|--------|---------|
| Tab 补全 | 输入时自动 | 最低 | Tab 接受 / Esc 拒绝 |
| Cmd+K Inline Edit | 选中代码 + 指令 | 中等 | 看到预览再决定 |
| Cmd+L Chat Panel | 打开 chat | 中高 | 多轮对话引导 |
| Cmd+I Agent Mode | 打开 agent | 最高 | 看到每一步，可随时介入 |

**2025 年新增：Automations 平台**
- AI agent 响应事件（event-driven），不需要手动触发
- 如：PR 创建时自动 review、lint 错误时自动修复

**对 moziplus 的启示**：
- 4 种交互粒度的设计思路值得借鉴——从被动到主动，覆盖所有场景
- moziplus 也应该有不同的介入深度：全自动 → 半自动 → 手动

### A.4 Devin 交互模式分析

**全屏工作展示**：
- 左侧：Agent 工作终端（shell + editor + browser）
- 右侧：步骤摘要
- 用户只能观察，不能在 Agent 工作过程中介入
- 只有在 Agent 完成或遇到问题时才能提供反馈

**对 moziplus 的启示**：
- 对于长任务，用户不需要时刻盯着，只需要在关键节点介入
- "观察模式"适合好奇心驱动的场景，不适合日常操作

### A.5 Hermes Kanban 交互模式分析

**三种交互面**：
1. **Dashboard**：可视化看板，拖拽、评论、心跳可视化
2. **CLI**：`hermes kanban list/show/create/complete/block/comment`
3. **Worker Tools**：Agent 通过 kanban_* 工具操作看板

**Comment Thread 设计**：
- 每个 task 有独立评论线程
- Agent 和人都可以评论
- 评论是结构化的（不是自由文本）：可以附带文件、链接、状态变更

**心跳可视化**：
- Agent 领取任务后必须定期发心跳
- Dashboard 上显示心跳状态：🟢 正常 / 🟡 延迟 / 🔴 超时
- 心跳超时 → 自动回收任务

**对 moziplus 的启示**：
- 三面一致（Dashboard + CLI + Worker Tools）是关键
- Comment Thread 是人 Agent 协作的最佳实践
- 心跳可视化是展示 Agent 健康状态的好方式

---

## 附录 B：关键决策建议

### B.1 Dashboard vs Chat 的关系

| 维度 | Dashboard | WebChat |
|------|-----------|---------|
| 信息密度 | 高（一屏多任务） | 低（线性对话） |
| 交互深度 | 浅（点击操作） | 深（自然语言） |
| 适用场景 | 全局监控、快速操作 | 复杂指令、探索性对话 |
| AI 主动性 | 被动展示 | 主动推送 |

**推荐：Dashboard 为主，WebChat 为辅。**
- Dashboard 是默认界面，展示全局状态
- WebChat 是入口，用户在 chat 中发指令，结果在 Dashboard 上展示
- 两者通过 WebSocket 共享实时状态

### B.2 实时 vs 轮询

| 方案 | 延迟 | 复杂度 | 推荐阶段 |
|------|------|--------|----------|
| HTTP 轮询 (5s) | 5s | 低 | M2 |
| SSE (Server-Sent Events) | <1s | 中 | M3 |
| WebSocket | <100ms | 高 | M3+ |

**推荐：M2 用轮询，M3 升级 WebSocket。** 延续 v1.0 方案。

### B.3 避免的陷阱

1. **不要做第二个 Grafana**：Dashboard 是协作界面，不是监控面板
2. **不要做第二个 Slack**：Dashboard 上的对话应该围绕任务，不是闲聊
3. **不要过度动画**：开工仪式被砍掉是对的——用户打开 Dashboard 是看状态，不是看动画
4. **不要展示所有日志**：L3 才展示详细过程，L1/L2 只展示摘要
5. **不要固定刷新频率**：有事才推，没事不刷新