Rescale 基于 Strands Agents 与 AI-DLC 五天构建测试失败分诊智能体

每个工程团队都熟悉这套流程，Rescale 也不例外。夜间测试套件失败了。值班工程师拉取日志、对根因进行分类，并将其转给合适的团队，然后第二天早上再重复一遍。在规模化场景下，面对分布式服务和数十个代码仓库，这套流程成了隐藏在值班轮换里的全职工作。

Rescale 是为 AI 时代打造的数字工程平台。航空航天、汽车、能源、生命科学、半导体和制造领域的研发与工程团队使用 Rescale 平台加速创新，将智能 HPC、先进建模与仿真、智能体数字工程和 AI 物理仿真汇聚到单一平台上。

除了编码之外，Rescale 还在整个工程生命周期中使用 AI，从规划和设计，到实现、测试、评审和运营，同时让工程师对结果负责。AI 可以提出建议并执行，但人负责定义范围、验证工作成果并批准生产变更。这样，工程师就可以专注于架构、产品判断以及运维复杂分布式系统所需的上下文。

在这篇文章中，我们展示了 Rescale 如何在 AWS 上使用 AI 驱动的开发生命周期（AI-DLC）框架构建一个智能分诊智能体。他们从问题定义到预发布部署只用了五天，几周内便进入了生产环境。本文还介绍了 Rescale 如何在他们的整个工程组织中推广 AI-DLC。

面临的挑战

随着 Rescale 平台规模的扩大，维持其运行的运维开销也随之增长。工程师们把大量时间花在一项重复但至关重要的任务上：对自动化端到端测试失败进行分类。套件中运行着数百个测试用例，一旦出现失败，每一条警报、缺陷报告和升级请求都需要被分类、排定优先级并转给合适的团队。转派之后，工程师还需要从多个日志和监控系统以及多个源代码仓库中收集证据，然后才能开始调试。端到端测试通过是将服务部署到生产环境的必要条件，因此调试这些系统故障是让新变更进入生产环境的关键路径。

在人工流程中，工程师需要在测试报告、日志、历史模式和源代码之间来回切换，对失败进行分类并找出可能负责的团队。由于这些集成测试是每周生产发布的门槛，未解决的失败可能会让多个团队陷入数小时的协调，部署才能继续进行。

团队对解决方案的形态有清晰的认识：一个能够自动分类和转派问题的智能体。他们需要的是一种结构化的方法，把这个认识变成生产环境中可运行的系统，并且这种结构要足以在之后将该方法扩展到其他用例。

Rescale 为何选择 AI-DLC

Rescale 的分诊智能体是一个范围明确、时间紧迫的问题。团队需要一种能够跟上这种节奏的开发方法，同时又不能跳过那些决定系统能否在生产环境中正常运行的架构决策。

AI 驱动的开发生命周期（AI-DLC）是一种开源的、以 AI 为中心的软件开发方法论，它围绕两个核心理念构建：

AI 执行，人类决策：AI 生成工作计划、编写代码并提出架构，但它会呈现决策点并提出澄清问题，而不是自行猜测。人类在每一步进行验证和引导。
团队会话取代异步交接：不再是单人独自构建、之后再请求评审，AI-DLC 采用聚焦的群组会话：Mob Elaboration（共同定义需求）和 Mob Construction（共同构建，由 AI 负责实现）。决策实时完成。

AI-DLC 之所以契合，是因为难点不在于编写代码，而在于确保 AI 理解团队想要构建什么。在群组会话中，Rescale 的工程师共同回答 AI 的问题，并在 AI 继续之前批准每个计划，因此不会留下任何假设的空间。

解决方案概览

Rescale 的分诊智能体自动对每夜端到端测试失败进行分类和路由。它作为 Rescale 现有 Argo Workflows 持续集成与持续交付（CI/CD）流水线中的一个步骤，运行在 Amazon Elastic Kubernetes Service（Amazon EKS）上。当每夜的 Playwright 测试套件中数百个测试用例出现失败时，流水线会触发分诊智能体 pod。

该智能体执行以下步骤：

调用 Amazon Bedrock 上的 Claude Opus 4.8，将每个失败分类到根本原因类别：基础设施问题、代码缺陷、不稳定测试或环境问题。
从知识库中检索相关的历史失败模式，以获取额外上下文。
通过 Model Context Protocol（MCP）查询 pod 日志，获取支持分类的运行时证据。
生成包含具体文件引用、函数名称和推荐修复方案的结构化整改报告，供工程师在采取任何行动之前审查。

该智能体在几秒钟内完成此工作流，并直接输出到团队现有的报告流水线中。下图展示了这些组件如何协同工作：

图 1：Rescale 的 AI 分诊智能体架构，运行在 Amazon EKS 上，使用 Amazon Bedrock 进行分类，使用知识库存储历史失败模式，并通过 Amazon CloudWatch 集成进行基于 MCP 的日志检索

AI-DLC 研讨会体验

此次合作以为期五天的现场研讨会形式组织。AWS 架构师指导构建，Rescale 的工程师亲自动手，实时共同构建。

起始阶段（第 1–2 天）：从愿景到经过验证的需求

团队首先确定需求范围，将意图记录在愿景文档和技术环境文档中，在开始任何构建之前奠定基础。这一意图最初只是一句话：“我们想要由 AI 驱动的测试分诊，能够对失败进行分类并推荐整改方案”。团队以群组形式协作，回答了 AI 生成的 20 多个澄清问题。最终产出了一份范围明确的需求文档，其中明确界定了第一阶段（Phase 1）的边界，并将第二阶段（Phase 2）的事项延后。五个用户故事被整合为四个工作单元：

用于历史失败模式的知识库。
AI 分诊智能体，作为核心的分类与整改引擎。
Argo Workflow 集成，用于触发、基础设施和部署。
评估套件（Evaluation Harness），用于准确度测量和回归门禁。

人类决策决定了关键边界：哪些内容属于第一阶段还是第二阶段、优先级排序，以及延后的功能（如自动生成拉取请求（PR））。

构建阶段（第 2–4 天）：从架构到可运行的代码

团队定义了接口契约和数据模式，完成了功能性与非功能性设计问题，并签署确认了架构。在构建过程中出现了两次架构转向，团队在每次改变方向之前都进行了验证。

首先，团队原本计划将智能体托管在 Amazon Bedrock AgentCore 上，随后将其迁移到 Amazon EKS，Rescale 的 Argo Workflows CI/CD 流水线已经在那里运行。将智能体保留在现有集群中意味着无需运维新的运行时环境，并且可以从 Argo 直接触发。其次，在早期构建中，智能体通过 MCP 从第三方日志服务中提取日志证据。团队将日志检索迁移到了 Amazon CloudWatch，这简化了依赖链。MCP 模式保持不变，只是其背后的数据源发生了变化。由于 AI-DLC 将需求和设计决策保存在共享文档中，团队就地更新了这些文档，并在不丢失上下文的情况下继续构建。

该智能体使用 Strands SDK 构建，支持并发故障分析，并以 JSON 和 HTML 格式输出结构化结果，容器化部署在 Amazon EKS 上。

到第 4 天，完整流水线已在预发布环境中运行：Argo 工作流触发、分诊智能体 Pod、MCP 日志查询、知识库检索以及结构化的分诊输出。

运维阶段（第 5 天）：评估与交接

团队构建了一个基于 PyTest 的评估框架，包含实时和桩（stub）两种测试模式，建立了一个初始的分类一致性基线，用于衡量智能体并持续改进。团队向 Rescale 的 CTO 和工程副总裁现场演示了该智能体，它正确分类了一次基础设施故障和一个真实的代码缺陷，并给出了具体到文件级别的修复建议。

AI-DLC 如何将严谨性匹配到复杂性

并非每个工作单元都得到相同的对待。知识库只需极少的设计，并在几小时内使用 Terraform 完成部署。分诊智能体则得到了完整的严谨流程：架构评审、接口契约、12 个设计问题以及迭代式代码评审。Argo 集成聚焦于基础设施契约和 IAM。评估框架采用轻量设计但重视实现。AI-DLC 自动将深度与复杂性相匹配。

到第 5 天结束时，该智能体已在预发布环境中上线，能够处理真实的测试失败，并拥有经测量的准确率基线和清晰的上线路径。

生产成效

