统一的"capture_debug_bundle"工具 (HAR + 控制台 + 性能 + 屏幕截图)

你的功能请求是否与问题有关？请描述。 当使用 chrome-devtools-mcp 的代理遇到页面中的错误、回退或“可疑行为”时，通常需要收集多种类型的 DevTools 数据来进行正确的调试： - 网络行为（HAR / 水滴图）。 - 控制台错误和警告。 - 性能特征（长任务、主线程活动、布局混乱）。 - 可视化上下文（屏幕截图、视口快照）。 - 可能的 DOM / 存储上下文。 目前，代理（或主机）需要： - 使用多个低级别工具（如果暴露）或 - 依赖于 MCP 服务器之外的自定义脚本和 CDP 调用，或 - 完全跳过收集此类数据，这会使人类或后续分析变得更加困难。 相比之下，当人类在 Chrome DevTools 中进行调试时，通常会“导出 HAR”、“截取屏幕”或“记录性能追踪”，并在问题发生的位置附加到错误报告中。 对于代理，没有单一的高级工具来表示： > “我遇到了问题，请捕获相关的 DevTools 文件，以便人类（或其他系统）可以在以后分析此问题。” ### 描述你想要的解决方案 介绍一个 单一的高级工具（例如 capture_debug_bundle）来从当前页面/会话中收集可配置的调试文件，并以结构化的形式返回它们。 #### 1. capture_debug_bundle 工具 - 输入（示例形状，确切的模式灵活）： - include_network_har: bool（默认：true） - include_console_logs: bool（默认：true） - include_performance_trace: bool（默认：false 或时间限定） - include_screenshot: bool（默认：true） - trace_duration_ms: number（可选；如果要捕获围绕调用的迷你追踪） - note: string（可选，代理对 为什么 要捕获此捆绑的简短描述） - 输出（示例）： - bundle_id: string - artifacts: { ... } 具有以下字段： - network_har（HAR JSON，或引用/URL 到存储的 HAR） - console_logs（结构化数组：类型，消息，时间戳，堆栈） - performance_trace（追踪 JSON 或 URL 到追踪文件） - screenshot（数据 URL 或二进制引用/URL） - metadata（URL，时间戳，用户代理，如果可用，环境/配置名称等） 服务器可选择将这些捆绑存储在某个位置（文件系统/配置存储）并返回主机或人类可以以后检索的引用。 #### 2. 可选的辅助工具 不必强制使用，但可以补充主工具： - list_debug_bundles → 在当前会话/时间窗口中枚举捕获的捆绑。 - get_debug_bundle(bundle_id) → 重新检索之前捕获的捆绑。 从代理的角度来看，核心流程如下： 1. 检测失败/异常（HTTP 5xx，不正确的 UI 状态，意外错误）。 2. 使用短说明调用 capture_debug_bundle。 3. 将结果的 bundle_id / 文件提供给用户，或者