Multica issue 一直停留在 queued 状态怎么排查【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica当你把一个 issue 指派给 agent或在评论里 了 agent之后发现它在 Multica 的执行日志里始终停在queued状态、迟迟不进入dispatched或running就可以按这篇文章的路径排查。queued的含义是run 已经创建正在等待某个 runtime执行机上的守护进程 AI 编码工具来认领它。只要认领不上issue 就不会开始执行。适用前提是Multica CLI 已安装并登录目标机器上有 daemon 在跑或本来应该跑。排查的核心思路是把问题定位到正确的层Multica 服务、daemon、runtime、AI 编码工具。文档给出的第一组命令是multica version multica auth status multica daemon status --output json multica daemon logs --lines 100自托管实例还可以直接从执行机上请求服务健康检查/health只说明 API 进程在响应/readyz还会检查数据库和迁移。从 issue 的执行日志确认 run 状态打开目标 issue 右侧边栏的Execution log执行日志区域找到那条一直停在queued的 run。每一行会显示触发来源、执行 agent、状态和时间。如果看不到该区域点 issue 标题栏的面板按钮展开边栏窄屏下它默认是收起的。也可以用 CLI 直接查看某个 issue 的 run 列表issue-id用类似MUL-123的 issue key 或完整 UUIDmultica issue runs issue-id确认它确实是queued而不是waiting_local_directory等待另一个 run 释放同一本地目录的锁——后者的处理方式完全不同本文只处理queued。按顺序检查四个卡点文档对queued给出的排查顺序是固定的按序检查agent 绑定的 runtime 是否在线该 runtime 是否检测到了 agent 所配置的那个 AI 编码工具agent 是否还有并发余量daemon 是否还有全局执行容量下面逐项给出检查命令。1. runtime 是否在线在执行机上运行multica daemon status --output json同时在 Multica 网页的Runtimes页面确认目标计算机和对应的 AI 编码工具显示为 online。如果 daemon 本身没有起来先启动它multica daemon startdaemon 每 15 秒发送一次心跳daemon 意外退出后runtime 最多大约 3 分钟后会显示为 offline。offline 期间已入队的 run 会一直等待它恢复——这正是queued长期不动的常见原因之一。如果 daemon 起不来常见原因包括CLI 未登录或本机 token 过期、daemon 连错了 Multica 服务、执行机访问不到 APIDNS/TLS/防火墙、当前账号已不是目标 workspace 的成员或本机没有安装任何受支持的 AI 编码工具daemon 至少要检测到 1 个内置支持的工具才会启动。重新登录并重启 daemonmultica login multica daemon restart2. 工具是否被 daemon 检测到runtime 列表里缺少预期的工具时先确认该工具能在同一系统账号、同一PATH下直接运行且已完成登录再重启 daemonmultica daemon restart验证工具可发现性command换成实际命令如claude、codex、cursor-agentcommand -v command command --version如果终端里能找到、但 Desktop 或后台 daemon 找不到通常是两者使用的PATH不同重启应用或通过对应的MULTICA_PROVIDER_PATH环境变量设置绝对路径完整配置见 环境变量文档。注意最低版本要求低于最低版本时 daemon 不会注册对应 runtime。文档列出的部分最低版本为Claude Code 2.0.0、Codex 0.100.0、Copilot 1.0.0、Grok 0.2.89、Qwen Code 0.20.0、MiniMax Code 0.1.2。工具清单与各自的可执行命令名见 安装 AI 编码工具。daemon 日志里如有版本、路径或认证错误用下面命令跟踪multica daemon logs --follow3. 与 4. 并发余量是否耗尽默认限制是单个 agent 最多 6 个 run 并发单个 daemon 最多 20 个 run 并发实际生效值取两者中较小的。达到上限后新 run 会一直留在队列里直到有正在执行的 run 结束。agent 级并发在 agent 设置中调整或用multica agent get agent-id查看该 agent 的当前配置确认。daemon 级上限环境变量MULTICA_DAEMON_MAX_CONCURRENT_TASKS默认20或启动参数--max-concurrent-tasks也可以持久化为max_concurrent_tasksmultica config set max_concurrent_tasks n。如果确认是并发打满处理办法是等活跃 run 结束或调高上限。调高前要明白文档的提示并行的 run 会同时竞争机器资源、工具账号配额和同一工作目录。理解排队规则queued 什么时候才会失败这决定你要等多久、什么时候该动手runtime 只要还在心跳哪怕只是忙它排队的 backlog 就不会因等待过久而失败会一直等它慢慢消化。queued的 run 只有在同时满足两个条件时才失败失败原因记为queued_expiredruntime 停止心跳超过重连宽限期reconnect grace且该 run 本身入队时间也超过了这个宽限期。宽限期由服务端的MULTICA_RUNTIME_RECONNECT_GRACE控制默认3h低于150s的值会被截断。把任务指派给一台已经下线的机器时run 仍会获得一个完整的宽限期等你把它救回来而不是立即失败。queued状态的 run 不属于自动重试范围。所以排了很久的队本身不报错、不自动消失需要人工按上面四个卡点定位原因。验证与恢复逐项修复后用以下方式确认问题真的解决了Runtimes 页面目标计算机与对应工具显示 online且该 runtime 在 agent 可选范围内。执行日志 /multica issue runs issue-id那条 run 离开queued进入dispatched已被认领、正在启动工具此状态超过 5 分钟会被判失败再进入running。如果之前已经以queued_expired失败确认 runtime 在线后从执行日志里对该 run 点重试CLI 侧也可以重新入队multica issue rerun issue-idrerun针对 issue 当前的 agent 指派人并使用全新的会话和工作目录而执行日志里对某一条历史 run 的重试用的是当时处理那条 run 的 agent即使 issue 后来改派了也不会切换。参考Troubleshooting分层排查的完整入口含 daemon 连接失败、日志位置等章节。Runsrun 的全部状态、超时后果与失败原因对照表。Daemon and runtimesruntime 如何注册与报告在线状态、offline runtime 的排查顺序。CLIdaemon、runtime、issue runs、rerun等命令的完整参数。【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Multica issue 一直停留在 queued 状态怎么排查
Multica issue 一直停留在 queued 状态怎么排查【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica当你把一个 issue 指派给 agent或在评论里 了 agent之后发现它在 Multica 的执行日志里始终停在queued状态、迟迟不进入dispatched或running就可以按这篇文章的路径排查。queued的含义是run 已经创建正在等待某个 runtime执行机上的守护进程 AI 编码工具来认领它。只要认领不上issue 就不会开始执行。适用前提是Multica CLI 已安装并登录目标机器上有 daemon 在跑或本来应该跑。排查的核心思路是把问题定位到正确的层Multica 服务、daemon、runtime、AI 编码工具。文档给出的第一组命令是multica version multica auth status multica daemon status --output json multica daemon logs --lines 100自托管实例还可以直接从执行机上请求服务健康检查/health只说明 API 进程在响应/readyz还会检查数据库和迁移。从 issue 的执行日志确认 run 状态打开目标 issue 右侧边栏的Execution log执行日志区域找到那条一直停在queued的 run。每一行会显示触发来源、执行 agent、状态和时间。如果看不到该区域点 issue 标题栏的面板按钮展开边栏窄屏下它默认是收起的。也可以用 CLI 直接查看某个 issue 的 run 列表issue-id用类似MUL-123的 issue key 或完整 UUIDmultica issue runs issue-id确认它确实是queued而不是waiting_local_directory等待另一个 run 释放同一本地目录的锁——后者的处理方式完全不同本文只处理queued。按顺序检查四个卡点文档对queued给出的排查顺序是固定的按序检查agent 绑定的 runtime 是否在线该 runtime 是否检测到了 agent 所配置的那个 AI 编码工具agent 是否还有并发余量daemon 是否还有全局执行容量下面逐项给出检查命令。1. runtime 是否在线在执行机上运行multica daemon status --output json同时在 Multica 网页的Runtimes页面确认目标计算机和对应的 AI 编码工具显示为 online。如果 daemon 本身没有起来先启动它multica daemon startdaemon 每 15 秒发送一次心跳daemon 意外退出后runtime 最多大约 3 分钟后会显示为 offline。offline 期间已入队的 run 会一直等待它恢复——这正是queued长期不动的常见原因之一。如果 daemon 起不来常见原因包括CLI 未登录或本机 token 过期、daemon 连错了 Multica 服务、执行机访问不到 APIDNS/TLS/防火墙、当前账号已不是目标 workspace 的成员或本机没有安装任何受支持的 AI 编码工具daemon 至少要检测到 1 个内置支持的工具才会启动。重新登录并重启 daemonmultica login multica daemon restart2. 工具是否被 daemon 检测到runtime 列表里缺少预期的工具时先确认该工具能在同一系统账号、同一PATH下直接运行且已完成登录再重启 daemonmultica daemon restart验证工具可发现性command换成实际命令如claude、codex、cursor-agentcommand -v command command --version如果终端里能找到、但 Desktop 或后台 daemon 找不到通常是两者使用的PATH不同重启应用或通过对应的MULTICA_PROVIDER_PATH环境变量设置绝对路径完整配置见 环境变量文档。注意最低版本要求低于最低版本时 daemon 不会注册对应 runtime。文档列出的部分最低版本为Claude Code 2.0.0、Codex 0.100.0、Copilot 1.0.0、Grok 0.2.89、Qwen Code 0.20.0、MiniMax Code 0.1.2。工具清单与各自的可执行命令名见 安装 AI 编码工具。daemon 日志里如有版本、路径或认证错误用下面命令跟踪multica daemon logs --follow3. 与 4. 并发余量是否耗尽默认限制是单个 agent 最多 6 个 run 并发单个 daemon 最多 20 个 run 并发实际生效值取两者中较小的。达到上限后新 run 会一直留在队列里直到有正在执行的 run 结束。agent 级并发在 agent 设置中调整或用multica agent get agent-id查看该 agent 的当前配置确认。daemon 级上限环境变量MULTICA_DAEMON_MAX_CONCURRENT_TASKS默认20或启动参数--max-concurrent-tasks也可以持久化为max_concurrent_tasksmultica config set max_concurrent_tasks n。如果确认是并发打满处理办法是等活跃 run 结束或调高上限。调高前要明白文档的提示并行的 run 会同时竞争机器资源、工具账号配额和同一工作目录。理解排队规则queued 什么时候才会失败这决定你要等多久、什么时候该动手runtime 只要还在心跳哪怕只是忙它排队的 backlog 就不会因等待过久而失败会一直等它慢慢消化。queued的 run 只有在同时满足两个条件时才失败失败原因记为queued_expiredruntime 停止心跳超过重连宽限期reconnect grace且该 run 本身入队时间也超过了这个宽限期。宽限期由服务端的MULTICA_RUNTIME_RECONNECT_GRACE控制默认3h低于150s的值会被截断。把任务指派给一台已经下线的机器时run 仍会获得一个完整的宽限期等你把它救回来而不是立即失败。queued状态的 run 不属于自动重试范围。所以排了很久的队本身不报错、不自动消失需要人工按上面四个卡点定位原因。验证与恢复逐项修复后用以下方式确认问题真的解决了Runtimes 页面目标计算机与对应工具显示 online且该 runtime 在 agent 可选范围内。执行日志 /multica issue runs issue-id那条 run 离开queued进入dispatched已被认领、正在启动工具此状态超过 5 分钟会被判失败再进入running。如果之前已经以queued_expired失败确认 runtime 在线后从执行日志里对该 run 点重试CLI 侧也可以重新入队multica issue rerun issue-idrerun针对 issue 当前的 agent 指派人并使用全新的会话和工作目录而执行日志里对某一条历史 run 的重试用的是当时处理那条 run 的 agent即使 issue 后来改派了也不会切换。参考Troubleshooting分层排查的完整入口含 daemon 连接失败、日志位置等章节。Runsrun 的全部状态、超时后果与失败原因对照表。Daemon and runtimesruntime 如何注册与报告在线状态、offline runtime 的排查顺序。CLIdaemon、runtime、issue runs、rerun等命令的完整参数。【免费下载链接】multicaMake humans and AI agents work as one team — open-source and self-hostable.项目地址: https://gitcode.com/GitHub_Trending/mu/multica创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考