AI 工程師現在到底在做什麼？——專訪 Arize AI 的 Aparna Dhinakaran

Arize AI 共同創辦人 Aparna Dhinakaran 認為，AI 工程師的工作正從「寫功能、審 diff」轉向「打造持續運轉的代理迴圈（agent loop）來做這些事」，並且要讓遙測資料（telemetry）變成代理讀得懂、而不是隻有人看得懂的形式。這場在 AI Engineer New York 的演講，大部分時間花在 Arize 的 Signal 代理的具體架構（觸發機制、沙箱、記憶、耐久性、模型與執行框架（harness）的無關性），以及如何建立並信任評測（eval）；「AI 工程師到底在做什麼」這個框架，只是包住這些工程細節的外殼。

Dhinakaran 把這個轉變建立在 Andrej Karpathy 在演講前一個週末發布的一張漏斗圖上，並用它主張：前沿（frontier）——幾千名使用者、每人跑著數千個代理——就是這個角色將要前往的地方。她對其他人的具體處方有三：全部追蹤（包括打造你的代理的那些寫程式代理）、在上線前寫出與人類判斷一致的評測、並把產生的遙測資料接回代理，讓系統自我改善。讀者讀完應該能帶走一個可用的心智模型：持續運轉的代理的生命週期長什麼樣，以及 Arize 把產品賭注押在哪裡。

AI 工程師現在打造的是迴圈，不是功能

Dhinakaran 的核心主張是：建置—評測—上線—監控—改善這個迴圈的每一步都已交給代理，因此工程師的工作變成建構讓這些步驟運轉的迴圈。她把這個轉變講成一連串的替換：不再是寫 AI 功能，而是打造會寫這個功能的迴圈；不再是讀 diff、做程式碼審查，而是設定代理來審查程式碼，並為非確定性任務寫評測；不再只是埋指標和遙測，而是讓代理去消費這些遙測、找出模式。

她把這件事定位為數十年來抽象層不斷上移的最新一步——從高階語言、複製貼上程式碼、本地代理，到雲端代理——而過去幾年這個程序被大幅壓縮。她描述的近期預期是：團隊會在內部執行「一組代理，或是一整座代理工廠」。

「身為 AI 工程師，你的工作不再是單純寫功能、寫一個 AI 功能，而是你怎麼打造出寫那個功能的迴圈。」

她賦予這件事的意義，在於縮小一道落差。她說「今天實驗室裡發生的事，和許多企業裡發生的事之間有相當大的落差」，並把部分原因歸於企業資料比實驗室裡受控、可測試的資料凌亂得多。在她的框架裡，AI 工程師就是負責彌平這道落差的角色。

Karpathy 的漏斗把前沿放在幾千名使用者

Dhinakaran 的論證建立在一張 Karpathy 在演講前一個週末推文發布的漏斗圖上（依 2026-10-25 的發布日期推算，大約是 2026-10-18）。根據她的轉述，各層級如下：

她把這張漏斗讀成一份路線圖，而不是靜態快照：它拋出的問題是每個人現在站在哪一層，以及所有人要如何「在未來幾年內」爬到最上層。她提到 Karpathy「漏掉了一部分漏斗」——也就是公開版本並不完整——但她認為重點在於整體形狀。5,000 名使用者的前沿數字，正是支撐她主張的錨點：執行代理工廠目前仍是極小規模、菁英式的做法。

Signal 的生命週期：觸發、沙箱、掃描、持久化、拆除

演講的主旨是拆解 Arize 如何打造 Signal——一個持續運作的代理，會讀取追蹤資料（trace）、辨識問題，若有 repo 許可權還能開出修正或 PR。Dhinakaran 把它當成任何人打造持續運作代理時的參考架構來講，而設計選擇相當具體。

觸發。 Signal 可以依可設定的頻率喚醒（每三或六小時，拉取最近 X 筆追蹤資料）、依事件觸發（例如使用者在 Slack 上抱怨的訊息），或依指標門檻觸發。她把「什麼會喚醒代理」視為任何代理工廠的第一個設計問題。

執行。 每次喚醒都會建立一個沙箱，內含追蹤脈絡、第三方遙測（APM 日誌與指標）、repo 許可權，以及所需的金鑰。進出沙箱的唯一通道是一個代理（proxy），沙箱內的一切都被追蹤。

記憶。 Signal 找到的問題會存到沙箱外的記憶中，讓下一次執行不必從零開始。她把記憶問題描述成一部分是「隨時間累積的判斷」：代理以前看過這個嗎？它看起來像問題但當時沒被捕捉到嗎？現在累積的資料是否讓它變得關鍵？

