AWS 詳述 AgentCore 遷移路徑，隨著客戶將代理型工作負載推進至正式環境

AWS 正在說明團隊如何使用 Amazon Bedrock AgentCore 將實驗性代理推進至正式環境，並透過兩篇 Machine Learning Blog 文章，展示分階段的遷移路徑與一個已在正式環境中運行的企業工作流程。

第一篇操作說明會將一個 LangGraph 客戶支援代理遷移到 AgentCore Runtime、Gateway 和 Memory，之後可選擇再以 Strands Agents 重建其規劃迴圈。第二篇則描述一個自動化的架構文件管線，服務於一家全球的 interdealer broker：它會分析 .NET 程式碼、產生圖表，並透過 Amazon Bedrock Knowledge Bases 與 AWS CodePipeline 發布可搜尋的文件。

綜合來看，這些文章將 AgentCore 呈現為包覆不同框架與模型所建構代理的營運層，而不是單一的代理框架。這則訊息主要針對已有可運作原型，但仍需自行處理工作階段隔離、持久狀態、工具驗證、基礎架構修補、可觀測性與部署擴充的團隊。

AWS 從原型到代管代理的分階段路徑

遷移指南從既有的 LangGraph 代理開始，該代理會分類客戶訊息、升級憤怒客戶，並使用工具查詢訂單、處理退貨，以及搜尋常見問題。它的模型呼叫已經透過 Amazon Bedrock 執行，但 AWS 強調，這並不能解決周邊的正式環境責任。

在第一階段，代理的圖保持不變。AgentCore Runtime 負責代管程序，Gateway 處理選定的工具連線，而 Memory 則跨越回合、程序與日期保存對話狀態。AWS 表示，這一階段可移除多項營運工作，而不改變代理如何決定要做什麼。

第二階段則以 Strands Agents 的模型驅動規劃，取代手寫的路由迴圈。若團隊希望保留既有的協調方式，同時享有代管主機、工具與狀態，也可以在第一階段就停止。AWS 也描述了第三個 AgentCore harness 階段，但該文章是記錄此階段，而非在範例中實作它。

這個區別對開發者很重要。Runtime 不會自動取代應用程式的推理邏輯；它提供的是該邏輯執行的環境。選擇更自主的規劃模型，是另一個架構決策，而 AWS 將分階段的方法呈現為隔離這些變更的一種方式。

AgentCore 針對的營運工作

AWS 將 AgentCore 的服務對應到通常會累積在正式代理周邊的工作。Runtime 承擔 AWS 基礎架構上的代管運算、工作階段隔離與擴展責任。團隊可以將 runtime 連接到虛擬私有雲，但 AWS 表示，網路設計、邊緣防護、授權、IAM 政策、web application firewall 規則，以及 secrets 輪替，仍然由客戶負責。

Gateway 管理工具存取，並以自身的執行角色呼叫 AWS Lambda 等目標。指南中的範例使用 AWS IAM 憑證簽署呼叫，而不是第三方權杖。AgentCore 也包含一項身分能力，可在代理需要代表使用者呼叫 API 時，代管憑證並更新 OAuth access tokens，不過該能力並未在操作示範中使用。

Memory 處理的是將對話狀態保存在程序本機字典中的限制。當程序重新啟動，或多個副本需要存取同一段對話時，這種做法可能失敗。AWS 表示，其範例已將 checkpoint 儲存移入 AgentCore Memory，因此狀態能跨越回合、程序與日期持續保存。

可觀測性是 AWS 另一個強調的領域。Runtime 的 logs、metrics 與 traces 會送往 Amazon CloudWatch，而客戶無須自行設定底層管線。不過，該指南並未表示 AgentCore 會消除所有營運工作。依賴項管理在後續 harness 階段前仍屬客戶責任，而 AWS 代管的基礎架構也不會移除應用程式層級安全決策的需求。

超越客戶支援的正式環境案例

第二篇 AWS 文章將 AgentCore 套用到另一類工作負載：架構文件。根據 AWS，一家全球 interdealer broker 自 2026 年第一季起已在正式環境中運行此系統，用以維護其電子交易平台的文件。文章未提及客戶名稱，因此無法根據所提供證據獨立評估該採用說法。

工作流程在程式碼變更進入 AWS CodeCommit repository 時開始。AWS CodeBuild 取回 .NET 程式碼、進行封裝，並呼叫一個託管於 AgentCore 的 Strands 代理。該代理聚焦於正式程式碼，排除測試、建置產物與生成檔案，接著分析介面、抽象類別、實作與相依性。

