Designing loops with Fable 5：把 Agent 變成可驗證的工作循環
Lance Martin 的重點不是「Fable 5 比上一代更會聊天」，而是它更適合被放進可重跑的 agent loop：先規劃，再執行，接著用 verifier 檢查，最後把結果與教訓寫回記憶。能力升級只有在 loop 設計跟上時，才會變成穩定產出。
這篇文章真正要你改的，不是模型選擇，而是工作設計
Fable 5 的發表容易被理解成「更強模型上市」。但 Lance Martin 這篇文章把焦點移到另一層：當模型更能處理長任務、更能保留上下文、更能自己檢查時，工程師要設計的不再只是 prompt，而是一條能反覆運轉的 loop。
這個 loop 的核心不是讓 AI 一次做更多，而是讓它每一輪都知道自己在追什麼目標、採取了哪些行動、通過或沒通過哪些檢查、下一輪該避免什麼。換句話說，模型能力是燃料，loop 結構才是把燃料轉成可交付成果的機器。
從請模型回答，變成委派一段工作
Fable 5 類模型的價值在於承接更長的 task arc。使用者不只是問答案，而是把一段有目標、有工具、有檢查的工作交出去。
驗證器比 prompt 技巧更關鍵
沒有 verifier，loop 只會把不確定性放大。檢查可以是 unit tests、lint、資料一致性規則、rubric，或另一個子 agent。
記憶不是聊天紀錄，是下輪決策素材
好的 loop 會把成功策略、失敗原因、使用者偏好與環境限制整理成可重用狀態，而不是把全部上下文塞回下一個 prompt。
一個可用的 Fable 5 loop，至少要有五個部件
文章的精神可以整理成一個很工程化的骨架。這個骨架不依賴特定框架，但每一層都要能被觀察、替換與回放。
把任務變成可判斷的終點
例如「修好這個 bug 並讓測試通過」比「幫我看一下」更適合 loop。目標越能被機器或人檢查，loop 越容易收斂。
先拆路徑，再動手
模型要先把工作拆成可執行步驟，並決定哪些步驟需要工具、哪些步驟需要子 agent、哪些地方需要人工確認。
每一步都留下狀態
跑命令、查資料、改檔案、產生候選答案都算 action。重點是 action 之後要能知道發生了什麼，而不是只保存最後輸出。
用外部訊號壓住幻覺
測試、編譯、資料查核、schema validation、benchmark、review rubric 都可以是 verifier。強模型加上弱驗證，仍然很容易產生漂亮但不可靠的結果。
把教訓寫回下一輪
loop 最後要更新記憶：什麼假設錯了、哪個工具可靠、哪段上下文下次必帶、哪個檢查規則要調整。沒有這一步，loop 每次都像第一次上工。
Fable 5 這類模型把天花板往上推，但真正讓它進 production 的，是你能不能替它設計可靠的邊界與回饋。
本頁依 X Article 公開摘要、搜尋索引片段與相關二手整理改寫，不逐字重刊原文。要不要做成 loop，可以先問四個問題
不是每個任務都值得 agent loop。Fable 5 讓更多工作有機會被委派，但 loop 本身也有維護成本。真正該做成 loop 的，是那些會重複出現、驗證方式明確、人工處理昂貴，而且錯誤可以被回饋吸收的工作。
對工程師的實用解讀
如果你正在做 coding agent、研究助理、資料分析 copilot、內容流水線或內部營運自動化，這篇文章的實用訊息是：先別急著把所有 prompt 換成 Fable 5，而是盤點哪些工作已經有明確驗證器，哪些工作有足夠重複性，哪些工作需要長時間狀態。
最好的起點通常很小：挑一個可測的 recurring task，先做一條短 loop，讓它能跑、能檢查、能記錄錯誤，再慢慢加入子 agent 或更長記憶。這比一開始就設計龐大的全自動 agent 更容易成功，也更容易知道模型到底在哪裡創造價值。
TL;DR
- 01Fable 5 的價值不只是更強，而是更適合放進長任務 agent loop。
- 02Loop engineering 的核心是 goal、plan、act、verify、learn，不是把 prompt 寫得更長。
- 03Verifier 是把模型能力變成可靠產出的關鍵；沒有外部檢查，loop 很容易放大錯誤。
- 04記憶要服務下一輪決策，而不是單純保存聊天紀錄。
- 05先從小而可驗證的 recurring workflow 開始，讓 loop 真的產生複利。