任务
任务保存一项工作的上下文、负责人、状态和执行记录。
任务是 Multica 中安排工作的基本单位:一项功能、一个 bug、一次调研,任何需要成员或智能体负责推进的工作。围绕它的讨论、状态变化和每次执行都留在同一处,无需再从聊天记录或终端日志中拼接上下文。
任务的组成
| 内容 | 用途 |
|---|---|
| 标题和描述 | 目标、背景、要求和验收条件。 |
| 状态和优先级 | 工作处于哪个阶段,先处理什么。 |
| 负责人 | 工作区成员、智能体或小队。 |
| 日期、标签和自定义属性 | 计划、分类和团队自己的字段。 |
| 项目和父子关系 | 归入更大的工作范围,或拆成子任务。 |
| 动态和执行日志 | 评论、状态变化、运行和智能体返回的结果。 |

创建任务
在任务页面或项目中新建,填写标题即可,其余属性随时补充。
每个任务有一个编号,例如 MUL-123。数字在工作区内递增;管理员修改工作区的任务前缀后,编号会用新前缀显示。详见工作区。
选择负责人
| 负责人 | 效果 |
|---|---|
| 成员 | 由这位成员负责跟进,不创建运行。 |
| 智能体 | 为该智能体创建一次运行。 |
| 小队 | 由小队 leader 接收,再决定交给谁处理。 |
分配给智能体或小队时,任务不在 backlog 就会立即入队;运行时离线时,运行留在队列中等待。已归档的智能体和小队不能被分配。
分配不会绕过智能体的访问范围(Access);分配给小队时,校验的是 leader 的 Access。详见分配任务给智能体。
状态
每个工作区都自带 7 个内置状态,归入 4 个生命周期分类:
| 分类 | 内置状态 | 含义 |
|---|---|---|
unstarted | backlog、todo | 还没开始的工作,不论是已规划还是暂时搁置。 |
started | in_progress、in_review、blocked | 已经开始、等待检查,或暂时无法继续。 |
done | done | 顺利完成,终态。 |
closed | cancelled | 不再继续,终态,但不算顺利完成。 |
分类让生命周期判断保持简单。看板、列表、筛选和排序都按具体状态来,具体状态也保留了智能体和自动化依赖的那些更细的行为。
| 状态 | 含义 |
|---|---|
backlog | 暂不启动。已分配给智能体的任务需离开 backlog 后才会创建运行。 |
todo | 已明确,等待开始。 |
in_progress | 正在处理。 |
in_review | 已有结果,等待检查。 |
done | 已完成。 |
blocked | 暂时无法继续。 |
cancelled | 不再继续,保留记录。 |
状态之间没有固定流转,成员和智能体都可以直接修改。
智能体随着工作对任务的实际影响写入状态:开始产出任务本身要求的东西时立刻推到 in_progress——不论形式是代码、调研、设计,还是任务本身要求的 review——让看板在工作进行中就能反映出来;交付后推到 in_review;工作跨轮继续则保持 in_progress;没有产出本任务交付物的轮次(答疑、给别处的工作做咨询)则全程不改状态。这些状态变更由智能体在运行中通过 Multica CLI 显式写入——运行开始或完成时,服务端不会自动改任务状态(下面两个系统例外除外)。done 通常留给人工确认,或在工作区设置合并后改为 done 时,由关联 PR 全部合并后系统写入。
两个变化由系统执行:
- 执行失败,且该任务没有其他执行、也没有触发重试时,
in_progress回到todo。 - 任务的所有关联 PR 都合并时,任务改为工作区选定的状态(默认
done),除非工作区设置为不改变,或该任务设置了合并后不改状态。详见 GitHub 集成。
自定义状态
工作区的 owner 或 admin 可以在设置 → 任务状态里添加自己的状态,比如 Code Review、QA、Rework。每个状态都属于 4 个生命周期分类之一:
| 分类 | 生命周期含义 |
|---|---|
unstarted | 还没开始,包含内置的 backlog 和 todo。 |
started | 进行中,包括等待检查和等待外部回应。 |
done | 顺利完成,终态。 |
closed | 取消或不再继续,终态,但不算顺利完成。 |
自定义状态只继承生命周期语义,不继承内置状态的具体行为。backlog 的停车、in_review 结束自动化运行、blocked 的失败处理、in_progress 的失败回收,这些都不会被继承——需要哪个行为,就用对应的那个内置状态。以前建的自定义状态也按同一套规则:Awaiting Response 算进行中的工作,不会自动结束检查。分配和创建仍然走通用的智能体触发规则。
平台自己写入状态时——失败回滚到 todo、PR 合并置 done——写的都是内置状态,不会写成某个自定义状态。
对已安装的客户端,API 里原有的分类字段仍然返回 7 值的传输枚举。新客户端会把它归一成 4 个分类;传输值本身从不授予任何行为继承。数据库里只存这 4 个生命周期值。
由此有四点:
- 状态一旦创建,分类就不能再改。 改分类等于悄悄重写所有已经在该状态上的任务的行为,所以编辑时分类是只读的。先想清楚要什么行为,再取名字。
- 按状态分组用的是具体状态。 看板的列、列表的分节、泳道的状态列,都会把内置状态和自定义状态分开。
Code Review和QA各占一列,即使两者都属于started。分类是内部的生命周期划分,不是用来替代列名的。 - 内置状态是锁死的。 名称、颜色、分类都不能改,也不能归档——从不打开这个页面的工作区,看板和原来一模一样。
- 归档是停用,不是删除。 已经在该状态上的任务保持不变,名称、颜色和行为都不变,只是之后再设置状态时不再出现这个选项。
内置状态会按界面语言翻译,自定义状态则始终显示你填的名字。API 和 CLI 通过 key 引用它:multica issue status MUL-42 code_review。设置页里的 key 由名字生成;API 可以显式指定,省略时才自动生成。无论哪种方式,key 在创建时就定下来了——之后改名字不会改 key。
任务与运行
任务是持续存在的工作记录;运行是智能体的一次具体执行。一个任务可以先后产生多次运行——第一次实现、补充修改、再次检查。运行“已完成”只表示这一次执行结束;任务是否完成,以任务的状态为准。
项目和子任务
一个任务最多属于一个项目,项目为其中的执行提供共享说明和资源;移到另一个项目不会产生副本。
较大的工作可以拆成子任务:父任务保留整体目标,子任务各自独立推进。父子状态互不联动。
子任务可以设置阶段(stage),按 1、2、3 分批推进。当前最早未完成阶段的全部子任务到达 done 或 cancelled 时,父任务会收到"子任务完成"通知;父任务的负责人是智能体时,它会被唤醒并决定是否推进下一阶段。未设置阶段的子任务视为同一批,全部结束时通知一次。
切换视图
任务页面提供列表、看板、表格、甘特图和泳道五种视图,可按状态、负责人、项目和其他属性筛选、排序,展示的都是同一批任务。
删除任务
任何工作区成员都可以删除任务。
删除不可恢复:任务及其评论、附件和关联记录会被永久移除,尚未结束的运行会被取消。不再继续时把状态改为 cancelled,讨论和结果仍可查阅。