該代理產生 Mermaid 圖表語法、驗證圖表、將其轉換為 SVG，並且在驗證失敗時可反覆修正。產生的 SVG 檔案、Mermaid 原始碼與 metadata 會儲存在 Amazon S3。之後 Amazon Bedrock Knowledge Bases 會擷取這些資產，並使用 Amazon Titan Text Embeddings v2 支援語意搜尋與檢索增強生成。

開發者與利害關係人可以用自然語言查詢生成的文件，包括關於服務流程或特定類別的問題。AWS 將這種反覆精修與自我修正描述為相較於一次性生成更可靠的優勢，但這仍是 AWS 對其解決方案的說明，而非獨立報導的基準測試。

證據、主張與限制

這兩個來源都是 AWS 撰寫的技術文章，因此產品能力、架構圖與實作步驟都屬於供應商控制的證據。它們有助於理解 AWS 期望如何部署 AgentCore，但並不能建立與其他代理平台之間獨立的效能比較。

遷移文章提供了少見且具體的實作細節。AWS 報告，在其固定範例中，代理內部有 45 行被修改、22 行支援程式碼被新增，而 85 行維持不變。這些數字只描述該特定範例；不應被視為適用於具有不同狀態模型、工具、安全控制或網路布局的正式系統之一般遷移估算。

架構文件文章提供了正式使用的主張，但沒有客戶名稱、工作負載量、準確度衡量、成本資料或失敗率。它也沒有量化移除了多少人工文件工作。評估這種做法的買家，在假設會有類似結果之前，仍需要來自自己 repository 與部署管線的證據。

技術前提也很重要。這個操作示範需要一個可存取 Amazon Bedrock 模型的 AWS 帳號、能建立 AgentCore、Lambda、Amazon S3 與 IAM 資源的 AWS CLI 憑證，以及已啟用的 CloudWatch Transaction Search 以便查看 traces。這些要求明確將遷移限制在 AWS 的安全、權限與區域模型可用性邊界內。

AgentCore 對建置者與企業的意義

對工程團隊而言，最清楚的價值主張是職責分離。團隊可以保留既有的 LangGraph workflow，同時將主機代管、工具仲介與持久狀態移到代管服務上。這能降低基礎架構遷移的影響範圍，並讓團隊拿記錄下來的 baseline 比較行為。

對於本來就要重寫代理的團隊，基於 Strands 的規劃階段提供了另一種取捨。模型驅動的規劃或許可減少手寫路由邏輯，但也可能在工具選擇與執行上引入更多變動。AWS 的指南強調一個重要觀點：轉向 Runtime 並不代表必須接受這種取捨。

企業買家應聚焦於 AgentCore 仍保留的邊界。IAM、VPC 設定、WAF 規則、secrets 與授權政策，仍需要設計與治理。AWS 表示，Amazon Bedrock Guardrails 可以過濾有害內容、檢查與來源文件的 grounding，並阻擋 prompt injection 嘗試；但這些控制並不能取代應用程式測試或工作流程專屬的核准規則。

架構文件案例也顯示 AgentCore 在營運上可能的切入點：不只用於對話式支援，也可用於事件驅動的管線，檢查程式碼、呼叫工具、產生資產、驗證輸出，並將其發布供搜尋。這將相關買家群擴大到平台工程、開發者生產力、法遵與架構團隊。

接下來要關注什麼

下一批重要訊號將是針對較大工作負載下 AgentCore 的營運成本、延遲、擴展行為與失敗處理的獨立測量。AWS 的範例建立的是遷移模式，而不是通用的正式環境基準。

團隊也應留意 AgentCore 如何與 AWS 以外的模型供應商、外部身分系統與既有可觀測性堆疊整合。指南稱該平台支援任何框架或模型，但示範路徑高度依賴 AWS 服務、IAM、Lambda、CloudWatch、S3 與 Bedrock。

最後，採用證據將很重要。那個未具名的 broker 部署是有用的參考點，但更多可辨識的客戶案例、工作負載指標與安全評估，會更有助於判斷 AgentCore 是在降低營運負擔，還是只是將其在 AWS 平台內重新分配。

Creati.ai 觀點

AWS 正提出一個可信的基礎架構論點：讓代理正式上線，遠不只是選擇一個模型或寫一個工具迴圈。分階段遷移尤其實用，因為它把主機代管與狀態管理的變更，和讓模型主導規劃這個更關鍵的決策分開來。

不過，目前的證據幾乎完全來自 AWS 自身。AgentCore 的重要性，將取決於團隊是否能在不放棄對身分、網路、可靠性與成本控制的前提下，證明營運工作量有所下降。就目前而言，這些文章展示的是清楚的 AWS 部署模式與早期正式環境參考，而不是決定性的市場優勢。