那個你自己也會提交的拉取請求

你會親自開啟的 PR

摘要 (TL;DR)

我們提供了一項「技能」（Skill）和一個測試框架，協助將語言模型從 transformers 移植到 mlx-lm，讓模型在加入 transformers 的那一刻起，幾乎能立即在 mlx-lm 上使用。這項「技能」旨在作為貢獻者和審查者的助手，而非完全的自動化工具。我們將解釋開發它的原因、方法，並探討在智能體（Agent）時代，如何對開源做出有意義的貢獻。

代碼智能體的降臨

2026 年，代碼智能體開始真正發揮作用。過去在編輯器側邊的自動補全功能，已演變成能根據簡短規範直接生成合理方案的系統。生成的代碼通常開箱即用，涵蓋了你的需求，並對未指定的細節做出了合理的假設。這非常棒。正如黃仁勳所說，全世界的程式設計師瞬間從 3000 萬增加到了 10 億。創意靈魂得以釋放。

但這迫使我們重新思考開源。

以 transformers 函式庫為例。它擁有數百名貢獻者，被應用於數千個項目，下載量超過十億次。突然之間，任何擁有智能體的人都可以指示它尋找開放的 Issue、修復它並提交 PR。而這正是正在發生的事情。這些人感到高興，因為他們正在為一個偉大的函式庫做貢獻，但悲哀的現實是，大多數時候，他們並沒有意識到自己其實並非在幫忙。

為什麼呢？智能體生成的 PR 通常會忽略兩個前提。

像 transformers 這樣的代碼庫非常在意代碼質量。在某些項目中，代碼長什麼樣並不重要，但 transformers 不是其中之一。由於被成千上萬的人使用，transformers 主要被構建為一種通過代碼進行「人與人溝通」的方式。模型文件從上到下閱讀，因為我們希望從業者無需跳過複雜的抽象就能理解它們。這種理念滲透在整個函式庫的設計中，也是為什麼我們偏好扁平化層級結構的原因。

智能體缺乏這種背景信息。因為設計決策並非顯性，智能體會遵循「最佳實踐」建議重構以「改進」代碼庫，卻沒意識到它們正在破壞函式庫與用戶之間的隱性契約。它們往往過於冗長、過早泛化、察覺不到變更對其他區域的影響、引入微妙的 Bug，並破壞性能。它們還具有「迎合性」（sycophantic），會接受任何想法並勤奮地執行，包括那些維護者本會用簡短評論直接回絕的想法。

少數維護者仍必須閱讀每個 PR、理解它、決定設計方向是否正確、識別副作用並撰寫反饋。PR 的數量增加了十倍，但維護者的數量卻沒有（也不可能，因為團隊協作無法無限擴展）。

這與 MLX 有什麼關係？

由於龐大的體量，transformers 是首批感受到這種壓力的項目之一，但同樣的動態正在各處發生。舉一個不同領域的例子，App Store 的審核員正被淹沒，因為現在任何人都能構建並提交 App，所以許多人都這麼做了。

同樣的邏輯也適用於 MLX：他們的維護者非常在意代碼，並仔細閱讀每個 PR。我們想看看智能體是否能幫助貢獻者快速提交高質量的模型移植，同時在審查工作中支持維護者。我們不僅渴望產生看起來像是由細心的真人提交的 PR，還提供額外的產出物以增加信號：生成範例、數值對比，以及一個獨立的、非智能體化的測試框架以確保可重複性。

transformers 與 MLX 之間的另一個聯繫是，大多數時候，mlx-lm 模型是從 transformers 的實現移植而來的。由於 transformers 專注於清晰度和可讀性，它已成為模型定義的事實來源（source of truth）。下游貢獻者會等到 transformers 實現就緒後再移植到其他框架。作為副作用，這對智能體來說是一個極佳的環境，因為它自然地限制了範圍：智能體不需要從頭開始創建實現，而是依賴 transformers 代碼作為事實來源。

這種方法支持了我們的目標：當一個模型進入 transformers 時，它應該很快就能在 MLX 上使用。

我們做了什麼

我們構建了一項「技能」（Skill），mlx-lm 貢獻者可以使用它將模型從 transformers 移植到 MLX。給定一個提示詞，例如「將 olmo_hybrid 架構轉換為 MLX」，該技能會設置虛擬環境、從 Hub 發現並下載相關模型、閱讀 transformers 建模代碼、編寫 MLX 實現，並運行一系列測試。如果結果看起來不對，它會進行調試和迭代，直到滿意為止才宣告成功。

我們將其設計為對審查者和貢獻者同樣有用。

對於貢獻者，該技能當然會處理所有基礎工作：在 Hub 上尋找模型變體、對比配置以發現不同變體間的參數差異、下載權重、設置 mlx-lm 和 transformers 的可編輯安裝。但它也處理更困難的建模任務。它關注顯著的架構細節並驗證敏感區域，例如可能導致難以發現的 Bug 的 RoPE 配置。它能檢測配置何時未聲明數據類型（dtype），並從 safetensors 元數據頭中推斷。它在 transformers 和 MLX 之間運行逐層對比，以精確定位發散發生的位置。這些檢查只有具備移植經驗的人才會想到去運行。

對於審查者，該技能生成的 PR 會坦誠是智能體輔助的，但看起來確實像細心的真人提交。審查者會看到代碼遵循 mlx-lm 的慣例：地道的解決方案、無不必要的註釋、無投機性的抽象、未經明確批准不修改共享工具。鑑於代碼是智能體輔助的，我們嘗試包含比平均 PR 更多的數據，以提供盡可能多的信號。PR 正文包含一份報告，摘要了變體及其架構差異、生成範例、數值對比、數據類型驗證、以及針對 transformers 基準的逐層對比。PR 始終會披露它是智能體輔助的，且在貢獻者接受結果之前，該技能不會開啟 PR。

