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，将每个失败归入根因类别：基础设施问题、代码错误、易出现波动的测试或环境问题。
从知识库中检索相关的历史失败模式，以获取更多背景信息。
通过模型上下文协议 (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 现有的流水线中托管容器化智能体。