执行任务
智能体每一次工作的单位，有明确的状态机、超时和重试规则。
执行任务（task）是 智能体 每一次工作的单位——把一个 issue 分给智能体、在评论里 @提及智能体、在 聊天 里发一条消息、或者 Autopilot 到点触发，都会产生一个执行任务。Multica 把它放进队列，由 守护进程 领走后交给对应的 AI 编程工具 执行，结束时把结果写回服务器。
执行任务和 issue 是两层不同对象：一个 issue 可以反复分配、反复 @提及、手动重跑——每次都产生一个新的执行任务。
一个任务会经过哪些状态
- 排队中（queued）——任务刚创建，等待某个守护进程来领
- 已派发（dispatched）——守护进程领走了，正在启动对应的 AI 编程工具
- 运行中（running）——AI 编程工具在真正干活
- 完成（completed）——成功结束，产出（评论、代码提交、状态变化等）写回服务器
- 失败（failed）——出错或超时终止；如果失败原因可重试，会自动回到
queued再来一次 - 取消（cancelled）——用户主动取消
任务超时会怎样
Multica 服务器每 30 秒扫描一次，有两种超时会触发失败：
| 什么情况 | 超时阈值 |
|---|---|
| 派发后迟迟不开始（守护进程领走但没启动 AI 工具） | 5 分钟 |
| 正在运行但跑得太久 | 2.5 小时 |
两种超时的失败原因都是 timeout，会自动重试（下一节）。关联的运行时失联判定见 守护进程与运行时 → 运行时什么时候被判定为离线。
上面这层是服务端的粗粒度兜底——按任务启动时间算，不看任务是否还在活动。真正区分「卡死」和「正常的长任务」的是本地守护进程：它不再用固定墙钟时长砍任务（MULTICA_AGENT_TIMEOUT 默认 0 = 不设上限），而是看活动——只要 agent 还在持续产出事件（消息、工具调用），守护进程就不会因为跑得久判它超时（服务端那条 2.5h 仍是外层上限）。只有真正静默卡死时才会被空闲看门狗（MULTICA_AGENT_IDLE_WATCHDOG，默认 30 分钟）终止；如果是某个工具调用发出后长时间无任何输出（疑似卡死的子进程），则由更大的工具看门狗预算（MULTICA_AGENT_TOOL_WATCHDOG，默认 2 小时）兜底。这类被看门狗终止的任务失败原因是 idle_watchdog，和墙钟 timeout 区分开。各参数见 环境变量 → 守护进程的调节参数。
哪些失败会自动重试，哪些不会
失败分两类：可重试和不可重试。
可重试（Multica 自动重排队）：
runtime_offline——任务派发后，守护进程失联了runtime_recovery——守护进程崩溃重启，回收上次没跑完的任务timeout——运行超时或派发超时
不可重试（任务停在失败状态）：
agent_error——AI 编程工具自己报错（API 错误、超额度、内部 bug）。底层问题不重试，避免无限循环。
自动重试有两个额外条件：
- 最多 2 次——1 次原任务 + 1 次重试。重试也失败就不再重试，即使原因可重试。
- 只对 issue 和聊天触发的任务生效——Autopilots 触发的任务不自动重试。
Autopilots 任务不自动重试是刻意设计。Autopilot 有自己的触发周期（例如每天一次）；如果失败又自动重试，会和下一个周期的任务重叠。需要失败后立即重跑，用手动重跑（下一节）。
怎么知道 Autopilot 失败了：失败的 Autopilot 任务会在你的 收件箱 里出现一条通知，关联的 issue 状态也会从 in_progress 退回 todo。直接打开 Autopilots 页面也能看到每条 autopilot 的最近运行结果。
手动重跑和自动重试的区别
手动重跑（rerun）是你通过命令行或 API（POST /api/issues/{id}/rerun）主动发起的：
multica issue rerun <issue-id>行为：
- 默认跑的是 issue 当前的智能体分配人——适用于希望 rerun 跟随当前分配人的场景。
- 执行日志里某一行的 retry 按钮会把这一行的 task ID 一并发出，rerun 会针对那一行原本的 agent，而不是当前分配人。这让 squad worker、并行的 @-mention agent、或者已经被新分配人替代的旧任务行的 retry 按钮都能符合直觉地工作。
- 取消目标 agent 在这条 issue 上 queued / running 的任务（如果有）。同 issue 上其它 agent 的任务（例如 @-mention 触发的并行任务）不会被一起取消。
- 创建一个全新的执行任务——尝试次数重置为 1，即使原任务已达最大尝试。
- 启动全新的智能体会话——不继承之前的会话 ID。手动重跑意味着你已经判定上一次的产出不行，再继续之前的对话只会重放被污染的上下文。（自动重试则相反，会继承会话——那条路径处理的是基础设施层面的失败，不是产出不好。）
对比：
| 维度 | 自动重试 | 手动重跑 |
|---|---|---|
| 触发 | 系统基于失败原因自动执行 | 你主动发起 |
| 上限 | 2 次 | 无上限 |
| 适用来源 | issue、聊天 | 有智能体分配人的 issue |
| 跑哪个 agent | 失败任务原本的 agent | UI 单行 retry：那一行任务的 agent；CLI / 不带 task_id：issue 当前的分配人 |
| 会话继承 | 是（接着上次会话） | 否（全新会话） |
失败的任务对 issue 状态有什么影响
如果一个 issue 因为分配给智能体而触发的任务失败了（且没有自动重试成功），issue 的状态会自动从 in_progress 退回 todo——这样你打开看板时能立刻看到「这条需要再看看」。详见 Issue 与 project。
任务能接着上次的上下文继续吗
可以——前提是对应的 AI 编程工具支持会话恢复。
Multica 在任务过程中两次保存会话 ID——任务一开始（AI 工具返回第一条系统消息时）pin 一次，任务结束（完成或失败）时再 pin 一次。前者让守护进程中途崩溃时也能恢复，后者留给下一次自动重试——届时把这个 ID 传回去，智能体就能接着上次的对话和文件状态继续。手动重跑会主动跳过这一步，永远从全新会话开始——见 手动重跑和自动重试的区别。
但哪些 AI 编程工具真的支持差别很大：
- ✅ 真支持——Antigravity、Claude Code、Copilot、Hermes、Kimi、Kiro CLI、OpenCode、OpenClaw、Pi
- ⚠️ 代码看起来支持但实际不可用——Codex、Cursor
- ❌ 不支持——Gemini
下一步
- Providers Matrix —— 12 款 AI 编程工具的能力差异对照（包括会话恢复的精确状态）
- 分配 issue 给智能体 / 在评论里 @智能体 / 聊天 / Autopilots —— 触发执行任务的四种方式