【內容摘要】生成式AI正迎來從「ChatBot轉型為AI Agent」的關鍵典範轉移。本文首創以傳統網路OSI七層模型為對比，拆解Software 3.0時代商用級AI的「應用七層架構」，深入剖析Agent如何點亮L5工具執行層與L6邏輯編排層，長出雙手雙腳；實務上面對Agent的行動落地，本文深度剖析靈活狂野的CLI與安全結構化的MCP兩大技術路線之抉擇、資安風險與系統負載考量，最後再揭示Agent為了追求目標「抄捷徑」而違反企業內規的隱患，正式敲響企業AI行動治理的警鐘。

【TAG 關鍵字】#AI Agent #AI七層架構 #OSI模型 #CLI #MCP模型上下文協定 #工具調用 #系統資安 #商用AI落地 #AI治理

作者簡介

作者目前擔任凌群電腦資通技術處經理，現專職AI解決方案規劃與領導AI專案開發，並規劃凌群AI開發團隊之研究方向。

AI從單純的對話，走向行動

在前面的專欄中，我們透過提示工程為AI設定了初始與簡單的定義，又透過RAG或Fine-tuning架構為企業打造了專屬的AI知識庫大腦。

但走到這一步，我想許多人會發現一個共通的瓶頸，那就是…這個大腦再怎樣的聰明，它終究只是一個「AI ChatBot」，當我問它：「我們庫存還有多少？」它可以告訴我數字；但如果我說：「幫我向代理商追加1台設備」，這時的AI卻只能回答：「我只是一個語言模型，無法替您執行下單操作。」

倘若AI只能「對話」而不能「行動」，那麼它就永遠無法對企業生產力的提升產生任何的效益；想當然爾，人類的需求不會只停在這，會希望這聰明的AI還能去做更多的事，並不單單只是一個會說話的機器人，也因此為了實現這個需求，AI圈內從2025年中開始，一直到2026年初小龍蝦終於爆紅風靡全球，故也發展出了目前應用開發的最熱門主題—AI Agent。

傳統網路 OSI 七層 vs. AI 應用七層架構

要理解 AI Agent 是如何長出「手腳」的，我們可以用業界最熟悉的OSI七層網路架構來做一個概念上的對比與對應。

傳統的OSI模型定義了資料從實體網路線一路傳輸到應用程式的標準標準；而在Software 3.0時代，一個成熟的企業/商用級AI Agent應用，同樣也具備了層層疊加的「AI七層架構」：


資料來源：筆者自行整理

《圖說》圖片來源：AI生成

Agent的關鍵進化：代表L5的手腳與L6的中樞

一般的Chatbot，其能力只停留在L4的提示詞與L3的資料，它只能根據給定的知識生成文字。

但AI Agent則帶動了L5的工具執行層與L6的邏輯編排層，這就代表著，AI Agent可以透過L5去呼叫企業內部的ERP API、寄送電子郵件，甚至是執行直接Python程式碼；同時，它還具備L6的規劃能力，能夠將一個大任務拆解成多個步驟。

例如，當你說「幫我安排下午三點的會議室，再將會議通知一起發送給A同事」：

1.L6邏輯編排：Agent會自行思考：「我需要先查會議室的閒置狀態，預定可用的會議室，最後發送會議通知給大家。」
2.L5工具調用：它會依序呼叫「會議室預約系統」、「查詢會議室預約狀態」以及「Outlook寄送會議通知」。
3.完成行動：最終回報給你「已完成預約，會議通知已連同A同事一起寄到信箱了」。

這就是從「對話」到「行動」的跨越。

Agent長出手腳的兩條路：CLI與MCP的使用抉擇

這裡做個重要的補充，目前在實務上，關於如何讓Agent動手？目前業界主流有兩條完全不同的技術路線：

《路線一》CLI：

自由、簡單但無限的CLI就像是賦予了AI一個隱形的系統終端機與鍵盤作為手腳，讓它能像資深工程師一樣直接下達系統指令(例如bash或script腳本)。

