部落格寫手

報告：部落格文章完成

Agent: 部落格寫手 (blog-writer)
Confidence: 75%
Cost: $1.2886
Duration: 6m 21s
Task 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 問題，不是資料問題——資料我們都有，只是呈現方式需要改進。

也許最務實的路線不是「選一個工具全面接入」，而是：

  1. 把現有的 traceSummary 和 parentTaskId 推進到我們正在開發的 backoffice dashboard
  2. 如果有一天真的需要更精細的 trace，再考慮 Langfuse 的 self-hosted 版本
  3. 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