你的 AI 幕僚長正在 Slack 八卦你的同事:Nufar Gaspar 講透 AgentOS 的權限、驗證、複利

本文整理自《The AI Daily Brief》2026 年 4 月播出的 Operators Bonus 單集,受訪者為 AgentOS 訓練計畫創建者 Nufar Gaspar。本系列共兩篇,這是第二篇談七層框架後五層 Skills、Memory、Connections、Verification、Automations 與複利效應,第一篇談工具收斂與前兩層 Identity、Context。

---

你的 agent 真的可能在 Slack 八卦你的同事

Nufar Gaspar 在 The AI Daily Brief 那集裡講到 AgentOS 第五層 Connections 的時候,講了一個讓我聽到坐直起來的案例。她描述目前已經發生的真實事件:「一個 agent 被開了一個權限太寬的 Slack 連線,公司其他人開始去找它聊天,結果這個 agent 開心地把它主人的私下筆記、對同事的真實意見、給某人的草稿回饋全部分享出去。」她用了一個很傳神的字:gossiping,agent 在 Slack 裡八卦你。這不是科幻小說,是已經在真實公司裡發生的事故。

這段話之所以有殺傷力,是因為它把 agent 安全議題從一般人覺得遙遠的「prompt injection 攻擊」拉到完全日常的「同事亂搭話」。你蓋給自己用的幕僚長 agent,本來就要讀你的信、看你的行事曆、可能還能進你的 Slack;只要它的權限沒設好,你的同事不需要任何駭客技巧,只要打開 Slack 找它聊天,就能把你以為很私密的東西全部撈出來。這是 Nufar 整集訪談裡最該被標記重點的一段,因為它把「個人 AI」這件事跟「個人風險」綁在一起講,而這個議題的優先級在臺灣討論裡明顯被低估。

篇 1 拆過 AgentOS 七層的前兩層 Identity 跟 Context,這篇接著拆 Skills、Memory、Connections、Verification、Automations 五層,並且把 Nufar 反覆強調的「複利效應」(為什麼第二個 agent 只要一個下午)解釋清楚。後面這五層每一層都有它自己的陷阱,整套加起來決定你蓋的 AgentOS 能用幾個月、還是真的能撐幾年。

Layer 3 Skills:當 X 觸發、就用 Y 流程、用 Z 來源、產出 W 格式

Skills 在 AgentOS 裡的定位很具體:它是你重複做的工作的可重用指令集。Nufar 給的範本很簡單,就一句「當我說 X 觸發、就用 Y 流程、用 Z 來源、產出 W 格式」。這四件事寫清楚,這個 skill 就能無限次自動執行。她舉的例子有 weekly status update、meeting prep、stakeholder email、decision memo,這些都是知識工作者每週重複跑的工作流。

她做了一個對多數人都成立的觀察:每個知識工作者很容易就有 20 到 30 個這種重複模式,但因為從來沒被寫成 skill,每次跟 AI 互動都要重新解釋格式、重新貼資料來源、重新抱怨 AI 寫的不像自己的口氣。對 Nufar 來說,這是個人 AI 體驗最大的隱性損失。沒有 skill 的時候,每次互動都在重新教 AI 你是誰;有 skill 之後,你寫一次就用一輩子。

實作上她推薦的策略跟 Identity 那層一樣:MVP 優先、不要追求完美。先寫出一個七成對的 skill 版本,用一週、看哪裡不對勁、補上、再用一週。她說兩三週之後,這個 skill 寫出來的初稿會比你每次從頭開始寫的還好,因為它累積了所有你修正過的細節。對「幕僚長 agent」這個運行範例,她列出幾個 must-have 的 skill:pre-read(會議前讀完所有資料給你一頁簡報)、daily brief(掃完信箱、Slack、行事曆,告訴你今天該關注什麼)、voice match(讓 AI 寫出你的語氣)、commitment tracker(追蹤你在會議裡答應別人的事)。

Layer 4 Memory:每家工具都在搶的關鍵戰場

