能點擊畫面、輸入文字的 AI，乍看像是把自動化腳本換成會看螢幕的模型。Hugging Face 上的 Hcompany 在 2026 年 9 月 28 日發布 Holo4；依 Hcompany 發布說明，搭配執行框架後，同一代理可在圖形介面（GUI）、程式碼、模型上下文協定（MCP，讓模型連接外部工具的規範）與應用程式介面（API，供軟體交換資料或呼叫功能的介面）之間切換。它能補上部分軟體沒有 API、流程又跨越多種操作介面的缺口；能否穩定完成工作，仍要看執行框架、權限設計與結果驗證。
Holo4 新增的能力，究竟改變了哪個操作環節？
依 Hcompany 發布說明，Holo4 搭配執行框架後，可將 GUI 操作、程式碼執行、MCP 與 API 工具呼叫放進同一代理流程，讓模型依任務切換介面。這擴大了可操作的範圍，並不代表模型不需外部執行框架，也不代表它能自行判定任務已正確完成。
傳統腳本通常依照固定欄位、按鈕位置或 API 規格執行。條件穩定時，腳本步驟明確，也容易檢查；遇到介面改版、沒有 API 的舊系統或需要跨應用程式的流程，就得另外處理例外。電腦操作代理則可接收螢幕畫面，判斷目前狀態，再輸出點擊、輸入、捲動等動作。若任務另有程式碼環境、MCP（Model Context Protocol，模型上下文協定）工具或 API，代理也能透過那些介面取得資料或執行操作。
這種彈性在混合流程較有用。例如整理一筆資料時，代理可能先從網頁擷取內容，再以程式碼整理欄位，接著透過 API 查詢內部資料，最後在沒有整合介面的桌面應用程式輸入結果。Hcompany 表示，Holo4 可跨桌面、網頁、Android、程式碼沙箱與業務 API 執行任務。實際可用範圍仍由所接上的工具、環境和權限決定，不能只憑「通用代理」這個名稱推定。
因此，評估時要問的第一個問題是：既有自動化在哪個環節卡住？若每一步都有穩定 API，採用 API 或明確腳本往往更容易控管；若少數步驟只能透過畫面操作，GUI 代理可能補足缺口。混合做法也很常見，由確定性高的程式處理可預期步驟，將介面變動或需要判讀的部分交給模型。三種做法可先按介面穩定度、結果可驗證性與維護負擔篩選，再決定是否讓代理介入：
| 做法 | 適用情境 | 優勢 | 限制 |
|---|---|---|---|
| 固定腳本 | 欄位、步驟與介面長期穩定 | 行為可預期，容易重複執行與追蹤 | 介面或流程一改就需維護，例外處理需明確撰寫 |
| API／MCP 工具 | 系統提供穩定的資料或功能介面 | 可直接讀寫結構化資料，通常較容易核對輸入與結果 | 需有可用介面並處理權限、版本與連線故障 |
| GUI 代理 | 缺乏介面的舊系統，或必須跨畫面操作的流程 | 能依畫面狀態操作既有軟體，減少逐一改造介面的需求 | 受畫面變動、辨識誤差與長流程狀態影響，需加驗證與人工接手 |
表格提供的是初步選擇條件，不是固定排名。同一流程常同時包含穩定和不穩定步驟，例如資料查詢適合走 API，舊系統最後的確認畫面才需要 GUI 操作。若把整條流程都交給畫面代理，原本可用結構化欄位驗證的部分也會變得難追；反過來，若硬把每個畫面步驟寫成腳本，介面小幅改版就可能增加維護工作。先標出真正缺少介面的節點，才能估算引入代理後減少了多少人工切換，以及新增多少驗證與維運成本。
為什麼能操作畫面，仍不等於能穩定完成工作？
不代表。模型負責理解輸入並提出下一步，執行框架負責把截圖和工具結果送回模型、執行動作並管理流程，應用程式則決定資料與狀態如何變化；任何一層出錯，都可能讓整項任務失敗。
Hcompany 將執行框架稱為 harness，也就是包住模型的執行迴圈。框架會把螢幕截圖與工具結果交給模型，再執行動作並回傳結果。模型必須透過框架提供的操作能力才能控制電腦。Hcompany 說明其框架新增長流程記憶和桌面端 shell（命令列介面），這些系統設計不宜全歸功於模型權重。
流程越長，狀態錯誤越容易累積。代理可能看錯目前頁籤、重複送出表單、把尚未儲存的資料當成完成，或在操作失敗後沿用錯誤狀態繼續執行。若完成條件只是「模型說做完了」，就沒有確認資料是否真的寫入。較可靠的流程應以可觀察的結果驗證，例如比對資料庫欄位、確認檔案存在、檢查系統回傳的交易編號，並在狀態不明時停止或交給人員處理。
權限與錯誤復原也屬於可靠性的一部分。代理可能接觸帳號、檔案與業務資料，應按任務授予最小必要權限，並在隔離環境中限制外部連線與可執行指令。付款、刪除、對外寄送或變更權限等高影響動作，應設人工確認與可回復程序。操作紀錄需保留模型輸入、工具呼叫、畫面狀態、錯誤訊息及人工介入，方便追查故障來自模型判斷、環境變動、工具權限或任務定義。
Holo4 公布的評測能回答哪些問題？
基準分數能描述特定測試集、模型版本與執行設定下的結果，不能直接預測某家公司自有流程的成功率。比較前要先確認測試版本、任務集合、執行框架、成本算法與參照模型是否一致。
Hcompany 在發布文章中列出 OSWorld 2.0 與 AutomationBench 等結果，並說明不同模型的資料來自內部執行框架、公開排行榜或各自的模型卡；版本、測試子集和執行環境並不完全相同。
文章列出的 OSWorld 2.0 數字包括 Holo4 27B 的 61.7% 與 Holo4 35B-A3B 的 30.9%，同一比較中 Opus 5.5 為 81.8%。因此，不能只看參數較多或採用 MoE（Mixture of Experts，混合專家）架構，就推斷某個型號一定較適合特定任務；MoE 會依輸入由多個專家子網路分工處理，參數總量不等於每次操作都使用相同計算量。
還要留意基準名稱與版本。Holo4-27B 模型卡同時提及 OSWorld 與 OSWorld 2.0，列出不同分數；名稱相近，但測試集與版本不同，不能將兩項分數視為同一把量尺。成本圖表則混用 token（模型處理文字或輸出的計算單位）用量估算、API 價格與不同來源的數據，並非同條件的獨立實測。
「OSWorld 涵蓋真實網頁與桌面應用程式中的電腦操作任務，也包含跨應用程式工作流程。」這是 Xie 等人對 OSWorld 測試集的描述，該原始研究並未評估 Holo4；測試範圍越接近實際工作，不代表任一組織的軟體版本、資料與權限條件都相同。
公開操作軌跡提供另一種檢查方式。Hcompany 將其基準執行軌跡公開，包含動作、工具結果與畫面等資料；讀者可以抽查模型如何完成特定測試、在哪些步驟失敗，再判斷任務是否接近自己的工作。軌跡只能呈現被公開的執行內容，不能單獨證明資料治理、部署安全或整體適用性。
分數也需要配合「成功」的定義閱讀。代理可能完成大部分步驟，卻在最後一個儲存或提交動作失敗；另一個任務即使操作次數較多，仍可能正確達到目標。評估時要確認測試如何判定完成、是否允許重試、失敗是否有部分得分，以及成本是按單次嘗試還是成功任務計算。若比較對象的測試條件不同，應把差異列出，不宜把排名當成直接採購依據。
部署前要先盤點哪些整合與治理成本？
至少要確認權重或 API 的取得方式、授權範圍、運算與維運需求、環境相容性、資料權限、稽核紀錄與失敗接手流程。每個模型版本和服務條件都要分開查，不能由一個量化檔案或模型家族名稱推論全部版本相同。
Hugging Face 上的 Holo4-27B 模型卡對該模型卡所列版本標示 CC BY-NC 4.0，也就是非商業授權。這項限制不應直接推及所有 Holo4 版本；下載模型權重也不等於取得商業使用許可。其他模型版本、模型版本檔（checkpoint）、量化版本或託管 API 的條款可能不同，導入前要查核實際使用版本的授權、商業條款、資料處理方式與服務區域。量化（以較低精度儲存權重，降低運算需求）不會自動改變模型授權。
即使授權允許使用，自架仍要評估硬體容量、推論速度、更新與監控成本，API 則要納入請求費用、網路延遲、供應商服務調整和資料傳輸規則。兩種路徑都需確認系統能否操作目標桌面或瀏覽器，是否支援必要的工具，模型失敗時如何保留現況，以及新版本上線前如何回歸測試。這些工作會影響真實總成本，不能只以每次模型呼叫的價格估算。
安全設計要從操作權限開始。測試帳號與正式帳號分開，使用合成資料或去識別資料，將檔案、網站和命令列的存取範圍縮到任務所需。對於可能對外造成後果的按鈕，應設預覽或人工核准；發生錯誤時，能暫停流程、回復資料並還原權限。若操作軌跡包含敏感資訊，也要限制存取與保存期限，並明確規劃誰能調閱。
Hcompany 的公開軌跡可協助理解部分模型行為，實際部署仍需在自有環境做權限測試。應先定義停止條件和負責接手的人，再開放更多操作能力，將失敗限制在可處理範圍內。
哪些任務適合先做小規模驗證？
先挑步驟重複、輸入可控、結果能客觀檢查、失敗可以復原的任務。若結果難以驗證或錯誤代價高，先保留人工執行或只讓代理提供建議，不要直接授予正式環境的寫入權限。
OSWorld 原始研究以真實網頁與桌面應用程式設計任務，涵蓋檔案操作及跨應用程式流程。組織自行驗證時，還要把本地應用版本、內部資料格式、權限政策和例外情況納入。挑測試項目時，應先寫清楚輸入、預期結果、不可執行的動作和停止條件，避免測試中途才更改成功標準。
同一任務最好準備不同但合理的輸入，包括欄位缺漏、格式錯誤、頁面延遲和權限不足等情況。如此才能觀察代理遇到例外時會停下來求助，還是繼續執行並造成錯誤。測試次數也要足以暴露不穩定性，不能只挑一次順利完成的操作作為結論。若代理需要頻繁由人員修正，這些介入時間應列入總成本，與原有腳本或人工流程以相同任務量比較。
成本估算應納入模型或 API 費用、運算設備、框架維護、流程整合、稽核與人工覆核。長流程中的重試、修正和復原都會增加耗時。概念驗證要看端到端任務是否改善，以及改善幅度能否抵銷新增維護負擔。
- 選一項高頻、低風險的重複任務，準備隔離環境與測試資料。
- 先用唯讀或最小權限運行，確認每一步的畫面、工具呼叫和資料變化都能留下紀錄。
- 預先訂出成功條件、錯誤分類、人工介入方式及復原步驟。
- 多次執行同一批任務，記錄成功率、人工介入次數、完成時間、單次成本與錯誤後果。
- 比較代理、現有腳本和人工流程的結果，再決定是否擴大範圍或停止評估。
- Holo4 的差異在於同一代理能跨 GUI、程式碼、MCP 與 API 操作，價值取決於原流程是否真的有介面缺口。
- 基準與公開軌跡能提供檢查材料，不能替代自有環境的可靠性、授權和安全驗證。
- 先以隔離環境、最小權限和可復原任務測量成效，再評估更高風險的操作。
導入決策應回到流程本身：哪一步最耗時，模型能否可靠完成，結果是否容易核對，出錯後誰能接手。依測試指標決定是否擴大，才能看出代理是否解決實際問題。
「我們重建了執行框架，讓代理能在數百步的流程中管理上下文。」Hcompany 在發布說明中將長流程記憶和桌面端 shell 列為框架更新項目；這是開發者的設計說明，實際效果仍需在目標工作流程中測量。
常見問題
Q1: Holo4 是一個可以直接控制電腦的應用程式嗎？
Holo4 是 Hcompany 發布的代理模型系列。模型需要搭配執行框架、操作環境和工具權限，才能接收畫面、執行動作並讀取結果。
Q2: Holo4 的基準分數可以代表企業導入後的成功率嗎？
不能直接代表。測試版本、任務集、模型版本和執行框架都會影響分數，企業仍需用自己的流程與資料進行驗證。
Q3: Holo4-27B 可以免費商用嗎？
Hugging Face 上 Holo4-27B 模型卡所列版本標示 CC BY-NC 4.0，屬非商業授權；這項說明僅適用該模型卡所列版本。其他模型版本或服務條款應分別核對，商業使用前不可由此推定已獲許可。
Q4: 哪些工作適合先測試電腦操作代理？
可先選步驟固定、結果容易核對、失敗可復原的低風險任務，在隔離環境以測試資料和最小權限試跑。
