发布补丁与渠道回退

需要把 main 上的修复尽快带到稳定版或预览版时，官方提供自动创建补丁 PR 的流程。执行属于 release manager 协调下的维护工作，补丁仍需审阅和验证。

从已合并 PR 创建补丁

维护者可在原已合并 PR 中评论：

评论	目标
/patch	默认同时补 stable 与 preview
/patch both	显式同时补两个渠道
/patch stable	仅 stable
/patch preview	仅 preview

Patch from Comment 会寻找 merge commit SHA 并触发 Patch (1) Create PR。原 PR 未合并时会报告失败。也可手动运行 Create PR，提供 main 上修复的完整 SHA 和 stable/preview 渠道。

自动化创建哪些内容

流程寻找目标渠道最新发布 tag，必要时创建 release 分支，再创建 hotfix 分支，cherry-pick 指定提交，并发起 hotfix 到 release 的 PR。

release 分支受保护，官方要求至少一个 code owner 审阅后才能合并。检查冲突处理、实际差异和测试结果，不把 cherry-pick 自动成功等同于修复在旧版本上正确。

需要组合多个相关修复时，可以在已创建的 hotfix 分支中继续加入提交，更新原补丁 PR 的描述并重新验证。使用 PR 实际分支名，不复制文档中的历史版本示例名称。

合并后发布

合并补丁 PR 后，Patch (2) Trigger 启动 Patch (3) Release，完成构建、测试、npm 新 patch 发布与 GitHub Release 说明。

若出现 Resource not accessible by integration 或引用已不存在的工作流，官方列出的排查方向是旧 release/hotfix 分支中可能保留过时流程。先核对这次运行实际采用的工作流 ref 和权限，再按维护流程修正；不能将特定示例推广成所有 GitHub Actions 事件的统一分支读取规则。

回退或前移 npm tag

Release: Change Tags 将渠道指向一个已经发布到 npm 的版本，不需要为该动作重新完成一次包发布。输入包括 Version、Channel、Dry Run 和 Environment；dry run 默认为 true，prod 需要相应授权。

工作流会为 CLI、core 和 A2A server 对应包更新 dist-tag。核对真实渠道名称；stable 用户安装入口通常是 latest，不应仅凭文档某段的 stable 字样创建另一个预期之外的 tag。

改标签影响后续按该 tag 解析版本的安装，不等于重新编译修复，也不自动改变所有已安装用户的程序。完成后核对包版本和发布验收结果。