- 集成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方法重新构建全文搜索索引 - 优化索引触发器和表的维护流程
37 KiB
前端需求讨论
当前讨论到第二页:Task 管理界面。
这份文档先不展开其它页面。每次只把一页讲清楚:页面定位、用户目标、必须展示什么、不要塞什么、争议点是什么。等这一页定下来,再开下一页。
相关参考:
- 后端运行结构:
../backend/flow.md - 后端施工状态:
../backend/施工指南.md - 长期蓝图:
../backend/change.md - 旧系统蓝图:
../backend-old/change.md
第 1 页:对话页
路径:/
一句话定位:
对话页是用户和主 Agent 交互的主工作台。它负责提交问题/任务、展示最终回答、展示必要的运行状态,并收集用户对 Task 结果的反馈。
它承担一部分轻量后台管理工作,主要是会话管理和任务入口。但它不应该变成完整后台管理台,也不应该让用户直接配置 team strategy、sub-agent、MCP、插件市场等系统能力。
已确认的方向:
- session 不做“删除”,改成“归档”。
- 归档后的 session 不再出现在前端会话列表。
- 归档不等于抹除记忆;相关记忆和历史数据仍然存在。
- 附件是对话页第一版必须能力。
- Slash command 不保留。
- 复杂任务创建后,对话中显示 Task 创建回复,点击跳转到 Task 管理界面。
- 原
Office概念改名为Task,并删除图形化办公室展示,改为更合理的任务交互过程与链条展示。 - “需要修改”走类似 Codex plan mode 的选择/评论框;用户也可以继续在主聊天框说话,此时默认上一轮结果满意。
- 验证失败时,大字显示状态,详细原因小字展示并默认折叠,可展开查看。
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 会话区
必须支持:
- 新建会话。
- 切换会话。
- 归档会话。
- 显示会话最近更新时间或可读标题。
- 默认不显示已归档会话。
暂不确定:
- 是否需要会话搜索。
- 是否需要手动重命名。
- 是否需要 pin。
- 是否需要“查看已归档会话”的二级入口。
已确认:
- 不使用“删除”语义。
- 归档只影响前端列表可见性,不等于删除记忆或永久清除历史。
3.2 消息区
必须支持:
- 展示用户消息。
- 展示 assistant 最终回答。
- 刷新后保留
run_id / task_id / task_status / validation_status / feedback_state对应的 UI 状态。 - 对 Markdown 内容做稳定渲染。
不应该做:
- 不直接展示隐藏事件原始 JSON。
- 不把 sub-agent 的中间 summary 当成最终回答。
- 不让用户手动改内部 Task 状态。
3.3 输入区
必须支持:
- 输入文本。
- 发送。
- 发送失败时明确提示。
- 运行中避免重复提交,或明确支持排队。
- 上传附件。
- 在消息中展示用户已提交的附件。
暂不确定:
- 附件进入模型上下文的具体语义:作为文件引用、文本提取、图片输入,还是先作为 workspace 文件供工具读取。
- 是否要提供模型/provider 快捷选择。
不保留:
- Slash command。
3.4 运行状态
必须支持:
- 等待模型时显示“思考中”。
- Task 验证中有明确状态。
- 验证失败重试时有明确状态。
- 失败时告诉用户失败发生在发送、运行、验证还是反馈。
- 验证失败时,大字显示失败状态。
- 验证详细原因放在状态下方,以小字/展开区展示,默认折叠。
当前缺口:
- 现在基本只有 thinking。
- 验证中、重试中、Task awaiting feedback 没有足够清晰的产品化表达。
3.5 反馈区
必须支持:
- 只对最新 assistant Task 结果显示反馈。
- 三种反馈:满意、需要修改、放弃。
- 已反馈后显示反馈状态。
- 反馈失败时显示错误。
- “满意 / 需要修改”使用带评论框的选择交互。
- 用户如果不点反馈、直接在主聊天框继续聊天,则默认上一轮结果满意。
待继续细化:
- “满意”的评论框是可选还是默认隐藏。
- “需要修改”的评论是否必填。
- “放弃”是否需要二次确认。
- “满意”后是否显示“已用于学习候选”之类的反馈。
3.6 Task 入口
必须支持:
- 复杂任务创建后,对话流中出现一条 Task 创建回复。
- Task 创建回复包含可读标题或 description。
- 用户点击 Task 链接后跳转到 Task 管理界面。
- 对话页只保留轻量 Task 状态,不展开完整执行链条。
示例表达:
已创建 Task:整理最近三个月销售数据并生成分析结论
查看 Task
不应该做:
- 不展示未实现的策略按钮,例如
moa / hierarchy / group_chat。 - 不让用户选择 specialist agent 来影响当前 Task。
- 不把完整过程链条塞在对话页主界面。
- 不再使用
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. 当前版本建议稿
这是讨论稿,不是最终结论。
对话页当前版本收敛成:
- 左侧:会话列表。
- 删除改为归档。
- 归档后不在默认列表展示。
- 中间:消息流 + 输入框。
- 输入区保留附件能力。
- 移除 Slash command。
- 复杂任务创建后,在对话流里显示 Task 创建回复和跳转链接。
- 移除顶部 Office banner。
Office改名为Task;完整任务过程进入 Task 管理界面展示。- 最新 Task 回答下:满意 / 需要修改 / 放弃。
- “满意 / 需要修改”使用类似 Codex plan mode 的选择评论框。
- 用户不点反馈、直接继续聊天时,默认上一轮结果满意。
- 验证失败:大字状态,详细原因折叠展示。
- 对话页不提供 Team 策略选择、Sub-agent 选择、Skill 审核、MCP/插件/Outlook 管理。
8. 已确认问题
| 问题 | 结论 |
|---|---|
| 对话页是不是只作为“主工作台”,不承担后台管理? | 承担部分轻量后台管理,尤其是 session 归档和 Task 入口 |
| 附件是不是对话页第一版必须能力? | 是,必须保留 |
| Slash command 是否继续保留? | 不保留 |
| 过程区是默认显示,还是复杂任务出现后再显示? | 不常驻完整过程区;复杂任务创建后显示 Task 链接,点击进入 Task 管理界面 |
| Office 入口是否应该出现在对话页顶部? | 不应该;Office 改名 Task,入口放在对话消息中 |
| “需要修改”是否需要评论框? | 需要;满意/需要修改使用选择评论框,用户继续主聊天则默认满意 |
| 验证失败时,用户需要看到详细原因还是只看状态? | 大字状态 + 默认折叠的小字详细原因 |
9. 下一页遗留给 Task 管理界面的问题
这些问题不在对话页继续展开,留到下一页“Task 管理界面”讨论:
- 原 Office 页改名 Task 后,路由叫
/tasks还是继续兼容/office。 - Task 管理界面如何展示任务交互过程和链条。
- 是否支持暂停、取消、重试某个 Task 或某个节点。
- 子任务、验证、技能选择、工具调用、产物如何分层展示。
- 删除图形化办公室后,新的 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 配置页,不是完整后台设置页。
已确认的方向:
- 路由改为
/tasks,旧/office跳转到/tasks。 - 任务管理入口分为“普通任务 / 定时任务”两个 tab。
- 当前
/cron能力并入“定时任务”tab,不再作为顶层导航。 - 普通任务列表需要存在,用户可以从列表进入普通任务详情。
- 普通任务详情采用“阶段链 + 节点分组”展示执行链条。
- 普通任务详情允许直接输入修订意见。
- 用户可以暂停、取消、重试普通 Task 或节点。
- 第二次验证失败后,普通任务用户可见状态叫“任务失败”。
- sub-agent 输出只算节点结果,不算产物。
- 产物需要下载按钮,支持单个下载或全部下载。
- 已归档 session 里的普通任务仍然在普通任务列表显示。
- 已放弃普通任务不允许恢复。
- 所有任务没有归档概念;定时任务可以暂时关闭,也可以删除。
- 定时任务每次触发都创建普通 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 | 计划任务列表、新建任务、启停、编辑、手动运行 |
| 全局空状态 | 引导用户回到对话页创建普通任务,或创建一个定时任务 |
待讨论:
- 入口是否叫
任务,英文是否叫Tasks。 - tabs 名称是“普通任务 / 定时任务”,还是“任务 / 计划任务”。
- 是否需要全局搜索。
3.2 普通任务列表
| 区域 | 内容 |
|---|---|
| 状态筛选 | 全部、运行中、等待反馈、需要修改、已完成、已放弃、失败 |
| 任务卡片/表格 | 标题、description、来源会话、状态、当前阶段、更新时间、子任务数量、失败数 |
| 快速动作 | 打开详情、回到对话、暂停、取消、重试 |
| 空状态 | 引导用户回到对话页创建复杂任务 |
普通任务列表不负责展示完整链条,只负责让用户找到任务并进入详情。
已确认:
- 普通任务列表需要存在。
- 已归档 session 里的普通任务仍然显示。
- 普通任务没有归档概念。
- 已放弃普通任务不允许恢复。
3.3 定时任务列表
| 区域 | 内容 |
|---|---|
| 顶部动作 | 新建定时任务 |
| 列表字段 | 名称、启用状态、计划类型、计划表达式、目标会话、消息摘要、上次运行、下次运行、最近结果 |
| 快速动作 | 启用/停用、编辑、手动运行、删除 |
| 空状态 | 引导用户创建一个计划任务 |
定时任务管理保留现在 /cron 页的主要能力,但归入 Task 管理页,不再作为顶层独立概念。
已确认:
- 定时任务可以暂时关闭,也可以删除。
- 定时任务没有归档概念。
- 每次定时触发都创建普通 Task。
- 定时任务运行历史必须链接到对应普通 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
优点:
- 最容易读。
- 移动端友好。
- 和事件时间顺序一致。
缺点:
- 对 parallel / dag 的依赖关系表达较弱。
方案 B:DAG 链条图
Planner
├── Node A ──┐
├── Node B ──┼── Synthesis ── Validation
└── Node C ──┘
优点:
- 能清楚表达依赖关系。
- 对 team/dag 任务更准确。
缺点:
- 实现和布局复杂。
- 小屏幕容易难读。
方案 C:阶段链 + 节点分组
纵向展示阶段,在 team execution 阶段内部用节点分组表达 sequence / parallel / dag:
Plan
↓
Team execution
Group 1: Node A + Node B 并行
Group 2: Node C 依赖 A/B
↓
Main synthesis
↓
Validation
优点:
- 兼顾可读性和结构。
- 比纯 DAG 更适合产品界面。
- 能覆盖 sequence / parallel / dag。
缺点:
- 需要后端或前端把 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 | 可选 | 开发者调试用,不默认展示 |
已确认:
- sub-agent 输出属于节点结果。
- 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 | 执行失败且没有恢复,或第二次验证仍失败 |
已确认:
- 第二次验证失败后,用户可见状态叫“任务失败”。
- 用户可以暂停、取消、重试普通 Task 或节点。
待讨论:
- 用户继续聊天默认满意后,状态是否直接变“已完成”。
- 暂停/取消/重试分别作用于整个 Task 还是当前节点时,状态如何显示。
7. 普通任务反馈与修订
普通任务详情页和对话页要保持一致。
必须支持:
- 满意。
- 需要修改。
- 放弃。
- 满意/需要修改的评论框。
- 用户在对话页继续聊天时,默认上一轮 Task 结果满意。
- 普通任务详情页允许直接输入修订意见。
待讨论:
- 详情页内输入修订意见时,是否同步写回来源会话消息流。
- 放弃是否需要原因。
已确认:
- 已放弃普通任务不允许恢复。
8. 普通任务详情:产物区
产物需要先定义清楚,否则会变成空面板。
可能的产物类型:
| 类型 | 例子 | 来源 |
|---|---|---|
| 文件 | 生成的报告、代码、表格 | filesystem tool / workspace |
| 链接 | 搜索结果、外部引用 | web tool / MCP |
| JSON | 结构化计划、评估报告 | hidden events / validation |
| 图片 | 生成图、上传图分析结果 | attachment / tool |
| 文本报告 | 节点输出、最终总结 | main synthesis / sub-agent |
待讨论:
- 无。
已确认:
- sub-agent 输出只算节点结果,不算产物。
- 产物区需要下载按钮。
- 下载可以支持单个产物下载或全部下载。
- validation report 属于验证区,不算产物。
- 用户上传附件不出现在 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. 本页剩余待讨论问题
- 是否需要任务搜索。
说明:“全局搜索任务”指任务管理页里是否需要一个搜索框,可以跨普通任务和定时任务搜索任务标题、description、来源会话、状态、定时任务消息内容等。不是全站搜索,也不是搜索聊天内容。
第 3 页:技能页
建议路径:/skills
一句话定位:
技能页是 Agent 能力生命周期管理台。它负责查看已发布技能、处理学习候选、生成和审核草稿、查看安全/评估报告,并把通过审核的技能发布到 runtime catalog。
它不是聊天页,也不是直接在线编辑 published skill 的地方。
已确认的方向:
- 主 tab 确定为“已发布 / 候选 / 草稿评审”。
- “运行学习”按钮不放在技能页。
- 保留技能上传;上传后必须进入 draft/review 流程。
- 保留技能下载。
- 允许删除技能。
- 已发布技能暂时不需要版本历史和 diff。
- 草稿评审需要 diff 视图。
- approve/reject 不强制填写 notes。
- publish 不需要二次确认。
- high risk draft 允许发布,但必须展示理由。
- candidate 允许忽略/关闭。
- 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
核心约束:
- draft 不进入 runtime catalog。
- rejected draft 不可 publish。
- publish 必须要求 approved review + safety passed + eval not failed。
- high risk publish 需要显式确认。
- worker 可以自动到 draft/safety/eval,但永不自动 approve/publish。
- 不允许绕过 lifecycle 直接在线改 published skill。
3. 页面结构建议
技能页建议保留三个主 tab:
| Tab | 目的 |
|---|---|
| 已发布 | 查看 runtime catalog 中当前可用/不可用的技能 |
| 候选 | 查看 learning candidates,决定是否生成/重生成草稿 |
| 草稿/评审 | 审核 draft,查看 safety/eval,批准/拒绝/发布 |
3.1 已发布 tab
| 区域 | 内容 |
|---|---|
| 技能列表 | 名称、描述、来源、状态、当前版本、更新时间 |
| 状态标识 | available / unavailable / disabled / retired |
| 操作 | 查看详情、禁用、回滚、删除、下载、上传 |
| 可选操作 | 复制路径、查看支持文件 |
已确认:
- 保留上传技能。
- 上传后必须进入 draft/review 流程。
- 保留下载技能。
- 允许删除技能。
- 已发布技能暂时不需要版本历史和 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 | 退役技能建议 |
待讨论:
- 是否允许用户手动创建 candidate。
已确认:
- 技能页不放“运行学习”按钮。
- candidate 允许忽略/关闭。
- 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 |
已确认:
- 草稿评审需要 diff 视图。
- approve/reject 不强制填写 notes。
- publish 不需要二次确认。
- high risk draft 允许发布,但必须展示理由。
- 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. 本页剩余待讨论问题
暂无。