Taskr - Persistent Task Planning & Execution for AI Agents

核心用法

Taskr 是一套专为 OpenClaw 设计的持久化任务管理系统，将任务规划、执行与审计完全脱离对话上下文，存储于云端。其核心工作流遵循「Plan → Create → Review → Execute → Document」的闭环：用户首先通过 create_task 一次性创建包含最多10层嵌套的完整任务层级（支持1-100个任务），并立即附加 CONTEXT 类型笔记记录背景与目标；经用户审批后，代理通过 get_task 自动获取所有权（状态变为 wip），单任务顺序执行，完成后以 update_task 标记状态；过程中通过 create_note 附加 FINDING/PROGRESS/FILE_LIST 等笔记形成审计链。

关键特性包括：task_sync 三步回溯法（survey → drill-in → create_done）可补录 Taskr 激活前已完成的工作；跨代理连续性允许任何机器、任何模型、任何会话无缝接管任务；共享状态机（open/wip/done/skipped）让用户通过 Web/VS Code/移动端实时可视化进度。

显著优点

1. 上下文免疫：任务状态 survives 会话重置与上下文压缩，彻底解决长对话中的「失忆」问题
2. 协作原生：任务所有权自动转移，支持多代理接力与人类异步审批
3. 审计完整性：笔记直接挂载于任务节点，因果链条清晰，告别聊天记录碎片化
4. 灵活回溯：task_sync 填补历史空白，已完成的线下工作可结构化归档
5. 用户主权：计划阶段即可审查，执行透明可控

潜在局限

• 学习成本：层级编号系统（1.1.2）、笔记类型规范、单任务纪律需要适应
• 重流程设计：对于<3步的短时任务，启动 overhead 可能不经济
• 外部依赖：任务状态依赖 Taskr 云服务，离线场景不可用
• API 限制：免费档 200调用/小时，重度使用可能触发限流

适合人群

• 需要跨会话延续复杂项目的专业用户
• 多代理协作场景下的团队/组织
• 对可审计性、可追溯性有合规要求的场景
• 希望「人审机执」、保持对工作流控制权的用户

常规风险

• 状态漂移：若代理未遵守「单任务纪律」中途放弃，会导致 wip 任务悬空
• 凭证管理：MCP_USER_API_KEY 等敏感配置需用户妥善保管
• 过度规划：层级过深（接近10层）或任务粒度过细可能增加管理负担而非降低
• 同步滞后：云端状态与本地执行存在网络延迟，极端情况下可能产生竞态

核心用法

Taskr 是专为 OpenClaw 设计的持久化任务管理系统，通过 MCP 工具调用实现云端任务规划与执行。其核心工作流程遵循「Plan → Create → Review → Execute → Document」闭环：

1. 分层规划（Hierarchical Planning）
使用 create_task 配合 taskListTitle 一次性创建 1-100 个任务，支持最多 10 层嵌套（如 "1.1.2"）。必须在执行前完成完整规划，让用户先行审阅。

2. 跨会话持久化
任务状态（open/wip/done/skipped）、笔记与上下文存储于云端，不受上下文窗口限制。任何 Agent 可在任意会话、任意机器上通过 get_task 自动接管未完成任务。

3. 审计追踪（Notes 系统）
五类笔记直接附加于任务节点：

• CONTEXT：任务列表创建后立即附加，记录背景与目标
• FINDING：执行中发现的问题或阻碍
• PROGRESS：仅用于阶段级任务（phase-level）里程碑
• FILE_LIST：文件变更记录
• OTHER：其他补充信息

4. 用户审批机制
执行前必须向用户展示任务分解方案并获得确认，支持通过 Taskr Web 应用、VS Code 扩展或移动端远程监控进度。

5. 历史补录（task_sync）
三步流程（Survey → Drill → Create）将 Taskr 激活前已完成的工作 retroactively 录入系统，消除历史盲区。

显著优点

| 维度 | 优势 |

|------|------|

| **可靠性** | 任务状态云端持久化，彻底规避「上下文丢失导致计划中断」风险 |

| **协作性** | `get_task` 自动转移所有权，天然支持多 Agent 接力完成复杂任务 |

| **透明性** | 用户可通过多平台实时查看进度，笔记系统确保因果链条不碎片化 |

| **规范性** | 强制「先规划后执行」与「单任务纪律」（同一时间仅处理一个 `wip` 任务），降低执行混乱 |

| **可审计** | 完整的 `skipped` 理由记录、进度里程碑标记，满足合规追溯需求 |

| **灵活性** | `task_sync` 支持历史补录，中期发现的新任务可通过 `parentId` 动态插入 |

潜在局限

1. 认知开销：简单任务（<3 步、<2 分钟）强制使用 Taskr 会产生过度工程化负担，官方明确建议此类场景跳过
2. 外部依赖：核心功能依赖 taskr.one 云服务可用性，离线环境无法使用
3. 学习曲线：需掌握任务编号规则（层级编码）、笔记类型区分、批量/单条更新模式差异等约定
4. 成本考量：免费版 200 次/小时调用限制，大规模任务管理可能需要付费升级
5. Vendor Lock-in：数据存储于第三方云服务，迁移成本与数据主权需用户自行评估

适合人群

• 复杂项目开发者：需要分解多阶段技术任务并跨 session 持续跟踪
• 团队协作场景：多 Agent 或多开发者需共享任务上下文与进度状态
• 合规敏感用户：需要完整审计日志记录决策过程与执行轨迹
• 远程监控需求者：希望通过 Web/移动端独立查看 AI 执行进度，而非完全依赖对话窗口

常规风险

| 风险类别 | 具体表现 | 缓解措施 |

|----------|----------|----------|

| **配置泄露** | API Key 硬编码或误提交至版本控制 | 强制使用环境变量注入，SKILL.md 已提供 `.env` 与系统密钥管理建议 |

| **状态不一致** | Agent 异常终止导致 `wip` 任务悬空 | 新 Agent 可通过 `get_task` 自动接管，但需人工确认或超时机制 |

| **过度规划** | 简单任务套用复杂流程，降低效率 | 遵循「3 步/2 分钟」跳过原则，主动询问用户是否启用 Taskr |

| **笔记泛滥** | 无纪律的笔记创建导致信息噪音 | 严格遵循笔记类型定义，优先使用 `update_note` 而非重复创建 |

| **服务可用性** | taskr.one 服务中断导致任务系统瘫痪 | 关键任务建议本地备份，关注官方状态公告 |

Taskr 代表了 AI 任务管理从「一次性对话」向「结构化工程化」演进的重要范式，其设计哲学强调可见性、可恢复性与用户控制权，适合对可靠性与可追溯性有较高要求的专业场景。