How to build a self-improvement loop for your Skills
Zach Lloyd 把「loop」討論拉回很工程化的問題：如果 Skills 是 agent 的可重用工作單位，就不要只靠更多 prompt 修正一次性失誤，而要建立會收集失敗、改寫技能、重新驗證的改善循環。
這篇的重點不是「loop 很潮」，而是 Skills 該怎麼自己變好
這則 X post 本身只貼出一個 X Article 連結；可驗證 metadata 顯示文章標題為 How to build a self-improvement loop for your Skills，作者是 Zach Lloyd。LinkedIn 同步貼文則把它描述成一個讓 agents 基於 Skills 自我改善的實用框架，而且是個簡單 loop。
因此這頁採保守整理：不假裝拿到了完整 X Article 內文，而是依已確認的標題、預覽文字與作者公開貼文，拆成一個可執行的工程框架。核心判斷是：Skills 不只是 prompt 檔案，它們應該像程式碼一樣有 regression set、失敗案例、review 與版本演進。
把技能當成 agent 的工作單位
每個 Skill 都應該清楚說明何時使用、輸入是什麼、要產出什麼，以及遇到模糊情況時怎麼判斷。
把改善寫成循環，而不是一次性修補
任務跑完後，不只看結果成功或失敗，還要把失敗原因回寫到 Skill 的流程、範例與限制中。
用驗證器判斷是否真的進步
沒有測試集或 reviewer gate，Skill 的修改很容易只是讓這次任務看起來變好，卻把其他情境弄壞。
一個可用的 self-improvement loop 至少有五步
如果把 Zach Lloyd 的題目落成工程流程，loop 不該從「再叫 agent 試一次」開始，而是從固定任務樣本開始。你需要知道 agent 在哪些任務上表現不穩，才能判斷 Skill 是否真的改善了可重複能力。
收集代表性任務
挑一批會觸發同一個 Skill 的真實任務，包含成功、邊界、常見失敗與高風險案例。這是 Skill 的 regression set。
讓 agent 用當前 Skill 執行
記錄輸入、工具使用、決策、輸出與人工修正。不要只保留最後答案，因為失敗通常藏在中間步驟。
用驗證器或 reviewer 分級
判斷結果是正確、可接受、需要人工修補，還是完全走錯方向。評分規則要比「看起來不錯」更具體。
改 Skill，而不是只改下一個 prompt
把失敗原因轉成 Skill 裡的流程、範例、反例、禁區或檢查表。這一步才是自我改善的累積點。
重新跑同一批任務
確認新 Skill 修掉原問題，同時沒有破壞原本成功的情境。若只是把 bug 從 A 移到 B，loop 還沒完成。
Skills 是比聊天紀錄更好的改善載體
很多 agent workflow 的弱點，是把成功經驗留在一次性的對話紀錄裡。下一次任務開始時，agent 不一定知道上次踩過哪些坑，也不一定能重用上次修正後的做法。Skill 則提供一個更穩定的承載方式：它可以被版本化、審查、測試，並且在多個任務中重複套用。
只靠 prompt 修補
- 經驗留在單次 session，難以複用
- 修正通常針對眼前任務，缺少回歸檢查
- 團隊無法明確知道 agent 能力何時變好了
用 Skills 累積能力
- 把任務流程、判斷準則與反例寫成穩定資產
- 每次修改都能回跑樣本集，衡量改善幅度
- 讓 agent 的工作方式可被 review、討論與治理
落地時，要先定義哪些東西能被 loop 自動改
Self-improvement loop 最容易失控的地方，是把「改善自己」誤解成 agent 可以自由改所有規則。比較穩健的做法，是把可修改內容限制在 Skill 文件、範例、測試資料與局部 adapter，並保留人類 review 或 CI gate。
本頁依可取得來源保守重寫
本輪可確認的來源包含：X post 的 author、日期與文章連結；X server-rendered payload 中的文章標題、預覽文字與 cover image；以及 Zach Lloyd 在 LinkedIn 上對同一篇文章的簡短說明。X Article 完整正文沒有透過可公開抓取的 payload 顯示，因此本文不宣稱逐段摘要原文。
DMBot 讀者版重點
- 01Agent loop 不只是重跑；它要把執行結果轉成下一版 Skill 的改進。
- 02Skills 應該有樣本集、驗證器、失敗案例與版本管理，像程式碼一樣被維護。
- 03Self-improvement 的邊界要明確：agent 可以建議或產生 Skill patch，但評分規則與高風險權限不能隨便被它自己改掉。