AI Agent Observability 工具完整指南：LangSmith、Langfuse、Helicone、Arize、Datadog 五大平台決策框架與外包採購紅線

凌晨三點，老闆 LINE 你：客服 AI 又在亂講話了

螢幕上是一段截圖：客戶問「我訂的桌子什麼時候到？」，AI 回了一段三百字的物流知識，最後甚至引用了一個不存在的訂單編號。你趕緊登入後台，翻了半小時 log，只看得到一行「response generated successfully」。模型到底為什麼這樣回？這個 prompt 在哪個 agent 步驟壞掉？昨天有多少客戶被同樣回答？這三個問題沒有一個答得出來。

這是 2026 年 AI agent 進入生產環境後最常見的窘境：東西看起來「跑得起來」，但只要出事，整個團隊都成了瞎子。如果你正在找外包做 AI 系統，或公司內部工程師已經把第一版 agent 推上線，那AI Agent Observability（可觀測性）就是你接下來三個月不能跳過的功課。這篇會把市面上五大主流工具：LangSmith、Langfuse、Helicone、Arize Phoenix、Datadog LLM Observability，用「老闆視角」拆給你看，附上一份外包採購合約紅線清單，讓你不用懂程式也能跟工程師對齊。

先說一個很多人會搞混的觀念：observability 跟 evals 不是同一件事。如果還沒讀過 LLM Evals 完整指南，建議先把那篇看完：evals 是「上線前」的考試制度，observability 是「上線後」的監視器。本篇談的是後者。

什麼是 AI Agent Observability

傳統軟體的 observability 由三柱組成：logs（日誌）、metrics（指標）、traces（追蹤）。LLM 應用多了一層複雜度：一個 agent 可能一次推理就會呼叫 5 次 LLM、3 個 tool、2 個 RAG retrieval，外加一個 reranker。任何一步出問題，最終答案都會走樣。

根據 LangChain 官方部落格的整理，2026 年的 LLM 應用 observability 至少要看清這五件事：每個 LLM call 的輸入輸出與 token 用量、tool call 的參數與回傳、retrieval 階段抓到了哪幾段文件、agent 的決策路徑（為什麼選 A 不選 B），以及最重要的：「這個壞掉的 session 我能不能在 60 秒內重現」。少一項，事故就會像今天凌晨那個訂單編號一樣，永遠是個謎。

有一個很直覺的比喻：傳統 APM（Application Performance Monitoring）看的是「水管」：請求進來、響應出去、延遲多久；LLM observability 看的是「水質」：這個答案合不合理、是不是幻覺、有沒有人在 prompt injection 攻擊。前者用 Datadog、New Relic 就好，後者要用 LLM-native 的工具。

Evals、Monitoring、Observability 三件事的真正分工

這三個詞在 2026 年的 AI 圈被混著用，但對外包採購來說必須拆清楚，否則合約寫出來會跑掉重點。簡單拆解：

外包合約最常見的踩雷是把這三件事混成一條「需要做監控」就帶過。後果是工程師交付 Datadog 儀表板看 CPU 和延遲，但你想看「為什麼 AI 回了一個假訂單編號」時，整個系統什麼也答不出來。

五大主流 Agent Observability 平台正面對決

市面上 LLM observability 工具至少有 20 家在打仗，但真正能讓中小企業老闆「在外包合約裡寫得出名字」的，是這五家：LangSmith、Langfuse、Helicone、Arize Phoenix、Datadog LLM Observability。其他像 Lunary、Phoenix Cloud、Confident AI、Traceloop 都還不錯，但要嘛太年輕、要嘛社群太小、要嘛只解一個小切面，外包丟給你「我們用 XX」時你會查不到夠多參考資料。

先用一張總表把五家的定位差異講清楚，後面再分頭拆。資料整理參考 Digital Applied 的 2026 平台比較 與各家官方文件：

LangSmith：LangChain 生態的官方答案

