跳到正文
AWS Machine Learning Blog· Isha Doshi·· 11 天前AI 评分38

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

How Rescale built an AI triage agent with Strands Agents and AI-DLC

AI 导读

Rescale 基于 AWS 的 AI-DLC 框架和 Strands Agents 构建了一个 AI 分诊智能体,用于自动分类和路由夜间端到端测试失败,从问题定义到 staging 部署仅用五天,数周内进入生产。

摘要与补充说明

该智能体运行在 Amazon EKS 上的 Argo Workflows CI/CD 流程中,调用 Amazon Bedrock 上的 Claude Opus 4.8 将失败归类为基础设施问题、代码缺陷、不稳定测试或环境问题,并从知识库检索历史失败模式、通过 MCP 查询 pod 日志,数秒内生成含文件引用、函数名和修复建议的结构化报告供工程师审核。

正文· AI 翻译

每个工程团队都熟悉这套仪式,Rescale 也不例外。夜间测试套件失败。值班工程师拉取日志,归类根因,并将其转交给正确的团队,结果第二天早上又要重复同样的过程。在规模化场景下,跨分布式服务和数十个代码仓库,这套仪式变成了一份隐藏在值班轮换中的全职工作。

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

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

在本文中,我们展示 Rescale 如何在 AWS 上使用 AI-Driven Development Lifecycle (AI-DLC) 框架构建智能分诊代理。他们从问题定义到预发布部署仅用五天,并在数周内进入生产环境。本文还介绍了 Rescale 如何在其工程组织中推广 AI-DLC。

挑战

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

在手动工作流中,工程师从测试报告转到日志、历史模式和源代码,以对失败进行分类并确定可能的负责团队。由于这些集成测试是每周生产发布的关口,未解决的失败可能会在部署获准继续之前,将多个团队拖入数小时的协调工作。

团队对解决方案有清晰的想法:一个能够自动分类和转交问题的智能代理。他们真正在寻找的是一种结构化的方法,能够从这一理解出发,走向生产环境中的可用系统,并且具备足够的结构,以便之后将该方法扩展到其他用例。

为什么 Rescale 选择 AI-DLC

Rescale 的分诊代理是一个范围明确、时间紧迫的问题。团队需要一种能够以这种节奏推进、同时又不跳过那些决定系统能否在生产中运行的架构决策的开发方法。

AI-Driven Development Lifecycle (AI-DLC) 是一种开源的、以 AI 为中心的软件开发方法论,围绕两个理念构建:

  1. AI 执行,人类决策:AI 生成工作计划、编写代码并提出架构,但它会呈现决策点并提出澄清性问题,而不是靠猜测。人类在每一步进行验证和引导。
  2. 团队协作会话取代异步交接:AI-DLC 不再由一个人独自构建、之后再请求审查,而是采用聚焦的团队协作会话:Mob Elaboration(共同定义需求)和 Mob Construction(共同构建,由 AI 负责实现)。决策实时发生。

AI-DLC 之所以合适,是因为难点不在于编写代码,而在于确保 AI 理解团队想要构建什么。在 mob 会话中,Rescale 工程师共同回答 AI 的问题,并在 AI 继续推进之前批准每个计划,因此没有任何事情被留给假设。

解决方案概述

Rescale 的分诊代理可自动对夜间端到端测试失败进行分类和路由。它作为 Rescale 现有 Argo Workflows 持续集成与持续交付(CI/CD)流水线中的一个步骤,运行在 Amazon Elastic Kubernetes Service(Amazon EKS)上。当包含数百个测试用例的夜间 Playwright 套件产生失败时,流水线会触发分诊代理 pod。

该代理执行以下步骤:

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

该代理在数秒内完成此工作流,并直接输出到团队现有的报告流水线中。下图展示了这些组件如何协同工作:

Architecture of Rescale’s triage agent on Amazon EKS using Amazon Bedrock, a knowledge base, and MCP log retrieval through Amazon CloudWatch

图 1:Rescale AI 分诊代理的架构,运行在 Amazon EKS 上,使用 Amazon Bedrock 进行分类,使用知识库获取历史失败模式,并通过 Amazon CloudWatch 集成进行基于 MCP 的日志检索

AI-DLC 工作坊体验

本次合作以为期五天的线下工作坊形式组织。AWS 架构师指导构建,Rescale 工程师则亲手操作键盘,实时共同构建。

初始阶段(第 1–2 天):从愿景到经过验证的需求

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

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

人类决策推动了关键边界:哪些属于 Phase 1 而非 Phase 2、优先级排序,以及推迟的功能(如自动生成拉取请求(PR))。

构建阶段(第 2–4 天):从架构到可运行的代码

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

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

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

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

运营阶段(第 5 天):评估与交接

