OpenClaw 持久云任务规划与执行。创建层级任务计划,可在会话重置后保留,跨多个代理运行,并让用户重新...
任务员 — 持续性任务规划和执行是一项面向实际任务的技能,主要用于任务员给OpenClaw 代理持续、结构化的任务管理, 并且生活在聊天会话之外;计划幸存上下文重排, 可以恢复。
从功能定位来看,该技能强调把分散的操作要求整理成清晰、可复用的处理流程,使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数,再依据技能说明逐步执行;
若输入条件不完整,应先补齐信息或采用保守配置,避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期,并对异常提示、缺失字段和边界情况进行处理;涉及批量任务时,还应保存进度,避免中断后重复操作。
Taskr 为 OpenClaw 智能体提供持久化、结构化的任务管理能力,该能力独立于聊天会话之外运行。任务计划可在上下文重置后继续存在,可由任意机器上的任意智能体恢复执行,并始终通过 Taskr 网页应用、VS Code 插件或移动应用向用户可见。
Taskr 为 OpenClaw 提供六大核心能力:
get_task 自动完成任务所有权转移task_sync 可记录 Taskr 启用前已完成的工作,补全历史记录中的空白open、wip、done、skipped)为智能体与用户提供明确、实时的进度视图建议在以下情形中启用 Taskr:
无需使用 Taskr 的情形:
主动默认策略: 对于任何实质性工作,应在启动前主动提议使用 Taskr:
“我将先在 Taskr 中进行规划——您可在执行前审阅任务分解方案。是否可行?”
一旦启用 Taskr,请全程保持在 Taskr 工作流内。 切勿在工作流程中途放弃任务。仪表板中未完成的任务会造成理解混乱,并破坏审计追踪的完整性。
规划 → 创建 → 创建 CONTEXT 备注 → 用户审阅 → 执行 → 归档 → 循环
create_task 并指定 taskListTitle,单次调用即可构建完整任务层级get_task → 执行工作 → 调用 update_task 将状态设为 done → 重复此流程单任务原则: 每次仅处理一个任务。get_task 将使你成为该任务的负责人(wip),必须在切换至下一任务前完成或跳过当前任务。
使用带 taskListTitle 参数的 create_task 创建新任务列表。单次调用可提交 1–100 个任务——务必在执行开始前一次性创建完整层级,以便用户审阅。
层级编号规则:
"1"、"2"、"3" —— 顶层阶段(任务列表的直接子节点)"1.1"、"1.2" —— 阶段 1 下的子任务"1.1.1" —— 更深层级嵌套(最多支持 10 层)任务类型: setup、analysis、implementation、validation、testing
保持任务聚焦。 若某任务体量过大,无法在单次智能体响应中完成,则应将其拆分为子任务——可在创建时完成,也可在执行中途通过 create_task + parentId 动态拆分。子任务可避免上下文过载,并在恰当粒度上清晰呈现进展。
创建任务列表后,请立即为其创建一条 CONTEXT 备注:
create_note(type="CONTEXT", title="[Task List] — Context", body="...", taskId="TL_...")
调用 get_task 获取下一个待处理任务。该操作将自动将任务状态设为 wip 并分配所有权。请务必使用 get_task,切勿手动将任务设为 wip。
task_list_id 参数以继续当前任务列表task_list_id=TL_... 以切换至其他任务列表include_context=true 可获取额外任务上下文与备注bypass_task_id状态更新模式(单任务):
update_task(taskId="TS_...", status="done", ruleContext="RU-PROC-001")
批量更新模式(仅支持标题/描述更新,批量模式下禁止设置状态):
update_task(tasks=[{taskId, title?, description?}, ...], ruleContext="RU-PROC-001")
状态是智能体与用户均可实时查看的检查点,请严格遵循规范使用。
| 状态 | 含义 |
|---|---|
open |
已就绪,可立即开始处理 |
wip |
已被某智能体主动接管并处理中 |
done |
已完成且经验证确认 |
skipped |
经审慎判断决定跳过 —— 必须创建一条 FINDING 备注说明原因 |
当某父任务的所有子任务均完成时,系统将自动将该父任务标记为 done,无需手动设置。
当发现超出当前任务范围的工作时:
create_task(parentId 设为当前任务),完成子任务后再恢复主任务使用 get_task_hierarchy 浏览与审阅任务结构 —— 请勿使用 get_task 进行结构查看。切勿仅为查看结构而调用 get_task。
| 作用域 | 返回内容 |
|---|---|
project |
所有任务列表。建议优先使用 depth=0 仅获取名称列表,避免 token 消耗过高 |
task_list |
单个任务列表的完整嵌套层级。需传入 taskId=TL_... |
subtree |
某任务及其全部后代任务。需传入 taskId=TS_... |
task_list 作用域下的响应路径:data.task_lists[0].tasks[0].children[]
备注与具体任务绑定。例如在任务 2.3 执行过程中发现的问题,其 FINDING 备注将永久附着于任务 2.3,而非悬浮于项目层级。后续任何智能体恢复工作时,均可在所需位置获得完整上下文。这正是防止信息碎片化的关键机制。
备注类型:
| 类型 | 适用场景 |
|---|---|
CONTEXT |
背景说明、目标设定、用户偏好、关键决策等 —— 任务列表创建后立即为 TL_ 创建 |
FINDING |
执行过程中发现的问题、障碍、洞察或异常情况 |
PROGRESS |
阶段里程碑 —— 仅用于阶段级任务(即编号为 "1"、"2"、"3" 的任务,即任务列表的直接子节点)。不适用于叶子任务 |
FILE_LIST |
用户系统中创建、修改或删除的文件列表 |
OTHER |
不属于上述类别的其他内容 |
备注使用规范:
update_notesearch_notes 可在恢复工作时快速获取先前上下文skipped 状态时,必须同时创建一条含原因说明的 FINDING 备注两步式备注检索:
list_notes(taskId="TL_...", includeDescendants=true) —— 获取备注 ID 与标题(data.notes.notes[])get_note(noteId="NT_...") —— 按需获取完整内容当工作已在 Taskr 启用前完成,或需回溯性补全任务历史记录空白时,请使用 task_sync。共三步操作:
步骤 1 —— 概览(无参数):轻量级汇总所有任务列表
task_sync(ruleContext="")
→ data.sync_check.task_lists[]: {id, name, status, task_count, done_count, open_count, wip_count}
步骤 2 —— 深入查看(传入 task_list_id):平铺列出所有任务的标题、描述、状态与层级
task_sync(task_list_id="TL_...", ruleContext="")
→ data.sync_drill_down.tasks[]: {id, task_number, title, description, status, level, parent_id}
步骤 3 —— 创建已完成任务(传入 items[]):创建预设状态为 done 的任务
task_sync(items=[
{
"action": "create_done",
"title": "...",
"parentId": "TS_or_TL_...",
"description": "...",
"type": "implementation"
}
], ruleContext="")
每项必须包含 action: "create_done" 与 title。若未提供 parentId(TS_ 或 TL_),则需提供 taskListTitle 以创建新任务列表;未指定 parentId 的条目将默认归属至该新列表。单次调用最多支持 50 项。
同步完成后,请为所创建任务附加 CONTEXT 或 FINDING 备注,以记录工作的背景与决策依据。
Taskr 状态存储于云端,而非本地上下文窗口中。恢复工作流程如下:
search_notes —— 查找先前的决策、上下文与发现get_task_hierarchy(scope="project", depth=0) —— 识别当前活跃的任务列表get_task(task_list_id="TL_...") —— 在上次中断处接管任务所有权任意智能体——无论来自不同会话、不同设备或不同模型——均可精确恢复至工作中断处。任务列表即计划,备注即记忆,状态即当前进展。
当凭证缺失时:
向用户获取凭证:
PR_00000000...)通过 gateway.config.patch 配置:
{
"skills": {
"entries": {
"taskr": {
"env": {
"MCP_API_URL": "https://taskr.one/api/mcp",
"MCP_PROJECT_ID": "",
"MCP_USER_API_KEY": ""
}
}
}
}
}
验证配置: 调用 tools/list 并确认 create_task 已出现在可用工具列表中。
用户可为不同工作场景创建多个项目。
对于 mcporter 或其他 MCP 客户端:
mcporter config add taskr "$MCP_API_URL" --header "x-project-id=$MCP_PROJECT_ID" --header "x-user-api-key=$MCP_USER_API_KEY"
| 需求 | 对应工具 |
|---|---|
| 创建计划 | create_task(需指定 taskListTitle 与 tasks[]) |
| 为新任务列表添加上下文 | create_note(type=CONTEXT,taskId=TL_) |
| 获取下一个任务 | get_task |
| 标记为完成 | update_task(传入 taskId 与 status="done") |
| 标记为跳过 | update_task(status="skipped") + create_note(type=FINDING) |
| 浏览任务结构 | get_task_hierarchy |
| 执行中动态添加子任务 | create_task(传入 parentId=TS_or_TL_) |
| 记录一项发现 | create_note(type=FINDING,taskId=TS_) |
| 阶段里程碑备注 | create_note(type=PROGRESS,taskId=TS_ 阶段任务) |
| 回溯式历史补全 | task_sync(三步式) |
| 从上一会话恢复工作 | search_notes → get_task_hierarchy → get_task |
| 查找先前上下文 | search_notes 或 list_notes |
ruleContext 取值说明: 传入 Schema 中定义的规则 ID(例如 RU-CTX-001、RU-PROC-001、RU-NOTE-001)。当 Schema 明确要求“请留空此参数”时,传入 ""。