同時開三個 AI 編程 agent，審批全推到手機上點：Railse 解決的是「排隊等按鈕」這件小事
一則張貼在 V2EX「分享創造」板的作品展示，這幾天在開發者社羣裡引起討論。作者描述的情境很多人不陌生：同時開著 Claude Code、Codex 和 Gemini CLI 三個 agent 寫程式，agent 本身跑得很好，麻煩的是它們每次要跑命令、改檔案都得停下來等人按「允許」。三個終端機輪流切換，切到的時候它往往已經等了十分鐘；出去喫頓飯回來，每個都停在第一條 git push 上。全部放行（俗稱 yolo 模式）又不敢，一句 rm -rf 出去就沒有後悔藥。
作者於是自己寫了 Railse，開源，採 Apache 2.0 授權，目前版本 v0.1.2。
它實際上做了什麼
Railse 的核心思路可以用大樓門禁來比喻：三家 CLI 工具原本各自有一個警衛亭，訪客（每條命令）要分別排隊簽名。Railse 把三個警衛亭的線路都接到同一個總機，規則統一寫一套，總機判斷不了的才轉給住在手機裡的你。
運作方式分成三層。第一層是接入：三家 CLI 的權限鉤子（hook）都接到本機的一個守護行程。第二層是風險分檔：只讀操作和修改專案內檔案的命令直接放行；涉及對外連線的如 curl、npm install，對外發佈的如 git push、deploy，以及不可逆的如 rm -rf、git reset —hard，一律要問。第三層才是手機：定不了的請求透過 Web Push 推到手機，點開批準或拒絕。批準時可以勾「記住」，當場存成規則，下次同類操作不再問。
有一條設計值得特別注意：對外和不可逆的操作永遠不能被「記住」放行，只能自己手寫規則。等於說系統替你守住了那條最不能自動化的底線。
失效設計：掛了也不卡 agent
工具類軟體最怕的就是「我為了省麻煩裝了你，結果你變成新的麻煩」。這一點 Railse 處理得頗務實：守護行程沒起來，或者 hub 連線超過 30 秒不通，CLI 會直接彈出自己的審批框。最壞情況就是回到沒裝 Railse 的樣子，agent 不會因此卡死。
部署門檻也壓得很低。hub 是單一個 Go 執行檔，官方提供 Fly.io 的現成設定；手機端網頁由 hub 直接託管，不用另外部署。命令裡認得出來的 token 和密碼，會在本機先換成
已知限制要誠實看
作者自己列出的限制清單，比功能清單更有參考價值。Gemini CLI 的鉤子只能拒絕、不能放行；Codex 的鉤子只在互動式 session 裡生效；iPhone 要把手機網頁加到主畫面才能收到推送；hub 目前是單機 SQLite，還談不上多人共用。v0.1.2 加上「我自己在用」，意思就是這是一個個人工具的公開化，不是成熟產品。
所以呢：誰該看這個專案
同時跑多個 agent 的開發者，痛點是真實的：審批排隊喫掉的時間，可能比 agent 省下的時間還多。Railse 把「等按鈕」變成「手機推播順手點一下」，等於把監督工作從專注模式搬到了碎片時間。
更大的訊號在於工作流集中化這個方向。先前 把二十九個編程 Agent 收進同一個桌面面板的 Casbin Gateway處理的是供應商切換與流量管理，Railse 處理的是權限審批，切入點不同，但都假設了同一件事：開發者桌上同時有多個 agent 已經是常態，而每個工具各自為政的雜務，正在成為新的整合需求。
作者在文末徵求兩種回饋：你同時開幾個 agent 時怎麼處理審批；以及規則表判錯的案例，直接到 GitHub 專案頁開 issue。如果你正好在三個終端機之間來回切換，這個 issue 板或許比功能本身更值得先看一眼。