2026 AI 智慧體可觀測性實戰指南：追蹤、評估與生產監控

上個季度，一家中段 SaaS 公司上線的客服智慧體悄悄開始用自信、流暢卻完全捏造的內容回答 14% 的票券。沒有人察覺，整整九天。後台的儀表板一片綠：每分鐘請求數穩定、錯誤率持平、延遲正常。唯一顯示有問題的訊號，是一則來自受挫使用者的 Slack 訊息。等到團隊追蹤到那次迴歸時，智慧體已經在大約 4,300 段客戶對話中虛構了內部政策引用。

這是 2024 年沒人警告你的失敗模式。傳統監控根本看不見 LLM 智慧體。HTTP 200 的回應幾乎沒告訴你任何事。CPU 與記憶體的圖表抓不到真正的失敗。Token 數與請求數也無法揭露你的智慧體正在自創政策。你真正需要的訊號，存在於模型在產出那段回應時所走過的推理、工具呼叫、檢索步驟鏈之中——而你之所以沒有它，是因為你當初沒有為它埋點。

這就是為什麼到了 2026 年，「可觀測性」（observability）——而非模型品質或提示詞工程——已經悄悄成為把 AI 智慧體送上生產環境的成敗關鍵技能。

對智慧體來說，「可觀測性」到底意味著什麼

傳統軟體的可觀測性建立在三大支柱上：日誌、指標、追蹤（trace）。到了 2026 年，對 LLM 智慧體而言，你三個都需要，再加上第四個過去不存在的支柱：評估（evaluation，簡稱 evals）。

• 日誌（Logs）紀錄發生了什麼——原始的模型請求、原始的模型回應、任何工具呼叫及其結果。日誌是智慧體執行的 ground truth。
• 指標（Metrics）把日誌彙整成時間序列訊號——每分鐘 token 數、每請求成本、延遲百分位、錯誤率、幻覺率、檢索命中率。
• 追蹤（Traces）把單一使用者請求串起整個智慧體的執行過程：LLM 呼叫、工具呼叫、檢索器呼叫、記憶體查找、工具回傳之後的第二次 LLM 呼叫。沒有 trace，一個多步驟智慧體就是團讀不懂的混亂。
• 評估（Evals）是附加在 trace 上的品質分數——自動化或人工對「輸出是否正確、是否有幫助、是否符合政策」的判斷。Evals 是把可觀測性從「我們看得到發生了什麼」推進到「我們能判斷那是不是對的」的那一步。

誠實地說：2026 年大多數團隊只上日誌、偶爾上指標的智慧體就上線了。幾乎沒有人把 trace 與 evals 妥善接好。這正是造成開頭「九天自信鬼扯」事件的落差。

為什麼這件事比聽起來更難

三個結構性原因，讓智慧體可觀測性成為不同於一般後端可觀測性的學問。

第一，智慧體在步驟層級是非確定性的。同一個輸入，在不同次執行中可能走不同的工具呼叫與推理路徑。這代表你沒辦法定義單一「快樂路徑」trace，然後像 REST API 那樣對偏離發警報。你需要的是行為的統計分佈，加上在某件事出包時對單一軌跡的分析。

第二，失敗模式是語意上的，不是語法上的。呼叫錯工具的智慧體會回 HTTP 200。幻覺出退款政策的智慧體同樣會回 HTTP 200，附帶完美的 JSON 主體。你現有的告警基礎設施基本上對這些失敗是瞎的——因為傳輸層什麼錯都沒發生。只有模型感知的檢查——LLM-as-judge 的 eval、檢索 grounding 分數、引用精確度檢查——才抓得到。

第三，單一使用者請求會產生一棵 LLM 呼叫、工具呼叫、檢索步驟的樹。一個簡單的客服智慧體每次對話可能產生 8 到 15 次 LLM 呼叫。一個程式設計智慧體可能產生 50 次。多智慧體研究流程可能 200+ 次。每一個葉節點都必須歸屬到同一個使用者請求，並帶有時間、成本、品質資料，好讓你在使用者回報問題時能完整重現當時發生了什麼。

2026 年的技術棧：實際在出貨的有哪些

過去 12 個月，智慧體可觀測性的版圖已經大幅收斂。2026 年中，大多數生產團隊都從一小撮覆蓋面差不多的平台中選一個。

