AWS 已發布一份技術指南，說明如何將在其雲端以外執行的 AI 代理遙測傳送至 Amazon Bedrock AgentCore Observability。這項做法涵蓋地端環境、開發者電腦、Google Cloud Platform 和 Microsoft Azure，讓團隊能使用 AWS 儀表板，而不必將代理工作負載本身搬到 AWS。

這份指引之所以重要，是因為 AgentCore Observability 無法原生監控部署在 AWS AgentCore 執行環境之外的代理。AWS 文件中的替代方案結合了 AWS Distro for OpenTelemetry（ADOT）、Amazon CloudWatch 與 AWS Identity and Access Management（IAM）憑證，從外部環境收集追蹤、指標與日誌。

將 AgentCore 擴展到 AWS 託管執行環境之外

Amazon Bedrock AgentCore 被 AWS 定位為一個平台，可用來建構、連接與最佳化以不同框架與模型打造的代理。其可觀測性功能旨在揭示代理執行、工具呼叫、模型活動與 token 使用量等細節。

根據 AWS Machine Learning Blog，原生支援主要聚焦於在 AWS Cloud 中 AgentCore 執行環境上執行的代理。部署於 Amazon Elastic Kubernetes Service、Amazon Elastic Container Service 或 AWS Lambda 的代理可使用 AWS 原生整合模式，而 AWS 之外的工作負載則需要額外設定。

新文件化的設定不會搬移這些工作負載。相反地，ADOT 會與代理應用程式並行執行，並為支援的框架與模型呼叫進行 instrument。產生的遙測會匯出至 Amazon CloudWatch OpenTelemetry Protocol 端點，並可進一步供應 AgentCore Observability 儀表板。

AWS 的範例引用了使用 Strands Agents、LangGraph 與 CrewAI 建構的代理。這使得該指南與標準化採用不同代理框架的團隊相關，而不是將可觀測性視為綁定於單一應用程式堆疊的功能。

跨雲遙測管線如何運作

這項設定有三個主要部分。首先，ADOT 為應用程式提供自動 instrument。AWS 表示，OpenTelemetry 發行版可以為 Amazon Bedrock 呼叫修補 boto3，並為 Strands 框架進行 instrument，讓與推理相關的 span 與生成式 AI 語意慣例資料得以輸出。

其次，外部環境需要具備可將遙測傳送至 AWS 服務的 IAM 憑證。指南中列出的權限包括 CloudWatch 指標、建立與擷取日誌，以及 AWS X-Ray 追蹤操作的存取權。此設定也需要對 AWS 端點的對外 HTTPS 連線。

第三，環境變數定義 OpenTelemetry 的路由與驗證設定。遙測在傳送至 CloudWatch 端點之前，會先使用 AWS Signature Version 4，也就是 SigV4 進行驗證。接著 CloudWatch 提供擷取與儲存層，而 AgentCore Observability 則提供針對代理活動調整的儀表板。

AWS 也指出，CloudWatch Transaction Search 是每個帳戶只需啟用一次的前置條件。該指南的範例使用 Amazon Bedrock 模型存取與 Claude Haiku，儘管核心流程是在於從外部代理匯出遙測，而非引入新模型。

證據、主張與仍然存在的限制

這項發展的主要證據來自 AWS 自己的技術部落格文章與設定說明。提供內容中的另一則 AWS 項目並沒有額外文章文字、客戶證詞或獨立驗證。因此，關於儀表板價值、框架支援廣度與營運效益的說法，都應視為供應商報導的指引，而非獨立測得的結果。

AWS 將這些遙測描述為能提供對推理鏈、工具呼叫與模型輸出的可視性。AWS 認為，這種可視性能幫助團隊找出幻覺、有害或偏離主題的回應，追蹤 token 消耗，並稽核行為。這些都是合理的可觀測性使用情境，但文章並未提供能顯示偵測準確率、延遲開銷、成本節省或使用該設定的部署數量的基準測試結果。

這項公告也有一個重要界線。這種做法建立了一條跨平台監控路徑；它並不會讓 AgentCore Observability 成為完全本地或雲端中立的服務。外部代理仍會將遙測送入 AWS 服務，團隊則必須管理相關 IAM 權限、網路存取、CloudWatch 設定與資料處理政策。

這一點對於資料駐留規範、安全架構或採購策略會限制將提示、輸出或追蹤細節傳送到第三方雲端的組織尤其重要。這份指南提供的是技術路徑，而不是證明每一項企業需求都已被滿足。

這對 AI 建構者與企業團隊的意義

對開發者而言，最大的好處是營運一致性。團隊可以在開發期間於本機執行代理，在正式環境中於私人資料中心執行，或在其他雲端供應商上執行，同時將執行資料送到單一 AWS 監控介面。這可能降低為每個部署位置建立不同儀表板的需求。

這些資料也能支援實務除錯。追蹤可將使用者工作階段連結到模型呼叫、工具呼叫與後續步驟，使調查比單一提示-回應交換更複雜的工作流程故障變得更容易。token 使用量也可作為成本監控的基礎，特別是在代理反覆呼叫模型或工具時。

然而，對企業採購者來說，集中化也帶來取捨。IAM 存取金鑰與包含模型輸入或輸出的遙測必須受到保護、範圍限定並加以治理。團隊需要決定哪些欄位可安全匯出、記錄應保留多久，以及 CloudWatch 與 AgentCore Observability 是否符合其合規邊界。

即使運算仍留在其他地方，這項設定也會產生某種程度的 AWS 依賴。使用 GCP、Azure 或地端基礎設施的建構者可以保留部署彈性，但 AWS 所描述的監控控制平面、驗證模型與儲存路徑仍與 AWS 服務綁定。這對 AWS 中心化的組織可能很有吸引力，對追求供應商中立 OpenTelemetry 堆疊的公司則可能沒那麼有說服力。

接下來要觀察什麼

最直接的訊號將是 AWS 是否會將 AgentCore Observability 的原生支援擴展到 AgentCore 執行環境之外，或持續依賴基於 ADOT 的外部工作負載整合。關於額外框架 instrument 與模型供應商的文件，將顯示此模式超出文章範例後可涵蓋的廣度。

評估此做法的團隊也應留意有關遙測成本、匯出延遲、取樣控制、保留選項與資料遮罩的具體資訊。獨立的導入報告將有助於確認這項設定在正式生產規模下是否可行，而不只是能依照教學範例重現。

最後，市場也會觀察其他雲端供應商是否推出類似的跨環境代理監控。隨著 AI 代理 分散到私有基礎設施與多個雲端，觀測性可能成為團隊決定將工作負載部署在哪裡的關鍵因素。

Creati.ai 觀點

AWS 並不是在宣布外部代理現在可原生在 AgentCore Observability 內執行。它是在文件中說明一座橋接，透過 ADOT 與 CloudWatch 將服務的可視性延伸到部署在其他地方的工作負載。這是一項有意義的營運改善，但其效用取決於團隊是否接受 AWS 作為遙測控制平面。

對建構者而言，最強烈的啟示是架構層面的：代理監控必須跨越模型、工具與部署環境，隨著工作流程一起移動。AWS 的做法降低了已投資其服務的組織在整合上的成本，但所需的憑證與資料路由，也讓安全性、可攜性與成本問題成為任何正式上線的核心。