先看見真正卡住的地方
LLM Agent 上線前，團隊知道要測試，卻很難把「回答品質」說成一致的判斷。 提示詞或 skill 一改，答案依然看似合理，但可能已經繞過必要流程、漏掉限制，或引用錯誤資料。
改變之前，工作怎麼發生
最初的工具各自處理測試題、批次執行與結果檔案，資料格式和判斷規則散在不同位置。 同一個案例換一個人執行，得到的紀錄不一定能重現，也難以回答某次品質下降是從哪個變更開始。
- 01
定義答案契約
先寫出必須出現、不得出現，以及需要呼叫哪些工具或 skill，讓「好」有可檢查的邊界。
- 02
組合測試矩陣
將多語言、多腳本、隱含檔案與字面值契約組成可重複執行的情境。
- 03
執行並留下證據
每次 run 保留輸入、模型回應、規則判斷與必要的中間檔案。
- 04
稽核與回溯
以一致報表比較 run，辨識是資料、提示詞、skill 還是判斷規則造成差異。
工具介入哪裡，又停在哪裡
交給工具的部分
AI 負責產生 Agent 回應；測試工具負責把回應轉成可重跑、可追溯的 run 資料， 並用軌跡斷言與宣告式規則檢查必要行為。
仍然由人負責
工具不替人決定業務答案是否真的正確。規則定義、例外處理與最終發布判斷仍由工程師負責。
如何把路線真的走出來
採規格先行：先逆向整理兩套既有工具與七份需求，再收斂成單一 CLI、四個可替換接縫， 以及明確的資料契約。這讓測試平台可以替換模型或執行器，而不必改寫整條稽核流程。
成果與目前能說到哪裡
目前已完成規格、系統邊界與問題盤點，實作與量化會隨工具完成逐步補上。 這個階段的主要成果，是先把「品質」從主觀印象變成可被系統保存和比較的證據。
沿路留下的幾個判斷
- 先寫清楚什麼叫做好，再選擇要自動化哪一段。
- 判斷規則與模型回應必須分離，才能知道問題出在哪裡。
- 每次執行留下相同格式的證據，比單次看起來合理更重要。
隱私說明：案例只描述工具架構；開源前會把真實期貨領域字面值替換為虛構示例。