# 前端需求讨论

当前讨论到第二页：**Task 管理界面**。

这份文档先不展开其它页面。每次只把一页讲清楚：页面定位、用户目标、必须展示什么、不要塞什么、争议点是什么。等这一页定下来，再开下一页。

相关参考：

- 后端运行结构：`../backend/flow.md`
- 后端施工状态：`../backend/施工指南.md`
- 长期蓝图：`../backend/change.md`
- 旧系统蓝图：`../backend-old/change.md`

---

## 第 1 页：对话页

路径：`/`

一句话定位：

> 对话页是用户和主 Agent 交互的主工作台。它负责提交问题/任务、展示最终回答、展示必要的运行状态，并收集用户对 Task 结果的反馈。

它承担一部分轻量后台管理工作，主要是会话管理和任务入口。但它不应该变成完整后台管理台，也不应该让用户直接配置 team strategy、sub-agent、MCP、插件市场等系统能力。

已确认的方向：

1. session 不做“删除”，改成“归档”。
   - 归档后的 session 不再出现在前端会话列表。
   - 归档不等于抹除记忆；相关记忆和历史数据仍然存在。
2. 附件是对话页第一版必须能力。
3. Slash command 不保留。
4. 复杂任务创建后，对话中显示 Task 创建回复，点击跳转到 Task 管理界面。
5. 原 `Office` 概念改名为 `Task`，并删除图形化办公室展示，改为更合理的任务交互过程与链条展示。
6. “需要修改”走类似 Codex plan mode 的选择/评论框；用户也可以继续在主聊天框说话，此时默认上一轮结果满意。
7. 验证失败时，大字显示状态，详细原因小字展示并默认折叠，可展开查看。

---

## 1. 用户打开对话页是为了什么

| 用户目标 | 页面需要支持 |
|---|---|
| 问一个简单问题 | 快速输入、快速看到 assistant 回答，不制造 Task 负担 |
| 提交一个复杂任务 | 输入任务后进入运行中状态，最终看到主 Agent synthesis 的结果 |
| 知道系统是不是还在工作 | 明确显示 thinking/running/失败状态 |
| 看到必要过程 | 能看到规划、子任务、验证、重试等摘要，但不被原始事件淹没 |
| 判断结果是否可接受 | 最新 Task 结果下提供“满意 / 需要修改 / 放弃” |
| 继续上下文 | 会话列表、切换历史会话、加载历史消息 |
| 修改结果 | 反馈“需要修改”后，下一条消息应自然复用未关闭 Task |
| 管理会话可见性 | 支持归档 session，使它不再出现在前端列表 |
| 进入复杂任务工作台 | Task 创建后，从对话消息中的 Task 链接跳转到 Task 管理界面 |

---

## 2. 当前对话页已有元素

| 元素 | 当前情况 | 本页讨论点 |
|---|---|---|
| 会话列表 | 左侧已有新建、切换、删除会话 | 删除应改为归档；归档后前端不再显示 |
| 消息流 | 中间展示 user / assistant 消息 | 是否需要显示模型、run_id、token、工具次数等元信息 |
| 输入框 | 支持文本输入、回车发送 | 是否需要模型选择、参数选择、模式选择 |
| 运行状态 | 有 thinking 状态 | 是否要区分 simple run、Task run、验证中、重试中 |
| 反馈按钮 | 最新 assistant Task 结果显示三按钮 | 需要改成带评论框的选择交互 |
| 过程区 | 桌面端有 ProcessLane，移动端有 Process tab | 对话页不再常驻大过程区；复杂任务通过 Task 链接进入 Task 管理界面 |
| 结果区 | 有 ArtifactSidebar | 需要和 Task 管理界面重新划边界 |
| Office 入口 | 当前任务现场 banner | 不应该在顶部常驻；改成消息中的 Task 链接 |
| 附件入口 | 前端已有上传入口 | 第一版必须保留，需要后端补足附件语义 |
| Slash command | 前端已有 `/` 命令选择 | 不保留，应移除 |

---

## 3. 对话页必须有

### 3.1 会话区

必须支持：

1. 新建会话。
2. 切换会话。
3. 归档会话。
4. 显示会话最近更新时间或可读标题。
5. 默认不显示已归档会话。

暂不确定：

1. 是否需要会话搜索。
2. 是否需要手动重命名。
3. 是否需要 pin。
4. 是否需要“查看已归档会话”的二级入口。

已确认：

1. 不使用“删除”语义。
2. 归档只影响前端列表可见性，不等于删除记忆或永久清除历史。

### 3.2 消息区

必须支持：

1. 展示用户消息。
2. 展示 assistant 最终回答。
3. 刷新后保留 `run_id / task_id / task_status / validation_status / feedback_state` 对应的 UI 状态。
4. 对 Markdown 内容做稳定渲染。

不应该做：

1. 不直接展示隐藏事件原始 JSON。
2. 不把 sub-agent 的中间 summary 当成最终回答。
3. 不让用户手动改内部 Task 状态。

