一旦遇到 MiniMax Agent 任务执行失败，不要再依赖手动盲查或反复碰运气，更高效的方式是立即切换到结构化的 Bug 排查指令：①将完整错误堆栈原样粘贴给 Agent，让它优先判断根因；②明确指定日志路径读取本地日志，并完成分类分析与调用链还原；③启用 systematic-debugging 技能，按照四步流程系统推进排障；④结合 trace_id 反向恢复执行路径，尽快锁定最早出现的报错节点。

当你在 MiniMax Agent 运行过程中遇到“任务失败”，却无法判断究竟是哪一步出错，日志中又混杂着 LLM 响应、工具调用结果和错误堆栈，单靠肉眼翻看数百行内容几乎无法快速定位根因。这种情况下，应该使用结构化、可直接触发的 Bug 排查指令，替代低效的手动盲搜。

直接把报错信息交给Agent分析

这是最快速、最容易上手的排查方式，适用于终端或日志中已经明确捕获完整错误堆栈的场景。

第一步：复制完整错误输出，包括 panic 信息、goroutine 栈、文件路径以及行号；

第二步：在 MiniMax Agent 对话框中输入：“我运行测试时出现了这个错误，帮我分析根因”，然后粘贴全部报错内容；

这一步操作非常直接，把错误文本完整贴进去即可。Agent 通常能够自动识别 nil pointer、timeout、JSON decode failure 等常见异常模式，并进一步指出问题可能出在哪个对象未初始化、哪一行代码发生越界，或哪个工具返回了不符合预期的数据结构。

让Agent读取本地日志文件

这种方式适用于线上环境日志已经落盘、但不方便实时复制粘贴的场景，例如 /var/log/app/error.log 或 ~/.minimax/agent/logs/ 目录下的滚动日志。

方法一：指定路径 + 明确分析目标

输入：“帮我查看 /var/log/app/error.log 最近的错误，按类型分类，找出出现频率最高的前 5 个，并分析可能原因”；

方法二：限定时间范围 + 聚焦异常调用链

输入：“读取 ~/.minimax/agent/logs/agent-20260811*.log 中从 14:00 到 15:30 的日志，提取所有包含 ‘failed’ 或 ‘panic’ 的行，并按调用链还原为执行步骤序列”；

【注意：日志路径必须位于 Agent 有权限读取的目录，不能填写 ~/Downloads 或 /root 下的路径】

启用systematic-debugging技能

这是最接近专业 SRE 故障排查流程的指令写法，能够避免凭经验乱试、反复试错带来的时间浪费。

① 先激活技能：输入“激活 systematic-debugging skill”；

② 再补充上下文：提供任务 ID、失败时间戳，以及涉及的工具列表（如 search_knowledge_base、send_email、parse_pdf）；

③ 最后下达指令：“对 task_id=ag-8d2f9c 的失败执行完整排障流程”；

Agent 收到后通常会严格按照四个步骤推进：先收集日志片段与配置快照 → 生成 3 个最可能的根因假设 → 逐一验证（例如重放某次 tool call 的输入，或检查对应缓存 key 是否存在）→ 在确认原因后给出修复代码补丁与回归测试建议。这一步不要求你必须理解 Redis pipeline 或 Go context 超时机制，Agent 会自行辅助分析。

用trace ID反向定位执行路径

如果你已经在代码中接入了 trace 层（例如每一步生成唯一 span_id 并写入日志），就可以借助 ID 驱动 Agent 进行更精准的执行链路回溯。

输入：“根据 trace_id=tr-7a1b3e9f 查找所有关联日志行，按时间顺序还原执行路径，标出第一个返回非 200 或抛出异常的工具调用”；

与手动翻查原始日志相比，这种排查方式的效率通常可以提升一个数量级。Agent 会先自动过滤无关日志，只保留带有该 trace_id 的记录，再将 Calling tool、Tool result、LLM response、Error stack 这四类关键事件，按照毫秒级时间戳依次串联，形成清晰完整的因果链。这样一来，问题往往可以快速定位：例如第 7 步调用 search_knowledge_base 时返回空数组，紧接着第 8 步的 LLM 就生成了无效 SQL。