Giskard v3 重寫評析：模組化 LLM Agent 測試框架的取捨與邊界
🐢 Open-Source Evaluation & Testing library for LLM Agents
秒懂
- 它是什麼？
- Giskard 以 Apache-2.0 授權釋出 v3 完整重寫，將評估與紅隊掃描拆成獨立套件。本文檢視其 Scenario 與 Check 架構、vulnerability_scan 的定位，以及它與 v2 世代、其他測試框架的實際差異。
- 適合誰用？
- 適合以下團隊採用：正在開發多輪對話 Agent、需要把評估寫成可重跑的程式碼而非平台操作、且能接受 Python 3.12 與 LLM-as-judge 額外成本的專案。不適合：仍維護 v2 表格模型掃描的使用者，因為那部分留在舊版且不再主動維護；需要 GUI 操作或雲端儀表板的團隊，此開源版只提供程式庫與 CLI 報告。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 2 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
v3 重寫：從單體套件到模組化函式庫的定位轉變
Giskard 在 v3 做了一次徹底的架構重寫，README 明說這是 fresh rewrite，不是 v2 的增量升級。v2 仍然可用，但已不再主動維護。這個時間點採用 v3，等於接受一個較新的基礎，同時放棄 v2 世代的後續修補。
重寫的核心是把功能拆成 giskard-checks 與 giskard-scan 兩個穩定套件，再加上 giskard-core、giskard-llm、giskard-agents 三個底層函式庫。後三者被描述為自動拉入、很少直接使用。這個拆分解決了舊版依賴過重的問題，README 特別提到 v3 drops heavy dependencies for better efficiency。
對工程團隊而言，這個變動的實際意義是安裝面變輕。只寫評估測試的人可以裝 giskard-checks，不需要拖著掃描器或 provider SDK。需要紅隊功能時再加 giskard[scan]。依賴邊界清楚，這是 v2 時代較難做到的。
Scenario 與 Check：非確定性輸出的測試單位設計
Giskard Checks 的核心抽象是 Scenario、Check 與 Suite。Scenario 代表一次評估，包含互動序列與檢查項目；Check 是對 trace 的斷言或 LLM judge；Suite 則把多個 Scenario 集合起來執行。
文件中的範例展示了鏈式呼叫的風格。Scenario("test_france_capital") 先建立一個具名情境，interact 方法接受 inputs 字串與 outputs 可呼叫物件，最後 check 掛上 Groundedness 判斷。result.print_report() 輸出結果。整個流程是非同步的，main 函式要用 asyncio.run 驅動。
這個設計的關鍵在於 Target 的抽象。任何 sync 或 async 的 callable，只要符合 (inputs) -> outputs 的形狀，就能被測試，文件說 optionally with trace。換句話說，Giskard 不綁定特定框架，LangChain、LlamaIndex 或自幹的 pipeline 只要包成函式就能測。這是務實的選擇，但也代表 trace 資訊的提供完全落在使用者身上。如果 Agent 內部有複雜的工具呼叫或狀態轉移，而你不主動輸出 trace，Groundedness 這類檢查能看到的就只有最終輸出。
Groundedness 與 LLM-as-judge：判斷品質取決於法官模型
內建的 Groundedness 檢查是 LLM judge 的實例。它接收 context 參數，範例中是「France is in Western Europe. Its capital is Paris.」這段文字，然後判斷 Agent 的回答是否立足於這個脈絡。
這是典型的 groundedness 評估，用於驗證 RAG 系統的答案有沒有超出檢索內容。但要注意，這個檢查的品質完全取決於法官模型的能力。README 指出預設模型是 openai/gpt-4o-mini，要使用它必須安裝對應的 provider extra，例如 pip install "giskard[openai]"，並設定 API key。
這裡有個實際成本問題。每次跑 Scenario 都會呼叫 LLM judge，多輪對話的 trace 越長，token 消耗越高。Groundedness 之外的 Conformity 與 LLMJudge 同樣依賴外部模型。如果你的測試環境不允許外送資料到雲端 API，這些內建檢查就無法運作，你只能退回字串比對、regex 或語意相似度這類不依賴 LLM 的檢查。
vulnerability_scan：紅隊掃描與 RAG 品質評估的繼承關係
giskard-scan 套件提供 vulnerability_scan 與 quality_scan 兩個功能。前者是 v2 Scan 的後繼者，處理紅隊演練、prompt injection、jailbreak 與有害內容；後者承接 v2 的 RAGET，做知識庫品質評估。README 特別強調這兩個功能 native 於 giskard-scan，不依賴 v2。
這個繼承關係對既有使用者很重要。v2 的 Scan 與 RAGET 是分開的工具，v3 把它們收進同一個套件，但底層實作是重寫的。文件沒有提供 v2 與 v3 掃描結果的對照資料，所以無法確認偵測率或誤報率是否一致。
另一個界線是：v2 的 legacy scan 只保留給表格與 ML 模型，v3 的掃描針對 agentic system。如果你的專案同時要測傳統模型與 LLM Agent，你會被夾在兩個版本之間，v2 不維護、v3 不支援表格模型掃描。這是採用前需要明確確認的邊界。
安裝、Python 3.12 與 telemetry 的實際運作條件
安裝指令很直接，pip install giskard 會帶入 giskard-checks 與依賴，pip install "giskard[scan]" 額外加上掃描功能，pip install "giskard[openai]" 則安裝 LLM judge 的 provider SDK。Python 版本要求是 3.12 以上，這比多數仍在 3.10 或 3.11 的生產環境來得新。如果你的部署環境還沒升級，這會是第一個阻礙。
Telemetry 是選用的，README 說明不會送出 prompts 或 outputs。關閉方式有兩種環境變數：DO_NOT_TRACK=1 或 GISKARD_TELEMETRY_DISABLED=1，可以放在 .env 檔。文件提醒要在 import 之前設定，才能避免建立 ~/.giskard/id 檔案；之後設定仍會停止後續傳送。
這個設計比預設全開的套件好，但要注意 .env 的讀取時機。如果你的 CI 流程沒有載入 .env 就執行測試，telemetry 檔案還是會被建立。基於文件描述，最保險的做法是在虛擬環境啟用時就匯出變數，而不是依賴 .env 的隱含載入。
限制與誤用情境：什麼時候 Giskard 是錯的工具
最明顯的限制是 v2 與 v3 的斷裂。README 用 IMPORTANT 標註 v2 不再主動維護，但 legacy scan for tabular/ML models 仍留在 v2。這代表 Giskard 團隊把資源集中在 Agent 測試，傳統 ML 測試變成孤兒。
第二個限制是評估的非確定性。LLM judge 本身會產生變異，同一個 Scenario 跑兩次可能得到不同結果。README 說 evals 是為非確定性輸出設計的，這點誠實，但它也意味著 regression 測試的紅線會模糊。string matching 與 regex 是確定的，但 Groundedness 不是。團隊需要接受一定比例的 flaky test，或設計重試機制。
第三個限制藏在 Target 的抽象裡。文件說 Target 可以是任何 callable，但多輪 Agent 通常有狀態、有工具呼叫、有外部副作用。如果 Agent 不是純函式，interact 的線性序列就很難表達真實使用情境。Scenario 的 API 看起來是單向的對話流，文件沒有提到平行分支、條件跳躍或工具結果回饋的語法。複雜 Agent 的測試可能需要你自己在 Target 內部處理狀態，這會讓測試程式碼變厚。
替代方案的實質差異：從單體平台到程式庫的抉擇
Giskard 的開源本質是程式庫，不是平台。這與 DeepEval、Promptfoo 或 Ragas 這類同樣以程式碼為主的評估框架站在同一側，但與 LangSmith、Weights & Biases 的 LLM 監控產品有根本差異。後者提供託管儀表板、資料庫與團隊協作介面，Giskard 開源版只有 print_report() 的文字輸出。
以 Ragas 為例，它專注於 RAG 評估指標，如 faithfulness 與 answer relevancy，提供預先定義的指標集合。Giskard 的 Groundedness 概念上接近 faithfulness，但 Giskard 的野心更大，涵蓋 Agent 紅隊與漏洞掃描，Ragas 沒有對應的 vulnerability_scan。
Promptfoo 則走另一條路，它用 YAML 設定檔描述測試案例，適合不寫 Python 的團隊。Giskard 的 Scenario API 是純 Python 鏈式呼叫，與其說是設定檔，不如說是測試程式。這兩個選擇反映不同的團隊組成：寫 Python 測試的人會覺得 Giskard 自然，習慣聲明式設定的人會覺得 Promptfoo 較輕。沒有哪個絕對正確，取決於你的測試是嵌在 pytest 流程裡，還是獨立於應用程式碼之外。
維護成本與授權：Apache-2.0 的採用自由度與版本風險
授權是 Apache-2.0，商用整合沒有 copyleft 負擔，這點對內部工具或產品嵌入都算友善。但授權開放不等於維護承諾。v2 的命運就是前車之鑑，團隊在 v3 推出時直接宣告 v2 停止主動維護，沒有長期的雙版本支援期。
v3.0.0 在 2026 年 8 月釋出，同一天 giskard-scan 與 giskard-llm 也釋出 1.0.0，顯示這是團隊刻意同步的版本里程碑。但 1.0.0 同時意味著 API 可能還在不穩定階段。README 提到 roadmap 存在於 GitHub issues，沒有給出明確的穩定化時程。
升級成本方面，v2 使用者不能直接 pip install --upgrade 了事。Scenario 與 Check 的 API 是新的，v2 的 Scan 呼叫方式也換成 vulnerability_scan。README 沒有提供遷移腳本或對照表。如果既有測試資產是 v2 格式，重寫成 v3 的 Scenario 鏈式呼叫需要人工介入。對於新專案，這些成本不存在；對於老專案，這是一次實質的投資。
編輯結論
適合以下團隊採用：正在開發多輪對話 Agent、需要把評估寫成可重跑的程式碼而非平台操作、且能接受 Python 3.12 與 LLM-as-judge 額外成本的專案。不適合：仍維護 v2 表格模型掃描的使用者，因為那部分留在舊版且不再主動維護；需要 GUI 操作或雲端儀表板的團隊，此開源版只提供程式庫與 CLI 報告。採用前應先驗證三件事：你的 Agent 能否包成 sync/async callable 並在必要時提供 trace；你選用的 LLM judge 提供者（openai、anthropic 等）是否已安裝對應 extra 並設定 API key；以及你的評估場景能否用 Scenario 的線性 interact 序列表達，因為文件沒有暗示支援分支或平行對話圖。若你的測試需求超出這些條件，giskard-scan 的 vulnerability_scan 仍是獨立可用的切入點，不需要完整導入 checks 層。
社群筆記