Rescale 用 AI 开发流程构建测试分诊助手

夜间端到端测试失败后，工程师往往要先翻日志、查历史记录、找代码归属，才能开始修问题。Rescale 用 AI 接手了这轮初筛：判断失败类型、收集证据，再给出供工程师审核的修复建议。

这篇案例值得看的，是他们如何用 AI-DLC 把一个想法拆成可验收的系统：5 天完成预发布验证，数周内进入生产。分类与人工判断的一致率从 44% 提升到 68%，分析测试失败造成的发布阻塞时间减少了 20%。这些结果有价值，也有需要追问的前提。

Agent 接手的是初筛，工程师仍然负责结论

Rescale 的夜间 Playwright 测试套件包含数百个用例，端到端测试通过又是服务进入生产的必要条件。一旦失败，工程师需要在测试报告、日志、历史故障和多个源码仓库之间来回切换。有时还要拉上几个团队，花数小时确认责任归属，才能继续每周的生产发布。

这里适合自动化的，是调试之前那段重复劳动：先确定问题大概属于哪一类，再整理足够的证据，让接手的人能直接开始排查。

他们把 triage agent 放进已有的 Argo Workflows CI/CD 流水线，运行在 Amazon Elastic Kubernetes Service（Amazon EKS）上。夜间测试失败后，流水线触发一个 agent pod，执行几项工作：

• 调用 Amazon Bedrock 上的 Claude Opus 4.8，将失败分为基础设施问题、代码缺陷、不稳定测试或环境问题。
• 从知识库检索历史失败模式，为当前判断补充上下文。
• 通过 Model Context Protocol（MCP）查询 pod 日志，取得运行时证据。
• 生成包含具体文件、函数名和修复建议的结构化报告，交给工程师审核。

原文称，这套流程能在数秒内完成，输出直接进入现有报告流水线。Agent 使用 Strands SDK 构建，支持并发分析失败，并输出 JSON 和 HTML。

这里真正影响可用性的，是报告能否把证据和判断连起来。只写一句「可能是环境问题」，工程师仍然要重新调查；指出相关日志、文件和函数，才有机会减少接手成本。

这个系统自动化的是第一轮排查，修复建议仍需工程师验证。

自动生成 pull request（PR）被明确推迟到后续阶段。原文没有描述自动修改代码或自动合并的能力。

五天交付，靠的是先把问题问具体

Rescale 采用的 AI-Driven Development Lifecycle（AI-DLC），是一套开源、以 AI 为中心的软件开发方法。它要求 AI 生成计划、代码和架构建议，同时把需要判断的地方交给人；遇到需求缺口时，先提出澄清问题。

另一个做法是集中协作。团队通过 Mob Elaboration 一起细化需求，通过 Mob Construction 一起构建系统，AI 负责推进实现。需要产品、架构或运维判断时，相关工程师当场作出决定。

大白话解释，就是把原本可能散落在多轮消息和代码评审里的问题，尽量提前放到同一张桌子上解决。

这次是一个为期 5 天的线下工作坊，由 AWS 架构师指导，Rescale 工程师实际操作。

第 1 至第 2 天，团队先写愿景文档和技术环境文档，再共同回答 AI 提出的 20 多个澄清问题。他们明确了 Phase 1 的边界，把 Phase 2 的需求留到以后，并将 5 个用户故事归并为 4 个工作单元：历史故障知识库、核心 triage agent、Argo Workflow Integration，以及负责准确性测量和回归门禁的 Evaluation Harness。

第 2 至第 4 天，团队确定接口契约、数据结构，以及功能和非功能设计，审核架构后进入实现。到第 4 天，预发布环境已经跑通 Argo 触发、agent pod、MCP 日志查询、知识库检索和结构化输出的完整链路。

第 5 天，重点转向评估和交接。他们搭建了基于 PyTest 的评估框架，支持真实调用和桩替代两种测试模式，并建立初始分类一致率基线。现场演示中，Agent 正确识别了一次基础设施故障和一次真实代码缺陷，还给出了文件级修复建议。

现场演示证明了链路能够工作，但两个案例不能代表整体效果。后续生产数据才是更值得看的证据。

