Goose 发布清单实战：风险分级、自测配方与 Agent 驱动的 Release QA 流程

Goose 的每次版本发布都依赖一份手工测试清单来把关质量：在 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 环节的操作手册，核心动作有四步：

1. 从 release PR 下载构建包（Actions bot 会在 PR 上评论下载与签名方式）；
2. 运行风险检查脚本，生成风险分级报告与测试计划；
3. 运行 Goose 自测配方 goose run --recipe goose-self-test.yaml；
4. 让 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/）、桌面 UI（ui/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 的核心关注点汇总。

配方声明了唯一的必填参数 version（release 版本号），并绑定 developer 平台扩展以获得 shell 等基础工具能力。

release_risk_report.py：启发式评分规则全解

release_risk_report.py 是 Step 1 的执行者，全部基于 gh CLI 拉取 GitHub 数据。流程与规则如下：

• 定位 release PR：在未提供 --pr 时，列出仓库开放 PR（gh 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 函数，累加制）：

信号	条件	加分
大变更	增删行数 > 500	+2
中等变更	200 < 行数 ≤ 500	+1
多文件	变更文件数 > 10	+1
触碰核心路径	命中 CORE_PATHS	+2
无测试文件	有生产代码变更但无 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.yaml

goose-self-test.yaml 是一个“元测试”配方：让正在运行的 Goose 实例用自己的工具验证自己的能力，属于第一人称集成测试。理解它的关键是参数与五个测试阶段。

参数

参数	默认值	说明
test_phases	all	可选 all、basic、extensions、delegation、reasoning、acp-effort、advanced
test_depth	standard	quick（冒烟）、standard（常规）、deep（穷尽）
workspace_dir	./gooseselftest	测试产物与报告目录
parallel_tests	true	独立测试尽量并行
cleanup_after	true	完成后清理临时产物

配方声明的成功标准是：每个阶段 ≥80% 用例通过；整个套件全部阶段完成且关键功能可用；每个用例遵循 setup → execute → validate → result → cleanup 的记录规范。它绑定了 developer（600 秒超时）、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.md and 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_phases=all" --params "test_depth=standard"

# 3. 打开桌面应用，指向 release PR，让 goose 基于报告产出测试计划并执行

这份清单的设计要点在于把“发布风险”拆成了可计算的启发式部分（行数、文件数、核心路径命中、是否有测试）与语义复核的 AI 部分（架构敏感度、PR 质量信号），再以自测配方兜底核心工具链，最后以 Agent 生成的测试计划收敛到人工验证——每个环节都有仓库内可查验的脚本与配方作为依据。