### 3.3 输入区

必须支持：

1. 输入文本。
2. 发送。
3. 发送失败时明确提示。
4. 运行中避免重复提交，或明确支持排队。
5. 上传附件。
6. 在消息中展示用户已提交的附件。

暂不确定：

1. 附件进入模型上下文的具体语义：作为文件引用、文本提取、图片输入，还是先作为 workspace 文件供工具读取。
2. 是否要提供模型/provider 快捷选择。

不保留：

1. Slash command。

### 3.4 运行状态

必须支持：

1. 等待模型时显示“思考中”。
2. Task 验证中有明确状态。
3. 验证失败重试时有明确状态。
4. 失败时告诉用户失败发生在发送、运行、验证还是反馈。
5. 验证失败时，大字显示失败状态。
6. 验证详细原因放在状态下方，以小字/展开区展示，默认折叠。

当前缺口：

1. 现在基本只有 thinking。
2. 验证中、重试中、Task awaiting feedback 没有足够清晰的产品化表达。

### 3.5 反馈区

必须支持：

1. 只对最新 assistant Task 结果显示反馈。
2. 三种反馈：满意、需要修改、放弃。
3. 已反馈后显示反馈状态。
4. 反馈失败时显示错误。
5. “满意 / 需要修改”使用带评论框的选择交互。
6. 用户如果不点反馈、直接在主聊天框继续聊天，则默认上一轮结果满意。

待继续细化：

1. “满意”的评论框是可选还是默认隐藏。
2. “需要修改”的评论是否必填。
3. “放弃”是否需要二次确认。
4. “满意”后是否显示“已用于学习候选”之类的反馈。

### 3.6 Task 入口

必须支持：

1. 复杂任务创建后，对话流中出现一条 Task 创建回复。
2. Task 创建回复包含可读标题或 description。
3. 用户点击 Task 链接后跳转到 Task 管理界面。
4. 对话页只保留轻量 Task 状态，不展开完整执行链条。

示例表达：

```text
已创建 Task：整理最近三个月销售数据并生成分析结论
查看 Task
```

不应该做：

1. 不展示未实现的策略按钮，例如 `moa / hierarchy / group_chat`。
2. 不让用户选择 specialist agent 来影响当前 Task。
3. 不把完整过程链条塞在对话页主界面。
4. 不再使用 `Office` 作为用户可见概念。

---

## 4. 对话页不承担的事情

| 不承担 | 原因 | 应该去哪里 |
|---|---|---|
| Skill 审核、发布、回滚 | 这是能力生命周期管理，不是对话主流程 | Skills 页 |
| Provider 深度配置 | 配置属于系统设置，不应打断对话 | Status/Settings |
| MCP server 管理 | 属于工具/集成管理 | MCP/Settings，是否保留待后续讨论 |
| Outlook 浏览与连接 | 属于集成管理 | Outlook/Settings，是否保留待后续讨论 |
| Plugin/Marketplace 管理 | 属于平台扩展 | Plugins/Marketplace，是否保留待后续讨论 |
| 内部 Task 管理 | Task 是运行容器，不是当前产品级实体 | 仅通过过程投影展示 |
| Team strategy 配置 | 当前 team 是 Task 内部执行策略 | 仅展示，不手动配置 |

对话页承担的轻量后台管理：

| 承担 | 说明 |
|---|---|
| session 归档 | 替代删除；归档后不在前端会话列表展示，但记忆仍然存在 |
| Task 入口 | 复杂任务创建后，通过对话消息提供跳转到 Task 管理界面的入口 |

---

## 5. 对话页和后端的最小契约

| 能力 | 后端接口/数据 | 对话页使用方式 |
|---|---|---|
| 发送消息 | `POST /api/chat` | 输入框发送；返回 final answer + run/task/validation 元数据 |
| WebSocket 对话 | `WS /ws/{session_id}` | 实时发送和接收 assistant message / session_updated |
| 提交反馈 | `POST /api/chat/feedback` | 最新 Task answer 下三按钮 |
| 读取会话 | `GET /api/sessions/{session_id}` | 刷新消息流和反馈状态 |
| 会话列表 | `GET /api/sessions` | 左侧会话列表 |
| 过程投影 | `GET /api/sessions/{session_id}/process` | 右侧过程区，不直接展示隐藏事件 JSON |
| 归档会话 | 待补：archive session API | 归档后会话不再出现在默认列表 |
| 附件 | 待补：chat attachment / file reference 契约 | 对话页必须支持附件上传和附件展示 |
| Task 链接 | 待补：Task 管理页路由与 Task identifier 映射 | 复杂任务创建回复跳转到 Task 管理界面 |

---

## 6. 当前主要争议点

