FrogNano-4B-2609：Microsoft 將一個 4B 程式設計代理發布到 Hugging Face，卻從未宣布

該儲存庫於 2026 年 9 月 17 日隨著初始提交上線，而檢查點本身則在四分鐘後落地。接著便悄無聲息。Microsoft AI 沒有推文，Microsoft Research 部落格沒有文章，也沒有發布頁面。七週後 microsoft/FrogNano-4B-2609——一個以 Qwen3.5-4B 為基礎打造的四十億參數級程式編寫代理——背後仍然沒有任何公告，而這份沉默是這個模型發布最重要的一項事實。它確實擁有的是：一張聲稱有論文與測試框架的模型卡、一個結果證明是測試框架而非論文的 GitHub 儲存庫，以及一個 createdAt 為 9 月 17 日，卻置於一張寫著「發布日期 22-SEP-2026」的卡片之下。這兩個日期都是臨時湊出來的；兩者都沒有錯；它們彼此不一致。

實際上到底是什麼

以下所有內容現在都可以在中心查證，而本文中的每一個數字都來自 Microsoft 自家的卡，或是來自儲存庫本身的位元組計數。沒有任何內容是由第三方重現的——在任何地方都沒有 Artificial Analysis 的條目、沒有 arena 評分，也沒有對 FrogNano 的獨立評估。

• 權重 — Microsoft 組織底下的一個公開存放庫，無限制存取，在 hub 上標記為 MIT，15 個檔案，沒有下載閘門，也無需簽署任何協議。

• 磁碟上的權重 — 9.32 GB，分佈於兩個 safetensors 分片，包含無最佳化器檔案集的 596 億位元組儲存庫資料，索引中有 738 個張量。

• 架構 — Qwen3_5ForConditionalGeneration，這是承襲自 Qwen3.5-4B 的稠密 32 層混合堆疊，並搭配 24 層視覺塔，而模型卡指出該視覺塔是承襲而來、從未經過後訓練。

• 卡片本身的參數欄位——「500M-5B」。那是一個範圍，不是一個數字，而下載的文件是更精確的資料。

• 授權條款 —— 卡片的前置資訊寫的是 MIT。卡片本身內文寫的卻是 Apache License 2.0，而 GitHub 測試框架確實附有一個 MIT LICENSE 檔案。這兩段敘述指的是同一個發布版本中不同的產物。

• 公告——沒有。既不在 Microsoft Research 部落格上，也不在團隊自家的研究網站上，在 Hugging Face 組織動態中，也僅僅是一則儲存庫列表，別無其他。

最後那一句，才是應該為讀者定下閱讀這篇文章其餘部分時姿態的一句。一個悄悄上傳的檢查點，並不比一個公開宣告的檢查點更次等——它的模型卡往往更長，因為沒有人會為了新聞稿而把它刪短。但它沒有經過公開宣告的發布版本無需付出就能獲得的那一道過濾：其他人的審視。

分數，以及每一分是由誰締造的

微軟報告指出，FrogNano 在 SWE-bench Verified 上達到 61.5%，在 SWE-bench Pro 上達到 37.6%，在 Terminal-Bench 2.0 上達到 31.1%，在 PatchEval-Verified 上達到 47.3%，這些全都是透過 Leaf harness 測得的 Avg@3 解決率。同一張卡也提供了起點：Qwen3.5-4B 在相同 harness 與預算下，於 SWE-bench Verified 上得分 39.4%。五輪強化學習迭代讓它依序達到 49.1%、53.1%、56.7%、59.1% 和 61.5%——比基礎模型高出 22.1 個百分點，而微軟自己的表述將其四捨五入為約 56% 的相對提升。

關於那個階梯，有兩點值得停下來想一想，因為它們是摘要可能出錯的地方，而不是供應商出錯的地方。

第一個是 Iter 5 的差異。卡片的主標題表格說最終迭代為 61.5%；論文自己的效率附錄則把同樣的五個檢查點進程報告為 48.2%、53.4%、58.3%、58.6% 和 61.6%。只有最後一個數字接近，而也只有最後一個數字是大家會引用的。把最終數字當作穩定結果，並把中間的各個層級當作對不同事物的測量，因為在不同的聚合方式下，它們顯然就是如此。

第二點是，FrogNano 並非在每個面向上都一致優於它最初所基於的模型。其公佈的平行工具呼叫率為 1.71%。模型卡坦率指出，後續迭代失去了在單一回合中發出多個工具呼叫的能力，而團隊的整併工作有一部分正是為了恢復這項能力。一個能解決更多問題、卻幾乎不發出並行呼叫的模型，是真正的工程取捨，而非註腳。

測試框架就是產品，而儲存庫就是測試框架

FrogNano 無法自行運作。它會向五個工具發出結構化呼叫——Read、Write、Edit、Glob與Bash——而且必須有某個東西在隔離環境中執行它們，並把輸出交回來。那個東西就是 Leaf，而在這裡，這條線索出現了有點不尋常的狀況。

模型卡的「其他相關資產」列會連結到一份技術報告：aka.ms/frognano-tech-report，以及一個測試框架：github.com/microsoft/FrogNano。這個 aka.ms 連結並非指向 PDF；它會直接重新導向到 arXiv 摘要頁面，而實際報告就位於該處。另一方面，GitHub 儲存庫不含任何訓練程式碼、RL 配方或檢查點。它自己的 README 描述了一個評估框架，該框架會在 Kubernetes 沙箱中，針對 OpenAI 相容端點執行程式編寫代理，並回頭指向 arXiv 論文以說明訓練歷程。因此，模型卡的兩個資產連結分別是指向該論文，以及指向該論文的回覆，而名稱則是共用的。

