2025 年，一家台灣中型電商的行銷團隊有五個人，輪班管理三個社群帳號。密碼存在一張共用的 Google 試算表裡，每個人都有存取權。沒有人覺得這有什麼問題，直到他們決定導入 AI Agent 來自動發文。
第一個直覺是：「把帳密給 Agent 就好了。」
這個直覺，幾乎每一家開始用 AI 的企業都會有。而它幾乎都是錯的。
訓練 Agent 之前，先問一個問題
大多數人談 AI Agent，談的是能力：它能搜尋嗎？能寫報告嗎？能串接哪些工具？這些問題都對，但都是第二順位的問題。
第一順位的問題是：這個 Agent，被允許做什麼？不被允許做什麼？當它做了不該做的事，責任落在哪裡？
這不是技術問題，是治理問題。而企業在設計 Agent 的時候，90% 的注意力都花在前者，幾乎沒有人在想後者。
沒有授權邊界的 Agent，能力越強越危險。一個什麼都能做的助理，和一個隨時可能失控的漏洞，在系統架構上其實沒有本質差異。
這正是 S.P.E.A.K 框架誕生的起點。
- 【S】 Skill 技能
- 【P】Personality 特質
- 【E】Experience 經驗
- 【A】Authority 授權
- 【K】Knowledge 知識
五個維度裡，S、P、E、K 都在描述 Agent 是什麼、懂什麼、能做什麼。只有 A 【Authority】在回答一個完全不同的問題：它被允許走到哪裡為止。
「你給 Agent 的每一項授權，都是一扇打開的門。問題不是門打開了多少，而是你知不知道哪些門永遠不該開。」
密碼的物理隔離：流程代理的邏輯
回到那家電商的故事。他們最後沒有把社群帳密交給 Agent。
他們做的事情更聰明：Agent 只被授權觸發發布流程，而不是執行發布動作本身。當 Agent 決定要發一篇貼文，它做的事是把內容和時間傳入 Make.com 的一個場景流程，由 Make 在背後用真實帳密完成登入與發文。
整個流程的授權鏈是這樣的：
Agent（知道要發什麼）→ 觸發 Make 場景（知道怎麼發）→ Make 持有帳密（有權限發）
Agent 全程碰不到密碼。它不知道密碼是什麼，也不需要知道。
這個設計的本質，是企業安全架構裡幾十年前就存在的原則：最小權限原則（Principle of Least Privilege）。每個角色只被授予完成工作所需的最小權限，不多給一分。
銀行系統、醫院資訊系統、政府資料庫，它們都是這樣設計的。但在 AI Agent 的世界裡，這個原則幾乎被遺忘了，因為大家都急著讓 Agent「更強大」。
智働話的核心命題是：AI 不是來取代人的，而是來協作的。但協作有前提，每個參與者都要清楚自己的職責邊界。給 Agent 無限授權，不是信任，是失職。
雙層金鑰：當技能本身也需要授權
流程隔離解決了「操作層」的安全問題，但還有另一個問題：技能本身，要怎麼授權？
在 Smart4A 的 Agent 職訓中心平台（speak.smart4a.tw）裡，每一項技能都是加密的。主機端用 AES 加密儲存技能內容；用戶端必須在本機持有對應的解密金鑰，才能解鎖使用。
這創造了一個優雅的安全結構：技能不是「下載」來的，而是「解鎖」來的。平台知道你有資格使用，你的本機金鑰確認你是本人，兩者缺一不可。
對企業主來說，這個設計的好處不是技術上的，而是心理上的：你不需要懂 AES 是什麼，你只需要保管好你的金鑰。 複雜的安全邏輯由平台承擔，你承擔的只有最後一把鑰匙。
這讓我想到保險箱的設計哲學：最好的保險箱不是讓用戶理解它的鎖芯構造，而是讓用戶只需要記住一組密碼，其他都由機械結構保護。SPEAK 的授權層，做的是同一件事。
金流的邊界：不是拒絕，是加一道人的關卡
那麼，有沒有什麼場景是 Agent 可以觸發流程，但不能獨自完成的？
答案是有的。金流，是最典型的例子。
對帳、請款、甚至部分匯款流程，Agent 可以啟動、可以整理資料、可以帶入數字，但在流程的某個關鍵節點，必須有人確認才能繼續。這就是 Human-in-the-Loop（HITL） 的設計邏輯。
HITL 設計原則
Agent 觸發流程，但流程在執行之前會暫停，等待人工審核與放行。資金不會在沒有人確認的情況下移動。Agent 的角色是準備與提醒，決策權留在人的手上——這不是技術限制，是刻意為之的治理設計。
HITL 不是不信任 AI，而是承認有些決策的後果不可逆。一旦出錯，沒有撤回鍵。金流挪用、帳款錯付，任何一個環節的失誤都可能造成無法彌補的損失。在這種場景下，讓人保持在迴路裡，是授權設計最負責任的選擇。
Authority 的成熟形式不是二元的「給」或「不給」，而是設計一條有層次的授權鏈：Agent 可以走到哪一步、哪一步需要人工確認、哪一步只有特定角色才能放行。這才是企業級 AI 治理真正的樣子。
一部好的憲法，不只寫明誰有什麼權力，也寫明哪些權力必須經過制衡才能行使。你的 Agent 授權架構，也應該如此。
SPEAK 的真正順序
如果你正在規劃企業 AI Agent，SPEAK 給你一個反直覺的建議：不要從 S 開始，要從 A 開始。
先問：這個 Agent 被允許接觸哪些系統？哪些帳密永遠不該落地到 Agent 手中？哪些操作必須保留人工確認？有沒有一條你無論如何都不會跨過的紅線？
把這些問題回答清楚，你的 Agent 才有資格開始學技能、建立個性、累積經驗、吸收知識。
否則，你訓練出來的不是助理，是一個隨時可能失控的漏洞。只是它說話很有禮貌，你暫時還沒發現問題在哪裡。
智働話的核心不是用 AI 取代人的工作，而是重新定義人與 AI 各自該負責什麼。授權設計，就是這道邊界最具體的體現。
那家電商的行銷團隊，最後建了一個乾淨的 Agent 架構：Agent 負責內容生成與排程判斷，Make 負責執行與帳密管理，人負責最終的發布決策與金流操作。三層分工，各司其職。
他們說，導入之後最大的感受不是「AI 幫我省了多少時間」，而是：「第一次感覺我們的系統是有設計過的。」
這才是 SPEAK 框架想要帶給每個企業的東西。
