紀律放哪:讀完 flue 和 eve,我還是把 gate 留在自己手上

最近我把兩個大廠開源的 agent framework 都 clone 下來,用 codegraph 建索引後深讀了一輪:Astro 團隊的 flue,和 Vercel 的 eve。兩個框架的 API 長得不一樣,但押的是同一注:harness 本身是產品,模型退化成一個可換字串。你在設定裡填哪家模型只是一個參數;框架賣的是模型周圍那一圈——session、工具、skills、sandbox、可恢復的執行。

這跟我自己的判斷同構,所以讀起來格外認真。但讀完之後,我的結論反而是:有幾樣可以偷,核心那樣不能外包。

同一注,兩種押法

flue 走 programmatic:一個宣告式的 agent 定義,把模型、工具、skills、sandbox 全列成物件屬性。幾個設計我認為值得抄——skill 檔在編譯期就被解析成型別可檢查的依賴,而不是執行期才去檔案系統撈,少一類「上線才爆」的失敗;執行環境收成一個可替換的 sandbox 工廠,開發用本機、部署換隔離容器,agent 定義不動;subagent 的執行狀態以持久化的對話紀錄為唯一真相,程序崩潰重啟後能偵測沒做完的邊界、只續跑缺口。

eve 走 filesystem 慣例:一個 agent 就是一個目錄,指示是一個 markdown 檔、工具是一個 TS 檔、排程是一個檔,放對位置就被發現,沒有中央註冊表。生產基建——可恢復執行、沙箱、人工核准、追蹤——全部內建,開箱即用。還有一個小而聰明的招:完整文件直接打包進套件,寫 code 的 agent 從本機就地讀,不用上網查到錯的版本。

真正的分歧:紀律放哪

比較這兩個框架跟我自己的做法,真正的分水嶺不是 API 風格,是紀律放在誰手上。

flue 和 eve 走同一條路:把基建和紀律塞進框架 runtime。可恢復、沙箱、核准流程是框架的一等能力,你 import 就有——紀律隱含在 runtime 的行為裡。方便,但框架換掉,紀律就跟著沒了;而且紀律的形狀由框架定義,不由你。

我的交付 pipeline 走另一條:紀律外掛成顯式的狀態機。工作流狀態放在磁碟上的 ticket 檔,一支 CLI 當被強制的狀態機,非法的階段轉移直接被拒絕——規則寫在 code 裡,不在 prompt 裡,模型沒辦法說服自己繞過。它不綁任何 agent runtime,跨 session、跨機器都能接續。代價是基建要自己扛;換來的是紀律自有、不鎖框架。

我的判準

這不是「框架不好」的結論。判準是分層的:可靠性零件可以借別人的厚框架——可恢復執行、沙箱、追蹤,這些自建吃力不討好;但領域知識和 gate 規則必須留在自己的版控裡。前者是水電,換供應商照常過日子;後者是你對「什麼算做完、什麼不准過」的定義——把它交給框架,模型變強、框架改版的時候,你是受傷的那個,不是受惠的那個。

把限制寫進自己的 code、做客觀可驗證的 gate,這件事沒有框架能替你做。框架能給你的是更好的地基,不是你的紀律。