平台	部署方式	關鍵差異化	最適合的情境
LangSmith	雲端、BYOC、自架	SmithDB 為智慧體查詢模式專門打造；與 LangChain/LangGraph 深度整合	已經在使用 LangChain 或 LangGraph 的團隊，或需要在數百萬筆 trace 上做到次秒級查詢的團隊
Langfuse	雲端或完整自架（開源）	原生支援 OpenTelemetry，沒有廠商綁定，框架整合廣	想要自架、符合 OTel、或走開源技術棧的團隊
Arize Phoenix	雲端或自架	OpenInference 埋點；內建 PXI 智慧體做 in-context 除錯	想要 OTel 原生追蹤加上強大 eval 套件的團隊，特別是 RAG 重的應用
Helicone	雲端（現已併入 Mintlify）	AI 閘道加可觀測性，proxy 式設定超快	想要一鍵掛上 OpenAI／Anthropic proxy 順便做日誌，不要整套平台的團隊
OpenLLMetry + 自有 OTel 後端	隨你高興	純標準，可輸出到 Datadog/Honeycomb/Grafana/Tempo	已經有可觀測性基礎設施、想完全不引入新廠商的團隊
MLflow Tracing	自架或託管	與既有 MLflow experiment tracking 生態整合	已經用 MLflow 做 ML 模型生命週期管理的團隊

最重要的一件事：幾乎每個現代平台在 2026 年都已經原生支援 OpenTelemetry。這是 2025-2026 年悄悄發生的革命。OpenTelemetry 的 GenAI 語意慣例（semantic conventions）在 2025 年底從草案進入穩定狀態，搬進了 OpenTelemetry 專案底下的正式倉庫，對 LLM 呼叫、工具呼叫、retriever、MCP 呼叫、還有各家供應商專屬擴充（OpenAI、Anthropic、AWS Bedrock、Azure AI Inference、Google Vertex）都給出了正式的 span 與指標定義。過去需要專屬 SDK 才能做的事，現在就是標準的 OTLP。如果你的可觀測性廠商在 2026 年還不原生支援 OTel，那他已經落後了。

一段真正讀得懂的 trace

以下是一段 2026 年埋點完整的智慧體 trace 大致長什麼樣子，為求清晰有做簡化。Langfuse、Phoenix、LangSmith 看起來形狀都差不多。

Trace: ticket-4827-support-conversation
+-- Span: agent.run [12.4s, 4,210 tokens, $0.062]
    +-- Span: llm.openai.gpt-4o.plan [1.1s, 480 tokens]
    +-- Span: tool.get_customer [0.3s]
    +-- Span: tool.search_docs [0.8s, k=5, hit=true]
    +-- Span: llm.openai.gpt-4o.draft [1.4s, 720 tokens]
    +-- Span: llm.openai.gpt-4o.critique [1.0s, 380 tokens]
    +-- Span: tool.create_ticket [0.2s]
    +-- Span: llm.openai.gpt-4o.format_reply [0.9s, 290 tokens]
+-- Eval: hallucination_check to 0.18 (pass)
+-- Eval: grounded_in_docs to 0.92 (pass)
+-- Eval: policy_compliance to 0.45 (fail) - THE BUG
+-- Eval: tone_appropriate to 0.88 (pass)

這就是 2026 年除錯智慧體和 2023 年除錯智慧體的差別。trace 明確告訴你是哪個步驟花了 12.4 秒、哪個步驟最花 token——更關鍵的是——哪個 eval 沒過。沒有掛 evals 的話，你會看到一條綠的 trace、再一條綠的 trace，完全不知道其中 55% 的回覆其實漏了一段必要的揭露聲明。

四個能抓出大多數生產失敗的 eval

你沒辦法什麼都評估。預算不夠，eval 帶來的延遲也會侵蝕使用者體驗。看過很多團隊接好這套之後，四類 eval 大致能涵蓋我看過的生產事故中 80% 的災難性失敗。

1. Groundedness / 引用精確度

對任何有 RAG 或會用工具的智慧體來說，這就是抓幻覺的 eval。把智慧體的輸出、檢索到的上下文一起交給 LLM 評審：「這段輸出裡的每個主張是否都有檢索上下文支撐？請引用不相符的那句。」這幾乎每次都能抓到開頭客服那個幻覺故事。

2. 政策／指令遵循度

