LangWatch：把追蹤、資料集、評估與提示優化綁成一個迴圈的開源平台

LangWatch 想解的是評估流程的斷點，不是模型品質本身

多數團隊做 LLM 應用的困境不在於寫不出 prompt，而在於改完 prompt 之後沒有一套可重複的驗證方式。線上出了問題，trace 存在某個 APM 裡；想驗證修正，測試案例散在試算表；要跑評估，得另外接一套評估框架；評估結果又跟提示版本對不上。LangWatch 的定位就是把這幾段接起來。README 的敘述是 Trace → dataset → evaluate → optimize prompts/models → re-test，並強調 no glue code, no tool sprawl。這個順序本身就是產品主張：追蹤產生的真實案例可以沉澱成資料集，資料集拿去跑離線評估，評估結果回饋到提示優化，優化後的版本再回到追蹤驗證。目標讀者是已經有 agent 上線或即將上線、需要回歸測試與模擬的工程團隊，而不是只想對單一 prompt 打分的人。

OpenTelemetry 是資料入口，ClickHouse 是資料落點

README 明確寫 OpenTelemetry/OTLP-native，並在整合章節指向 OpenTelemetry 指南。這代表 LangWatch 不要求你改用它的專有 SDK 才能取得 trace：任何已經輸出 OTLP 的框架或 provider 都能把資料送進來，官方也說自己是 framework- and LLM-provider agnostic by design。這是一個架構上的讓步，也是一個約束。讓步在於採用成本低，你不用為了評估而重寫 instrumentation；約束在於你能查詢的欄位取決於 span attribute 的語意，超出 OTLP 標準語意的資訊要靠 LangWatch 自己的 SDK 補齊，這也是它同時維護 Python、TypeScript 與 Go SDK 的原因。儲存層的線索來自啟動方式：本地開發章節要求先跑 docker compose up redis postgres opensearch，而 npx 安裝路徑則會拉起 postgres、redis、clickhouse。兩種路徑的差異本身就是一個訊號，正式環境的追蹤資料量需要 ClickHouse 這類列式儲存來承接，而 OpenSearch 出現在開發路徑裡，說明搜尋與檢索是流程的一部分。

AI Gateway 是獨立的 Go 二進位，不是主服務的一個模組

README 把 AI Gateway 描述成 OpenAI/Anthropic-compatible proxy，具備 virtual keys、hierarchical budgets、inline guardrails、跨 provider 自動 fallback，以及 Anthropic cache_control passthrough。更關鍵的是部署形態：它 ships as a separate Go binary，路徑為 services/aigateway/，並附帶 Helm sub-chart charts/gateway/。把治理層拆成獨立程序有實際好處，代理的升級與主平台的升級可以分開進行，掛掉時影響面也不同。README 提到約 700 ns 的 hot-path overhead，這個數字來自專案方，我沒有實測，也不打算替它背書；但把延遲寫進 README 說明團隊自己知道這是這類代理最容易被質疑的地方。要注意的是這個子系統用 Go 寫，而主體是 TypeScript，兩者的相依管理與 CI 路徑不同，維運上等於多一套要顧的產物。

用 npx 起一個完整環境，代價是三個 evaluator 的取捨

README 給的最短路徑是 npx @langwatch/server，只要求 Node.js。這個 CLI 會把 uv、postgres、redis、clickhouse、AI gateway binary 以及 Langy 助理的 runtime 安裝到 ~/.langwatch/，產生帶有本地密鑰的 .env，平行啟動所有服務，最後開 http://localhost:5560。想要乾淨重置就是 rm -rf ~/.langwatch。三個開關放在 ~/.langwatch/.env：LANGWATCH_ENABLE_LANGY 預設 true，會多約 45MB，README 直說它的 worker 以你的身分在機器上執行且沒有沙箱隔離；LANGWATCH_ENABLE_PRESIDIO 預設 false，開啟會多約 670MB 的語言模型，官方特別註明它自己的密鑰與 PII 遮蔽不依賴這個 evaluator；LANGWATCH_ENABLE_LINGUA 預設 false，多約 95MB。其餘 evaluator 無論如何都會安裝。改完設定要重啟伺服器。偏好容器的人可以走 git clone 後進 platform/app，複製 .env.example 為 .env，再 docker compose up -d --wait --build。

