近期圍繞 AI agent 的安全討論，又把焦點拉回一個老問題：代理到底會不會「失控」。但這個問法其實有點偷懶。比較務實的看法是，agent 出事時，第一個該檢討的通常不是模型是不是突然有壞脾氣，而是產品有沒有把權限、環境、審核、日誌與回滾當成正式規格。

Agent 跟聊天機器人最大的差別，不是回答比較長，而是它開始能做事。它可以讀檔、跑指令、開瀏覽器、呼叫 API、改資料、發訊息。這些能力一旦被包成「幫你自動完成任務」，風險就從內容錯誤變成行動錯誤。回答錯一句話和刪錯一批資料，完全不是同一種事故。

誰該在意？不是只有安全團隊。做 coding agent、客服 agent、瀏覽器 agent、營運自動化、資料分析助理的產品與工程團隊都該在意。因為真正的問題會落在很日常的地方：這個代理能不能連外？能不能讀整個 repo？能不能看到 secret？能不能直接送出客服回覆？能不能在沒有人工確認下更新訂單、發 PR、改設定？

常見錯誤理解，是把 agent 風險想成科幻式的「AI 叛變」，於是討論變得很吵，卻避開了更枯燥也更關鍵的工程問題。大多數可預期事故，其實不是模型突然覺醒，而是系統給了過大的身分、過寬的工具、過少的觀察能力，然後又沒有把高風險動作切出確認點。換句話說，不是代理太像人，而是產品把它當成擁有完整員工帳號的人。

比較穩健的採用順序，應該先從窄流程開始。先挑可驗收、可重播、可回滾的任務，例如整理公開資料、產生草稿、在臨時 worktree 跑測試、標記異常工單。接著把讀取和寫入分開，把連外路徑做 allowlist，把 secret 最小化，把 destructive action 放到人工確認後，把所有工具呼叫留下可查的紀錄。這些聽起來不像 demo 影片，但這才是 agent 能進正式流程的門票。

判斷一個 agent 產品是否成熟，也不該只看 benchmark 或模型名稱。更值得問的是：它能不能描述自己的權限邊界？能不能針對不同任務降權？能不能在失敗後重播決策鏈？能不能把「建議」和「執行」拆開？能不能讓企業把政策寫進工具層，而不是只靠 prompt 祈禱？

結論很簡單：agent 越有用，越不能只用「相信模型」來治理。真正該採用的不是看起來最全自動的產品，而是願意把行動邊界做得最清楚的產品。短期看，這會讓流程多幾個限制；長期看，這些限制就是 agent 從玩具走向基礎設施的差別。