Agentic AI基礎設施實踐經驗系列（七）：可觀測性在Agent應用的挑戰與實踐詳情 - 人工智能亞馬遜雲開發者博客

一. 引言：

我們正處在一個由 AI Agent 驅動的範式轉換前夜。它們不再只是簡單的文本生成器，而是能夠理解複雜指令、自主規劃多步任務，並調用各類 API 與數字世界交互的“數字工作者”；在為大型語言模型增加“執行臂膀”後，Agent 正在成為企業應用中的“能力放大器”。

過去，當我們監控傳統微服務或 Web 應用時，“Metrics → Logs → Traces” 的可觀測模型已足夠應對。但在 Agent 場景，它只能告訴我們“發生了什麼”，卻無法解釋“為什麼會這樣”——也無法指明“下一步該怎麼辦”。一旦將關鍵業務流程託付給 Agent，黑盒效應便迅速顯現：

決策的“原因”：為何 Agent 選擇在此時發起特定調用？它基於怎樣的上下文與推理？
行為的“鏈條”：在這次調用之前，Agent 是否已經與用户或其他工具反覆交互？這一步是解決方案的關鍵，還是誤入歧途的昂貴嘗試？
結果的“質量”：返回的內容是否真正提升了任務完成度，還是引入了新的偏差或錯誤？

在下文中，我們將結合 Amazon Bedrock、Amazon Bedrock AgentCore、Amazon CloudWatch 等原生能力，構建一套從行為洞察到質量評估、從成本監控到閉環優化的多維度可觀測框架。

📢限時插播：無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。
⏩快快點擊進入《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》實驗構建無限, 探索啓程！

二. Agent 可觀測性詳解

Agentic AI可觀測性是一個多維度的概念，它不僅包括傳統應用監控中的指標，還需要特別關注AI特有的行為特徵。在Agent系統中，我們需要監控從用户輸入到最終輸出的整個處理流程，包括模型調用、推理過程、工具使用等各個環節。這種全方位的監控能力使我們能夠及時發現問題、優化性能、提升用户體驗。對於Agent系統，這裏主要需要關注指標、追蹤兩方面。

重要指標

響應時間指標：時間相關的指標是評估Agent性能的重要維度。其中最關鍵的是以下幾個指標：

總體請求處理時間（TotalTime）：這個指標衡量了從接收用户請求到生成最終響應的完整時間。例如，當用户詢問”巴黎的天氣如何？”時，系統可能需要500ms來理解問題，300ms調用天氣API，再用200ms生成回答，總計1000ms。監控這個指標可以幫助我們發現性能瓶頸，優化響應速度。
首個token生成時間（TTFT）：這是衡量系統響應速度的關鍵指標。它記錄從請求開始到生成第一個響應token的時間。比如，如果系統在接收到問題後能在200ms內開始生成回答，這表明系統的初始響應速度較快。這個指標對於提供流式響應的系統特別重要。
模型延遲（ModelLatency）：專門衡量模型推理所需的時間。通過監控這個指標，我們可以評估不同模型的性能表現，為特定場景選擇最適合的模型。

Token使用指標：Token使用情況直接關係到系統的運營成本和效率

輸入Token數量（InputTokenCount）：記錄發送給模型的token數量。例如，一個包含系統提示詞、上下文歷史和用户問題的請求可能使用了1000個token。這個指標幫助我們優化提示詞設計和上下文管理策略。
輸出Token數量（OutputTokenCount）：統計模型生成的token數量。比如，一個詳細的天氣報告響應可能產生200個token。監控這個指標有助於控制響應的簡潔度和成本。

工具使用指標：Agent系統中的工具調用情況也需要密切監控：

調用頻率（InvocationCount）：記錄每個工具被調用的次數。例如，在一個客服Agent中，可能發現知識庫查詢工具的使用頻率是訂單查詢工具的三倍，這樣的信息可以指導我們優化工具的設計和緩存策略。
工具執行時間：監控每個工具的執行耗時。比如，如果發現天氣API的平均響應時間超過800ms，可能需要考慮更換更合適的模型或實施緩存機制。

