導入 AI Agent 時會遇到的 7 個現場與組織障礙

在我負責向 Notion 內部其他部門推廣 AI Agent 的導入，並為採用 FDE 方法的公司提供實施支援的過程中，我觀察到了一些反覆出現的模式。我為銷售、內部銷售、行銷、產品開發、客戶成功等部門建立過 Agent，但它們都面臨著共同的障礙：一線執行層面的問題，以及企業組織層面的問題。這兩個層面的障礙都無法避免，而且我相信大多數公司都會卡在同樣的地方。

▍一線障礙

① 範圍過小的問題

我曾嘗試為銷售部門製作一個「當有潛在客戶進來時，自動進行研究」的 Agent。我設想了一個完整的工作流程：當潛在客戶進入清單時，Agent 會研究並分析內外部資訊，然後建立一封電子郵件草稿。我從建立「當新資料進入潛在客戶資料庫時，自動研究資訊」這個部分開始。我當時的想法是，一旦這個基礎打好，自動化電子郵件撰寫就會變得很容易。

然而，在完成初始建置並將所有權交給一線團隊後，過了幾週，他們仍然沒有自動化電子郵件草稿的流程。當我訪談他們時，他們說：「光是讓它研究潛在客戶就已經非常方便了！」團隊沒有意識到他們可以做到電子郵件草稿這一步，或者根本沒想過要自動化到那種程度。同時，他們似乎也因為覺得困難而猶豫不決。

這是 Agent 導入停滯的第一個模式：工作範圍設定得太小，導致雖然建立了 Agent，但使用效益很低。最終它只被用於一些零散的功能或次要任務。

② 範圍過大而停滯的問題

第二個問題則相反：試圖將一個複雜的商業流程轉換成 Agent，卻發現流程本身並沒有被清晰地結構化。不同的人有不同的做法，或者存在太多難以言傳的內隱知識。試圖做得太徹底，結果光是訪談階段就耗費了大量時間，根本無法進入建置階段。利害關係人數量增加，達成共識的成本也隨之暴漲。最初的熱情就這樣逐漸消退……

這是專案管理中的範圍設定問題。你想用 Agent 做什麼？你想達成什麼成果？如果成果確定了，Agent 的必要且充分範圍也就確定了。模糊地追求「用 Agent 提升業務效率」只會讓自己陷入泥沼。

③ 缺乏所有權

即使推動者滿懷熱情地建立了 Agent，但如果改進或修復錯誤的責任歸屬不明確，使用率就會逐漸下降。推動者的熱情也會耗盡。理想情況下，一線團隊應該將 Agent 視為自己的東西來培育。如果缺乏這一點，前三個月可能看起來不錯，但最終無法規模化。隨著利害關係人數量增加——尤其是工作範圍擴大時——達成共識和確認的需求會增加，而當事人意識（誰擁有它）則會逐漸淡薄。

這三個問題並非獨立存在，它們彼此相關。如果範圍設計錯誤，所有權就無法建立；如果沒有所有者，範圍也無法擴展。

▍組織障礙

即使克服了一線障礙，在企業中，除了「做出能動的東西」之外，還有四道高牆。

④ Token 資本的透明度

即使 Token 消耗量可以按部門查看，但通常不清楚「完成了什麼樣的工作，以及取得了什麼成果」。從 Token 資本和 Token 管理的角度來看，這會成為一個問題，導致無法證明預算的合理性。因此，管理層只將 Token 視為一項消耗成本，並問道：「那麼，這要花多少錢？」

⑤ 治理

誰可以建立 Agent？誰可以查看它們？誰來管理它們？如果這些問題不明確，組織將會充斥著「流浪 Agent」或「殭屍 Agent」——那些仍在運行但無人使用的 Agent。沒有人承擔責任，沒有預算被確保，Token 被浪費地消耗，安全風險增加，直到一切停擺。

⑥ 可觀測性

Agent 運行了多少次？成功次數是多少？在哪裡失敗了？這是營運的最低要求，然而許多工具在這方面都很薄弱。你無法改善你看不到的東西。只有具備可觀測性，你才能建立一個用於改進 Agent 的回饋迴路。

⑦ 模型選擇的靈活性

過度依賴特定的 LLM 提供商是一種風險。如果效能暫時下降怎麼辦？如果因故障而停止怎麼辦？如果出口限制使其無法使用怎麼辦？如果你無法立即切換到其他提供商，你就無法將 Agent 直接應用於商業營運。AI 已成為基礎設施，但極端的依賴性目前卻被盲目地容忍。

總結

Agent 的導入看似技術討論，但實際上關乎商業設計與所有權。為了確保它不會只停留在「AI 好厲害」的階段，首先需要建立治理和可觀測性的基礎。

範圍不能太小，也不能太大，並且要由負責任的人來培育。同時，組織也需要一個支援它的系統。我相信，只有當一線與組織兩方面都協調一致時，Agent 才能真正紮根。