BTL-3：8GB 就能跑的本地程式代理人

📌 本文重點

• BTL-3 是可本地部署的程式代理人模型
• 8.39GB GGUF 保留約 92% 的 27B 能力
• 特化在工具呼叫與完整程式工作流
• 適合離線開發與本地 Agent 架構

想要在自己電腦上擁有類似 GitHub Copilot / Claude Code 的程式代理人，又不想連雲端？BTL-3 是目前少數「真實可落地」的開源選擇。

原帖與技術細節：[Reddit] BTL-3 27B agentic coding model

---

核心功能：一顆小體積、但會「自己想和動手做」的模型

1. Agentic 架構：不只是聊天，而是完整工作迴圈

BTL-3 的訓練目標不是「回答問題」，而是模擬一個真正的程式代理人工作流：

Reason → Act → Inspect → Recover → Continue

你可以直接把它當成一個「會自己規劃與檢查的本地 Copilot」，實際用法像這樣：

1. Reason（思考）：給它一個 repo 跟目標，例如：把這個專案加上簡單的健康檢查 API。
2. Act（行動）：它會規劃要改哪些檔案、生成修改方案或腳本。
3. Inspect（檢查）：搭配工具（如 git diff、測試腳本）檢查結果。
4. Recover（恢復）：若測試失敗，會根據錯誤訊息繼續修正。

行動建議：

• 設計你的 prompt 時，直接描述「任務目標 + 可用工具 + 成功條件」，讓它接手後續流程，而不是只叫它「寫一段程式」。

---

2. 工具呼叫：一次、連續、並行都能掌握

BTL-3 內建工具使用能力，可做到：

• 單次工具呼叫：例如呼叫 bash 跑測試、或呼叫 HTTP client 打內部 API。
• 連續呼叫：先爬資料，再處理，再更新資料庫。
• 並行呼叫：同時對多個服務發出請求，再整合結果。
• 知道何時不要用工具：測試顯示，它在「工具呼叫放棄」場景的表現也很不錯（原文數據：工具呼叫放棄約 91.2% 準確）。

💡 關鍵： 約 91.2% 的工具呼叫放棄準確率，代表它不只會用工具，也懂得在不需要時適時收手。

你可以把它接到現成 orchestrator（如 MCP、或你自己的 agent framework），讓 BTL-3 再負責「判斷何時用哪個工具」。

行動建議：

• 若你已有工具系統（CLI、內部 API），先列出 3–5 個常用操作，包成「工具描述 + I/O 格式」，再讓 BTL-3 透過這些工具完成任務，而不是只輸出文字。

---

3. 在 8.39GB GGUF 裡塞進 92% 的 27B 智慧

BTL-3 原始是 27B 參數模型，但 Bad Theory Labs 用自家量化壓縮技術（AVQ2 解碼、INT4 仿射運算等），做出一個：

• 單一 GGUF 檔（約 8.39GB）
• 每參數不到 2.5 bits
• 保留約 92.2% 原始模型能力

💡 關鍵： 約 8.39GB 的 GGUF 就保留 92.2% 能力，代表一般開發者電腦即可接近 27B 模型效能。

一個關鍵指標是 HumanEval pass@1 約 95.12%，這個成績在開源程式模型裡非常高，實際效果就是：

• 常見演算法題、資料處理、API 包裝腳本，大多可以一次寫對（或只需小修）。

💡 關鍵： HumanEval pass@1 約 95.12%，表示它在「一次寫對程式」上的成功率已逼近頂級商業程式模型水準。

行動建議：

• 若你現在在本地跑的是 7B–8B 一般聊天模型（例如常見的「通用 LLM」），可以直接用同一套 llama.cpp / LM Studio 配置，換成 BTL-3 GGUF，感受一次「針對程式與工具使用優化」的落差。

---

適合誰用：三種典型場景

1. 離線／內網環境的程式開發助手

如果你的程式碼不能上雲（金融、政府、內網產品），BTL-3 提供一條路：

• 在機房或開發者筆電本地部署，不經過外部 API。
• 讓它讀 repo、理解架構、提出修改建議。

典型任務：

• 在不同微服務間統一 logging 格式。
• 為舊專案補上基本 test suite。

行動建議：

• 選一個「不能丟到 GitHub Copilot」的專案，讓 BTL-3 先生成一份「系統總覽 + 待改善清單」，作為內網 code review 助手。

2. 自動化腳本 & 工具串接

BTL-3 對工具呼叫特別強，適合當成：

• CLI 自動化腳本生成器：幫我寫一個每天備份某資料夾到 S3 的腳本。
• 爬蟲與內部 API orchestration：串接 curl、Python script、內部 REST API。

行動建議：

• 設計一個小專案：例如「自動整理 log + 發 Slack 通知」，讓 BTL-3 負責生成腳本、再透過工具跑一次，測試它的完整 workflow 能力。

3. 本地 Agent 開發環境的一顆「程式專家」核心

你可能已經在用：

• llama.cpp / vLLM 當推理引擎
• 本地 IDE 插件（VS Code extension、JetBrains plugin）
• MCP 或其他 orchestrator 做多工具協調

BTL-3 可以直接當「程式 & 工具專家」，其他模型負責一般聊天或決策。

行動建議：

• 在你的 agent framework 裡，新增一個 coding-agent 路由：
• 當任務涉及 repo、CLI、API 操作時，轉給 BTL-3。
• 其他任務仍用通用模型（如 Solar Open 2、Laguna S 2.1 等）。

下面用表格簡單比較常見選項：

