我們公司有 31 個 AI 員工。他們有的每天凌晨五點半起來掃新聞，有的每週三下午自動生一支影片，有的每兩天半夜整理我的記憶。不用打卡，不用管午休，也不領年終。
上個月，他們把公司弄掛了。不是幾乎，是整整一天。
那天我人在國外旅行，早上起床打開手機，官網、後台、客戶端全部連不上。人在外面，只能乾著急：VPN 連不回去、伺服器看起來是活的、所有服務就是沒有回應。從機場候機室查到飯店大廳，查了一整天，什麼都沒查出來。最後只能把前一週的備份整個恢復。消失的不只是那一天，是整整一週新寫的文章、開發的功能，全部付之流水。
回台灣之後才抓到兇手，不是駭客，是三個月前部署官網時留下的一個伺服器設定。nginx 和另一個服務搶同一個 port，每天早上自動啟動就打架。跟 AI 一點關係都沒有，但那一刻我坐在電腦前想：我們讓 31 個自動化 agent 同時上線，卻沒有一個像樣的管理層。
台灣多數企業現在正站在同一個位置。員工用 ChatGPT 寫報告、部門自己接 API 做客服機器人、主管在會議上展示「我們也有 AI」。聽起來很熱鬧，實際上是一個個沒人管的 pilot。McKinsey 去年給這個現象取了名字，叫 Pilot Trap。任何人花一個下午就能用 low-code 架起一個 agent，但沒人治理的實驗，會把舊流程的碎片慢慢硬化成程式碼。過去企業做數位轉型，沒有藍圖只是浪費時間；這次沒有藍圖，是連藍圖本身都會消失。
我們已經當過一次那個例子了。所以這兩個月，開始替自己的 agent 部隊建立管理制度。沒有參考書，就是從事故裡長出來的。回頭看，我們做了四件事。
第一件事：先盤點，才知道自己養了什麼
這其實就是 HR 人力盤點的翻版。以前在 HR，我們會定期盤公司有多少人、每個人在做什麼、哪些職位重複、哪些流程過剩。AI agent 也需要同樣的盤點，而且頻率要更高：人不會一夜之間多出十個，但 agent 會。一個部門下午沒事，用 low-code 一個小時就能架出一個新的。盤點的速度跟不上繁殖的速度，就會出事。
我們把所有自動化任務攤開來，一個一個記錄：做什麼、多久跑一次、花多少成本、有沒有負責人、壞了誰修、什麼情況下該停掉。
盤點完最驚訝的不是數量，是歸屬。31 個 agent 只有一個有明確的負責人，其他全部掛在系統管理員名下。意思是：出錯的時候，沒人覺得自己該負責；該優化的時候，沒人覺得自己該動手。典型的「三個和尚沒水喝」。
我們還發現，成本高度集中：前五個最花錢的任務，吃掉了一半以上的資源。其中一個每天掃新聞的任務，輸出量是第二名的 1.5 倍。貴不一定要砍，但你必須知道錢花在哪。
第二件事：訂出五個檢查項目
盤點之後，我們建立了自己的治理框架。每個 agent 定期過五關：
- 1鋪路還是硬化？ 這個 agent 是在為未來營運鋪路，還是在自動化一個遲早消失的舊流程？
- 2有 owner 嗎？ 壞了誰修、沒用了誰提議退役？
- 3可審計嗎？ 有 log 可看、產出可驗證、歷程可回溯？
- 4划算嗎？ 成本對產值，貴的不見得該砍，但你要知道錢去哪了。
- 5該退役嗎？ 還在跑不等於還有用，退役是治理的日常。
五題裡，第一題最容易答錯。我們做過一個自動化貼文的 agent，每天把文章摘要發到社群，看起來很勤奮。三個月後回頭看，它只是把「每週人工貼文」這個動作加速了，流程的價值沒有增加，讀者還是那些人，互動還是那樣。我們停掉它，把力氣拿去建真正會累積的資產：每天的知識掃描寫進知識庫，知識庫餵給內容引擎，內容引擎產出文章、影片、電子報，形成閉環。同樣是自動化，一個在硬化舊流程，一個在鋪未來營運的路。判斷方法很簡單：把 agent 停掉一個月，你損失的是效率，還是累積？
第三件事：讓檢查變成例行公事
我們把五個檢查做成了每月自動執行的任務。每月一號，系統自己跑一遍全部資產，套用五關，產出報告，標出紅燈。我們還設了紅燈條件：沒有 owner、連續出錯、幾個月零產出、不可審計，任一成立就必須處置。
第一個月的報告出來，我們才知道原本有六個任務是重複的。四個研究掃描任務各自掃不同的來源，每週各跑一次，聽起來很完整，其實可以合併成一個，資訊完整度反而更高；一個每日健康檢查，功能早就併進別的任務；還有一個自動升級任務，也早就改成手動。我們把它們全部退役。
月檢不是偶爾做一次的健康檢查，是讓治理變成肌肉記憶。合併那天我們才意識到，有些 agent 不是設計出來的，是長出來的。先有了一個，覺得不夠，又加一個，最後變成四胞胎。
第四件事：把踩過的坑寫成教訓庫
我們開始記錄每一個事故：症狀、根因、怎麼修的、下次怎麼預防。兩個月下來記了十六筆。整理這些事故的過程，有四條鐵律浮出來。
鐵律一：agent 不能自己改自己的技能。
我們踩過最大的坑，是讓 agent 自動更新自己的技能檔案。它學到一個錯誤的假設，把未完成的東西合併進主分支，我們花了一整天才救回來。從那天起，關鍵技能的人工審核變成鐵律。
鐵律二：備份要異地，而且備份本身也要被驗證。
VPS 故障後系統回滾到舊版，幾個月的記憶、報告、對話記錄全部消失，雲端備份上也沒有。從那天起，所有重要產出當天就 push 到 GitHub。但備份自己也會出錯，我們的備份系統就曾經漏傳一百多個檔案，原因是判斷變更的方式有缺陷，系統根本不知道那些檔案變了。連備份都要被審計，這是付了學費才學會的。
鐵律三：自動化不等於累積。
自動化貼文的 agent 停掉之後，我們才真正理解這件事。每天跑得勤快的 agent，不一定在幫你累積資產，可能只是在加速一個本來就該淘汰的流程。
鐵律四：貴的不該盲目砍，但必須被看見。
成本治理不需要高深的工具。定期盤點、知道誰在花錢、誰在重複做事，就贏過一半的企業。我們重新設計了那個最花錢的掃描任務的觸發方式，每個月省下約三成的運算量。
這套做法的成果
兩個月下來，帳面上的變化很具體：27 個自動化任務全數有 owner、零重複、零無人認領；每月一號自動月檢，紅燈當月處置；十六筆事故教訓全部寫成可執行的預防檢查項。更重要的是流程本身變快了。以前一個任務壞了，要等人發現、等人查、等人修；現在月檢會主動把它標出來。
你的公司現在在哪裡？
如果你是老闆或人資主管，可以做一個五分鐘的自測：
- 1你公司的 AI 應用，停掉一個月會損失效率還是累積？
- 2每個 AI 工具或 agent，有沒有一個名字負責？
- 3出錯時，你能查到它做了什麼嗎？
- 4你知道每個 AI 工具每個月花多少錢嗎？
- 5上一次檢討「這個工具還要不要留」是什麼時候？
五題都答得出來，你的 AI 治理及格了。如果答不出來，你其實不是在做 AI 轉型，只是在養一堆沒人管的 pilot。而 pilot 養久了，總有一天會把公司弄掛。
這套五個檢查項目，我們已經做成了 25 題的線上診斷量表，讓企業可以自己測自己的 agent 部隊健不健康，就像我們每月一號做的那樣。
👉 免費診斷你的 AI 部隊：https://rong-rise.com/pilot-trap-scan
📂 更多 AI 治理內容（實錄、診斷、量表、工作坊）：https://rong-rise.com/ai-governance
那天在飯店大廳，我們就是這樣過來的。