AgentCore 上的多代理

場次筆記

挑戰

故障期間的傳統工作流程

• 檢查雲端資源狀態
• 發生故障
• 查看事件歷史記錄
• 檢查設定
• 檢查警示
• 指派工單
• 分析日誌
• 推測根本原因
• 搜尋解決方案
• 檢查指標
• 分析相依關係
• 查看近期更新
• 搜尋呼叫鏈
• 查看維運手冊
• 查詢服務儀表板
• 執行緩解措施
• 通知同事
• 查詢異常指標
• 閱讀手冊
• 監控復原狀態。核心挑戰
• 及時減輕損失
• 故障隔離
• 在可接受的時間範圍內解決問題
• 將故障限制在隔離邊界內，避免對其他服務產生連鎖影響，進而縮小故障影響範圍
• 確保服務符合使用者期望與 SLA

解決方案演進

• 從單一代理演進至多代理解決方案。理想解決方案：系統通知與警示
• 警示指標：5xx 比率超過 30%
• 警示詳細資料：服務、端點、觸發時間。補充根本原因分析。主要發現：API 錯誤率 100%，DB 無錯誤，S3 bucket 政策已更新。
• 立即動作：檢查 S3 bucket 政策是否為 Deny
• 信賴度：90%。確認自動操作
• 訊息：系統已復原（原文：System Revered）。
• RCA：S3 bucket 政策設為 Deny
• MTTR：5 分鐘
• 將故障復原時間從數小時縮短為數分鐘。SRE 專家的工作範圍
• 為什麼我的 User Service 錯誤率在過去一小時內達到 5%？
• 因為 RDS MySQL 執行個體在過去一小時內發生 12 次超過連線上限的問題
• 熟悉目前系統
• 找出服務關聯性
• 分析日誌
• 分析稽核日誌
• 分析設定
• 分析指標。思考兩個問題

1. 如果系統複雜度高、疑難排解工作流程很長，而且日誌量龐大，單一代理能否順暢運作？

2. 是否可以將 SRE 專家的經驗複製到代理中，以取代問答方式，讓代理能自主決策及採取行動？

多代理架構設計

• 「Planner」建立工作流程
• 「Executor」負責執行指派的任務
• 「Evaluator」負責評估每個步驟的結果是否有助益，再交回「Planner」進行後續規劃
• 結果在傳回前也需要由「Evaluator」審查
• 「Planner」可根據「Evaluator」的意見回饋調整流程。多代理 vs 單一代理

1. 適合更複雜的任務

2. 責任與權限邊界更清楚

3. 更容易進行情境工程

4. 更方便擴展規模。AgentCore 最佳實務：代理專用執行環境簡介

• 從「試用」到「實作」的挑戰
• 從 PoC 到正式環境實作的挑戰
• 效能
• 彈性
• 安全性
• 創造商業價值
• 合規性

代理執行環境 v1.0

• 介面與通訊協定 (MCP/A2A)
• 代理部署
• 代理框架
• 大型語言模型
• 記憶
• 提示
• 工具／資源
• 防護機制
• 可觀測性
• 評估。代理執行環境 v2.0
• 介面與通訊協定 (MCP/A2A)
• 代理部署
• Amazon Bedrock
• AgentCore
• 代理框架
• 大型語言模型執行環境
• 記憶
• 提示
• 工具／資源
• 身分識別工具
• 防護機制
• Gateway
• 可觀測性
• 評估。專門化
• Amazon Q Agents。完全受管
• Amazon Bedrock Agents。自行建置
• OSS 框架、Strands Agents SDK