Appearance
功能规格说明:任务管理工具与 UI
创建日期:2026-02-11
用户场景与测试 (必填)
用户故事:创建和跟踪任务(优先级:P1)
作为用户,我希望创建一个新任务,以便跟踪我在特定目标上的进度。
为什么是这个优先级:这是核心功能。没有任务创建,其他工具就没有数据可以操作。
独立测试:可以通过调用 TaskCreate 并验证在正确目录中创建了具有预期内容的 JSON 文件来进行完整测试。
验收场景:
- 假设会话处于活动状态,当我使用主题和描述调用 TaskCreate 时,则创建一个具有唯一 ID 的新任务并存储在
~/.wave/tasks/{taskListId}/{taskId}.json中。 - 假设任务已创建,当我使用 taskId 调用 TaskGet 时,则我收到该任务的完整详情。
用户故事:更新任务进度(优先级:P2)
作为用户,我希望更新任务状态并添加评论,以便保持我的进度记录为最新。
为什么是这个优先级:任务管理是动态的;能够更新状态和添加注释对于跟踪工作进度至关重要。
独立测试:可以通过对现有任务调用 TaskUpdate 然后通过 TaskGet 验证更改或检查 JSON 文件来进行测试。
验收场景:
- 假设存在一个现有任务,当我使用新状态(例如"in_progress"、"completed")调用 TaskUpdate 时,则任务的状态在存储中被更新。
- 假设存在一个现有任务,当我使用元数据或描述更改调用 TaskUpdate 时,则任务被相应更新。
用户故事:列出所有任务(优先级:P3)
作为用户,我希望看到当前会话的所有任务列表,以便获得工作概览。
为什么是这个优先级:提供跨多个任务的可见性,这对于管理复杂工作流很重要。
独立测试:可以通过创建多个任务并调用 TaskList 来确保所有任务都被返回来进行测试。
验收场景:
- 假设当前任务列表存在多个任务,当我调用 TaskList 时,则我收到所有任务的摘要列表,包括其 ID、主题和当前状态。
用户故事:在聊天 UI 中查看任务列表(优先级:P1)
作为用户,我希望在消息列表底部看到当前任务的摘要,以便始终跟踪进度而无需手动列出任务。
为什么是这个优先级:这在对话流程中提供对任务状态的即时可见性。
独立测试:可以通过创建任务并验证任务列表组件出现在聊天界面底部来进行测试。
验收场景:
- 假设当前会话中有活动任务,当我查看消息列表时,则任务列表摘要显示在底部。
- 假设任务列表已显示,当任务状态更改时,则任务列表 UI 更新以反映新状态。
- 假设一个已保存会话的任务全部处于已完成状态,当我打开或切换到该会话时,则任务列表立即保持隐藏,不会先短暂显示再于数秒后消失。
- 假设当前会话的活动任务超过 4 个,当我查看任务列表时,则列表最多同时显示 4 个任务,其余任务在列表区域内滚动查看。
用户故事:废弃遗留 TodoWrite 工具(优先级:P4)
作为系统维护者,我希望移除遗留的 TodoWrite 工具,以便 agent 专门使用新的任务管理系统。
为什么是这个优先级:确保向新系统的平稳过渡,并防止旧任务管理方法与新方法之间的混淆。
独立测试:验证 TodoWrite 不再出现在 agent 的工具集中。
验收场景:
- 假设 agent 已初始化,当我列出可用工具时,则
TodoWrite不在列表中。
用户故事:任务提醒注入(优先级:P3)
作为系统,我必须定期提醒 agent 使用任务跟踪工具,以确保 agent 不会遗忘对任务进度的管理。
为什么是这个优先级:任务提醒是辅助性功能,提升 agent 自主管理任务的意识,但不影响核心任务 CRUD 操作。
独立测试:可以通过模拟连续 10 个 assistant turn 不使用 TaskCreate/TaskUpdate,然后验证下一次 API 调用中注入了提醒消息来进行测试。
验收场景:
- 假设会话处于活动状态且 TaskCreate/TaskUpdate 工具可用,当连续 10 个 assistant turn 未调用 TaskCreate 或 TaskUpdate,且距上次提醒也已过去至少 10 个 assistant turn 时,则系统在下一次 API 调用中注入一条 user 消息形式的任务提醒,并将该提醒持久化到会话历史中作为
isMeta: true消息,确保后续轮次的计数器能检测到该提醒。 - 假设提醒已注入,当 agent 收到提醒时,则提醒内容指示 agent 不得向用户提及该提醒的存在。
- 假设当前存在活动任务,当提醒触发时,则提醒消息末尾附加当前任务列表,格式为
#id [status] subject。 - 假设当前任务列表为空,当提醒触发时,则提醒消息仍然注入,作为通用提醒,不包含任务列表。
- 假设 agent 调用了 TaskCreate 或 TaskUpdate,当工具执行完成后,则
turnsSinceLastTaskManagement计数器重置为 0。 - 假设 agent 调用了 TaskList 或 TaskGet(只读工具),当工具执行完成后,则
turnsSinceLastTaskManagement计数器不被重置。
边界情况
- 任务 ID 不存在时会发生什么? TaskGet 和 TaskUpdate 应返回清晰的错误消息,指示任务未找到。
- 系统如何处理无效的状态转换? 系统应验证提供的状态是允许值之一。
- 如果存储目录不可写会怎样? 工具应优雅地处理文件系统错误。
- 任务很多时会发生什么?
TaskManager.listTasks()始终按 ID 升序返回;TaskList 组件在此稳定顺序之上,最多同时显示 4 个任务,多余任务在固定高度的列表区域内滚动查看,并通过折叠摘要和自动隐藏已完成任务来处理长任务列表。 - 如果 TaskCreate/TaskUpdate 工具不可用会怎样? 系统必须完全跳过任务提醒注入,不发送任何提醒消息。
- 如果任务列表为空会怎样? 提醒仍然触发,作为通用提醒鼓励 agent 使用任务跟踪,但不附加任务列表。
- 并发创建任务时会发生什么? 系统使用会话级排他文件锁串行化"读取最大 ID + 写入任务文件"这一临界区,确保并发
TaskCreate调用获得唯一递增 ID,不会产生重复或冲突。 - 进程在持有锁时崩溃会怎样? 后续获取者检测到锁文件 mtime 超过陈旧阈值(10 秒)时,判定持有者已不活跃,将其删除后重试,不会因遗留锁文件而永久卡死。
- Windows 上释放锁后立即重新获取会怎样? Windows 文件系统在删除文件后存在 pending-delete 窗口,此时以
wx方式打开可能返回EPERM而非EEXIST;系统将EPERM视为瞬时错误进行有界重试,而非硬失败。