确认服务实例是否真正就绪

第一步，先看看调度中心UI，检查任务绑定的执行器地址列表。如果为空，那说明Manus压根没发现任何可用的工作节点。 第二步，去核实目标服务有没有成功注册到Nacos或Eureka这类服务发现组件里。打开浏览器，直接请求服务的健康检查接口（比如 `http://localhost:8080/health`），返回的必须是 `{"status":"UP"}`。要是返回404或503，那基本就是服务进程没启动，或者端口被占用了。 第三步，还得确认这个服务实例有没有被授予执行任务的权限。进入Manus后台的权限管理，搜一下服务名，看看「TaskExecutor」角色有没有勾选。没勾选的话，调度器会直接跳过这个节点，即使服务活着也当作没看见。

核对时区与Cron表达式一致性

方法一：打开任务配置页，找到「调度设置」区域，检查Cron表达式是不是标准格式，比如 `0 0 * * 1` 表示每周一凌晨执行。一个常见的错误是误用 `* * * * *`（每秒触发），这会把服务队列瞬间压垮。 方法二：比对一下系统时区和Manus配置的时区。Linux下用 `timedatectl status`，Windows则在控制面板里查看。如果服务器是UTC+8，而Manus配置的是UTC，那每天实际执行时间就会偏移8小时，导致任务看起来像是“从未运行”。 **关键前提**：所有时间相关的配置，必须基于同一个时区基准，否则Cron表达式永远无法匹配到真实的系统时间。

强制注入登录态凭证

Manus的虚拟机环境搞不定图形验证码或信息二次验证，所以调用知乎、小红书这类平台的API时很容易中断。 方法一：发起任务前，先用Chrome手动登录目标平台（比如知乎），确保Cookie已经写好。然后启动Manus任务时，勾选「复用当前浏览器会话」选项。 方法二：如果需要批量操作，可以导出浏览器Cookie为JSON文件，然后在Manus任务设置里上传这个文件，系统会自动注入到虚拟浏览器上下文里。 方法三：对于必须扫码登录的平台（比如微信公众号后台），可以用Playwright录制登录流程，导出为可复用脚本，然后在Manus工具调用链里插入这个脚本的路径。注意，脚本必须放在 `~/manus/tools/` 目录下，路径不对的话调用会直接跳过。

定位原始执行日志文件

第一步：找到任务的关键词（比如 `seo-report`、`japan-trip`），然后进入对应的文件夹 `~/manus/tasks/[任务关键词]/execution_log.md`。Windows用户记得把 `~` 替换成 `C:UsersYourName`。 第二步：用文本编辑器打开 `execution_log.md`，按 `Ctrl+F` 搜索「ERROR」可以定位失败节点；搜索「[x]」可以统计已完成的步骤数；搜索「final_output」可以确认最终成果是否生成。 第三步：如果日志文件不存在或为空，立刻检查同级目录下的 `debug_trace.log`。这个文件记录的是Agent内部状态流转的细节，比如 `search_agent` 第3次抓取因反爬而返回403，而 `execution_log.md` 只会简单记成「→ ToolCall: search_agent → FAILED」。 **不可逆操作**：手动删除或移动 `~/manus/tasks/` 下的任意文件夹，会导致日志永久丢失，无法恢复。