小編精選 - 技術文章翻譯 · 07月02日

從 Harness Engineering 到 Evals：AI Engineer 正在流行什麼

我這週人在舊金山參加 AI Engineer conference。這場活動集結了你預期中所有大型品牌贊助商、舞台上還有一眾在網路上很有名的專案維護者，議程也相當龐大，幾乎人人都能找到感興趣的內容。但也很容易淹沒在噪音裡。我花時間想釐清：到底哪些主題是真的重要。

面對數十條主題軌、成千上萬的開發者，整個生態系看起來極度分散。但如果你觀察工程師實際部署到生產環境的東西，這些混亂就會收斂成一個清晰的模式。這個產業正在超越單純的聊天介面，把大型語言模型當成更大、且高度結構化軟體架構中的中央處理單元——本質上就是一個 LLM 作業系統。

我把自己看到的一切都整理了一遍，也深入研究了技術場次，最後歸納出這六個主題。這不代表我認同這些方向，而且我也沒有把炒作和現實完全分開。你可以把下面這些簡短摘要當成跳板，如果其中任何一個概念引起你的好奇，再深入挖掘即可。

1. 轉向倉儲庫規模的「軟體工廠」

過去幾年，開發中的 AI 基本上就是自動補字。你寫一行程式碼，助理接著建議下一些 token，然後你繼續往下做。

這種單檔式做法很快就會過時。重點已經轉向倉儲庫規模、多人協作的多代理系統，也就是大家現在所說的 軟體工廠（Software Factories）。

開發者不再只是和 AI 助理一起寫程式碼，而是在管理一整群遍布整個程式碼庫運作的代理。舉例來說，Uber 分享了他們內部程式碼審查引擎 uReview 的細節。它會使用代理自動審查 pull request、啟動本地化測試套件、找出邊界案例，甚至在人類還沒看之前就把修正提交回分支。

為了讓這件事可靠，工程師把編譯器和 lint 工具直接接進代理的回饋迴圈。如果生成的程式碼無法編譯，原始錯誤輸出就會立刻回饋到系統提示中。模型讀取自己的錯誤、修正 bug，然後自動重新執行檢查。

2. 用「Harness Engineering」加固系統

現在會場上有個很常見的共識：「每個人都在做 agent harness，只是沒人這麼叫它。」

LLM 本質上是機率式且非決定性的；但軟體基礎設施需要可預測的輸入與輸出。為了解決這個問題，團隊正在把一個核心系統工程學科正式化：Harness Engineering。

所謂的「harness」，就是包在模型外面的嚴格軟體封裝，用來強制約束、管理狀態，並防止無限執行迴圈。

<center>
+--------------------------------------------------------+ 
| 代理 Harness | 
+--------------------------------------------------------+ 
| 1. 持久化執行（狀態保留與重試） | 
+--------------------------------------------------------+ 
| 2. 結構化輸出（Schema 約束 / Pydantic） | 
+--------------------------------------------------------+ 
| 3. 動態防護欄（輸入/輸出清理） | 
+--------------------------------------------------------+ 
</center>

開發者不再讓代理在沒有監控的情況下自行執行，而是使用 Temporal 或 Inngest 之類的工具鏈來實作 持久化執行（durable execution）。如果代理正在執行一個複雜、歷時數小時的工作流程，卻遇到網路逾時，harness 會保留它的記憶與狀態。流程可以從失敗的地方精準接續，不必重複昂貴的 API 呼叫。再搭配 Pydantic 或 Instructor 這類函式庫來強制嚴格符合 JSON schema，harness 就能讓不確定的模型表現得像穩定的基礎設施。

3. 電腦使用 vs. 自訂 API

幾十年來，整合的意思就是撰寫自訂 API 連接器，或是抓取 endpoints。這一年的一大主題是 電腦使用（Computer Use）——打造像人類操作員一樣操作軟體的代理：看螢幕、移動滑鼠、輸入指令。

在更好的視覺語言模型（VLM）支援下，這些系統不需要結構化的後端 API。它們會持續擷取圖形使用者介面（GUI）的截圖，解析視覺版面以定位欄位與按鈕，並執行精準的像素座標操作。

這也迫使本地端開發環境發生變化。工程師正在建立隔離的沙箱終端機，以及開源桌面助理（像 OpenClaw），讓背景代理擁有自己的虛擬環境。這樣一來，代理就能啟動本地伺服器、在隔離環境中除錯檔案，而不會接管工程師正在使用的螢幕與鍵盤。

4. Context Engineering 與「Tokenmaxxing」

Context window 已經擴展到百萬 token，但把整個程式碼庫直接丟進提示詞，仍然是昂貴、低延遲效率差的反模式。

現在真正的瓶頸是首次 token 產生時間與 API 成本。因此，開發者正大量聚焦在 Context Engineering——把 context window 當成高度最佳化、動態的記憶體快取，而不是靜態文字傾倒區。

最佳化策略通常遵循三層方法：

前綴快取（Prefix Caching）：像 vLLM 這類推論引擎，會快取靜態系統指令或文件標頭的 Key-Value（KV）狀態。後續請求可以重用這個快取，大幅降低延遲與成本。
Context 壓縮（Context Compression）：在中介層加入語意壓縮演算法，在把資料送到供應商之前，先刪除無關 token，並摘要雜亂的聊天紀錄。
Graph RAG 與混合檢索（Hybrid Retrieval）：系統不再不分青紅皂白地抓取原始文字區塊，而是使用結構化知識圖譜，只把高訊號資料送進當前的 context window。

閱讀更多請見 link.dev.to/aie39。

5. 超越「Vibe-based」評估

如果有一件事的操作層面變化非常明顯，那就是 vibe-based 工程已經死了。看幾個輸出、覺得差不多可以、然後就推進生產環境，這已經不是可接受的做法。

Evals 社群的核心關注點，是自動化的多步驟模擬基準測試。現在要評估一個代理，必須先啟動隔離的虛擬環境——一個帶有模擬資料庫與網路存取的臨時沙箱——再讓代理嘗試完成複雜任務。評估框架不會評分回答風格，而是檢查任務是否成功完成、記錄花了多少步，並驗證沒有破壞任何安全協定。

工程師也正在遠離「Persona Trap」——也就是給模型一個像「你是一位資深 Staff Engineer」這樣的提示詞。會議中分享的研究顯示，這種做法評估的是風格化的氛圍，而不是嚴謹的技術能力，還常常引入隱性的偏誤，反而降低表現。現在的標準是嚴格、以任務為導向的測試。

6. 用安全的微型沙箱保障執行期安全

讓代理有權限寫程式、修改檔案與執行終端機指令，會帶來嚴重的安全風險。

平台工程師正透過聚焦底層執行層來處理這個問題。業界標準已經逐漸以 微型沙箱（Micro-Sandboxes） 為核心。代理產生的程式碼會在輕量、短暫存在的微型 VM 中執行（例如 E2B 或 Docker 提供的環境），這些 VM 能在毫秒內啟動，完成特定運算後會立即銷毀，以避免容器逃逸或持久性檔案系統竄改。

此外，隱藏憑證也成為一大重點。當代理需要存取企業資料庫或第三方工具時，工程師會使用像 AAuth protocol 這類新的委派層。這讓代理獲得有任務範圍限制的工具呼叫權限，但永遠看不到或接觸不到原始 API 金鑰，從而中和 prompt injection 外洩風險。