2026 年 Amazon Bedrock AgentCore 看不到追蹤資料怎麼辦？

AgentCore 呼叫已經送出，CloudWatch 卻找不到可用的日誌或追蹤資料。 最快做法：先確認 CloudWatch Transaction Search 與 AgentCore 資源的可觀測性設定，再核對資料目的地、權限和查詢範圍；若 Agent 不由 AgentCore Runtime 託管，還要檢查應用程式是否已設定 OpenTelemetry 埋點。

正在排查 AgentCore Runtime 呼叫失敗、但手上沒有追蹤線索的開發者，可以由症狀開始定位。 負責設定 CloudWatch 日誌與追蹤的平台工程師，可用下列檢查順序縮小範圍。 需要為正式環境 Agent 建立可重複排障流程的技術負責人，也可直接採用文末的記錄格式。

先辨別呼叫失敗、日誌缺失與追蹤缺失

「CloudWatch 沒資料」不是單一故障類型。若呼叫本身沒有成功送達 Runtime，首先要沿著呼叫端、Runtime 狀態與錯誤回應排查；若呼叫成功但沒有日誌，應看日誌設定與目的地；若有日誌或指標、唯獨沒有 spans，則應檢查追蹤設定、Transaction Search 及應用程式埋點。

開始查詢前，先把下列範圍對齊：

• 帳戶與 Region：確認你查看的是實際執行 AgentCore 資源的帳戶和 Region；跨帳戶登入或切換 Region 後，原有查詢不一定會帶到正確範圍。
• Runtime 資源：確認目前查詢對應的 Runtime，而不是測試用或舊版資源；同名 Agent 不代表使用同一個 Runtime。
• 時間範圍：將查詢時間涵蓋在實際請求發生的時段，並留意介面目前使用的時區與時間篩選條件。
• 請求是否抵達：對照呼叫端收到的回應、Runtime 狀態與錯誤資訊。沒有成功送達的請求，不應期待出現完整的 Agent 呼叫追蹤。

AWS 將 AgentCore 可觀測性資料分為不同類型，不能用「看得到指標」推定「一定有 spans」。可先參考AgentCore 可觀測性資料類型說明，再依你缺少的資料類型逐項檢查。

為什麼 AgentCore CloudWatch 查不到 trace？

要查 AgentCore CloudWatch 追蹤資料，先確認 CloudWatch Transaction Search 是否已啟用，以及相關資料是否已具備可搜尋條件。這是帳戶層級的功能設定，不等同於某一個 Runtime 已完成資源遙測設定；兩者都正常，也不代表查詢條件一定涵蓋該次請求。

依照Transaction Search 啟用說明，核對帳戶設定與所需權限，再確認 AgentCore 資源是否有產生並送出相應追蹤資料。若剛完成啟用或修改設定，先確認設定已生效，再以較寬的時間範圍重查。文件中的操作範例不應視為所有帳戶、Region 或執行方式下的固定等待時間。

另外，追蹤資料的檢視位置可能與你預期的日誌頁面不同。AWS 的Runtime spans 檢視說明提供了定位線索；不要只在一般日誌串流裡搜尋 trace，就判定資料沒有產生。

指標看得到，為什麼 spans 和日誌仍然缺席？

AgentCore Runtime、Memory、Gateway 等資源的遙測設定並不應視為同一個開關。每種資源需要依其配置文件確認可用資料類型、日誌設定及目的地；部分指標可依資源文件查看，日誌或 spans 則可能需要另外配置。對照AgentCore 遙測設定文件與Runtime 遙測資料說明，逐項確認你使用的資源與執行方式，不要把某一類資料的預設行為套用到其他資源。

目的地也要單獨核實。檢查設定目前指向的日誌群組或追蹤服務、資源所在 Region，以及相關資源是否存在且可讀。AgentCore 的目的地設定可能隨文件版本更新；可對照官方發布紀錄中的目的地變更資訊，不要只依據先前部署時複製的範例推斷目前設定。

提醒：若你開啟請求載荷或應用程式內容記錄，先確認其中是否可能包含個人資料、憑證、提示詞或客戶輸入。排障需要的追蹤欄位，應與可直接識別使用者或重建敏感內容的資料分開評估。

