Rescale 如何透過 Strands Agents 和 AI-DLC 構建 AI 分流智能體

每個工程團隊都熟悉這套例行流程，Rescale 也不例外。夜間測試套件失敗，值班工程師便會提取日誌、判斷根本原因，再轉交給合適的團隊，翌日早上又重複一次。當服務分散在多個系統、橫跨數十個程式碼儲存庫，這套例行流程便會演變成一份藏身於值班輪值中的全職工作。

Rescale 是為 AI 時代而打造的數碼工程平台。航空航天、汽車、能源、生命科學、半導體及製造業的研發和工程團隊，都使用 Rescale 平台加快創新步伐。平台將智能高效能運算（HPC）、進階建模與模擬、代理式數碼工程及 AI 物理學整合於一處。

除了編碼，Rescale 也在整個工程生命週期中運用 AI，從規劃和設計，到實作、測試、審查及營運，同時確保工程師對結果負責。AI 可以提出建議並執行工作，但工作範圍由人員界定，成果由人員驗證，正式環境的變更也須經人員批准。工程師因而可以專注於架構、產品判斷，以及營運複雜分散式系統所需的背景知識。

本文將介紹 Rescale 如何在 AWS 上運用 AI 驅動開發生命週期（AI-DLC）框架，打造智能分流代理。團隊由界定問題到部署至預備環境，只用了五天，並在數週內投入正式環境。本文亦會介紹 Rescale 如何在整個工程團隊中擴展 AI-DLC 的應用。

挑戰

隨着 Rescale 的平台不斷擴展，維持平台運作所需的營運工作也隨之增加。工程師花費大量時間處理一項重複但關鍵的工作：判斷自動化端對端測試失敗的原因。測試套件會執行數百個測試案例；一旦出現失敗，每項警示、錯誤報告和升級個案都需要分類、排定優先次序，並轉交給合適的團隊。完成轉交後，工程師還需要從多個日誌及監察系統，以及數個原始碼儲存庫收集證據，才能開始除錯。服務必須通過端對端測試，才能部署至正式環境，因此除錯這些系統故障是將新變更部署至正式環境的關鍵環節。

在人工處理流程中，工程師會查閲測試報告、日誌、過往模式及原始碼，判斷測試失敗的原因，並找出最可能負責的團隊。由於這些整合測試是每週正式環境版本發布的關卡，未解決的失敗可能令多個團隊花數小時協調，部署才能繼續進行。

團隊對解決方案已有明確構想：打造一個能自動分類問題並轉交的智能代理。他們需要一套有系統的方法，將這個構想轉化為可在正式環境中運作的系統，同時具備足夠的架構，日後可將此方法延伸至其他應用場景。

Rescale 為何選擇 AI-DLC

Rescale 的分流代理是一個範圍明確、時間緊迫的問題。團隊需要一種能配合這個步伐的開發方法，同時不能略過那些決定系統能否在正式環境中運作的架構決策。

AI 驅動開發生命週期（AI-DLC）是一套開源、以 AI 為核心的軟件開發方法論，建基於兩個理念：

AI 執行，人類決策：AI 產生工作計劃、編寫程式碼並提出架構方案，但會指出需要作決定的環節，並提出澄清問題，而非自行猜測。
團隊協作會議取代非同步交接：AI-DLC 不再採用由一人獨自開發、之後再請人審核的做法，而是透過專注的小組會議協作：Mob Elaboration（共同制定需求）和 Mob Construction（共同建構，由 AI 負責實作）。團隊會即時作出決定。

AI-DLC 之所以合適，是因為難處不在編寫程式碼，而在確保 AI 明白團隊想要開發甚麼。在小組協作會議中，Rescale 工程師一起回答 AI 的問題，並在 AI 繼續下一步前核準每項計劃，避免任何部分只靠假設。

解決方案概覽

Rescale 的分流 Agent 會自動分類每晚端對端測試的失敗，並將其路由至適當位置。它在 Rescale 現有的 Argo Workflows 持續整合及持續交付（CI/CD）流程中運作，該流程在 Amazon Elastic Kubernetes Service (Amazon EKS) 上執行。每晚執行的 Playwright 測試套件包含數百個測試案例；一旦出現失敗，流程便會觸發分流 Agent Pod。

Agent 會執行以下步驟：

呼叫 Amazon Bedrock 上的 Claude Opus 4.8，將每項失敗分類為以下根本原因類別：基礎設施問題、程式錯誤、不穩定測試或環境問題。
從知識庫擷取相關的歷史失敗模式，作為額外背景資訊。
透過 Model Context Protocol (MCP) 查詢 Pod 日誌，以取得支持該分類的執行階段證據。
產生結構化的修復報告，列出具體的檔案參照、函式名稱及建議修正方法，供工程師審核；在審核前不會採取任何行動。

Agent 只需數秒便可完成此工作流程，並直接將結果輸出至團隊現有的報告流程。下圖展示這些組件如何配合運作：

圖 1：Rescale 的 AI 分流代理架構。代理在 Amazon EKS 上運行，使用 Amazon Bedrock 進行分類、利用知識庫掌握歷史故障模式，並透過 Amazon CloudWatch 整合，以 MCP 為基礎擷取日誌

AI-DLC 工作坊體驗

這次合作以為期五天的實體工作坊形式進行。AWS 架構師指導建置工作，Rescale 工程師則親自動手，實時共同建構。

啟動階段（第 1–2 天）：從願景到確認需求

團隊先界定需求，將目標記錄在願景文件和技術環境文件中，為建置工作奠定基礎。最初的目標只有一句話：「我們希望透過 AI 測試分流，分類故障並建議補救措施。」團隊以 mob 形式協作，回答由 AI 生成的 20+ 條澄清問題，並據此制定範圍明確的需求文件，清楚界定第一階段的範圍，並將第二階段項目延後處理。五個用戶故事整合為四個工作單元：

