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

Rescale 是一家面向 AI 时代的数字工程平台，服务航空航天、汽车、能源、生命科学、半导体和制造业的研发与工程团队。随着平台规模扩大，维护运行的开销同步上升：每晚运行的端到端测试套件包含数百个用例，失败出现后，每个告警、缺陷报告和升级都需要被分类、定级并路由到对应团队，工程师还要从多个日志与监控系统以及若干源码仓库中收集证据，才能开始调试。由于端到端测试是服务上生产的必经环节，未解决的失败可能把多个团队拖入数小时的协调。

Rescale 的目标很明确：用一个智能体自动完成失败分类与路由。团队需要的是从这一认识走到生产可用系统的结构化方法，并且这套方法之后能复用到其他场景。

为什么选择 AI-DLC

AI-DLC（AI-Driven Development Lifecycle）是一套开源、以 AI 为中心的软件开发方法论，围绕两点展开。其一是“AI 执行、人类决策”：AI 生成工作计划、编写代码并提出架构方案，但遇到不确定处会抛出决策点、提出澄清问题，而不是自行猜测，人类在每一步验证和掌舵。其二是“团队会话替代异步交接”：不再由一个人独自构建、事后再请求评审，而是通过 Mob Elaboration（共同定义需求）和 Mob Construction（共同构建、由 AI 承担实现）两类集中会话，让决策实时发生。

Rescale 认为难点不在写代码，而在确保 AI 理解团队想构建什么。在集中会话中，工程师共同回答 AI 的问题，并在 AI 继续之前批准每一份计划。

方案构成

分诊智能体作为 Rescale 现有 CI/CD 流程中的一个步骤运行，该流程基于 Amazon EKS 上的 Argo Workflows。当夜间 Playwright 套件产生失败时，流水线触发智能体 pod，其执行的动作包括：

• 调用 Amazon Bedrock 上的 Claude Opus 4.8，将每个失败归入根因类别：基础设施问题、代码缺陷、不稳定测试或环境问题；
• 从知识库检索相关的历史失败模式作为补充上下文；
• 通过 Model Context Protocol（MCP）查询 pod 日志，获取支持分类的运行时证据；
• 生成结构化修复报告，包含具体文件引用、函数名和建议修复方案，供工程师在任何操作前审阅。

该智能体在数秒内完成上述流程，结果直接输出到团队现有的报告流水线。

workshop 与推进节奏

这次合作以为期五天的线下工作坊形式组织，AWS 架构师提供指导，Rescale 工程师全程动手共同构建。前两天的 Inception 阶段从愿景走向经过验证的需求：团队先界定范围，把意图写入愿景文档和技术环境文档，再开始构建。原文提到，这一意图最初只是一句话——“我们想要 AI 驱动的测试……”。

从问题定义到预发布部署，Rescale 用了五天，数周内进入生产。文章还提到 Rescale 正在把 AI-DLC 推广到整个工程组织。

编辑部观察

这条案例值得注意的地方不在模型本身，而在方法论的落点：AI-DLC 把“AI 提出方案、人类批准计划”做成了流程约束，而不是靠提示词自律。对于测试失败分诊这类边界清晰、重复度高、又卡在发布关键路径上的任务，这种结构化的推进方式比单纯追求自动化比例更贴近生产要求。

需要说明的是，原文没有披露该智能体的分类准确率、人工复核比例、误路由率或节省的工时数据，也没有给出知识库的构建方式和历史失败模式的覆盖范围。因此目前无法判断它在长期运行中的稳定性，也无法量化其对发布周期的影响。

实践建议

如果读者所在团队考虑类似方案，可以先做三件事：一是确认失败分诊是否真的位于发布关键路径上，这决定了投入优先级；二是在集中会话中把根因分类的边界定义清楚，尤其是“不稳定测试”与“环境问题”这类容易混淆的类别；三是让智能体只输出带文件引用和函数名的建议报告，把执行动作留给工程师审批，再逐步评估是否扩大自动化范围。评估阶段应自行采集分类准确率和误路由数据，而不是沿用厂商或案例方的叙述。