--- name: mda-issue-log-analysis description: 分析 MDA 公开 Issue、日志包或本地日志。用于 `https://github.com/1204244136/MDA/issues/...`、`#1234`、MDA 日志压缩包、识别失败、任务卡死、控制器差异、Pipeline/Agent/MXU 问题。会从 maafw.log、maafw.bak.*.log、go-service.log、mxu-tauri.log、mxu-web-*.log、mxu-agent*.log、config/*、on_error/ 中筛选证据，并结合 MDA、MaaFramework、MXU 代码和文档判断根因。 --- # MDA Issue / Log Analysis ## Scope - 用于 MDA 仓库：`https://github.com/1204244136/MDA`。 - 输入可以是完整 issue URL、`#1234` 形式的 issue 编号、本地日志目录或日志压缩包路径。 - 只分析用户授权访问的公开 issue、用户提供的日志包或本地文件。 - 如果 issue 没有日志包，且问题明确需要运行证据，先说明证据不足；不要凭空推断根因。 - 如果发现 `.dmp` 文件，必须联动 `dmp-analysis` skill，不要只凭文本日志猜测崩溃原因。 ## Workflow ### 1. 规范化输入 - `#1234` 视为 `https://github.com/1204244136/MDA/issues/1234`。 - 如果 URL 不是 `1204244136/MDA`，说明本 skill 不适用，除非用户明确要求按 MDA 同类日志格式分析。 - 如果输入是本地路径，先识别它是目录、zip 包还是单个日志文件。 ### 2. 获取 issue / 日志上下文 从 issue 或用户描述中提取： - MDA 版本。 - MaaFramework / MXU 版本。 - 控制器类型。 - 任务名 / 入口名。 - 用户期望行为。 - 实际行为。 - 复现步骤。 - 维护者评论。 维护者评论只能作为线索；仍需用日志和代码自行验证。 ### 3. 提取日志附件 关注 MDA 导出的日志压缩包。附件命名可能随打包工具变化，不要只匹配单一文件名；优先寻找包含以下文件或目录的 zip： - `maafw.log` - `maafw.bak.*.log` - `go-service.log` - `mxu-tauri.log` - `mxu-web-YYYY-MM-DD.log` - `mxu-agent*.log` - `config/` - `on_error/` - `.dmp` 如果同一个 issue 有多个日志包： 1. 先看最新一次复现。 2. 若 issue 在对比版本、控制器或配置，再补看前面的包。 ### 4. 下载 / 解压日志包 二进制 zip 不要用网页抓取工具直接读取。使用终端下载到临时目录，例如： ```text .cache/issue-logs/issue-/ .cache/log-analysis/local-/ ``` 解压后先列目录，不要假定结构固定。常见差异： - 多份 `mxu-agent--.log`。 - 多天 `mxu-web-YYYY-MM-DD.log`。 - `maafw.log` 过短，需要看 `maafw.bak.*.log`。 - 没有 `on_error/`。 - 现场图被日志导出体积限制截断。 - 包内存在 `.dmp`。 ### 5. DMP 崩溃转储分析 如果发现 `.dmp`： 1. 立即读取并执行 `.claude/skills/dmp-analysis/SKILL.md`。 2. 解析异常类型、崩溃模块、crashing thread。 3. 需要时下载 MaaFramework / MXU PDB 并符号化。 4. 用 DMP 文件名中的 PID 与 `maafw.log` 的 `[Px]` 或 MXU 日志交叉验证。 5. 最终报告必须包含 DMP 分析区域，并列出 crashing thread 的全部有效帧。 不要把 `.dmp` 当作普通附件跳过。 ### 6. 建立时间线 先定位用户认为出问题的时间，再串联日志： 1. `mxu-web-*`：前端提交了什么任务和配置。 2. `mxu-tauri.log`：实例、控制器、资源、任务开始/停止、agent 生命周期。 3. `maafw.log` / `maafw.bak.*.log`：Pipeline 节点识别、动作、超时、回调。 4. `go-service.log`：Go 自定义逻辑、环境检查、业务日志。 5. `mxu-agent*.log`：agent stdout/stderr 和用户运行日志面板。 6. `on_error/`：错误现场截图。 优先锁定本次复现的 `task_id`，后续分析都限定到该任务实例。一个日志包里经常混有历史运行，不要串任务。 ### 7. 回溯到 MDA 代码和配置 MDA 代码证据优先顺序： - 任务入口、控制器限制、用户选项： - `assets/tasks/*.json` - `assets/interface.json` - `assets/tasks/preset/*.json` - Pipeline 节点： - `assets/resource/pipeline/**/*.json` - Go 扩展逻辑： - `agent/go-service/**` - Schema / 协议： - `tools/schema/*.json` - 本地化文案： - `assets/locales/interface/zh_cn.json` - `assets/locales/interface/en_us.json` 总结任务、选项、界面提示时，优先读取 `zh_cn.json` 的中文文案，不要直接把 task id 当成用户可见名称。 ### 8. 必要时查上游 先用 issue、日志、MDA 仓库和 MaaFramework 文档做初步归因。只有证据指向上游实现或现有证据不足时，再看： - MaaFramework：`https://github.com/MaaXYZ/MaaFramework` - MXU：`https://github.com/MistEO/MXU` - maa-framework-go：`https://github.com/MaaXYZ/maa-framework-go` - maa-framework-rs：`https://github.com/MaaXYZ/maa-framework-rs` 不要为了普通 Pipeline 配置问题过早下钻上游源码。 ## Log Map ### `maafw.log` MaaFramework 核心运行时日志。 最适合看： - Pipeline 是否按预期推进。 - `next` / `on_error` 是否命中。 - `Tasker.Task.Starting` / `Succeeded` / `Failed`。 - `Node.Recognition.Failed` 连续重复。 - `Node.Action.Failed`。 - OCR / TemplateMatch / ColorMatch 细节。 - 控制器、截图、资源加载问题。 ### `maafw.bak.*.log` 滚动日志。用于： - 当前 `maafw.log` 不够长。 - 复现发生在较早时间。 - 对比同配置的历史成功/失败样本。 不要把旧日志误判成最新复现。 ### `go-service.log` MDA Go Agent 日志。 最适合看： - 自定义识别器/动作是否触发。 - taskersink 环境检查，例如 HDR、分辨率、进程检查、会员/额度逻辑。 - Go 参数解析、外部请求、业务扩展错误。 环境告警不一定是根因，必须和 `maafw.log`、现场截图一起判断。 ### `mxu-tauri.log` MXU Tauri/Rust 后端日志。 最适合看： - 实例创建与资源加载。 - 控制器连接。 - 任务开始/停止。 - agent 生命周期。 - `maa_ffi` 回调。 - 用户是否手动停止任务。 ### `mxu-web-YYYY-MM-DD.log` MXU 前端日志。 最适合看： - UI 是否加载了正确的 `interface.json`。 - 用户实际提交了哪些任务和配置。 - `pipeline_override` 是否符合用户选择。 - 配置持久化或界面状态问题。 日志包可能含多天文件，要优先看复现当天。 ### `mxu-agent*.log` MXU 捕获的 agent 子进程 stdout/stderr。 最适合看： - 用户在运行日志面板看到的内容。 - 子进程 stdout/stderr 报错。 - MaaFramework 或 go-service 的辅助输出。 它有用但不是最权威的根因日志；细节仍优先看 `maafw.log` 和 `go-service.log`。 ### `config/*` 配置快照。常见文件： - `config/mxu-MDA.json` - `config/maa_option.json` - `config/maa_pi_config.json` 最适合看： - 实际启用了哪些任务和选项。 - 控制器配置。 - 是否开启错误截图保存。 - 用户口述配置与实际配置是否一致。 ### `on_error/` MaaFramework 错误现场截图。 最适合看： - 实际停留界面。 - 模板/OCR 是否识别错画面。 - 是否被弹窗、加载态、遮罩、分辨率、HDR 等干扰。 日志和用户描述冲突时，优先相信现场截图。 ## How To Filter Evidence 1. 先从用户描述或 issue 拿锚点：版本、控制器、任务名、入口名、失败画面、复现步骤。 2. 在日志中找高价值信号： - `Tasker.Task.Starting` / `Succeeded` / `Failed` - `Node.Recognition.Failed` - `Node.Action.Failed` - `timeout` - `Warn` / `Error` / `Fatal` - agent 启动失败、断连、被停止 3. 锁定本次复现 task_id 后再看细节。 4. Pipeline 问题重点看 `maafw.log` 和 `mxu-tauri.log` 回调。 5. Go 扩展问题重点看 `go-service.log` 和 `mxu-agent*.log`。 6. UI / 配置 / 编排问题重点看 `mxu-web-*`、`mxu-tauri.log`、`config/*`。 7. 只摘足够支撑结论的关键片段，不要倾倒整份日志。 ## Common Patterns - `next` 列表中的识别连续失败直到超时： - 当前画面不在预期分支、模板/OCR 失配、漏了中间节点、弹窗打断、控制器资源不匹配。 - 某个兜底返回/退出节点连续成功但流程没有前进： - Pipeline 对当前状态判断错了，或回退动作本身就是错误行为。 - issue 文字说失败，但目标 `task_id` 最终 `Tasker.Task.Succeeded`： - 明确写“本日志未复现用户描述的失败”。 - 如代码仍有脆弱点，单独标为潜在风险，不当作已证实根因。 - 用户日志流程与当前主线代码明显不一致： - 先确认用户版本。 - 必要时按对应 tag/commit 复核旧逻辑。 - 不要用当前分支直接否定旧版本日志。 - 奖励/确认弹窗节点识别和点击成功，但父流程没有验证弹窗消失： - 这是常见脆弱点；若本次没失败，写成潜在风险。 - `go-service.log` 只有 HDR / 分辨率 / 进程告警： - 通常是环境风险提示，不自动等同根因。 - `maafw.bak.*.log` 有同配置历史成功样本，本次失败： - 可作为行为回归或环境差异的强旁证。 ## Localized Copy 输出任务、选项、界面提示时，优先查： 1. `assets/locales/interface/zh_cn.json` 2. `assets/locales/interface/en_us.json` 常见 key： - `task..label` - `task..description` - `option..label` - `option..description` - `task..option..label` 如果中文 key 缺失，退回原始 id，并说明未找到对应文案。 ## Linking Code Evidence 如果要指向具体代码行： - 本地工作中可以用相对路径引用文件。 - 面向 issue 报告时，优先给远端 GitHub blob 行号链接。 - MDA 链接格式： - `https://github.com/1204244136/MDA/blob//#L1-L2` - `` 使用本次分析依据的版本：当前 `HEAD`、用户版本 tag，或日志对应 commit。 ## Output Format 最终回答推荐结构： ````markdown ## Issue / 日志概要 - issue / 日志包：`...` - 版本 / 控制器：`...` - 任务 / 相关选项：优先使用中文 label，必要时补 task id - 用户现象：... ## 关键证据
点击展开 - `maafw.log`：... - `go-service.log`：... - `mxu-tauri.log`：... - `mxu-web-*.log`：... - `mxu-agent*.log` / `on_error`：... - 代码依据：... ### DMP 崩溃分析 （仅当存在 `.dmp` 时输出；否则删除本节。） - DMP 文件：`...` - 异常类型：`...` - 崩溃模块：`...` - 符号化状态：... ```text Frame 0: ... Frame 1: ... ```
## 根因判断 - 直接结论：... - 证据链：... - 置信度：高 / 中 / 低 ## 给用户的建议 - 用户现在可以尝试：... - 是否建议升级 / 重下完整包 / 同步资源 / 重置配置：... - 是否有临时绕过方案：... ## 修复方案 1. Pipeline / 配置 / Go 代码修复方向。 2. 需要补充的测试或日志。 3. 如属于不支持场景，说明应如何限制入口或改进提示。 ## 给修复 AI 的建议（可复制） ```text 现象： ... 关键证据： ... 可能相关线索（待验证）： ... ``` ```` ## Reminders - 发现 `.dmp` 必须执行 `dmp-analysis`。 - 不要只看一个日志文件下结论。 - 不要把维护者评论当唯一证据。 - 不要把环境告警自动等同根因。 - 日志与 issue 文字不一致时，明确说明“证据未复现”还是“证据已复现但用户表述不精确”。 - 如果证据表明问题已在新版本修复，明确建议升级。 - 如果怀疑安装包、资源或配置损坏，明确建议重新下载、同步资源或重建配置。