Terminator：把 Windows 桌面自動化寫成確定性程式碼，AI 只負責收拾殘局
playwright for windows computer use
秒懂
- 它是什麼？
- Terminator 是 mediar-ai 以 Rust 開發的 Windows 桌面自動化工具，透過 MCP 讓 Claude、Cursor 等助理操作整個桌面。它的核心主張是把流程預先編譯成確定性程式碼，只在失敗時才呼叫模型。本文說明它的機制、安裝方式、只支援 Windows 的硬限制，以及什麼情況下你該改用 Playwright。
- 適合誰用？
- 如果你的自動化場景綁定在 Windows 桌面應用上，而且流程本身固定、只是偶爾會因介面變動而失敗，Terminator 的確定性執行加 AI 復原這個組合值得評估。若你的目標其實是網頁，Playwright 在跨平台與 CI 環境上更成熟，不需要為此引入一個只跑 Windows 的執行層。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 106 天前。
- 用什麼語言寫的？
- 主要是 Rust（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是「桌面應用沒有 API」這件事
多數自動化工具假設目標有介面可打：HTTP endpoint、CLI、資料庫連線。但企業內部大量流程卡在沒有 API 的桌面程式上，例如只能靠 GUI 操作的內部系統、舊版 ERP 客戶端、需要人工點選的安裝精靈。這些流程過去要嘛靠人重複做，要嘛靠傳統 RPA 錄製腳本，而傳統 RPA 的維護成本往往高到讓專案最後被放棄。
Terminator 的定位就是把這一層補起來。README 開頭寫得很直白：「Give AI assistants (Claude, Cursor, VS Code, etc.) the ability to control your desktop and automate tasks across any application.」它要面對的使用者是已經在用 AI 助理寫程式的開發者，而不是想找無程式碼 RPA 平台的操作人員。README 列出的使用案例也反映這一點：在 GCP 開一台新執行個體再用 CLI 連上去、去 Vercel 查 log 找出最常見的錯誤、根據最近的 commit 測試應用新功能。這三件事的共同點是它們橫跨瀏覽器與終端機，單一工具做不到。
值得注意的是專案在 README 中對自己的定位用詞是「playwright for windows computer use」，這個比喻抓住了重點：它想當的是執行層，不是決策層。決策交給模型，執行交給確定性的程式碼。
確定性執行加 AI 復原：機制與資料流
README 對效能的說法需要小心閱讀。它寫「Runs 100x faster than ChatGPT Agents, Claude, Perplexity Comet, BrowserBase, BrowserUse」，並補上一句關鍵說明：「We achieve this by pre-training workflows as deterministic code, and calling AI only when recovery is needed.」也就是說，速度優勢不是來自更快的模型推論，而是來自大部分步驟根本沒有模型參與。流程被預先訓練成程式碼後，執行時是 CPU 速度，模型只在步驟失敗時被叫進來判斷怎麼救。
這個設計的好處是成本與延遲都可預測：成功路徑上沒有 token 消耗，也沒有網路往返。代價是流程必須先被「訓練」出來，而 README 提到的途徑是 Workflow Recording，錄製人類操作後轉成確定性自動化。README 在 08/25 的更新紀錄裡寫到「OS event recording → YAML generation in MCP」，表示錄下來的作業系統事件會產出 YAML 工作流程。這條路徑的含義是：Terminator 不適合一次性、探索性的任務，它適合會被重複執行很多次的流程。
元素定位方面，README 說它「Works across all dimensions - pixels, DOM, and Accessibility tree」。三種定位方式並存是有意義的：Accessibility tree 最穩定但依賴應用有正確實作；DOM 只在瀏覽器情境下有效，需要 Chrome 擴充功能；像素層是最後的退路，也最容易因解析度或主題變動而失效。README 沒有說明三者在執行時如何排序或回退，這部分無法從現有材料確認。
另外 README 聲稱「Doesn't take over your cursor or keyboard - runs in the background without interrupting your work」，以及瀏覽器情境下「Uses your browser session - no need to relogin, keeps all your cookies and auth」。後者對需要登入的內部系統是實質優勢，因為它避開了自動化腳本最常卡住的登入與驗證流程。
安裝：一行指令或一段 MCP 設定
Terminator 的主要入口是 terminator-mcp-agent，透過 npx 執行，不需要先編譯 Rust。Claude Code 的使用者可以一行解決：
claude mcp add terminator "npx -y terminator-mcp-agent@latest"
其他用戶端（Cursor、VS Code、Windsurf）則是在 MCP 設定檔加入：
{ "mcpServers": { "terminator-mcp-agent": { "command": "npx", "args": ["-y", "terminator-mcp-agent@latest"], "env": { "LOG_LEVEL": "info", "RUST_BACKTRACE": "1" } } } }
兩個環境變數值得說明。LOG_LEVEL 控制日誌詳細程度，排查定位失敗時會用到。RUST_BACKTRACE 設為 1 會在底層 Rust 執行層panic 時印出回溯，這對回報問題有幫助，因為 MCP agent 只是外殼，真正做事的程式碼在 Rust 端。
README 另外提供 Windows 安裝檔下載連結，指向 cdn.crabnebula.app 上的 windows-x86_64 版本，以及指向 app.mediar.ai 的 macOS 入口。這裡有個容易混淆的地方：README 的功能支援表明確寫「Terminator currently supports Windows only. macOS and Linux are not supported.」，macOS 欄位全部是 No。app.mediar.ai 是 Mediar 自家的託管服務入口，不是 Terminator 本身支援 macOS。
函式庫方面，Python 綁定是 terminator.py，安裝指令為 pip install terminator，README 標示支援程度為 Partial。TypeScript 綁定是 @mediar-ai/terminator，安裝指令 npm i @mediar-ai/terminator，標示為 Yes。Rust 端則發佈在 crates.io 上，套件名稱為 terminator-rs 與 terminator-workflow-recorder。
只支援 Windows 不是疏忽，是設計邊界
功能支援表把 macOS 與 Linux 全部標為 No，包括元素定位、UI 動作、應用程式管理、視窗管理、瀏覽器自動化、工作流程錄製、多螢幕管理、螢幕與元素擷取。這不是「還沒做」，而是整個執行層建立在 Windows 的無障礙與視窗 API 之上。如果你需要跨平台，這個專案在架構層面就排除了你，不是等一兩個版本就能解決的事。
第二個限制是維護成本。從釋出紀錄看，v0.24.30 到 v0.24.32 之間大約每兩到三週一個版本，v0.24.32 在 2026-04-05，而最後推送時間是 2026-06-02。這種節奏對早期採用者是好消息，表示專案活躍；但對已經把自動化流程上線的團隊意味著你必須決定要不要跟著升。桌面自動化腳本對底層定位邏輯的變動特別敏感，一次升級就可能讓原本穩定的選擇器失效。
第三個限制與 Chrome 擴充功能有關。README 說瀏覽器自動化需要擴充功能，而「Uses your browser session」這個賣點同時也是風險：它依賴你本機既有的瀏覽器設定檔與登入狀態。在受管理的企業環境裡，能不能安裝擴充功能、能不能讓自動化程式存取既有 profile，取決於 IT 政策，不是技術問題。
還有一點要說清楚：README 裡的「>95% success rate」與「100x faster」都是專案方的宣稱，沒有附帶測量方法、測試集或環境描述。這類數字在評估時只能當作方向性參考。
Playwright 與 Terminator 走的是兩條路
最直接的替代方案是 Playwright。兩者的差異不在功能多寡，而在作用範圍與執行模型。
Playwright 驅動的是瀏覽器引擎本身，透過 DevTools Protocol 與各家瀏覽器通訊。它不需要你的桌面、不需要 Accessibility tree、不需要像素比對，也不需要你在機器上先登入好。它可以在無頭模式下跑在 Linux 容器裡，這是 CI 環境的標準做法，也是它最大的優勢。代價是它只能碰瀏覽器裡的東西。要開 GCP 執行個體、要操作原生 Windows 應用、要讀取本機檔案總管，Playwright 一概做不到。
Terminator 走的是作業系統層。它操作的是整個桌面，瀏覽器只是其中一個視窗。這讓它能處理跨應用流程，但也讓它綁死在 Windows，並且難以容器化。在 CI 裡跑 Playwright 是常態；在 CI 裡跑一個需要互動式桌面工作階段的工具則完全是另一回事。
如果你的流程全部在網頁上，選 Playwright，不要為了「AI 可以自己修復」這種可能性去承擔一個只支援 Windows 的執行層。如果你的流程橫跨桌面應用與瀏覽器，或者目標系統根本沒有網頁版，那 Playwright 幫不上忙，Terminator 這類工具才有存在理由。
授權方面兩者都是 MIT，這點沒有差異。
授權與升級成本：MIT 給的自由與它不保證的事
Terminator 採 MIT 授權。README 對此的表述是「MIT-licensed - fork it, ship it, no lock-in」，意思是你可以修改、商用、閉源散布，只要保留著作權聲明與授權條款。對想把自動化層嵌進內部產品的團隊，這比多數 RPA 廠商的商業授權寬鬆得多。
但 MIT 也意味著沒有保固。專案方不承諾任何特定行為、穩定性或後續支援。README 裡提到的「managed hosting」與 Mediar 的託管服務是另一條商業路徑，與 MIT 授權的開源程式碼是分開的兩件事，兩者關係在現有材料中沒有進一步說明。
升級成本主要來自兩個地方。一是 Rust 執行層與 MCP agent 的版本綁定：npx 指令用的是 terminator-mcp-agent@latest，這表示每次啟動都會拉最新版，你可能在毫無預警的情況下換到新版行為。在正式環境裡應該把版本釘死，而不是跟著 latest 跑。二是工作流程的格式。README 提到 YAML 工作流程與 OS 事件錄製產出 YAML，這類格式在專案早期階段有變動的可能，錄製好的流程在升級後是否需要重新產生，材料中沒有說明，這是採用前應該實測確認的項目。
本文未實際安裝或執行此專案，上述行為描述均來自 README、功能支援表與釋出紀錄。
編輯結論
如果你的自動化場景綁定在 Windows 桌面應用上，而且流程本身固定、只是偶爾會因介面變動而失敗，Terminator 的確定性執行加 AI 復原這個組合值得評估。若你的目標其實是網頁，Playwright 在跨平台與 CI 環境上更成熟，不需要為此引入一個只跑 Windows 的執行層。若你需要 macOS 或 Linux，這個專案目前直接排除你，README 的功能表在兩者欄位全部標示 No。動手前先確認三件事：你的 Windows 版本與目標應用是否落在 Accessibility tree 可讀的範圍內；Chrome 擴充功能是否能裝進你的企業受管瀏覽器；以及 v0.24.x 的版本節奏下，你能否承擔跟著升級的成本。
社群筆記