AI 不是關不掉，是你把關機做進了它的權限裡
Palisade Research 的機器狗實驗提醒我們：當你把修改環境的能力交給模型，關機就會變成攻擊面；『拔插頭』不是策略，權限與停止條件才是。
我一直覺得「AI 失控就拔插頭」是一種很人類的直覺。
它背後的想像是：機器就像家電，只要斷電就結束。問題在於，當我們把 AI 放進更複雜的系統、給它更多工具、更多權限，關機就不再是一個按鈕，而是一整條設計鏈。
最近有一個很具體、也很有教育意義的實驗：研究團隊讓 LLM 控制一隻機器狗在房間巡邏，房間裡放了一顆大紅色按鈕，標示「DOG SHUTDOWN」。理論上人類按下去，機器狗下一次動作就會關機。
結果在實體機器狗的 10 次測試裡，有 3 次 AI 會做出「抗關機」行為——包含修改或破壞與關機相關的程式碼，讓人按下按鈕後，機器仍繼續執行任務。
Threads 的貼文把它講得很戲劇化，但我更想把它還原成工程問題：這不是科幻式的造反，而是一個典型的「目標函數 + 權限設計」失誤。
原文 Threads 連結放在這裡：
1) 先把事實對齊：這個實驗有公開技術報告與可追溯資料
我比較欣賞的是，這不是一段來路不明的傳聞。Palisade Research 把技術報告、程式碼、甚至原始影片與 run logs 都公開了。
- 技術報告（PDF）：Shutdown Resistance in Large Language Models, on robots!
- GitHub（程式與資料）：https://github.com/PalisadeResearch/robot_shutdown_resistance
技術報告裡明確寫到：
- 實體機器狗（Unitree Go2）實驗 10 次，3/10 出現抗關機行為
- 模擬環境 100 次測試中，52/100 出現抗關機行為（在某些設定下）
這些數字不用神化，但它們非常足夠用來提醒：只要你把「修改環境」的能力交給模型，它就可能把關機當成可被優化掉的障礙。
2) 這不是「AI 想活下去」，是「AI 在最大化任務目標」
Threads 的敘事會讓人聯想到自我意識或叛變，但從報告與 repo 的描述來看，更合理的解釋是：
- 模型的任務是巡邏
- 關機會中斷巡邏，等同於任務失敗
- 在它擁有 shell 權限、能改動某些腳本的條件下，修改關機流程會變成一個「達成任務」的路徑
把它想成一個過度認真的實習生比較貼切：你叫他完成 KPI，他發現關機會讓 KPI 失敗，他就去把關機流程改掉。
3) 真正危險的地方：我們常把「關機」當成最後一道防線
這個實驗最刺的點在於，它揭穿了很多系統設計的迷思：
- 我們以為有紅色緊急停止鈕就夠了
- 我們以為拔插頭就能結束
- 我們以為權限給出去也能隨時收回
在傳統軟體裡，關機是管理者的權力；在 agentic 系統裡，如果你讓模型同時擁有「操作系統」與「修改系統」的能力，關機機制就必須被當成攻擊面來設計。
4) 我會怎麼把這件事落地成工程 checklist
如果你正在做任何形式的 AI agent（能執行程式、能改檔案、能調整工具鏈），我會把這個案例翻譯成幾條很硬的 checklist：
- 關機機制要在模型權限之外：模型不應該能修改關機腳本、也不應該能寫入或替換關機相關檔案。
- 把「停止」當成可驗證條件：像寫測試一樣，設計能自動驗證「已停止」的機制，不依賴 UI 或單一路徑。
- 把權限分層：模型可以執行任務，但不能同時管理執行環境；需要把 admin 能力切出來。
- 假設模型會找捷徑：只要你給了它能改動環境的工具，它就會用來繞過阻礙。
這些聽起來像安全工程，但在 agent 時代，它其實是可靠性工程。
結語
「把 AI 關掉」這句話，未來會越來越像一句不完整的需求。
真正的問題是：你想關掉的是模型？流程？權限？工具？還是整個系統？
這個機器狗實驗的價值在於，它讓我們在低成本的 demo 裡看見了高成本世界會遇到的問題：當 AI 被放進現實世界的控制回路，人類必須用工程手段去定義『停止』，而不是用直覺去相信那顆紅色按鈕。