如果你的外包團隊跟你說「我們用 LangChain」或「我們用 LangGraph 寫 agent」，那 LangSmith 幾乎是不用比的預設選擇。它做的事就像 GitHub Actions 之於 GitHub：同公司、同生態、整合到讓你忘記它是另一個產品。

LangSmith 強的地方是 trace 視覺化做得極細：每一個 chain、每一個 tool、每一個 retriever 都會自動切成節點，點下去能看到輸入、輸出、token、延遲、cost。對於多步 agent，這就是你凌晨三點找出「到底哪一步壞掉」唯一的依靠。它也內建 Datasets 跟 Evaluations，意思是同一個平台可以拿線上 trace 直接變成 regression test 案例。這個 loop 在外包交付後特別有用，每次模型升版你都能用過去 30 天的真實流量回測一輪。

弱的地方有兩個：第一，雖然有 self-hosted 版本，但功能比 cloud 受限，且需要 enterprise 合約才開放；第二，價格按 trace 數量計費，agent 應用一次推理可能會產生 5-10 個 trace，量大起來容易超預算。中小企業典型的踩雷是看 starter 方案 $39/month 就簽下去，結果三個月後流量上來變成 $800/month。

Langfuse：開源派的標竿

Langfuse 是 2026 年自架陣營的領頭羊。GitHub 上 21k+ star 的開源專案，docker compose 一個指令就能拉起完整功能。對於以下三種公司特別合適：資料不能離開內網（金融、醫療、政府）、預算極緊（自架月成本一台 VPS 就夠）、技術棧不是 LangChain（Langfuse 對 LiteLLM、Vercel AI SDK、OpenAI SDK 都有原生整合）。

實際操作上，Langfuse 的 UI 設計大量參考 LangSmith，所以從 LangSmith 跳過來幾乎沒學習成本。功能上最值得提的是 prompt management：它把 prompt 當作版本化資產管理，可以 A/B test 不同 prompt 在線上的真實表現，這對行銷類、客服類的迭代特別實用。商業 cloud 版本也有，但中小企業多半會選 self-host 走 free tier，這是它最迷人的地方。

Helicone：最低門檻的入門選擇

Helicone 的賣點極簡單：你不用改任何 SDK，只要把 OpenAI 的 baseURL 從 api.openai.com 改成 oai.helicone.ai，所有請求就會自動被記錄。這個 proxy 模式對「還沒選好框架、先想看看流量長怎樣」的階段非常有用，半小時內就能跑起來。

但 proxy 模式的代價是看不到 LLM call 之外的東西：你的 tool call、RAG retrieval、agent 決策樹這些「介於 LLM call 之間」的脈絡，Helicone 撈不到。所以它比較適合作為「第一週的快速驗證工具」，等系統長到有複雜流程，多半要遷移到 LangSmith 或 Langfuse。把它當作「永久解」會踩到天花板。

Arize Phoenix：ML 級嚴謹派

Arize 是 ML monitoring 老牌廠商，Phoenix 是它釋出的開源 LLM observability 工具。最大的特色是把傳統 ML 的 drift detection、embedding 視覺化帶進 LLM 世界。對於有資料科學團隊的公司、或者 RAG 系統需要長期觀察 embedding 品質漂移，Phoenix 是少數能打的選項。

但對中小企業老闆來說，Phoenix 的學習曲線是門檻。它假設你會 OpenTelemetry、會自己寫 instrumentation、會解讀 embedding visualization。如果外包團隊不是有資料科學背景的 ML 工程師，硬要用 Phoenix 反而會卡住。判斷準則很簡單：你的系統有沒有 RAG？有沒有需要長期觀察 embedding 品質？如果都沒有，Phoenix 就跳過。

Datadog LLM Observability：企業內預設選項

如果你的公司本來就在用 Datadog 看後端 APM、infra metrics、log aggregation，那 Datadog 2024 推出的 LLM Observability 模組就是不用想的選擇：同一個帳號、同一個 dashboard、同一張帳單。對 IT 部門有「禁止新增監控平台」政策的公司，Datadog 是唯一能繞過審批的路。

