為什麼 agent 系統越強大越需要工程流程保護它
最近在讀一篇讓我重新思考整個 agentic AI 開發模式的論文。
一直以來，NLP 社群在做 agent 相關實驗的時候，習慣的流程是：寫一個 prompt loop，跑起來看看效果，調整一下，再跑。整個過程非常即興，非常「臨場發揮」。這種方法做原型超快，但我開始意識到它的問題，特別是當我看到自己實驗室的 agent pipeline 在某些邊緣 case 下出現完全不可預期的行為。
問題的核心在於：我們把 agent loop 當成一次性的實驗，而不是可以被信賴的工程資產。
On-the-fly generation 的根本局限
現在的主流做法，是在 runtime 讓 LLM 動態決定下一步要做什麼。這種彈性很誘人，但它同時意味著你無法事先對 workflow 做靜態測試。你不知道它在特定輸入下會走哪條路徑，也很難在部署前驗證它在高風險情境下是否安全。
從 NLP 研究者的角度來看，這個問題其實不難理解：LLM 的輸出本質上有隨機性和脈絡敏感性。你在 A 環境下測過的 agent，換個 context 就可能出現全然不同的行為。如果每次使用都是全新的即席生成，你根本無法累積對這個系統的信任。
傳統軟體工程有一套成熟的工具來處理不可靠性：單元測試、整合測試、staged deployment、rollback 機制。但大多數 agent 框架完全跳過了這些。
把 workflow 當成工程資產這件事
我覺得真正重要的洞察是：如果你把一個 agent workflow 設計成可重用的資產，它的測試成本可以被攤提。
你花時間對一個「搜尋 + 摘要 + 輸出報告」的 workflow 做 adversarial evaluation，找出它會在什麼情況下失敗，調整直到它在各種邊緣 case 都穩定，然後部署。下次你需要類似功能，不是重新寫一個即興 loop，而是調用這個已經被驗證過的 workflow。
這個邏輯跟軟體工程的函式庫概念非常相似。你不會每次需要排序的時候自己實作一個 quicksort，你用已經被測試過的標準庫。但在 agent 開發裡，我們幾乎每次都在重寫 quicksort，而且常常沒有測試它。
Adversarial evaluation 的重要性被嚴重低估
在 NLP benchmark 的世界，我們很習慣看「平均表現」。但 agent 在高風險場景下的失敗，往往發生在尾部分佈。一個在 95% 情況下表現良好的 agent，如果在那 5% 的邊緣情況下出現嚴重錯誤，它能用在醫療診斷輔助嗎？能用在法律文件處理嗎？
Adversarial evaluation 的意義就在這裡：主動尋找你的 workflow 會失敗的地方，而不是等到上線後被使用者踩到。這件事在 LLM fine-tuning 社群（特別是 RLHF）已經被廣泛討論，但在 agent workflow 設計層面還沒有成為標準流程。
Staged deployment 也需要被引入 agent 開發
傳統軟體有金絲雀發布（canary release），先把新版本暴露給小部分用戶，監控異常後再全量推送。Agent workflow 也應該這樣。
問題是，很多人把 agent 視為「AI 能力的展現」，而不是「需要維護的系統」。這個認知差距導致他們對 staged deployment 的需求視而不見。但一旦你的 agent 開始做真實世界的操作（發送郵件、修改文件、執行代碼），任何一次非預期行為都可能造成真實損害。
彈性與穩健性不是零和關係
有人可能會問：如果把 workflow 固化下來，是不是失去了 LLM 的彈性優勢？
我認為這是錯誤的二元對立。你可以有一個穩健的 workflow 骨架，在固定的步驟節點上保留 LLM 的動態生成能力，但骨架本身是經過驗證的。就像一個有嚴格協議的外科手術流程，不妨礙醫生在手術過程中做出判斷，但它確保每一步都被記錄、被確認、可以在出問題時被回溯。
對 NLP 研究者的意義
從研究方法論的角度，這個框架的提出對我最大的啟發是：我們需要建立 agent workflow 的 benchmark，不是評估「能不能完成任務」，而是評估「
source: internalize
作者：陳思維