Tracely：把生產環境的失敗軌跡凍結成 CI 迴歸測試
Trace-native CI/CD for AI agents — production failures become regression tests that block the PR. Auto-detect, cluster, freeze into hermetic cases, replay in CI for $0.
秒懂
- 它是什麼？
- Tracely 是一套以 trace 為核心的 CI/CD 工具，把線上 agent 執行失敗的軌跡直接轉成可重播的迴歸案例，並在 PR 階段擋下重複出錯的提交。本文檢視它的機制、部署路徑與適用邊界。
- 適合誰用？
- Tracely 適合已經有 OTLP trace 落地、且痛點在於「看到失敗卻沒有測試可擋」的 agent 團隊，尤其是多輪對話與多 agent hand-off 的系統。若你的團隊還沒有穩定的 trace 管線，或失敗主要來自模型本身能力而非可控的程式與工具鏈，Tracely 的價值會大打折扣。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「看得到卻擋不住」這個缺口
多數 agent 觀測工具停在儀表板。你能看到 agent 壞了，但接下來呢？Tracely 的 README 把這個問題講得很直白：observability stops at the dashboard。它針對的不是「我不知道 agent 出錯」，而是「我知道它出錯，卻沒有任何機制阻止同樣的錯再進一次 main。
目標使用者是有生產流量的 agent 團隊。README 描述的流程是 production trace → failure detection → regression test → CI gate → alert，五個階段各自對應應用裡的一個頁面。這個定位意味著它假設你已經有 trace 在跑，而且失敗是可觀測的。如果沒有，這套工具沒有起點。
它同時反對 dataset-first 的做法。README 的說法是，每個 eval 工具都要求你手工編寫資料集，而那份資料集是對「什麼可能壞掉」的猜測。Tracely 的立場是：生產環境已經給了真東西，也就是那次失敗執行的完整軌跡。
trace 是唯一來源，其餘都是衍生物
Tracely 的架構核心是一句話：the recorded run is the test。失敗的執行被凍結成 hermetic regression case，每次 PR 重播。品質分數、失敗叢集、修復建議、CI 判定、趨勢、告警，全部從 trace 推導而來，README 明確寫著 there are no hand-authored datasets。
資料進來走的是 OTLP。這裡有個關鍵設計：agent.id、conversation.id、turn、step 這些 agent 語意欄位被提升為一級索引欄位。這不是裝飾性的欄位命名，它決定了查詢模型。有了 conversation.id，執行會分組成對話執行緒，而不是一堆扁平 span。如果沒有這層語意，你面對的就是 span soup，瀑布圖再漂亮也讀不出多輪脈絡。
評估器在資料模型裡的位置也值得注意。它們是 trace table 上的欄位，不是獨立分頁。每個評估器在 conversation、run 或 span 層級評分，把判定寫進表格。分數透過 SSE 即時串流，所以你可以看著一次執行被就地評分。這個選擇讓評估結果和原始軌跡綁在同一個檢視裡，省掉了在兩個系統之間來回對照的成本。
失敗進來之後會做結構與語意雙重分群。README 舉的例子是 31 次壞掉的執行收斂成一個帶計數的 issue，而不是 31 列要人逐條讀。每個叢集還能建議哪個評估器本來可以抓到它。這一步是整條流程的樞紐：沒有分群，失敗數量一大，人工分類就崩了。
凍結失敗：fixture 與 fail-to-pass 契約
把失敗軌跡變成測試的動作是「promote」。一次點擊會把失敗 trace 轉成 hermetic case，內容包含記錄下來的輸入、工具輸出與 LLM 輸出，全部打包成 fixture。
這裡有個設計上的約束值得指出：promotion 會附帶 fail-to-pass 契約。案例必須在舊程式碼上失敗、在修復後通過，否則這次 promotion 不被信任。這是一個嚴格的條件，好處是擋掉那些其實沒有重現問題的假測試；代價是當失敗本身具有隨機性時，這個判定會變得棘手。README 沒有說明在這種情況下如何處理，這是實務上要自己驗證的地方。
多輪行為走的是另一條路：scenarios。可以是腳本化的對話，也可以是一個對抗性目標，由 red-team 模型即時即興發揮。這區分了「重播一次已知的壞執行」和「探索這類目標下會不會壞」，兩者對應的測試意圖不同。
重播本身是離線的。README 強調 deterministic、offline、no API keys and no model spend，成本標示為 $0，因為用的是記錄下來的工具與 LLM fixture，不打真實模型。這一點直接決定了 CI 的可行性：如果每次 PR 都要打模型，成本和延遲都會讓這個 gate 變成團隊想關掉的東西。
CI gate 與告警流：把發現變成阻擋
gate 的執行方式是 tracely gate。README 說明它會以非零狀態碼結束、張貼 commit status、並 upsert 一則 PR comment。三件事各自對應不同受眾：exit code 給 CI runner，commit status 給 GitHub 介面，PR comment 給正在看 diff 的工程師。
告警被設計成 flow，而不是單純的規則清單。一條規則有兩半：when 與 what happens。when 的條件包括 gate 失敗、線上對話在 judge 上壞掉、出現沒人見過的失敗模式、或某個比率越線。what happens 則畫在畫布上，包含用來把關後續流程的條件、Slack、email、以及自訂 webhook。
這種畫布式設計的意圖是讓「什麼情況下通知誰」變成可視化的流程，而不是散落在設定檔裡的 if-else。README 沒有交代流程的版本控制方式，也沒有說明複雜流程的除錯手段，這兩點在團隊規模變大時會是需要自己摸清楚的部分。
值得注意的是，告警條件裡有一項是「出現沒人見過的失敗模式」。這依賴前面的分群機制能夠辨識出新的叢集，也就是說，分群的品質直接決定了這類告警的可用性。
部署：一鍵自架與四個相依服務
README 提供 Railway 的一鍵部署按鈕，會帶起 API、worker、UI，以及 Postgres、ClickHouse、Redis、MinIO。這是一個完整的自架堆疊，也是它與純雲端 SaaS 觀測工具最大的差別：資料留在你自己的基礎設施裡。
代價是維運面。四個相依服務不是小數字，ClickHouse 尤其需要對儲存與查詢模式有基本理解。對於只想快速看到 agent 品質分數的小團隊，這個組合偏重。反過來說，對於有資料落地要求、或已經在跑 ClickHouse 的團隊，這個組合是合理的。
Python 版本要求是 3.10 以上，套件在 PyPI 上是 tracely-ai，授權為 MIT。MIT 意味著你可以自由使用、修改、再散布，包含商業用途，但軟體不附帶任何擔保。這是條款層面的描述，不是法律意見，實際使用前仍應自行確認授權全文與你的合規要求。
README 另外提到一個 agent skill，標題是 teach your coding agent Tracely，讓 coding agent 理解這套工具的操作方式。這對已經在用 coding agent 的團隊可能有用，但 README 沒有說明這個 skill 的具體內容與安裝步驟。
什麼情況下它不是對的工具
第一個明確的邊界是 trace 語意。Tracely 的查詢與分群建立在 agent.id、conversation.id、turn、step 這些欄位上。如果你的 trace 只有通用的 span 名稱，沒有這層 agent 語意，對話執行緒分不出來，失敗分群的品質也會受影響。你要嘛先改 instrument，要嘛這套工具對你來說只是另一個 span 檢視器。
第二個邊界是失敗的性質。整條流程的前提是「失敗可以被凍結成可重播的案例」。如果失敗主要來自模型本身的能力邊界，而工具鏈、檢索、prompt 組裝都是對的，那麼把那次執行凍結成 fixture 之後，重播會穩定通過，因為 fixture 固定了模型的輸出。這種情況下 gate 不會擋下任何東西，你得到的是綠燈，而不是修復。
第三個邊界是 fail-to-pass 契約的穩定性。README 把它寫成信任 promotion 的條件，但沒有交代當失敗本身不穩定時怎麼辦。如果你的失敗是間歇性的，這個契約可能反覆判定失敗，讓 promotion 流程變得難用。這是要在真實資料上驗證的第一件事。
第四個邊界是規模。README 沒有給出任何關於 trace 吞吐量、ClickHouse 儲存成長、或分群延遲的數字。對於高流量系統，這些是需要自己壓測的項目。
與 dataset-first 評估工具的實質差異
最直接的替代方案是 dataset-first 的評估工具，也就是你先寫好一組問題與理想答案，再拿它去跑 agent。兩者的差異不在功能清單，而在測試的來源與保真度。
dataset-first 的測試是你對「什麼可能壞掉」的猜測，需要隨產品演進持續維護。Tracely 的測試是生產環境實際壞掉的那一次執行，README 的說法是 the exact failing run, byte for byte。這帶來兩個後果：測試的維護成本從「編寫」轉移到「篩選」，你需要判斷哪些失敗值得 promote；而測試的覆蓋範圍受限於已經發生過的失敗，沒發生過的問題不會有對應案例。
重播成本也是分水嶺。dataset-first 工具在 CI 裡跑通常要打真實模型，成本和延遲都高，團隊往往降低頻率或縮小範圍。Tracely 用記錄下來的 fixture 重播，成本標示為 $0。這讓「每個 PR 都跑完整套」在經濟上變得可行，而這正是 gate 能成立的前提。
最後是結果的呈現方式。dataset-first 工具通常讓你去儀表板看分數變化；Tracely 的設計是讓 PR 被擋下來，並透過 Slack、email 或 webhook 主動找你。README 用一句話概括這個差別：You go and look 對比 It comes to you。這兩種模式適合的團隊文化不同，前者適合有專職評估人員的團隊，後者適合希望把品質門檻直接寫進開發流程的團隊。
編輯結論
Tracely 適合已經有 OTLP trace 落地、且痛點在於「看到失敗卻沒有測試可擋」的 agent 團隊，尤其是多輪對話與多 agent hand-off 的系統。若你的團隊還沒有穩定的 trace 管線，或失敗主要來自模型本身能力而非可控的程式與工具鏈，Tracely 的價值會大打折扣。導入前請先確認三件事：你的 trace 是否帶有 agent.id、conversation.id、turn、step 這些語意欄位；自架時 Postgres、ClickHouse、Redis、MinIO 四個依賴的維運成本是否可接受；以及 fail-to-pass 契約在你的場景下能否穩定判定。
社群筆記