別為了AI而AI：從流程矩陣的減法思維，到多代理人階層架構的精準分流

在各類企業內訓與校園諮詢中，我經常遇到帶著焦慮前來的專案負責人：

「老師，我們部門想導入AI，能不能幫我們用大語言模型做一個自動審核報銷的系統？」 「老師，我們學校想做一個AI客服，能不能讓學生隨便打字，AI就自動去資料庫幫他選課？」

每當聽到這類宏大的願望，我通常會先按下暫停鍵，反問對方三個最根本的問題：

1. 這個流程如果現在用一張Google Sheets試算表人工勾選，每週會花掉多少分鐘？
2. 流程中卡住的地方，是因為文字理解太困難，還是因為各部門的資料欄位根本沒有對齊？
3. 如果模型產生了5%的幻覺判定錯誤，你們單位有誰願意在公文上簽章承擔責任？

多數人在回答完這三個問題後，眼神裡的興奮往往會轉變為沉默。

因為大家突然意識到：很多情境其實完全不需要AI。 盲目跟風的結果，只是把原本十行試算表公式就能解決的問題，包裝成一個運算成本高昂、回應延遲緩慢、且隨時可能出錯的黑盒子系統。

要避開這種「為了AI而AI」的資源浪費，我們必須先回歸工程思維的根本：先做減法，再做結構化；當確定有語意理解的不確定性時，才輪到AI登場。

一、 流程減法：先質疑需求，再談自動化

現代科技圈有一套被反覆驗證的流程優化準則：質疑需求 ➔ 刪除環節 ➔ 簡化流程 ➔ 加快運作 ➔ 最後才自動化。

很多人在接觸新科技時，直接跳過了前四步，把一個本來就充滿官僚廢話與重複勞動的病態流程，直接交給AI去「全自動執行」。在泥沙俱下的地基上蓋全自動流水線，產出的只會是高傳輸速率的垃圾。

我習慣把這套思考方式具象化為一張「業務流程減法矩陣表」。在動手寫任何程式碼或呼叫API之前，先把現有的工作步驟逐行填入：

透過這張矩陣的層層過濾，你會發現原本號稱需要「智慧化大語言模型判斷」的繁瑣專案，被刪減到最後，核心只剩下「表單自動寫入試算表」加上「依欄位關鍵字轉寄Email」。

這不需要用到任何模型Token，不需要訓練任何Prompt，甚至連伺服器都不用租。用最基礎的試算表與表單連動，半天之內就能上線穩定運作。

因為需要而想要，再進一步考量必要。把虛浮的包裝一層層剝掉，留下來的才是真實的痛點。

二、 資料架構先行：用關聯資料庫取代語言模型瞎猜

第二個常見的思維誤區，是把AI當作「資料庫關聯引擎」。

許多人抱怨：「為什麼我問AI某個客戶上個月買了什麼，它有時候會記錯、甚至編造出不存在的訂單？」 當我去檢查他們的後台資料時，往往令人哭笑不得：他們把客戶資料、收件地址、歷史購買紀錄與客訴留言，全部混雜成一大段未經清洗的純文字對話紀錄，然後期待AI能每次都從這團文字雜草中精確撈出答案。

這是設計者缺乏基礎的關聯式資料庫（Relational Database）概念。

在資料科學的視角裡，資訊必須依賴「欄位、資料型別與關聯鍵」來維持秩序：

當這兩張表格透過Customer_ID建立好關聯後：

• 客戶下十次訂單，地址只需要在客戶表儲存一次，不需要在每張訂單重複謄寫。
• 查詢客戶總消費金額，只需要一道標準的SQL語法或試算表SUMIF函數，耗時千分之一秒，計算準確度是百分之百。

如果這時候你偏要引進一個大型語言模型，把所有歷史文字丟給它去推算「這客戶總共花了多少錢」，你不僅要為每次查詢支付昂貴的運算費用，還要承擔機率運算帶來的算術誤差。

先把資料怎麼存、表格之間怎麼關聯定義清楚。 結構化資料該交給試算表與資料庫，確定性計算該交給傳統程式邏輯。只有當問題跨入「非結構化資料的理解與合成」時，才是AI的守備範圍。

三、 當真正需要AI時：多維矩陣派送與階層式AI Agent架構

當我們透過減法矩陣剔除了無效步驟，並透過資料庫思維固化了基礎數據後，剩下的工作往往才是真正需要AI介入的核心節點：例如使用者輸入了一段口語化的長句，或是上傳了一張雜亂的照片，系統必須理解其意圖並進行跨工具調度。

這時，系統設計不能只停留在「單一對話框」的玩具層次。

