為什麼代理需要真實的螢幕。
對只填網頁表單的代理來說，瀏覽器沙盒就夠了。一旦工作跨進原生 App，沙盒就走到盡頭。真實桌面是最乾淨的代理執行環境：人用得到的，代理也用得到。
只活在無頭瀏覽器裡的代理，無法開啟 Final Cut、無法把影片檔從 Finder 拖進創作工具、無法在預覽程式中簽署 PDF、無法執行 .dmg 或 .exe 安裝程式、無法授予其他 App 螢幕錄製權限、無法用系統的檔案選擇器挑選檔案，也無法應付作業系統突然跳出的對話方塊。而大多數真實的工作流程，偏偏就發生在這些時刻，也是無頭瀏覽器代理悄悄失敗的地方。
虛擬化容器（各大實驗室的「代理電腦」模式）補上了其中一些缺口，卻也帶來自己的問題。映像檔通常是只預裝少數 App 的精簡 Linux 桌面，範圍之外的東西一律碰不到。容器和使用者實際的工作毫無連續性：他們安裝的 App、登入的帳號、儲存的檔案、授予的權限都不在其中。每次代理執行，都從一台不屬於使用者的空白機器開始。
Remio 的設計走另一條路。透過我們正在打造的執行環境連線的代理，會拿到使用者真實的桌面，也就是使用者實際工作的那台 Mac、PC 或 Linux 電腦，並使用人今天就在用的同一個遠端桌面連線。使用者安裝的每個 App 都在，登入的每個帳號都在，每個檔案也都在。代理不會是人工合成環境的住戶，而是使用者真實工作站上的訪客，使用者讓它待多久，它就待多久，一刻也不多。
代理將使用的管線，現在已為人類運作中。
Remio 使用者今天送出的每次點擊、按鍵與捲動，都已透過作業系統自己的原生輸入子系統送達主機，與實體滑鼠或鍵盤產生的事件完全相同。這條管線並非假設，它正是 Remio 此刻能在真實 Mac、PC 或 Linux 電腦上為人類運作的原因。而且並非巧合，它也正是代理執行環境會接上的基礎：沒有另外給代理用的 API，沒有注入視窗事件佇列的合成按鍵，也沒有用輔助使用墊片假裝真實的點擊。
設計承諾：如果推出，代理的輸入在主機端將與人類的輸入無法區分，因為它使用的是完全相同的管線，而不是另外為代理打造的平行管線。
這件事比聽起來重要，也是我們認為 Remio 的架構不只是方便、而是真正適合作為代理執行環境起點的原因。在應用程式層偽造輸入的代理平台，例如把合成按鍵塞進視窗的事件佇列，或用輔助使用 API 直接驅動介面元件，會不斷碰壁：受保護的欄位拒絕輸入、原生快速鍵誤觸、App 之間的拖放行不通、焦點管理混亂。對現在運作中的人類連線來說，走作業系統層級的輸入管線早已避開這一切。把它延伸到代理連線仍是我們要完成的設計工作，但做最困難部分的基礎已經在運作了。
依設計，權限邊界會原封不動地沿用。人類只需對 Remio Host App 授予一次的主機「輔助使用」與「輸入監控」權限，已經管控人類連線送出的每個輸入事件。我們的設計承諾是：代理連線將受同一份授權管控，代理不會有自己能持有的獨立權限，也不會有比人類已為該 App 打開的更寬的門。
螢幕存取，以及代理如何使用它的設計。
Remio 的螢幕擷取管線今天就已向人類用戶端串流主機的即時畫面：完整畫格、硬體編碼、即時傳送。代理執行環境還需要同一份資料的幾種形式：依需求的靜態擷取、較小的區域、對畫面內容的結構化讀取。這些額外的形式目前都還沒有出現在已推出的程式碼中。
今天已推出的是即時串流：主機的螢幕被持續擷取、以硬體編碼，並透過人類用戶端已在使用的同一條加密通道傳送。代理執行環境會把同一條管線重複用於自己的靜態擷取，也就是依需求取一個畫格，或只取模型已知該看的區域，而不是另外架一條獨立的擷取路徑。這種重複使用是我們已定案的設計選擇，並不是在宣稱今天已經存在。
對於處理文字比處理像素更擅長的代理，設計中構想了文字稿模式：以平台自己的 OCR（macOS 上的 Vision 框架、Windows 上的 Windows OCR API）產生畫面文字與其邊界框，而不是讓視覺模型參與其中。這部分完全還沒開發。它列在清單上，是因為它能讓代理把文字比對結果變成精準的點擊，而完全不必把畫格送給模型，如果我們做得好，這會是真正的效率提升。
為了取得最高保真度的結構化存取，設計中也構想了讀取焦點視窗的作業系統輔助使用樹，也就是螢幕閱讀器走訪的那棵樹：由按鈕、文字欄位、選單與角色組成的有標籤階層。這部分同樣尚未存在。而在我們構想的每個版本中，輸入管線的同一條規則都會沿用：代理連線看到的，與主機的螢幕錄製權限已允許人類連線看到的完全相同，不會更多。如果某個顯示器關閉了該權限，代理從那個顯示器什麼也拿不到，就和人類用戶端今天的情況一樣。
在撰寫代理程式碼之前，我們承諾的防護機制。
這些不是以後再做、再祈禱做得對的功能。它們是整個 Agent Runtime 設計在任何功能推出前都必須滿足的限制，並且現在就決定，趁著還沒有程式碼需要繞著它們設計。
每個 Remio 連線，不論是人或代理，都會以同樣的方式開始：由人掃描主機螢幕上顯示的 QR 碼，或在 Remio 中輸入裝置 ID 與 PIN。我們考慮的設計中，沒有任何一種讓代理建立自己的連線、持有可以悄悄更新的權杖，或在配對它的人決定結束之後延長存取。下一次代理執行時，需要人再配對一次，依設計，每次都是一個新的人機協作時刻。
代理連線進行期間，主機與用戶端都會顯示持續且明顯的指示，並提供可立即結束連線的「停止」控制，坐在主機鍵盤前的任何人都能使用，而不只是發起連線的人。代理採取的每個動作都會寫入人可以檢視的稽核記錄。這些在目前已推出的程式碼中都還不存在，它們是設計必須跨越的門檻。
權限邊界與上面輸入與螢幕的章節是同一個道理：代理連線繼承的，正是人類連線已遵守的主機作業系統層級權限，也就是「螢幕錄製」與「輔助使用」，不會更寬。它不會有自己的提升授權，也沒有途徑擴大人類已為 Remio App 設下的範圍。如果我們設計的某項能力放不進這個邊界，它就不會推出。
目前還沒有 SDK，以下是我們朝向的樣貌。
Remio 尚未發布代理 SDK、API 介面，或給代理的連線規格。我們有的，是設計不斷回到的一小串基本能力：輸入、螢幕存取、結構化介面讀取，以及承諾無論推出什麼，從第一天起都與模型無關。
我們不斷收斂到的樣貌刻意保持精簡：幾個輸入基本功能（一次點擊、一個按鍵），幾個視覺基本功能（一個靜態畫格、一個區域），以及一個結構化介面讀取。這是草圖，不是規格：沒有任何一項已推出，確切的介面也仍未定案。我們現在承諾的是樣貌，而不是語法。
與模型無關是設計要求，而不是以後才要達成的願望。無論規劃工作流程的模型是 Claude、GPT、Gemini，或是你自己執行的模型，推出的內容運作方式都一樣。我們不會圍繞單一廠商的工具呼叫格式來打造，因為一旦把執行環境鎖在某個模型的介面上，我們就許下了錯誤的承諾。
桌面執行環境與代理自己的執行環境是兩回事，我們打算讓它維持這樣。Remio 會是把代理的動作送上真實桌面的那一環；模型、規劃迴圈，以及它在哪裡執行，完全由打造代理的人決定。我們不打算自己代管、計量或管控模型的存取。
這個設計不是為了什麼而打造。
真實桌面執行環境適合某些代理工作流程，對另一些則不是。以下是簡短而誠實的取捨，即使在任何功能推出之前。
Remio 不是為只需要網頁瀏覽器的代理打造的，例如擷取網頁、填寫表單、閱讀儀表板。一整個遠端桌面連線超出一個瀏覽器分頁所需，而 Remio 並不想在那個類別中競爭。
Remio 也不是為需要幾十個用完即丟環境的代理打造的，每個任務一個、每次都是全新狀態、平行執行。Remio 圍繞持續的人類配對連線打造，這剛好是相反的形態：低並行、高連續性、真實的使用者情境。
如果我們依這一頁描述的方式打造 Agent Runtime，當代理需要擁有原生 App 的真實作業系統桌面、使用者實際安裝的軟體、使用者真實的帳號與檔案，以及人機協作的連線邊界時，它就是正確的答案。例如替身心障礙使用者操作桌面的輔助使用代理、在真實作業系統 App 上進行 AI 輔助的 QA，以及必須使用使用者已擁有的特定原生工具的代理式工作流程。任何「在我監督下，使用我真正的電腦和上面的一切」是自然說法的任務皆是如此。對這些情況，一旦推出，Remio 就會是那個執行環境。
關於我們正在設計的 Agent Runtime 的常見問題。
這個設計常引發的五個問題，以下是誠實的回答，包括誠實答案是「還沒有」的那些。
我今天可以用 Claude、GPT 或其他 AI 代理透過 Remio 控制我的電腦嗎？
代理可以在沒有人的情況下自行啟動 Remio 連線嗎？
主機如何知道連線的是代理而不是人？
代理能看到或觸及的範圍，會比人類連線更多嗎？
哪些 AI 模型能搭配 Remio 的 Agent Runtime？
今天已實現：為你打造的快速、私密桌面。即將推出：同樣的桌面，給你的 AI 代理。
安裝 Remio，用最快、最私密的方式連上你自己的 Mac、PC 或 Linux 電腦：原生輸入、原生螢幕存取、端對端加密，無需帳號。這一頁描述的 Agent Runtime 尚未推出，我們也不承諾日期，但同樣的架構正是我們認為它值得打造的原因。