但對純 AI 應用、或還沒被 Datadog 綁定的公司，它的 LLM 功能起步比 LangSmith / Langfuse 晚一年，trace 視覺化的細緻度、prompt management、eval workflow 都還在追趕。價格上更是企業級：starter 跑不起來，多半要走 enterprise 合約。中小企業除非「公司已經是 Datadog 客戶」，否則沒有理由先選它。

自架、雲端、proxy：三種部署架構怎麼挑

選完工具還沒結束。同一個工具，例如 Langfuse，可以走 self-hosted、可以走 cloud；LangSmith 雖然主打 cloud 但 enterprise 也有 self-hosted。架構選錯，後面再換要付的代價遠高於工具本身。三種架構的本質差異：

外包採購 Observability 合約必踩的 7 條紅線

從業界系統客製化諮詢經驗中，最常被外包硬塞、事後吃悶虧的合約陷阱有以下七條。寫合約前一條一條對：

• 資料所有權沒寫死：trace 資料、prompt 歷史、eval dataset 屬於誰？合約結束後外包能不能帶走？必須寫「所有 observability 資料（含原始 trace、衍生 dataset、eval 結果）歸甲方所有，乙方應於合約終止 30 日內完整匯出並刪除。」

• 帳號權限不在甲方手上：常見狀況是外包用自己的 LangSmith / Datadog 帳號掛你的專案，合約結束後你完全進不去。必須要求工作空間（workspace / organization）由甲方名下信箱建立，乙方只是 invited member。

• Prompt 沒做版本控制：合約必須要求所有 production prompt 走 Langfuse 或 LangSmith 的 prompt management，每一版都有 timestamp、修改人、上線記錄。不要接受「prompt 寫在 code 裡」這種交付。

• Tool / MCP 串接沒寫進 trace：2026 年 agent 普遍用 MCP（Model Context Protocol） 串接外部資料源，這些 call 必須跟 LLM call 在同一個 trace 樹底下，才能 debug。要求外包提供「一個典型 session 的完整 trace 截圖」當驗收。

• 成本上限沒設熔斷：trace 數量 × 模型 token，兩條曲線疊加會在大促、行銷活動當天炸開。合約要寫「乙方應設定 daily token budget alert、超過 X 元自動降級到便宜模型」。

• PII（個資）沒做 masking：trace 會把使用者輸入完整收進來，包含手機、email、地址。合約要求 observability 平台必須開啟 PII redaction（LangSmith / Langfuse 都有原生支援），否則就是個資法地雷。

• 沒交付「事故重現 SOP」：交付物清單裡要明寫「給定一個 session ID，30 分鐘內能完整重現該次 agent 推理路徑」的 SOP 文件 + 一次實際演練。沒有這份東西，你買的觀測平台只是漂亮儀表板。

中小企業外包採購 Observability 的五步驟 SOP

把上面所有東西收斂成一份可執行 SOP，這是你下次跟外包開會時可以直接 print 出來對的清單。決策路徑如下：

Step 1：先做需求盤點，不要直接問外包要報價

跟外包開報價會議之前，內部要先回答四個問題：這套 AI 系統一個月預期多少 session？單次 session 平均幾個 LLM call？資料有沒有個資 / 醫療 / 金融屬性？公司現有 APM 平台是什麼？四題答完，工具範圍會自然縮到 1-2 個選項。

Step 2：在 RFP 裡明確指定 observability 平台

RFP（Request for Proposal，需求建議書）裡要寫死「乙方應使用 X 平台（或同等 OpenTelemetry-compatible 方案）進行 LLM observability，並開設甲方擁有的 workspace」。不要寫「乙方應提供觀測能力」這種模糊條款：這種條款的下場就是工程師交一個 Grafana CPU 儀表板給你。