對那些有明文政策的智慧體（「永遠要附上退款窗口」、「未查過承運商 API 前不要承諾到貨日期」），這個 eval 檢查輸出是否照做。這是高槓桿區，因為政策常改，而人會忘記更新提示詞。每週用最新政策文件做一次批次 eval，可以在使用者抓到之前就先抓到漂移。

3. 工具呼叫正確性

智慧體有沒有呼叫對的工具、傳對的參數？有沒有用到工具的回傳，還是忽略結果自己掰一個？簡單的程式碼式 eval，解析工具呼叫、比對預期樣式，就能抓到提示詞改動後最常見的智慧體迴歸。

4. 使用者回饋或任務成功訊號

如果你有的話，這就是 ground truth。讚/爛、票券是否解決、使用者是否需要換個方式重問、對話最後是否升級給真人。這些通常量比較少但訊號很強。把它們連結回產生回應的 trace，你就擁有了一座金礦級的 eval 集。

其他東西——語氣、簡潔、人設、創意——是 nice-to-have，但很少是「能上線」與「被下架」之間的差別。

線上 vs 離線 eval：選你的戰場

每個團隊最後都會撞上同一面牆：eval 要跑在哪裡？你大致有兩條路。

線上 eval在真實生產流量的抽樣上即時跑。它會增加延遲（通常每個 eval 200-800ms），所以你得抽樣——常見範圍是 1% 到 10%。好處是幾小時內就能抓到迴歸，不是幾週。壞處是成本：每個線上 eval 都是另一次 LLM 呼叫，量大起來會很貴。

離線 eval對一組策展過的代表性 trace 跑，通常是每晚或在每次部署時跑。它便宜、可重現、確定性高。壞處是有時間差——如果週二冒出新失敗模式，要等資料集更新才會被發現，通常就是下週。

大多數成熟團隊最後會停在這個務實的拆分：便宜快速的線上 eval（小樣本，如工具呼叫正確性、簡單政策檢查）、昂貴慢的線上 eval 只在被標記的 trace 上跑、每晚離線批次把全部 eval 對著完整黃金資料集跑一輪。不要在每一個生產請求上都跑四個昂貴的 LLM 評審。你的毛利會被吃光。

就算什麼都沒有，至少要埋這些

如果你只有一個週末，這是生產智慧體的最低可行可觀測性技術棧。這大致是一個獨立開發者在週一早上之前就能接好的東西，也是小團隊在第一位真實使用者出現之前就應該上線的東西。

• 每個使用者請求一條 trace，把每一個 LLM 呼叫、工具呼叫、檢索都當作子 span。用 OpenTelemetry GenAI 語意慣例，或任何會輸出 OTel 的廠商 SDK。成本：幾個小時的整合工。
• 每條 trace 的 token 與成本指標，做成儀表板，顯示每日總量、每 trace P95 成本、按使用者拆分。這能在第一時間抓到成本失控的 bug。成本：再多幾小時。
• 一個線上 eval，5% 抽樣，瞄準你最怕的那一種失敗。對大多數團隊來說就是 groundedness 或政策遵循度。成本：你預算中的一個 LLM 呼叫。
• 每晚批次 eval，對 30-50 條代表性 trace 的黃金資料集，結果發到 Slack 或 email。成本：每晚幾美分。
• 一條告警規則：每 trace P95 成本週對週翻 3 倍，或 eval 失敗率超過 10%，或錯誤率超過 5%。PagerDuty 整合可有可無。成本：15 分鐘。

這就是整套地板。少於這些，你就是蒙眼飛行。

OpenTelemetry GenAI 的位移

這件事值得停下來談，因為它大幅改變了廠商數學。在 2025 年以前，每家可觀測性廠商都有自己專屬的 trace 格式。換廠商意味著整個程式碼庫要重新埋點。OpenTelemetry GenAI 語意慣例改變了這件事。

到了 2026 年中，OTel GenAI 慣例在高頻路徑上已經穩定：gen_ai.agent、gen_ai.tool、gen_ai.retriever、gen_ai.embedding，以及 OpenAI、Anthropic、Bedrock、Vertex、Azure AI Inference 各家 LLM 客戶端的 span。MCP 呼叫有自己的 span 類型。Span 帶有標準屬性：gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.usage.output_tokens、gen_ai.response.finish_reason 等。