Agent追蹤：完整的執行鏈路視圖

在傳統的可觀測性三支柱中，追蹤（Tracing）對於Agent系統具有獨特且至關重要的價值。與指標和日誌相比，追蹤能夠提供Agent決策過程的完整上下文鏈路，這對於理解和優化AI系統的行為模式至關重要。傳統指標雖然能夠反映系統的健康狀況和性能特徵，但無法解釋Agent在特定情境下做出某個決策的原因。日誌雖然提供了詳細的事件記錄，但往往缺乏跨服務的關聯性，難以構建完整的執行圖譜。而追蹤數據通過span的層次化結構，能夠精確記錄Agent從接收用户輸入、理解意圖、規劃執行路徑、調用工具、生成響應的完整決策鏈條。這種端到端的可見性使開發者能夠快速定位性能瓶頸、識別錯誤根因，並深入理解Agent的推理邏輯。

根據Amazon X-Ray和OpenTelemetry的最佳實踐，Agent場景下的追蹤數據不僅記錄了”發生了什麼”，更重要的是揭示了”為什麼這樣發生”以及”各個組件之間如何相互作用”。具體而言，Agent追蹤系統需要關注以下幾個核心維度：

Agent執行追蹤：提供完整的執行鏈路視圖，包括系統級追蹤和推理週期追蹤。系統級追蹤記錄每個請求的完整生命週期，從用户輸入、系統提示詞到最終響應的全過程，形成完整的執行圖譜幫助理解Agent的決策過程。推理週期追蹤則深入到每個推理步驟的細節，詳細記錄當前思考步驟的內容、工具調用的決策過程以及中間結果的處理方式，這些信息對於調試複雜的推理鏈特別有價值。
錯誤和異常追蹤：系統中的錯誤和異常需要特別關注，主要包括客户端錯誤和服務器錯誤兩類。客户端錯誤記錄由客户端引起的問題，如參數錯誤、認證失敗等，這些信息幫助改進API設計和文檔。服務器錯誤則追蹤服務器端的異常情況，如模型調用失敗、資源不足等，這類信息對於提升系統可靠性至關重要。

而這些內容均可通過Opentelemerty 協議記錄並傳輸到後端以供分析。在OpenTelemetry的追蹤體系中，每個操作都有對應的span ID和trace ID，這兩個標識符構成了分佈式追蹤的核心骨架。Trace ID代表Agent執行循環中的一次完整會話，從用户發起請求到Agent返回最終結果的整個生命週期都會共享同一個trace ID。而span ID則代表這個執行循環中的每個具體操作，如模型調用、工具執行、上下文檢索等，每個span ID都是唯一的，並通過父子關係構建起完整的執行樹狀結構。在Agent場景中，一個trace包含了從用户輸入到最終響應生成的所有中間步驟，每個步驟都通過span來表示。Agent traces通常包含模型調用span和工具調用span，這些span會根據其追蹤的步驟類型，被豐富的上下文信息所充實。

圖1. Agent完整執行鏈路

除了標準屬性外，OpenTelemetry還提供了baggage機制來傳遞自定義的跨服務元數據。Baggage是一種分佈式上下文傳播機制，允許開發者在整個請求鏈路中傳遞業務相關的鍵值對信息。例如，可以通過baggage傳遞用户類型、實驗標識、會話主題等業務屬性，這些信息會自動附加到所有相關的span中，為後續的離線評估、性能分析和A/B測試提供寶貴的上下文。通過合理使用baggage機制，開發者可以實現更精細化的Agent行為分析和優化。

圖2. OpenTelemetry span機制

許多Agent框架已自帶Opentelemetry支持，但仍需要將Opentelemetry SDK嵌入應用中。對於採用Python開發的Agent，可使用自動注入方式，利用 opentelemetry-instrument 命令將SDK自動嵌入到應用中。這一命令會自動化配置流程，從參數或環境變量中生成Opentelemetry配置，並自動將SDK附加至Agent的內部，亞馬遜雲科技調用，或其他的外部調用中。這樣，Agent的所有操作都會被Opentelemetry記錄並傳輸到後端。