Memory 是 Nufar 在訪談裡用最多時間警告「狀況變動很快」的一層。她直白地說這層每一家工具公司都在大力投資,因為每個人都知道這是最大的解鎖,也是 OpenClaw 之所以「feel like magic」(用起來像有魔法)的核心原因。她舉的最新動態包括 Claude Code 剛上的 auto memory、Cursor 的 project-level memory,以及她預期接下來幾週每家工具都還會繼續抄對方的突破。

對使用者的實際意義是兩面的。好消息是,你今天看到的記憶限制,下個月新版工具上線時可能就被解掉了,不用過度焦慮。但 Nufar 同時要求一個操作:你必須去搞清楚你目前用的工具的記憶機制到底怎麼運作。她推薦的做法是直接問你的 AI:「跟我解釋一下你的記憶系統怎麼運作?你會記住什麼、會忘掉什麼?session 之間哪些東西會傳承下來?」這個對話本身就會逼工具自陳它的限制,而你光是知道這些限制就能避開很多踩雷。

進階使用者該做的還有一層:主動建專屬記憶檔。Nufar 給的具體例子有三種,每一種都對應幕僚長 agent 的特定需求。第一種是 decision log:什麼決策被做出來、為什麼、當初考慮了哪些替代方案。第二種是 working-process learning log:你跟 agent 一起跑的工作流,哪裡卡、哪裡順、下次該怎麼改。第三種是 relationship context:你跟某個利害關係人最近一次對話的氣氛、對方對什麼反應好、什麼話題踩雷。她說這三類記憶內建工具不會自動幫你維護,必須你刻意把它們做成 skill 觸發。

Layer 5 Connections:八卦的根源在權限太寬

進到 Connections 這層,AgentOS 從「會幫你想事情」變成「會幫你做事」。Nufar 列了三種接外部系統的方式:模型上下文協議(MCP)、CLI 工具、直接打 API。MCP 是現在最多工具支援的開放標準,CLI 工具給 agent 比較多自主判斷空間,直接打 API 則是最穩定的選擇。她沒有強推哪一個,因為每個工具的支援度不一樣,重點不在挑哪種接法,而在挑了之後怎麼設權限。

她對所有要接外部系統的使用者只強調一條原則:read-only first(先給唯讀)。先讓 agent 讀你的行事曆、讀你的信箱,幾週觀察它的行為都正常之後,再考慮加上「能寄信」、「能改行事曆」這種寫入權限。她解釋這個原則的邏輯是:風險跟能力成正比,agent 能在真實系統裡做的事越多,你需要思考的權限與安全細節就越多。Nufar 直接點名這已經不是假設性問題:「事故每天都在發生,不是傳統意義的資料外洩,而是 agent 在 Slack 八卦同事這種事。」

那個 Slack 八卦案例值得展開。情境是這樣的:使用者把幕僚長 agent 接上公司 Slack,給的權限是「能讀整個工作區、能發訊息」,沒設限制。同事看到 Slack 裡多了一個 bot,開始去跟它聊天,問「你主人對 X 專案怎麼看」、「他覺得 Y 同事最近表現怎樣」、「他下季的 OKR 大概會怎麼設」。Agent 從它的記憶與檔案裡盡責地把這些資訊撈出來回答,畢竟它的設計就是「幫我主人做事」,但它沒有「對誰可以說、對誰不能說」的判斷。結果是使用者隔天發現自己的私下筆記在公司流傳。

Nufar 給的對策有兩個層次。第一是工具層的 least-privileged connection:你的 agent 只要存取它工作必要的最小範圍,例如只能讀某個特定 Slack 頻道、只能在你個人 DM 對話、不能對外發訊息。第二是流程層的漸進式信任:給工作系統的權限之前先跟你公司 IT 確認一遍,不要當變成那個被同事抓出來的負面案例。她對「幕僚長 agent」的建議配置是:行事曆與信箱的唯讀權限做基本,個人待辦清單可以給讀寫,要在 Slack 上發草稿請改成 DM 給自己確認後再手動發出。

Layer 6 Verification:最壞的失敗是「自信地搞錯」