實際意義是：你只要用 OTel SDK（或 OpenLLMetry、OpenInference 這類自動埋點函式庫）把智慧體埋點一次，trace 就能送到你想送的後端——Datadog、Honeycomb、Grafana Tempo、SigNoz、New Relic、開源的 Langfuse 或 Phoenix、或託管的廠商。廠商綁定如今是一種選擇，不再是預設。

對自架派來說，這也是阻力最小的路徑。如果你已經為後端跑 Prometheus 加 Grafana，你可以把 OTel trace 送進一份 Tempo 或 Mimir，在上面疊儀表板，完全跳過 LLM 專屬廠商。資料是一樣的。

常見錯誤

看過很多團隊採用智慧體可觀測性之後，失敗模式驚人地一致。

• 什麼都記錄，什麼都不告警。一個塞滿 50GB 智慧體 trace 的 OpenSearch 叢集，但從來沒人查，這不是可觀測性，這是囤積。挑三個你真的會告警的訊號，其他等它們變成訊號再說。
• 沒有黃金資料集就跑 eval。在每條生產 trace 上跑 LLM 評審，不等於你擁有 evaluation。沒有一組策展過的已知好與已知壞的 trace，你根本沒辦法判斷 eval 是在變好還是變差。先把資料集建好。
• 單一支柱的可觀測性。只挑 trace（「我們看得到發生什麼」）、只挑指標（「成本有上升」）、或只挑 evals（「評審說平均品質 0.7」）的團隊，看到的是扭曲的圖。任何有趣的除錯，三個都要有。
• 忘了使用者端的延遲。埋了 LLM 呼叫的時間，卻忘了使用者其實也在等你的檢索、工具呼叫、記憶體查找、以及 eval 抽樣。一條顯示「LLM 花了 2 秒」但使用者等了 8 秒的 trace，是誤導的。要量的是從請求接收算到回應送出的外層 span。
• 把失敗抽樣掉。抽 1% 流量沒問題，直到 bug 只出現在 0.5% 的 trace 裡。永遠對錯誤、重試、以及任何 eval 觸發旗標的 trace 保持 100% 抽樣。只用 head-based sampling 是個陷阱。
• Trace 裡帶著 PII。智慧體 trace 常常含有使用者 PII——姓名、Email、檢索文件中的地址，有時還有健康或財務資料。如果沒做去識別化就把這些 trace 丟給第三方廠商，你會碰上合規問題。在 trace 離開你的基礎設施之前，請在 SDK 層先遮罩。

自架 vs 託管：2026 年的誠實評價

過去這題是「功能完整度」對上「維運痛苦」。到了 2026 年，這題大多落在「你信誰保管你的 trace」以及「你有多少工程時間」。

託管（LangSmith cloud、Arize cloud、Helicone cloud、Langfuse cloud）讓你一天內就能上手，吃下擴展性、留存、SOC2 等文件。你按 trace 或按事件計費，過了每月數億事件這個量級之後帳單會很可觀。對大多數每月 1,000 萬 trace 以下的團隊，託管是正解。

自架（Langfuse OSS、Phoenix OSS、OpenLLMetry + 自有 OTel 後端）在你跨過下列任一門檻時就合理：託管理價變得痛的 trace 量級、禁止第三方 SaaS 的資料落地法規、受監管行業（醫療、金融、國防）、或已經有平台團隊在跑 Kubernetes 與 Postgres，寧願多掛一個工作負載也不願再付一家廠商帳單。維運成本是真的——你要負責可用性、升級、備份、留存政策——但這跟其他自架基礎設施沒什麼兩樣。

我誠實的看法：先從託管開始。有了具體理由再搬到自架，不要提早搬。

什麼時候智慧體可觀測性還不值得做

不是每一個智慧體都需要整套技術棧。在下列情境可以先跳過重型投資：

• 智慧體處於 4 週原型期，使用者少於 50 人。用筆記本和好的紀錄就夠了。
• 任務是單次 LLM 呼叫、沒有工具、沒有檢索。沒有東西可以追蹤。
• 你在做離線批次生成，延遲無關緊要，成本由批次大小固定。
• 智慧體是唯讀的，不會執行破壞性動作。錯誤是可恢復的。

其他所有情境——任何對使用者的、任何碰到錢的、任何在真實世界採取行動的——可觀測性都是「你可以信任的智慧體」和「你一直提心吊膽的智慧體」之間的差別。

務實的採用 checklist

