Beam 權重開放：Apache 2.0 到手，Agent 能力為何不能只看總分？（2026）

2026 年 10 月 16 日，Reflection 在官網發布〈Beam is now available〉，宣布 Beam 權重開放。10 月 5 日的模型預告，到了可以檢查檔案與授權的階段；接下來的問題是：拿得到模型，究竟讓哪些事情變得可行，又有哪些能力仍要另行驗收？

先看這次交付了什麼，再對照外部評測，最後判斷適合把它放進哪一種工作。這次的新進展是取得與改造模型的選擇增加；能力是否適合你的任務，則由另一份證據回答。

Beam 權重開放：先把「已交付」與「接下來」分開

與我們先前的Beam 預告分析相比，這次可以直接查到 Hugging Face 的權重分片、設定檔與 LICENSE。官方模型集合列有 BF16、FP8、NVFP4 與 DFlash2 草稿模型；這些檔案讓自行部署、量化選擇與後續調整，有了具體的起點。本文只查驗公開材料，沒有下載整套權重或執行模型推論。

依模型卡，Beam 是文字輸入、文字輸出的稀疏混合專家模型：總參數 501.3B、活躍參數 23.4B，上下文標為 1M tokens，主要以英文開發。設定檔的最大位置數為 1,048,576。這是配置容量的證據；長文件裡的資訊能否被完整找出、繁中任務能否穩定做對，仍需以具體問題驗收。

也別把 A23B 當成只要容納 230 億參數。它描述單步計算啟用的部分；部署還要安排整體權重與執行時記憶體。這次有不同精度的版本，意味著可以比較不同配方，並不直接交出「你的機器能跑多快」的答案。

公告的另一條時間線是客製化。Reflection 展示微調、強化學習與自蒸餾的路線；其中自蒸餾配方，在這篇 10 月 16 日公告裡仍被寫成未來幾天將發布的項目。不要把公告內的下一步，併入已交付清單。若要今天採用，先找到可執行文件與對應版本，再討論重現。

Apache 2.0 的價值：能改造，還要保留使用條件

這次的授權可以查到實際檔案。模型倉庫的 LICENSE使用 Apache License 2.0：提供使用、修改與散布的授權；重新散布時要附授權、標記修改，並遵守適用的通知保留要求。它也明確區分商標權，不能把模型的授權理解成取得品牌背書。

對企業或研究者，這改變的是選擇權：可以把模型放在自己控制的環境，評估特定領域調整，再決定如何提供服務。至於訓練資料、建模過程與執行環境是否足以完整重建，應逐項查驗；一個授權名稱不能包辦所有「開放」的含義。

同樣要分清權重與線上服務。Reflection 的服務條款明確將自架模型交由相應模型授權處理，企業與開發者的線上服務另有商業條款。因此，讀取某個 API 的條件，與持有權重後怎麼部署，是兩條需要分別核對的路。

原文真正的訴求：模型外面，也要有一套可運作的系統

A model is only one layer of a working system; making it useful takes more than releasing weights.

中文：模型只是可運作系統的一層；要讓它有用，光是釋出權重還不夠。

Reflection，〈Beam is now available〉

原文把推論、部署、評估、安全工具、客製化與 Agent 執行環境接成一幅圖，並以逾 40 個合作夥伴與整合項目描述生態系。這是公司的發布範圍與願景；真正值得採用者逐層核對的，是自己要用的那條路是否已備齊。單一平台的支援，不能替其他平台的配置與品質做保證。

其中 Mirror CLI是讓模型在終端機接工具、讀專案與執行工作的 Harness。官方原始碼與說明列出不同 worktree 的平行工作、對話接續與分支、工具核准、模型端點選擇等能力。它讓模型外圍的控制方式變得可檢查，也提醒我們：模型與控制它的程式，會共同影響最後結果。

這張示範圖顯示的是擴充功能的指令入口，並非成功率證明。Mirror 的 README 還特別提醒：預設工具使用你的帳號權限，核准操作本身不提供檔案系統或網路隔離。初次試用應從測試專案開始，把可讀資料、可寫範圍與可執行工具先縮小。

外部評測：自動化工作流與終端機，分數指向不同方向

Artificial Analysis 在 10 月 16 日的原始評測報告，Beam 的 Intelligence Index 為 30。同篇記錄 Muse Spark Open 為 39；這是該次指數與測試範圍內的比較，不能改寫成每種應用的能力差距。

更有用的是拆開組成：Beam 的 AutomationBench-AA 為 48.5%，Terminal-Bench 4.0 為 3.0%。前者顯示它在該工作流自動化考卷的表現較突出，後者揭露終端機測試的弱項。兩個百分比的題目、難度和評分範圍不同，不能相減成「能力落差」。