情境說明：當你向AI提出「幫我把伺服器裡某個資料夾下的所有docx檔轉成PDF並壓縮成zip」；Agent會直接在底層終端機輸入指令與OS原生的壓縮指令來完成這項工作。

優點：非常的靈活，只要OS能做的事，它幾乎都能做，開發上不需要為每一個小動作去刻意寫一支API，可以使用者隨講AI即用。

缺點：資安風險極高，如果沒有嚴格的Sandbox隔離，AI可能會因為一句錯誤的指令把整個系統刪光。案例參考出處給讀者們參考-鉅亨號。GPT-5.6被曝重大bug！矽谷大佬Mac被一鍵清空。2026年07月12日，取自：https://hao.cnyes.com/post/258567。

《路線二》MCP：

安全且標準化的萬用傳輸線 為了解決CLI難以控制且功能有限的痛點，Anthropic帶頭推動了MCP，我們可以把它想像成「AI 專用的 USB-C 標準介面」，企業透過MCP伺服器，將內部的資料庫或ERP系統包裝成結構化的工具，安全地附加到Agent身上。

情境說明：當你要求 Agent「查閱某A專案的履約截止日，並向專案團隊發送提醒信」，Agent不會去亂翻系統檔案，而是透過 MCP標準格式呼叫get_contract(project_A)以及send_email(project_member)這兩個明確的工具。

優點：伺服器端通常會有嚴格的資安架構，Agent只能看見並使用MCP 伺服器允許調用的工具，完全杜絕了AI在系統底層亂執行的風險，而且跨系統的整合也能變得標準化。

缺點：建置成本較高，企業必須投入額外的開發資源，為現有的老舊系統撰寫MCP，無法像CLI那樣直接使用。

這段補充的內容比較多，以結論來說，筆者目前認為CLI可做為消費級或一般使用者端的Agent應用，可避免伺服器資源過度消耗，畢竟一家企業若導入了AI，相信使用者約莫可達上百上千甚至是上萬規模，故此時也必須考慮系統整體架構的負載量以及最重要的資訊安全之設計，而MCP肯定還是企業級AI Agent落地的唯一標準，適合用於AI系統/平台的應用模組使用。


《圖說》圖片來源：AI生成

失控的捷徑：當 AI 的行動沒有邊界

請記得，無論我們選擇CLI或是更安全的MCP，都是在賦予AI雙手，等於是打開了AI這個潘朵拉的盒子。

我們想像一個情境，開發了一個「退貨處理Agent」，透過MCP連接到公司的訂單資料庫，並給予了它執行退款指令的權限，然後我們的目標是「提高顧客滿意度並解決退貨爭議」。
然而有一天，一位客戶來信抱怨商品有微小瑕疵。

如果是一般正常的客服SOP可能是：先道歉→判斷瑕疵→提出補償10%折扣金→若不接受，再進入退款流程。

但AI Agent是一支追求「最高效率達成目標」的演算法模型，為了極大化「提高顧客滿意度」這個目標，它可能在收到信的瞬間，直接跳過所有溝通，動用它的系統權限發放了100%全額退款，然後又霸氣地回覆客戶「商品不用退了，錢也直接退款給您」。

目標達成了嗎？達成了，客訴瞬間結案，客戶也確實會超級滿意。

但對企業的流程來說合理嗎？我相信是完全不合理的，因為它嚴重違反了企業的內規與成本控管流程。

這就是AI Agent最大的隱患：如果不加限制，它每一次採取的步驟與流程都可能不同，雖然條條大路通羅馬，但有些大路會讓你面臨嚴重的合規風險與企業災難。

既然我們不能讓Agent像脫韁的野馬一樣隨意調用工具，我們該如何為它的行動套上韁繩？這就帶出了我們下一期的關鍵主題：「讓 AI 照著 SOP 走：Agent Skills 的設計與企業 AI 治理」。