對任何打算使用這個模型的人來說，這點都很重要，而且有實際上的理由。官方記載的服務配置是 SGLang 搭配 --reasoning-parser qwen3 與 --tool-call-parser qwen3_coder，而測試框架想要的是已能處理工具呼叫與推理的端點。只要解析設定稍微弄錯，模型就會在測試框架預期 JSON 的地方產生文字；從外部解讀起來，這看起來完全像是模型不好，而不是設定不好。這張模型卡明確指出，任何相符的分數都需要相符的檢查點、分詞器、服務配置、任務影像與評估協定——這等於廠商在告訴你，測試框架佔了結果的一半。

另外，也值得向任何正在評估硬體規模的人直說：在該模型卡所評估的上下文下，9.32 GB 的檢查點並不代表這是個 9.32 GB 的推論問題。這些評估是在大約 131K 合計 token 數、150 步預算下執行。記憶體用量取決於上下文，而非權重，而且該模型卡寫道，最低 GPU 配置仍「必須在發布前驗證」——這句話竟出現在一個已經可供下載的模型上。

這段訓練實際上做了什麼，用一段話說明

這篇論文的貢獻不在模型，而在迴圈。TaskPilot 從真實的儲存庫快照產生候選軟體工程任務，讓當前檢查點對這些任務執行 rollout，保留那些處於策略有時能解出的邊緣附近的任務，並捨棄永遠過於簡單或永遠不可能完成的候選任務。被接受的集合用來訓練下一個檢查點。接著，下一個檢查點會校準下一輪的任務生成，因此任務分布會隨著策略移動而移動。總計約 1,500 個經過驗證的環境。沒有蒸餾：該模型卡明載，代理專屬的後訓練並未使用更強模型的解題軌跡、動作、推理軌跡或修補目標。更強的模型負責撰寫任務；它們並不示範答案。

Microsoft 執行了那個迴圈五次迭代，並回報在任何整併之前有 8.7 點的增益，而且因為推理軌跡的成長速度比改善速度更快，所以中途加入了日誌長度懲罰。

這份模型卡異常直白地指出整套方法在何處脆弱。訓練資料以 Python 為主，且主要為英文；模型卡所述支援的自然語言集合只有英文，別無其他，而基礎模型更廣泛的多語言涵蓋範圍則明確不在其宣稱之列。效能對評測框架與測試品質很敏感。產生的修補程式「即使通過可用的測試，仍可能不正確或不安全」。4B 的模型卡以一句每位讀者都應銘記奉行的話結束該段：未經合格的人工審查，以及獨立的迴歸與安全測試，不得使用。那是供應商針對自家產物所作的聲明，而它比上方任何一列計分板內容都更有用。

這讓買家處於什麼境地，以及路由器適合放在哪裡

FrogNano 不是那種你直接呼叫的模型。沒有第一方 API、沒有託管端點，也沒有無伺服器映像。它是一個檢查點；使用它意味著你要嘛在 Kubernetes 託管的沙箱後面架設自己的 SGLang 部署，要嘛把它當作你已在營運的代理堆疊中的元件來評估。這就是目前完整的採用路徑，而沒有任何公告能改變它的樣貌。

路由層在這裡能老實做到的事，比乍聽之下更狹窄。如果你的計畫是在自己的評測框架中，將自行託管的 FrogNano 與託管的程式碼模型互相比較，那麼託管的那一半，正是受益於只要用一組金鑰、而不是第二份合約的那一半：OrcaRouter 在單一 OpenAI 相容端點後提供 200 多個模型，以 0% 加成，意即供應商定價原樣傳遞、未受更動，而且供應商價格若有變動，當天就會在我們這邊生效。對於一場勝負取決於每解決一個問題的成本、而非單一基準測試分數的評比來說，這一點很重要。我們不託管 FrogNano，也沒有時程；權重與推論服務的工作由你負責。

能讓它塵埃落定的三件事

首先，一次獨立的複現。本文章中的每一個數字——61.5、37.6、31.1、47.3——都是由訓練該模型的實驗室所產生的，使用的是同一個實驗室維護的測試框架，並且對照的是同一個實驗室測得的基礎模型數據。這是一幅完整且內部一致的圖像，同時也是一個封閉迴路。有用的測試是，是否有一個沒有利害關係的人，能在同樣的 500 項任務上複現 39.4 到 61.5 的躍升，而且沒有 Microsoft 對該任務集所做的校準工作。

其次，必須有人端到端檢驗這個測試框架的主張。該儲存庫是公開的，這已經勝過許多發佈版本所能做到的，但它是評測裝置。如果這五項工具與沙箱隔離確實是效能機制，那麼第三方執行已公布的配置時，結果應該會落在已公布數字附近。如果沒有，落差才是真正的發現。

第三，也是最容易回答的一點：微軟應該說明這是一項產品，還是一份論文產物。這張卡片的分發章節把權重、卡片和測試框架視為交付物，這讀起來像是論文發表，而不是產品發布。「發布日期 22-SEP-2026」讀起來像是產品發布。一款已宣布的模型，本會在部落格文章的第一句話就解決這個模糊之處，但並沒有任何部落格文章。

在那之前，正確的姿態就是該發布本身所暗示的那一種。FrogNano-4B-2609 是一個真實、可下載、標示 MIT 與 Apache、也許並非如此的檢查點，附有異常詳盡的模型卡、公開的評估框架、真正的方法論構想，以及一個從未被任何沒有 Microsoft 電子郵件地址的人碰過的排行榜。對一間實驗室而言，那是一件完整而有趣的產物。對一個即將在凌晨三點把代理放到某個儲存庫前面的團隊而言，那是一條值得追查的線索，但還不是一個值得做出的決定。