如何判斷 AI 代理何時能獨立運作——Coinbase 的 Evan Kormos

Evan Kormos 是 Coinbase 的 player-coach 工程師，在企業金融服務領域有 15 年資歷。他的主張是：要放心讓 AI 代理在無人監督下運作，做法是讓工作流程「外層確定、內層調適」，再透過可量測的評估——而不是憑直覺——逐步換取自主權。整場演講大部分時間放在政策驅動工作流程的結構上——外層流程用有向無環圖（directed acyclic graph, DAG），每個節點內部的重試迴圈則用有向迴圈圖（directed cyclic graph, DCG）——以及如何判斷哪些節點該交給代理驅動。標題提出的問題「何時可以讓代理不必人工介入」，答案落在最後幾分鐘的三階段推進（先監督、再抽樣、後例外處理），篇幅很短。

Kormos 從企業金融服務工程師的視角切入這個問題：政策是「最初的系統提示」，實際執行的系統演化速度比規範它的政策還快，而代理則橫跨了大家熟悉的人員、流程、技術三層模型。讀者讀完應該帶走三樣東西：一套可用來拆解受監管工作流程的心智模型、一份判斷某節點能否自動化的檢查清單，以及一個務實的認知——迴圈可不可信，取決於它的檢查步驟。

迴圈的可信度，取決於它的檢查

Kormos 的核心技術主張是：代理的重試迴圈繼承的是評估步驟的可靠度，而不是模型的可靠度。在工作流程的每個節點裡，代理先做事，再由檢查判斷成果是否「夠好」、能否往下傳；如果不夠好，回饋就會驅動下一輪迭代。這個內層結構是有向迴圈圖（DCG），也就是一個迴圈；相對地，外層的有向無環圖（DAG）只往前走，不會繞回來。

他說，難的部分在於定義「好」長什麼樣子，並且可靠地評估它。少了這一步，「多跑幾輪不一定代表結果更好」。他把後果講得很白：「迴圈的可信度，真的就只等於檢查的可信度。」

他拿傳統軟體的信心機制，對比代理系統可用的機制：

| 面向 | 傳統軟體 | 代理系統 |
|---|---|---|
| 輸出的確定性 | 相同輸入、相同輸出 | 機率性；同一個請求可能得到不同答案 |
| 可接受的答案 | 只有一個正確結果 | 可能有多個答案都可接受 |
| 驗證方式 | 單元測試、逐字比對輸出 | 具代表性的資料集、反覆執行評估、統計分析 |
| 執行期證據 | 日誌 | 追蹤紀錄（trace，記錄實際發生了什麼的執行期日誌） |

他的處方是建立一套互補的信心機制：具代表性的資料集、明確定義的「好」、以重複序列方式執行的評估，以及追蹤紀錄——讓品質有「關於代理品質的研究與統計」撐腰，而不是靠「對某個模型的感覺」。

把政策與實際執行的系統分開

Kormos 開場先把企業常混為一談的兩件事拆開：政策，以及依政策執行的系統。政策是「最初的機構意圖，也就是最初的系統提示」——工作該怎麼做的規則，尤其是風險與合規相關的部分，最好用 *must*、*may*、*should* 這些字眼寫下來。實際執行的系統則是另一回事，而且持續變動，隨著產品需求快速演化；即便它一直在變，仍應大致受政策約束。

他也把建置狀態與執行狀態分開，視為「兩個不同的時間點」：政策在某個時間點被定義或修改，系統則是持續執行。他提到兩者之間有一個「編譯事件」把它們串起來，但明白表示先跳過不談。

在系統內部，他採用企業標準的人員、流程、技術三層模型，並把代理定位為「橫跨這三層的營運模型」——代理與人協作、自己執行流程中的部分環節，既使用技術，本身也是技術構成的。演講接著聚焦到代理與流程交會之處：代理拿到什麼工作、設下什麼界線，以及如何建立對其產出的信任。

把工作流程建成 DAG，再把代理變便宜的環節並行化

外層工作流程應該畫成有向無環圖——步驟與相依關係一路往前，不會繞回。Kormos 提到 Apache Airflow 這套開源軟體，能用 Python 程式碼把工作流程及其相依關係表示成 DAG，並舉了三個可用 DAG 編碼的政策驅動流程：商業放款、在某個特定地區把代幣上架交易所，以及受監管的軟體交付流程。

現在值得重新檢視這張流程圖，是因為代理改變了並行的經濟效益。以往「成本太高、或協調起來太複雜」的工作，現在可以拆成彼此獨立的審查並行執行，再把結果彙整起來——該做的檢查仍然照做。他以放款流程為例：KYC 與財務審查並行進行，再依序接到信用備忘錄、風險審查、檔案作業與核決。

flowchart TD
    A["政策邊界（must / may / should）"] --> B["外層 DAG：設有閘門、只進不退的流程"]
    B --> C["節點：工作＋檢查迴圈（DCG）"]
    C --> D{"檢查：夠好嗎？"}
    D -->|否| E["回饋、再迭代"]
    E --> C
    D -->|是| F["傳給下一個節點"]
    F --> G["例外流程：取消、未通過安全審查"]
    B --> H["營運可視性：指標、瓶頸"]