| 争议点 | 方案 A | 方案 B | 需要定什么 |
|---|---|---|---|
| 附件 | 当前版本保留，要求后端补附件语义 | 当前版本隐藏，等文件能力页讨论后再接回 | 已定：保留 |
| Slash command | 保留为高级用户快捷入口 | 隐藏，避免旧系统命令残留干扰 | 已定：不保留 |
| 过程区默认状态 | 桌面端默认显示 | 复杂 Task 出现后，以 Task 链接跳转到 Task 管理界面 | 已定：对话页不常驻完整过程区 |
| Office banner | 对话页顶部显示当前任务现场 | 从对话页移除，复杂任务创建后在消息里显示 Task 链接 | 已定：移除顶部 Office banner，Office 改名 Task |
| 模型/provider 选择 | 在输入区提供轻量选择 | 只在设置页改默认模型 | 用户是否经常需要按消息切模型 |
| 反馈评论 | “满意 / 需要修改”弹出选择评论框 | 只点按钮，用户下一条消息补充 | 已定：需要评论框；用户继续主聊天则默认满意 |
| 验证细节 | 大字状态 + 折叠详情 | 只显示通过/未通过 | 已定：状态大字，原因默认折叠 |
| 调试元信息 | 可展开显示 run_id、task_id、token、工具次数 | 普通用户隐藏 | 当前产品面向开发者还是普通使用者 |

---

## 7. 当前版本建议稿

这是讨论稿，不是最终结论。

对话页当前版本收敛成：

1. 左侧：会话列表。
   - 删除改为归档。
   - 归档后不在默认列表展示。
2. 中间：消息流 + 输入框。
3. 输入区保留附件能力。
4. 移除 Slash command。
5. 复杂任务创建后，在对话流里显示 Task 创建回复和跳转链接。
6. 移除顶部 Office banner。
7. `Office` 改名为 `Task`；完整任务过程进入 Task 管理界面展示。
8. 最新 Task 回答下：满意 / 需要修改 / 放弃。
9. “满意 / 需要修改”使用类似 Codex plan mode 的选择评论框。
10. 用户不点反馈、直接继续聊天时，默认上一轮结果满意。
11. 验证失败：大字状态，详细原因折叠展示。
12. 对话页不提供 Team 策略选择、Sub-agent 选择、Skill 审核、MCP/插件/Outlook 管理。

---

## 8. 已确认问题

| 问题 | 结论 |
|---|---|
| 对话页是不是只作为“主工作台”，不承担后台管理？ | 承担部分轻量后台管理，尤其是 session 归档和 Task 入口 |
| 附件是不是对话页第一版必须能力？ | 是，必须保留 |
| Slash command 是否继续保留？ | 不保留 |
| 过程区是默认显示，还是复杂任务出现后再显示？ | 不常驻完整过程区；复杂任务创建后显示 Task 链接，点击进入 Task 管理界面 |
| Office 入口是否应该出现在对话页顶部？ | 不应该；Office 改名 Task，入口放在对话消息中 |
| “需要修改”是否需要评论框？ | 需要；满意/需要修改使用选择评论框，用户继续主聊天则默认满意 |
| 验证失败时，用户需要看到详细原因还是只看状态？ | 大字状态 + 默认折叠的小字详细原因 |

## 9. 下一页遗留给 Task 管理界面的问题

这些问题不在对话页继续展开，留到下一页“Task 管理界面”讨论：

1. 原 Office 页改名 Task 后，路由叫 `/tasks` 还是继续兼容 `/office`。
2. Task 管理界面如何展示任务交互过程和链条。
3. 是否支持暂停、取消、重试某个 Task 或某个节点。
4. 子任务、验证、技能选择、工具调用、产物如何分层展示。
5. 删除图形化办公室后，新的 Task 页面信息架构怎么排。

---

## 第 2 页：Task 管理界面

建议路径：

- 任务管理入口：`/tasks`
- 普通任务详情：`/tasks/{task_id}`
- 定时任务详情/编辑：`/tasks/scheduled/{job_id}` 或 `/tasks/scheduled`

历史对应：

- 当前前端里的 `/office` 和 `/office/[taskId]`
- 当前前端里的 `/cron`
- 后续用户可见名称统一改为 `Task`
- 原图形化办公室展示删除，不再把任务现场做成地图/办公室/角色走动形式
- 当前“任务管理”思路保留：任务分为普通任务和定时任务
- 旧 `/office` 跳转到 `/tasks`
- 当前 `/cron` 能力并入“定时任务”tab，不再作为顶层导航

一句话定位：

> Task 管理界面是任务中心。它统一管理普通任务和定时任务：普通任务用于查看复杂任务的执行链条和反馈状态；定时任务用于创建、启停和查看计划触发的任务。

它不是单个 Task 的详情页本身。单个普通 Task 的链条页是它下面的详情页。

它也不是普通聊天页，不是 agent/sub-agent 配置页，不是完整后台设置页。

已确认的方向：

