當 AI 代理永不喊停：軟體開發的「無限迴圈」時代正在逼近
lucumr.pocoo.org · 2026-06-23
Flask 與 Jinja2 的作者 Armin Ronacher 於 2026 年 6 月 23 日在個人部落格發表了一篇引發廣泛討論的長文，描述一種他稱為「迴圈」（loop）的新型軟體開發模式正在席捲業界：外部協調系統（harness）持續驅動 AI 代理反覆執行、自我修正，直到任務真正完成為止。Ronacher 坦承自己對這個未來感到不安，卻也承認它已無可迴避。
什麼是「兩層迴圈」架構？
傳統的 AI 輔助開發，通常是工程師給出指令、模型產出程式碼、工程師再審查修改。Ronacher 描述的迴圈模式則截然不同，它由一個內層代理迴圈（agent loop）與一個外層 harness 迴圈巢狀組成。內層代理自行呼叫工具、迭代執行；外層 harness 則持續判斷任務是否真的完成，並在需要時重新啟動會話、修改上下文或將工作重新導向。
這個架構意味著系統不再接受代理的第一次「完成」宣告，而是持續施壓直到達到可驗證的目標。Ronacher 舉出 Bun 將程式碼從 Zig 移植到 Rust 的專案作為成功案例，其他適合的場景還包括效能基準測試、安全掃描、以及一次性的概念驗證原型——這些任務的共通點是產出物本就不需要長期人工維護。
迴圈產出的程式碼，品質令人憂心
Ronacher 對迴圈模式最深的疑慮，在於它產出的程式碼品質。他觀察到模型在長時間不間斷執行後，傾向於寫出過度防禦性的程式碼：多餘的抽象層、本地端錯誤處理而非從根本讓無效狀態不可能發生、不必要的重複邏輯。他引用 Andrej Karpathy 的觀察，稱模型「對例外錯誤有著死亡般的恐懼」，選擇以複雜度換取表面上的穩健性。
這種趨勢在實際工具上也有跡可循。Ronacher 批評 Claude Code 在長時間運行後，產出的程式碼品質明顯不如 2025 年秋季的版本。迴圈帶來的自動化便利，似乎正在以可維護性為代價。他擔憂的不只是個別專案的品質，而是整個工程文化走向「生機體」（organism）模型——把軟體系統當作需要持續監控、機器輔助診斷的生命體，而非可被人類完整理解的確定性機器。
curl 的困境：開源維護者被 AI 海嘯淹沒
迴圈模式的副作用，已經在開源社群引發了真實的危機。curl 的維護者 Daniel Stenberg 在 2026 年 6 月 15 日宣布，curl 專案將於 2026 年 7 月 1 日至 8 月 3 日暫停接受漏洞通報，稱之為「幸福之夏」（summer of bliss）。起因是 curl 在過去數個月承受了龐大的漏洞回報壓力，大量低品質、疑似 AI 自動產出的通報讓維護者身心俱疲。版本 8.22.0 的發布也因此延後兩週至 2026 年 9 月 2 日。
Ronacher 以此為例說明：即使個別工程師選擇不採用迴圈，他們仍必須被動應對來自迴圈的衝擊。AI 代理自動發現漏洞並提交報告的能力，讓開源維護者陷入兩難——忽略這些報告有安全風險，但審查它們卻耗盡人力。在這個意義上，迴圈的採用壓力並非來自效率誘因，而是來自防禦性的必要。
人類工程師將扮演什麼角色？
文章最令人深思的部分，是 Ronacher 對人類角色轉變的描述。當迴圈接管了程式碼審查、漏洞修補、甚至系統架構決策，人類工程師的角色正在從「創造者」滑向「傳聲筒」——在機器與機器之間傳遞指令，而對系統的真正理解則交由語言模型代勞。
Ronacher 點出了幾個具體風險：貿易限制可能切斷對特定模型的存取、費用持續上漲、以及人類對程式碼的理解能力不斷萎縮。他沒有給出解答，卻提出了他認為最重要的問題：在機器主導的開發節奏中，如何確保工程師的判斷力與責任感得以保留？這個問題，或許比任何技術細節都更值得整個業界認真思考。
原始來源：The Coming Loop — Armin Ronacher、curl Summer of Bliss — Daniel Stenberg
2.5 百萬參數搞定滑行輸入：FUTO 開源鍵盤模型的小巧野心
swipe.futo.tech · 2026-06-23
非營利組織 FUTO 於 2026 年 6 月在 swipe.futo.tech 發布了 FUTO Swipe，一套專為行動裝置滑行輸入（swipe typing）設計的開源模型與推論函式庫。整套系統的總參數量僅 250 萬，訓練只需一台工作站 GPU，卻能達到約 4% 的 top-4 失敗率。這套技術目前已整合進 FUTO Keyboard（Android 離線鍵盤應用），並以開放授權釋出供社群採用。
三模型協作：從觸控軌跡到文字預測
FUTO Swipe 的架構由三個相互獨立又可組合的模型構成，各司其職：
- Encoder（代號 honorable_sturgeon）：635K 參數，2.65 MB。讀取原始 (x, y) 觸控座標序列，透過一維時序卷積網路（1D temporal CNN）將滑行軌跡映射為每個時間步的字元機率分布。此模型不綁定特定鍵盤排版或語言，具有通用性。
- Decoder（代號 magic_macaw）：304K 參數，1.25 MB。針對特定排版與語言（目前為英語 QWERTY）進行精調，進一步提升預測精度。
- Context LM（代號 hungry_jellyfish）：1.5M 參數，6.25 MB。一個微型語言模型，利用句子上下文對候選詞重新排序，並提供下一個單字預測功能。
推論函式庫以 C++ 撰寫，核心演算法是「字典約束集束搜尋」（dictionary-constrained beam search），在候選詞空間中尋找最可能的輸入結果。整個推論流程完全在裝置本地端執行，不需要任何網路連線。
訓練資料：百萬筆 MIT 授權滑行紀錄
模型的訓練資料來自 FUTO 透過 swipe.futo.org 公開收集的資料集，共計 100 萬筆使用者自願提供的滑行軌跡，全部採用 MIT 授權，於 2025 年 3 月釋出。這個資料集的開放授權是此專案的一大亮點——過去滑行輸入的訓練資料幾乎全由商業公司掌握，FUTO 的做法讓學術界和獨立開發者都能在相同基礎上進行研究與改進。
模型的準確率數據相當亮眼：排除詞彙表外（out-of-vocabulary）的情況後，錯誤率低於 1%；即使納入詞彙表外的情況，top-4 失敗率也只有約 4%，意即正確答案幾乎總會出現在前四個候選詞之中。FUTO 強調，整個訓練過程僅使用單一工作站 GPU，大幅降低了重現實驗的門檻。
授權策略與開放生態
FUTO Swipe 的授權採取了分層設計：推論函式庫（swipe-library）以 GPL v3 授權在 GitLab 開源（建立於 2026 年 5 月 27 日），而模型權重則使用 FUTO Model License，要求使用者在產品介面中向終端使用者顯示明確的歸因聲明。這種「函式庫開源、模型附條件」的授權組合，反映了 FUTO 希望在推廣開放技術的同時，確保其努力能被適當認可的立場。
FUTO 的成立宗旨是對抗科技公司對使用者的過度控制，FUTO Keyboard 本身也是其中一個具體實踐。模型已上架 HuggingFace（futo-org/swipe），技術論文尚在撰寫中，預計後續發布。對於想在自家鍵盤應用或嵌入式系統中實現離線滑行輸入的開發者而言，這套體積小、授權清晰、資料公開的方案，目前是最具吸引力的起點之一。
原始來源：FUTO Swipe — swipe.futo.tech、futo-org/swipe — HuggingFace、swipe-library — GitLab FUTO