两次架构调整，都在减少额外运维负担

案例里最有参考价值的工程决策，是两次主动收缩架构。

最初，团队计划把 Agent 部署到 Amazon Bedrock AgentCore，后来改为 Amazon EKS。原因很直接：Rescale 已经在 EKS 上运行 Argo Workflows，把 Agent 放进现有集群，既有直接的触发路径，也少了一套需要维护的运行环境。

另一次调整发生在日志获取上。早期方案通过 MCP 接入第三方日志服务，随后改用 Amazon CloudWatch，缩短依赖链。MCP 的调用模式保留，后面的日志来源发生了变化。

这两次调整都经过人工验证，需求和设计决策也同步更新到共享文档里。编码 Agent 因而可以继续依据最新约束实现，减少代码与设计各走各的情况。

设计投入也有区别。知识库使用 Terraform，数小时内完成部署；核心 Agent 则接受完整架构评审、接口契约设计、12 个设计问题和迭代代码评审。Argo 集成重点处理基础设施契约与 IAM，评估框架采用较轻的设计流程，但投入更多实现工作。

这套做法可以理解为：把评审时间花在最可能出错、出错后最难收拾的地方。

Rescale 后续正在把 AI-DLC 用于新工程仿真产品，也应用于 HPC 仿真应用目录管理、面向政府合规要求的容器漏洞跟踪与修复，以及基于工作流的云端编码 Agent。他们还在评估建立内部 AI-DLC Center of Excellence，帮助其他团队采用这套方法。不过，原文没有给出这些扩展项目的量化结果。

我的判断

我认可这个案例的切入点。测试失败初筛有真实输入、历史记录、可核对的人工判断，还能把输出嵌入现有流程，适合逐步验证 AI 的价值。先整理证据、再由人审核，也给模型判断留出了纠错空间。

但几个数字必须分开看。

分类与人工判断的一致率从 44% 升到 68%，不能直接理解为根因识别准确率达到 68%。人工判断是否经过复核、样本有多少、四类失败各占多少，原文都没说清。团队继续迭代黄金数据集和提示词，但没有交代两次测量是否使用同一批独立测试样本。

发布阻塞时间减少 20% 是更贴近工程收益的指标，不过它指的是「分析测试失败期间阻塞生产部署的时间」，不能扩展成整体交付效率提高 20%。统计周期、发布规模和同期流程变化，也没有披露。

分类一致率不必接近满分，系统也可能节省时间，但收益需要单独测量。

这也是它与传统规则分类器、历史错误检索方案应该比较的地方。固定错误码和重复日志模式，可能用规则就能可靠处理；需要跨日志、历史记录和代码理解上下文的失败，才更能体现模型的作用。原文没有给出这些方案的对照数据，也没有披露模型调用费用、误判代价或延迟分布。

同样，作者认为集中协作比独自构建更快，目前只能当作团队经验。此次工作坊有 AWS 架构师参与，问题边界清晰，也有现成的 EKS 和 Argo 基础设施。一般团队能否复现「5 天到预发布」，取决于这些条件。

AI-DLC 最值得借鉴的部分，是把澄清问题、范围边界、接口约束和验收标准留成可审查的文档。至于具体模型和运行平台，应该跟着团队已有环境选择。

能拿来做什么

• 如果团队的 Playwright 测试经常阻塞发布，可以先选一类反复出现的失败，让 AI 汇总日志证据、判断类别并提出建议，再由值班工程师确认。先验证初筛价值，再决定是否扩大范围。
• 给日常编码 Agent 派复杂任务前，先整理技术环境、接口契约、当前阶段边界和验收条件，并让它列出未确定的问题。把需要人工判断的事项解决后，再进入实现。
• 为故障分类保留一套经过人工复核的历史样本，分别记录分类一致率和工程师处理时间。调整提示词或知识库后，用固定样本检查是否退步，避免只看几次成功演示。
• 部署 Agent 时，先评估能否复用现有 CI/CD、容器环境和日志系统。Rescale 的两次调整说明，减少运行环境和外部依赖，也可能比增加组件更有助于交付。