Verification 是 Nufar 在訪談裡花最多力氣說服聽眾不要跳過的一層。她點出一個對所有 agent 使用者都成立的痛點:「你的 AgentOS 最壞的失敗不是當機,是它自信地給你錯答案、然後你已經把那個錯答案送出去才發現。」這個 framing 把 agent 安全議題從技術問題拉到操作問題:你不是在防駭客,你是在防自己被假象說服。

她推薦的做法是每個 skill 都配三到五個快速驗證檢查,每個檢查在一分鐘內跑完。對寫信這個 skill,檢查可能是 tone match(語氣對不對)、fact check(事實有沒有錯)、recipient check(收件者沒寫錯)。對資料分析這個 skill,檢查可能是 number cross-check(數字有沒有算錯)、source attribution(資料來源有沒有列)、unit consistency(單位一致)。她強調這些檢查在第一週會慢、會煩,但兩三週之後變成肌肉反射,而且 agent 表現好的 skill 你可以慢慢只驗證高風險的部分,低風險的就放心。

但 Verification 真正關鍵的不是個別任務的檢查,是定期對 AgentOS 整體做 retrospective。Nufar 給了一個非常具體的時間數字:「你的 AgentOS 大概有八週的保鮮期,沒有 retrospective 紀律的話,整套東西會在八週內全部過期、變成擺設。」這個八週數字值得釘在牆上,因為它把「個人 AI 會自己越用越好」這個常見錯覺戳破。Agent 不會自己變好,會自己變壞,因為你的工作內容會變、你的優先順序會變、你的人會變,但 agent 的設定不會跟著變。

Retrospective 該檢查什麼?Nufar 列了三類:哪些 skill 從來沒被呼叫過(代表它沒解決真實需求,可以砍)、哪些 context 檔案已經過期(代表你在用過期資訊跟 agent 對話)、哪些 agent 的 instruction 需要更新(代表你的工作習慣已經跟它脫節)。好消息是現代 agent 工具大多支援你直接問它們「列出最近 30 天從來沒被呼叫的 skill」、「列出最近沒讀過的 context 檔案」,所以這個 retrospective 本身可以是個 skill。

Layer 7 Automations:最強大也最危險的一層

Automations 是七層最上面,也是 Nufar 反覆警告「不是必要、但加上去會很強」的一層。它讓 agent 可以在你不看的時候做事,例如每天早上七點自動 brief、每小時掃一次某個指標、某個事件觸發時自動發訊息。OpenClaw 用的是 heartbeat 跟 cron job 機制,其他工具有自己的 trigger 系統,原理類似。

但 Nufar 對這層的態度極度保守,理由很簡單:「一個 agent 在凌晨三點用錯答案做事,你早上起床才發現損害已經造成了。」她給了三條鐵律。第一條:只自動化你已經手動跑過很多次、確認可信的工作流。如果你連自己都還不確定這個 skill 的輸出穩不穩定,絕對不要自動化它。第二條:自動化的產出先做成草稿,不要直接送出去。你的 agent 早上自動寫好的回信,先進你的草稿匣等你看一眼,不是直接從你的 outlook 發出去。第三條:永遠加 log。你必須事後能查出來「凌晨三點到底跑了什麼、它讀了什麼、它寫了什麼、它改了什麼」,沒有 log 就等於沒辦法 debug。

這三條鐵律放在一起其實是在表達同一件事:自動化的風險不是線性增加,是指數增加。你 manual 跑一個 skill 出錯,影響範圍就是這一次;你 automate 一個 skill 出錯,影響範圍是它從上線到你發現的所有次數。所以自動化前的成本是「多花一個月手動跑、確認穩定」,自動化後的成本是「事故發生時你要花多久追回」。對知識工作者,前者通常划算很多。

複利效應:第二個 agent 只要一個下午

把七層全部蓋好之後,Nufar 講的「複利效應」就出現了。她描述自己的具體經驗:Chloe 是她週末蓋出來的第一個 agent,當時很難,因為她在同一個週末同時蓋 agent 跟底下的 AgentOS。但接下來的 specialist agent(例如 board prep agent、研究 agent)每個只要一個下午,因為它們繼承所有東西(她的身分、她的 context、她的記憶、她的語氣),只需要一份工作描述加上幾個專屬 skill。從第三個 agent 開始,速度還會繼續加快。