他特別強調，營運可視性比流程編排工具本身更重要：當代理把各步驟加速、並行化之後，瓶頸會跟著倍增，因此整體流程的指標與視覺化會變得「遠比工作流程工具的編寫與建置更重要」。例外流程——例如出貨被取消、程式碼未達安全標準——必須被監控，但不必試圖為每一種邊界情況預先設計。

加入代理會改變流量，也會製造新瓶頸

演講中反覆出現的一個觀察是：把代理放進流程的某一段，壓力就會轉移到其他段。以軟體交付為例，如果程式碼審查變快了，設計與安全掃描也必須跟著加快，否則它們就會成為新的瓶頸。Kormos 說這個模式在軟體交付已經上演過，之後代理進入其他流程時也會重演。

言下之意是：工作流程是一個需要平衡的系統，而不是一組可以逐一最佳化的獨立步驟。這也是他為什麼一再回到端到端指標與視覺化，而不是隻調校單一節點。

高品質的輸入能降低算力成本，但品質的好壞是在檢查這一關決定的

Kormos 先承認輸入端的重要性，再把它放到一邊。他相信「更高品質的輸入能以更低的算力成本換得更好的輸出」，也提到可信脈絡（trusted context）或脈絡模型這類概念——但他說那不是這場演講的重點。他倒是給了一個具體做法：把 DAG 的狀態注入代理，讓它知道自己在大局中的位置，包括長期目標。他提醒，這麼做只會更凸顯最佳化迴圈成本與效率的必要性。

他也點出輸入／輸出的變異性是 AI 工程的核心挑戰之一，並主張用 AI 開發正是整體提升產品品質的機會——他正面引用了圍繞「耐久軟體」（durable software）的討論。

逐節點判斷該由代理還是人來驅動

Kormos 不問「這裡到底有沒有用到 AI」，而是把問題改成逐節點思考：「這個節點交給代理驅動，會比交給人驅動有價值多少？」他給了一份判斷節點能否自動化的簡易篩選條件——產出能否輕易對照政策檢查、能否在有界迴圈中執行、能否留下追蹤紀錄、能否退回給人接手？若答案都是肯定的，這個節點就是不錯的自動化候選。

他把這套篩選套用到放款 DAG 上，得到一個明確的分界：最終核決應維持由人驅動，因為它「本質上就是對政策的那道檢查」，他預期這個節點會比較難「爬坡」（hill climb）。DAG 其餘部分則以代理輔助為目標——重點不在於決定 AI 參不參與，而在於預期它最終會在哪裡接手。

自主權分三階段換取，以政策門檻為閘

標題那個問題的答案，是一段分階段的推進，並以對照政策門檻所量測出的信心值作為閘門：

| 階段 | 人的角色 | 正在建立什麼 |
|---|---|---|
| 第一天：監督 | 人工驗證代理產出 | 調整資料集；領域專家定義「好」，並開始驗證 |
| 抽樣 | 只抽查一部分產出，而非全部 | 透過追蹤紀錄做系統性評估，確認人沒看到的部分仍達標 |
| 跨過門檻後 | 處理例外，仍持續參與 | 持續調整資料集與品質保證 |

從一個階段推進到下一階段的觸發條件，是「量測出的信心值達到政策門檻」——規範流程的那套政策，同時也規範代理需要多少監督。人始終沒有完全退場；到了最後階段，人處理更多流程中的例外，同時仍是調整資料集的參與者。

四個重點：外層確定、內層調適、全程評估

Kormos 用一組精簡的原則收尾：

• 外層保持確定，內層保持調適——DAG 與 DCG 都是基礎圖論，真正的工作是把代理帶進人們原本就在跑的流程裡。
• 品質來自評估——一套以統計為後盾的互補信心機制，而不是對模型的感覺。
• 品質是團隊運動——AI 工程師負責的是一條管線：從四面八方接收產品訊號，交付建構良好的應用，背後則有 MLOps 支撐。
• 代理會加速整個營運模型——把軟體交付所見的效率與規模，當成其他業務領域的目標，縮小採用落差。

他請聽眾參考最後一頁投影片上的資料，以瞭解演講涵蓋的內容。

這場演講裡沒有解開的張力，正是 Kormos 點出但未解決的那一個：最終核決節點——對照政策的那道檢查——最難自動化，也是他預期會留給人的節點。這意味著，決定自主權的信心門檻，本身是由人依據人訂的政策來判斷的——統計機制量測的是代理，但「夠好」的定義終究是一項治理選擇。採用這套模型的團隊該留意兩件事：以追蹤紀錄為基礎的抽樣，是否真能抓到人已經看不到的失誤；以及他所描述的流量轉移，是否會讓瓶頸出現的速度快過並行容量紓解的速度。