把 Langy 打開等於讓未隔離的 worker 在你的機器上跑

LANGWATCH_ENABLE_LANGY 預設是 true，而 README 對它的描述是 workers run unsandboxed as you, on your own machine。這句話值得停下來讀兩遍。預設開啟、沒有沙箱、以你的權限執行，三個條件疊加起來，對於在個人筆電上試玩的開發者影響有限，對在共用開發機或 CI runner 上跑的人就是一個要主動處理的設定。關掉它的成本只是失去 Langy 助理，其餘評估功能不受影響。第二個限制是資源。Presidio 一個 evaluator 就佔約 670MB，比其餘評估環境加起來還大，語言偵測再加約 95MB。這代表「全部打開」不是免費選項，在記憶體吃緊的環境裡必須明確取捨。第三個限制來自部署形態本身：Postgres、Redis、ClickHouse 三套儲存同時存在，備份、升級與容量規劃都得各自處理，這也是它與託管服務之間最大的體驗落差。

與 LangSmith、Langfuse 的差別在於評估迴圈是否閉合

同樣處理 LLM 可觀測性的專案不少，LangSmith 與 Langfuse 是最常被拿來對比的兩個。差別不在於誰收的 trace 多，而在於從 trace 到評估之間有沒有一段產品化的路徑。Langfuse 的強項是把 trace、prompt 管理與評分集中在一處，資料模型圍繞觀測建構；LangSmith 綁定 LangChain 生態較深，對非 LangChain 的 stack 需要額外接線。LangWatch 選擇的是把資料集當成第一級物件，讓 trace 可以直接轉成評估案例，再讓評估結果回到提示優化。這個選擇的代價是系統更重，你需要 ClickHouse 這類儲存來支撐資料集與評估的查詢模式。反過來說，如果你的評估流程本來就靠筆記本與散落的 CSV 在跑，LangWatch 的價值不在於多收幾條 trace，而在於把那段流程固定下來。

Apache-2.0 是地板，不是天花板

README 的授權徽章寫的是 Apache 2.0 + Enterprise，並附上一句 open-core: Apache 2.0 floor + Enterprise extension。這代表倉庫裡存在兩種授權狀態的程式碼，Apache-2.0 覆蓋的部分可以自由使用、修改與再散布，Enterprise 目錄則適用另一套條款。實務上的風險不是「能不能用」，而是「用了之後會不會踩到邊界」。自架時若只部署核心服務，通常落在 Apache-2.0 範圍；一旦啟用標示為 Enterprise 的功能，條款就跟著改變。這件事沒有模糊空間，但需要你自己去核對倉庫目錄與授權檔，本文不提供法律意見。維護成本方面，從 release 節奏可以看出這個專案在動：sdks/go/v1.0.0、typescript-sdk@v1.13.0 與 skills@v1.4.0 都在 2026 年 9 月發布，Go SDK 才剛到 1.0.0，意味著它的 API 表面還在穩定化階段，鎖定版本並保留升級測試的時間是合理的做法。

編輯結論

已經在用 OpenTelemetry 蒐集 LLM trace、而且需要把評估結果沉澱成資料集反覆回歸的團隊，LangWatch 值得排進試用清單；如果你的需求只是單次呼叫的品質評分，或團隊無法承擔 Postgres、Redis、ClickHouse 三套儲存的維運，那它是過重的工具。動手前先確認三件事：把 LANGWATCH_ENABLE_LANGY 關掉後，沒有沙箱隔離的 worker 是否仍符合你的內部規範；ClickHouse 的資料保留策略能否滿足你的合規要求；以及你的部署是否會碰到 Apache-2.0 以外的 Enterprise 目錄。這三項決定 LangWatch 是能長期留在架構裡，還是只適合當一次性實驗。

官方來源

1. langwatch/langwatch on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases