Rescale 如何用 Strands Agents 和 AI-DLC 构建 AI 分诊智能体

每个工程团队都熟悉这套仪式，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 多个澄清性问题。这产出了一份范围明确的需求文档，其中明确界定了第一阶段边界，并将第二阶段事项推迟。五个用户故事被整合为四个工作单元：

用于历史失败模式的知识库。
作为核心分类与修复引擎的 AI 分诊代理。
用于触发、基础设施和部署的 Argo Workflow 集成。
用于准确性度量和回归门禁的评估框架。

人类决策推动了关键边界：哪些属于第一阶段、哪些属于第二阶段、优先级排序，以及推迟的功能（如自动生成拉取请求（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 的评估框架，支持实时和桩测试两种模式，并建立了初始的分类一致率基线，用于衡量智能体表现并据此改进。智能体向 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 现有的流水线中托管了容器化智能体。