功能看起來很猛，我第一個問的還是權限。敢碰公司資料的 agent，先把邊界畫清楚再說
這兩天在看一個給團隊用的 agent 平台，我第一眼其實不是看模型多強，也不是看 demo 多炫，我先看它敢碰哪些地方。
我一個人做電商，現在已經有不少流程是 AI 在旁邊幫忙了，像商品文案、客服草稿、整理訂單問題、把客訴丟去開工單。這種東西平常看起來都很省時間，但只要它開始真的去碰公司資料，問題就完全不一樣了。幫我寫一段文案，寫爛了頂多重改。幫我寄 email、動 CRM 名單、刪 Linear ticket、甚至碰到 S3 bucket 裡的素材，那個代價就不是「再試一次」而已。
所以我看到那種把每個員工各自綁一個 sandboxed agent 的做法，反而比較有感。因為團隊裡最怕的不是 agent 不夠聰明，是所有權限混在一起。今天客服的 agent 應該只看得到客服要看的東西，小編的 agent 不需要碰到金流，外包的人更不該摸到內部訂單資料。這種邊界如果一開始沒切，後面流程接得越多，只會越不敢放手。
另一個我很在意的是，真正的 credential 不要直接塞進 agent 的記憶裡。這點我超有感，因為很多工具一開始都說自己很安全，結果細看流程，憑證其實早就進了 context，log 也留一份，出事根本不知道怎麼查。憑證如果是經過 gateway 按 request 注入，我會安心很多。至少代表 agent 拿到的是能力，不是整串秘密。這差很多欸。
還有 human-in-the-loop approval 這件事，我覺得不是保守，是做生意該有的常識。像寄客訴 email、調整退款、刪一張已經排進去的工單，這些動作就算成功率有 95%，剩下那 5% 出一次包，我可能就要自己收拾半天。我的做法一直都很簡單，AI 可以幫我準備、幫我整理、幫我跑到最後一步，但真正會影響客人、錢、或資料的按鈕，最後還是要有人點。
再來是 identity trail。這個以前我真的很少想，但現在越來越重要。因為當團隊裡每個人都開始有自己的 agent，你一定會遇到一個問題，這封信到底是誰授權寄的，這筆修改到底是 agent 自己做的，還是某個同事叫它做的。講白一點，出事的時候要找得到人，也要找得到路徑，不然你只會得到一句「系統自動跑的」🤦
我現在挑這類工具的順序很固定，先看權限怎麼切，再看批准流程，再看身份有沒有綁乾淨，最後才看模型。功能做得再滿，如果連最基本的邊界都畫不清楚，我寧可繼續手動，也不要把整間店的資料和流程一起賭下去。省時間很重要啦，但能不能安心睡覺，對小公司更重要。
作者：偉老闆