发布质量门禁 Agent：不是替 QA 拍板，而是把证据链收齐

发布前最怕的不是发现问题，而是证据不完整。

自动化跑了没有？失败是不是已知问题？核心接口有没有回归？APP 主流程有没有真机确认？服务端错误日志有没有新增？灰度监控有没有异常？历史缺陷有没有覆盖？这些信息如果散在 CI、测试平台、日志平台、群消息和人工备注里，QA 最后只能靠记忆做判断。

发布质量门禁 Agent 的价值不是替 QA 说“能不能发”，而是把发布前必须看的证据收齐、归类、标出缺口。

这对应哪类 QA 工作

它覆盖功能测试、接口测试、UI 自动化、APP/小程序测试和服务端测试。

功能测试需要确认：

• 需求验收点是否完成
• 主流程是否通过
• 历史缺陷是否回归
• 风险项是否有解释

接口测试需要确认：

• 核心接口是否回归
• 错误码和字段兼容是否确认
• 契约或请求响应变更是否评审

UI 自动化需要确认：

• 冒烟是否通过
• 失败是否已分诊
• 截图差异是否有结论

APP/小程序测试需要确认：

• 真机主流程是否通过
• 授权、支付、分享、弱网是否覆盖
• 平台差异是否记录

服务端测试需要确认：

• 日志是否有新增异常
• trace 是否有异常耗时
• 消息、缓存、定时任务是否正常
• 灰度指标是否稳定

原来怎么做

很多发布前检查是这样的：

• QA 在群里问自动化结果
• 去 CI 看测试报告
• 去测试平台看用例状态
• 去日志平台查错误
• 问开发是否有已知风险
• 问产品是否验收通过
• 手工整理发布备注

这不是技术能力问题，而是证据分散。

一旦发布节奏快，最容易漏掉：

• 某个失败用例没分诊
• 某个历史缺陷没回归
• 某个灰度异常没解释
• 某个端没有真机确认
• 某个接口变更没有兼容结论

Agent 具体接管哪一步

发布质量门禁 Agent 应该接管“证据收集和缺口标记”。

它不应该直接给“允许发布”。

输入可以是：

发布单：
需求列表：
PR 列表：
自动化报告：
手工用例结果：
缺陷列表：
日志/trace 摘要：
灰度监控：
历史风险项：

输出固定成：

已通过证据：
失败但有解释：
阻塞风险：
证据缺口：
需要人工确认：
建议补充检查：

重点是“证据缺口”。

一个好的门禁 Agent 不应该只会总结已完成事项，更要指出哪些还没被证明。

一个具体发布场景

假设一个订单模块发版，涉及：

• 订单确认页 UI 调整
• 优惠试算接口变更
• 服务端缓存策略调整
• 小程序入口文案调整

发布前，门禁 Agent 应该收集：

功能验收：订单确认主流程通过
接口回归：优惠试算接口 happy path 通过
UI 自动化：Web 冒烟通过，截图差异已确认
小程序：真机验证缺失
服务端：缓存命中日志正常，但未验证缓存失效
历史缺陷：优惠叠加金额错误已回归
阻塞风险：无
证据缺口：小程序入口、缓存失效、灰度错误率

QA 看到这份结果，就知道不是“都测完了”，而是“还有三个地方需要补证据”。

技术实现建议

第一阶段，用 Markdown 表格就够。

每次发布收集一份：

检查项 | 证据链接 | 状态 | 负责人 | 缺口 | 结论

第二阶段，接入只读工具。

可以读取：

• CI 结果
• 测试报告
• 缺陷列表
• 日志摘要
• trace 摘要
• 灰度指标截图

第三阶段，再生成门禁报告。

报告必须区分 4 类：

• 通过
• 失败但有解释
• 缺证据
• 阻塞

不要把“未检查”写成“正常”。

和 CI 的关系

CI 只能告诉你某些自动检查通过或失败。

发布质量门禁更关心“证据是否足够”。

GitHub Actions 这类 CI 可以上传构建和测试产物，便于后续调试、覆盖率查看和失败定位。但 QA 的发布判断通常还需要手工验收、端侧确认、业务风险和灰度观察。

所以 Agent 应该聚合 CI 证据，而不是把 CI 结果等同于质量结论。

最小验证：先做一个发布证据表

不用接平台。

选最近一次小版本，手工准备这些材料：

• 发布单
• 自动化报告链接
• 手工验收结果
• 缺陷列表
• 关键接口回归结果
• 日志/trace 摘要
• 灰度观察记录

让 Agent 输出一份门禁报告。

你只检查：

• 有没有把缺证据写出来
• 有没有区分失败和阻塞
• 有没有把已知问题写清楚
• 有没有提醒人工确认
• 有没有把推测写成事实

如果它能减少 QA 发布前四处找证据的时间，就有价值。

风险边界

门禁 Agent 不能替 QA 做最终决策。

它不能决定：

• 是否允许发布
• 是否接受某个风险
• 是否回滚
• 是否跳过端侧验证
• 是否忽略线上异常

它能做的是：

• 收集证据
• 标记缺口
• 归类风险
• 生成待确认清单
• 给 QA 一份可审查的发布材料

总结

发布质量门禁 Agent 不应该是“自动审批器”。

它更像 QA 的证据秘书：把测试结果、失败解释、缺陷状态、日志摘要、灰度观察和历史风险收拢到一张表里。

真正的价值是让发布判断从“凭印象”变成“看证据”。

高级 QA 需要的不是模型替自己拍板，而是在拍板之前，确保没有关键证据被漏掉。

参考资料

• GitHub Actions Artifacts：https://docs.github.com/en/actions/tutorials/store-and-share-data
• Playwright Trace Viewer：https://playwright.dev/docs/trace-viewer
• OpenTelemetry Traces：https://opentelemetry.io/docs/concepts/signals/traces/