1. 路由改为 `/tasks`，旧 `/office` 跳转到 `/tasks`。
2. 任务管理入口分为“普通任务 / 定时任务”两个 tab。
3. 当前 `/cron` 能力并入“定时任务”tab，不再作为顶层导航。
4. 普通任务列表需要存在，用户可以从列表进入普通任务详情。
5. 普通任务详情采用“阶段链 + 节点分组”展示执行链条。
6. 普通任务详情允许直接输入修订意见。
7. 用户可以暂停、取消、重试普通 Task 或节点。
8. 第二次验证失败后，普通任务用户可见状态叫“任务失败”。
9. sub-agent 输出只算节点结果，不算产物。
10. 产物需要下载按钮，支持单个下载或全部下载。
11. 已归档 session 里的普通任务仍然在普通任务列表显示。
12. 已放弃普通任务不允许恢复。
13. 所有任务没有归档概念；定时任务可以暂时关闭，也可以删除。
14. 定时任务每次触发都创建普通 Task，并在运行历史里链接过去。

---

## 1. 用户打开任务管理页是为了什么

| 用户目标 | 页面需要支持 |
|---|---|
| 查看普通任务 | 显示从对话中创建的复杂任务列表 |
| 查看定时任务 | 显示计划触发的任务列表 |
| 区分任务类型 | 普通任务和定时任务在同一个任务管理入口中分 tab 或分区展示 |
| 进入普通任务详情 | 点击普通任务进入执行链条页 |
| 管理定时任务 | 创建、启停、编辑、删除、手动运行定时任务 |
| 看任务状态 | 对普通任务显示运行中、等待反馈、需要修改、已完成、已放弃、任务失败等状态 |
| 看计划状态 | 对定时任务显示启用状态、计划规则、上次运行、下次运行、最近结果 |
| 回到对话继续沟通 | 普通任务详情提供来源会话链接 |
| 回看历史任务 | 普通任务列表也显示已归档 session 里的任务 |

---

## 2. 任务类型

Task 管理界面至少分两类：

| 类型 | 来源 | 用户主要动作 | 详情页重点 |
|---|---|---|---|
| 普通任务 | 用户在对话中提交复杂任务后自动创建 | 查看、反馈、回到对话修订 | 执行链条、节点、验证、最终结果 |
| 定时任务 | 用户手动创建计划任务 | 新建、启停、编辑、手动运行、查看历史触发 | 计划规则、触发记录、每次运行结果 |

普通任务详情页负责展示完整过程：

```text
Task 创建
│
├─ 规划 plan
│  ├─ single
│  └─ team
│     ├─ sequence
│     ├─ parallel
│     └─ dag
│
├─ 子任务执行 nodes
│  ├─ selected skills
│  ├─ generated ephemeral skill
│  ├─ tool / file / memory activity
│  └─ node result
│
├─ 主 Agent synthesis
│
├─ validation
│  ├─ passed
│  ├─ failed
│  └─ retry
│
└─ feedback
   ├─ satisfied
   ├─ revise
   └─ abandon
```

定时任务详情页负责展示计划和触发历史：

```text
定时任务
│
├─ 计划规则
│  ├─ at
│  ├─ every
│  └─ cron
│
├─ 目标会话 / message
│
├─ 触发历史
│  ├─ run 1
│  ├─ run 2
│  └─ run N
│
└─ 最近结果 / 错误
```

---

## 3. 页面结构建议

### 3.1 任务管理入口

路径建议：`/tasks`

| 区域 | 内容 |
|---|---|
| 顶部 tabs | 普通任务、定时任务 |
| 普通任务 tab | 复杂任务列表、状态筛选、打开详情、回到对话 |
| 定时任务 tab | 计划任务列表、新建任务、启停、编辑、手动运行 |
| 全局空状态 | 引导用户回到对话页创建普通任务，或创建一个定时任务 |

待讨论：

1. 入口是否叫 `任务`，英文是否叫 `Tasks`。
2. tabs 名称是“普通任务 / 定时任务”，还是“任务 / 计划任务”。
3. 是否需要全局搜索。

### 3.2 普通任务列表

| 区域 | 内容 |
|---|---|
| 状态筛选 | 全部、运行中、等待反馈、需要修改、已完成、已放弃、失败 |
| 任务卡片/表格 | 标题、description、来源会话、状态、当前阶段、更新时间、子任务数量、失败数 |
| 快速动作 | 打开详情、回到对话、暂停、取消、重试 |
| 空状态 | 引导用户回到对话页创建复杂任务 |

普通任务列表不负责展示完整链条，只负责让用户找到任务并进入详情。

已确认：

1. 普通任务列表需要存在。
2. 已归档 session 里的普通任务仍然显示。
3. 普通任务没有归档概念。
4. 已放弃普通任务不允许恢复。

### 3.3 定时任务列表

| 区域 | 内容 |
|---|---|
| 顶部动作 | 新建定时任务 |
| 列表字段 | 名称、启用状态、计划类型、计划表达式、目标会话、消息摘要、上次运行、下次运行、最近结果 |
| 快速动作 | 启用/停用、编辑、手动运行、删除 |
| 空状态 | 引导用户创建一个计划任务 |

