在你睡覺時自我改進的代理——Arize AI 的 Fuad Ali

Arize AI 產品經理 Fuad Ali 主張，代理的可靠性應該用一套能自我改進的閉環來經營：把追蹤資料（traces）餵給一個常駐的審查代理，由它把失敗案例分群、提出修正方案、撰寫評測（evals），並在實驗中先證明修正有效，最後才由人合併。整場議程大部分時間都在實機示範這套閉環，示範物件是一個刻意埋了 bug 的購物助理 Wonder Toys；此外還有問答時段，坦率討論評測設計、成本取捨，以及哪些環節仍然值得由人來把關。「在你睡覺時完成」這個說法在精神上算貼切——賣點是代理趁夜讀完追蹤資料，早上就留下一份附有驗證結果的 PR——但這場演講真正談的是追蹤、評測生成與實驗的運作機制，而不是全自主代理。

Ali 的立場是產品端：他展示的是 Arize 的託管代理平臺（Signal、Agent Studio、內部代理 Alex），以及其開源追蹤埋點工具，並且明白指出這個示範裡有一個刻意植入的 bug。讀者讀完應該能建立一套具體的心智模型：這套閉環怎麼跑、Signal 抓到哪個具體的失敗、決定每一步值不值得做的成本與投資報酬率問題，以及 Ali 認為人仍然應該坐鎮的地方——驗證修正、整理資料集、設計評測。

閉環：追蹤、分群、修正、驗證、合併、重複

Ali 把代理可靠性定位成經典的 SRE 問題，只是被非確定性與規模放大得更棘手。代理可以用很多方式做很多事，失敗模式因此更難鎖定；再把這個問題乘上內部、程式開發、行銷、客服等各種代理，「這些全都替問題加了一大堆雜訊」。他的解法是一套五階段成熟度階梯，他還在現場拿來做了一次舉手調查：追蹤、評測、讓代理讀追蹤資料、把失敗案例存成回歸測試、證明修正有效。他逐階段請聽眾舉手，結果相當多人已經有追蹤，「少數幾位」已經在對追蹤資料跑評測。

閉環本身的流程是：追蹤資料進來 → Signal（Arize 內建的審查代理）讀取、把失敗分群，並針對 GitHub repo 提出修正 → 建立一筆資料集專案與一項評測 → 實驗把失敗案例重播到修正後的版本並評分 → 由人審查後合併 → 評測持續對新的追蹤資料執行，並餵給下一輪 Signal。每一輪都會累積脈絡，所以隨著新使用情境出現，這套閉環會不斷複利。Ali 舉的未來情境是：替購物助理加上一鍵結帳，這件事同時會回饋到產品路線圖與可靠性組織。

flowchart TD
    A["線上代理追蹤資料"] --> B["Signal 依排程或告警進行審查"]
    B --> C["將失敗分群，每個問題開一張票"]
    C --> D["針對 GitHub repo 提出修正"]
    C --> E["把失敗案例加入資料集"]
    E --> F["生成評測"]
    D --> G["實驗將失敗案例重播於修正後版本"]
    F --> G
    G --> H["人工審查 PR 與評分"]
    H --> I["合併並部署新版本"]
    I --> A

植入的 bug：大小寫不一致導致延遲暴增三倍

示範代理 Wonder Toys 是一套聊天式玩具購物助理，以 FastAPI、JS 前端、ChromaDB 與代理 SDK 打造，在本機執行並把追蹤資料送到 Arize AX。植入的 bug 是：產品分類以全小寫、連字號分隔的 slug 儲存，但 LLM 傳進來的是「Games」這種首字大寫、含空格的易讀名稱。篩選條件因此默默回傳空結果，代理便反覆重試搜尋——三次連續的 LLM 呼叫，延遲飆到 14–17 秒。Ali 展示了「show me toys for nine-year-olds」這類查詢的追蹤樹，裡頭有每個 span 的起訖時間、延遲、輸入、metadata、圖階段與資料庫結果。

