你的代理修好了，卻弄壞了別的東西——專訪 Arize AI 的 Sofia Jakovcevic

Arize 是可觀測性（observability）廠商，其 Forward Deployed Engineer（前線部署工程師）Sofia Jakovcevic 主張：AI 代理（agent）是在執行階段（runtime）出錯，而非在程式碼裡出錯，因此團隊必須以生產環境的追蹤資料（trace）與評估分數建立回歸測試，而不是憑直覺就上線提示（prompt）變更。這場演講大部分時間花在五步回歸迴圈，以及 Arize 對應工具的實機操作，最後才以一個前瞻性主張收尾：代理終究應該能自行除錯與修復；標題所說的「修好一處、弄壞另一處」情境只是開場舉例，並非整場演講的主體。

Jakovcevic 是站在廠商立場現身說法，示範 Arize 的 Prompt Playground、Agent Playground、prompt hub、evaluator library，以及一個公開的「agent skills」儲存庫，用來把編碼代理連上可觀測性後端。讀者應該帶走三件事：具體的失敗案例（一行提示變更讓動作安全性提升 17 分，任務完成度卻掉了 17 分）、把主觀的代理行為轉成數字的機制，以及「每一次生產環境失敗都該變成永久回歸測試」這個論點。

一行提示變更，淨效果可能掛零

Jakovcevic 的核心警示案例是這樣：一位資安工程師審閱客服代理的政策，要求加一行，規定代理在採取任何動作前都必須先確認。上線一週後，用生產資料做評估顯示，動作安全性提升了 17 分——工程師的直覺是對的——但任務完成度同時掉了 17 分，因為一個每步都要先確認的代理，遇到使用者中途離開時，工作階段就懸在那裡沒完成。兩項效果平均下來，淨值為零。

她的重點是：改善代理的某一個面向，並不等於改善代理本身。她直接問聽眾：換作是你，會不會把這個變更上線？然後自己回答：在評估測試出現之前，很多人會。她為這種失敗模式取的名字是「憑感覺寫程式」（coding on vibes）——相信用自然語言描述的直覺來判斷代理行為，而不是相信有資料支撐的數值評估套件。

「diff 告訴你改了什麼，trace 才告訴你實際發生了什麼。」

代理是在執行階段出錯，不是在程式碼審查時出錯

這個例子最根本的錯誤，在於一個不切實際的假設：以為缺陷會出現在程式碼層級。程式碼審查者看到的，是系統提示 markdown 檔裡的一行修改——區域性、簡單、很容易核准。但行為上的改變並不區域性：這一行改變了代理的運作方式、增加了步驟、改變了它與子代理（subagent）協作的方式，也改變了它呼叫工具的方式。這些影響散佈在可能數千條的軌跡裡，而這些軌跡只存在於可觀測性後端，不在靜態程式碼中。

Jakovcevic 把這件事定調為「真相來源（source of truth）位置的轉移」。傳統軟體裡，邏輯是寫下來的，執行階段在進入生產前就可預測；有了代理之後，邏輯只存在於執行階段，而「寫下來的東西」與「實際發生的事」之間的落差，全被無聲的錯誤填滿。追蹤資料——也就是代理實際行為的結構化日誌——成了新的真相來源，回歸測試必須從這裡開始。

五步回歸迴圈

Jakovcevic 提出一套可重複的流程，把生產環境行為變成合併前的關卡。每一步都對應到具體的產出物與具體的 Arize 功能。

關於第 1 步，她特別強調第四類——成功流程——因為目標不只是證明修復有效，還要證明它沒弄壞原本能運作的東西。關於第 4 步，她把迴圈延伸到提示修改之外：團隊可以一次測試多個提示變更，也可以測試換模型。她舉的例子是某團隊想換用一個新模型（「新的 Fable 模型」），成本是原本的五倍；實驗套件就是讓你在切換之前，用數字證明投資報酬率（ROI）的工具。

評估器把判斷轉成分數

