# 策展 · X (Twitter) 🔥🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Akshay 🚀 (@akshay_pachaar) · 平台：X (Twitter) · 日期：2026-06-09

> 原始來源：https://x.com/akshay_pachaar/status/2064051835636498924

## 中文摘要

# 你的 Agent Harness 應該要能自我修復

當 AI Agent 在生產環境中出錯時，你的可觀測性（observability）工具會精確地顯示它做了什麼，但對於如何修復它，卻幾乎提供不了任何幫助。

你得到了一份乾淨的執行追蹤（trace），包含每一次模型呼叫、觸發的工具、每個步驟耗費的時間，以及以 token 計算的成本。

但你沒得到的是：為什麼它會壞掉？哪種變更可以修復它？或者，下週同樣的問題不會再次發生的保證。

於是，你只能在追蹤紀錄中一段一段地捲動，針對出錯原因提出假設，手動寫下修復程式碼，然後祈禱這不會破壞原本運作正常的其他功能。

接著，新的模型版本發布了，帶來了一批新的故障模式，你又得從頭開始執行整個手動循環。

真正的瓶頸不在於你的可觀測性工具，而在於當追蹤紀錄出現在螢幕上之後，所有必須進行的後續工作。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891444-iaHKSta5UaAAE4D7Sjpg.jpg)

Cursor 最近分享了他們在 Agent 的 harness 上投入了多少工程心力——也就是圍繞在原始模型之外，由 Prompt、工具和檢查機制組成的層級。在同一個模型上，更好的 harness 能帶來遠勝以往的結果，而這項工作永遠沒有真正結束的一天。

這正是所有可觀測性平台讓你感到無力的地方。它們回答了「發生了什麼事」，然後就把「為什麼發生」、「該改什麼」以及「如何防止再次發生」這些難題丟回給你。

這個落差，就是目前大多數團隊深陷其中的循環。以下說明為什麼這個問題總是不斷重演，以及最終需要什麼才能終結它。

# 為什麼現有的可觀測性在規模化時會失效

大多數的 Agent 可觀測性平台在提供追蹤紀錄後就停止了。

你得到了一棵 span 樹、延遲數據、token 成本和一個儀表板。但你沒得到的是：為什麼失敗、該修復什麼，或是任何不會再次故障的保證。

- 「發生了什麼事」 → 平台處理這個部分
- 「為什麼發生」 → 手動
- 「這是修復方案」 → 手動
- 「這不會再次故障」 → 手動

這在 2023 年或許是個合理的產品，但對於今天在生產環境中運行 Agent 的團隊來說，這是一種錯誤的抽象層級。

問題會不斷疊加。每一次模型升級都會引入新的故障模式，每一個新工具都會增加新的邊緣案例（edge cases）。Harness 變得越來越複雜，速度快到沒有團隊能手動追蹤並修復。

以下是解決這個問題的技術堆疊。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891691-iaHKStt7DbEAAb7oEjpg.jpg)

# Opik：為 Agentic 時代而生的 AI 可觀測性與 Evals

Opik 是一個開源的日誌記錄、除錯與最佳化平台，專為 AI Agent 和 LLM 應用程式設計。Opik 的核心前提是：這個循環應該自動化，而不是靠人力堆疊。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891848-diaHKSuZYNbwAAyjhjpg.jpg)

# 四層堆疊架構

Opik 的架構是一個相互連結的工作流程。

追蹤（Trace）→ Ollie 診斷 → Ollie 提出修復建議 → 套用並驗證修復 → 測試套件（Test Suite）將故障鎖定為回歸測試 → 回到追蹤

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891687-iaHKSulwkbYAApCVAjpg.jpg)

以下是每一層的說明：

## 第一層：追蹤（Tracing）

每一次 LLM 呼叫、工具呼叫和檢索步驟，都會透過一個簡單的 decorator 自動進行檢測（instrumentation）。

```python
import opik

@opik.track
def my_agent(query: str):
    # 在此處編寫你的 Agent 邏輯
    ...
```

它能直接與 LangGraph、CrewAI 以及超過 50 種框架相容。每一筆追蹤紀錄都會記錄當時啟用的 Agent 設定，當你需要稍後重新執行失敗的輸入時，能確保完全的可重現性。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891865-iaHKSwDwNboAATBy7jpg.jpg)

## 第二層：Ollie

其他所有可觀測性平台都止步於「這是你的追蹤紀錄」。Opik 則在 Ollie 的驅動下，從追蹤紀錄直接邁向修復後的程式碼。

Ollie 是內建於 Opik 中的一個程式開發 Agent。單一 Agent，完整脈絡。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891852-iaHKSwqWkakAAhrBVjpg.jpg)

即使沒有程式碼存取權，Ollie 也能讀取 span 樹、識別故障模式，並解釋跨越所有 LLM 呼叫的因果鏈。你可以問它：「為什麼最終答案忽略了檢索到的 context？」它會遍歷完整的 span 樹並找出根本原因。

