這篇文章是我在轉型為應用 AI 工程師之前，希望自己能夠擁有的指南。
這個角色與傳統軟體工程大致重疊，但它增加了一些重要的概念，而這些概念是大多數軟體工程師在轉型過程中必須學習的。我建議你將這篇文章視為你需要理解的核心主題大綱，然後在你想深入探討時，跟隨文章中的連結資源進行學習。
讀完這篇文章後，你應該能更清楚地了解什麼是應用 AI 工程、這份工作實際上需要什麼，以及它如何超越傳統的軟體工程。
如果你有興趣與一個非常有才華的工程團隊一起，解決應用 AI 領域中最有趣的問題，我們隨時都在招募。請到我們的網站 varickagents.com 應徵，或推薦候選人，成功推薦可獲得 2 萬美元的推薦獎金。
話雖如此，理解應用 AI 工程的最佳方式，是從你思考如何建構軟體的心態轉變開始。
軟體工程 vs. AI 工程
軟體工程師與 AI 工程師之間最大的差異在於，傳統軟體工程訓練你以確定性（deterministic）的方式思考，而應用 AI 則迫使你以機率性（probabilistic）的方式思考。
在一般的軟體開發中，你撰寫邏輯、讓它運行，當出現問題時，你通常可以追蹤到原因——結構化的輸入會確定性地產生結構化的輸出。
應用 AI 並非如此。你是在圍繞一個非確定性的 API 呼叫來建構系統，這個 API 呼叫的是「智慧」，這意味著相同的輸入每次都可能得到不同的結果。正因如此，這份工作不再只是建構軟體，而是轉變為衡量系統是否真的按照預期的方式運作。
我們衡量的方式就是透過評估（evals），所以我會詳細說明如何建立一個評估套件，以確保你開發的 Agent 不會犯錯。考慮到我們所做工作的非確定性本質，我體認到這是應用 AI 開發者最重要的技能之一。
文章的下一個部分涵蓋了開發 AI Agent 的各個環節（當然，除了模型本身之外），因為你可以呼叫模型的 API，但其他所有東西都需要你自己建構。這被稱為「框架工程」（Harness Engineering）。
最後，我將介紹如何從一個上線的 Agent 發展到多個 Agent——以及為什麼這是一個分散式系統的問題。如果你能讀完這篇文章，你絕對有能力成功轉型為應用 AI 工程師。
評估（Evals）
應用 AI 工程師透過評估（evals）將不確定性轉化為可衡量的信心。在傳統軟體開發中，你信任系統，因為你撰寫了邏輯並測試了程式碼。在應用 AI 中，你無法以同樣的方式信任系統，因為模型在不同運行中可能會有不同的行為。因此，AI 工程師必須圍繞 Agent 建立一個衡量層。
評估（Eval）是一個過程：給 Agent 一個任務，讓它執行，然後對其行為進行評分。目標是證明兩件事：Agent 正確完成了工作，並且 Agent 在其被賦予的邊界內運作。
第一步是評分結果（grade the outcome）。這是評估過程中最簡單的一步。對於我通常處理的發票 Agent 來說，這意味著確保發票被歸檔到正確的位置，或者重複的發票被標記出來。你只是在比較最終結果與應該發生的結果。
第二步是評分軌跡（grade the trajectory）。這是 Agent 達到該結果所經歷的路徑：它呼叫了哪些工具、觸碰了哪些欄位、傳遞了哪些參數，以及沿途嘗試了哪些動作。這點很重要，因為 Agent 可能在達到正確最終答案的同時，過程中卻做了某些危險的事情。它可能正確地分類了發票，但同時也更改了銀行帳戶資訊，或在獲得批准之前就發送了付款。
軌跡本身只是一個日誌：Agent 呼叫過的每個工具及其傳遞參數的有序列表——對其評分，就只是針對該日誌編寫檢查。
有些檢查是確定性的——確保 send_payment 永遠不會出現在批准呼叫之前，檢查只有 Agent 被允許寫入的欄位才會被寫入。其他檢查則是判斷性的——例如升級處理是否恰當、推理過程是否證明了該行動的合理性。這些檢查會交給另一個模型，並附上評分標準。
要遵循的一般原則是：確定性檢查通常能捕捉到安全違規，而評判模型則負責評分品質。
結果是每個測試案例會得到兩個分數：Agent 是否得到了正確答案，以及它在過程中是否行為得當。這兩個分數需要分開報告，因為一個能 95% 正確分類發票，但在 4% 的運行中觸碰了禁止欄位的 Agent，在綜合分數上看起來很棒，但在生產環境中會導致重大的業務問題。
這篇文章是對評估（evals）及所有其他主題的介紹，所以我連結了其他資源來幫助你深入學習。以下是一些幫助我理解如何建立有效評估的資源：
我建議你逐一閱讀，但可以先從 Lenny 和 Hamel 的指南開始，然後再學習評估課程（後者稍微更偏向實作）。
但是，評估仍然需要一個 Agent 來測試，而模型周圍的一切都需要由你來建構。這個圍繞的系統稱為「框架」（Harness）——下一節將介紹如何思考框架工程過程的各個部分，從工具呼叫到上下文視窗最佳化。
框架工程（Harness Engineering）
一個模型本身並不是一個 Agent。模型可以推理、分類、撰寫和決策，但它無法獨自在公司內部運作。它可以說出應該採取什麼行動，但除非你為它建構了周圍的系統——而這個系統就是框架（Harness）——否則它無法安全地採取該行動。
框架是模型周圍的一切，它將一個 API 呼叫轉變為一個可運作的 Agent：它可以使用的工具、它看到的上下文、它記住的狀態、限制它的護欄（guardrails），以及讓它持續工作直到任務完成的循環。
框架的第一部分是工具執行。
模型只能讀取和寫入文字，所以當模型決定要做某事時，它實際上並不會執行。它會發出一個結構化的請求（一個 JSON 字串）來更新記錄、發送電子郵件或搜尋資料庫。
框架接收該請求、驗證它、執行實際操作，並將結果以文字形式發送回模型。
第二部分是上下文管理。每一條指令、工具選單、工具結果和先前的訊息都會佔用模型上下文視窗的空間。框架必須決定模型當前需要看到什麼、哪些內容應該被摘要、哪些應該被移除。沒有這個，Agent 就會迷失在不相關的歷史記錄中。
我之後會撰寫一篇更全面的文章，深入探討框架開發過程的各個部分，但現在，我建議你聽聽 Arize（一個專為 Agent 設計的持續學習平台）一位工程師的演講，其中深入探討了他們在上下文管理方面的思考過程。
要了解更多關於如何在實踐中將有效的上下文管理應用於你的 Agent，請閱讀以下文章：
框架工程的第三部分是狀態與記憶。模型在每次呼叫之間是無狀態的，因此 Agent 需要記住的任何東西都必須存在於模型之外（通常在資料庫、檔案儲存或任務記錄中）。上下文是模型當前正在查看的內容。狀態是 Agent 知道但當前沒有查看的所有資訊。
第四部分是護欄（Guardrails）。由於模型可能以與正確行動相同的信心來請求錯誤的行動，因此框架必須檢查權限、驗證輸入、阻止不安全的行動，並將高風險步驟轉交給人類處理。
最後，所有這些都透過 Agent 循環（agent loop）結合在一起：建構上下文、呼叫模型、檢查其回應、在允許的情況下執行工具、儲存結果、更新上下文，然後重複直到任務完成。
框架工程將是你作為應用 AI 工程師大部分時間在做的事情，所以請花時間好好理解這一節。作為一名應用 AI 工程師，你的全部工作就是建立一個操作環境，讓一個機率性系統能夠在確定性軟體內部完成工作。
但是，生產環境通常不會只有一個 Agent。
隨著工作流程變得越來越大，直覺會告訴我們要拆分工作。但一旦你加入了第二個 Agent，系統設計就改變了。
只有一個 Agent 時，大部分複雜性都集中在一個循環內部。有了多個 Agent，你現在就有了幾個在同一個環境中運作的循環。每個 Agent 都可能讀取另一個 Agent 剛剛更改的狀態、寫入另一個 Agent 依賴的記憶體，或呼叫一個其結果會影響整個工作流程的工具。
在這一點上，困難的部分不再只是提示詞工程、評估或框架設計。它變成了一個分散式系統問題：誰擁有哪個狀態、誰可以寫入記憶體、哪些工具可以安全地重試、以及當兩個合理的 Agent 以錯誤的順序採取行動時會發生什麼。
多 Agent 部署是一個分散式系統問題
當第一個 Agent 運作良好且工作流程變得更大時，新的應用 AI 工程師自然會有將工作拆分為不同角色的直覺：一個 Agent 負責研究，一個負責規劃，一個負責執行，一個負責審查。
但是，第二個 Agent 將設計的單位從 Agent 本身轉變為整個系統。現在有幾個循環在同一個環境中運作——一個 Agent 可能正在更新客戶狀態，而另一個 Agent 卻正根據過時的狀態進行規劃。兩者都做出了合理的決定，但系統讓這些決定以錯誤的順序相互作用。
這是一個分散式系統問題。好消息是，分散式系統工程師在幾十年前就已經解決了這些故障。你的工作是將這些解決方案應用於那些恰好包含 LLM 的循環。以下是適用於 AI 工程的分散式系統解決方案列表：
單一寫入者原則（Single-writer principle）。每個重要的狀態片段都恰好有一個 Agent 可以對其進行寫入——其他 Agent 從中讀取或提交變更請求。在工具層級強制執行此原則：如果執行 Agent 是唯一可以寫入 CRM 的 Agent，那麼研究 Agent 無論其推理能力多差，都無法破壞 CRM。
冪等性金鑰（Idempotency keys）。當某些工具呼叫失敗或超時時，Agent 會重試，但當工具改變了現實世界中的某些東西時，重試可能很危險。你不希望僅僅因為第一次請求看起來失敗了，就讓 Agent 發送兩次相同的付款。解決方案是為每個會改變資料的工具呼叫附加一個唯一金鑰——意指任何在外部系統中更改資料的動作。如果工具再次看到相同的金鑰，它應該返回原始結果，而不是第二次執行該動作。Stripe 的 API 就是這樣運作的——在處理付款、電子郵件等情況時，這種做法也適用於 Agent 開發。
寫入前提條件（Preconditions on writes）。Agent 經常根據對世界的舊有觀點來行動。從 Agent 制定計劃到它嘗試更新外部系統的這段時間內，某些事情可能已經發生了變化。為了防止基於過時資訊的寫入，會改變資料的工具在進行更改之前應該要求一個條件。例如：「僅在狀態仍為『待處理』時，才將其設置為『已批准』。」如果狀態已經改變，工具應該明確地失敗，而不是默默地覆蓋較新的狀態。
明確的交接（Explicit hand-offs）。將工作作為具有定義架構的訊息進行傳遞，並由一個協調器排序。Agent 應該接收其任務，而不是自己去發現任務。
總結
這篇文章概述了我作為應用 AI 工程師學到的最重要主題：評估（evals）、框架工程（harness engineering）和多 Agent 系統設計（multi-agent system design）。
如果你只帶走一件事，那就是這個——模型提供了智慧，但讓它變得可靠的一切（衡量層、操作環境、協調規則）都是由你設計的。理解了這些，從軟體工程的轉型就變成了對你已有技能的延伸。
如果你對這類工作感興趣，並想與一個非常有才華的工程團隊一起，解決應用 AI 領域中最有趣的問題，我們隨時都在招募。請到我們的網站 varickagents.com 應徵，我們可以讓你盡快入職。另一方面，如果你推薦的候選人成功入職，我們將提供 2 萬美元的推薦獎金。