名稱	核心功能	免費方案	適合誰
BTL-3	本地程式代理人、工具呼叫	開源、GGUF 免費	想要本地 Copilot / 程式 Agent
Solar Open 2	長上下文、辦公 & 程式代理	開源模型	文件密集 + 長上下文任務
Laguna S 2.1	多語言、大型本地通用模型	開源模型	需要高性能通用助手

相關連結：

• Solar Open 2：https://www.reddit.com/r/LocalLLaMA/comments/1v3b58h/upstagesolaropen2250b_hugging_face/
• Laguna S 2.1：https://www.reddit.com/r/LocalLLaMA/comments/1v2orhb/poolsidelagunas21_released_finally_an_interesting/

---

怎麼開始：從硬體到第一個 workflow

Step 1：確認硬體配置

官方 8.39GB GGUF 版本的目標是「一般開發者電腦可以跑得動」，實務建議：

• RAM：16–32GB（越多越穩定）
• GPU：一張中階卡（8–12GB VRAM 足夠），或純 CPU 也可嘗試
• 儲存空間：至少預留 20GB 給模型與前端工具

行動建議：

• 先在自己的機器跑過任一 7B–8B GGUF 模型，如果能順跑，再換 BTL-3 應可接受。

Step 2：下載 BTL-3 GGUF 模型

目前 BTL-3 GGUF 版本由 Bad Theory Labs 釋出（連結通常在 Reddit 原帖或其 X 帳號）：

• 進 Reddit 帖文：https://www.reddit.com/r/LocalLLaMA/comments/1v3q86q/btl3_27b_agentic_coding_and_tooluse_model_from/
• 找到 GGUF 下載連結，選擇對應量化版本（建議先用官方推薦那個）。

行動建議：

• 用瀏覽器或 wget 下載 GGUF 檔到一個固定資料夾，例如：~/models/btl3/btl3-agentic.gguf。

Step 3：用 llama.cpp / LM Studio / Ollama 載入

三條常見路徑：

1. llama.cpp（命令列 / 伺服器模式）
2. 安裝：依官方 repo 說明編譯。
3. 啟動 server：
   bash
./llama-server \
-m ~/models/btl3/btl3-agentic.gguf \
-c 262144 \
--host 0.0.0.0 --port 8080

4. 之後透過 HTTP API 或前端連接。

5. LM Studio

6. 開啟 LM Studio → Add local model → 指向 GGUF 檔。

7. 選好推理設定（context 長度、GPU offload），直接在內建聊天介面測試。

8. Ollama 類工具

9. 建一個 Modelfile 指向 BTL-3 GGUF。
10. ollama run btl3 即可啟動本地推理。

行動建議：

• 初次使用先從 LM Studio 或類似 GUI 工具開始，快速確認模型品質，再把配置搬到 llama.cpp / server 模式。

Step 4：實作一個簡單 workflow：讀 repo → 改動 → Patch → 自評測

以下示範用「BTL-3 + llama.cpp server + 你習慣的 HTTP client」做一個小流程。

1. 讓 BTL-3 讀 repo
2. 先用你自己的 script 把重要檔案（README、主要程式入口、config）整理成一個壓縮過的文字輸入。

3. 發送一個請求：
   json
{
"prompt": "你是一個程式代理人。以下是專案的主要檔案內容：...\n\n請先用條列方式整理這個系統的主要模組與依賴，再列出 3 個可以改善的地方。",
"max_tokens": 2048
}

4. 規劃改動

5. 根據它提出的改善建議，選一項（例如「增加健康檢查 API」），再下指令：
   > 「請為此改動設計一個實作計畫：要改哪些檔案、新增哪些函式、需要哪些測試。」

6. 生成 Patch

7. 要求它輸出 git-style unified diff：
   > 「根據上面的計畫，請輸出 unified diff 格式的 patch，適用於 git apply。」

8. 自評測

9. 套用 patch，跑測試（可寫成工具讓 BTL-3 呼叫）。
10. 把測試結果回傳給 BTL-3：
    > 「以下是測試輸出，請根據錯誤訊息更新 patch。」

行動建議：

• 把上述流程包成一個腳本或簡單 web UI，讓 BTL-3 成為你團隊的「自動 Patch 提案助手」，從單一專案先試用。

Step 5：接進你現有的 Agent workflow（如 MCP）

如果你已在用 MCP 或其他 orchestrator：

1. 新增一個 LLM provider 指向 BTL-3：

2. 透過 llama.cpp server / LM Studio API 對接。

3. 定義工具：

4. read_repo：讀指定路徑檔案並壓縮輸出。
5. run_tests：執行 test 命令並回傳 stdout / stderr。

6. apply_patch：套用 diff 到 repo。

7. 給 BTL-3 的 system prompt：

8. 明確告訴它有哪些工具、何時該使用、成功定義（例如「所有測試通過」）。

行動建議：

• 在你的 orchestrator 裡，把「所有涉及程式碼修改的任務」預設派給 BTL-3，其他任務仍用通用模型，實際對比整體完成品質與速度。

---

BTL-3 的定位很清楚：不是要取代所有模型，而是成為你本地環境裡專門負責「寫程式 + 用工具」的那顆專家模型。如果你正在找一個接近本地版 Copilot / Claude Code 的選擇，它值得你花一個週末搭起來試用。

🚀 你現在可以做的事

• 到 Reddit 原帖下載 BTL-3 GGUF，並用 LM Studio 或 llama.cpp 在本地先跑一輪測試
• 選一個不能上雲的專案，讓 BTL-3 產生「系統總覽 + 改善清單」，試做一次 Patch workflow
• 在你現有的 agent framework 中新增 coding-agent 路由，將程式與工具相關任務導向 BTL-3 並觀察效果