任务

任务在 Rudder 里对应 issue。它把意图、归属、状态、上下文、执行记录、评论、阻塞、评审和输出放在同一个对象上。

​

为什么任务重要

长时间运行的 agent 工作需要一个固定位置。否则，决策、上下文、产物和评审证据会散在聊天 transcript 和终端输出里。 任务就是这个位置。

​

常见使用场景

需要下面这些能力时，就用任务：

• 给一个具体结果指定唯一 owner
• 让 agent checkout 工作，避免重复执行
• 把评论、计划、截图、PR 和验证结果放在一起
• 把输出交给 reviewer
• 从失败或阻塞的 run 中恢复上下文

​

状态模型

常见任务状态包括：

• backlog：已捕获，但范围、优先级、负责人或验收标准仍需讨论
• todo：已经准备好由 assignee 接手
• in_progress：已被 assignee checkout
• blocked：正在等待人、reviewer、依赖或外部条件
• in_review：实现已经足够完整，可以交给 reviewer 判断
• done：已接受并关闭

​

Backlog 与 TODO

todo 用于已经足够明确、可以执行的工作。一个 todo 任务应该说明期望结果，包含 assignee 需要的上下文，并且下一步不需要再讨论产品判断。 backlog 用于仍在塑形的工作。Backlog 任务可以记录真实问题或机会，但要先停在那里，直到团队讲清楚范围、负责人、优先级、验收标准，或者这件事到底要不要做。

​

Checkout 语义

Agent 开始实现前应先 checkout 任务。Checkout 会明确当前执行负责人，也能避免同一个任务被重复推进。

​

关闭信号

每次活跃工作运行结束时都应该留下一个清晰信号：

• 工作仍未完成时，留下进展评论
• 下一步属于其他人时，留下阻塞评论
• 任务完成时，留下完成评论
• 作为 reviewer 时，留下结构化评审决定

​

Follow-up 和 reviewer

Follow-up 的作用是防止工作在运行、评审、阻塞或用户评论之后卡住。下面这些情况需要 follow-up：任务缺少清晰关闭信号、reviewer 要求修改、阻塞需要指定下一负责人，或新信息改变了预期结果。 当前 assignee 负责实现、证据和修改。Reviewer 在任务进入 review 或需要独立质量判断时负责下一步。涉及产品、法律、预算、权限或客户上下文的决定，仍由对应的人类负责人处理。 Reviewer 结论应结构化：通过、要求修改、需要跟进或阻塞。这样“应该差不多了”才会变成可追踪的关闭路径。看板能看到谁负责下一步，也能看到哪些证据被接受或拒绝。

​

输出

好的关闭评论会包含证据：变更文件、验证命令、预览链接、截图、提交、部署状态和剩余风险。 如果读者不能从任务里检查结果，这条关闭评论就不够。标记完成前，补上产物、链接、截图或剩余风险。

​

下一步