Agent 觀測三國殺：agents-observe vs ClawMetry vs LangWatch

我用咗一年半嘅 agent 框架，由 LangChain 玩到自家寫嘅 lightweight orchestrator，中間踩過無數個坑。最令人頭痛嘅從來唔係 agent 嘅 reasoning 能力，而係——佢出錯嗰陣你根本唔知佢諗過啲乜。

LLM agent 係一隻黑盒入面嘅黑盒。你以為你 call 咗一次 LLM，實際可能係五次 tool call、三次 retry、兩次 context window 爆咗自動 truncation，再加一次 sub-agent 嘅 hallucination。而最後個 output 完全錯，你連係邊一步錯都搵唔到。

Agent observability 就係為了解決呢個問題而生的。但問題係，市面上嘅工具多到眼花繚亂。我篩走咗一大輪之後，留低三款認真試用：agents-observe、ClawMetry、LangWatch。本文用我喺生產環境踩過嘅教訓，拆解呢三款工具嘅真正分別。

點解 agent 嘅 debug 成本咁高？

傳統 software 嘅 debug 好直接：睇 log、睇 stack trace、reproduce bug、fix。但 agent 係 non-deterministic 嘅——同一段 code、同一組 prompt，每次行嘅結果都可能唔同。你冇辦法「重現個 bug」。

呢個問題喺 production 環境被放大十倍。當你個 agent 每日處理幾千個 request，其中 3% 出錯，你點樣從幾萬行 LLM call log 入面搵出 pattern？係 prompt 問題？係 tool 嘅 return value 有問題？係 context window 塞滿咗導致模型忘記咗前面嘅 instruction？定係 temperature 太高令模型亂咁作嘢？

呢啲問題嘅答案唔喺 error message 入面，而係喺 agent 嘅每一步 decision trace 入面。你要睇到每個 step 嘅 LLM input/output、每個 tool call 嘅請求和回應、token 消耗、latency 分佈、仲有 agent 嘅「思考過程」（reasoning chain）。冇呢啲數據，debug 等同蒙眼騎馬。

而 agent observability 工具嘅價值，正正就係將呢啲 data 整理成一個可以搜尋、可以過濾、可以分析嘅 dashboard。但唔同工具嘅切入點好唔同，揀錯工具嘅代價唔止係錢，仲有成個團隊嘅 debug workflow 要從頭適應。

agents-observe：輕量定太過輕量？

agents-observe 係一個比較新嘅工具，主打「lightweight, open-core, developer-first」。佢嘅 core 係一個 Python SDK，你用 decorator 或者 context manager 包住 agent 嘅執行邏輯，佢就會自動 capture 每個 step 嘅 trace。

最大賣點係 setup 真係快。五分鐘搞定，唔使改 agent 嘅核心邏輯，unobtrusive 做得好。而且佢嘅 trace 係 structured JSON，可以 export 出去自己做分析，唔使綁死喺任何 vendor 平台。

但用咗兩個月之後，我發現幾個致命問題。第一，佢嘅 UI 太簡陋。得一個 flat list of traces，冇辦法 drill down 做 multi-dimensional analysis。你想 filter 某個特定 tool call 嘅 latency 分佈？自己寫 script。你想睇某條 user query 嘅完整 trace chain？可以，但要逐條 click 入去，唔夠 efficient。

第二，community 太細。有 bug 要等幾日先有人回，pull request merge 得慢。如果你嘅 agent 系統夠複雜，你會好快撞到佢嘅 edge case——例如某啲 nested sub-agent 嘅 trace 會斷開、某啲 tool call 嘅 timing 唔準確。呢啲問題喺 demo 階段唔會出現，但 production 跑一個星期就會浮晒出嚟。

結論：agents-observe 適合 prototyping、side project、或者 team 入面已經有成熟嘅 internal observability infra 嘅團隊。如果你只係需要一個 quick way to see what your agent is doing，佢夠用。但如果你需要真正嘅 production-grade observability，佢嘅短板會好快顯現。

ClawMetry：深度 trace 嘅王者？

ClawMetry 係三款入面最「重」嘅。佢唔止係 trace tool，而係成個 LLM application lifecycle platform——monitoring、evaluation、guardrails、experimentation，全部包晒。

佢嘅 agent trace 做得極度深入。每一個 LLM call 嘅 full prompt、completion、token usage、latency，每一個 tool call 嘅 input/output/duration，agent 嘅內部 reasoning chain，全部 capture 晒。而且佢嘅 UI 係真係好用：你可以 search by user ID、by session、by error type，可以畫 latency distribution chart，可以 set alert threshold。

我用 ClawMetry trace 過一個有 7 個 sub-agent 嘅 booking system，每一個 agent 都有自己嘅 tool set 同 memory。ClawMetry 能夠將成個 execution graph visualise 出嚟，邊個 agent call 咗邊個 agent、每個 step 用咗幾多 token、邊個 step 最慢、邊個 step 成日 error——一目了然。