為了驗證，該技能會為一個獨立的、非智能體化的測試框架生成測試清單（manifest），該框架在設計上易於重現，且不受 LLM 幻覺或盲目從眾的影響（詳見下文）。

我們是如何做到的

「技能」（Skills）是智能體的食譜：包含指導方針的簡單文本文件，引導模型完成複雜任務。它們並非魔法；你可以通過提示和迭代達到同樣的結果。但它們提供了連貫性（每次運行都遵循相同的過程，而不同的人提示方式不同）、最小化歧義，並作為文檔：任何人都可以閱讀技能文件來了解它的作用、識別缺失的情況並提出改進建議。

我們通過親自移植一個模型來引導（bootstrap）這項技能，過程中與 Claude 進行對話。我要求它將 GLM 4.7 從 transformers 移植到 mlx-lm，並像平時一樣給出指示。一個技巧是：我讓 Claude 指向一個我已經刪除了現有實現的 mlx-lm 分支，這樣我就可以將輸出與真實結果進行對比。經過幾次迭代後，我得到了一個可運行的實現、一段揭示 Claude 如何處理問題的對話，以及技能的第一個草案（由 Claude 作為過程總結創建）。我對其進行了大量修改，並納入了 @gabegoodhart 的經驗，他慷慨地分享了自己移植另一個模型的對話過程 🙌。

我們多次重複這個循環，技能也隨之成長。在技術方面，我們涵蓋了諸如：可能產生看似合理但在長序列中退化的 RoPE Bug、會悄悄殺死推理速度的 float32 精度污染（你會驚訝於這些事情發生的頻率！）、以及實現必須處理的跨模型變體的配置字段、不適用於單台機器的超大型模型的分布式推理。我們教會它如何調用 hf CLI 來發現和下載模型。最重要的是，我們指示它運行經驗豐富的移植者會運行的測試，並且在測試通過前不宣告成功。

來源：@Prince_Canuma

在文化方面，我們涵蓋了較軟性的特徵，並解釋了使 PR 易於審查的慣例：不要使用註釋來解釋代碼（審查者必須同時解析註釋和代碼 🤦‍♂️）、絕不提議重構、未經詢問不要觸動共享工具。這些規則對智能體來說毫無成本，卻能為審查者節省大量時間。

最終結果：貢獻者輸入提示詞，技能就會生成像這樣的 PR，以及外部測試框架的測試清單。

測試框架

該技能在 PR 中分享一份全面的結果報告。這些都來自智能體在轉換期間運行的測試，但我們不希望審查者僅憑信任就接受它們。為了更進一步，我們創建了一個獨立的、非智能體化的測試框架，對轉換後的代碼運行系統測試。這帶來了幾個好處：

測試框架並非 CI 門禁。有些檢查很直接（輸出數據類型是否正確？），但大多數是定性的。預訓練模型在長序列中自我重複是否正常？與 transformers 基準相比，4% 的相對 Logits 差異是否可以接受？這些是基於類似架構經驗的判斷。框架提供了有用的信號，但最終仍需審查者和貢獻者做出決定。

如何使用該技能

該技能是為那些已經在提交 mlx-lm 模型 PR，或準備手動進行移植的人設計的。它不適合大眾消費，因為 mlx-lm 的 PR 很少會被直接採納。典型的循環是：貢獻者開啟 PR，審查者指出改進點，雙方迭代直到達到質量標準。如果專家提交的內容是這樣，智能體輔助的提交也將如此。

如果你不打算參與這個循環，你可能不應該開啟 PR。審查者會努力理解你的代碼（即使知道它是智能體輔助的），所以你也應該這樣做。承擔起代碼的責任，並準備好納入他們的反饋。特別是，不要把審查者的評論直接丟回給智能體，然後發布它產出的任何內容。LLM 會堅持自己的決定、離題，且無法有效地進行辯論。一旦你與審查者互動，這就變成了人與人之間的對話，所以輪到你來討論並尊重他們投入的時間。

你也可以利用這項技能來學習；在你的信心和經驗建立之前，你不需要提交任何東西。閱讀技能文件以識別你未察覺的問題區域：技能文件、參考文檔和工具腳本中包含近 1.5 萬字。將它指向你自己的 mlx-lm 分支，嘗試轉換，並在官方倉庫發布正式實現後對比你的輸出。如果你這樣做幾次，你會學到很多關於 transformers、MLX 和語言模型架構的知識。

如果你準備好了：

我們使用 Claude Code 開發並測試了該技能。同樣的方法也適用於 Codex 或其他編碼智能體，但我們尚未測試。如果你在不同環境中嘗試該技能，請告訴我們效果如何！

後續步驟與已知不足

該技能在 mlx-lm 的 LLM 移植方面表現良好，但仍有很大提升空間。

下一步計劃

目前尚無法運行的部分

結論

開源的瓶頸不在於打字速度：而在於理解代碼庫，以便在不破壞與用戶的隱性和顯性契約的情況下進行更改。如果我們教會智能體什麼是重要的，它們就能在這個過程中提供幫助。我們探索了這在 mlx-lm 背景下的樣貌，希望它能幫助貢獻者和審查者更快地完成高質量的模型轉換！

資源

貢獻：

函式庫：

背景：

謝謝！

非常感謝 Ben、Shaun、Aritra 閱讀本文的早期版本並使其變得更好 🙌

我們非常感激 Apple 將 MLX 作為開源項目發布，也感謝社區立即認可其價值並熱情地做出貢獻 🙏

更多來自我們博客的文章

OpenEnv 實踐：在真實環境中評估工具使用智能體

Codex 正在開源 AI 模型

社區

· 註冊或登錄以發表評論