前端拋出 500。stack trace指向一個 React 元件。真正的問題在三個服務之外，由一個洩漏的背景工作耗盡了資料庫連線池。

你可以點開 trace waterfall、關聯時間戳記、閱讀提交歷史。或者你可以把它交給 Sentry 的 Seer，一個由 LLM 驅動的除錯代理，它會讀取你的 traces、錯誤與程式碼，然後告訴你什麼壞掉了。

Seer 很擅長這件事。它不是通靈者。這兩句話之間的差距，就是這篇文章的主題。

統計除錯到底是什麼意思

統計除錯利用多次執行中的模式來精確定位 bug。傳統除錯器只顯示一次執行。統計方法看的是分布：哪些函式一起失敗、哪些 traces 與錯誤相關、哪些提交 precede 了當機高峰。

Sentry 做統計部分已經很多年了。Seer 加入了一個 LLM 來在這些資料之上推理因果關係。它沒有取代統計，而是詮釋它們。

Seer 不會從虛無中幻覺出根本原因。它看的是你本來就會看的相同 traces 與 stack trace，但它在幾秒鐘內讀取數千個 span，並將它們與你的 codebase 關聯。

Seer 如何在不被 span 淹沒的情況下讀取 trace

一個分散式 trace 可能包含數千個 span。將所有內容塞進 LLM 的 context window 只會造成混亂。模型會固執於無關的細節而錯過訊號。

Sentry 透過建立壓縮過的 trace tree 來解決這個問題。不是每個 span，Seer 看到的是一個 transaction 的層級結構，也就是將 span 分組成有意義單元的 service boundaries。這棵樹顯示哪些 transaction 呼叫了哪些其他 transaction、它們花了多久，以及其中是否有任何錯誤發生。

以下是一個原始 trace 概念上的樣子：

GET /api/checkout
├── POST /payment-service/process
│   ├── SELECT * FROM orders
│   └── UPDATE inventory
├── GET /user-service/profile
│   └── SELECT * FROM users WHERE id = ?
└── POST /notification-service/email
    └── SMTP send

Seer 收到這棵附帶時間與錯誤狀態標註的樹。它看到結帳請求呼叫了三個下游服務。它看不到每個個別的資料庫查詢，除非它主動要求。

關鍵字是「除非」。Seer 有工具。如果樹顯示支付服務有問題，它可以取得該 transaction 內的完整 span、透過 ID 關聯的錯誤事件，或 CPU profile。它決定下一步要看什麼。

這種 agentic 方法與「把這個 trace 貼到 ChatGPT」之間的差異，就是 Seer 實際在做的事。一個聊天機器人只有一次機會。Seer 有一個迴圈：觀察、推理、取得更多資料、再次推理。

Seer 為了解決跨服務問題而誕生

在 trace 出現之前，Seer（當時叫做 Autofix）依賴 stack trace 與 breadcrumbs。這對單體式架構有效。對分散式系統無效。

考慮一個前端 500 錯誤。stack trace指向一個 fetch 呼叫。沒有 trace 的話，Seer 會判定前端壞掉了。有了 trace，它看到前端呼叫了 API gateway，後者呼叫了 auth 服務，後者因為憑證輪替而拋出了 token validation 錯誤。

Sentry 自己的團隊在內部也遇到了這個問題。Sentry 後端與 Seer 微服務之間的認證問題已經持續數天。Seer 拿到了 trace tree 與兩個 repo 的存取權後，識別出根本原因並在兩個服務中開啟了 pull request。

這就是承諾。但前提是要完成設定。

Seer 要能幫助你之前需要什麼

Seer 需要三樣東西才能好好運作：

1. 連接的 traces。

如果你的服務使用不同的 Sentry 專案且沒有 distributed tracing，Seer 看到的是孤立的錯誤，而不是 trace tree。你需要在每個服務中安裝 Sentry SDK 並傳播 trace header。

在 Python 中：

import sentry_sdk

sentry_sdk.init(
    dsn="https://your-dsn.ingest.sentry.io/project-id",
    traces_sample_rate=0.1,  # Adjust for your volume
)

對於跨服務傳播，SDK 會在支援的 HTTP client 上自動讀寫 sentry-trace 與 baggage header。如果你使用自訂的 client，手動附加 header：

from sentry_sdk import continue_trace

headers = {}
continue_trace(headers).apply_to_request(headers)
response = my_custom_http_client.get(
    "http:// downstream-service/api",
    headers=headers,
)

沒有這個，Seer 會把前端與後端錯誤視為不相關的事件。Trace tree 永遠無法成形。

2. 連接的程式碼。

Seer 會搜尋你的 codebase 來將 trace 與實作關聯。這需要 GitHub 整合，並將 repo 對應到 Sentry 專案。Seer 無法從 zip 檔案或本地路徑讀取你的程式碼。

3. 足夠的訊號。

一個只有自動插樁 HTTP span 的 trace 會告訴 Seer 服務 A 呼叫了服務 B。但不會告訴 Seer 中間發生了什麼業務邏輯。Custom span 很重要。

