之一：起點
我透過 Anthropic Cowork 設計了一群 Agent 幕僚團隊，不是那種「我請 AI 幫我寫個 email」的程度，共有 5 位 Agent 幕僚，每個幕僚各司其職、共享知識庫，也能即時協作。因為是個人使用為主，因此全地端運作 ， MCP 串 Notion、Slack、Gmail、Google Drive、Calendar。
整個系統不複雜，但組合起來後，效果遠超過我的預期，有幕僚長、有法務、有創作者開發、有產品策略、有技術幕僚。每個人有自己的名字、自己的個性、自己的專業領域，共享同一份公司知識庫。
之二：架構
先有一個「通用知識庫層」。裡面放的是公司月報、三年目標、OGSM、vocus PlayBook，以及我寫過的多篇（非生活類，以商管、趨勢、管理心得為主），全部轉成 markdown 餵進去。
知識庫每週自動掃描更新，幕僚們讀的是萃取過後的重點摘要，不是原始資料，效率和 Token 的運用上差很多。
每個幕僚各有特化和專屬的知識來源和調教過的技能（Skill），各自負責不同任務。通用知識庫確保大家對公司方向的理解一致，專屬知識庫讓每個人在自己的領域夠深。這跟經營團隊是一樣的道理：你不可能讓法務和產品經理讀完全一樣的資料，但他們必須對公司走哪個方向有一致的理解。
每個幕僚自己的 Skill 以及專屬的知識庫
之三：David 的 N 種影法術
跟中二王道的少年漫畫一樣，術式公開或是揭露念能力的時候，就是要是一決生死了！
所以這裡只先揭露兩個影法術的式神，幕僚長 Emily、技術幕僚 Neo 。
開玩笑的，其實是其他 Agent 的名字太中二了，例如：森上梅友前（法務幕僚）、廣未涼子（創作者開發幕僚）、贈送的豬肝連（行銷成長幕僚）、穗稻夏舞（HR幕僚）…等，我就不一一介紹了。
幕僚長 Emily，她的工作之一是每天固定三個時間掃 Notion、Slack、Gmail，對每個 incoming 的任務、會議決策、信件做預判，標記風險等級和機會標籤，然後給具體行動建議，也都有對應的票進到我自己的票倉。
在 Emily 跑 task 的時候，我可以先好好喝一杯咖啡。
AI 的 task 跟好幾個 session 在運作，不知道要做什麼的 me （人類）
之四：Agent 互相串聯
不需要我每次手動進行 dispatch，我在每個幕僚的運作裡就寫好了「遇到這種情況，建議諮詢 XXX」。就像真的組織運作一樣，你不需要每件事都經過 CEO，彼此之間自己會知道什麼時候該拉誰進來。
舉個例子，Email 進來一封代理商的合約談判信。Emily 分析完，往下做三件事：建回覆草稿、在我的每日代辦開一張票（附回覆草稿連結）、在決策資料庫開另一張票提醒我要做決定。然後因為信裡有合約初版，她自動讓法務幕僚開一張新的法務票，進行初步審閱。一封信進來，三件事情同時被處理，也會在 Slack 通知我，我只需要做最後的判斷。
一個議題，我可以同時請不同的幕僚針對自身背景和專業給我意見，甚至在同一張會議票上面進行討論（第一次看到他們互相討論的時候，覺得很魔幻）。
之五：一些沒必要，但讓自己開心的東西
我做了一個幕僚指揮中心的前台。一個 HTML 頁面，每 3 秒輪詢 agent-status.json，如果有幕僚在運作，就會在畫面上看到他們跑來跑去、顯示正在執行的任務。
非常沒必要的一個功能。
但每次看到幕僚同時在畫面上各自忙碌、跑來跑去，就覺得莫名療癒。大概就是一種養電子寵物的心情吧？
Fallout Vault 風格的幕僚指揮中心
另外，我也幫幕僚們加上各自的人設，例如：森上梅友前是台灣長大的日本人，嚴謹但私下其實很好相處；創作者開發幕僚廣未涼子，背景是「傳說的 20 世紀末最後美少女，淡出演藝圈後加入 vocus」...。
一樣是沒必要的功能，但自己開心。
設計 Agent 真正花費時間的地方
技術面，老實說沒什麼好講的，以後方法只會越來越簡單、門檻越來越低，每個 AI 巨頭應該都會跟自身的生態系整合的越來越便利。
我花費最多時間的地方在：
- 設計幕僚之間的協作邏輯：誰遇到什麼情況該提醒誰、誰的 output 是誰的 input、什麼時候需要拉 CEO 做最終判斷。這跟在真實組織裡，設計工作流程是完全一樣的事情。
- 設計每個幕僚的知識來源：不是把所有東西都丟進去就好。什麼該放通用知識庫、什麼該放專屬知識庫、萃取的顆粒度要多細、哪些資料需要定期更新，這些設計時的思考比寫 prompt 重要。
所以這件事情的本質不是「會不會用 AI 工具」。而是有沒有辦法把自己腦中對於組織、流程、知識管理的理解，具體化成一套可以運作的系統。
怎麼建立一套可維護、持續更新的知識庫，才是建立 Agent、與之協作最重要的工作。
AI 時代，Context 的重要性
因為我固定會整理一個給自己閱讀的「決策紀錄庫」，方便自己檢視決策的背景、原因，也有利我後續追蹤、自我評分；再加上有固定寫作、整理思緒的習慣，因此個人的知識庫建立的還算完整。
在這樣的基礎下建立起來的幕僚團隊，輸出品質很符合我的期待，也因為這個資料庫足夠完整，甚至可以建議某些不需要再由我進行決策的任務移交給其他主管。
另一個例子，則是老翁要自賣自誇了。
vocus 內部對於「建立團隊知識庫」的協作準則，一直有比較高的要求。產品幕僚 Jobs 串了我們內部的產品知識庫，有了過去產品團隊歷代火影們留下來的文件、紀錄等充足知識的火力支援下， Jobs 在準備功能評估、用戶場景分析、產品 Roadmap、競品研究時，他提出來的完整度遠超過我的預期，不是 60 分堪用，已經有 80 分的水平，甚至可以進行非常高品質的策略討論。
註記
這篇文章中的 Claude Cowork AI Agent 幕僚團隊，大約在 3 月初至上旬完成，測試了一週後，個人工作效率明顯提升，所以正式寫篇文章紀錄、分享。
然而個人閥值提升，我可以做更多事情反而變得比以前還更忙碌，Dispatch 推出後更是如此，離開辦公室吃午餐時直接繼續用手機遠端操控 Agent 們工作...，舊文章「再見了，單一職能與資訊提供者」紀錄了當時初淺的想法。
回到 Agent 以及相關的協作。
我後來又陸續進行了多次的改版，也新增了 3-4 位新的幕僚（名字也更中二），有的幕僚準備升級成團隊使用，也改走 Claude API，不再是地端的架構，也正式進入團隊協作的階段，這部分有有更多心得，包含 Context 的重要性、團隊導入會遇到的挑戰...等，未來幾篇文章再談。
如果你有任何想法，也歡迎在文章底下直接跟我交流。
我會不定時分享和紀錄不正經的東西，有時候也可能是關於內容產業的觀點（我的觀察啦）、工作的心得，不過，說不定大多時候都還是亂七八糟的東西和雜談，歡迎追蹤：