定时任务管理保留现在 `/cron` 页的主要能力，但归入 Task 管理页，不再作为顶层独立概念。

已确认：

1. 定时任务可以暂时关闭，也可以删除。
2. 定时任务没有归档概念。
3. 每次定时触发都创建普通 Task。
4. 定时任务运行历史必须链接到对应普通 Task。

### 3.4 普通任务详情页

路径建议：`/tasks/{task_id}`

建议分区：

| 区域 | 必须展示 | 说明 |
|---|---|---|
| Task header | 标题、description、状态、来源会话、创建时间、更新时间 | 用户先知道自己看的是哪个任务 |
| 当前状态区 | 大字状态 + 当前阶段 + 下一步动作 | 例如“验证失败，等待修订” |
| 执行链条 | plan、nodes、dependency、main synthesis、validation | 这是本页核心 |
| 节点详情 | 每个节点的任务、状态、输入、输出、skills、错误 | 点击链条节点后在详情区展示 |
| 最终结果 | 主 Agent synthesis 的用户可见结果 | 不把 sub-agent summary 当最终结果 |
| 验证区 | 验证状态、分数、失败原因、重试记录 | 大状态明显，详情折叠 |
| 反馈区 | 满意、需要修改、放弃；评论框 | 和对话页保持一致 |
| 产物区 | 文件、链接、JSON、图片、报告 | 需要先定义产物来源 |
| 事件时间线 | 重要事件，不展示原始隐藏 JSON | 用产品化语言展示 |

### 3.5 定时任务详情/编辑页

路径建议：`/tasks/scheduled/{job_id}`

| 区域 | 必须展示 | 说明 |
|---|---|---|
| Job header | 名称、启用状态、创建时间、更新时间 | 用户先知道这是哪个定时任务 |
| 计划规则 | at / every / cron，下一次运行时间 | 核心配置 |
| 消息内容 | 触发时发送给 Agent 的 message | 可编辑 |
| 目标会话 | 触发运行归属哪个 session | 可选择或固定 |
| 运行历史 | 每次触发的时间、状态、run/task 链接 | 和普通任务结果打通 |
| 错误区 | 最近错误、失败原因 | 方便排查 |
| 操作区 | 保存、启用/停用、手动运行、删除 | 管理动作 |

---

## 4. 普通任务详情：执行链条怎么展示

这是普通任务详情页最核心的问题。删除图形化 Office 后，需要一个清晰的链条视图。

### 方案 A：纵向阶段链

```text
Plan
  ↓
Team execution
  ├─ Node A
  ├─ Node B
  └─ Node C
  ↓
Main synthesis
  ↓
Validation
  ↓
Feedback
```

优点：

1. 最容易读。
2. 移动端友好。
3. 和事件时间顺序一致。

缺点：

1. 对 parallel / dag 的依赖关系表达较弱。

### 方案 B：DAG 链条图

```text
Planner
   ├── Node A ──┐
   ├── Node B ──┼── Synthesis ── Validation
   └── Node C ──┘
```

优点：

1. 能清楚表达依赖关系。
2. 对 team/dag 任务更准确。

缺点：

1. 实现和布局复杂。
2. 小屏幕容易难读。

### 方案 C：阶段链 + 节点分组

纵向展示阶段，在 team execution 阶段内部用节点分组表达 sequence / parallel / dag：

```text
Plan
  ↓
Team execution
  Group 1: Node A + Node B 并行
  Group 2: Node C 依赖 A/B
  ↓
Main synthesis
  ↓
Validation
```

优点：

1. 兼顾可读性和结构。
2. 比纯 DAG 更适合产品界面。
3. 能覆盖 sequence / parallel / dag。

缺点：

1. 需要后端或前端把 DAG 分层。

已确认：

> 普通任务详情执行链条采用方案 C：阶段链 + 节点分组。

---

## 5. 普通任务详情：节点卡片需要展示什么

| 信息 | 是否必须 | 说明 |
|---|---|---|
| 节点标题 / node_id | 必须 | 让用户知道哪个子任务 |
| 状态 | 必须 | queued / running / done / error / blocked |
| 分配目的 | 必须 | 这个节点被安排做什么 |
| selected skills | 必须 | 体现为什么它按某种方式做 |
| generated ephemeral skill | 必须 | 如果系统临时生成了 draft-only guidance，需要可见 |
| 输出摘要 | 必须 | 用户不展开也能知道节点结果 |
| 错误/阻断原因 | 必须 | 失败时必须清楚 |
| 工具调用 | 待讨论 | 是否展示全部，还是只展示关键工具活动 |
| token/model/provider | 可选 | 可能只放调试展开区 |
| run_id/session_id | 可选 | 开发者调试用，不默认展示 |

已确认：

1. sub-agent 输出属于节点结果。
2. sub-agent 输出不算产物。

---

## 6. 普通任务状态设计

用户可见状态建议不要完全照搬内部状态，而是做产品化映射。

