必须查看原始运行日志才能确认真实原因：控制台可查72小时内结构化日志，含step_id、tool_name及error_code；宿主机需用systemctl或docker logs查进程级日志；前端问题则通过开发者工具network面板定位失败请求。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在MiniMax Agent平台中部署了一个含多步骤、工具调用或人工审批环节的工作流，却在某一步骤卡住、返回空结果或报错时，仅靠界面提示无法定位是系统超时、工具执行失败，还是上下文被截断——必须查看原始运行日志才能确认真实原因。
通过控制台Agent管理页直接查看运行日志
该方式适用于已发布且正在运行中的Agent实例，无需额外权限，但仅显示最近72小时内触发的运行记录，且每条记录只保留最简摘要。
1、登录 console.minimax.tech，进入「Agent」模块 → 找到目标Agent名称，点击右侧「运行记录」按钮。
2、在运行记录列表中，找到状态为「失败」「中断」或耗时异常长（>90s）的条目，点击其右侧「查看日志」图标。
3、弹出抽屉中将展示结构化日志片段：包含step_id、tool_name、execution_status及error_code（如有）。若某step显示execution_status: "timeout"，说明该工具调用未在默认60秒内返回响应。
4、点击「展开原始日志」可查看完整JSON格式输出，注意检查input_context_truncated字段是否为true——若为true，表示输入上下文被自动截断，需在Agent配置中调高max_context_length值。
从主机层面获取Agent进程级运行日志
当控制台日志缺失关键细节（如内存溢出、Python进程崩溃、工具命令stderr未被捕获），需登录部署Agent的宿主服务器，直接读取本地日志文件。
方法一：使用systemctl查看服务日志
1、SSH登录Agent所在Linux主机，执行：【sudo systemctl status minimax-agent】，确认服务处于active (running)状态。
2、若状态异常，立即执行：【sudo journalctl -u minimax-agent -n 200 -f】，实时跟踪最新200行日志并持续输出。重点查找包含Segmentation fault、Killed process或OOM killed的行——这表明Agent进程因内存不足被系统强制终止。
3、若需导出历史日志，运行：【sudo journalctl -u minimax-agent --since="2026-08-09 14:00:00" --until="2026-08-09 15:30:00" > agent_oom_debug.log】，将指定时段日志保存为文件。
方法二：直接读取日志文件（适用于Docker部署）
1、执行：【docker ps | grep minimax】，获取Agent容器ID。
2、运行：【docker logs --tail 500 --timestamps 】，查看最近500行带时间戳的日志。
3、若容器日志量过大导致滚动丢失，需进入容器内部：【docker exec -it /bin/sh】 → 进入/var/log/minimax/目录，用cat或tail -n 100 agent-runtime.log查看原始日志文件。
通过浏览器开发者工具捕获前端工作流执行痕迹
此方法专用于排查Web UI端发起的工作流在提交后无响应、按钮禁用或状态不更新等前端交互问题，不涉及后端逻辑。
第一步：复现问题并打开调试面板
1、在MiniMax Agent Web UI中，重新触发一次卡住的工作流（例如点击「执行流程」按钮）。
2、立即按F12打开开发者工具，切换至「Network」标签页，勾选「XHR」与「Fetch」过滤器。
第二步：定位失败请求
3、在Network列表中，找到以/v1/workflow/run或/api/agent/execute开头的请求，点击它。
4、在右侧「Response」面板中查看返回内容：若返回{"code":400,"message":"invalid step configuration"}，说明工作流定义JSON中某个step缺少必需字段；若返回空响应或net::ERR_CONNECTION_RESET，则是网关层中断，需检查API密钥有效性或网络代理设置。
5、切换到「Headers」面板，检查Request Headers中是否存在Authorization: Bearer xxx——若缺失，说明前端未正确注入Token，需清除浏览器缓存并重新登录。