• 挑一個會輸出或接受 OpenTelemetry GenAI span 的廠商或自架技術棧。
• 為每個使用者請求埋一條 trace，把所有 LLM、工具、檢索呼叫都當作子 span。
• 把 token 與成本指標加到儀表板，按使用者與 trace 類型拆分。
• 辨識你最怕的那一個失敗模式，為它寫一個 eval。
• 在 5% 抽樣上跑那個線上 eval，並對 30-50 條 trace 的黃金資料集每晚跑離線版本。
• 接上三條告警：成本異常、eval 失敗率、錯誤率。
• 在 SDK 層做 PII 去識別化，trace 才離開你的基礎設施。
• 每週看一次儀表板。如果你不看，那不是可觀測性，那是資料庫。

誠實的評價

2026 年的模型品質故事在頂端大致已經解決——GPT-4o、Claude 4.5、Gemini 2.5 Pro、以及開源權重模型的領頭羊，對大多數生產任務都夠好了。瓶頸不是模型做不做得了這份工作。瓶頸是你能不能判斷它有沒有把這份工作做對。可觀測性是這個問題的答案，它正是區分「穩定上線智慧體的團隊」與「只會 demo 智慧體的團隊」的那項技能。

仍然被過度吹捧的是：「自主 eval 智慧體」聲稱能取代人工判斷。它們作為第一輪把關有用，但不是終局。任何團隊在每條生產 trace 上跑 LLM-as-judge eval、卻沒有對失敗做人工抽樣檢查，一定會以自己看不見的方式持續犯錯。

現在最值得做的：挑一個廠商或自架技術棧、把四個支柱埋好、寫一個能抓到你最怕的那個失敗的 eval、每週看一次儀表板。其他都是增量。基本層才是重點。

FAQ

我需要付費的可觀測性平台嗎？還是 OpenLLMetry 加 Grafana 就夠了？

對大多數每月 1 億 trace 以下的團隊來說，OpenLLMetry 加上一個 OTel 相容的後端（Grafana Tempo、Honeycomb、SigNoz、Datadog APM）在功能上和付費 LLM 專屬平台是等價的。你會犧牲一些拋光的智慧體專屬 UI（session 檢視、軌跡分析、提示詞 playground），但你留下的是資料和標準。付費平台值得買的時機，是它專屬的 UX 為團隊省下的時間超過帳單的成本。

對智慧體來說，trace 和 log 有什麼差別？

Log 是個別事件的紀錄——一個 LLM 呼叫一行、一個工具呼叫一行。Trace 把這些事件串成同一個使用者請求的結構化樹狀圖。對除錯來說，trace 大概有用十倍，因為它保留了事件之間的關係。對合規或稽核來說，log 通常已經足夠。兩者你都需要結構化資料，不是自由文字的 log 行。

實務上線上 eval 大概花多少錢？

一個 LLM-as-judge eval 通常每次呼叫成本 $0.001 到 $0.01，視評審模型與輸出長度而定。在每月 100,000 次使用者請求的 5% 抽樣下，一個 eval、單一評審模型，一個月大約 $5 到 $50。四個 eval、5% 抽樣會落在 $20 到 $200 的區間。這是 LLM 智慧體預算中較便宜的項目之一，也是槓桿最高的之一。

沒有黃金資料集可以跑 eval 嗎？

你可以跑線上 eval，但你沒辦法判斷你的 eval 到底準不準。先建一個小型資料集——30 到 50 條帶著已知結果（好與壞都有）的代表性 trace——拿你的 eval 對它量精確率跟召回率，再讓 eval 上生產線。

智慧體專案中最常見的可觀測性落差是什麼？

是對智慧體推理「步驟」而非僅僅最終輸出的 eval。大多數團隊評估最終回應是否正確。幾乎沒有人評估中間的推理或工具呼叫決策是否健全。當智慧體在複雜任務上失敗時，失敗通常發生在 12 步中的第 3 步，而不是最終回應。對步驟做 eval，是大多數團隊能做的最高槓桿加碼。

結語

到了 2026 年，對任何對使用者的智慧體來說，可觀測性已經不再是選項。工具成熟、標準開放、「夠好」的地板現在已經清楚定義：trace、指標、eval、每週的檢視。少於這些，你就離「九天自信鬼扯」只差一次迴歸。

挑一個技術棧。把四個支柱埋好。寫一個能抓到你最怕的失敗的 eval。看一次儀表板。這就是工作。