Agent驱动的自动化回归如何为自动驾驶研发流水线兜底
- 2026-07-25 17:40:53
技术负责人：带过几十个骨干后发现，混得差的技术人，不是能力不行，是学生思维太重
技术负责人给年轻人的忠告：努力先成为老板的价值嫡系，再谈其他
技术负责人给年轻人的忠告：将军赶路不追小兔，带过几十个骨干，最后成事的人都懂得这个道理
技术负责人给年轻人的忠告：单纯的技术没有价值，成功靠持续的做事
上一篇写自动驾驶研发流水线时，我提到我们正在花很大力气建设 Agent 驱动的自动化回归平台，为整个自动驾驶流水线兜底。
这件事为什么重要？
因为 Agent 已经可以分析告警、修改代码、生成 PR，甚至继续触发部署。
但代码修复完成以后，哪些用例需要执行、测试现场如何恢复、失败到底是谁的问题、这次变更能不能继续发布，仍然需要一套质量保障机制。
当编码效率大幅提升，而质量保障手段通过原始、手动点点点，我们面临大量pr积压，不能/敢发布到线上的尴尬处境。
这就是自动化测试 Agent 在自动驾驶研发工作流里的位置。
它负责用例构建、用例审核、执行编排、结果评测和报告生成。
自动化测试平台继续负责用例池、人工 Review、用例版本和批量黑盒执行。
两者分工清楚以后，自动化回归才能作为一个独立步骤，追加到 PR、告警修复、发布、灰度和配置变更等研发工作流后面。
为什么现有自动化测试接不住 Agent 研发工作流
这里以一套智能客服系统为例。
一次功能或配置变更，可能同时影响 Prompt、模型输出、多轮交互策略、工具调用、工作流节点、变量写入、知识检索、人工接管、外部通知、业务回调和最终指标。
服务实例配置、环境配置、模型配置、实验策略和功能开关也会影响运行结果。
如果自动化测试仍然依赖人工维护 case、人工拖拽执行和人工判断覆盖，会遇到几个直接问题：
回归用例构建和维护成本很高
线上真实的长尾场景难以进入回归集
历史用例默认使用当前配置，容易因为服务配置或环境配置变化而误失败
告警修复完成后，事故样本很难稳定沉淀为后续回归资产
自动化测试平台解决了批量执行问题，却没有自动完成用例构建、上下文恢复、结果评测和失败归因。
自动化测试 Agent 补的是这部分能力。
先把三套系统的边界划清楚
方案里有一个关键前提：自动化测试 Agent 不替代研发工作流平台，也不替代自动化测试平台。
研发工作流issueops平台负责 Issue、告警、PR、发布事件和配置变更等入口。它汇聚 PRD、代码、日志、配置和 CI/CD 上下文，决定什么时候触发测试、什么时候等待人工确认，以及结果回写到哪里。
自动化测试 Agent 负责决定构建什么用例、审核哪些用例、从用例池选择哪些用例、如何恢复运行上下文、如何评测结果，以及如何生成报告和门禁建议。
自动化测试平台继续维护用例池、用例版本、人工 Review、批量执行、并发、排队、重试、超时、执行结果和历史记录。
用例执行对 Agent 黑盒化。
Agent 通过平台 API 创建执行任务、查询进度、拉取结果和证据索引。
它不需要了解平台内部怎样调度每一条 case，也不再自建独立用例库和批量执行引擎。
自动化测试平台是用例资产和执行结果的事实源。Agent 是连接研发工作流与测试平台的智能层。
用例构建和用例执行必须分开
整个方案被拆成两个完全独立的业务场景。
用例构建场景只负责产出和维护高质量用例。它从线上真实流量、PRD、技术方案和代码变更中生成候选用例，经过审核以后录入自动化测试平台。
用例执行场景不临时生成用例。它只从平台用例池拉取已有用例，恢复运行上下文，向平台下发批量执行任务，再完成结果评测和报告生成。
这样拆开的原因很明确。
构建用例是一项持续进行的资产建设工作。
执行用例是一项可以被 PR、发布、灰度或告警修复随时触发的质量验证工作。
两者混在一起，每次执行都会临时造一批 case，用例池无法沉淀，历史结果也无法复用。
构建链路不直接触发执行，只产出审核后的用例资产。执行链路不临时造用例，只消费平台用例池。
回归用例只从线上真实行为中构建
方案对回归用例来源做了一个明确限制：只从线上环境构建。
回归用例构建 Agent 会拉取生产日志、用户交互记录、场景日志、工具调用记录、回调记录和必要的业务状态记录。
再通过任务标识和链路追踪，把 Prompt、工具调用、关键日志、模型输入输出、完整交互过程和最终业务结果关联起来。
用户会话尽量保留完整轨迹。
线上真实工具调用可以作为初始 Oracle，但不能直接被当成正确答案。候选用例还要经过审核 Agent，检查来源证据、预期工具调用、节点路径、最终状态和评测规则是否可信。
审核 Agent 还要检查重复度、覆盖价值、可执行性和合规性。联系方式、客户信息、原始内容地址和请求标识等敏感信息，进入用例池前必须脱敏或引用化处理。
审核通过以后，用例才会进入自动化测试平台，接受人工 Review、版本管理和后续批量执行。
运行快照决定历史用例能不能复现
对智能客服系统来说，保存交互内容和日志还不够。
同一条用例在不同服务实例、环境配置、模型配置或功能开关下执行，可能得到完全不同的结果。
因此，回归用例构建时要同步保存运行上下文快照，包括：
服务实例快照
环境配置快照
配置中心快照
模型配置、实验策略和关键开关
用于一致性校验的上下文校验值
执行 Agent 拉取用例以后，要先读取服务实例、环境配置和配置中心的快照标识，在目标环境恢复对应上下文，再校验上下文校验值。
执行完成后，还要记录实际使用的配置版本、恢复方式和差异检查结果。
历史用例不能默认绑定最新生产配置。如果功能需求已经改变了服务行为，应由用例构建场景迁移或重建用例，而不是由执行 Agent 强行拿最新配置执行旧用例。
新功能不仅生成新用例，也会改变旧回归集
功能测试用例来自 PRD、技术方案、代码 Diff、接口协议、配置变更和验收标准。
功能测试用例生成 Agent 会提取正常路径、边界条件、异常路径和高风险动作，生成输入脚本、变量、预期工具调用、预期节点路径、最终状态和评测规则。
但它的工作不止是新增功能用例。
一个新功能可能改变已有业务行为，也可能让原来的回归用例失效。构建 Agent 还要检索相关回归用例和黄金用例，判断旧用例需要怎样处理：
新功能引入新路径，新增回归用例
原有节点路径、工具参数或最终状态变化，修订旧用例
旧行为已经废弃，将原用例标记为 deprecated
旧用例覆盖范围太粗，拆成多个更稳定的用例
适用服务实例、场景、节点或配置变化，迁移用例集、标签和上下文快照
变更没有触达原回归点，保留用例并记录影响分析结论
这些建议不能直接修改用例池。
它们要形成回归集变更记录，交给用例审核 Agent 审核，存在业务争议时再进入人工 Review。
执行 Agent 只负责编排平台执行
用例执行场景可以追加在 PR、发布、灰度、告警修复和配置变更等研发工作流后面。
执行 Agent 接到触发请求后，会根据变更范围、风险等级、用例标签、服务实例、场景和执行环境，从自动化测试平台选择用例集合。
随后恢复服务实例、环境配置和模型配置上下文，校验上下文校验值，再向自动化测试平台下发批量执行任务。
批量执行、并发、排队、限速、超时、重试、取消、环境隔离和高风险动作隔离，仍由自动化测试平台负责。
执行 Agent 只监控排队、运行中、成功、失败、超时和取消等状态，最后获取执行任务标识、用例结果、失败原因、链路追踪标识、日志时间窗和证据索引。
这些结果会继续交给用例评测 Agent，而不是直接根据平台显示的成功或失败决定是否发布。
失败必须先归因，再决定是否阻断
测试失败归因与门禁决策
方案里要求失败归因至少覆盖七种类型：
产品问题：产品逻辑、模型输出、工具调用、节点流转或配置行为不符合预期
测试平台问题：自动化测试平台执行、排队、回调或结果持久化异常
执行环境问题：预发或生产环境、依赖服务、权限或限流导致失败
上下文恢复问题：服务实例、环境配置、配置中心数据或模型配置恢复不一致
用例定义问题：输入脚本、变量、依赖数据、执行参数或用例格式有问题
预期规则问题：预期工具、参数、节点路径、最终状态或文本规则定义错误
负向用例按预期通过：用例按预期失败或按预期被拒绝，业务评测结论为通过
用例定义问题和预期规则问题要回灌到用例构建与审核链路，生成用例修订任务。
它们默认不应该被当成产品失败，但也不能直接自动放行。当前测试结论需要进入人工复核，修订用例以后再补跑。
负向用例也不能只看平台状态。某条用例本来就在验证系统应拒绝越权内容、不触发工具或停留在原节点，平台显示 failure，业务结论可能是 pass。
测试报告必须把执行状态、失败归因和业务结论分开。
高风险动作以规则审核为主
规则审核与 AI 审核的双评测机制
用例评测分为规则审核和 AI 审核。
规则审核处理确定性结论，包括工具是否触发、参数是否正确、禁止工具是否未触发、节点是否正确流转、最终状态是否符合预期，以及延迟和错误率是否超过阈值。
AI 审核处理开放文本、意图理解、知识贴合、话术自然度和需求语义是否满足。
结束服务、转接人工、发送外部通知、调用外部接口和退出工作流等高风险动作，必须以规则审核为主，AI 审核只能辅助。
如果规则审核与 AI 审核发生冲突，高风险场景按规则结果处理，并进入人工复核。
评测完成后，报告生成 Agent 要回答几个明确问题：
为什么触发本次测试
从用例池选择了哪些用例，没选哪些用例
执行环境是预发还是线上
使用了哪个服务实例、环境和配置中心快照
哪些失败属于产品、平台、环境、上下文或用例问题
哪些负向用例属于按预期失败
是否阻断发布，是否需要重试或人工复核
下一步应该修代码、改配置、修用例、补证据还是回灌构建链路
最终门禁结论写回 Issue、PR、CI/CD、发布系统或灰度流程。
告警修复怎样接入这套回归链路
告警触发后进入 Issue 系统，Agent 编排器读取任务并执行告警处置工作流，生成 PR，部署到流水线，再追加用例执行场景。
自动化测试 Agent 拉取生产日志、用户交互记录、链路追踪数据、配置变更和运行快照，构建故障用例。
用例经过审核以后进入自动化测试平台。修复完成后，执行 Agent 选择相关用例，恢复上下文并触发平台批量执行。
评测 Agent 使用规则审核和 AI 审核判断结果，报告 Agent 把结论写回 Issue、PR 和 CI/CD。
验证不通过，工作流继续修复。验证稳定通过以后，高价值故障用例可以晋升为黄金用例，持续守住这类问题。
这样，一次线上告警不会只留下修复代码。它还会留下可复现的用例、运行快照、失败证据和后续质量门禁。
第一阶段先跑通一个高风险动作专项
方案最终会覆盖回归用例、功能用例、执行编排、结果评测、报告、覆盖度和用例演进。但第一步不需要同时建设所有能力。
可以先做高风险动作专项，优先覆盖结束服务、转接人工、退出工作流、发送外部通知和调用外部接口。
选择一个真实 PR 或告警修复工作流，完成以下链路：
从生产日志、用户交互记录和关键证据中构建回归用例
抓取服务实例、环境和配置中心快照
通过用例审核 Agent 检查证据、Oracle 和可执行性
将审核后的用例录入现有自动化测试平台
修复或变更完成后，在预发环境触发批量执行
使用规则审核与 AI 审核完成失败归因
将门禁结论、失败证据和人工复核建议写回原工作流
把用例定义、Oracle 和上下文问题重新回灌到构建链路
这条链路跑通以后，再逐步接入发布、灰度和配置变更，持续补充覆盖度与黄金用例管理。
自动驾驶研发需要一套可解释的质量验证层
自动化测试 Agent 的定位很明确。
它不取代研发工作流平台，不取代自动化测试平台，也不替代人工对高风险变更负责。
它把线上真实行为、功能需求、运行快照、现有用例池和研发工作流连接起来，让测试用例能够自动构建、审核、选择、执行、评测和回灌。
当一次 PR、告警修复、发布或配置变更完成后，系统能够回答执行了哪些用例、使用了什么上下文、失败发生在哪里、证据是什么、是否需要阻断，以及下一步由谁处理。
这套质量验证能力跑稳以后，自动化回归才能成为自动驾驶研发工作流里真正可复用的一步。
这里忽略大量落地过程中的细节，先提供一种思路，只为抛砖引玉，更多实践细节后面单独开篇。
13年技术路，6年管理路，呆过多家大厂，带过多种规模的技术团队。这里记录技术管理者的真实踩坑与成长。既关注技术管理，也关注技术架构，致力于技术管理和技术架构双线发展。
关注我阅读更多技术管理文章，也欢迎与我私聊职场困惑、职业发展、技术架构等话题。
