AWS Professional Services 已詳細說明一套旨在自動化大型企業雲端遷移的多代理系統，並使用 Amazon Bedrock AgentCore 來協調探索、基礎架構程式碼生成、治理與遷移後營運。

這套系統鎖定的是包含數百個應用程式的遷移專案，在這類專案中，人工導入與基礎架構開發所耗費的時間，可能比實際搬遷還要多。AWS 表示，其內部框架已將 300 多個應用程式組合中的 Infrastructure as Code 開發時間，從每個應用程式三到四週縮短到數分鐘。該結果來自內部專案追蹤資料，並未經獨立驗證。

這項揭露之所以重要，是因為它不只是把 AgentCore 當作單一助理的執行環境，而是把它呈現為涵蓋評估、部署與營運的工作流程控制層。對企業技術團隊來說，更重要的問題在於：代理式自動化能否在不移除高影響力基礎架構決策的人類核准的前提下，產生可重複、受治理的遷移工作。

由專門代理分工的遷移工作流程

AWS 描述了一個由 AWS Professional Services 以 Strands Agents SDK 建構的框架。與其將整個遷移交給單一通用模型，這個架構把工作拆分給職責較窄的代理。

Intake Agent 負責自動化應用程式探索、相依性對映，以及目標架構定義。接著，IaC Agent 會依照組織的安全實務與標準產生 Infrastructure as Code。Migration Intelligence and Governance Agent 則會跨 Jira、Confluence 與 Webex 等工具，產生投資組合報告、Well-Architected 評估與治理資訊。

部署後，SRE Agent 會監控已遷移的工作負載、找出潛在退化，並支援自動修復。AWS 也列出可用於特定遷移任務的相鄰服務，包括用於協助 schema 轉換與資料庫切換的 AWS Database Migration Service，以及用於舊有應用程式現代化的 AWS Transform。

這種分工反映了遷移專案中的不同風險輪廓。探索需要從文件與既有系統中萃取事實；程式碼生成需要遵循基礎架構標準；治理需要投資組合層級的可視性；營運則需要存取即時系統並進行嚴格控制的修復。將這些工作視為不同代理角色，可能比把廣泛權限交給單一代理更容易管理權限與評估。

Amazon Bedrock AgentCore 如何融入系統

根據 AWS Machine Learning Blog，每個代理都是由基礎模型、系統提示與一組工具所定義。Amazon Bedrock AgentCore Runtime 會在具備工作階段隔離與多代理協調支援的無伺服器環境中託管這些代理。

代理透過 Model Context Protocol 工具存取外部能力。AgentCore Gateway 可將 API、AWS Lambda 函式與既有服務轉換為相容 MCP 的工具，讓框架能把遷移代理連接到企業系統，而不必為每個整合重新打造一個新介面。

身分識別由 AgentCore Identity 處理；AWS 表示它會使用範圍受限的 AWS Identity and Access Management 角色以及組織的身分提供者來驗證呼叫。這對基礎架構自動化來說是關鍵細節：實際的安全邊界不只是模型指令，還包括每個代理在技術上被允許讀取、修改或執行的內容。

AWS 表示，這套框架會在遷移生命週期中套用安全控制，並保留人類對決策的責任。來源並未說明內部部署所使用的具體核准關卡、回復機制或評估門檻，因此團隊不應假設所述模式會自動為所有環境提供生產等級的控制。

支撐效能主張的證據

這項公告中最強的效率主張來自供應商本身。AWS 將每個應用程式三到四週的 IaC 開發縮短到數分鐘、涵蓋超過 300 個應用程式組合的成果，歸因於其內部專案追蹤資料。該部落格未提供完整的前後比較方法、每個應用程式的複雜度細節、人工審查量，或有多少生成程式碼是在未做重大修改下被採納。

這個區別很重要。「數分鐘」可能只是在描述初始生成，而非通往獲准、測試、安全且已部署基礎架構的完整路徑。在企業遷移工作中，即使程式碼撰寫已自動化，驗證、例外處理、網路決策、資料相依性、合規審查與變更管理仍可能占有相當比重。

目前可見的證據確實說明了 AWS 正在展示的內容：一套可運作的內部架構，結合了目的專用的AI 代理、企業工具與 AWS 遷移服務。但它尚不足以證明在各產業或應用程式組合中，都能普遍重複達成這種時間節省。這個主題組中的第二個來源是 AWS 控制的部落格，而所提供的 wire 稿則沒有額外的文章內文或獨立報導。

這對雲端遷移團隊代表什麼

對開發者而言，這個框架提供了一個參考模式，可把 AI 代理連接到既有遷移資料與營運系統。最可重複利用的概念，是依生命週期階段與權限範圍來分離代理。探索代理可存取清單與架構文件，而基礎架構代理可產生檔案，但不具備直接的正式環境部署權限。營運代理則可檢視遙測資料並提出修復建議，再由人類或政策引擎核准變更。

這種結構也能讓測試更具體。團隊可以透過相依性對映結果來評估探索準確度，針對政策與安全檢查來檢視生成的 IaC，並以警示精準度、修復成功率與回復行為來衡量營運代理。這些比單看模型回應速度更有用。

對企業買家而言，關鍵取捨在於：更快完成標準工作，與治理代理存取權限所需成本之間的平衡。AgentCore 的 runtime、gateway 與 identity 能力涵蓋部署與授權的一部分，但組織仍需要模型選擇政策、稽核紀錄、環境隔離、密鑰管理、人類核准，以及處理不符合標準模式應用程式的流程。

這種做法對有固定期限的資料中心退出計畫尤其相關，因為重複性的探索與程式碼準備容易形成工作排隊。至於在高度客製化系統、未文件化相依性，或需要大幅重新設計應用程式的遷移上表現如何，則還不明朗。AWS 同時納入 AWS DMS 與 AWS Transform，顯示其協調層旨在把通用代理與專業服務結合，而不是取代所有遷移工具。

接下來要觀察什麼

下一步有價值的訊號，會是能顯示完整遷移時間的獨立案例研究，而不僅只是 IaC 生成時間。買家應尋找涵蓋審查工時、部署成功率、回復率、安全發現，以及無需客製工程即可處理的應用程式比例的數據。

若能進一步說明框架中的人類核准點，也會讓其營運成熟度更加清楚。被拒絕或被修正的代理輸出範例、來自 AgentCore Identity 的稽核追蹤，以及管控自動修復的政策，都能幫助團隊評估風險。

最後，可重複使用的參考實作、各 AWS Region 支援的模型，以及超出部落格所列工具之外的整合能力，將顯示這究竟仍是 AWS Professional Services 的模式，還是會成為可廣泛採用的平台架構。遷移合作夥伴的採用情況，以及來自 AWS 以外客戶的證據，將比目前的內部成果提供更強的市場訊號。

Creati.ai 觀點

AWS 正把 AgentCore 定位為協調式企業 AI 代理的基礎架構，而雲端遷移是個可信的測試案例，因為這類工作雖然重複，但仍仰賴專業判斷。這套架構的價值，可能更多來自把零散的遷移任務轉化為受控、可檢視的工作流程，而不是自動決策本身。

這項加速成果值得注意，但應被視為內部基準，而非整體市場的結果。對 AI 建構者與企業團隊而言，長久的啟示是：在允許生成的基礎架構或自動修復影響正式環境前，先把狹窄的代理職責、嚴格的身分邊界、可衡量的審查關卡，以及營運證據結合起來。