MiniMax Agent多步骤任务中断或报错，本质是底层调度系统触发阻塞或失败判定，而非模型主动停止；需通过状态标签、日志定位错误码、检查工具权限、调用minimax-cli diagnose诊断，并可跳过或编辑参数断点续跑。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
MiniMax Agent执行多步骤任务时卡在中间、报错退出或反复确认，不是模型“不想干”，而是底层调度系统在某个环节触发了阻塞或失败判定。
先看任务状态栏有没有红色标记
打开 MiniMax Desktop App，在右侧任务栏找到当前运行的任务，观察其状态标签。如果显示【Failed】或【Blocked】，说明任务已被调度器主动中止，不是模型“思考中断”，而是工具调用返回了不可忽略的错误码。
点击该任务右侧的“详情”箭头，展开日志面板。重点查找带「ERROR」前缀的行，尤其是紧挨着失败步骤前后的两行——那里通常藏着真实原因，比如「Tool web_search returned status 403」或「File write permission denied on /Users/xxx/Sorted/PDF」。
检查工具权限是否被手动关闭
方法一：网页端快速验证
访问 https://agent.minimaxi.com → 右上角齿轮图标 → “Agent设置” → “工具权限”。确认“联网搜索”“文件读写”“代码执行”三项开关均为开启状态。MiniMax 不会默认启用所有工具，尤其新注册账号首次运行多步骤任务时，这些权限常处于关闭状态。
方法二：桌面端深度核对
在桌面客户端左下角点击“Settings” → 切换到“Advanced Tools”页签 → 检查“Enable sandboxed execution”是否勾选。未启用沙箱时，某些写操作（如 mv、mkdir）会被拦截并静默失败，日志里只显示「Step 3: pending…」却不再推进。
定位具体哪一步出问题
第一步：复制任务 ID
在任务详情页顶部，找到形如「TASK-7a2f9e1d」的唯一标识符，全选复制。
第二步：调用诊断命令
打开终端，执行：minimax-cli diagnose --task-id TASK-7a2f9e1d --verbose。该命令会拉取 Redis 中该任务的完整执行快照，包括每步输入、工具返回原始响应体、调度器决策日志。
第三步：聚焦「checkpoint」字段
输出中搜索关键词「checkpoint」，找到最近一次成功保存的状态点。若 checkpoint 停在 step_2，而日志显示 step_3 调用了 web_search 但返回空结果，则问题不在模型，而在 M2.5-Search 插件未正确加载或网络策略拦截了请求。
【注意】该诊断命令仅对已启用 CLI 的用户生效。未安装 CLI 的，需先运行 curl -sSL https://cli.minimaxi.com/install.sh | sh 完成本地部署，否则无法获取底层调度日志。
临时绕过失败步骤重试
方法一：跳过式重跑
在任务详情页点击“重试”，弹窗中勾选“Skip failed step and continue from next”。适用于明确知道某步工具不可用（如目标网站已关停），且后续步骤不依赖其输出的场景。
方法二：编辑参数后断点续跑
点击“编辑输入”，将原指令中导致失败的部分删减或替换。例如原指令含「抓取知乎API返回数据」，可改为「抓取知乎公开页面HTML源码」。修改后点击“从当前步重试”，调度器会复用之前已完成的 checkpoint，直接启动 step_4。
这一步操作起来很简单，直接把文件拖进去就行。但必须确保修改后的指令语义与原计划兼容，否则 verifier agent 会在验收阶段拒绝通过。
