Simlock 讓 AI 代理各用一台模擬器：從搶裝置到可回收的手機測試租約
Simlock 用裝置租約協調 AI 代理的 iOS、Android 測試。看懂排隊、TTL 續租、Gateway 與環境條件，以及為何獨占仍需要代理遵守規則。
如果兩個 AI 代理同時在一台 Mac 測試手機 App，它們可能各自選到同一台模擬器，接著把對方的版本覆蓋掉。Simlock 想解決的就是這種資源衝突。
測試於是像隨機失敗：程式未必有錯，裝置卻在測到一半被另一個工作重設，讓代理一直修改原本正常的程式。
Callstack 的 Szymon Chmal 於 2026 年 10 月 30 日介紹開源工具 Simlock，讓代理先申請一份裝置租約，再開始操作。
租約把裝置交給當下的使用者，忙碌時排隊，結束後清理，因此把彼此搶資源的問題變成可以追蹤的等待。
但這份獨占靠代理遵守操作規則。Simlock 不會阻止其他程式直接控制模擬器，也沒有把本機變成強制隔離的雲端服務。
對已在並行跑行動測試的團隊，先把裝置分配好，比再加一個代理更有用，而租約正是整個流程的起點。
Simlock 的租約，如何避免代理搶同一台裝置？
租約是裝置的使用權紀錄，讓代理知道自己目前可以操作哪一台。Simlock 官方介紹以 iOS 模擬器與 Android 模擬器為主要用途，也支援納入實體裝置。
代理可以指定平台、裝置型號與作業系統版本。若符合條件的裝置有空位，就取得已啟動並檢查過的裝置，接著沿用回傳的識別資料執行測試。
如果沒有空閒裝置，工具會在機器容量允許下建立新的裝置。容量已滿時，請求進入佇列，等其他工作結束後才繼續，因此更多代理不會直接變成更多可用硬體。
這個安排把等待原因明確化。代理可以知道自己仍在排隊、建立或啟動裝置，避免把還沒取得測試環境，誤判為 App 無法開啟。
釋放後，模擬器會被清理再交給下一個工作。清理可能還需要數十秒，所以釋放命令返回，也不等於下一台裝置已經立刻準備完成。先前安裝的 App、檔案與設定會消失，因此測試所需資料必須由自己的流程重新準備。
獨占成立的前提，是都使用租得的裝置
官方特別說明，租約管理不會隱藏系統中的其他模擬器，也不會封鎖直接執行 xcrun simctl。它協調的是使用順序，沒有提供作業系統層級的強制隔離。
如果其中一個代理仍從系統清單隨意挑裝置，另一個代理即使持有租約，也可能受到干擾。所以接入時要把「只操作租約回傳裝置」寫進代理工作指引。
排隊也能設定等待上限。官方提供逾時離開與立即失敗的選項，因此對有固定執行期限的測試，應先安排可等待多久，免得整批工作都在等同一個空位。
但中止等待命令不等於取消排隊。官方文件指出，某些情況下請求仍會留在佇列，稍後取得裝置並持有到租約期限，所以使用者應透過請求狀態確認，不要只看終端視窗已經關閉。
這個差別在持續整合中特別實際。若工作因為總時間到期被停止，設備端可能稍後才分配成功，下一批工作就會看到看似有人占用。保存請求與租約識別資料，才能把這種延遲取得與真正仍在執行的測試分清楚。
裝置分配能成立，還取決於每個代理都沿著租約操作。接著才是讓機器具備真正啟動裝置的條件。
Introducing Simlock: a free, open-source tool that turns your machine into a simulator cloud that manages itself, so every coding agent gets its own iOS or Android device, simulator or real phone.https://t.co/iymaqe5TVp https://t.co/tYqWufpgUb pic.twitter.com/fxJtaXUk68
— Szymon Chmal (@ChmalSzymon) October 30, 2026
先檢查哪個環境，才能真的拿到裝置？
工具管理的是既有機器與平台程式，因此安裝成功不代表 iOS、Android 環境都已就緒。官方要求 Node.js 22.13 或更新版本，這是執行管理程式需要的環境。
iOS 測試仍要在具備 Xcode 的 Mac 上進行，Android 則需要 Android SDK 等平台工具。SDK 是開發與執行平台功能的工具集合，Simlock 不會把這些需求變成可省略的步驟。
依官方安裝指引，可先安裝命令列工具，再用 simlock doctor 檢查機器。它會指出哪個平台缺少工具，讓只做 iOS 的人不必把所有 Android 提醒都當成阻擋。
管理裝置的背景程序稱為 daemon，會在第一次需要時啟動，資料與設定保存在 ~/.simlock。官方沒有把它註冊為登入電腦時自動啟動的服務，因此不用先另外維護一套開機程序。
如果後來才安裝 Xcode、Android SDK 或 JDK，就要停止背景程序後重新檢查。因為平台工具是在程序啟動時偵測，裝好檔案不代表已在執行的程序立刻看得到。
Doctor 的修復選項也有範圍。--fix 會整理 Simlock 內部紀錄，例如已不存在的裝置或過期卻仍標示有效的租約，但不會代替使用者安裝開發工具。
這讓環境修復和租約修復能分開處理。若缺的是平台工具，就先補齊工具，若是紀錄與現況不一致，再處理管理資料，避免用錯方式反覆重試。
環境準備好後，下一個問題就變成租約要跟著哪個程序活多久。這會直接影響代理能否在多個測試步驟之間持續使用同一台裝置。
常駐、分離與 TTL，怎麼避免測到一半被收回？
一般租約命令會持續運作，替使用者續租，並在正常結束時釋放裝置。TTL 是租約有效時間，超過期限又沒有續租，系統就能把裝置回收，避免代理意外停止後永遠占用。
官方租約文件列出的預設時間為十五分鐘，單次請求最長四小時，管理員可以調整。常駐命令會每隔約三分之一租約時間續租，因此正常工作不必每幾分鐘重新搶裝置。
但許多代理每次執行命令都開一個新 shell，命令結束後它就消失。Shell 是執行命令的工作程序，如果租約跟著這個短命程序，裝置可能剛分配就被釋放。
短命命令應如何保持租約
這時可用 --detach 讓命令印出租約後離開，留下租約供後續步驟使用。不過使用者或代理就要自行安排續租與釋放，否則測試太久仍會過期。
另一種方式是用 --bind-pid 指向代理本身持續存活的程序，讓租約跟著整段工作。這適合測試會跨多次命令，但仍有一個明確工作生命週期的情況。
釋放要使用自己的租約識別碼。release --all 會結束整台機器上的租約，連別的代理也會受影響，因此不能把它當成一般工作結束時的清理方式。
斷線與正常退出也不同。官方文件指出，若背景程序連線中斷，租約可能仍保留到期限，並能在重新連線後續租，不能只因為目前看不到命令輸出，就認定裝置已經空閒。
因此要把租約識別碼、到期時間與工作狀態一起留下。這些資料能讓接手者知道應續租、釋放，還是重新申請，也避免把環境變動誤判為程式錯誤。
代理若每次換一個短命 shell，就應選擇明確續租的方式。租約能保持之後，還要確認多人與子代理是否被辨識成同一位使用者。
多人與子代理共用時，使用者識別為何重要？
租約管理用 requester 識別持有人，因此代理名稱的安排會影響是否能同時取裝置。預設每個 requester 同時只能持有一份租約，或有一個等待中的請求。
在 Claude Code、Codex 的同一個工作階段裡，子代理共用同一份工作識別。因此派出更多子代理，不一定會各自得到一台裝置，因為它們可能仍被當成同一個租用者。
其他啟動方式則可透過 SIMLOCK_AGENT_ID 明確指定。若兩個獨立工作使用相同值，它們就會共用身分，反而無法達到原本期待的裝置分工。
透過遠端 HTTP 使用時，持有人則由存取權杖辨識，而非請求文字自稱的名稱。因此多人共用入口也要配合管理員核發的權限，不能只靠代理把自己換一個名字，就當成新的合法使用者。
相反地，沒有設定持續身分時，每次命令也可能變成不同的 requester，讓一人一租約的限制無法跨命令生效。因此，身分設定應對應實際工作，而不是只求通過一次申請。
實務上可以讓同一項功能的安裝、畫面操作與結果檢查共用一份租約。另一個真正獨立的功能測試再用不同身分，讓裝置使用順序與測試責任能一一對上。
本機命令列連線具有管理員權限，可以處理其他租約，所以這也不能當成不同租戶之間的安全保證。多人共用設備仍需要自己的帳號、存取與操作管理方式。
同一台機器能協調之後，才需要考慮把裝置池延伸到其他機器。Gateway 就是用來處理這個階段。
Gateway 怎麼把多台機器接成一個裝置池？
Gateway 提供單一入口，但真正執行裝置與存放檔案的仍是各個 worker。Worker 就是實際擁有模擬器、平台工具與裝置的工作機器。
依Gateway 官方文件，代理只需向同一個網址申請，Gateway 再選擇能服務的機器。Worker 主動向 Gateway 連線，因此不必每台都開放外部進入的連接埠。
Gateway 本身沒有裝置，也不需要 Xcode 或 Android SDK。這讓管理入口和實際測試能力分開，擴大時可以增加工作機器，而不用改掉代理對外使用的入口。
不過遠端檔案路徑指的是 worker 上的位置。代理在自己的機器上剛編好的 App，不會因為透過 Gateway 操作，就自動出現在執行裝置的另一台電腦。
因此安裝前要先讓產物到達正確的 worker。否則「找不到檔案」可能只是跨機器的交接問題，與 App 能不能在手機上運作無關。
作業系統映像也要事先準備。Gateway 不會在核發租約時替所有 worker 下載缺少的版本，所以需要某個 iOS 或 Android 版本，應先確認池子裡真的有對應環境。
如果單台機器已能容納所有測試，就沒有必要先加 Gateway。多一層路由不會增加那台機器的記憶體與可用容量，卻會多出連線、權限與檔案交接的管理工作。
所以擴大容量的同時，也要讓 App 檔案、系統映像與存取權跟著正確機器準備。容量足夠後，才能進一步看工具是否減少了測試干擾。
哪些測試適合接入，怎麼判斷導入是否有效？
Simlock 最直接的用途，是把可重複的裝置測試從互相干擾改成可追蹤的排程。已經並行跑功能測試或持續整合的團隊，比單次手動開 App 更容易遇到它處理的問題。
可以先挑兩項原本可能搶同一裝置的測試，分別記下申請、取得、安裝、完成與釋放的時間。如果錯誤發生在裝置尚未取得，就先查容量與等待，而不是修改產品程式。
如果裝置取得後畫面仍不對，再看是否安裝了正確版本、是否使用租約回傳的裝置，以及測試資料是否完整。把這些原因分清楚，才能知道協調機制是否有效。
工具提供命令列、MCP、HTTP 與程式用戶端等入口。MCP 是把工具提供給代理呼叫的通訊方式，官方提供列出、租用、釋放、查狀態四種操作，仍要配合代理自己的工作流程。
原始碼採 MIT 授權，硬體與服務費用則要另外計算。自有 Mac、實體手機、遠端機器與代理訂閱，仍可能是團隊的主要支出。
若代理仍繞過租約直接控制其他裝置，就應先修正使用方式，再談增加並行數。讓測試結果對得上明確的一台裝置，才有基礎判斷 App 本身是否正常。
延伸閱讀：Claude Code 2.1.314 加入寫入目錄限制：讓代理改檔前，先畫清楚工作範圍
延伸閱讀：Factory Delegations 正式開放：從 Slack、Linear 派工作給 Droid，權限與審查怎麼設？
常見問題
Simlock 會替我提供免費的雲端手機嗎？
Simlock 協調的是你自己準備的模擬器、實體裝置與工作機器。開源工具可免費取得，不代表硬體、雲端運算或代理帳號不用付費，也不能把 Gateway 當成代管設備服務。
租約結束後，測試資料還在嗎？
模擬裝置釋放後會清理，供下一位使用者重新開始。因此需要留存的截圖、日誌與測試結果，應在釋放前保存到工作流程指定的位置，避免只能靠裝置上的暫存資料判讀結果。
一個人使用，需要先架 Gateway 嗎？
如果一台機器已有足夠裝置與容量，可以先用單一 worker。只有跨機器、持續整合或需要共用裝置池時，再考慮 Gateway，會比較容易分清楚問題來自哪一層。
如果你想追蹤 AI 代理如何接進實際開發與測試，歡迎免費訂閱 AI 郵報。