在我設計「輕量級雲端管理LINE Bot AI Agent」時，我所採用的正是多維矩陣狀態機（Multi-dimensional Matrix Routing）。

1. 矩陣狀態機的派送邏輯

面對使用者的非結構化輸入，系統第一步不是急著生成長篇大論，而是由主控模組進行意圖分類與狀態標定。

系統內部維護著一個狀態向量：

• [0, 0, 0]：常態監聽與身分驗證。
• [0, 1, 0]：辨識到檔案處理意圖，切換至雲端硬碟讀取與多模態分析模組。
• [0, 1, 1]：讀取完成，進入跨文件內容合成與簡報產出流程。

透過這種狀態矩陣的逐步推進，系統精準地控制了當前對話落在矩陣中的哪一個具體座標（例如階段二的步驟2-1）。每一個座標只掛載該步驟所需要的特定指令，杜絕了把所有規則塞在同一個Prompt裡所引發的邏輯混亂。

2. AI Agent的階層構造（Hierarchical Structure）

在系統底層，AI Agent的運作並非鐵板一塊，而是由內而外嚴密嵌套的四層架構：

• 最外層：Agent（代理人全體）： 它是面對外部世界的主體。在我的實作中，它對接LINE Messaging API與Web介面，負責接收使用者的文字、語音與照片，並把最終成果遞送出去。
• 第二層：MCP（Main Control Process 中央控制與決策核心）： 它是大腦的神經中樞。它根據當前收到的訊號與前述的矩陣狀態，評估目標差距，並決定下一步策略：「現在該調用哪個工具？是否需要向使用者追問？還是資料已經充足可以交卷？」
• 第三層：Skill（技能與能力）： 這是被封裝好的特定執行模組。例如「Google Drive檔案列表萃取模組」、「試算表日誌寫入模組」、「Markdown轉HTML排版模組」。它不負責長遠策略，只專注於接收參數並把單點任務執行到位。
• 核心層：File / Memory（記憶與知識庫）： 這是系統的長期資產。包含存放在Google Sheets裡的對話歷史日誌、掛載於Google Drive的參考文件（RAG），以及經過驗證的系統設定。

3. 工作流程的閉環檢驗

真正的AI協作流程，是一個由「感知、決策、行動與學習」構成的動態閉環：

當使用者拋出需求時：

1. 感知（Perception）： 系統解析輸入的文字語意、辨識圖片中的物件或收據品項。
2. 決策（Decision Making）： MCP參照內部知識庫的規則，比對當前的矩陣位置，推導出最適動作。
3. 行動（Action）： 執行腳本，產生實體檔案、發送通知或更新試算表。
4. 學習與優化（Learning & Optimization）： 將互動過程的執行成效（如成功派工或被使用者退件）寫回日誌，作為調整後續Prompt與流程權重的實徵依據。

結語：清醒的實踐者，懂得何時「不用AI」

當科技浪潮席捲而來時，最難能可貴的品質不是走在最前面盲目追新，而是隨時保持「批判與節制」的清醒。

不要把AI當成逃避思考的萬靈丹。

遇到任何問題時，先退一步，拿出紙筆或打開試算表：

• 先用減法矩陣把虛浮的環節砍掉；
• 用資料庫邏輯把實體的欄位與關聯排正；
• 當流程已經精簡到極致，面對剩下的非結構化語意挑戰時，再調用多維矩陣與階層式AI Agent，讓算力精準落在刀口上。

懂得在什麼時候「不用AI」，你才能在真正需要它的那一刻，打造出堅不可摧、言行一致的高效系統。

研究延伸閱讀

• Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A design science research methodology for information systems research. Journal of Management Information Systems, 24(3), 45-77. https://doi.org/10.2753/MIS0742-1222240302
• Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319-340. https://doi.org/10.2307/249008
• 施育廷（2026）。基於對話式介面之多源資訊整合與自動化內容生成之系統與方法 （中華民國發明專利證書號碼：I918530）。中華民國經濟部智慧財產局。Shih, Y. T. (2026). System and method for multi-source information integration and automated content generation based on conversational interface (Taiwan Patent No. I918530). Taiwan Intellectual Property Office.
• 施育廷、李政軒（2025年6月4日）。AI 輔助程式設計與數據分析學習中的人機互動行為分析【論文發表】。ICEET 2025 數位學習與教育科技國際研討會，臺北，臺灣。
• 施育廷、林育慶（2026年5月15日）。優化學習工作流輕量級無伺服器AI代理人之開發與成效分析【論文發表】。2026年工程、技術與STEM教育學術研討會，臺中，臺灣。

本文為作者於高等教育教學現場、無伺服器架構開發與人機協同系統設計之實務反思。