GetRun 桌面 App 與 API Key，應該由哪個開始？
按任務、權限與驗收方式，選擇 GetRun Harness、現有 AI 用戶端或直接 API 整合，完成最小可用驗證。
先看你要完成的工作。GetRun Harness 提供用於 Agent 任務的桌面工作區；API Key 用來連接現有用戶端或自己的程式。兩種方式可配合使用，但設定位置、權限範圍與檢查結果的方法不同。
需要圍繞本機專案互動時，先試桌面 App
如果你想選擇專案目錄，在會話中描述任務，並查看 Agent 使用了哪些檔案與工具，可以先試 GetRun Harness。整理本機筆記、圍繞專案逐步完成任務，都方便直接檢查最終檔案。
安裝適合操作系統的版本，以帳戶登入或手動填寫 Key 連接，再選擇工作區與目前 Key 可用的模型。開始前確認執行模式及檔案權限。Browser Use 與 Computer Use 是獨立設定，任務確實需要時再啟用。
- 需要工作區與對話介面。
- 有人能檢查操作並驗收生成的檔案。
- 任務依賴本機上下文，而非只有一段獨立問題。
已慣用某個用戶端時，先設定 API Key
如果工作已在某個編程工具或受支援的用戶端中進行，優先閱讀該用戶端的接入文件。通常需設定 Key、接口地址及準確的公開模型識別碼。不同用戶端對協定與地址有不同要求，照搬另一個工具的設定，可能到首次請求才發現不相容。
在現有 GetRun 帳戶控制台建立 Key，按相應指南儲存設定，再傳送「只回覆 OK」這類小請求。確認回應後查看用量，再開始較大的任務。官網域名並非模型 API 地址，應使用用戶端文件提供的接口地址。
- 使用目標用戶端專屬的設定指南。
- 從目前模型目錄複製識別碼，不按顯示名稱猜測。
- 截圖、儲存庫與共享日誌不要包含完整 Key。
由自己的程式控制流程時，採用直接 API 整合
當業務程式需要構造請求、處理回應及決定呼叫時機，直接 API 整合較合適。同時，錯誤處理、使用者看到的狀態及憑據儲存亦由你的程式負責。Key 應留在可信伺服器端，不要嵌入公開瀏覽器程式碼。
按具體操作閱讀 API 參考；如使用串流回應或工具相關欄位，也要核對相應契約。相容性需針對接口與模型組合驗證，不能假定所有用戶端選項都可用。先測試一條完整成功請求與一個錯誤分支，再設計較長的自動化流程。
用一個最小實驗作決定
需要人工驗收本機檔案，就做一個桌面任務；已有成熟用戶端，就驗證一次設定；要做產品功能，就實作一次伺服器端呼叫，清楚顯示成功或失敗。先證明它能協助完成目前工作，再決定是否遷移更大範圍的流程。
目前 get-run.com 提供產品介紹、下載、指南與文件；登入、Key 管理及充值仍由 get-apikey.com 承接。沿網站帳戶入口存取即可，行銷域名改變不會建立另一份餘額或另一個模型 API 服務。
- 最後在哪裏驗收：檔案、用戶端，還是自己的應用？
- 誰控制工具權限與重試？
- 擴展任務前，能否查看首次呼叫的實際用量？
三個選擇例子
整理五份本機專案筆記 → 從 Harness 工作區開始。 繼續使用現有編程用戶端 → 按相應指南設定 API Key。 為自己的服務加入模型功能 → 實作伺服器端 API 請求與明確的錯誤處理。