拆除與耐久性。 一次執行結束後，沙箱、憑證、repo 許可權都會移除；追蹤資料、輸出，以及任何學到的「技能」會存進 repo 並保留。這個代理被設計成耐久的——如果沙箱或執行框架在執行中途掛掉，存在沙箱外的狀態能讓新的沙箱與執行框架從失敗的那一步接續，而不是重新開始。

flowchart TD
    T["觸發：頻率、Slack 事件或指標"] --> S["建立沙箱，內含追蹤資料、APM 資料、repo 許可權、金鑰"]
    S --> P["單一代理是進出的唯一通道"]
    P --> R["代理掃描追蹤資料並辨識問題"]
    R --> D{"找到問題？"}
    D -->|是| M["把問題存到沙箱外的記憶，必要時開 PR"]
    D -->|否| X["拆除沙箱、憑證、repo 許可權"]
    M --> X
    X --> N["下一次執行從記憶接續，不從零開始"]
    N --> T
    F["執行中途沙箱或執行框架故障"] --> U["狀態已持久化在沙箱外"]
    U --> S

模型與執行框架的無關性是評測與成本控制的槓桿

Signal 從一開始就設計成不繫結執行框架與模型。它最初建在 Claude Code 上，現在也支援 Cursor 和 Codex，目標是支援所有主流執行框架，包括開源方案。在 Claude Code 之內，使用者可以任選 Anthropic 家族的模型。

Dhinakaran 提出兩個理由，兩者都是營運考量而非意識形態。第一，切換執行框架與模型，是每次啟動時評估代理品質的一種方式。第二，它能實現成本控制：她想看更強大的模型是否產出更好的 PR，以及較便宜的模型能否維持同樣的嚴謹度與偵測品質。這是對多數代理營運者都會面對的取捨——輸出品質對比每次執行的成本——相當具體的表述，而且被當成該去測量、而非預設的事情。

評測就是工作本身，而評測器本身也得被評測

Dhinakaran 說寫評測是 AI 工程師該投入大量時間的地方，而她對「好」長什麼樣講得很具體。評測可以簡單到只是在開發流程中跑一組資料集加提示、比對預期輸出以攔截回歸，但它們必須與人類判斷一致。她提到一些工具——另一位講者前一天提到的、用來建立評測的 Claude skill，以及 Arize 自家的 Arize Evaluator skill——但重點在流程本身。

她合作的團隊最常問的問題是「我要怎麼信任評測器？」她的答案是：Arize 會評測自己的評測器——建立黃金資料集、跑評測、對照人類輸出驗證，並在發布新的評測器之前確認評審（judge）與人類判斷一致。同一套評測隨後一魚兩吃：變更上線前做離線測試，上線後對生產遙測做線上評測。

「我們真的會去評測評測器。」

對部署 LLM 評審的團隊來說，這是整場演講中最可轉移的做法：把評審當成一個本身就有準確率問題的模型，並以「與人類判斷的一致程度」作為發布的把關條件。

追蹤打造你的代理的那些寫程式代理

結尾的處方是：「全部追蹤」現在要往堆疊上層再延伸一層。Dhinakaran 說團隊不只要追蹤自己上線的代理，還要追蹤背後打造它們的寫程式代理——Claude Code、Cursor、Codex——這樣才能理解「你們正在打造的那座代理工廠裡發生了什麼事」。這些追蹤資料會餵給線上評測，評測的輸出又成為代理讀取的新資料，用來在追蹤資料中浮現問題。

她把最終形成的系統描述成一個封閉迴圈：收集資料、評測資料、在資料之上執行代理以找出問題與缺口，再用這些發現改善系統。誰來消費遙測的轉變，是讓這一切成立的條件——可觀測性資料不再是人看的儀錶板，而是持續運轉代理的觸發器與輸入。

flowchart TD
    A["收集追蹤資料，包括寫程式代理"] --> B["上線前的離線評測"]
    B --> C["上線到生產環境"]
    C --> D["對生產遙測做線上評測"]
    D --> E["代理讀取評測與追蹤資料以浮現問題"]
    E --> A

未解的張力：信任、成本，以及實驗室到企業的落差

演講中有兩條線索是提出多於解決。第一是對自動化判斷的信任：Signal 決定什麼算問題，評測層決定一個 PR 好不好，所以系統的可靠性建立在評測器上——Arize 說它會對照人類驗證這些評測器，但演講中並未量化，沒有給出一致率或誤差範圍。第二是落差本身。Dhinakaran 把前沿實驗室與企業之間的距離部分歸因於資料凌亂，但沒有提出證據說明那 2,000 萬人的專業層級多快能彌平它。她真正給出的是一個可檢驗的賭注：勝出的模式不是更好的個別功能，而是一個被追蹤、被評測的迴圈，其中代理是遙測資料的主要消費者。這個迴圈在企業資料品質下能否站得住腳——以及要付出多少模型成本——是 Signal 的多模型、多執行框架支援成熟後值得觀察的重點。