技术负责人：带过几十个骨干后发现，混得差的技术人，不是能力不行，是学生思维太重

如何画架构图：技术负责人带你画部署架构

架构是权衡和取舍的艺术，架构师的工作就是不断地权衡取舍

技术负责人给年轻人的忠告：努力先成为老板的价值嫡系，再谈其他

技术负责人给年轻人的忠告：将军赶路不追小兔，带过几十个骨干，最后成事的人都懂得这个道理

如何画架构图：技术负责人带你画应用架构

技术负责人给年轻人的忠告：单纯的技术没有价值，成功靠持续的做事

如何画架构图：业务架构的画法

我为什么不建议你做纯架构师

如何画架构图：技术负责人的十年绘图心得二

上一篇写自动驾驶研发流水线时，我提到我们正在花很大力气建设 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年管理路，呆过多家大厂，带过多种规模的技术团队。这里记录技术管理者的真实踩坑与成长。既关注技术管理，也关注技术架构，致力于技术管理和技术架构双线发展。

关注我阅读更多技术管理文章，也欢迎与我私聊职场困惑、职业发展、技术架构等话题。