自託管 Agent 沒有追蹤資料，該先檢查什麼？

若 Agent 並非由 AgentCore Runtime 託管，AgentCore 資源設定不會自動替應用程式建立完整埋點。你需要確認應用程式使用的 OpenTelemetry SDK 是否已初始化、Agent 框架是否產生 spans，以及遙測環境變數與匯出設定是否指向預期的接收端。

先用同一個測試請求，在本機與雲端各執行一次，並保留相同的請求識別值或可安全比對的業務識別值。若本機能看到 spans、雲端看不到，優先比較兩邊的環境變數、執行角色、網路連線和匯出目的地；若兩邊都沒有，先回到 SDK 初始化與框架埋點，不必先改 CloudWatch 查詢。AWS 的可觀測性入門指南可作為官方設定步驟的核對依據。

例如，你在本機測試時能追到模型呼叫和工具執行，但部署後只剩 Runtime 指標，這更像是應用程式 spans 沒有匯出，或雲端執行環境沒有載入預期設定；只調整 CloudWatch 篩選條件，未必能補回未送出的資料。排查時應比較實際生效的設定，而不是只看部署檔裡是否寫了環境變數。

用症狀選下一個檢查點

依你觀察到的結果採取對應分支，避免同時修改多個設定，否則很難確認是哪一項改動有效：

• 若 Runtime 呼叫失敗且沒有日誌：先確認請求是否抵達正確 Runtime，再檢查資源日誌設定、目的地與執行角色權限；接著參考Runtime 故障排查文件對照錯誤類型。
• 若有指標但沒有 spans：先檢查 Transaction Search 是否啟用，再核對 Runtime 或應用程式的追蹤設定；若 Agent 是自託管，回頭確認 OpenTelemetry 初始化與匯出。
• 若有 spans 但日誌空白：檢查日誌是否另行設定、目的地是否正確，以及日誌檢視頁面使用的帳戶、Region 和時間範圍。
• 若同一帳戶部分資源有資料、部分沒有：逐一比對 Runtime、Memory 或 Gateway 的遙測配置與日誌目的地，不要用一個資源的成功設定代表其他資源。
• 若跨帳戶查不到資料：確認你登入的帳戶、查詢範圍與角色是否具有讀取目標資料的權限；先在資源所在帳戶驗證資料是否存在，再追查跨帳戶存取設定。

追蹤缺失時，不宜把「權限」和「目的地」當成二選一。你可以先確認目的地設定指向哪裡，再以實際執行角色核對對該目的地的存取權；若目的地根本不正確，擴大權限不會讓資料出現在預期位置。Runtime 所需權限可對照AWS 的 Runtime 權限文件。

建立可重複使用的排障記錄

每次調整只記錄一項變更，以及調整前後的查詢結果。排障記錄至少包括：發生時間與時區、帳戶和 Region、Runtime 識別資訊、請求是否成功抵達、缺少的是日誌／指標／spans、Transaction Search 狀態、遙測設定、資料目的地、執行角色，以及查詢時間範圍。記錄請求識別資訊時，先移除或遮蔽載荷、憑證及個人資料。

需要釐清服務使用或帳戶操作問題時，可從kvmboot 說明中心查找相關協助；若要整理環境需求，也可透過kvmboot 聯絡頁面說明你的測試方式與資源類型。這些管道不能取代 AWS 權限或遙測設定核查，但能協助你把問題描述整理完整。

排查後，何時需要另一套測試環境？

若你的 Agent 長期運作在 AWS，應優先補齊正式環境的遙測、權限和告警；租用 Mac 不能取代 AgentCore 的 CloudWatch 追蹤，也不適合需要長期穩定重負載或實體介面直連的工作。相較之下，臨時建立雲端測試環境可能需要處理權限與目的地設定、追蹤查詢範圍不一致，以及測試資源未能重現本機問題等成本。

如果你需要的是短期驗證程式、重現本機與雲端行為差異，或測試 Apple 平台相關工作流程，租用 kvmboot Mac 可作為額外的測試環境；它適合補充本機驗證，不應被當成正式 Agent 遙測方案的替代品。你可先評估kvmboot 美國東部方案，再按專案需求決定是否需要臨時 Mac 環境。