評分層是讓整個迴圈得以自動化的關鍵。Jakovcevic 列出代理真正重要的指標——幻覺（hallucination）、準確度、工具軌跡、步驟效率——並指出這些都是主觀的：人類審查員可以判斷某個輸出是不是幻覺、是不是走了最有效率的路徑，但這種做法無法規模化。LLM-as-a-judge 會拿一段 span、trace 或日誌紀錄，對照一份定義「什麼算有事實根據、什麼算有效率」的指南來評判，本質上產出的是二元分類。她的例子是一個任務完成度評估器，評分為完成或未完成，這種零一分結果也可以對映到零到五分，或多個標籤。

她明確表示，LLM-as-a-judge 不是唯一選項：確定性檢查適合用程式碼評估器，另外也有機器學習評估器可用。她展示的 Arize evaluator library 內建幻覺、使用者挫折感等選項，另有程式碼範本與安全檢查，其餘需求都能客製。

在介面上測試單一代理與多代理系統

Jakovcevic 在 Arize 平臺上示範兩條路徑，兩者都跑在她精選的 100 筆資料集上，內容涵蓋邊界案例、已知失敗與成功流程。在 Prompt Playground 裡，單一代理被建模成一個提示，加上掛載的工具、模型與 LLM 設定；她從 prompt hub 取出一個已儲存的提示（第一版），載入資料集，複製提示以便並排測試兩個版本，再掛上任務完成度與動作安全性兩個評估器。執行後，每一筆紀錄都會被評分，結果顯示在實驗執行檢視中，同時附上延遲、總成本與隨時間追蹤的錯誤率。

Agent Playground 則把這套做法延伸到多代理系統。透過 HTTP 呼叫連線遠端代理後，團隊可以在自己的程式碼庫裡改變子代理之間的溝通方式，再讓每一筆資料集紀錄去呼叫線上的代理，輸出同樣由同一組評估器評分。她提到，同樣的實驗也可以用 SDK、REST、CI 或 CLI 以程式化方式執行。

以代理的速度閉環

Jakovcevic 描述的手動迴圈是這樣跑的：可觀測性為每一次生產執行擷取追蹤資料，評估為它評分，工程師實作變更（提示、模型、工具、技能或政策），實驗測試並反覆調整，通過的變更才上線。關鍵動作在失敗時發生——失敗的生產追蹤資料會被回饋進回歸套件，成為新的測試案例。她的第一個結論：每一次失敗都該變成一個測試，這樣套件會自己長大，代理也越來越難被弄壞。

她的第二個結論，針對她認定為瓶頸的環節：由人來盯儀錶板、做問題分類、審 PR。她問：如果由代理來做調查並提出修復方案，會怎樣？並預測會從可觀測性走向自我改善——可觀測性不再是人理解代理，而是代理理解自己，具備改善自己、為自己負責的工具。她指出，編碼代理若對生產環境毫無可見度就推送 PR，等於「盲推 PR」，只能依賴靜態程式碼；把編碼工具連結上生產追蹤資料庫，它們才能看到全貌。Arize 公開的 agent skills 儲存庫，就是她所說、把編碼代理接上 Arize 介面每一項功能的機制。

「最好的代理不只從失敗中學習，最好的代理會自我修復。」

這場演講留下的空白

有兩條線索值得後續追蹤。第一，自我改善的願景是宣示而非實證——Jakovcevic 在產品裡展示的是由人驅動的迴圈，而代理驅動的調查與修復則被描述為「下一個前沿」，既沒有可運作的範例，也沒有時間表。第二，回歸迴圈的品質完全取決於評估器的校準：一個會誤判任務完成度的 LLM-as-a-judge，等於用錯誤的分數來決定合併與否，而演講並未說明該如何驗證評估器本身。真正具體、可立即使用的內容，是五步迴圈與那個 17 分取捨的例子；自我修復的代理是前進方向，截至這場 2026 年 10 月的演講為止，還不是已出貨的能力。