自研讨会以来，该分诊智能体一直在生产环境中运行。它自动对每夜端到端测试的失败进行分类，用工程师验证的自动化首轮分诊取代了人工首轮分诊。对于每次失败，智能体会生成一份结构化的修复报告，其中包含可执行的后续步骤，而不是原始日志。智能体与人工分诊的分类一致率已从最初部署时的 44% 提升至今天的 68%。随着团队持续迭代黄金数据集和提示词工程，它还在不断改进。

自分诊智能体进入生产环境以来，团队测量到在分析测试失败期间阻塞生产部署的时间减少了 20%。由于这些测试是 Rescale 每周生产发布的门禁，这一缩短直接体现在变更到达生产环境的速度上。工程师在值班轮换中花在重复性分类上的时间也减少了。

研讨会之后的生活：从单个智能体到 AI 优先的实践

这次研讨班交付了一个生产级智能体，但其更大的影响在于改变了 Rescale 开展工程工作的方式。这个分流智能体是 Rescale 面向 AI 时代提供数字工程能力这一更大战略的一部分。在公司内部，Rescale 正将 AI 所带来的这些益处应用于其自身的工程组织。AI-DLC 为 Rescale 的工程师提供了一种结构化、可重复的方式来将这一方向付诸实践。

在整个组织中推广 AI-DLC

Rescale 正在评估建立一个内部 AI-DLC 卓越中心，这是一个小型团队，负责总结最佳实践，并帮助其他团队独立采用该方法论。

参与的工程师们已经在应用他们所学到的东西。其中一位工程师指出，这一流程“将成为我今后工作流的一部分”，不仅适用于构建智能体，也适用于任何 AI 能够发挥作用的复杂开发工作。

更广泛的 AI 原生开发

Rescale 目前正将 AI-DLC 融入新工程仿真产品的标准软件开发生命周期。该框架将仿真领域的专业知识、产品需求、平台架构、验证和运营整合到一个结构化的设计流程中。团队尽早解决关键问题，将经过评审的决策记录在可执行规范中，并让编码智能体专注于目标明确、验收标准清晰的工作。这缩短了从产品概念到经过验证的实现之间的路径，同时工程师仍然对产品的正确性负责。

同样的方法已经被用于产品赋能平台工作和智能体系统中：

HPC 仿真应用目录管理。
面向政府合规要求的容器漏洞跟踪与修复。
基于工作流的云端编码智能体。

结论

对于分流智能体而言，AI-DLC 最有价值的产出并非代码本身，而是从最初想法到经过评审的系统设计之间的结构化路径：澄清问题、划定范围的需求以及评估标准。

这份规范为编码智能体提供了一个更窄、定义更清晰的问题去解决。团队无需让智能体在实现架构的同时去推断架构，而是可以让智能体专注于根据人类已经评审过的决策进行构建。其结果是输出更加聚焦、更易于评审，也更容易集成和改进。对 Rescale 来说，这就是可重复的模式：使用 AI-DLC 来组织设计讨论，将决策转化为规范，然后使用编码智能体加速实现。

核心要点

从一个真实的问题开始。Rescale 的分流智能体之所以成功，是因为它解决了一个实际的工程挑战。是问题驱动了解决方案，而不是相反。
人类监督是加速而非减速。每一次改善系统的架构调整都来自人类对 AI 提案所做的验证。这种由 AI 生成、由人类验证的群组协作模式，比独自工作更快。
AWS 技术栈提供了智能体所需的每一层能力。Amazon Bedrock 在 Rescale 已在使用环境中提供了用于分类的基础模型访问，因此团队能够构建分流工作流，而无需承担额外的模型基础设施开销。Strands SDK 提供了智能体框架，Amazon EKS 则在 Rescale 现有的流水线中托管了容器化的智能体。

开始使用 AI-DLC

了解方法论：阅读 AI-DLC 介绍博客和自适应工作流深度解析。
探索该服务：了解更多关于 Amazon Bedrock 的信息。
立即尝试：克隆开源的 AI-DLC 工作流规则，地址为 github.com/awslabs/aidlc-workflows。
查看实际应用：逐步了解使用 Amazon Q Developer 的 AI-DLC 实战构建。
建立联系：联系您的 AWS 客户团队，探讨如何将 AI-DLC 定制化以适配您组织特定的工程工作流。