from sentry_sdk import start_span

def process_payment(order_id):
    with start_span(op="payment.process", description="Validate and charge"):
        validate_order(order_id)
        charge_customer(order_id)

沒有這些，Seer 看到的就是 HTTP 請求與資料庫查詢之間的黑盒子。

沒人會寫在行銷文案裡的權衡

Seer 有真實的限制，而 Sentry 對此相當坦誠。

準確率很高，但不是 100%。

Sentry 回報的根因識別率是 94.5%。這表示大約每 20 個問題中就有一個被誤診。對於高嚴重性事件，你仍然需要人類在部署修復之前驗證 Seer 的結論。

每次執行都要花錢。

Seer 的執行成本大約是每次根因分析 1 美元，外加月費訂閱。自動掃描比較便宜，每個問題 0.003 美元。對於每天處理數十個問題的團隊來說，這會累積起來。請仔細設定自動化門檻。

它看不到就無法修復。

如果你的 trace 取樣率是 1%，而 bug 只出現在那 99% 中，Seer 找不到它。如果根本原因在於一個不會傳送 trace 給 Sentry 的第三方服務，Seer 會撞牆。如果問題是一個從不拋出錯誤的邏輯 bug，Seer 永遠不會被觸發。

LLM 在某些推理上仍然很差。

一項 Microsoft 研究證實了大多數開發者的懷疑：AI 代理在定位問題上表現出色，但在根本原因與症狀相距遙遠時，很難進行根因分析。跨時間的因果關係，尤其是涉及競態條件或狀態損毀時，仍然很困難。

Seer 發揮作用的時機與該跳過它的時機

Seer 值得嘗試的時機：

  • 你有一個分散式系統，trace 在多個服務之間是連接的
  • 問題涉及一個 Sentry 已經捕捉到的明確錯誤事件
  • 根本原因很可能在你自己的程式碼中，而不是第三方依賴項
  • 你有足夠的 trace 數量，手動調查已經變得繁瑣

跳過它的時機：

  • 你的 trace 沒有跨服務連接
  • 問題是間歇性的，很少被捕捉在 trace 中
  • 你需要次分鐘級的解析度來處理進行中的事件（Seer 執行需要數分鐘）
  • 根本原因幾乎肯定是基礎設施，而非程式碼

如何實際嘗試

如果你已經使用付費的 Sentry 方案，Seer 提供 14 天試用。

  1. 在你的 Sentry 組織設定中連接 GitHub
  2. 在 Seer 設定中將你的 repo 對應到 Sentry 專案
  3. 確保 SDK 中啟用了 tracing，並設定 traces_sample_rate
  4. 開啟任何問題並點擊 Find Root Cause

對於自動執行，請設定一個停止點。大多數團隊從 Stop after Root Cause 開始。一旦你信任準確率，就可以讓它提出解決方案或起草 pull request。

如果你使用 Cursor 或 Claude Code，你可以透過 Sentry 的 MCP server 直接在 IDE 聊天中呼叫 Seer。

坦誠的結論

Seer 可以透過建立壓縮過的 trace tree、按需取得詳細資料，以及跨 codebase 推理，來在 trace 中找到根本原因。對於連接良好、插樁完善的分散式系統，它確實很有用。Sentry 自己的工程師在跨服務問題上節省了數天的除錯時間。

它不是取代你理解自己系統的工具。它是一個非常快、讀過很多書的實習生，能讀 trace 與程式碼，但仍然偶爾會怪錯服務。用它來加速調查，而非消除調查。

如果你的 trace 乾淨、連接良好且充滿有用的 span，Seer 可能會讓你驚艷。如果不是，先修好 trace。沒有 LLM 能除錯你從沒費心插樁的東西。

常見問題

Seer 能與自架的 Sentry 搭配使用嗎？ 不能。Seer 是一個需要 sentry.io 的雲端服務。它依賴 Sentry 自己的基礎設施來執行 LLM 代理並存取你的遙測資料。自架實例無法使用 Seer。

Seer 能分析 Python 與 JavaScript 以外的語言的 trace 嗎？ 可以。Seer 讀取的是 Sentry 的 trace 資料，而非原始語言專屬的遙測。任何使用 Sentry SDK 插樁並產生 trace 的服務都可以餵給 Seer。程式碼分析步驟需要 GitHub 整合，這支援任何語言。

如果 Seer 的根因判斷錯了怎麼辦？ 你可以在分析過程中提供回饋，Seer 會納入考量。最終輸出總是需要人類核准，才會套用任何程式碼變更或開啟 PR。除非你明確設定，否則不會自動部署任何東西。

這與直接把 stack trace 貼到 Claude 或 ChatGPT 有什麼不同？ 聊天機器人只拿到你貼上去的單一 context window。Seer 擁有一個 agentic loop，可以存取你的完整 trace tree、關聯錯誤、CPU profile 與 codebase。它可以在推理過程中取得更多資料，而且它知道你的系統結構，因為它讀的是實際的程式碼。