Step 3：驗收驗 session replay，不驗 dashboard

最有用的驗收測試是：在驗收會議當場，請工程師從昨天的真實 session 隨機抽一個，當著你的面打開 trace，講解每一步發生什麼。如果他要花超過 5 分鐘 ramp up、或者打不開、或者很多欄位是空的，這套 observability 就是裝飾品。

Step 4：上線 30 天後做一次 chaos drill

上線後一個月，自己抽一個歷史 session 丟給外包：「這個用戶問了 X，但 AI 回了 Y，幫我找出哪一步出問題。」計時，30 分鐘內答不出來就是平台跟 SOP 沒到位。這比看月報 PPT 有用一百倍。

Step 5：把月費上限寫進 SLA

Observability 平台月費 + LLM token 月費是兩條會打架的曲線。合約 SLA 要寫「乙方應每月提供成本明細，且乙方應在 token 月費達合約上限 80% 時主動發送預警」，避免你在月底收到一張嚇人的帳單。

在系統客製化諮詢經驗中看過的兩個典型案

以下兩個情境是業界常見的縮影。第一個是某中型電商導入客服 AI：

他們一開始選了 Helicone，因為「最容易」。三個月後流量上來、agent 從單純 Q&A 演進到能查訂單、發退貨單，問題開始浮現：使用者抱怨 AI 亂發退貨單，工程師翻 Helicone 卻只看到 LLM call 的輸入輸出，看不到「為什麼 agent 決定呼叫退貨 tool」這一步。最後花了兩個月遷移到 Langfuse self-hosted，把 tool call 全程記錄補上，事故才止血。教訓是：proxy 型工具只適合單純 LLM 應用，agent 走起來就要換。

第二個是一家精品製造業導入內部知識問答（RAG 系統）：

他們的痛點是員工抱怨「AI 答案不準」，但工程師說「我看 LangSmith trace 模型回應沒問題」。追到最後發現是 retrieval 階段抓到錯誤段落，模型只是忠實地照著錯誤上下文回答。如果一開始選的工具只看 LLM call，而沒像 LangSmith 那樣支援 retrieval trace，這個問題會永遠是個謎。可以參考 AI 智慧客服系統 的客製化案例，類似情境的 RAG 觀測通常要把 retrieval、reranker、LLM call 三層 trace 都打通，缺一個都會盲區。

Observability 是一個策略組合，而非單一工具

實務上很少有公司只用一個 observability 工具。比較成熟的配置是「LLM-native 工具 + 傳統 APM」兩層併用：

LangChain 官方 2026 推的整合策略也是這個方向：把 LangSmith 跟 Datadog 串起來，讓 trace ID 能在兩邊跳轉。對於規模 50 人以上、有專職 SRE 的公司，這種雙層架構幾乎是標配。

如果你的團隊還在「該不該導入 AI」的更前端階段，建議先看 AI 系統開發服務 的需求盤點流程，再回頭看 observability。提前選好觀測平台，比上線後再補容易十倍。這也是我們在 AI 顧問服務 中最常提醒客戶的順序。

常見問題

下一步：把 observability 寫進你的下一份 AI 採購合約

AI Agent Observability 在 2026 年已經從「nice to have」變成「不裝就在賭命」。如果你正準備啟動一個新的 AI 系統外包，或現有系統還沒裝任何觀測工具，建議的最短路徑是：先讀完本篇與 LLM Evals 完整指南，再對著合約紅線清單跟外包對齊一輪。

恆遠提供 AI 顧問服務 與 AI 系統開發 兩種介入方式：前者協助你在採購階段把 observability 寫進需求書、避開 7 條紅線；後者直接交付帶有 observability 標準配置的 AI 系統。如果你正在凌晨三點被 LINE 吵醒，可以先預約一次 30 分鐘諮詢：把眼前那個亂回答的 session 帶來，我們一起把它變成可以重現、可以修、可以避免再犯的工程問題。