| 用户可见状态 | 内部来源 | 说明 |
|---|---|---|
| 已创建 | task created / open | 已创建但还未开始执行 |
| 规划中 | task_execution_planned 前后 | 正在决定 single/team 和执行结构 |
| 执行中 | team run / main run running | 正在执行子任务或主综合 |
| 验证中 | validating | 正在自动验证最终结果 |
| 验证失败，正在重试 | validation failed + retry_scheduled | 第一次失败，系统自动重试 |
| 等待反馈 | awaiting_feedback | 最终结果已给出，等用户满意/修改/放弃 |
| 需要修改 | needs_revision | 用户要求修订，下一条消息复用该 Task |
| 已完成 | closed | 用户满意并关闭 |
| 已放弃 | abandoned | 用户放弃 |
| 任务失败 | 第二次验证失败 / unrecoverable failure | 执行失败且没有恢复，或第二次验证仍失败 |

已确认：

1. 第二次验证失败后，用户可见状态叫“任务失败”。
2. 用户可以暂停、取消、重试普通 Task 或节点。

待讨论：

1. 用户继续聊天默认满意后，状态是否直接变“已完成”。
2. 暂停/取消/重试分别作用于整个 Task 还是当前节点时，状态如何显示。

---

## 7. 普通任务反馈与修订

普通任务详情页和对话页要保持一致。

必须支持：

1. 满意。
2. 需要修改。
3. 放弃。
4. 满意/需要修改的评论框。
5. 用户在对话页继续聊天时，默认上一轮 Task 结果满意。
6. 普通任务详情页允许直接输入修订意见。

待讨论：

1. 详情页内输入修订意见时，是否同步写回来源会话消息流。
2. 放弃是否需要原因。

已确认：

1. 已放弃普通任务不允许恢复。

---

## 8. 普通任务详情：产物区

产物需要先定义清楚，否则会变成空面板。

可能的产物类型：

| 类型 | 例子 | 来源 |
|---|---|---|
| 文件 | 生成的报告、代码、表格 | filesystem tool / workspace |
| 链接 | 搜索结果、外部引用 | web tool / MCP |
| JSON | 结构化计划、评估报告 | hidden events / validation |
| 图片 | 生成图、上传图分析结果 | attachment / tool |
| 文本报告 | 节点输出、最终总结 | main synthesis / sub-agent |

待讨论：

1. 无。

已确认：

1. sub-agent 输出只算节点结果，不算产物。
2. 产物区需要下载按钮。
3. 下载可以支持单个产物下载或全部下载。
4. validation report 属于验证区，不算产物。
5. 用户上传附件不出现在 Task 产物区。

---

## 9. 任务管理页不应该做什么

| 不应该 | 原因 |
|---|---|
| 不再展示图形化办公室/地图/人物移动 | 用户要看执行链条，不是看装饰性现场 |
| 不允许手动选择 team strategy | 当前 strategy 是 Main Agent/Planner 内部决策 |
| 不允许手动选择 specialist agent | 当前 Task sub-agent 是 generic worker + skill guidance |
| 不直接暴露隐藏事件 JSON | 需要投影成产品可读事件 |
| 不混淆最终回答和中间节点输出 | 最终回答仍来自主 Agent synthesis |
| 不承载 Skills 审核发布 | 去 Skills 页 |
| 不承载 MCP/插件/Outlook 管理 | 去对应设置/管理页，是否保留后续讨论 |
| 不把定时任务和普通任务混成一张无区分列表 | 两者来源、动作和状态完全不同 |
| 不给任务设计归档概念 | session 有归档；任务没有归档 |

---

## 10. 与对话页的关系

| 对话页 | 任务管理页 |
|---|---|
| 提交复杂任务 | 普通任务列表出现该任务 |
| 显示 Task 创建消息 | 打开普通任务详情 |
| 展示最终回答 | 展示最终回答如何生成 |
| 提供轻量反馈 | 提供完整反馈和修订上下文 |
| 用户继续聊天默认满意 | Task 状态同步关闭 |
| 不展示完整链条 | 展示链条、节点、验证、产物 |
| 不创建定时任务 | 定时任务 tab 创建和管理计划任务 |

---

## 11. 已确认问题

