使用自訂 AI 模型。 我花了數週時間在 Azure A100 上測試了 8B–30B 的編程模型。 改變我們架構的模型是？ 在 M2 Pro Mac mini 上，僅用 3 分鐘 35 秒訓練了 137M 參數的模型。 微軟的 FastContext 揭示了瓶頸： 儲存庫探索可能消耗編程代理 46.5% 的 token。 他們發表的實驗將主代理使用量降低了高達 60.3%。 我在 DeltaCode 中進一步推進了這個想法： → Go 會列舉合法的儲存庫上下文 → 我們自訂的 137M 排序器處理常規選擇 → FastContext 4B 僅處理模糊的 READ/GLOB/GREP 探索 → 自訂 Qwen3 4B 執行編程預檢 → 費用高昂的模型僅接收壓縮證據，而非整個儲存庫 → 編譯器和測試保留最終決策權 我的自訂排序器達成： • 57.97% 封閉式 Recall@5 • 比原生模型高出 +5.80 點 • Recall@1 提升 +14.49 點 • 在路由的外部案例中達到 73.33% Recall@5 • 0 執行權限 效率差異極為顯著： • 比 4B 探索者少 96.6% 參數 • 比 27B–30B 模型少 99.5% 參數 • 僅有 0.3225% 的參數經過訓練 • 因此 99.68% 的基礎參數保持凍結 • 此適配器完全避免了 A100 的開支 • 預計一旦級聯在本地處理常規儲存庫搜尋，雲端上下文 token 將減少 35–55%* 大型模型並非因缺乏智慧而失敗。 它們失敗是因為我們要求單一模型同時執行探索、推理、格式化、編程、操作工具並自我驗證。 小型模型之所以勝出，是因為每個模型都只負責一項可衡量的任務。 我透過昂貴的 A100 實驗學會了如何在生產環境中避免使用昂貴的計算資源。 編程代理的未來，或許不是一個龐大的 LLM。 而是一支由眾多微型專家組成的團隊——每個專家只專注於一項任務，各自獨立評估，且無一擁有最終決策權。