在生成式 AI 爆發的年代，「AI Agent」（人工智能代理）已成為各大企業轉型關鍵詞。許多行政總裁聽到 Microsoft Copilot 的威力，直覺便想在自家常用的 MS Office（如 Word、Excel 及 Outlook）開發專屬插件（Plug-in），認為這樣最貼合業務需求。不過若詢問資深開發者，他們大多會表示反對。將企業 Agentic AI 押注在 Office 插件為何是一個「大伏」？本文將拆解這個開發界的惡夢。
對於開發者而言，Office 365 雖然推行多年，但現實中企業環境的軟件版本極之混亂。雖然 Microsoft Support 經常教導用戶使用兼容性檢查器，但實際開發是兩回事。目前仍有大量企業用戶運行 Microsoft 已經停止支援的舊版本（Legacy versions），不同版本的 API、COM 物件模型甚至介面渲染方式完全不同。若想開發一個能自動撰寫文章、處理數據的 AI Agent 插件，開發者會發現需要處理的並非 AI 邏輯，而是無窮無盡的版本兼容問題（Version Management）。這種碎片化的開發環境令開發成本倍增，是開發社群中惡名昭彰的黑洞。
許多對技術一知半解的買家（Layman users）在招標（Tender invitation）時為求安心，往往強迫供應商承諾開發的插件必須支援所有 Office 版本。這種要求對於真正有實力且懂技術的供應商（Competent vendor）來說，根本是自殺式條約，通常他們會直接退標。結果接標的往往是實力不足、或為了搶單而先應承後打算的小型公司。他們在第一份合約點頭稱是，但到了實際部署及維護階段，便會發現買家預期的維護費用（Software Assurance）與實際投入的開發人力成本存在巨大鴻溝，最終導致項目難產或爛尾。
事實證明，大部分個人化的 Office 插件在部署後 2 年內便會被棄用。因為 Microsoft 每隔一段時間便會更新 Office JavaScript API，每當 Windows 或 Office 有重大更新，原本寫好的插件便可能出現 UI 崩潰或權限出錯。由於企業內部的 AI Agent 需要存取敏感數據，安全性更新（Security patches）更是家常便飯。供應商發現維護舊版本插件的成本高於重新撰寫，而買家又不願意再付費，結果插件會因為長期無人更新而失效。在 Microsoft Learn 上，關於開發錯誤及快取問題的排錯指南多不勝數，足以證明這條路極難行。
AI Agent 的精髓在於靈活交互，但 Office Add-ins 的 UI 限制非常大。開發者只能在預定義的任務窗格（Task Panes）或 Ribbon 按鈕中工作，無法深度個人化用戶體驗。若 AI Agent 需要複雜的工作流，例如彈出式視窗、動態圖表交互或跨視窗操作，Office 的框架會令開發者非常受挫。結果辛苦開發的 AI Agent 在用戶眼中只是一個住在側邊欄、反應遲鈍的聊天框，一如當年那個「萬字夾」Clippy，阻礙工作多於提供協助。
在 Office 內部運行 AI 插件，涉及極其複雜的權限管理。根據 Oleria 的安全研究
，過度授權是 AI 助手最大隱患。若插件需要讀取用戶的 Outlook 郵件或 SharePoint 檔案，開發者需要處理複雜的 OAuth 流程及 RBAC（角色存取控制）。一旦權限設定出現微小錯誤，AI Agent 便有可能在不經意間將敏感財務報表或個人資料洩漏給無權限的人。在一個封閉且版本不一的 Office 環境進行細膩權限管控，難度遠高於在獨立 Web 平台上運作。
Microsoft 的 AI 策略近期備受批評，其中一個原因就是過度整合導致系統變慢。若企業 AI Agent 以插件形式運行，會與 Word 或 Excel 爭奪系統資源。當 AI 在背景處理大數據或調用 LLM 時，用戶會感覺到明顯卡頓（Lags）或當機。對於追求效率的專業用戶來說，若開啟 Excel 也要等插件載入 5 秒，他們很快會在增益集管理中直接封鎖（Disable）該 AI Agent，令投資付諸流水。
AI Agent 的終極目標是橫跨不同系統完成任務，例如：在 Salesforce 獲取數據，再到 Outlook 撰寫 Email，最後在 Teams 通知老闆。若將 Agent 鎖死在 Office 插件中，其活動範圍便會被限制。雖然 Microsoft Agent 365 試圖統一這種混亂，但對於企業來說，將所有雞蛋放在 Microsoft 同一個籃中非常危險。一旦 Microsoft 更改訂閱條款或 API 收費，整套 AI 策略便會陷入困境。
企業想要成功部署 AI Agent，正確做法是將 AI 邏輯與介面「解耦」（Decouple）。應建立一個獨立的後端服務（如使用 Python 的 LangGraph 或 AutoGen 框架），並透過標準 Web Hook 或輕量化的介面與 Office 溝通，而非將核心邏輯寫死在脆弱的 Office 插件中。這樣做不但可以避開版本混亂的地獄，還能確保 AI Agent 具備真正的擴充性與維護性。
公司是否正打算招標開發 Office AI 插件？不如先檢視現有的軟件版本分佈，或考慮建立一個獨立的 AI 門戶網站作為中轉站，比起強行在 Word 中加個按鈕更實際。