官方模型卡另列 BF16 的 Terminal Bench v2.1 為 80.1%。v2.1 與 4.0 是不同測試版本，所以這兩個數字不能直接拿來指控誰造假，也不能挑較好看的那個當唯一結論。應先核對版本、框架、預算與測例，再問成績是否對應自己的工作。

Artificial Analysis 也測了 Beam 搭配 Mirror 的完整組合：Coding Agent Index 為 28；同篇列出的領先組合為 68。它另報告 Beam 每個 Intelligence Index 任務約使用 26,000 個輸出 tokens。這支持「在那組測試中較節制」的觀察，仍不足以保證你的每次合格交付更便宜。失敗後的重試、工具等待與檢查時間，都要算回工作。

這些結果都歸屬評測方的觀察，並非 AlphaLab 的重跑成績。它們最直接的提醒是：開放權重讓你可以開始比較，並不先替比較宣布勝負。

安全文件已到位，部署安全仍要沿工具邊界驗收

這次也有可閱讀的 Beam Safety Technical Report。Reflection 在其中依自己的 Open Safety Framework 評估風險，並收錄外部機構的測試。這讓釋出決策與限制有材料可查；報告裡的評級仍應保留評估者、方法與比較基線，不能當成每個部署場景都通過的證書。

報告本身也提醒，在 Agent 評測中，框架、工具集、互動預算與上下文都會改變成績。這個限制同樣適用於安全：當模型從回答問題走向執行指令，真正需要檢查的是它能碰到什麼、錯了能否被攔下、工作結束後能否清楚核對。可從Agent Harness 的工作迴圈把這幾層拆開。

AlphaLab 的判讀：我同意選擇權增加，存疑的是把選擇權當成能力保證

一、權重交付，讓「我想換一個環節」成為可行問題

只有服務入口時，使用者通常只能在供應者提供的選項裡挑。拿到權重與可檢查的工具之後，可以研究更換推論引擎、調整精度或針對領域適配。這個價值不需要靠總榜第一才能成立：若一個組織重視可控制的部署環境，它可以有充分理由測 Beam。

但控制權的價值來自你實際能維護的那一層。若團隊無力處理模型更新、回歸測試與故障，自架也可能把服務商原本承擔的工作搬到自己身上。選擇增加，與總負擔減少，應分開計算。

二、能力不均衡，應改變派工方式

工作流自動化、修補程式與終端機操作，各自需要不同的行為組合。這次外部測試的分布，適合用來提出派工假設：先挑能明確驗收的一類工作，再確認 Beam 搭配你的工具能否完成。把一個總分展開成幾項可測任務，比替整個模型貼上「強」或「弱」更有用。

如果要比較 Mirror 與另一套 Harness，先固定模型；如果要比較 Beam 與另一個模型，先固定框架。兩者同時更換，即使交付改善，也很難知道下一次該保留哪一個環節。

三、蒸餾與微調，先要有能判斷好壞的考卷

原文描述的自蒸餾路線，是收集任務軌跡、驗證後再用來調整模型。這個迴圈最容易被低估的零件，是「驗證」：若只是挑看起來流暢的回答再訓練，可能強化的是熟悉的寫法。先有獨立的驗收條件，才知道微調學會了什麼，以及原本能力是否退步。

我同意：把權重、授權、工具與部署文件一起交付，增加了研究與採用的可操作性。我存疑：把較少推理 tokens、長上下文或生態系規模，直接換成前沿能力與交付效率的保證。這些訊號值得追，但各自都需要任務層的收據。

下一步：先挑一件能判分的工作，再決定是否搬到 Beam

先準備一個可復原的小任務，例如在假資料專案修一個已知 bug；預先寫下測試、允許修改的檔案與停止條件。使用已有且獲授權的模型入口，固定模型版本、精度、Harness、工具權限與時間預算。把「是否完成」和「用了多少資源」分兩欄記錄，失敗與重試也留下。

長文件工作則另外測：先放入你知道答案的位置、矛盾版本與找不到答案的問題，看輸出能否指出依據、承認缺口。主要面向繁中使用時，就用繁中材料驗收。1M 是可以提出大考卷的起點，考卷仍要能判分。

真正值得追蹤的後續證據，是同一批真實任務上的完成率、每次合格交付的總耗時與總成本，以及調整前後的回歸結果。先用AI Evals 的驗收方法做出小考卷；如果特定任務穩定過關，再逐步擴大權限與工作量。這才把 Beam 權重開放帶來的選擇，轉成能採用的能力。