目錄
Reflection Beam 是 Reflection AI 推出的開放權重大型語言模型，擁有約 5,013 億總參數、234 億啟用參數，以及最高 100 萬 Token 的上下文長度，主要針對程式開發、複雜推理與 AI Agent 多步驟任務設計。2026 年 10 月 16 日正式公開模型權重後，開發者除了能透過 API 使用 Beam，也能自行部署、調整推論環境，或將模型整合至既有的 Coding Agent 工具。
Beam 受到關注的原因，除了開放權重與大型 MoE 架構，還包括它試圖降低 AI 代理完成複雜任務所需的推理運算量。不過，從第三方測試來看，Beam 的程式開發能力仍有明顯限制，較少的推理 Token 也未必能換來更低的實際成本。對準備把 AI 接入 GitHub、Notion 或企業內部系統的團隊而言，模型效能只是其中一項考量，部署費用、資料權限與任務驗收方式同樣會影響最終成果。
Reflection Beam 是什麼？Reflection AI 開放權重模型正式發布
Reflection Beam 是美國 AI 公司 Reflection AI 開發的第一款開放權重大型語言模型，採用稀疏混合專家架構（Sparse Mixture-of-Experts，MoE），並以軟體工程、工具呼叫與長流程代理工作為主要應用方向。
Reflection AI 於 2026 年 10 月 5 日首次公布 Beam，當時主要介紹模型架構、訓練方法與初步效能。經過後續安全測試與評估，公司在 10 月 16 日正式釋出 Beam 1.0 權重，並同步提供模型說明、安全技術報告及開發工具；AWS、Google Cloud、Hugging Face 等平台也在發布期間提供部署或整合支援。
Beam 與一般 AI 聊天工具最大的使用差異，在於它的設計特別考慮到需要反覆使用工具的工作情境。以修復程式錯誤為例，AI 不一定能靠單次回答完成任務，而是需要讀取專案檔案、執行測試、理解錯誤訊息，再根據結果決定下一步。Beam 針對這類工作進行訓練，但實際執行仍須搭配 Coding Agent 框架及外部工具。
Reflection Beam 開放權重，與一般開源 AI 有什麼不同？
Beam 採用 Apache 2.0 授權，允許開發者在遵守條款的前提下下載、修改、重新散布及商業使用模型權重。相比只能透過供應商 API 使用的封閉模型，開放權重讓企業能自行選擇模型執行位置、推論框架與硬體配置，也能根據內部需求進行微調或其他客製化工作。
不過，開放權重不代表整個模型的開發流程都已公開。Reflection AI 提供模型權重、架構資訊與部分訓練方法，但完整訓練資料、資料篩選流程及所有內部研發細節並未全部釋出，外部研究者仍無法僅憑公開檔案完整重現原始訓練過程。
對企業而言，兩者的差別主要反映在控制範圍。開放權重可以讓組織自行管理模型執行環境，降低對單一 API 供應商的依賴；至於訓練過程是否可完整稽核、部署後是否符合資安規範，仍需要另外評估，不能只根據授權名稱判斷。
Reflection Beam 模型規格：501B 參數、MoE 架構與 100 萬 Token 上下文
Beam 的模型規模相當龐大，但它並非每次生成文字時都使用全部參數，而是透過 MoE 架構選擇部分專家參與運算。這種設計讓模型可以保有較大的參數容量，同時減少每次處理 Token 所需的部分計算量，也是 Reflection AI 強調推理效率的主要技術基礎。
根據 Reflection AI 官方 Model Card，Beam 1.0 的主要規格如下。
| 模型項目 | Reflection Beam 1.0 |
| 開發公司 | Reflection AI |
| 模型架構 | Sparse Mixture-of-Experts（MoE） |
| 總參數 | 501.3B，約 5,013 億 |
| 啟用參數 | 23.4B，約 234 億 |
| 專家數量 | 256 個 |
| 模型層數 | 52 層 |
| 上下文長度 | 100 萬 Token |
| 輸入與輸出 | 文字 |
| 權重格式 | BF16、FP8、NVFP4 |
| 模型授權 | Apache 2.0 |
| 知識截止日期 | 2026 年 6 月 30 日 |
| 主要開發語言 | 英文 |
這些數字適合用來初步了解模型架構，但無法直接代表實際回答品質或部署成本。例如總參數相近的兩款模型，可能因為專家路由方式、注意力機制、量化格式及推論框架不同，產生截然不同的硬體需求與執行速度。
501B 總參數與 23B 啟用參數，為什麼不代表一般電腦就能執行？
Beam 的 501.3B 總參數分布在不同模型層與專家網路中，處理每個 Token 時，只會啟用約 23.4B 參數參與計算。這能避免每次推論都動用完整模型的計算量，但其他專家權重仍需要存放在記憶體或透過適當的載入機制取得，因此硬體需求不會直接縮小成一般 23B 模型的等級。
以 BF16 權重估算，每個參數約需 2 Bytes，501.3B 參數的原始權重資料便接近 1 TB，尚未計入 KV Cache、執行框架及其他記憶體開銷。即使改用 FP8 或 NVFP4 壓縮權重，仍需要考慮 GPU 記憶體、裝置間通訊、記憶體頻寬與量化後的執行相容性。
Reflection AI 提供的 BF16、FP8 與 NVFP4 格式，主要差別在於權重精度和資源需求。BF16 的權重占用空間較大；FP8 可降低儲存與記憶體負擔，而 NVFP4 進一步使用較低精度表示部分權重，適合研究支援該格式的硬體部署方案。
但精度較高並不保證每項基準測試都表現最好。Beam 官方公布的 SWE-bench Verified 結果中，BF16、FP8、NVFP4 分別得到 81.6%、80.2% 與 80.7%，三者存在差異，卻不足以直接推論所有實際工作中的品質排序。企業若準備長期部署，仍應使用內部任務比較不同格式的正確率、回應速度及整體資源消耗。
Reflection Beam 支援 100 萬 Token，真的能理解整個程式專案嗎？
100 萬 Token 的上下文長度，讓 Beam 可以一次接收大量程式碼、技術文件與工具執行紀錄，對需要跨檔案分析的 Coding Agent 特別有吸引力。例如追查某個 API 的異常時，代理可能需要同時閱讀服務程式、測試檔案、錯誤日誌及相關規格，長上下文能減少因容量限制而被迫切斷資訊的情況。
然而，模型能接收多少文字，與它能否準確找到相關資訊，是兩個不同問題。當上下文同時包含多個版本的技術文件、重複錯誤紀錄或已經過時的規格時，模型仍可能引用錯誤內容；而且 Coding Agent 每次執行工具後，通常還會把新的結果加入對話歷史，使後續推論需要處理的資料持續增加。
對大型程式庫來說，直接把所有檔案送進模型，通常不是最有效率的做法。透過程式碼搜尋、檔案索引或檢索系統先找出相關模組，再提供必要的程式碼與測試紀錄，可以降低資訊干擾，也比較容易追查 AI 為什麼做出某項修改。
另外，Beam 目前是文字輸入與文字輸出模型，且主要以英文資料開發。涉及繁體中文需求文件、混合語言程式註解或圖片形式的設計規格時，不能直接假定它具有與英文文字任務相同的處理能力。
Reflection Beam Coding Agent 能做什麼？Mirror CLI 如何執行程式開發任務
Coding Agent 與一般程式碼生成工具的差異，主要在於能否根據執行結果持續處理工作。一般 AI 工具可能在收到需求後產生一段程式碼，而 Coding Agent 則能透過外部工具搜尋檔案、修改程式、執行測試，並依照測試結果決定是否繼續調整。
Reflection AI 同步推出的 Mirror CLI，就是為 Beam 設計的 Coding Agent 執行工具。Mirror 可以在終端機中操作，管理模型對話、工具呼叫與工作階段，也支援 MCP 整合及不同 Git Worktree 的平行作業。開發者可以檢視代理操作過程、核准工具呼叫，並在需要時介入工作。
Mirror 的架構將開發工具介面與代理執行核心分開處理，由 Python 前端管理使用者互動、提示詞及擴充工具，再透過 Rust 核心協調模型和外部操作。這種設計有助於將模型推理與實際工具執行分離，也方便開發團隊針對不同工作建立測試環境。
不過，Coding Agent 是否能完成任務，仍取決於模型、執行框架與工具權限的配合。即使 Beam 能正確判斷某個程式錯誤，如果代理無法執行必要測試，或缺少相關檔案的讀取權限，最後仍可能無法交付可驗收的結果。
Reflection Beam 效能好嗎？官方基準測試與第三方評測差異
Reflection AI 在模型發布時公布多項效能測試，涵蓋軟體工程、終端機操作、數學推理及工具呼叫。官方數據顯示，Beam 在部分 Coding Agent 任務上具有競爭力，但第三方平台的測試結果並不完全一致，因此需要先確認評測方法，才能判斷成績代表什麼。
Beam 官方 SWE-bench 與 Terminal-Bench 成績如何？
Reflection AI 的 Model Card 公布了不同精度版本的測試結果。以 BF16 模型為例，SWE-bench Verified 得分為 81.6%，SWE-bench Pro v2-Hard 為 76.5%，Terminal-Bench v2.1 則為 80.1%。這些數據顯示 Beam 在官方採用的測試環境中，能完成相當比例的程式修復與終端機任務。
不過，Coding Agent 測試通常會受到執行框架、工具設定、重試次數及評分規則影響。某項基準測試得到 80% 的成績，並不表示把 Beam 接上企業程式庫後，就有八成機率一次修復成功。
Artificial Analysis 實測：Beam 擅長自動化，但程式代理能力仍有限
2026 年 10 月 16 日，第三方評測平台 Artificial Analysis 公布 Beam 的獨立測試結果。在當時的 Artificial Analysis Intelligence Index 中，Beam 得分為 30，排名美國開放權重模型第二，但不同工作類型的表現存在明顯落差。
| 測試項目 | Beam 成績 | 測試來源 |
| SWE-bench Verified | 81.6% | Reflection AI 官方 |
| SWE-bench Pro v2-Hard | 76.5% | Reflection AI 官方 |
| Terminal-Bench v2.1 | 80.1% | Reflection AI 官方 |
| Artificial Analysis Intelligence Index | 30 分 | Artificial Analysis |
| AutomationBench-AA | 48.5% | Artificial Analysis |
| Terminal-Bench 4.0 | 3.0% | Artificial Analysis |
| Coding Agent Index（Mirror） | 28 分 | Artificial Analysis |
需要特別區分的是，官方 Terminal-Bench v2.1 與第三方 Terminal-Bench 4.0 並非相同測試，題目、執行環境及評分條件都可能不同，因此不能直接把 80.1% 與 3.0% 當作同一能力的前後對照。
從第三方結果來看，Beam 在 AutomationBench-AA 得到 48.5%，顯示它在部分自動化工作流程具有一定能力；但在 Terminal-Bench 4.0 只有 3.0%，代表面對該測試設定的終端機任務時，表現仍然偏弱。搭配 Mirror 的 Coding Agent Index 也只有 28 分，與當時部分領先代理組合存在差距。
另一項需要留意的測試是 AA-Omniscience。Beam 在這項知識評測中答對約 33% 的題目，但幻覺率達到 47%，顯示模型即使具備較強的推理能力，在部分缺乏確定答案的情境下仍可能產生錯誤資訊。這項結果不能直接套用到程式修復成功率，卻提醒企業在使用 Beam 處理技術文件、研究資料或自動化決策時，仍需要外部驗證。
Plotly 資料分析實測：Beam 為什麼比同分模型昂貴？
模型的推理效率高，不一定代表完成整件工作所需的費用比較低。2026 年 10 月 17 日，Plotly 公布 Beam 1.0 在 DataAnalyticsBench 的測試結果，使用相同的代理工具與資料環境，要求不同模型回答 43 題資料分析問題。
Beam 答對 36 題，通過率約 84%，與 DeepSeek V4.1 Flash 相同，但兩者的測試成本差距相當大。
| 比較項目 | Reflection Beam 1.0 | DeepSeek V4.1 Flash |
| 答對題數 | 36／43 | 36／43 |
| 通過率 | 約 84% | 約 84% |
| 完整測試成本 | US$8.29 | US$0.46 |
| 平均每題模型呼叫次數 | 約 15 次 | 約 7 次 |
Plotly 分析指出，Beam 在這次測試中需要更多模型呼叫，而且當時的服務商幾乎沒有有效利用輸入快取。每次代理繼續工作時，都需要重新送出大量對話歷史，造成輸入 Token 費用累積；Beam 的快取輸入比例僅約 0.4%，使整輪測試成本明顯增加。
這項結果反映的是 2026 年 10 月當時特定託管服務與代理設定的表現，不能據此認定 Beam 在所有部署環境都比較昂貴。若推論服務能有效重用 KV Cache、減少重複處理上下文，實際成本仍可能改變。
不過，對需要長時間執行的 AI Agent 而言，這個案例具有參考價值。企業不能只比較每百萬 Token 的價格，還需要記錄代理為完成任務呼叫模型多少次、重複處理多少內容，以及是否因為錯誤而需要重新執行。
Reflection Beam 如何部署？AWS SageMaker、Google Cloud 與自行託管比較
Beam 採用開放權重授權，因此可以透過不同服務商提供的 API 使用，也能部署在企業自行管理的 GPU 環境。AWS 與 Google Cloud 都在 2026 年 10 月 16 日公布 Beam 支援方案，但兩者提供的工具與管理方式不同，適合的團隊規模也不完全相同。
AWS SageMaker JumpStart 與 HyperPod 有什麼差別？
AWS 提供的其中一種方式，是透過 Amazon SageMaker JumpStart 建立受管理的即時推論端點。JumpStart 可以降低模型部署的初期設定工作，適合希望先測試 Beam 能力、評估 API 整合與觀察推論成本的團隊。
如果需要更細緻地控制 Kubernetes、GPU 資源與推論框架，則可以考慮 Amazon SageMaker HyperPod Inference，並搭配 SGLang、vLLM 等工具調整執行環境。這類配置提供更多控制權，但容量規劃、監控、故障處理與版本更新等工作，也需要企業投入相應的工程資源。
AWS 另外公布 Beam 對 Trainium3 的支援，使企業在 GPU 之外多了一種硬體部署選項。不過，硬體支援並不能直接換算成成本節省，仍應根據可取得的執行環境、請求量、延遲要求及完整帳單比較。
截至發布時，AWS SageMaker JumpStart 的 Beam 服務初期開放於美東維吉尼亞北部與美東俄亥俄。若台灣企業準備使用這些區域處理內部程式碼或客戶資料，需要確認組織的資料治理政策、跨區傳輸要求及相關服務設定，不能因為模型部署在自己的 AWS 帳戶，就直接假定所有資料都留在指定地區。
Google Cloud 部署 Beam，最高 5 倍效能提升代表什麼？
Google Cloud 同樣在 Beam 權重發布當天提供部署支援，並與 Reflection AI 合作，針對 llm-d、vLLM、NVIDIA Dynamo 與 SGLang 等推論元件進行最佳化。
Google Cloud 公布，在指定硬體與測試環境下，最佳化方案最高可達到 5 倍吞吐量，以及最高 8 倍的延遲改善。這些數據主要反映推論服務的系統效率，並非 Beam 的回答準確率提升，也不代表所有硬體配置都能取得相同結果。
這類最佳化的重要性，在於 Coding Agent 通常會持續進行多輪模型呼叫。隨著工具紀錄、程式碼差異及對話歷史增加，推論服務需要反覆處理大量上下文；若每次請求都被分配到不同執行節點，可能無法有效重用已經計算過的 KV Cache，進而增加延遲與 GPU 工作量。
Google Cloud 的方案透過快取感知路由、記憶體分層及推論工作分配，減少不必要的重複運算。對高頻率執行 AI Agent 的企業而言，這些基礎設施設定可能比單純提高模型輸出速度更影響長期成本。
Reflection Beam 三種使用方式，哪一種比較適合？
| 使用方式 | 適合對象 | 主要優勢 | 需要注意的成本 |
| 託管 API | 個人開發者、小型團隊 | 不需自行管理 GPU | API 計費、服務限制與資料處理政策 |
| 雲端受管理端點 | 企業測試、內部應用開發 | 降低部分部署工作 | 端點執行費、閒置資源與區域限制 |
| 自行管理模型 | 已具備 AI 平台工程能力的企業 | 控制模型版本、硬體與資料環境 | GPU、維運、安全監控及擴充成本 |
如果只是想測試 Beam 的程式修復能力，使用託管 API 或受管理端點通常比較容易取得初步數據。對需要長期處理敏感程式碼、限制資料傳輸位置，或準備進行模型客製化的組織，自行部署則可能具有較高的控制彈性，但前提是具備足夠的工程能力與持續使用量。
Reflection Beam 安全嗎？Coding Agent 的工具權限與提示詞注入風險
Reflection AI 在 Beam Safety Technical Report 中公布了安全訓練及風險評估結果，其中包含間接提示詞注入（Indirect Prompt Injection）的測試。這類攻擊會把惡意指令藏在 AI 代理即將讀取的資料中，例如網頁、郵件、專案文件或工具回傳結果，試圖讓模型偏離原本任務。
Reflection AI 使用 Mirror 執行框架，在兩組內部測試中評估 Beam。未加入特定防護提示時，攻擊成功率分別為 3.1% 與 3.6%；加入防護策略後，測得的成功率降低至 0.3% 與 0%。
這些結果顯示防護措施在指定測試中有效，但測試使用固定攻擊方式，無法代表所有真實環境的風險。尤其當攻擊者可以反覆調整內容，或代理具有存取私人資料與外部傳輸的能力時，單靠提示詞要求 AI 忽略惡意指令，仍不足以構成完整防護。
對 Coding Agent 來說，真正需要管理的是工具可以做哪些事。例如允許代理讀取程式庫，不代表應同時允許它取得正式資料庫憑證；能建立 Git 分支，也不表示應直接擁有部署正式環境的權限。將不同操作分配到隔離環境，並要求高風險動作經過獨立授權，可以降低模型判斷錯誤帶來的實際影響。
開放權重也不會自動解決這些問題。即使 Beam 完全運行在企業自行管理的伺服器中，只要代理仍會呼叫外部 API、寫入雲端資料庫或傳送執行日誌，就需要重新檢查整條資料處理流程。
Reflection Beam 如何整合 Notion？建立可驗收的 AI Agent 工作流程
對使用 Notion 管理需求文件、開發進度與專案紀錄的團隊，Reflection Beam 可以作為外部 Coding Agent 的模型選項。這種整合方式並非 Notion 原生內建 Beam，而是透過 Notion API、MCP 或自建中介服務，讓 AI 代理在取得授權後讀取任務資訊，並將執行結果回寫指定資料庫。
比較適合的設計，是讓 Notion 保存需求、驗收條件與決策紀錄，程式修改則交由獨立的 Coding Agent 執行環境處理。例如網站出現會員登入異常時，Notion 任務可以先記錄錯誤情境、相關程式模組、預期結果及禁止修改的資料；代理取得任務後，在隔離的 Git 分支中調整程式碼並執行測試，完成後再將測試結果與程式差異交由負責人審查。
這種流程需要事先設計資料欄位與權限，而不能只給 AI 一句「修復網站問題」就期待它自行判斷所有邊界。任務描述越具體，越容易確認代理是否修改了正確範圍，也能在結果不符合預期時追查原因。
Notion API 與 MCP 的權限差異
Notion API 與官方 Notion MCP 都能提供資料整合能力，但授權方式並不完全相同。
透過 Notion API 建立內部連線時，可以設定連線的操作能力，並將可存取的內容限制在已授權的頁面或資料庫，適合需要明確控制自動化範圍的流程。Notion 官方 MCP 則會依連線使用者原本擁有的 Notion 權限執行操作，AI 工具可使用的範圍可能因此涵蓋該帳號能存取的其他資料。
這代表企業在啟用 MCP 前，應先確認連線帳號本身擁有哪些權限。若帳號可以讀取大量敏感文件，不能只依賴提示詞要求代理不要查看；比較穩妥的方式，是使用權限受限的專用連線，或透過中介服務額外限制工具呼叫與資料範圍。
另外，Notion 的任務狀態不宜完全由代理自行決定。AI 可以回報已修改的檔案、測試結果與執行紀錄，但是否允許合併程式碼、更新正式系統或結束任務，仍應依照事先設定的驗收條件判斷。
Reflection Beam 值得導入嗎？先比較任務成功率、成本與維運負擔
Reflection Beam 已提供正式權重與多種部署途徑，適合列入開放權重 Coding Agent 的評估名單，但目前的第三方測試還不足以支持企業直接全面替換現有程式開發工具。不同測試對 Beam 的評價差異很大，特別是需要操作終端機、反覆修復錯誤或長時間處理代理任務時，仍應使用實際工作內容測量表現。
導入初期可以先從能夠還原、容易驗收的小型工作開始，例如補充單元測試、修改非正式環境的程式錯誤，或整理技術文件。測試時盡量固定程式庫版本、工具權限與驗收條件，再與現有 AI 工具比較，才能避免把執行框架造成的差異誤認成模型能力。
評估成本時，除了 API 或 GPU 費用，也需要計入代理重試次數、平均完成時間、人工審查工時及錯誤修復成本。Plotly 的測試已經顯示，即使模型具備良好的推理效率，當上下文快取不足、工具呼叫次數過多時，完成整件任務的費用仍可能高於其他模型。
對大型企業而言，Beam 的價值可能來自部署位置、模型版本與基礎設施的自主控制；對個人開發者或小型工作室來說，若任務量不足以支撐大型模型的固定維運費用，使用託管服務反而可能更符合需求。
截至 2026 年 10 月 22 日，Reflection Beam 已具備開放權重、百萬 Token 上下文及多平台部署支援，但不同評測結果顯示，它還不是所有 Coding Agent 工作的最佳選擇。若準備將 Beam 接入 Notion、GitHub 或其他自動化系統，建議先確認資料存取範圍與驗收方式，再比較相同任務的成功率、處理時間及完整成本，取得實測結果後再決定是否擴大使用。
常見FAQs
Reflection AI 推出的開放權重大型語言模型，主要針對程式開發、推理與多步驟 AI Agent 任務設計；2026 年 10 月 16 日正式公開 Beam 1.0 權重。
約 501.3B 是模型總參數，每次處理 Token 時約啟用 23.4B。MoE 架構減少部分運算量，但部署仍須管理龐大的專家權重及 GPU 記憶體。
不能保證。上下文容量不等於檢索或推理準確率，仍應先篩選相關程式檔案、測試結果及需求文件，避免過時或重複資訊造成干擾。
Beam 權重採 Apache 2.0 授權，可在遵循條款的情況下商用、修改及重新散布；但 API、GPU、儲存、推論與維運服務可能另外收費。
Beam 是提供推理能力的模型，Mirror CLI 則是協調終端機、檔案與外部工具的 Coding Agent 框架。是否能完成程式修復，仍取決於工具配置、權限及測試環境。
官方使用 Terminal-Bench v2.1，Artificial Analysis 使用 Terminal-Bench 4.0，測試版本與執行條件不同，不能直接比較 80.1% 和 3.0% 或推論企業任務的成功率。
完成一件代理任務可能需要多次模型呼叫，還會反覆讀取上下文。Plotly 測試顯示，快取不足與較多呼叫次數可能讓整體費用高於相同答對題數的其他模型。
可用 SageMaker JumpStart 建立受管理的即時推論端點；需要更高基礎設施控制權的團隊，可研究 SageMaker HyperPod Inference 搭配 SGLang 或 vLLM。
不是。Google Cloud 公布的是特定硬體與最佳化推論架構下的吞吐量提升，主要與路由、KV Cache 重用及服務效率有關，不是模型答案正確率提升。
沒有。文章討論的是透過 Notion API、MCP 或自建服務串接外部 Coding Agent，由 Notion 保存任務與驗收紀錄，再讓代理在隔離環境執行工作。
內部 Notion API 連線可限定授權內容與操作能力；官方 MCP 依連線使用者原有的 Notion 權限運作，因此需要檢查連線帳號的實際存取範圍。
主要包括提示詞注入、越權工具呼叫及非預期程式修改。應將程式操作限制在可還原的環境，讓正式部署、刪除或敏感資料寫入經過額外授權。
不一定。Beam 的大型權重需要足夠的硬體與維運能力，建議先用託管 API 或受管理端點測試實際任務，再比較成功率、人工審查時間與總成本。