| name | Task_Plan |
| slug | task_plan |
| version | 1.1 |
| description | 将复杂用户请求自动分解为可执行步骤计划，可视化进度，支持暂停/继续/中止。受用户 config.json 中 task_plan.accept_task 控制。 |
| category | task |
| enabled | true |
| tags | ["task","plan","scheduler"] |
任务计划 (Task Plan)
管理复杂任务的分解、执行和追踪。存储在 users/<name>/task-plan/。
插件路径
plugins/task_plan/
注册工具
| 工具 | 用途 |
|---|
task_plan_create | 调用子代理分析对话 → 生成结构化执行计划 |
task_plan_list | 列出当前用户的所有计划及进度 |
task_plan_view | 查看计划详情（含所有步骤、状态、结果）。不传 plan_id 时查看活跃计划 |
task_plan_step_done | 标记步骤完成并记录结果 |
task_plan_step_fail | 标记步骤失败并记录错误，计划自动暂停 |
task_plan_abort | 中止计划，未完成步骤标记为跳过 |
task_plan_edit | 编辑计划步骤的描述或参数 |
参数
task_plan_create
| 参数 | 类型 | 必需 | 说明 |
|---|
description | string | 是 | 用户请求的简要描述，用于生成计划标题和上下文 |
task_plan_view
| 参数 | 类型 | 必需 | 说明 |
|---|
plan_id | string | 否 | 计划 ID（如 plan_a1b2c3d4），不传时查看当前活跃计划 |
task_plan_step_done
| 参数 | 类型 | 必需 | 说明 |
|---|
plan_id | string | 是 | 计划 ID |
step_id | string | 是 | 步骤 ID |
result | string | 否 | 步骤执行结果摘要（建议 200 字以内） |
task_plan_step_fail
| 参数 | 类型 | 必需 | 说明 |
|---|
plan_id | string | 是 | 计划 ID |
step_id | string | 是 | 步骤 ID |
error | string | 是 | 错误描述 |
task_plan_edit
| 参数 | 类型 | 必需 | 说明 |
|---|
plan_id | string | 是 | 计划 ID |
step_id | string | 否 | 步骤 ID（编辑特定步骤时必填） |
description | string | 否 | 新的描述文本 |
params | string | 否 | 新的工具参数（JSON 字符串） |
状态枚举
| 计划状态 | 说明 | 步骤状态 |
|---|
pending | 等待批准 | pending |
in_progress | 执行中 | in_progress |
completed | 已完成 | completed |
paused | 已暂停（失败或手动暂停） | failed |
aborted | 已中止 | skipped |
子代理
agents/task_plan/agent.py::generate_plan() — 同步 LLM 调用，无流式无工具。
generate_plan_stream() — 流式版本，逐 chunk 推送到 Web SSE。
输入：完整对话 + 可用工具列表 + 技能目录 + system prompt
输出：{plan: {title, description, steps[{id, description, tool_calls, status}]}}
配置控制
| 配置 | 位置 | 效果 |
|---|
task_plan.accept_task: true | users/<name>/config.json | 计划创建后自动批准并执行 |
task_plan.accept_task: false | 同上 | 需用户在 Web UI 手动批准 |
task_plan.max_steps | config/config_core.json | 子代理生成计划的最大步骤数（默认 10） |
存储路径
users/<name>/task-plan/plan_<uuid8hex>.json
常见规范
- 计划创建后强制刷新 system prompt，使计划信息立即注入 LLM 上下文
- 同一时间只允许一个活跃计划（in_progress 或 pending）
- 每步执行完成后必须调用
task_plan_step_done，失败调用 task_plan_step_fail
- 步骤失败后计划自动暂停，等待用户介入或修改后继续
常见处理办法
- 已有活跃计划：先
task_plan_view 查看当前计划，完成或 task_plan_abort 后再创建新计划
- 计划已暂停：用户修改步骤后调用
task_plan_edit，计划自动恢复为 in_progress
- 用户未启用：检查
config.json 中的 task_plan.accept_task 配置
- 计划生成失败：检查子代理的 provider 配置是否可用
常见教训
- 防覆写机制：磁盘上已为
aborted 状态的计划不会被覆盖
- 计划原子写入：先写临时文件再 rename，防止写一半被读到
- 路径穿越校验：plan_id 通过
validate_plan_filepath() 统一校验，tool 层和 web 层共用
accept_task: false 时计划仅为 pending 状态，不会自动执行
