Files
beaver_project/app-instance/frontend/前端需求讨论.md
steven_li 30ab74ffb2 feat(engine): 添加MCP连接管理和工具集成功能
- 集成MCP连接管理器,支持MCP服务器连接
- 添加多种内置工具:ClarifyTool、CronTool、DelegateTool、ExecuteCodeTool、
  PatchFileTool、ProcessTool、SendMessageTool、SpawnTool、TerminalTool、
  TodoTool、WebFetchTool、WebSearchTool、WriteFileTool等
- 实现工具注册和装配功能
- 添加技能选择上下文参数
- 支持思考模式控制参数thinking_enabled

feat(coordinator): 重构任务执行计划器参数命名

- 将learning_candidate_enabled重命名为allow_candidate_generation
- 更新TeamGraphScheduler中的参数传递
- 修改LocalAgentRunner中的相关参数处理
- 更新README文档中的相应描述

refactor(context): 标准化工具调用参数格式

- 添加_json导入用于参数序列化
- 实现_provider_tool_calls方法标准化OpenAI兼容的工具调用载荷
- 修复工具调用中参数非字符串类型的序列化问题

refactor(session): 优化消息历史记录过滤逻辑

- 修改get_messages_as_conversation为基于运行状态过滤消息
- 排除未完成、失败或错误结束的运行记录
- 改进对话历史的可见性控制机制

fix(store): 修复FTS索引重建逻辑

- 添加异常处理防止FTS索引创建失败
- 实现_rebuild_fts_index方法重新构建全文搜索索引
- 优化索引触发器和表的维护流程
2026-05-14 09:43:48 +08:00

37 KiB
Raw Blame History

前端需求讨论

当前讨论到第二页: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 状态,不展开完整执行链条。

示例表达:

已创建 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 bannerOffice 改名 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 管理界面至少分两类:

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

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

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

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

定时任务
│
├─ 计划规则
│  ├─ 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纵向阶段链

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

优点:

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

缺点:

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

方案 BDAG 链条图

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

优点:

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

缺点:

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

方案 C阶段链 + 节点分组

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

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. 技能页应该覆盖的生命周期

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. 本页剩余待讨论问题

暂无。