Goose 发布清单实战风险分级、自测配方与 Agent 驱动的 Release QA 流程【免费下载链接】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 的每次版本发布都依赖一份手工测试清单来把关质量在 release PR 上下载构建包、用自动化脚本对版本内所有 PR 做风险分级、跑通 Agent 自身的集成测试配方最后让 Goose 基于风险报告反推一份测试计划。本文基于仓库根目录的 RELEASE_CHECKLIST.md 逐环节展开结合 workflow_recipes/release_risk_check/ 下的脚本与配方源码、goose-self-test.yaml 自测配方讲清这份清单背后每个环节的输入、输出与底层实现帮助你在发布任何 Goose 版本时知道“测什么、怎么测、风险从哪来”。发布清单在整个发布流程中的位置Goose 的发布由 GitHub Actions 自动化驱动定期创建版本提升 PR合并后自动建立release/version分支并开出带 QA 清单的 release PR测试就绪后打 tag 触发构建发布。完整流程见 RELEASE.md。RELEASE_CHECKLIST.md 就是这份 QA 环节的操作手册核心动作有四步从 release PR 下载构建包Actions bot 会在 PR 上评论下载与签名方式运行风险检查脚本生成风险分级报告与测试计划运行 Goose 自测配方goose run --recipe goose-self-test.yaml让 Goose 针对 release PR 产出具体测试计划并执行。第一步下载 Release 构建包清单开头说明发布构建来自 release PR 本身。构建就绪后Actions bot 会在该 PR 下发表评论给出下载与签名的说明。因此 QA 的第一动作是找到对应版本的 release PR标题中带版本号按 bot 评论指引下载对应平台的构建包在本地真实运行桌面端与 CLI验证基本可用性。这一步是后续所有自动化风险检查的“基线”报告告诉你哪些 PR 高危而你手上的构建包就是验证对象。第二步生成风险分级报告与测试计划清单给出的命令是./workflow_recipes/release_risk_check/run.sh {{VERSION}}例如./workflow_recipes/release_risk_check/run.sh 1.27.0。它会分析该版本 release PR 引用的所有 PR生成一份风险分析报告到/tmp/release_report_final.md并在高风险变更出现时给出相应的测试要求。下面拆解这条命令背后的三层实现。run.sh一条命令拉起 Agent 配方run.sh 本身非常薄校验第一个参数缺失时打印Usage: $0 version然后执行goose run --recipe $SCRIPT_DIR/recipe.yaml --params version$1也就是说版本字符串作为version参数注入 recipe.yaml 定义的配方由 Goose Agent 自己按步骤执行整个风险检查流程。配方三步走启发式报告、AI 复核、合并终版recipe.yaml 定义了三步指令Step 1 生成启发式报告执行release_risk_report.py --version {{version}} -o /tmp/release_report.md产出按 HIGH/MEDIUM/LOW 分级的初步报告分级依据是文件变更、代码行数和核心路径分析。Step 2 AI 复核 MEDIUM/HIGH 风险 PR把 Step 1 报告中的中高风险 PR 交给 LLM 复核。配方内嵌了一段完整的评审提示词核心是把 Goose 的架构按敏感程度分三档CRITICAL可能绕过安全或导致数据丢失权限系统crates/goose/src/permission/、工具执行管线crates/goose/src/agents/下的工具执行与 agent 逻辑、安全检查crates/goose/src/tool_inspection.rs负责检测提示注入与破坏性操作、ACP 权限流crates/goose/src/acp/中的用户审批处理、会话数据库crates/goose/src/session/SQLite 存储schema 变更有数据丢失风险、ACP 认证goose serve的访问控制。HIGH影响核心功能Agent 主循环消息路由、轮次上限、上下文压缩、Provider 集成LLM API 调用、凭证处理、响应解析、扩展管理器MCP 扩展加载与工具发现、ACP 服务与传输层。MEDIUM影响特定功能CLI 命令crates/goose-cli/、桌面 UIui/desktop/src/、平台内置扩展shell、文件编辑等。提示词还定义了明确的升降级信号修改关键区域既有逻辑、无测试说明、无或仅 bot审批人、跨多个子系统的大 diff、回滚重做、触碰错误处理回退路径——都会推高风险有具体测试用例说明、纯增量改动、只动测试/快照、单一子系统的小 diff——都会降低风险。要求对每个 PR 输出“启发式分数 / AI 风险 / 理由 / 关注点 / 测试情况”的表格并对 HIGH/MEDIUM PR 给出 2–4 条具体测试步骤AI 结论与启发式结论不一致时加粗标注。Step 3 生成最终报告以 Step 1 报告为骨架按 AI 复核结果修正风险计数为每个 MEDIUM/HIGH PR 追加AI assessment与AI concern字段被降级或升级时注明来源LOW 风险与跳过的 PR 保持原样并在顶部加入跨 PR 的核心关注点汇总。配方声明了唯一的必填参数versionrelease 版本号并绑定developer平台扩展以获得 shell 等基础工具能力。release_risk_report.py启发式评分规则全解release_risk_report.py 是 Step 1 的执行者全部基于ghCLI 拉取 GitHub 数据。流程与规则如下定位 release PR在未提供--pr时列出仓库开放 PRgh pr list --json number,title --limit 100按标题包含版本号匹配提取 PR 清单从 release PR 正文的## Changes in This Release小节中用正则\(#(\d)\)提取所有被引用 PR 的编号并行抓取详情用线程池默认 5 个 worker--workers可调并发拉取每个 PR 的标题、正文、作者、文件变更与审批人gh api .../reviews中状态为 APPROVED 的用户跳过规则全部文件位于documentation/下的 doc-only PR以及仅修改依赖锁文件Cargo.lock、package-lock.json、yarn.lock、pnpm-lock.yaml的 PR 直接跳过并单独列出风险评分assess_risk函数累加制信号条件加分大变更增删行数 5002中等变更200 行数 ≤ 5001多文件变更文件数 101触碰核心路径命中CORE_PATHS2无测试文件有生产代码变更但无 test/snap 文件1总分 ≥ 4 判为 HIGH≥ 2 判为 MEDIUM否则 LOW。其中CORE_PATHS硬编码为crates/goose/src/agents/、crates/goose/src/providers/、crates/goose/src/acp/、crates/goose-cli/、crates/goose/src/session、crates/goose/src/permission——与配方提示词中的敏感区域划分保持一致。测试说明提取extract_testing_section会识别 PR 描述中的## Testing、## Test Plan、## How Has This Been Tested、## Verification等小节清理 HTML 注释与空复选框后作为“Testing”字段写入报告找不到则标记为No——这本身是 AI 复核阶段的一个风险信号。报告结构每个被评估 PR 一节按风险分降序排列包含作者、审批人、文件统计additions / -deletions、风险因子列表、测试摘要MEDIUM/HIGH PR 额外列出逐文件路径与增删行数并附上 PR 描述前 500 字符便于 QA 直接阅读上下文。命令行参数为--version必填、--pr可显式指定 release PR 号、--repo默认aaif-goose/goose、-o/--output缺省打印到 stdout、--workers。第三步运行 Goose 自测配方清单的第二项动作是goose run --recipe goose-self-test.yamlgoose-self-test.yaml 是一个“元测试”配方让正在运行的 Goose 实例用自己的工具验证自己的能力属于第一人称集成测试。理解它的关键是参数与五个测试阶段。参数参数默认值说明test_phasesall可选all、basic、extensions、delegation、reasoning、acp-effort、advancedtest_depthstandardquick冒烟、standard常规、deep穷尽workspace_dir./gooseselftest测试产物与报告目录parallel_teststrue独立测试尽量并行cleanup_aftertrue完成后清理临时产物配方声明的成功标准是每个阶段 ≥80% 用例通过整个套件全部阶段完成且关键功能可用每个用例遵循 setup → execute → validate → result → cleanup 的记录规范。它绑定了developer600 秒超时、todo、summon、extensionmanager、skills五个内置扩展。测试阶段Phase 1 基础工具验证文件操作创建、str_replace 替换、按行插入、undo、删除重建、Unicode/特殊字符shell 工作流命令链、false || echo handled错误处理、环境变量代码分析多语言结构分析、目录级分析、符号聚焦与调用图、行数/函数/类统计以及若干 Provider 路由校验例如运行cargo test -p goose-providers databricks_v2::tests::gateway_path验证 Databricks AI Gateway 路径配置、验证 Azure AI Foundry 对不同模型的路由策略。若本机没有源码 checkout 或 Rust 工具链这些子项记为 skipped 而非 failed。Phase 2 扩展系统测试todo 扩展的持久化/更新/清空用platform__search_available_extensions发现动态扩展并验证启用/禁用与扩展间隔离。Phase 3 委派与加载测试summon 工具load()无参发现机制、内置技能加载、知识注入同步/异步/并行 delegate、后台任务 MOIM 状态监控、任务取消与清理、基于 source 的委派以及一项关键安全测试——嵌套委派禁止子代理尝试再调用 delegate 工具必须报错对应SessionType::SubAgent的检查逻辑可以在 summon.rs 中看到对session.session_type SessionType::SubAgent的判断若嵌套委派成功则记为 CRITICAL FAILURE。Phase 3C/3D/3E 推理与 ACP 专项多轮 thinking 保留回放测试针对会拒绝reasoning_content回放的 Provider、cargo test -p goose effort验证 ACP thinking-effort 的发现/转发/Provider 切换、cargo test -p goose-sdk --features uniffi --lib observability验证 GDK 可观测性钩子生命周期事件。Phase 4 高级测试错误边界非法路径、不存在的命令、超长文件名、shell 注入与目录穿越等安全输入、deep深度下的大文件与并发性能测量。Phase 5 报告生成产出{{workspace_dir}}/detailed_report.md详细报告并在终端直接打印不超过 30 行的执行摘要总体 PASS/FAIL、各功能 ✓/✗ 清单、问题列表与关键发现。这套自测配方与开发规范是联动的仓库的 AGENTS.md 要求“添加功能时更新 goose-self-test.yaml重建后运行goose run --recipe goose-self-test.yaml验证”。因此发布前跑一遍该配方等于用最新版本对自己做了一次全链路回归。第四步让 Goose 产出并执行测试计划清单的最后一步是把前面两份材料交给 Agent打开 release 候选桌面应用指向 release PR使用如下提示词Look at the notes in PR release PR and the report at/tmp/release_report_final.mdand investigate potential risks in this release. After familiarizing yourself with the scope of each change, produce a suggested test plan that I should follow before publishing the release.Goose 会基于 PR 说明与风险报告输出一份具体测试计划QA 人员按计划完成剩余手工测试重点覆盖报告中标注 HIGH 的 PR 及其“AI concern”关注点全部通过后再按 release PR 中的说明打 tag 发布。小结一条可复现的发布 QA 链路把清单翻译成一条可执行的命令链# 1. 生成风险报告需要已登录的 gh CLI 与 goose 二进制 ./workflow_recipes/release_risk_check/run.sh 1.27.0 # 产物/tmp/release_report_final.md # 2. 跑自测配方可裁剪阶段 goose run --recipe goose-self-test.yaml --params test_phasesall --params test_depthstandard # 3. 打开桌面应用指向 release PR让 goose 基于报告产出测试计划并执行这份清单的设计要点在于把“发布风险”拆成了可计算的启发式部分行数、文件数、核心路径命中、是否有测试与语义复核的 AI 部分架构敏感度、PR 质量信号再以自测配方兜底核心工具链最后以 Agent 生成的测试计划收敛到人工验证——每个环节都有仓库内可查验的脚本与配方作为依据。【免费下载链接】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），仅供参考 Goose 发布清单实战：风险分级、自测配方与 Agent 驱动的 Release QA 流程
Goose 发布清单实战风险分级、自测配方与 Agent 驱动的 Release QA 流程【免费下载链接】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 的每次版本发布都依赖一份手工测试清单来把关质量在 release PR 上下载构建包、用自动化脚本对版本内所有 PR 做风险分级、跑通 Agent 自身的集成测试配方最后让 Goose 基于风险报告反推一份测试计划。本文基于仓库根目录的 RELEASE_CHECKLIST.md 逐环节展开结合 workflow_recipes/release_risk_check/ 下的脚本与配方源码、goose-self-test.yaml 自测配方讲清这份清单背后每个环节的输入、输出与底层实现帮助你在发布任何 Goose 版本时知道“测什么、怎么测、风险从哪来”。发布清单在整个发布流程中的位置Goose 的发布由 GitHub Actions 自动化驱动定期创建版本提升 PR合并后自动建立release/version分支并开出带 QA 清单的 release PR测试就绪后打 tag 触发构建发布。完整流程见 RELEASE.md。RELEASE_CHECKLIST.md 就是这份 QA 环节的操作手册核心动作有四步从 release PR 下载构建包Actions bot 会在 PR 上评论下载与签名方式运行风险检查脚本生成风险分级报告与测试计划运行 Goose 自测配方goose run --recipe goose-self-test.yaml让 Goose 针对 release PR 产出具体测试计划并执行。第一步下载 Release 构建包清单开头说明发布构建来自 release PR 本身。构建就绪后Actions bot 会在该 PR 下发表评论给出下载与签名的说明。因此 QA 的第一动作是找到对应版本的 release PR标题中带版本号按 bot 评论指引下载对应平台的构建包在本地真实运行桌面端与 CLI验证基本可用性。这一步是后续所有自动化风险检查的“基线”报告告诉你哪些 PR 高危而你手上的构建包就是验证对象。第二步生成风险分级报告与测试计划清单给出的命令是./workflow_recipes/release_risk_check/run.sh {{VERSION}}例如./workflow_recipes/release_risk_check/run.sh 1.27.0。它会分析该版本 release PR 引用的所有 PR生成一份风险分析报告到/tmp/release_report_final.md并在高风险变更出现时给出相应的测试要求。下面拆解这条命令背后的三层实现。run.sh一条命令拉起 Agent 配方run.sh 本身非常薄校验第一个参数缺失时打印Usage: $0 version然后执行goose run --recipe $SCRIPT_DIR/recipe.yaml --params version$1也就是说版本字符串作为version参数注入 recipe.yaml 定义的配方由 Goose Agent 自己按步骤执行整个风险检查流程。配方三步走启发式报告、AI 复核、合并终版recipe.yaml 定义了三步指令Step 1 生成启发式报告执行release_risk_report.py --version {{version}} -o /tmp/release_report.md产出按 HIGH/MEDIUM/LOW 分级的初步报告分级依据是文件变更、代码行数和核心路径分析。Step 2 AI 复核 MEDIUM/HIGH 风险 PR把 Step 1 报告中的中高风险 PR 交给 LLM 复核。配方内嵌了一段完整的评审提示词核心是把 Goose 的架构按敏感程度分三档CRITICAL可能绕过安全或导致数据丢失权限系统crates/goose/src/permission/、工具执行管线crates/goose/src/agents/下的工具执行与 agent 逻辑、安全检查crates/goose/src/tool_inspection.rs负责检测提示注入与破坏性操作、ACP 权限流crates/goose/src/acp/中的用户审批处理、会话数据库crates/goose/src/session/SQLite 存储schema 变更有数据丢失风险、ACP 认证goose serve的访问控制。HIGH影响核心功能Agent 主循环消息路由、轮次上限、上下文压缩、Provider 集成LLM API 调用、凭证处理、响应解析、扩展管理器MCP 扩展加载与工具发现、ACP 服务与传输层。MEDIUM影响特定功能CLI 命令crates/goose-cli/、桌面 UIui/desktop/src/、平台内置扩展shell、文件编辑等。提示词还定义了明确的升降级信号修改关键区域既有逻辑、无测试说明、无或仅 bot审批人、跨多个子系统的大 diff、回滚重做、触碰错误处理回退路径——都会推高风险有具体测试用例说明、纯增量改动、只动测试/快照、单一子系统的小 diff——都会降低风险。要求对每个 PR 输出“启发式分数 / AI 风险 / 理由 / 关注点 / 测试情况”的表格并对 HIGH/MEDIUM PR 给出 2–4 条具体测试步骤AI 结论与启发式结论不一致时加粗标注。Step 3 生成最终报告以 Step 1 报告为骨架按 AI 复核结果修正风险计数为每个 MEDIUM/HIGH PR 追加AI assessment与AI concern字段被降级或升级时注明来源LOW 风险与跳过的 PR 保持原样并在顶部加入跨 PR 的核心关注点汇总。配方声明了唯一的必填参数versionrelease 版本号并绑定developer平台扩展以获得 shell 等基础工具能力。release_risk_report.py启发式评分规则全解release_risk_report.py 是 Step 1 的执行者全部基于ghCLI 拉取 GitHub 数据。流程与规则如下定位 release PR在未提供--pr时列出仓库开放 PRgh pr list --json number,title --limit 100按标题包含版本号匹配提取 PR 清单从 release PR 正文的## Changes in This Release小节中用正则\(#(\d)\)提取所有被引用 PR 的编号并行抓取详情用线程池默认 5 个 worker--workers可调并发拉取每个 PR 的标题、正文、作者、文件变更与审批人gh api .../reviews中状态为 APPROVED 的用户跳过规则全部文件位于documentation/下的 doc-only PR以及仅修改依赖锁文件Cargo.lock、package-lock.json、yarn.lock、pnpm-lock.yaml的 PR 直接跳过并单独列出风险评分assess_risk函数累加制信号条件加分大变更增删行数 5002中等变更200 行数 ≤ 5001多文件变更文件数 101触碰核心路径命中CORE_PATHS2无测试文件有生产代码变更但无 test/snap 文件1总分 ≥ 4 判为 HIGH≥ 2 判为 MEDIUM否则 LOW。其中CORE_PATHS硬编码为crates/goose/src/agents/、crates/goose/src/providers/、crates/goose/src/acp/、crates/goose-cli/、crates/goose/src/session、crates/goose/src/permission——与配方提示词中的敏感区域划分保持一致。测试说明提取extract_testing_section会识别 PR 描述中的## Testing、## Test Plan、## How Has This Been Tested、## Verification等小节清理 HTML 注释与空复选框后作为“Testing”字段写入报告找不到则标记为No——这本身是 AI 复核阶段的一个风险信号。报告结构每个被评估 PR 一节按风险分降序排列包含作者、审批人、文件统计additions / -deletions、风险因子列表、测试摘要MEDIUM/HIGH PR 额外列出逐文件路径与增删行数并附上 PR 描述前 500 字符便于 QA 直接阅读上下文。命令行参数为--version必填、--pr可显式指定 release PR 号、--repo默认aaif-goose/goose、-o/--output缺省打印到 stdout、--workers。第三步运行 Goose 自测配方清单的第二项动作是goose run --recipe goose-self-test.yamlgoose-self-test.yaml 是一个“元测试”配方让正在运行的 Goose 实例用自己的工具验证自己的能力属于第一人称集成测试。理解它的关键是参数与五个测试阶段。参数参数默认值说明test_phasesall可选all、basic、extensions、delegation、reasoning、acp-effort、advancedtest_depthstandardquick冒烟、standard常规、deep穷尽workspace_dir./gooseselftest测试产物与报告目录parallel_teststrue独立测试尽量并行cleanup_aftertrue完成后清理临时产物配方声明的成功标准是每个阶段 ≥80% 用例通过整个套件全部阶段完成且关键功能可用每个用例遵循 setup → execute → validate → result → cleanup 的记录规范。它绑定了developer600 秒超时、todo、summon、extensionmanager、skills五个内置扩展。测试阶段Phase 1 基础工具验证文件操作创建、str_replace 替换、按行插入、undo、删除重建、Unicode/特殊字符shell 工作流命令链、false || echo handled错误处理、环境变量代码分析多语言结构分析、目录级分析、符号聚焦与调用图、行数/函数/类统计以及若干 Provider 路由校验例如运行cargo test -p goose-providers databricks_v2::tests::gateway_path验证 Databricks AI Gateway 路径配置、验证 Azure AI Foundry 对不同模型的路由策略。若本机没有源码 checkout 或 Rust 工具链这些子项记为 skipped 而非 failed。Phase 2 扩展系统测试todo 扩展的持久化/更新/清空用platform__search_available_extensions发现动态扩展并验证启用/禁用与扩展间隔离。Phase 3 委派与加载测试summon 工具load()无参发现机制、内置技能加载、知识注入同步/异步/并行 delegate、后台任务 MOIM 状态监控、任务取消与清理、基于 source 的委派以及一项关键安全测试——嵌套委派禁止子代理尝试再调用 delegate 工具必须报错对应SessionType::SubAgent的检查逻辑可以在 summon.rs 中看到对session.session_type SessionType::SubAgent的判断若嵌套委派成功则记为 CRITICAL FAILURE。Phase 3C/3D/3E 推理与 ACP 专项多轮 thinking 保留回放测试针对会拒绝reasoning_content回放的 Provider、cargo test -p goose effort验证 ACP thinking-effort 的发现/转发/Provider 切换、cargo test -p goose-sdk --features uniffi --lib observability验证 GDK 可观测性钩子生命周期事件。Phase 4 高级测试错误边界非法路径、不存在的命令、超长文件名、shell 注入与目录穿越等安全输入、deep深度下的大文件与并发性能测量。Phase 5 报告生成产出{{workspace_dir}}/detailed_report.md详细报告并在终端直接打印不超过 30 行的执行摘要总体 PASS/FAIL、各功能 ✓/✗ 清单、问题列表与关键发现。这套自测配方与开发规范是联动的仓库的 AGENTS.md 要求“添加功能时更新 goose-self-test.yaml重建后运行goose run --recipe goose-self-test.yaml验证”。因此发布前跑一遍该配方等于用最新版本对自己做了一次全链路回归。第四步让 Goose 产出并执行测试计划清单的最后一步是把前面两份材料交给 Agent打开 release 候选桌面应用指向 release PR使用如下提示词Look at the notes in PR release PR and the report at/tmp/release_report_final.mdand investigate potential risks in this release. After familiarizing yourself with the scope of each change, produce a suggested test plan that I should follow before publishing the release.Goose 会基于 PR 说明与风险报告输出一份具体测试计划QA 人员按计划完成剩余手工测试重点覆盖报告中标注 HIGH 的 PR 及其“AI concern”关注点全部通过后再按 release PR 中的说明打 tag 发布。小结一条可复现的发布 QA 链路把清单翻译成一条可执行的命令链# 1. 生成风险报告需要已登录的 gh CLI 与 goose 二进制 ./workflow_recipes/release_risk_check/run.sh 1.27.0 # 产物/tmp/release_report_final.md # 2. 跑自测配方可裁剪阶段 goose run --recipe goose-self-test.yaml --params test_phasesall --params test_depthstandard # 3. 打开桌面应用指向 release PR让 goose 基于报告产出测试计划并执行这份清单的设计要点在于把“发布风险”拆成了可计算的启发式部分行数、文件数、核心路径命中、是否有测试与语义复核的 AI 部分架构敏感度、PR 质量信号再以自测配方兜底核心工具链最后以 Agent 生成的测试计划收敛到人工验证——每个环节都有仓库内可查验的脚本与配方作为依据。【免费下载链接】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），仅供参考