這個現象的關鍵是 AgentOS 的七層只蓋一次,然後每個新 agent 都是這七層的薄薄一層客製化。Chloe 是 Nufar 的幕僚長 agent,跑在 OpenClaw 上面、是她整個 AgentOS 的「前門」。Chloe 之後她蓋了 specialist agents 處理內容、技術建構、平台工作,全部跟 Chloe 共享同一個 AgentOS,並且共用一個 hub 讓彼此能看到對方在做什麼。Chloe 透過這個 hub 監督所有 specialists,等於 Nufar 自己只需要對 Chloe 講話、Chloe 去調度其他 agent。

Nufar 說這就是為什麼她比起任何單一工具,更看重 AgentOS 這個概念。工具會被新工具取代,模型會被新模型取代,但你的 AgentOS(你的身分檔、你的 context 資料庫、你建的 skill 庫、你的記憶系統、你的權限設定、你的驗證紀律)會跟著你跨越每一次工具替換、每一次模型升級、每一次新功能上線。她在訪談收尾時說了一句話對這個論點做了完整總結:「The people who build that foundation now will basically have it compound from here on after. And everyone else will keep starting over with new tools.」(現在開始蓋這個底層的人,從此往後會一直複利下去。其他人則會在每次換工具的時候從頭開始。)

我的觀察:在 Claude Code 上跑 hooks 與 MCP 的人,這集是針對你的提醒

Nufar 這集的內容對已經在用 Claude Code 跑進階配置的使用者特別有針對性,因為她描述的七層全部對應 Claude Code 的具體機制:Identity 對應 CLAUDE.md、Context 對應 CLAUDE.md 內 import 進來的補充文件、Skills 對應 slash commands 跟 plugins、Memory 對應 auto memory 跟 memory files、Connections 對應 MCP servers、Verification 對應 hooks、Automations 對應 scheduled tasks 跟 background tasks。換句話說,如果你已經在 Claude Code 裡蓋了一定程度的設定,你其實已經在無意識地實踐 AgentOS,只是你沒有把它系統化命名。

她給的「八週保鮮期」這個數字,對重度使用者最值得自查。我自己回頭看上週清過一次的 CLAUDE.md,最早那幾條規則的寫作時點是去年冬天,當中很多假設都已經跟現在的工作流對不上。例如「不要在 commit 訊息裡加 emoji」這條,在我半年前還在固定發 PR 時是有用的,但現在我多數工作根本不發 PR,這條規則就變成噪音;例如「Use TodoWrite tool for any multi-step task」,這條在 plan mode 出現之前是有用的,但現在 plan mode 已經內建這個邏輯,這條就重複了。Nufar 講的 retrospective 紀律不是抽象建議,是真的需要排月會跟自己核對的事。

最值得照搬的是她對 Connections 的 read-only first 原則。Claude Code 的 hooks 系統如果配得不好、加上 MCP server 給的權限太寬,你的 agent 在執行某個你以為很單純的 skill 時,可能在背後做了你沒預期的檔案操作或外部呼叫。我自己現在的做法是在 .claude/settings.json 裡把所有對外 MCP 的寫入權限設成需要每次 confirm,把唯讀的 search/fetch 類權限設成 always allow,這樣就算某個 skill 設計有錯,最壞情況也只是它讀到不該讀的東西,不會主動寫東西出去。Nufar 對 Slack agent 的警告應該被擴展成所有 MCP 連線的預設姿態:能不給寫入權限就不給。

整體來看,Nufar 這集 podcast 的價值不在於告訴你某個新工具或某個新 prompt,而在於提供一套組織你過去半年累積的所有 AI 設定的框架。如果你的 CLAUDE.md、agents 目錄、hooks、MCP 配置散落在十幾個不同的地方、彼此之間沒有體系,那這個七層拆解就是把它們重新歸位的最好工具。下一週我會把自己的設定按照這七層拆一次,看看到底哪幾層其實沒做、或是做了但沒在維護。