goose 内置诊断Diagnostics与支持上报指南生成诊断包、报告 Bug 与请求新功能【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goosegoose 提供了一整套开箱即用的诊断与支持工具用于在会话异常、运行崩溃或遇到费解错误时快速收集现场数据。本文基于 documentation/docs/troubleshooting/diagnostics-and-reporting.md 展开结合 goose 仓库中诊断生成器与 CLI 命令的真实实现crates/goose/src/session/diagnostics.rs、crates/goose-cli/src/commands/session.rs讲解如何在 goose Desktop 与 goose CLI 两种界面下生成诊断报告、如何用仓库自带的diagnostics-viewer.py检查报告内容以及如何结构化地上报 Bug、提交功能需求。读完本文你将掌握一套完整的「遇到问题 → 收集证据 → 提交反馈」流程也能看懂诊断 JSON 中每一个字段背后的数据来源。功能总览goose 内置三项与支持、反馈相关的功能覆盖了「自检数据采集」与「向社区反馈」两个环节功能用途入口位置输出诊断Diagnostics生成排障数据聊天输入工具栏包含系统信息、日志与会话数据的 JSON 报告报告 BugReport a Bug提交缺陷报告聊天输入工具栏或 Settings → App → Help feedback打开预填的 GitHub Issue 模板请求新功能Request a Feature建议新特性Settings → App → Help feedback打开预填的功能请求 Issue 模板三者定位互补诊断包负责「把问题现场打包带走」Issue 模板负责「把现场数据按统一格式交给维护者」。建议在提交任何 Bug 之前先生成一份诊断报告并把报告作为 Issue 的技术附件这样维护者可以复现你的环境而不必反复追问版本、配置与日志。诊断系统一条命令打包完整现场诊断功能的核心价值是把「问题发生时的一切相关数据」汇总为一份结构化报告包括应用版本与系统环境、当前会话内容、配置文件、最近的应用日志等。这份报告对自查排障与获取技术支持都非常有用。在 goose Desktop 中生成诊断在活动的聊天会话中找到底部工具栏上的Bug图标点击诊断按钮diagnostics button在弹出的模态窗口中审阅「将要收集哪些数据」的说明点击Download生成并保存诊断报告JSON 文件将被保存为diagnostics_{session_id}.json。提示诊断按钮仅在存在活动会话时可用因为生成数据包需要一个会话 ID。如果你刚启动应用还没有打开任何会话先新建或进入一个会话再操作。在 goose CLI 中生成诊断CLI 用户通过session子命令下的diagnostics命令生成排障数据包。命令的完整定义位于 crates/goose-cli/src/cli.rs 的SessionCommand::Diagnostics分支其处理逻辑见 crates/goose-cli/src/commands/session.rs 中的handle_diagnostics函数。更多选项说明可参考 CLI 命令指南。# 为指定会话生成诊断 goose session diagnostics --session-id session_id # 交互式选择会提示你选择一个会话 goose session diagnostics # 保存到自定义路径 goose session diagnostics --session-id session_id --output /path/to/diagnostics.json如果省略--output报告默认写入当前目录下的diagnostics_{session_id}.json。在底层实现中CLI 会将 crates/goose/src/session/diagnostics.rs 中generate_diagnostics()返回的报告用serde_json::to_vec_pretty序列化为格式化的 JSON再通过open_diagnostics_output安全地创建输出文件该函数在 Unix 上使用O_NOFOLLOW在 Windows 上校验FILE_FLAG_OPEN_REPARSE_POINT避免写入符号链接等非常规文件见 crates/goose-cli/src/commands/session.rs 中对应代码。先找到你的会话 ID列出当前可用会话goose session list示例输出Available sessions: abc123def - My coding session - 2024-01-15 14:30:22 xyz789ghi - Documentation work - 2024-01-15 10:15:45把abc123def这类会话 ID 填入--session-id即可也可以不带任何参数直接运行goose session diagnostics让 CLI 用prompt_interactive_session_selection交互式地让你挑选会话。诊断报告的字段结构源码视角的真实 Schema原文档给出了诊断 JSON 的概览结构。结合 crates/goose/src/session/diagnostics.rs 中的DiagnosticsReport结构体可以确认报告的实际字段比概览更完整并且除level、generated_at、system等个别字段外多数字段序列化时使用驼峰命名camelCase结构体上标注了#[serde(rename_all camelCase)]。概览结构示意如下{ schemaVersion: 1, generatedAt: 2026-09-08T02:26:44Z, level: full, system: {}, config: {}, extensions: {}, session: {}, logs: {}, prompts: [], schedule: {}, scheduledRecipes: [], errors: [] }各顶层字段的含义与来源如下字段含义数据来源对应源码逻辑schemaVersion报告格式版本号当前为1固定值便于未来格式演进时做兼容判断generatedAt生成时间RFC 3339 / UTCchrono::Utc::now().to_rfc3339()level诊断级别summary或fullDiagnosticsLevel枚举Summary为默认值CLI 使用Fullsystem系统与应用信息SystemInfo::collect()config主配置文件路径与内容Paths::config_dir().join(config.yaml)读取时受截断限制extensions已启用的扩展名列表get_enabled_extensions()仅收集名称session当前会话导出数据完整级别才有SessionManager::export_session(session_id)logsCLI 与 LLM 请求日志见下文「日志收集规则」prompts当前可用的提示词模板名称与内容list_templates()来源见 crates/goose/src/prompt_template.rsschedule计划任务配置读取数据目录下的schedule.jsonscheduledRecipes已排程的 recipe 文件与内容扫描数据目录下的scheduled_recipes/errors收集过程中的失败项路径 消息各读取步骤捕获的错误统一追加到该数组保证「部分失败不阻断整体报告」其中system节点由SystemInfo结构体承载包含app_version编译时注入的CARGO_PKG_VERSION、os与os_version、architecture、当前provider与model、以及enabled_extensions列表。SystemInfo::to_text()还会把这些信息格式化为可读的纯文本摘要含时间戳便于直接粘贴到 Issue 中。日志收集规则与截断上限为避免报告体积失控诊断器在读取大文件时执行了严格的截断策略这些常量定义在 crates/goose/src/session/diagnostics.rs 顶部常量值作用LLM_LOG_MAX_BYTES2 * 1024 * 10242 MB单条 LLM 请求日志llm_request.*.jsonl最大读取字节数CONFIG_MAX_BYTES256 * 1024256 KBconfig.yaml最大读取字节数CLI_LOG_TAIL_LINES400每个 CLI 日志文件只取末尾 400 行CLI_LOGS_TO_INCLUDE3最多包含 3 个最近修改的 CLI 日志文件超限文本不会直接丢弃read_capped会保留「开头一半 结尾一半」并在中间插入... (N bytes omitted) ...占位提示read_tail则按行取文件末尾内容。CLI 日志存放在状态目录logs/cli/下LLM 请求日志则匹配状态目录logs/下以llm_request.开头、.jsonl结尾的文件编号文件按序号排序滚动文件按修改时间排序详见recent_cli_log_paths与recent_llm_log_paths。诊断级别Summary 与 FullDiagnosticsLevel枚举定义了Summary默认与Full两种级别。从generate_diagnostics的实现可以看到在Summary级别下session、config、logs、prompts、schedule、scheduled_recipes均不填充为None/ 空数组只有系统信息与启用扩展列表而 goose CLI 的goose session diagnostics固定使用DiagnosticsLevel::Full因此生成的报告会携带完整会话与日志数据。这也意味着CLI 生成的诊断包包含你的会话消息全文分享前务必检查敏感内容。使用 diagnostics-viewer.py 检查诊断报告仓库根目录的 scripts/diagnostics-viewer.py 提供了一个交互式终端查看器基于 Textual 构建的 TUI用于浏览与检查下载的诊断报告。默认情况下它扫描~/Downloads目录Desktop 端生成的报告默认保存在该目录# 扫描默认目录 ~/Downloads python scripts/diagnostics-viewer.py # 指定扫描目录 python scripts/diagnostics-viewer.py /path/to/diagnostics_dir该脚本同时支持新版 JSON 报告diagnostics*.json与旧版 zip 压缩包diagnostics*.zip并在内部把 JSON 报告虚拟映射为一组文件视图system.json、session.json、config.yaml、extensions.json、logs/llm_request.*.jsonl、prompts/*.txt、scheduled_recipes/*等见DiagnosticsSession._json_virtual_files。查看器提供树形 JSON 浏览CtrlO全量展开/收起、针对超长字符串的弹窗查看、搜索界面以及按C复制当前文件内容等快捷键。什么时候该生成诊断遇到以下情形时建议先导出诊断报告再行动出现崩溃或不符合预期的行为收到你无法理解的错误信息遇到性能问题或响应缓慢准备上报 Bug需要附带技术细节。诊断中包含的内容系统信息System Information应用版本、操作系统、系统版本、架构、时间戳以及当前 Provider、Model 与已启用扩展会话数据Session Data当前对话的完整消息与历史配置文件Configuration Files你的 配置文件如果存在日志文件Log Files用于排障的近期应用日志。隐私提示诊断包包含你的会话消息与系统信息。如果会话中含有敏感数据API Key、个人信息、专有代码在公开分享之前务必先检查包内内容——这也是推荐先用diagnostics-viewer.py本地预览一遍再上传的原因。报告 BugBug 报告功能会打开一个结构化的 GitHub Issue 模板引导你填写完整信息从而提升问题的可复现性与处理效率。创建 Bug 报告goose Desktop在活动的聊天会话中点击底部工具栏的Bug图标点击诊断按钮点击File Bug on GitHub浏览器将打开一个已预填内容的 Bug 报告模板页面。goose CLICLI 用户可直接访问项目仓库的 Issue 页面并按bug_report.md模板提交https://github.com/aaif-goose/goose/issues/new?templatebug_report.md注上述为模板入口地址需在浏览器中打开并按模板填写。请求新功能功能请求系统用于向 goose 建议改进点与全新能力。提交前如果能同时描述使用场景与期望行为将大幅提升需求被采纳并正确实现的可能性。提交功能请求goose Desktop点击窗口左上角的面板图标PanelLeft打开侧边栏在侧边栏点击Settings切换到App标签页向下滚动到Help feedback区域点击Request a Feature浏览器将打开预填的功能请求模板。goose CLI直接访问功能请求模板https://github.com/aaif-goose/goose/issues/new?templatefeature_request.md报错时的快捷自救Ask goose在 goose Desktop 中某些类型的错误例如扩展激活失败发生后错误通知里会出现一个Ask goose按钮。该功能让你借助 goose 自己快速定位问题错误发生时通知栏出现Ask goose按钮点击按钮将错误详情以聊天提示的形式发送给 goosegoose 会返回诊断性建议与可能的解决方案。这相当于把「报错信息 → 人工搜索」的流程简化为「报错信息 → goose 直接分析」适合先于提 Issue 做一轮快速自查。进一步的调试手段如果诊断数据没能解决问题官方还提供两处更深的排障入口会话与系统日志查看用于单会话调试的详细日志遥测导出按环境变量配置遥测用于性能分析与生产环境监控。小结一套完整的排障工作流把本文内容串联起来goose 用户的推荐问题处理路径是复现问题 → DesktopBug 图标 → Download或 CLIgoose session diagnostics生成诊断包 → 用 scripts/diagnostics-viewer.py 本地核对内容与敏感信息 → 点击 “File Bug on GitHub” 提交预填 Issue 并附上诊断数据 → 若为需求类反馈则走 “Request a Feature” 模板。若只是想快速验证某个报错能否自愈可优先尝试错误通知中的Ask goose。理解诊断 JSON 各字段的来源crates/goose/src/session/diagnostics.rs后你甚至可以在等待官方支持前自行根据system、config、logs、errors节点交叉定位问题根因。【免费下载链接】goosean open source, extensible AI agent that goes beyond code suggestions - install, execute, edit, and test with any LLM项目地址: https://gitcode.com/GitHub_Trending/goose3/goose创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考