| 问题 | 结论 |
|---|---|
| 路由是否改为 `/tasks`，并让旧 `/office` 跳转到 `/tasks`？ | 是 |
| 任务管理入口是否分为“普通任务 / 定时任务”两个 tab？ | 是 |
| 当前 `/cron` 能力是否并入“定时任务”tab，不再作为顶层导航？ | 是 |
| 普通任务列表是否需要存在，还是主要从对话跳普通任务详情？ | 需要存在，可以从列表进入详情 |
| 普通任务详情执行链条是否采用“阶段链 + 节点分组”方案？ | 是 |
| 普通任务详情是否允许直接输入修订意见，还是必须回到对话页？ | 允许直接输入 |
| 普通任务详情内输入修订意见时，是否同步写回来源会话消息流？ | 无需同步 |
| 用户是否可以暂停、取消、重试普通 Task 或节点？ | 前端只能取消或重试整个任务；没有暂停；不操作单个节点 |
| 第二次验证失败后，普通任务用户可见状态叫什么？ | 任务失败 |
| sub-agent 输出算产物，还是只算节点结果？ | 节点结果 |
| 产物是否需要下载/导出全部？ | 具备下载按钮，支持单个下载或全部下载 |
| validation report 是否算产物，还是只属于验证区？ | 属于验证区 |
| 用户上传附件是否出现在 Task 产物区？ | 无需 |
| 已归档 session 里的普通任务是否还在普通任务列表显示？ | 需要显示 |
| 已放弃普通任务是否允许恢复？ | 不允许 |
| 定时任务删除语义是删除、禁用，还是归档？ | 可以暂时关闭，也可以删除；所有任务没有归档概念 |
| 定时任务每次触发是否创建普通 Task，并在运行历史里链接过去？ | 是 |
| tabs 名称最终用“普通任务 / 定时任务”，还是“任务 / 计划任务”？ | 普通任务 / 定时任务 |

## 12. 本页剩余待讨论问题

1. 是否需要任务搜索。

说明：“全局搜索任务”指任务管理页里是否需要一个搜索框，可以跨普通任务和定时任务搜索任务标题、description、来源会话、状态、定时任务消息内容等。不是全站搜索，也不是搜索聊天内容。

---

## 第 3 页：技能页

建议路径：`/skills`

一句话定位：

> 技能页是 Agent 能力生命周期管理台。它负责查看已发布技能、处理学习候选、生成和审核草稿、查看安全/评估报告，并把通过审核的技能发布到 runtime catalog。

它不是聊天页，也不是直接在线编辑 published skill 的地方。

已确认的方向：

1. 主 tab 确定为“已发布 / 候选 / 草稿评审”。
2. “运行学习”按钮不放在技能页。
3. 保留技能上传；上传后必须进入 draft/review 流程。
4. 保留技能下载。
5. 允许删除技能。
6. 已发布技能暂时不需要版本历史和 diff。
7. 草稿评审需要 diff 视图。
8. approve/reject 不强制填写 notes。
9. publish 不需要二次确认。
10. high risk draft 允许发布，但必须展示理由。
11. candidate 允许忽略/关闭。
12. candidate 和 draft 不需要链接回 source task/run。

---

## 1. 用户打开技能页是为了什么

| 用户目标 | 页面需要支持 |
|---|---|
| 看当前有哪些技能 | 展示已发布技能、状态、来源、描述、版本 |
| 看系统从任务中学到了什么 | 展示 learning candidates、来源 run/task、原因和风险 |
| 生成技能草稿 | 从 candidate 生成 draft，或重新生成 draft |
| 审核技能草稿 | 查看 proposed content、frontmatter、review 状态 |
| 判断草稿是否安全 | 查看 safety report、risk level、阻断原因 |
| 判断草稿是否有效 | 查看 eval report、是否通过、provider unavailable 等状态 |
| 发布技能 | approved + safety passed + eval not failed 后发布 |
| 管理已发布技能 | 禁用、回滚、删除、下载 |
| 上传技能 | 上传后进入 draft/review 流程 |
| 处理无价值候选 | 忽略/关闭 candidate |

---

## 2. 技能页应该覆盖的生命周期

```text
Task 成功 + 用户满意
│
└─ learning candidate
   ├─ open
   ├─ queued
   ├─ synthesizing
   ├─ draft_ready
   ├─ safety_failed
   ├─ eval_failed
   ├─ review_pending
   ├─ approved
   ├─ rejected
   ├─ published
   ├─ failed
   └─ superseded
      │
      └─ draft
         ├─ safety report
         ├─ eval report
         ├─ submit review
         ├─ approve / reject
         └─ publish / disable / rollback
```

核心约束：

1. draft 不进入 runtime catalog。
2. rejected draft 不可 publish。
3. publish 必须要求 approved review + safety passed + eval not failed。
4. high risk publish 需要显式确认。
5. worker 可以自动到 draft/safety/eval，但永不自动 approve/publish。
6. 不允许绕过 lifecycle 直接在线改 published skill。

---

## 3. 页面结构建议

技能页建议保留三个主 tab：

| Tab | 目的 |
|---|---|
| 已发布 | 查看 runtime catalog 中当前可用/不可用的技能 |
| 候选 | 查看 learning candidates，决定是否生成/重生成草稿 |
| 草稿/评审 | 审核 draft，查看 safety/eval，批准/拒绝/发布 |

### 3.1 已发布 tab

| 区域 | 内容 |
|---|---|
| 技能列表 | 名称、描述、来源、状态、当前版本、更新时间 |
| 状态标识 | available / unavailable / disabled / retired |
| 操作 | 查看详情、禁用、回滚、删除、下载、上传 |
| 可选操作 | 复制路径、查看支持文件 |

