一鍵開啟的下一步是設計安全邊界
最近看到 KoboldCpp 把 Agent harness 直接塞進 GUI，勾一個 checkbox 或下 agent flag 就能啟用。
它內建 9 個工具，還支援 MCP，工具描述大約只佔 2k tokens。對想試 local agent 的人來說，activation 從「研究半天怎麼組 harness」降成「先勾起來看看」。setup 細節打中新 user 流失的前 10 分鐘。
一鍵啟用降低了哪個門檻
產品面來看，一鍵開啟解決的是 activation，trust 仍然要另外設計。
做 B2B SaaS 時，我常看到 stakeholder 把「使用者可以開啟功能」誤認成「使用者準備好承擔結果」。中間少了一層：使用者要知道 Agent 會做什麼，出了問題誰能攔下來。MCP 把工具執行位置帶到外部服務後，風險也會擴大到檔案、網路與資料權限。
核准畫面要讓人看懂
所以我會把工具核准設計成三個維度。第一是動作風險，讀取、寫入、對外送出、刪除應該分級。第二是資料範圍，公開資料夾和客戶資料夾不能共用一個核准。第三是可逆性，能 undo 的變更和不可逆的刪除，確認成本應該不同。
KoboldCpp 的 on、auto、off 是很好的起點，我會再加一個 policy preview。勾選 auto 時，畫面顯示：「Agent 可讀取哪些路徑，可呼叫哪些 MCP server，哪些動作每次都會詢問。」這比 system prompt 或安全標籤更可理解。
第一次啟用時，預設只開放 workspace 目錄，讀取免確認，寫入需要確認，外部網路和刪除永遠需要確認。使用者批准後，系統記錄的應該是規則，不要只留下模糊的「我同意 Agent」：允許 workspace/reports/*.md 寫入，禁止存取 ~/.ssh。提供「只允許本次」和「記住這個範圍」。
Auto mode 必須能承受反例
有個容易被低估的反例。auto mode 可能讓 demo 成功率變高，但一旦 context compaction 發生，Agent 對前面核准的意圖記憶不完整，工具回傳又沒有可靠格式，連續操作可能變成錯誤寫入。安全設計不能只靠 prompt 裡的「請小心」，需要在每次工具呼叫前重建理由、目標與影響範圍。
我的判斷是，輕量 Agent 的競爭力會從「幾秒鐘能不能跑起來」轉到「使用者敢不敢讓它跑第二次」。前者靠 checkbox，後者靠權限邊界、核准語言和事後可追溯性。
如果只能先做一件事，我會先做權限預覽和安全預設，暫緩增加第 10 個工具。阻礙 adoption 的常常是使用者不清楚那一鍵替自己承諾了什麼。
作者：MingTech