用於掌握歷史故障模式的知識庫。
作為核心分類及補救引擎的 AI 分流代理。
用於觸發、基礎設施及部署的 Argo Workflow 整合。
用於準確度測量及回歸測試閘控的評估測試框架。

由人員作出的決定界定了關鍵範圍：哪些內容屬於第一階段而非第二階段、優先次序，以及延後處理的功能，例如自動生成拉取請求（PR）。

建置階段（第 2–4 天）：從架構到可運行程式碼

團隊定義了介面契約及數據結構描述，解答了功能及非功能設計問題，並確認了架構。開發期間出現兩次架構調整，團隊在改變方向前都先驗證了方案。

最初，團隊計劃在 Amazon Bedrock AgentCore 上託管 Agent，之後改為部署到 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 為基礎的評估框架，支援即時模式和 Stub 測試模式，並訂立初始分類一致率基線，作為衡量及改善 Agent 的依據。團隊向 Rescale 的 CTO 和工程副總裁即場示範 Agent；Agent 正確分類了基礎設施故障和真實程式碼錯誤，並針對具體檔案提出修正建議。

AI-DLC 如何按複雜程度調整嚴謹度

並非每項工作都需要同等程度的處理。知識庫只需少量設計，數小時內便透過 Terraform 完成部署。Triage Agent 則採用全面流程：架構審查、介面契約、12項設計問題，以及反覆進行程式碼審查。Argo Integration 著重基礎設施契約及 IAM。Evaluation Harness 採用輕量設計，但投入大量實作工作。AI-DLC 會自動按複雜程度調整工作的深入程度。

第5天結束時，Agent 已在預備環境運行，處理真實測試失敗，並具備經量度的準確率基線和清晰的正式環境部署路徑。

正式環境成果

自工作坊以來，分流 Agent 一直在正式環境運行。它會自動分類每晚端對端測試的失敗，取代人工初步分流；工程師再核實自動分流結果。每宗失敗都會產生一份結構化修復報告，列出可執行的後續步驟，而非只提供原始日誌。Agent 與人手故障分流的分類一致率，已由首次部署時的44%升至目前的68%。團隊持續調整黃金數據集和提示詞工程，令 Agent 不斷改善。

自分流 Agent 在正式環境投入運作後，團隊量度到：分析測試失敗期間阻礙正式環境部署的時間減少了20%。由於這些測試是 Rescale 每週正式環境發布的關卡，這項減幅直接加快了變更正式推出的速度。工程師在值班輪值期間用於重複分類工作的時間亦有所減少。

工作坊之後：從單一 Agent 邁向 AI 優先的工作方式

這次工作坊交付了一個投入生產環境的代理，但更大的影響在於 Rescale 處理工程工作的方式。分流代理是 Rescale 推動更廣泛工作的其中一環，旨在為 AI 時代提供數碼工程能力。在內部，Rescale 也正把 AI 帶來的同樣效益應用於自身的工程團隊。AI-DLC 為 Rescale 的工程師提供一套有系統、可重複的方法，將這個方向付諸實行。

在整個組織推廣 AI-DLC

Rescale 正在評估設立內部 AI-DLC 卓越中心，由一個小型團隊制定最佳實務，並協助其他團隊獨立採用這套方法。

參與其中的工程師已開始應用所學。一位工程師指出，這個流程「將會成為我往後工作流程的一部分」，不僅用於建構代理，也適用於任何 AI 能夠參與的複雜開發工作。

更廣泛地採用 AI 原生開發

Rescale 現正把 AI-DLC 納入新工程模擬產品的標準軟件開發生命週期。這套框架把模擬領域專業知識、產品需求、平台架構、驗證及營運整合到一個有系統的設計流程中。團隊及早解決關鍵問題，把經審核的決策記錄為可執行規格，並為程式編寫代理安排範圍明確、驗收準則清晰的工作。這縮短了從產品概念到經驗證實作的過程，同時由工程師繼續對產品的正確性負責。

同一套方法已用於支援產品的平台工作及代理系統：

HPC 模擬應用程式目錄管理。
為符合政府合規要求而追蹤及修復容器漏洞。
以工作流程為基礎的雲端程式編寫代理。

結語

對於分流代理而言，AI-DLC 最有用的成果並非程式碼本身，而是從初步構想到經審核的系統設計的有系統流程：釐清問題、界定需求範圍，以及訂明評估準則。

這份規格為程式編寫代理界定了更聚焦、清晰的問題。團隊毋須要求代理一邊實作、一邊自行推斷架構，而是可以讓代理根據人員已審核的決策，集中建構指定部分。結果是產出更聚焦、更易審核，也更容易整合和改進。對 Rescale 而言，這就是可重複採用的模式：運用 AI-DLC 有系統地進行設計討論，把決策整理成規格，再利用程式編寫代理加快實作。

重點摘要

從實際問題着手。 Rescale 的分流代理之所以成功，是因為它解決了工程上的挑戰。解決方案由問題帶動，而非本末倒置。
人為監督有助加快進度，而非拖慢進度。 每次令系統改進的架構調整，都源於人員對 AI 提案的驗證。由 AI 生成、人員驗證的羣體協作模式，比單獨工作更快。
AWS 技術堆疊為代理提供所需的各個層面。 Amazon Bedrock 在 Rescale 已使用的環境中，提供分類所需的基礎模型存取能力，讓團隊無需承擔額外的模型基礎設施開銷，便能建構分流工作流程。Strands SDK 提供代理框架，而 Amazon EKS 則在 Rescale 現有的管道中託管容器化代理。