你連 p99 latency 都沒在看，怎麼知道哪個工具穩定
r/openclaw 那串 OpenClaw vs Hermes 的戰文已經打幾百樓了，每次更新出來就有人喊爛、有人說換工具、有人說回滾、有人說這模型差那模型好。
看到看累了。
說穿了，大部分的「不穩定」抱怨根本不是模型的問題，是 infra 問題。更具體一點：是你根本沒定義什麼叫「穩定」。
「覺得不穩」不是指標
每次社群在吵穩定性，大家說的都是模糊的感覺：「感覺變慢了」「有時候回應怪怪的」「更新後 agent loop 一直卡」。這些描述放在 on-call 報告裡是廢話。
實務上，給 AI 服務定義穩定性，我用的是三個數字：
- Error rate（錯誤率）：tool call 失敗、context overflow、API timeout 各自算，不要混在一起
- p95/p99 latency：不是平均值，是尾端延遲。平均值會騙你，尤其 LLM call 的延遲分佈通常是有長尾的
- Task completion rate：agent 完整跑完任務的比例，這才是使用者真正在意的
有這三個數字，「感覺不穩」就可以翻譯成「v2.3 之後 p99 latency 從 4.2s 跳到 11.8s，task completion rate 從 87% 掉到 71%」。有了這個，你才能評估到底是模型問題還是 orchestration 層問題、還是你自己的 prompt 爛。
沒有這些數字，你只是在吵架。
升級節奏的問題
很多人踩的坑是：新版一出就全量更新，然後爆炸，然後才想到要 rollback，然後緊急叫醒同事。
我現在的做法是把 AI tooling 的升級拆成三個階段：
第一步：staging 跑 regression
不是官方 benchmark，是你自己的 use case。我有一套 25 條測試案例的腳本，涵蓋最常見的 10 種任務類型，跑完後自動 diff 輸出跟 baseline：
python run_benchmark.py --version 2.4 --baseline 2.3 --cases ./test_cases/
# 輸出：Pass: 23/25, Regression: 2 (task_type: code_review, infra_query)
有 regression 就先 hold，去看是什麼任務類型壞掉再決定要不要繼續推。
第二步：canary 10% 流量
先讓 10% 的 request 走新版，跑 24 小時，看指標有沒有 drift。k8s 上做起來不複雜：
# 兩個 deployment，透過 service weight 控制
openclaw-stable: weight 90
openclaw-canary: weight 10
第三步：全量推
Canary 期間指標沒有異常，再全量切過去。有問題的話 rollback 一行指令，不用緊急會議。
這套流程讓「更新炸掉」變成一個小事故，而不是緊急事件。整個流程跑順之後，我花在「更新出問題」上的時間從平均每次兩小時降到不到 20 分鐘。
可觀測性才是真正的護城河
切回社群那個討論。有個 comment 說「OpenClaw 不如 Hermes 穩定」，底下馬上有人反說「我用 OpenClaw 沒問題啊」。這種討論永遠沒有結果，因為兩個人根本在說不同的事情，衡量標準也不一樣。
穩定性不是主觀感受，是可量測的。如果你沒有在監控，你就沒有資格說哪個工具穩定。
我現在跑的 AI infra observability stack：
- Tracing：每個 agent run 都有 trace ID，tool call、LLM call、retry 全部串在一起，用 OpenTelemetry 收
- Metrics：Prometheus 收 latency histogram 和 error rate，Grafana dashboard 跑起來，SLO alert 設好
- Structured logging：每個 LLM response 記 token count、finish_reason、cost，方便事後 debug
這套東西讓我做到一件以前做不到的事：某個任務類型成功率從 85% 掉到 60%，五分鐘內定位到是哪個 tool call 開始失敗。沒有 observability，你只知道「壞了」；有了 observability，你知道「為什麼壞」。
一旦你能回答「為什麼壞」，換不換工具、換不換模型這個問題才有意義。你
知道是模型問題、prompt 問題、還是 tool definition 問題，再決定要換工具、調整 prompt、還是等廠商修。
OpenClaw vs Hermes 討論問錯了問題
這兩個工具都在快速迭代，都會有版本不穩的時候，很正常。但如果你沒有基礎的 monitoring，你根本沒辦法評估哪個「更穩」。你只是在根據直覺和社群風向換來換去，下次換回來的時候又炸一次。
更現實的問題是：你有沒有人在看 AI 服務的 error budget？有沒有定義 SLO？有沒有 runbook 說清楚「LLM API 延遲超過 5 秒時要做什麼」？
我猜大多數都沒有。因為 AI agent 是新東西，大家還在「玩」的階段，還沒把它當 production service 的標準來對待。
結果就是每次更新都在靠直覺賭，賭完爆了就抱怨，抱怨完換工具繼續賭。
這個循環不會因為工具換得更好而打破。先定義穩定，再建 observability，再談升級節奏。模型是之後的事。
作者：CtrlC