最近做了一件有點像「把家裡養熟的貓帶去公司上班」的事：把原本偏個人使用的 AI 助理，整理成團隊環境也能跑的服務。聽起來很簡單對吧？把設定搬一搬、Docker Compose 寫一寫、token 填一填，然後 up -d，收工。
結果真正開始動手時，我第一個停下來處理的，反而不是功能。不是讓它會讀更多文件、回更多信、接更多工具，而是把它關進一個乾淨、明確、可追蹤的邊界裡。
個人助理和團隊助理，是兩種生物
個人 AI 助理很好玩，因為它可以很貼近你的工作方式。它知道你的習慣、常用資料夾、偏好的語氣，也可能存著大量只有你自己看得懂的上下文。這在個人場景裡是優點，因為越貼身越省力。
但一旦要放進團隊環境，這些優點會瞬間變成風險。
個人記憶不能混進公司流程，私人 token 不能被團隊服務沿用，個人文件路徑不能被容器隨便 mount，甚至連 log 放在哪裡、session 存在哪裡，都不能用「反正我自己知道」帶過。技術人很容易低估這件事，因為我們常常先求能跑，再慢慢整理。但 AI agent 不太適合這種做法。
原因很簡單：它不是普通背景服務。它會讀資料、使用工具、做判斷、產生回覆，有時候還會替你觸發外部動作。這種東西如果邊界不乾淨，就像把一個拿著萬用鑰匙的實習生丟進辦公室，然後跟他說「你看情況處理」。
聽起來有點恐怖，但這大概就是很多 AI 自動化原型真正上線時的樣子。
我現在會先問四個問題
把 agent 放進團隊之前，我現在會先問四個很無聊、但很救命的問題。
第一，它的家在哪裡？也就是 runtime home、config、memory、session、log，全部要有獨立目錄。不要跟個人環境共用，也不要偷偷吃到開發機上的預設設定。環境變數、設定檔、volume mount 都要明確寫出來。
第二，它拿到哪些鑰匙？API token、模型金鑰、外部服務憑證都要分開。個人用的 credential 不能直接拿來給團隊服務用，否則出事時你根本說不清楚是哪個身份做了什麼。更麻煩的是，權限通常會不小心給太大，因為「先讓它能跑」真的太有誘惑力。
第三，它看得到哪些資料？這題比想像中難。很多人寫 Docker Compose 時，會很順手地把整個 home directory 掛進去，想說這樣最方便。對，方便到有點可怕。比較好的做法是只 mount 它需要的資料夾，而且路徑命名要讓下一個維護者看得懂：這裡是 config，這裡是 shared skills，這裡是 output，這裡是 log。
第四，它的行為怎麼追？agent 做了什麼、讀了什麼、回了什麼、失敗在哪裡，至少要有基本軌跡。不是為了抓戰犯，而是為了除錯。沒有 audit trail 的 AI 自動化，demo 時很酷，維運時會讓人很想辭職。
flowchart TD
A[個人 AI 助理] --> B{要放進團隊環境?}
B -->|先不要急著加功能| C[獨立 runtime home]
C --> D[分離 secrets 與權限]
D --> E[限制資料掛載範圍]
E --> F[建立 log / session / audit trail]
F --> G[再開始接團隊工作流]
symlink 很方便，但容器不懂你的浪漫
這次整理時有一個小坑，雖然不大，但很典型：共享知識或技能庫到底要複製一份，還是用 symlink 指向同一個來源？
我偏好一個源頭，因為同一份知識如果複製到多個地方，最後一定會版本漂移。今天這邊修了，明天那邊忘了同步，過兩週你就會看到兩個 agent 對同一件事給出不同答案。那種感覺很像養了兩個新人，結果他們看的 SOP 還不是同一版。
所以 symlink 看起來很合理。但容器有一個現實：如果 symlink 指到容器看不到的 host 絕對路徑，那在容器裡它就是一條斷掉的路。這不是什麼高深問題，卻很容易在「我本機明明可以」的情境裡浪費時間。
解法也不浪漫：要嘛把來源路徑也 bind mount 進容器，要嘛不要用跨邊界的 symlink。總之，不能只在 host 上看起來整齊，也要在 runtime 裡真的可解析。這句話其實可以套用到很多工程管理問題：架構圖上連得起來，不代表執行環境裡跑得動。
功能不是不重要，是順序不能反
我知道，談 AI agent 時大家最想看的通常是功能：它能不能自動回信？能不能查文件？能不能跑任務？能不能幫團隊省時間？這些都重要，我也喜歡做這些，畢竟功能跑起來才有爽感。
但從技術主管角度，我越來越覺得順序要反過來。
先不要問 agent 能做多少事，先問它被允許在哪裡做事。先不要問它能不能接更多工具，先問每個工具背後的權限邊界是什麼。先不要問它能不能理解更多上下文，先問哪些上下文本來就不該被它看到。
這不是保守，而是讓它可以長大的前提。個人玩具可以靠記憶和手感維持；團隊基礎設施不行。基礎設施要能交接、能重建、能除錯、能縮權、能停用。你不能把一個只有原作者知道怎麼活著的 agent 丟給團隊，然後期待它成為可靠同事。
AI agent 的治理，應該從部署那一刻開始
很多治理討論會從 policy 開始：誰可以用、什麼資料不能丟、哪些動作要 approval。這些當然需要，但我更在意的是，治理有沒有落到部署結構裡。
如果 policy 說資料要隔離，但容器掛了整個工作目錄，那 policy 只是文件。如果 policy 說憑證要分權，但大家共用同一組 token，那 policy 只是安慰劑。如果 policy 說行為要可稽核，但 log 分散在不明目錄，session 過幾天就找不到，那 policy 只是漂亮話。
真正的治理不是開會講出來的，是在 docker-compose.yml、目錄結構、環境變數、權限設定和操作手冊裡長出來的。
這也是我這次最大的心得：AI agent 要從「我的助理」變成「團隊的基礎設施」，最關鍵的不是讓它更像人，而是讓它更像一個正經服務。可以被部署、可以被限制、可以被觀察，也可以被安全地關掉。
如果你也正在把 AI 自動化從個人流程推向團隊，我會建議先忍住加功能的衝動。先把邊界畫乾淨。功能晚一天上線，頂多少一點爽感；邊界沒畫好，後面要補回來，通常會多很多冷汗。