| 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.logmaafw.bak.*.loggo-service.logmxu-tauri.logmxu-web-YYYY-MM-DD.logmxu-agent*.logconfig/on_error/.dmp
如果同一个 issue 有多个日志包：
- 先看最新一次复现。
- 若 issue 在对比版本、控制器或配置，再补看前面的包。
4. 下载 / 解压日志包
二进制 zip 不要用网页抓取工具直接读取。使用终端下载到临时目录，例如：
.cache/issue-logs/issue-<number>/
.cache/log-analysis/local-<timestamp>/
解压后先列目录，不要假定结构固定。常见差异：
- 多份
mxu-agent-<index>-<pid>.log。
- 多天
mxu-web-YYYY-MM-DD.log。
maafw.log 过短，需要看 maafw.bak.*.log。- 没有
on_error/。
- 现场图被日志导出体积限制截断。
- 包内存在
.dmp。
5. DMP 崩溃转储分析
如果发现 .dmp：
- 立即读取并执行
.claude/skills/dmp-analysis/SKILL.md。
- 解析异常类型、崩溃模块、crashing thread。
- 需要时下载 MaaFramework / MXU PDB 并符号化。
- 用 DMP 文件名中的 PID 与
maafw.log 的 [Px<pid>] 或 MXU 日志交叉验证。
- 最终报告必须包含 DMP 分析区域，并列出 crashing thread 的全部有效帧。
不要把 .dmp 当作普通附件跳过。
6. 建立时间线
先定位用户认为出问题的时间，再串联日志：
mxu-web-*：前端提交了什么任务和配置。mxu-tauri.log：实例、控制器、资源、任务开始/停止、agent 生命周期。maafw.log / maafw.bak.*.log：Pipeline 节点识别、动作、超时、回调。go-service.log：Go 自定义逻辑、环境检查、业务日志。mxu-agent*.log：agent stdout/stderr 和用户运行日志面板。on_error/：错误现场截图。
优先锁定本次复现的 task_id，后续分析都限定到该任务实例。一个日志包里经常混有历史运行，不要串任务。
7. 回溯到 MDA 代码和配置
MDA 代码证据优先顺序：
- 任务入口、控制器限制、用户选项：
assets/tasks/*.jsonassets/interface.jsonassets/tasks/preset/*.json
- Pipeline 节点：
assets/resource/pipeline/**/*.json
- Go 扩展逻辑：
- Schema / 协议：
- 本地化文案：
assets/locales/interface/zh_cn.jsonassets/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.jsonconfig/maa_option.jsonconfig/maa_pi_config.json
最适合看：
- 实际启用了哪些任务和选项。
- 控制器配置。
- 是否开启错误截图保存。
- 用户口述配置与实际配置是否一致。
on_error/
MaaFramework 错误现场截图。
最适合看：
- 实际停留界面。
- 模板/OCR 是否识别错画面。
- 是否被弹窗、加载态、遮罩、分辨率、HDR 等干扰。
日志和用户描述冲突时，优先相信现场截图。
How To Filter Evidence
- 先从用户描述或 issue 拿锚点：版本、控制器、任务名、入口名、失败画面、复现步骤。
- 在日志中找高价值信号：
Tasker.Task.Starting / Succeeded / FailedNode.Recognition.FailedNode.Action.FailedtimeoutWarn / Error / Fatal- agent 启动失败、断连、被停止
- 锁定本次复现 task_id 后再看细节。
- Pipeline 问题重点看
maafw.log 和 mxu-tauri.log 回调。
- Go 扩展问题重点看
go-service.log 和 mxu-agent*.log。
- UI / 配置 / 编排问题重点看
mxu-web-*、mxu-tauri.log、config/*。
- 只摘足够支撑结论的关键片段，不要倾倒整份日志。
Common Patterns
-
next 列表中的识别连续失败直到超时：
- 当前画面不在预期分支、模板/OCR 失配、漏了中间节点、弹窗打断、控制器资源不匹配。
-
某个兜底返回/退出节点连续成功但流程没有前进：
- Pipeline 对当前状态判断错了，或回退动作本身就是错误行为。
-
issue 文字说失败，但目标 task_id 最终 Tasker.Task.Succeeded：
- 明确写“本日志未复现用户描述的失败”。
- 如代码仍有脆弱点，单独标为潜在风险，不当作已证实根因。
-
用户日志流程与当前主线代码明显不一致：
- 先确认用户版本。
- 必要时按对应 tag/commit 复核旧逻辑。
- 不要用当前分支直接否定旧版本日志。
-
奖励/确认弹窗节点识别和点击成功，但父流程没有验证弹窗消失：
-
go-service.log 只有 HDR / 分辨率 / 进程告警：
-
maafw.bak.*.log 有同配置历史成功样本，本次失败：
Localized Copy
输出任务、选项、界面提示时，优先查：
assets/locales/interface/zh_cn.jsonassets/locales/interface/en_us.json
常见 key：
task.<TaskId>.labeltask.<TaskId>.descriptionoption.<OptionId>.labeloption.<OptionId>.descriptiontask.<TaskId>.option.<OptionId>.label
如果中文 key 缺失，退回原始 id，并说明未找到对应文案。
Linking Code Evidence
如果要指向具体代码行：
- 本地工作中可以用相对路径引用文件。
- 面向 issue 报告时，优先给远端 GitHub blob 行号链接。
- MDA 链接格式：
https://github.com/1204244136/MDA/blob/<commit>/<path>#L1-L2
<commit> 使用本次分析依据的版本：当前 HEAD、用户版本 tag，或日志对应 commit。
Output Format
最终回答推荐结构：
## Issue / 日志概要
- issue / 日志包：`...`
- 版本 / 控制器：`...`
- 任务 / 相关选项：优先使用中文 label，必要时补 task id
- 用户现象：...
## 关键证据
<details><summary>点击展开</summary>
- `maafw.log`：...
- `go-service.log`：...
- `mxu-tauri.log`：...
- `mxu-web-*.log`：...
- `mxu-agent*.log` / `on_error`：...
- 代码依据：...
### DMP 崩溃分析
（仅当存在 `.dmp` 时输出；否则删除本节。）
- DMP 文件：`...`
- 异常类型：`...`
- 崩溃模块：`...`
- 符号化状态：...
```text
Frame 0: ...
Frame 1: ...
```
</details>
## 根因判断
- 直接结论：...
- 证据链：...
- 置信度：高 / 中 / 低
## 给用户的建议
- 用户现在可以尝试：...
- 是否建议升级 / 重下完整包 / 同步资源 / 重置配置：...
- 是否有临时绕过方案：...
## 修复方案
1. Pipeline / 配置 / Go 代码修复方向。
2. 需要补充的测试或日志。
3. 如属于不支持场景，说明应如何限制入口或改进提示。
## 给修复 AI 的建议（可复制）
```text
现象：
...
关键证据：
...
可能相关线索（待验证）：
...
```
Reminders
- 发现
.dmp 必须执行 dmp-analysis。
- 不要只看一个日志文件下结论。
- 不要把维护者评论当唯一证据。
- 不要把环境告警自动等同根因。
- 日志与 issue 文字不一致时，明确说明“证据未复现”还是“证据已复现但用户表述不精确”。
- 如果证据表明问题已在新版本修复，明确建议升级。
- 如果怀疑安装包、资源或配置损坏，明确建议重新下载、同步资源或重建配置。
