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

TL;DR · AI 摘要
How Rescale built an AI triage agent with Strands Agents and AI-DLC Artificial Intelligence How Rescale built an AI tria...
核心要点
- 主题聚焦:How Rescale built an AI triage agent with Strand
- 来源:AWS Machine Learning Blog,建议结合原文判断细节。
- AI 分析暂不可用,本条为保底评分与摘要。
Rescale如何使用Strands Agents和AI-DLC构建AI分诊代理 | 人工智能
Rescale如何使用Strands Agents和AI-DLC构建AI分诊代理
每个工程团队都熟悉这个流程,Rescale也不例外。夜间测试套件失败,值班工程师提取日志、分类根本原因,并将其路由到合适的团队,但第二天早上又得重复这个过程。当系统规模扩大到分布式服务和数十个代码仓库时,这种流程会变成轮班制度中占据全职时间的隐性工作。
Rescale是专为人工智能时代打造的数字工程平台。航空航天、汽车、能源、生命科学、半导体和制造领域的研发与工程团队使用Rescale平台加速创新,将智能HPC、先进建模与仿真、智能数字工程和AI物理仿真整合到统一平台。
在代码之外,Rescale将AI应用于整个工程生命周期,从规划、设计到实施、测试、评审和运营,同时确保工程师对结果负责。AI可以提出并执行方案,但人员需要定义范围、验证工作并批准生产变更。这样工程师就能专注于架构设计、产品判断以及操作复杂分布式系统所需的上下文理解。
在本文中,我们将展示Rescale如何在AWS上使用AI驱动的开发生命周期(AI-DLC)框架构建智能分诊代理。他们仅用五天时间就从问题定义推进到预发布环境部署,并在数周内完成生产环境部署。本文还涵盖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套件的数百个测试用例产生失败时,流水线会触发分诊代理容器。
代理执行以下步骤:
- 通过Amazon Bedrock调用Claude Opus 4.8,将每个失败分类为根本原因类别:基础设施问题、代码错误、不稳定测试或环境问题。
- 从知识库中检索相关的失败历史模式以提供额外上下文。
- 通过Model Context Protocol(MCP)查询容器日志,获取支持分类的运行时证据。
- 在采取任何行动之前,生成包含具体文件引用、函数名称和推荐修复方案的结构化修复报告,供工程师审阅。
代理在几秒钟内完成此工作流,并直接输出到团队现有的报告流水线中。下图展示了这些组件如何协同工作:
Figure 1: Rescale AI分诊代理架构,运行在Amazon EKS上,使用Amazon Bedrock进行分类,知识库存储历史失败模式,通过Amazon CloudWatch集成实现基于MCP的日志检索
AI-DLC工作坊体验
这次合作被结构化为为期五天的线下工作坊。AWS架构师指导构建过程,而Rescale工程师则通过实际操作键盘实时共同构建。
启动阶段(第1-2天):从愿景到验证需求
团队首先确定需求范围,通过愿景文档和技术环境文档明确工作目标,这些文档在开始构建前就奠定了工作基础。该愿景最初是一个简短声明:“我们想要一个AI驱动的测试分诊系统,能够分类失败并推荐修复方案”。通过协作的Mob模式,团队共同回答了AI生成的20多个澄清问题。这产生了包含阶段1明确边界和阶段2事项延期的范围需求文档。五个用户故事被整合为四个工作单元:
- 历史失败模式知识库
- 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纳入新工程仿真产品的标准软件开发生命周期。该框架将仿真领域专业知识、产品需求、平台架构、验证和运营整合到一个结构化设计流程中。团队早期解决关键问题,将审查后的决策记录在可执行的规范中,并为编码代理提供明确验收标准的专注工作。这缩短了从产品概念到验证实现的路径,同时工程师仍需对产品正确性负责。
相同的方法已经在产品使能平台工作和代理系统中应用:
- 高性能计算仿真应用目录管理。
- 用于政府合规要求的容器漏洞跟踪和修复。
- 基于工作流的云编码代理。
结论
对于分诊代理而言,AI-DLC最有价值的输出不是代码本身。而是从初始想法到已审查系统设计的结构化路径:明确问题、范围需求和评估标准。
该规范为编码代理提供了更明确、更具体的问题需要解决。团队无需让代理在实现过程中推断架构,而是可以使用代理针对人类已审查的决策进行专注构建。结果是更聚焦、可审查的输出,更容易集成和改进。对Rescale而言,这就是可重复的模式:使用AI-DLC结构化设计对话,将决策转化为规范,然后使用编码代理加速实现。
关键要点
- 从真实问题出发。Rescale的分诊代理之所以成功,是因为它解决了工程挑战。问题是驱动解决方案的因素,而非相反。
- 人工监督加速而非延缓进程。每一次改进系统的架构调整都来自于对AI提案的人工验证。AI生成、人工验证的“蜂群”模式比单独工作更快。
- AWS堆栈为代理提供了所需的每一层支持。Amazon Bedrock在Rescale已使用的环境中提供了基础模型访问,使团队无需承担额外模型基础设施开销即可构建分诊工作流。Strands SDK提供了代理框架,Amazon EKS在Rescale现有流水线中托管了容器化代理。
立即体验AI-DLC
- 理解方法论:阅读 AI-DLC 简介博客和自适应工作流程深度解析
- 探索服务:了解更多关于 Amazon Bedrock 的信息
- 立即试用:在 github.com/awslabs/aidlc-workflows 克隆开源的 AI-DLC 工作流规则
- 实际操作:使用 Amazon Q Developer 逐步完成一个实际的 AI-DLC 构建
- 联系:联系您的 AWS 账户团队,讨论如何将 AI-DLC 定制到您组织特定的工程工作流程中
About the authors
'\"