Signal 是靠讀追蹤資料與 repo 原始碼抓到的。Ali 點進該次工作階段：代理「跑了六分鐘，也根據追蹤資料在程式碼 repo 裡找到根本原因」。它還抓到第二個不相干的問題——Ali 自己埋點失誤造成的孤立 span（orphan span）——他以此證明審查代理能揪出植入 bug 之外的真實問題。Signal 每個問題只留一張票，不會用重複票塞爆佇列，之後也會持續去重；票可以標記為已解決或忽略。

活的測試樣本才是會複利的資產

Ali 稱「加入資料集」這個流程是「這裡最重要的環節之一」，因為持續改進需要有過去失敗的紀錄來防範重演。他把上線前寫好的靜態測試案例，對比為會隨著生產環境新失敗模式出現而成長的「活的測試樣本（living fixtures）」。他的比喻是學騎腳踏車：修正一次次內化，直到你根本不再去想它——他補了一句，自己在演講前兩個月才從腳踏車上摔下來摔斷腳，所以才會想到這個例子。

資料集刻意由人來整理，而非自動填入，因為總得有人判斷某個發現夠不夠格成為永久的測試樣本。一旦有了測試樣本，評測就把預期行為寫成程式碼。Ali 展示了 Alex 根據重複重試的證據所生成的評測：一份提示模板，指示評審檢視包含工具呼叫的完整軌跡，標出任何被呼叫超過一次的 search_products，並把分數與分類寫回追蹤資料。這項評測可以對進來的追蹤資料執行、畫成圖表並設告警、追蹤其花費——而一旦該行為被固化成 CI 回歸檢查、逐筆追蹤的模型成本已不值得付，就可以把它退役。

評測分等級，而便宜的那一級正在擴張

Ali 替現場聽眾快速做了一份分類，並提到先前的 Arize 工作坊已深入講過評估器。程式碼檢查最便宜，處理確定性的問題——欄位在不在、JSON 合不合法、篩選條件有沒有套用、工具有沒有用正確引數呼叫。LLM 即評審（LLM-as-a-judge）處理質性或模糊的判斷，用另一個模型替某個模型的追蹤資料打分，代價是每筆紀錄多一次模型呼叫；靠抽樣與篩選可以把成本壓下來。代理即評審（agent-as-a-judge）用於開放式目標，由代理自己決定評分準則並打分，因為底下要跑多次 LLM 呼叫，所以最貴。決策模型（decision model）——Ali 說截至演講時問世大約一個月，Arize 也發表了相關的基準測試資料——則是便宜得多的選項，回傳的是有型別的輸出（是／否、選項、分數）。

有人問 Arize 怎麼評測 Signal 本身。他的答案是：同一套閉環，遞迴地跑。評測會在專屬的 Arize 專案裡留下追蹤資料，代理可以讀這些評測的追蹤資料來檢查評測；Signal 自己的執行也會產生追蹤資料，顯示它的指令、bash 呼叫與內部 MCP 調查呼叫。他也點出極限——除了 PR 合併率、工作階段逐字稿、交接、有沒有產出資料集或評測這類代理指標之外，「我們其實看不出更多東西」，再繼續往下評測，就只是「對著代理的輸出憑感覺，假裝自己在替股東創造價值」。

證明修正有效：實驗、門檻與驗證的成本

Ali 的實驗範例是「分類程式碼 enum 修正」那次執行，得分 88.9%——這是他自己設的門檻，他判斷這樣就夠格上線。機制是：拿失敗案例的活測試樣本，重播到修正後的代理版本，再用評測打分。Signal 可以自己透過 CLI 跑這件事，所以早上的審查不只有一份 PR，還有延遲下降、工具重試停止的證據，以及另外三項既有評測沒有退步的確認。Ali 特別強調回歸風險：在非確定性系統裡，系統提示改一個小地方，就可能弄壞你壓根沒想到的工具。