下面是一段跟蹤數據的樣本：

{
    "name": "chat",
    "context": {
        "trace_id": "0x68888fcdba6326c1fc004fe9396ad6a8",
        "span_id": "0x4f4c5c4caf92a36d",
        "trace_state": "[]"
    },
    "kind": "SpanKind.CLIENT",
    "parent_id": "0xbc776902450f8294",
    "start_time": "2025-07-29T09:09:33.427326Z",
    "end_time": "2025-07-29T09:09:34.932205Z",
    "status": {
        "status_code": "OK"
    },
    "attributes": {
        "session.id": "session-1234",
        "gen_ai.event.start_time": "2025-07-29T09:09:33.427342+00:00",
        "gen_ai.system": "strands-agents",
        "gen_ai.operation.name": "chat",
        "gen_ai.request.model": "us.anthropic.claude-3-5-haiku-20241022-v1:0",
        "gen_ai.event.end_time": "2025-07-29T09:09:34.932173+00:00",
        "gen_ai.usage.prompt_tokens": 443,
        "gen_ai.usage.input_tokens": 443,
        "gen_ai.usage.completion_tokens": 76,
        "gen_ai.usage.output_tokens": 76,
        "gen_ai.usage.total_tokens": 519
    },
    "events": [
        {
            "name": "gen_ai.user.message",
            "timestamp": "2025-07-29T09:09:33.427368Z",
            "attributes": {
                "content": "[{\"text\": \"Research and recommend suitable travel destinations for someone looking for China traditional culture experience in Beijing city. \\nUse web search to find current information about venues, \\nevents, and attractions.\"}]"
            }
        },
        {
            "name": "gen_ai.choice",
            "timestamp": "2025-07-29T09:09:34.932167Z",
            "attributes": {
                "finish_reason": "tool_use",
                "message": "[{\"text\": \"I'll search for the best traditional cultural experiences in Beijing.\"}, {\"toolUse\": {\"toolUseId\": \"tooluse_JSt-cJ9fRU28RmhdJ1XENA\", \"name\": \"web_search\", \"input\": {\"query\": \"Top traditional cultural attractions and experiences in Beijing 2024\"}}}]"
            }
        }
    ],
    "links": [],
    "resource": {
        "attributes": {
            "telemetry.sdk.language": "python",
            "telemetry.sdk.name": "opentelemetry",
            "telemetry.sdk.version": "1.33.1",
            "service.name": "agentic-travel-strands",
            "telemetry.auto.version": "0.10.0-aws",
            "aws.local.service": "agentic-travel-strands",
            "aws.service.type": "gen_ai_agent"
        },
        "schema_url": ""

從這個示例中可以看到，Strands Agent框架已經內置了對OpenTelemetry的深度集成支持。根據Strands官方文檔，該框架遵循OpenTelemetry GenAI語義約定，會自動將Agent的內部決策過程以標準化的事件（event）形式發送至追蹤後端。這種自動化的遙測數據收集機制大大簡化了Agent應用的可觀測性實現，開發者無需手動編寫複雜的追蹤代碼，即可獲得生產級別的監控能力。

Strands Agent的OpenTelemetry集成特別針對GenAI工作負載進行了優化，能夠自動捕獲Agent執行過程中的關鍵信息，包括用户消息、系統提示詞、模型推理結果、工具調用參數和返回值等。每個操作都會被封裝為符合OpenTelemetry語義約定的span，並通過 Baggage 機制，自動添加相應的屬性標籤。

從上面的示例中可以看到，常用的元數據包括session.id（會話標識符）、gen_ai.system（AI系統標識，如strands-agents）、gen_ai.operation.name（操作名稱，如chat）、gen_ai.request.model（請求的模型名稱）以及各種token使用統計信息。這些元數據對於後續的數據分析和問題診斷至關重要。這些標準化的屬性遵循OpenTelemetry GenAI語義約定，確保了不同Agent框架和監控平台之間的互操作性。

默認情況下，Agent應用產生的遙測數據會通過OTLP（OpenTelemetry Protocol）協議直接發送到CloudWatch的OTLP端點，這種直連方式簡化了部署架構，減少了額外的基礎設施維護成本。然而，在生產環境中，為了實現更靈活的數據處理和路由策略，通常會在數據源和目標系統之間部署OpenTelemetry Collector作為中間處理層。

OpenTelemetry Collector是一個功能強大的獨立服務組件，專門用於接收、處理和導出遙測數據到多個目標系統。其架構採用了管道化設計，包含三個核心組件：Receivers（接收器）負責從各種數據源收集遙測數據，Processors（處理器）對數據執行轉換、過濾、採樣、屬性增刪等操作，Exporters（導出器）將處理後的數據發送到指定的後端系統。

在Agent可觀測性場景中，Collector的處理器組件尤其有價值。例如，可以使用attributes處理器為特定的Agent span添加環境標籤或業務標識，使用sampling處理器對高頻操作進行智能採樣以控制數據量，使用filter處理器過濾掉敏感信息或無關數據，使用batch處理器優化網絡傳輸效率。這種流水線式的數據處理能力使企業能夠根據具體需求定製化Agent遙測數據的收集和分發策略，實現成本效益的最優平衡。

三. 實踐方式：開源生態以及亞馬遜雲科技託管方案

在理解了Agent可觀測性的核心概念和關鍵指標後，我們需要將這些理論轉化為實際的技術實現。亞馬遜雲科技生態系統為Agent可觀測性提供了完整的託管解決方案，同時開源社區也貢獻了豐富的第三方工具。接下來，我們將詳細探討如何在不同的技術棧和部署環境中實現Agent的全方位監控。

3.1 Amazon Cloudwatch GenAI Observability

Amazon Cloudwatch GenAI Observability 專門用於監控生成式AI工作負載，包括Amazon Bedrock AgentCore Runtime。它提供：

1、端到端提示詞跟蹤(End-to-end prompt tracing) – 跟蹤 AI Agent 的所有行為（包含大模型推理和工具調用）

2、預配置儀表板 – 提供兩個內置儀表板：

Model Invocations – 詳細的模型使用、token消耗和成本指標
Amazon Bedrock AgentCore agents – 代理的性能和決策指標

3、關鍵指標監控：

總調用次數和平均調用次數
Token使用情況（總數、每查詢平均數、輸入、輸出）
延遲（平均值、P90、P99）
錯誤率和限流事件
按應用程序、用户角色或特定用户的成本歸因

GenAI Observability的核心是Cloudwatch Transation Search，GenAI Observability利用Cloudwatch Transation Search收集並轉換的結構化日誌進行AI工作負載的深度分析。

亞馬遜雲科技在現有X-ray跟蹤服務的基礎上，推出了CloudWatch Transaction Search。Transaction Search最核心的創新在於其雙重存儲策略，這一設計巧妙地平衡了成本效益與數據完整性。當用户啓用Transaction Search時，所有發送到X-Ray的spans都會被自動轉換為語義約定格式（semantic convention format），並以結構化日誌的形式存儲在CloudWatch Logs的專用日誌組aws/spans中。這個轉換過程完全透明，spans會自動採用W3C trace ID標準，確保與OpenTelemetry生態系統的完整兼容性。每個span都包含完整的追蹤信息：開始時間、結束時間、持續時間，以及豐富的元數據，包括業務屬性如客户ID、訂單ID等。這些數據全部可以進行搜索和分析，完全消除了傳統採樣帶來的”盲區”問題。

Transaction Search提供的搜索能力遠超傳統X-Ray的範疇。通過可視化編輯器，用户可以基於任意span屬性進行搜索，包括服務名稱、span持續時間、狀態碼，以及自定義的業務屬性。系統支持多種查詢格式，List格式專注於單個span的詳細分析，特別適合故障排查。當出現問題時，工程師可以直接使用對應的業務ID快速定位相關的trace，然後深入分析具體的執行路徑。Group analysis格式提供聚合分析能力，可以按照可用區、狀態碼或客户ID等維度進行分組統計，快速識別影響面最大的問題。對於熟悉SQL的用户，Transaction Search還支持CloudWatch Logs Insights查詢語言，提供更靈活的數據分析能力。

a. 在 Bedrock AgentCore Runtime 上集成Cloudwatch GenAI Observability

Bedrock AgentCore Observability 在 Cloudwatch GenAI Observability 的基礎上，為 Bedrock AgentCore Runtime上運行的 Agent 提供更便捷的可觀測性體驗。在基礎設施層面，AgentCore Runtime會自動創建和配置所需的CloudWatch日誌組（如/aws/bedrock-AgentCore/runtimes/<agent_id>-<endpoint_name>/runtime-logs
），自動處理IAM權限，並預配置好OTEL環境變量，應用只需添加Opentemeletry SDK即可使用，無需配置任何參數或環境變量。

AgentCore為不同資源類型提供差異化的默認觀測能力：

Agent資源的指標可以在GenAI Observability頁面直接查看，AgentCore自動提供針對Agent運行時的豐富指標，如Invocations（API請求總數）、Session Count（Agent會話總數）、細分的錯誤類型統計（InvocationError.Validation、InvocationError.Internal等），以及跨所有資源的聚合指標。

而Memory、Gateway、Tools資源的指標、spans和logs會自動路由到相應的CloudWatch組件中。特別是Memory資源，AgentCore提供了獨特的深度可觀測性，包括Creation Count（內存事件創建數量）、Memory特定的延遲指標，以及專門的工作流日誌（提取日誌和整合日誌）。

我們提供基於 Jupyter Notebook 的快速使用指導，幫助您快速在 Amazon Bedrock AgentCore Runtime 上部署一個AI Agent，並從Bedrock AgentCore Observability 上觀測Agent 的運行狀況。您可以從此處獲取此快速使用指導。

b. 在其他計算服務上集成Amazon Cloudwatch GenAI Observability

對於選擇在自建運行環境（如EC2、EKS、Lambda等）部署Agent，但仍希望使用CloudWatch GenAI Observability能力的組織，可以通過標準的OpenTelemetry集成來實現。您可以在軟件包管理器中安裝ADOT SDK依賴，將SDK注入到Agent代碼中，配置詳細的OTEL環境變量後，即可將可觀測性數據上送至Cloudwatch。CloudWatch GenAI Observability的體驗與AgentCore一致，您同樣可以基於Trace和Span進行查詢，但無法使用Bedrock AgentCore Observability 的指標面板，需要您自行創建。

我們提供基於 Jupyter Notebook 的快速使用指導，幫助您在本地運行基於 Strands 框架的 AI Agent，並從Cloudwatch GenAI Observability 上觀測Agent 的運行狀況。您可以從此處獲取此快速使用指導。

3.2 MLFlow、Langfuse等第三方組件

除了Cloudwatch GenAI Observability，許多開源第三方工具，例如Langfuse、MLFlow 也作為觀測數據的分析平台。可以提供包括：數據可視化和分析界面，執行邊緣案例分析，評估準確性和成本的權衡，分析用户交互模式，提供性能優化建議。

以Amazon SageMaker 託管的 MLFlow 3.0 進行 Agent 開發中的 Tracing 為例，通過全託管 MLflow 3.0 的追蹤能力，開發者可以記錄請求每個中間步驟關聯的輸入、輸出和元數據，從而準確定位錯誤根源和意外行為的來源。以下示例代碼展示了使用 Strands Agents 來構建一個基本的 Agent 工作流及使用MLFlow來對其中間環節進行追蹤。

@mlflow.trace(name= "strands-bedrock", attributes={"k": "v"}, span_type=SpanType.LLM)
def get_model():...

@mlflow.trace(name= "strands-agent", attributes={"k": "v"}, span_type=SpanType.AGENT)
def create_agent(model):...

@mlflow.trace(name= "strands-chain", attributes={"k": "v"}, span_type=SpanType.CHAIN)
def run_agent():
    model = get_model()
    agent = create_agent(model)
    return agent("Hi, where can I eat in San Francisco?")


with mlflow.start_run(run_name="StrandsAgentRun"):
    results = run_agent()

這些能力通過捕獲工作負載服務、節點和工具執行的詳細信息，為您的 AI 工作負載提供可觀測性。可以在MLFlow Tracking Server 前端的 Trace 選項卡中，查看這些完整記錄的執行信息。見如下示例：

圖3. MLFlow trace頁面

同時，對於使用 Bedrock AgentCore 執行環境的Agents工作流來説，可以直接利用其集成至CloudWatch中的 GenAI Observability能力，直接獲取整個Agent調用鏈的軌跡信息。見以下基於 AgentCore 進行 Strands Agents 搭建的調試示例。

圖4. CloudWatch GenAI Observability頁面

除了MLFlow之外，也可使用其他可觀測性平台，例如Langfuse是一個專為LLM應用設計的開源可觀測性平台，提供了完整的追蹤、評估和分析能力。它支持多種LLM框架的集成，能夠自動捕獲Agent的執行軌跡、token使用情況和成本信息，並通過直觀的Web界面展示這些數據，幫助開發者快速識別性能瓶頸和優化機會。

四. 利用可觀測性組件運維 Agent

此部分將以基於 Strands Agent 構建的電商售後智能客服為例，展示如何在應用開發和生產迭代的過程中遇到的多個場景使用可觀測性組件進行運維。

示例環境可根據 workshop 進行創建，創建資源包括一個含有訂單數據表格並通過 api gateway 對外暴露的電商系統，和一個通過網頁交互的電商售後智能客服應用，智能客服 Agent 應用通過添加多個 MCP servers，其中包括調用電商系統的 API Gateway 接口的工具，來實現對電商系統中的訂單進行查詢並按照售後流程定義規則進行處理的功能。以下為智能客服的頁面截圖，支持添加豐富的 MCP servers, 選擇不同的 LLM 模型。

圖5. Agent應用客户端界面

以上應用在開發階段會在前端頁面顯示所有的模型和工具調用信息，在實際生產環境中基於數據安全應該在前端隱去。此時則可以將 Agent 的追蹤數據打入到 Langfuse 平台進行監控，來保證重要指標的收集和功能異常的分析。

模擬新模型發佈，針對不同的 LLM 模型進行效果和成本對比測試

使用兩個不同的 user 對相同的問題進行測試，在 Langfuse 中觀察到不同的 Latency, Token 和 Cost , 可以觀察到 Claude 3.7 和 Nova Lite 分析過程和對工具的調用次數上一致，Claude 3.7 在成本上更有優勢，而 Nova Lite 則在成本上更有優勢。

圖6. 使用Langfuse對模型分析對比

模擬模型混用、網關智能路由的場景

假設基於測試結果，團隊希望使用 Nova Lite 為主要模型，Claude 3.7 為備用模型，對話過程中交替切換 LLM 來進行充分測試，發現出現錯誤。

圖7. Agent客户端錯誤示例

從 Langfuse 頁面可以快速定位到歷史對話採用 Claude 3.7 模型和當前切換的 Nova Lite 模型的信息格式不一致導致調用出錯。基於此類的追蹤分析，可以針對性的快速解決開發迭代和生產中遇到的問題。

圖8. 使用Langfuse分析錯誤日誌

模擬新功能上線，分析功能調用全流程

售後客服擴展功能為不同賣家提供數據查詢功能，應用後端通過 Mysql MCP server 接入電商系統數據庫。以數據查詢“查詢今年銷售額最高的3個客户”為例，雖然兩種模型都可以完成查詢，通過調用流程可以看到 Claude 3.7 對數據查詢語句的生成思考更嚴謹，更適合用在數據分析的場景。

圖9. 使用Langfuse分析調用全流程

五. 結語

隨着 AI Agent 在企業應用中扮演越來越重要的角色，建立完善的可觀測性體系已成為確保其可靠運行的關鍵基礎設施。本文探討了 Agent 可觀測性的核心要素、實現方式和最佳實踐，為開發團隊提供了一個實用的參考框架，詳細介紹了亞馬遜雲科技生態系統為 Agent 可觀測性提供的完整解決方案。通過 CloudWatch GenAI Observability 和 Bedrock AgentCore Observability，團隊可以快速獲得對 Agent 系統的全面洞察，無需複雜的基礎設施搭建。這些服務與 OpenTelemetry 的深度集成，不僅確保了與開源生態的互操作性，更為後續的分析和優化提供了堅實基礎。

我們建議您從訪問 Amazon Bedrock 控制枱開始，體驗 CloudWatch GenAI Observability 的監控能力，並參考本文提供的Agent Observability 示例代碼將 Agent 應用接入這些服務。在 Amazon Sample 倉庫中還有更多資源供您參考。

隨着AI Agent在企業應用中的廣泛部署，可觀測性已經從”錦上添花”的輔助工具轉變為”不可或缺”的核心能力。傳統的監控方式雖然能夠告訴我們系統的運行狀態，但面對Agent的複雜決策鏈條和多步推理過程，我們需要更深層次的洞察能力。

通過本文介紹的多維度可觀測性框架，我們不僅能夠監控Agent的性能指標和資源消耗，更重要的是能夠理解Agent的”思考過程”——從意圖理解到工具調用，從推理鏈條到最終輸出的完整決策軌跡。亞馬遜雲科技提供的CloudWatch GenAI Observability和Bedrock AgentCore等託管服務，結合開源生態中的MLFlow、Langfuse等工具，為企業構建Agent可觀測性提供了完整的技術棧支持。無論是選擇全託管的便捷方案，還是基於開源工具的靈活定製，企業都能找到適合自身需求的實施路徑。

在AI Agent成為企業數字化轉型重要推動力的今天，建立完善的可觀測性體系不僅是技術需要，更是業務成功的關鍵保障。只有真正”看見”和”理解”Agent的行為，我們才能充分釋放其潛力，讓AI真正成為企業的智能助手和效率倍增器。

本篇作者

關於Agentic AI基礎設施的更多實踐經驗參考，歡迎點擊：

Agentic AI基礎設施實踐經驗系列（一）：Agent應用開發與落地實踐思考

Agentic AI基礎設施實踐經驗系列（二）：專用沙盒環境的必要性與實踐方案

Agentic AI基礎設施實踐經驗系列（三）：Agent記憶模塊的最佳實踐

Agentic AI基礎設施實踐經驗系列（四）：MCP服務器從本地到雲端的部署演進

Agentic AI基礎設施實踐經驗系列（五）：Agent應用系統中的身份認證與授權管理

Agentic AI基礎設施實踐經驗系列（六）：Agent質量評估

Agentic AI基礎設施實踐經驗系列（七）：可觀測性在Agent應用的挑戰與實踐

Agentic AI基礎設施實踐經驗系列（八）：Agent應用的隱私和安全

*前述特定亞馬遜雲科技生成式人工智能相關的服務目前在亞馬遜雲科技海外區域可用。亞馬遜雲科技中國區域相關雲服務由西雲數據和光環新網運營，具體信息以中國區域官網為準。

本期最新實驗《多模一站通 —— Amazon Bedrock 上的基礎模型初體驗》
✨ 精心設計，旨在引導您深入探索Amazon Bedrock的模型選擇與調用、模型自動化評估以及安全圍欄(Guardrail)等重要功能。無需管理基礎設施，利用亞馬遜技術與生態，快速集成與部署生成式AI模型能力。
⏩️[點擊進入實驗] 即刻開啓 AI 開發之旅
構建無限, 探索啓程！

亞馬遜雲開發者博客

亞馬遜雲開發者博客

博客 / 詳情