從你的專案根目錄執行 `opik connect`，Ollie 就會升級到完整的程式碼修復模式：

- 讀取你的原始程式碼檔案
- 識別出導致問題的確切行數
- 提出 diff（差異檔）；在未經你明確批准前，不會變更任何內容

一旦你批准，Ollie 就會針對原始失敗追蹤中的確切輸入重新執行你的 Agent，串流輸出新的追蹤紀錄以供並排比較，並將原始故障鎖定為測試套件中的回歸測試案例。

錯誤追蹤 → 根本原因 → diff → 批准 → 重新執行 → 鎖定回歸測試

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891421-diaHKSxAsCbAAEPsHjpg.jpg)

## 第三層：測試套件（Test Suites）

大多數的 Eval 工作流程是：建立標記資料集、定義數值指標、比較浮點數。這種模式適合研究人員，但不符合工程師對品質的思考方式。

Opik 用淺顯易懂的英文斷言（assertions）取代了上述做法。

```python
suite = opik.TestSuite("crm-agent-v2")
suite.add_assertion("The response must include specific deal details, not just a count")
suite.add_assertion("The response must never reveal unauthorized information")
suite.run_tests()
```

Opik 會在底層將這些斷言轉換為「LLM-as-a-judge」（以 LLM 作為評審）的檢查機制。每個測試案例都會得到明確的通過/失敗結果。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891441-iaHKSxkDzbYAA0bd3jpg.jpg)

真正改變工作流程的部分在於：你除錯的每一個失敗追蹤，都會自動成為一個新的測試案例。測試套件會從真實的生產故障中成長，而不是依賴某人預先編寫的合成場景。

每一個週期，你的 harness 都會變得更難以被破壞。

但即使測試套件不斷擴大，你仍然需要一個安全的地方來測試變更，然後再進行部署。這就是第四層的作用。

## 第四層：Agent 沙盒（Sandbox）

大多數的 Playground 只是 Prompt Playground。你更改一個系統 Prompt 並重新執行一次 LLM 呼叫。這回答了錯誤的問題。

生產環境中真正的問題是：當我更改這裡時，整個 Agent 圖（graph）會發生什麼變化？

Opik 的 Agent 沙盒（Sandbox）會在 UI 內端到端地執行經過完整檢測的 Agent。更改 Prompt、替換模型、新增工具，並觀察整個系統在完整的 span 樹中如何回應。每一次沙盒執行都會產生完整的 Opik 追蹤紀錄。

非開發人員的利害關係人、產品經理（PM）、領域專家和 QA 團隊，都可以在不觸碰 Git 的情況下安全地測試設定。

# 飛輪效應的實踐

這些層級並非獨立的功能，而是一個循環。

使用 `@opik.track` 進行檢測。宣告一個 `opik.Config`。生產環境中發生故障。Ollie 讀取追蹤紀錄、讀取你的原始程式碼，並提出修復建議。你批准。Ollie 在沙盒中針對原始失敗輸入重新執行 Agent。修復通過。將其儲存為新的 Blueprint。環境指標指向 Staging。原始故障被鎖定為回歸測試。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780987891684-iaHKSz8UVaIAAtf84jpg.jpg)

下一次故障會進入同一個循環。

每一個週期，你的 harness 都會變得更難以被破壞。

# 閉合循環

當 Agent 很簡單時，止步於追蹤紀錄的可觀測性是有意義的。一旦它們進入生產環境，真正的重點在於追蹤紀錄之後的所有工作，而這正是 Opik 為你處理的部分，而不是把它留給你自己解決。

整個堆疊皆為開源，包含追蹤（Tracing）、Ollie、測試套件、Agent 沙盒、一個 6 演算法的 Agent 最佳化器，以及超過 50 種框架整合，該專案在 GitHub 上已獲得超過 19.3K 顆星。

只需三個指令即可完成自架：

```bash
git clone https://github.com/comet-ml/opik
cd opik
./opik.sh
```

Cursor 所描述的手動循環，正是 Opik 能自動閉合的循環——從一個錯誤的追蹤紀錄，一路到鎖定回歸測試。

如果你正在生產環境中運行 Agent，這絕對值得一試。

查看 Comet ML 和 Opik →

（別忘了按個星號 🌟）

你目前的 Agent 堆疊中，可觀測性的狀態如何？對於你的團隊來說，除錯循環目前在哪個環節斷裂了？

---

如果你正在打造 AI 工程師會喜愛的開源工具，歡迎與我們聯繫。我們只會報導通過我們自身測試的工具，所以我們會先試用你的產品，只有在它表現優異時才會撰寫報導。

感謝 Comet ML 贊助今日的內容。

## 標籤

Agent, Harness, 自動化, 產業趨勢, Agent Harness