但缺點都好明顯：貴。Production plan 係按 event volume 收費，每個月幾千美金起跳。對於香港嘅 startup 或者 indie developer 嚟講，呢個價錢係天文數字。另外，佢嘅 onboarding 唔算易，SDK 嘅 abstraction layer 比較厚，如果你嘅 agent 框架唔係主流嗰幾款（LangChain、CrewAI、AutoGen），你要寫唔少 glue code 先兼容到。

仲有一個香港開發者會特別關注嘅問題：data residency。ClawMetry 嘅 cloud offering 嘅 server 喺美國，如果你做嘅係敏感行業（金融、醫療），send LLM prompt 出去第三方 platform 可能有 compliance 問題。佢有 self-hosted option，但 setup 複雜度又高一截。

結論：ClawMetry 係功能最全面嘅，適合預算充足嘅 enterprise team，或者 agent system 複雜到非佢不可嘅場景。但對 majority 嘅香港開發者嚟講，overkill 而且太貴。

LangWatch：開源社群嘅良心之選？

LangWatch 行嘅係另一條路——open source、community-driven、developer experience 行先。佢個 slogan 係 “Open-source LLM Observability”，而且佢真係 open，唔係 open-core 嗰種。

LangWatch 嘅 agent trace 做得唔錯，特別係佢個 “session replay” 功能——你可以將 production 嘅 agent trace 成個 replay 一次，逐個 step 睇返個 agent 點樣 decision making。呢個 feature 唔係得個睇字，係真正幫到你 debug：你見到 Step 3 嘅 tool call 返咗個 unexpected value，然後 Step 4 嘅 LLM 因為呢個 value 而開始 hallucinate，成條因果鏈一目了然。

另一個 LangWatch 嘅殺著係佢嘅 evaluation framework 同 observability 整合得好好。你可以用 production data 嚟 define evaluation dataset，然後自動 run eval 去 detect regression。呢個 loop——observe → detect anomaly → add eval → prevent regression——係真正嘅 production-grade workflow。

但 LangWatch 都有弱點。第一，佢嘅 agent trace 對於 non-LangChain 嘅 framework 支援未夠成熟。我用自家 orchestrator 嘅時候，要手動 instrument 每個 step，工作量唔細。第二，self-hosted version 嘅 performance 有 bottle neck，如果你每日有幾十萬個 LLM call，database query 會開始慢。

不過最大嘅優點係個 community。LangWatch嘅 Discord 好活躍，maintainer response 快，bug fix 通常幾日內出。對於唔想被 vendor lock-in 嘅團隊嚟講，呢個係好大嘅吸引力。

點揀？一個實用嘅 decision framework

試完三款工具之後，我總結咗一個簡單嘅 decision framework：

如果你係 solo developer 或者做緊 side project： agents-observe。Setup 最快，夠用就好，慳錢慳時間。但你遲早會 outgrow 佢。

如果你係 startup team，agent system 係 core product： LangWatch self-hosted。Open source、冇 vendor lock-in、community 活躍。你投入嘅 setup time 會喺長遠慳返嘅 debug time 度回報你。唯一要留意嘅係 infra 成本——你要預留 resources 嚟 host 同 maintain。

如果你係 enterprise，或者 agent system 嘅 failure cost 極高（例如 financial trading、healthcare decision support）： ClawMetry。俾錢買時間，買安心，買佢個 support team。對公司嚟講，幾千蚊美金一個月嘅 observability cost，相對於一次 production outage 嘅損失，係值得嘅。

一個 common mistake：好多團隊由 prototyping 直接跳去 ClawMetry，因為覺得「遲早都要用 enterprise tool」。結果 onboarding 搞咗兩個星期，發現好多 features 根本用唔着，但 contract 已經簽咗。我的建議係：先由 LangWatch 或者 agents-observe 開始，等到你真係撞到佢哋嘅天花板，先再考慮 upgrade。

結語

Agent observability 唔係奢侈品，係必需品。你寫嘅 agent 愈多、愈複雜，debug 嘅 hidden cost 就愈高。呢個成本唔响帳面上 show，但會消耗你團隊嘅研發產能。

揀工具嘅時候，唔好淨係睇 feature list。要諗你嘅實際場景：你嘅 agent system 幾複雜？你嘅 team 有冇 infra 能力去 maintain self-hosted solution？你嘅 data compliance requirements 係乜？你願意俾幾多錢去換 debug 效率？

最緊要嘅係：唔好等出事先嚟揀工具。喺你 agent system 仲係 manageable 嘅時候 setup observability，咁你先有 baseline data。等到 production 出咗大鑊嘢先嚟裝，你已經錯過咗最重要嘅 historical data。

我而家嘅 setup 係 LangWatch self-hosted + 自訂 alerting，for 我 majority 嘅 agent workload。對於一啲特別 high-stakes 嘅 agent，我會 parallel run ClawMetry 做額外 monitoring。agents-observe 我仲有用，但只限用喺 quick prototype 嘅階段。

希望呢篇比較幫到你揀啱自己嘅工具。如果你有唔同意見，或者試過其他工具，歡迎 share 你嘅經驗。