团队构建了基于 PyTest 的评估框架,支持实时和桩测试模式,建立了初始的分类一致率基线,用于衡量 agent 表现并据此改进。该 agent 向 Rescale 的 CTO 和工程副总裁进行了现场演示,正确分类了一次基础设施故障和一个真实的代码缺陷,并给出了具体的文件级修复建议。

AI-DLC 如何按复杂度匹配严谨程度

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

到第 5 天结束时,该 agent 已在预发布环境中上线,处理真实的测试失败,并具备经过测量的准确率基线和清晰的投产路径。

生产成果

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

自分诊 agent 进入生产环境以来,团队测得在分析测试失败期间阻塞生产部署的时间减少了 20%。由于这些测试是 Rescale 每周生产发布的关卡,这一减少直接体现在变更到达生产环境的速度上。工程师在 on-call 轮值中花在重复性分类上的时间也减少了。

研讨会之后:从一个 agent 到 AI 优先的实践

这次工作坊交付了一个生产级 agent,但其更大的影响在于 Rescale 对待工程工作的方式。该分诊 agent 是 Rescale 为 AI 时代提供数字工程能力这一更广泛推进的一部分。在内部,Rescale 正在将 AI 带来的这些相同收益应用到自身的工程组织中。AI-DLC 为 Rescale 的工程师提供了一种结构化、可重复的方式,将这一方向付诸实践。

在整个组织中推广 AI-DLC

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

参与其中的工程师已经在应用他们所学到的内容。其中一位工程师指出,这一流程“将成为我今后工作流的一部分”,不仅用于构建 agent,也适用于任何 AI 可以参与的复杂开发工作。

更广泛的 AI 原生开发

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

同样的方法已被用于产品赋能平台工作和 agent 系统:

  • HPC 仿真应用目录管理。
  • 针对政府合规要求的容器漏洞跟踪与修复。
  • 基于工作流的云端编码 agent。

结论

对于该分诊 agent 而言,AI-DLC 最有用的产出并不是代码本身,而是从最初想法到经过评审的系统设计之间的结构化路径:澄清性问题、界定范围的需求以及评估标准。

这份规范为编码 agent 提供了一个范围更窄、定义更明确的问题去解决。团队不再要求 agent 在实现的同时推断架构,而是可以让 agent 针对人类已经评审过的决策进行聚焦式构建。结果是产出更聚焦、更易于评审,也更容易集成和改进。对 Rescale 而言,这就是可重复的模式:使用 AI-DLC 来组织设计讨论,将决策转化为规范,然后使用编码 agent 来加速实现。

关键要点

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

开始使用 AI-DLC


关于作者

Isha Doshi

Isha Doshi

Isha 是 AWS 的 ISV 解决方案架构师 II,专攻机器学习和人工智能。她帮助客户在 AWS 上构建可扩展、安全且创新的解决方案。业余时间,Isha 喜欢徒步和摄影。

Ayush Ahuja

Ayush Ahuja

Ayush 是 AWS 的客户解决方案经理,他与 AI 原生和高性能计算 ISV 合作,通过战略合作和基于体验的加速(EBA)项目加速他们的云和 AI 之旅。

Matt Martin

Matt Martin

Matt 是 AWS 的 ISV 客户主管,他与 AI 原生和高性能计算客户合作,通过云迁移和 AI/ML 采用来加速增长。

Shree Krishnamurthi

Shree Krishnamurthi

Shree 是 AWS 原型设计与 AI 客户工程(PACE)团队的技术合作经理,她领导战略性的 AI 原型设计项目和 AI-DLC 计划,引导客户团队进行结构化、AI 原生的开发。凭借在软件开发、企业解决方案和云转型方面的经验,她帮助工程团队将新兴 AI 能力转化为生产就绪的系统。

Jimin Kim

Jimin Kim

Jimin 是 AWS 驻纽约的高级 AI 工程师。她是 AWS MCP Servers 的创始工程师之一,帮助企业采用 AI 驱动的开发。工作之余,她喜欢编织、弹钢琴和壶铃训练。

Mark Whitney

Mark Whitney

Mark 是 Rescale 的工程副总裁,负责领导工程组织和公司的 AI 原生工程战略。

Evan Richardson

Evan Richardson

Evan 是 Rescale 的高级软件工程师,参与构建并运营 Rescale 的 AI 驱动测试分诊代理,并参加了 AWS AI-DLC 研讨会。

Gustavo Frizzo

Gustavo Frizzo

Gustavo 是 Rescale 的高级软件工程师,亲身参与了 AWS AI-DLC 研讨会,并将该方法论应用于代理运行时工程。

Michael Dillon

Michael Dillon

Michael 是 Rescale 的软件工程高级经理,领导核心平台团队,并帮助推进公司的 AI 原生工程计划。

来源:AWS Machine Learning Blog · aws.amazon.com阅读原文

相关阅读

专题与标签

相关资讯专题

相关评测

Claude Opus 4.8 · 模型榜