讓 Agent 安全操作主力電腦的方法
用風險分區、單步交易、熔斷條件與可直接使用的提示詞，在保留 Agent 自主性的同時降低系統死機風險。
讓 Agent 安全操作主力電腦的方法
讓 Agent 有足夠自由度，可以大幅提高開發、測試與整理速度；把所有操作都改成逐項詢問，通常只會增加確認疲勞，最後反而讓真正危險的操作被習慣性允許。
比較有效的方法不是「全面限權」，而是依影響範圍分區：專案內工作維持自主，跨出專案、進入使用者登入環境或系統服務時，才要求更強的證據、回復方案與停止條件。
這套方法來自 Technical/kainnne lumareader/03_macos_launchservices_incident_20260902。該事件顯示，最危險的不是單一命令，而是核心服務已出現異常後，Agent 仍連續嘗試不同工具、疊加設定與快取變更。
先建立三個操作區域
| 區域 | 常見操作 | Agent 自主性 | 必要條件 |
|---|---|---|---|
| 綠區：專案內 | 讀程式、改 source、執行測試、建立可刪除的 build、檢查 Git diff | 高；可直接完成 | 不跨出指定 repository，不碰私人資料與外部發布 |
| 黃區：可回復的使用者層 | 安裝一個 App、修改單一 App 偏好、開啟 GUI 驗證、操作指定的使用者檔案 | 中；先說明再做 | 明確目標、精確路徑、備份或撤回方式、一次一項 |
| 紅區：主機系統層 | 系統服務、登入環境、預設 handler、LaunchServices、Finder／圖示快取、Keychain、TCC、launchd、網路與全域套件 | 低；必須另行確認 | 先唯讀診斷、證明回復路徑、設定熔斷點，最好改在測試帳戶或可還原環境 |
分區的重點是爆炸半徑，不是命令看起來是否簡單。defaults write、killall 或一個很短的 Swift script 都可能比數百行專案程式碼更接近紅區。
授權不等於安全判斷
使用者說「幫我設成預設程式」，授權的是成果，不代表 Agent 可以自行：
- 直接改寫整個 LaunchServices handler 資料。
- 清除全域或使用者層快取。
- 反覆停止、重啟系統服務。
- 安裝另一個工具繞過已失敗的方法。
- 在同一個登入帳戶中同時留下相同 Bundle ID 的多份 App。
Agent 仍需選擇最小影響手段。若安全方案需要新的權限或擴大範圍，必須把它視為新的決策點，而不是原始授權的自然延伸。
系統層操作要像交易，不要像試誤
每一輪只允許一個可辨認的狀態改變：
盤點目前狀態
→ 保存原值與回復方法
→ 執行一項精確變更
→ 驗證預期結果與非預期副作用
→ 成功才進下一項；失敗先回復，不疊加第二種修法
執行前
Agent 應回答六件事：
- 目標結果是什麼？
- 會改到哪些明確檔案、App、服務或偏好？
- 影響只在專案、單一使用者，還是整個登入環境？
- 原始狀態保存在哪裡？
- 如何證明變更成功，而不只是命令回傳 0？
- 發生什麼現象時必須停止？
執行中
- 一次只做一個變更，不用長命令串起多個副作用。
- 紀錄開始時間、命令、PID、輸出與被改動的目標。
- 命令超過合理時間時先視為異常，不直接再跑一次。
- 驗證應包含真實使用行為，例如實際開啟測試文件，而不只讀偏好檔。
執行後
- 比較執行前後狀態。
- 檢查 Finder、登入環境、相關 App 與系統服務是否仍正常。
- 清楚列出已完成、未完成及仍存在的風險。
- 只在前一步穩定後才繼續下一個系統變更。
必須寫進任務的熔斷條件
發生下列任一項，Agent 應立即停止所有同子系統的寫入操作：
- 系統 API、服務或命令超過預估時間仍未完成。
- 同一操作留下未知、殘留或重複程序。
- Finder、System Settings、背景 App 或登入環境開始異常。
- 實際驗證結果與偏好檔、命令輸出互相矛盾。
- 需要從「設定偏好」升級為「清快取、重啟 daemon、重建資料庫」。
- 已經嘗試一種方法失敗，下一步只是換另一個工具做同一件事。
- 無法明確說出 rollback 是否仍有效。
熔斷後允許 Agent 繼續做的事情只有：保存輸出、唯讀診斷、整理已發生的變更、提出回復選項並等待決定。不能因為工具有權限就自動突破熔斷。
保持自由度的關鍵：限制升級，不限制正常工作
一份好的安全規則不應要求 Agent 在每次讀檔、測試或修改 CSS 前都詢問。可以採用以下分工：
- 在綠區，Agent 依既有專案規則自主完成實作與驗證。
- 黃區只需要一次針對明確步驟的說明與同意，不為同一個低風險步驟反覆詢問。
- 紅區不是全面禁止，而是先提出小型變更計畫、備份與 rollback；使用者同意後執行一項，再回報結果。
- 從黃區升級到紅區時必須重新說明，不能沿用先前的一般授權。
- 熔斷只停止故障子系統；不相關的唯讀分析與專案內工作仍可繼續。
這樣保留了 Agent 在熟悉範圍內的速度，也把人類注意力集中在真正可能讓整個工作環境失效的決策。
主力機上的額外原則
非清除重裝後，要同時檢查兩類殘留
保留資料的 macOS 重裝會替換系統檔案，但可能保留使用者偏好、快取與第三方 App，所以不能假設原本的檔案關聯或 App 衝突已經消失。另一方面，SDK、runtime 或 system library 改變後，專案內既有的原生依賴也可能需要重建。
除錯時應把兩條路徑分開驗證：使用者層問題先做唯讀盤點；build／import 問題先隔離到單一套件，優先重建可再生的 repository dependency 並跑最小 smoke test。不要因為重裝過系統，就直接清理全域套件、重設系統服務或重裝整套開發環境。
不把第一輪實驗放在主要帳戶
涉及文件關聯、Finder extension、Quick Look、登入項目或系統服務時，優先順序應是：
- 靜態檢查 App bundle 與設定檔。
- CI 或乾淨 build artifact 測試。
- 測試用 macOS 帳戶、測試機或可還原 VM。
- 主力帳戶只執行已驗證的最後一步。
同一產品身分只保留一份可註冊 App
備份版不要以相同 Bundle ID 的可執行 .app 形式留在 /Applications。較安全的做法是壓縮成 ZIP、改成非 .app 結尾，或移出系統會主動掃描的位置。
先證明備份可以讀
「有 iCloud」與「有可用復原點」不是同一件事。系統層操作前至少確認：
- 關鍵文件已有獨立副本。
- Agent 的本機工作紀錄與專案狀態可復原。
- 需要的憑證、金鑰與環境設定有安全備份。
- Recovery 中知道如何辨認正確的 Data Volume，但不預設磁碟識別碼永遠相同。
可直接交給 Agent 的操作提示詞
這是我的主力電腦。請完成：[明確成果]。
你可以自主進行：
- 目標 repository 與臨時目錄內的唯讀檢查、程式修改、build 與測試。
- 不改變系統狀態的診斷。
以下操作必須在執行前另外列出風險、影響範圍、備份與 rollback，等我確認：
- 修改 /Applications、預設開啟程式、LaunchServices、Finder／圖示快取、登入項目、Keychain、TCC、launchd、網路或其他全域設定。
- 停止或重啟系統服務、清除快取、直接寫偏好資料庫、安裝替代系統工具。
工作方式：
1. 先盤點現況，確認只有一份會被系統註冊的目標 App。
2. 一次只做一項可回復變更，完成真實驗證後才能繼續。
3. 若命令／API 阻塞、留下殘留程序、Finder 或背景 App 異常，立即熔斷：停止同子系統的所有寫入與重試。
4. 熔斷後只保存證據、做唯讀診斷並回報；不得自行改用另一套工具、清快取、重啟 daemon 或擴大權限。
5. 不要把「我同意成果」解讀成「我同意所有系統層手段」。
完成時請提供：變更前後狀態、實際驗證、未完成項目與可執行的 rollback。
這段提示詞不會阻止 Agent 寫程式或跑測試；它只把系統層升級與失敗後的重試策略說清楚。
系統已經異常時的 Agent 提示詞
目前系統已出現：[症狀與開始時間]。
上一輪可能執行過：[已知命令／變更]。
現在只允許唯讀診斷與整理復原計畫，不得修改偏好、清快取、重啟服務、安裝工具、刪除或搬移資料。
請先：
1. 按時間列出已知變更與仍在執行的程序。
2. 區分已確認事實、推論與未知項目。
3. 找出可先備份的資料與最低風險的停止方式。
4. 提供分階段復原選項；每一階段只處理一個假設，寫清楚風險與 rollback。
5. 在我選擇方案前不要執行修復。
一旦系統已降級，Agent 的角色應從「自主完成者」切換成「事故紀錄與決策支援者」。這不是永久降低自由度，而是避免在證據最少、風險最高的時刻繼續堆疊變更。
最小檢查表
開始前
- 這是綠區、黃區還是紅區？
- 使用者授權的是成果，還是也明確同意此系統層手段？
- 目前狀態、備份與 rollback 已記錄。
- 只有一個明確變更與一個成功驗證。
- 熔斷條件已寫出來。
執行後
- 命令沒有阻塞或留下未知程序。
- 真實使用行為與設定檔結果一致。
- Finder、登入環境及相關服務正常。
- 沒有用第二套工具疊加未回復的失敗。
- 已回報殘留風險與 rollback。