他對成本很謹慎。在實驗中執行代理可能很貴，所以要不要接進 CI/CD 是判斷題；LLM 即評審的評測會增加模型花費，因此模型選擇與抽樣率很重要，免得每次推送都「成本膨脹」。至於代理的預算該有多少比例投在自我改進閉環上，他不給數字——「大家永遠給的那個爛答案是『看情況』，但它還真的就是看情況」——而是指向幾個調節桿：餵給審查代理多少脈絡與技能、評測抽樣率，以及可以選擇用 API 把工作外包給程式開發代理、以補貼後的價格執行。

人該坐鎮四個高槓桿環節，而不是泡在追蹤資料堆裡

Ali 主張人在迴路中的核心論點是：沒有人讀得完幾千筆追蹤資料——內部程式開發代理做不到，服務數百萬客戶的聊天機器人更不可能。讀資料這種苦工該交給代理；人應該坐在判斷力會複利的地方。他點出四個環節：讀 PR 驗證修正（金融這類高風險領域非做不可，其他領域可選）、整理資料集、設計評測以把品味寫進去，以及把這些脈絡全部回饋給程式開發代理。

他也談到用決策模型的信心分數，把低信心的結果導向人工標註佇列。他引用的例子是垃圾郵件偵測：4.6% 的案例信心分數落在 0.3 到 0.7 之間，被導給人工處理，其餘則以 99.5% 準確率處理完畢。他明白表示 80% 不是通用門檻——「我不會說 80% 的信心分數對所有人都適用」——正確的切點取決於使用情境。

「能自動化，不代表就該自動化。但你應該用這套自動化，真正替審查者提供判斷依據。」

平臺可擴充，路線圖是一鍵從問題到實驗

Signal 只是 Arize 託管代理平臺上幾個內建模板之一。其他還包括成本代理，會標出用昂貴模型做廉價工作的情況、建議更便宜的路由，並量化省下多少錢。Agent Studio 讓團隊從零開始：挑一個代理設定、指向一個專案、給它一個任務、掛上技能。Ali 點名一個 Datadog 技能，用來在告警發生時拉取指標、日誌與 APM 追蹤資料；並說團隊可以針對任何可呼叫的 API 自己寫技能——但要注意把金鑰許可權收斂好、別把脈絡塞爆，因為「要真正做好告警分流，多不一定就好」。底層這些都以 Arize 託管的沙箱執行，Ali 說客戶可以自帶執行框架（Codex、Cursor、Claude Code、OpenCode，之後還會陸續增加），也可以自帶沙箱供應商（Modal、Daytona、E2B）。

官方說的方向是全端到端的閉環，人力介入趨近於零，直到有人真的需要在 UI 上點幾下。Ali 也點出實驗裡最難的開放問題：一個代理需要跑起多少相依元件。Wonder Toys 很單純——它自己起一個資料庫、整段請求重跑一次——但有外部相依的代理，要重播就「比較曲折」。他還提到 Signal 將能提出評測健康檢查（把通過率 99.999% 的評測退役、把健康狀況不佳的評測加固）、一套讓評審與人類判斷保持一致的評測對齊流程、Slack 整合，以及 PR 說明裡直接內嵌實際失敗的追蹤資料作為證據。

綜合觀察

這場演講最有意思的張力，在於 Ali 的自動化推銷與他反覆的保留態度之間。他要代理去做讀資料、分群、修正，卻始終把人留在合併鍵、資料集與評測模板上——而且他承認，過了某個點之後，評測「評測器」本身已經沒有標準答案。成本問題則是真的懸而未決：沒有預算比例、沒有固定門檻，只有攤在陽光下的花費儀錶板與調節桿。後續值得追蹤的是：決策模型是否真能讓評測便宜到可以大規模執行（Ali 自己的賭注是評測變便宜，採用的人就會變多）；一鍵從問題到實驗的流程，碰上真有外部相依的代理還能不能成立；以及那個遞迴問題——誰來評測審查者——目前 Arize 的答案是 Signal 審 Signal，並以合併率當代理指標。