已确认：

1. 保留上传技能。
2. 上传后必须进入 draft/review 流程。
3. 保留下载技能。
4. 允许删除技能。
5. 已发布技能暂时不需要版本历史和 diff。

### 3.2 候选 tab

| 区域 | 内容 |
|---|---|
| 候选列表 | candidate id、kind、status、risk、reason、evidence summary |
| 来源信息 | source run ids、task id、相关技能 |
| 操作 | 生成草稿、重新生成、查看详情、忽略/关闭 |

候选类型：

| 类型 | 说明 |
|---|---|
| new_skill | 新建技能建议 |
| revise_skill | 修订已有技能建议 |
| merge_skills | 合并技能建议 |
| retire_skill | 退役技能建议 |

待讨论：

1. 是否允许用户手动创建 candidate。

已确认：

1. 技能页不放“运行学习”按钮。
2. candidate 允许忽略/关闭。
3. candidate 不需要链接回 source task/run。

### 3.3 草稿/评审 tab

| 区域 | 内容 |
|---|---|
| 草稿列表 | skill name、draft id、proposal kind、status、base version |
| 内容区 | proposed frontmatter、proposed content |
| Safety report | passed、risk level、findings |
| Eval report | passed、status、notes |
| Review | submit、approve、reject、review notes |
| Diff | base version vs proposed draft |
| Publish | publish、high risk reason |

已确认：

1. 草稿评审需要 diff 视图。
2. approve/reject 不强制填写 notes。
3. publish 不需要二次确认。
4. high risk draft 允许发布，但必须展示理由。
5. draft 不需要链接回 source task/run。

---

## 4. 已发布技能管理边界

| 动作 | 当前建议 | 说明 |
|---|---|---|
| 查看 | 必须 | 看名称、描述、版本、状态 |
| 禁用 | 必须 | 保留 skill spec，不进入 runtime selection |
| 回滚 | 必须 | 通过 publisher 回滚到旧版本 |
| 删除 | 必须 | 允许删除技能，暂时不需要二次确认 |
| 上传 | 必须 | 上传后进入 draft/review 流程，并自动跑 safety 和 eval |
| 下载 | 必须 | 作为备份/迁移能力保留 |
| 在线编辑 published | 不允许 | 必须通过 draft -> review -> publish |

---

## 5. 技能页和其它页面的关系

| 页面 | 关系 |
|---|---|
| 对话页 | 用户满意反馈触发学习候选；对话页不审核技能 |
| 任务管理页 | 技能页不需要链接回 source task/run |
| 状态页 | provider 不可用会影响 draft synthesis/eval，技能页只显示结果，不管理 provider |
| MCP/工具页 | skill 可有 tool hints，但技能页不管理 MCP server |

---

## 6. 技能页不应该做什么

| 不应该 | 原因 |
|---|---|
| 不直接编辑 published skill | 破坏 review/publish lifecycle |
| 不自动 approve/publish | 当前设计是 assisted learning |
| 不让 rejected draft 发布 | 审核状态必须生效 |
| 不让 safety_failed / eval_failed 绕过发布 | 安全和评估是发布门 |
| 不把 draft 当 runtime skill | draft 不进入 runtime catalog |
| 不把技能页做成普通文件管理器 | 技能是生命周期对象，不只是 Markdown 文件 |
| 不在技能页放 run learning | 学习 worker 手动触发不属于这个页面 |
| 不要求 candidate/draft 跳回 source task/run | 技能页只展示必要 evidence 摘要 |

---

## 7. 已确认问题

| 问题 | 结论 |
|---|---|
| 技能页主 tab 是否确定为“已发布 / 候选 / 草稿评审”？ | 是 |
| 是否保留“运行学习”按钮，允许用户手动触发 worker run-once？ | 不在技能页做 |
| 是否保留技能上传？如果保留，上传后是否必须进入 draft/review 流程？ | 保留，且必须进入 draft/review 流程 |
| 是否保留技能下载？ | 是 |
| 是否允许删除技能，还是只允许禁用/回滚/退役？ | 允许删除 |
| 技能删除是否需要二次确认？ | 暂时不需要 |
| 技能上传后是否自动跑 safety/eval？ | 是，上传后自动跑 safety 和 eval |
| 已发布技能是否需要版本历史和 diff？ | 暂时无需 |
| 草稿评审是否需要 diff 视图？ | 需要 |
| approve/reject 是否必须填写 notes？ | 无需 |
| publish 是否必须二次确认？ | 无需 |
| high risk draft 是否允许发布，还是只能重新生成/拒绝？ | 允许，但要展示来自 safety report 的理由 |
| high risk draft 的“理由”来自 safety report，还是需要发布者手动填写？ | 来自 safety report |
| candidate 是否允许忽略/关闭？ | 是 |
| candidate 和 draft 是否需要链接回 source task/run？ | 无需 |

## 8. 本页剩余待讨论问题

暂无。