超越感覺編程：使用 DeepEval 推動代理式開發迴圈

在開發以 LLM 為動力的代理的早期階段，許多開發者依賴「感覺編程」——即微調提示、執行少量手動測試，並判斷輸出是否「感覺」正確的過程。雖然這種直覺式方法在原型設計上快速，但根本無法擴展且容易出現回歸。隨著代理變得更複雜，加入 RAG 流程、多種工具以及多輪對話，「感覺」已不再是可靠的品質指標。

DeepEval 透過將評估套件從被動的品質關卡轉變為主動的開發驅動器，帶來範式轉變。將強大的評估框架直接整合到編碼代理的工作流程中，開發者可以從猜測走向結構化、迭代的測量與改進迴圈。

回饋迴圈：沒有「感覺」的感覺編程

DeepEval 使評估套件與編碼代理之間形成緊密的回饋迴圈。開發者不再需要手動解讀日誌，編碼代理本身執行評估、分析失敗並實施針對性的修正。此流程遵循五階段循環：

  1. 資料集生成：代理識別或生成金標資料集。使用 deepeval generate，代理可以從文件、現有追蹤或範例中合成測試案例，確保代理在有根據的需求集合上進行測試。
  2. 套件構建：代理使用預先定義的模板建立基於 pytest 的評估套件。透過從超過 50 種指標（例如 FaithfulnessMetric 或 AnswerRelevancyMetric）的目錄中選擇，代理為成功設定客觀門檻。
  3. 執行：代理透過 deepeval test run CLI 指令執行套件。這提供了可重現、非易失的訊號，遠比基於 UI 的測試更可靠。
  4. 失敗定位：利用 span 級別的觀測，代理不僅看到測試失敗，還能看到失敗位置。若「Faithfulness」分數偏低，代理可以追溯至特定的檢索器 span，而不是猜測提示的哪個部分有問題。
  5. 修補與驗證：代理套用最小的變更——例如精練檢索器過濾條件或調整工具結構——並重新執行評估，以驗證修正且不引入回歸。

為何此方法適用於編碼代理

並非所有評估框架都適合自主的編碼代理。DeepEval 提供三項具體特性，使其成為代理式開發的高訊號來源：

  • 結構化輸出：每個指標都返回數值分數與自然語言的 reason。這讓代理能解析失敗背後的原因，而不必抓取非結構化日誌。
  • Span 級別定位：透過使用 @observe 裝飾器，失敗會映射到特定檔案與函式。這防止代理進行「散彈式除錯」，而是直接指向造成問題的程式碼行。
  • 可重現的 CLI：單一且一致的指令 (deepeval test run) 讓代理能在不同迭代間客觀確認改進。

實作代理式迴圈

要從手動評估轉向由代理驅動的迴圈，思維必須從請求代理「新增測試」轉變為請求它「驅動迴圈」。此工作流程的有效提示包括：

執行 deepeval test run tests/evals/，並修正分數最低的指標。不要更改門檻。重新執行以確認。

Faithfulness 指標在第 3、7、12 案失敗。打開每個檢索器 span，找出共同模式，並修補檢索器——而非指標本身。

透過設置防護措施——例如禁止代理降低門檻以隱藏失敗或刪除困難的測試案例——開發者可確保代理真正提升系統效能，而非玩弄指標。

從本地擴展至團隊

雖然此迴圈可完全離線運作，連接至如 Confident AI 之類的集中平台，可使此代理式工作流程在團隊中擴展。當編碼代理執行測試套件時，產生的報告可透過 deepeval view 讓人類審閱。此外，生產監控可將真實失敗案例回饋至本地資料集，確保代理的下一輪迭代自動解決實際使用者痛點。

Sources