每个工程团队都熟悉这套流程，Rescale 也不例外。夜间测试套件失败了。值班工程师拉取日志、对根本原因进行分类，并将其转给正确的团队，第二天早上又要重复同样的过程。在分布式服务和数十个代码仓库的规模下，这套流程变成了藏在值班轮换中的一项全职工作。
Rescale 是为AI时代打造的数字工程平台。航空航天、汽车、能源、生命科学、半导体和制造领域的研发与工程团队使用Rescale平台加速创新，将智能HPC、先进建模与仿真、智能体数字工程以及AI物理整合到单一平台上。
除了编码之外，Rescale 在整个工程生命周期中使用 AI，从规划和设计到实施、测试、评审和运维，同时让工程师对结果负责。AI 可以提出建议并执行，但由人来定义范围、验证工作并批准生产变更。工程师因此可以专注于架构、产品判断以及运营复杂分布式系统所需的上下文。
在这篇文章中，我们展示了 Rescale 如何使用 AI驱动的开发生命周期（AI-DLC） 在 AWS 上的框架来构建一个智能分诊智能体。他们从问题定义到预发布部署仅用了五天，几周内便上线生产环境。这篇文章还介绍了 Rescale 如何在整个工程组织中推广 AI-DLC。
挑战
随着Rescale平台的成长，维持其运行的操作开销也在不断增加。工程师们花费大量时间处理一项重复但至关重要的任务：对自动化端到端测试失败进行分类。测试套件中运行着数百个测试用例，当出现失败时，每一条警报、错误报告和升级事项都需要被分类、排定优先级，并路由到正确的团队。路由完成后，工程师还需要从多个日志和监控系统以及多个源代码仓库中收集证据，然后才能开始调试。端到端测试通过是将服务部署到生产环境的必要条件，因此调试这些系统故障是让新变更进入生产环境的关键路径。
在手动流程中，工程师需要在测试报告、日志、历史模式和源代码之间来回查证，以对故障进行分类并找出可能的责任团队。由于这些集成测试是每周生产发布的门禁，未解决的故障可能会让多个团队卷入数小时的协调工作，之后部署才能继续进行。
团队对解决方案的形态有清晰的认识：一个能够自动分类和分派问题的智能代理。他们所寻找的是一种结构化的方法，将这种理解转化为生产环境中可运行的系统，并具备足够的结构性，以便日后将该方法扩展到其他用例。
Rescale 为何选择 AI-DLC
Rescale 的分诊代理是一个范围明确且时间紧迫的问题。团队需要一种能够跟上这种节奏的开发方法，同时又不跳过那些决定系统能否在生产环境中正常运行的架构决策。
该 AI 驱动的开发生命周期 (AI-DLC) 是一种以开源、人工智能为中心的软件开发方法论，围绕两个理念构建：
- AI负责执行，人类负责决策：AI生成工作计划、编写代码并提出架构，但它会呈现决策点并提出澄清性问题，而不是自行猜测。人类在每一步进行验证和引导。
- 团队会议取代异步交接：AI-DLC 不再由一个人独自构建、之后再请求评审，而是采用聚焦的团队会议：Mob Elaboration（共同定义需求）和 Mob Construction（在 AI 处理实现的同时共同构建）。决策实时完成。
AI-DLC 之所以适用，是因为难点不在于编写代码，而在于确保 AI 理解团队想要构建的内容。在 mob 会议中，Rescale 的工程师共同回答 AI 的提问，并在 AI 继续推进之前批准每个计划，因此不会留下任何靠假设推断的空间。
解决方案概述
Rescale 的分诊代理（triage agent）自动完成对夜间端到端测试失败的分类和路由。它作为 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驱动的测试分诊，对失败进行分类并推荐修复方案”。团队以群体协作（mob）的方式回答了AI生成的20多个澄清问题。这产出了一份有明确范围的需求文档，其中Phase 1的边界被明确界定，Phase 2的事项被延后处理。五个用户故事被整合为四个工作单元：
- 历史故障模式知识库。
- AI分类代理作为核心分类和修复引擎。
- 用于触发、基础设施和部署的 Argo Workflow 集成。
- Evaluation Harness（评估工具），用于准确性测量和回归把关。
人类决策决定了关键边界：哪些内容属于 Phase 1、哪些属于 Phase 2、优先级排序，以及推迟的功能（如自动化拉取请求（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 完成部署。Triage Agent（分诊智能体）则获得了完整的严谨流程：架构评审、接口契约、12个设计问题以及迭代式代码评审。Argo 集成聚焦于基础设施契约和 IAM。Evaluation Harness 采用轻量设计但重度实现。AI-DLC 自动地将深度与复杂度相匹配。
到第5天结束时，该智能体已在预发布环境中上线，处理真实的测试失败，具备了实测的准确性基线和清晰的生产路径。
生产成果
该分诊智能体自研讨会以来一直在生产环境中运行。它自动对每夜的端到端测试失败进行分类，用工程师验证的自动化首轮分诊取代了人工首轮分诊。对于每次故障，智能体会生成一份结构化的修复报告，包含可操作的后续步骤，而非原始日志。智能体与人工分诊的分类一致率已从最初部署时的44%提升到如今的68%。随着团队不断迭代黄金数据集和提示词工程，它仍在持续改进。
自从分诊智能体投入生产以来，团队测量到在分析测试失败期间阻塞生产部署的时间减少了20%。由于这些测试是 Rescale 每周生产发布的关卡，这一减少直接体现在变更到达生产环境的速度上。工程师在值班轮换中花在重复性分类上的时间也减少了。
研讨会之后的生活：从一个智能体到 AI 优先的实践
研讨会交付了一个生产级智能体，但它更大的影响在于改变了 Rescale 开展工程工作的方式。该分诊智能体是 Rescale 面向 AI 时代交付数字工程能力这一更宏大举措的一部分。在内部，Rescale 正在其自身的工程组织中应用从 AI 中获得的这些相同收益。AI-DLC 为 Rescale 的工程师提供了一种结构化、可重复的方式，将这一方向付诸实践。
在整个组织中扩展 AI-DLC
Rescale 正在评估建立一个内部 AI-DLC Center of Excellence（卓越中心），这是一个小型团队，负责将最佳实践整理成文，并帮助其他团队独立采用该方法论。
参与的工程师们已经在应用他们所学到的知识。其中一位工程师指出，这一流程“将成为我今后工作流程的一部分”，不仅适用于构建智能体，也适用于任何 AI 可以贡献力量的复杂开发工作。
更广泛的 AI 原生开发
Rescale 现在正将 AI-DLC 融入新的工程仿真产品的标准软件开发生命周期中。该框架将仿真领域专业知识、产品需求、平台架构、验证和运营整合到一个结构化的设计流程中。团队尽早解决关键问题，将经过评审的决策记录在可执行的规范中，并让编码智能体专注于具有明确验收标准的工作。这缩短了从产品概念到经过验证的实现之间的路径，同时工程师仍然对产品正确性负责。
同样的方法已经应用于产品支持平台的工作和智能体系统中：
- HPC 仿真应用目录管理。
- 针对政府合规要求的容器漏洞跟踪与修复。
- 基于工作流的云端编码智能体。
结论
对于分流智能体而言，AI-DLC 最有用的产出并不是代码本身，而是从最初想法到经过评审的系统设计的结构化路径：澄清性问题、范围明确的需求和评估标准。
该规范为编码智能体提供了一个更窄、定义更清晰的问题去解决。团队不必让智能体在实现的同时推断架构，而是可以让智能体针对人类已经评审过的决策进行专注的构建。其结果是输出更加专注、更易于评审、更容易集成和改进。对 Rescale 而言，这就是可重复的模式：使用 AI-DLC 来组织设计讨论，将决策转化为规范，然后使用编码智能体来加速实现。
关键要点
- 从一个真实的问题开始。 Rescale 的分流智能体之所以成功，是因为它解决了一个工程难题。是问题驱动了解决方案，而不是相反。
- 人类监督是加速，而不是减速。 每一次改进系统的架构转向都来自人类对 AI 提议的验证。AI 生成、人类验证的 mob 模式比单独工作更快。
- 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 定制适配到贵组织的特定工程工作流。