Rescale用AI-DLC五天构建测试分诊智能体，生产环境分类一致率从 44% 升至 68%
AWS博客披露，Rescale基于Strands SDK、Amazon Bedrock上的Claude Opus 4.8和MCP日志检索，在EKS内运行自动分类夜间端到端测试失败的智能体；AWS称其部署后阻断生产部署的时间减少 20%。
AI解读：这篇AWS博客讲的是一个具体工程问题的解法：Rescale的夜间端到端测试失败后，需要值班工程师拉日志、判断根因、找到负责团队，而这类测试又是每周生产发布的门禁，失败会卡住部署。Rescale与AWS架构师用AI-DLC方法在五天工作坊内把分诊智能体做到staging，数周内进入生产。
智能体的适用范围有明确边界：它做的是失败分诊的第一遍分类与路由，输出带文件引用、函数名和修复建议的结构化报告供工程师复核，不自动提交PR，自动PR生成被明确推迟到Phase 2。
效果数据来自Rescale自身生产环境，由AWS博客转述：与人工分诊的分类一致率从初部署时的 44% 升到 68%，仍在通过黄金数据集和提示词迭代改进；因分析测试失败而阻断生产部署的时间减少 20%。这些是单一团队、单一流水线的数字，不能外推为通用节省比例。
架构上有两次被记录下来的调整：原计划托管在Amazon Bedrock AgentCore，后改到Rescale已运行Argo Workflows的EKS集群，省去新的运行时；日志证据来源从第三方日志服务改到Amazon CloudWatch，MCP的检索模式不变。
方法层面的主张由AWS提出：AI-DLC强调AI执行、人来决策，用Mob Elaboration和Mob Construction的集体会话替代异步交接。Rescale正在评估设立内部AI-DLC卓越中心，并把该方法纳入新工程仿真产品的标准开发流程。
AWS机器学习博客发布案例文章，介绍Rescale如何使用AWS的AI-DLC（AI驱动开发生命周期）方法构建一个测试失败分诊智能体。文章署名Isha Doshi。按文中说法，Rescale从问题定义到staging部署用了五天，数周内进入生产。
Rescale自称是为AI时代构建的数字工程平台，客户覆盖航空航天、汽车、能源、生命科学、半导体和制造业。其平台规模扩大后，数百个端到端测试用例每晚运行，失败需要被分类、排优先级并路由到对应团队，而这类测试是每周生产发布的必要条件。
问题：测试失败分诊卡在发布路径上
文章描述的手工流程是：测试报告产生后，工程师去看日志、查历史模式、翻源代码，判断失败属于哪类根因、由哪个团队负责。因为集成测试是每周生产发布的门禁，未解决的失败可能在部署放行前把多个团队拉进数小时的协调。
Rescale团队对方案的设想是让智能体自动完成分类和路由，缺的是一个能从这一认识走到生产系统的结构化方法。
智能体如何运行
分诊智能体作为Rescale现有Argo Workflows CI/CD流水线中的一个步骤，运行在Amazon Elastic Kubernetes Service（EKS）上。夜间Playwright套件出现失败时，流水线触发智能体pod。
按文中描述，智能体调用Amazon Bedrock上的Claude Opus 4.8，把每个失败归入四类根因之一：基础设施问题、代码缺陷、不稳定测试（flaky test）或环境问题；随后从知识库检索历史失败模式，通过Model Context Protocol（MCP）查询pod日志作为运行时证据，最后生成含具体文件引用、函数名和修复建议的结构化补救报告，交工程师复核后才采取行动。文章称该流程在数秒内完成，输出直接进入团队已有的报告流水线。
智能体用Strands SDK构建，支持并发失败分析和JSON、HTML结构化输出，容器化部署在EKS上。
五天工作坊里的两次架构调整
合作以五天线下工作坊形式进行，AWS架构师指导，Rescale工程师动手共建。前两天做需求界定：团队以「我们要AI驱动的测试分诊，能分类失败并建议补救」为起点，集体回答了AI生成的 20 多个澄清问题，形成界定Phase 1边界的需求文档，5 个用户故事合并为 4 个工作单元：历史失败模式知识库、分诊智能体、Argo工作流集成、评估框架。
建设阶段（第 2 至 4 天）出现两次架构转向，且都经人工验证后才改。其一，原计划把智能体托管在Amazon Bedrock AgentCore，后移到Rescale已运行Argo Workflows的EKS集群，理由是无需再运维一个新运行时，且Argo可直接触发。其二，早期版本通过MCP从第三方日志服务取证据，后改为Amazon CloudWatch，依赖链更简单，MCP模式本身保留，只换了数据源。
到第 4 天，完整流水线已在staging运行：Argo触发、分诊pod、MCP日志查询、知识库检索、结构化分诊输出。第 5 天团队搭建基于PyTest的评估框架，含实时和桩（stubbed）两种测试模式，建立初始分类一致率基线；智能体向Rescale的CTO和工程副总裁做了现场演示，正确分类了一次基础设施失败和一个真实代码缺陷，并给出文件级修复建议。
生产结果与已知限制
文章称智能体自工作坊后一直在生产运行，自动分类夜间端到端测试失败，替代人工分诊的第一遍，由工程师复核。与人工分诊的分类一致率从初部署的 44% 升到目前的 68%，团队通过迭代黄金数据集和提示词继续改进。
另一个数字是：智能体进入生产后，因分析测试失败而阻断生产部署的时间减少了 20%。文章把这与每周发布门禁直接关联。
需要区分的是，44% 到 68% 的一致率说明智能体目前仍与人工判断存在明显差距，其定位是自动第一遍加人工验证；20% 的降幅是Rescale单一流水线的测量值，文章未给出测量口径、样本量或对照方法。
- 根因分类四类：基础设施问题、代码缺陷、flaky test、环境问题
- 输出包含文件引用、函数名与修复建议，人工复核后才行动
- 自动PR生成被列为推迟项，不在Phase 1范围
- 一致率 44%→68%；阻断部署时间减少 20%（AWS博客转述Rescale数据）
方法层面的主张与推广
AI-DLC被AWS描述为开源、以AI为中心的开发方法，两个要点：AI生成工作计划、写代码、提架构，但在决策点提问而非猜测，由人验证和把关；用Mob Elaboration（共同定义需求）和Mob Construction（共同构建）的小组会话替代异步交接。
Rescale对不同工作单元投入的严格程度不同：知识库只需极少设计，用Terraform数小时部署；分诊智能体经过架构评审、接口约定、12 个设计问题和迭代代码评审；评估框架设计轻、实现重。
后续推广方面，Rescale正在评估设立内部AI-DLC卓越中心，由小组沉淀最佳实践并帮助其他团队独立采用；同时把AI-DLC纳入新工程仿真产品的标准开发生命周期，已用于HPC仿真应用目录管理、面向政府合规要求的容器漏洞跟踪与修复、基于工作流的云端编码智能体等工作。上述推广均为进行中的计划或评估，文章未给出这些项目的效果数据。