作者：Gask Hung｜蓋斯克科技｜最後更新：2026-09-04
過去兩年，很多公司買了 ChatGPT 或 Copilot 的企業版，用了一陣子之後發現一件事：它很會回答問題，但公司真正想省下來的那些工，一件都沒少。報表還是要人去跑，訂單還是要人去key，客戶信件還是要人一封一封回。會聊天跟會做事，中間隔著一整層架構，而這層架構就是 AI Agent 在處理的事情。
📋 本文重點摘要
- AI Agent 跟聊天機器人的差別不在模型多聰明，在於它會不會「循環」：想一步、動手做一步、看結果、再決定下一步。
- 一個能用的 Agent 由四個模組組成：大腦（模型）、規劃、記憶、工具。缺工具就只會講，缺記憶就每次從零開始。
- 企業導入最該先問的不是「要不要用 Agent」，而是「這個流程的步驟固定嗎」。步驟固定就用 Workflow，成本低又好稽核；步驟開放才需要 Agent。
- Function Call、MCP、Skills、A2A 是四層不同的東西，不是四個競品：分別解決「能不能調用工具」「怎麼統一接工具」「知不知道該怎麼做」「Agent 之間怎麼溝通」。
- MCP 與 A2A 在 2025 年底到 2026 年間都已交給中立基金會治理，代表這兩個協議可以當成企業採購時的長期標準來看，不再是單一廠商的私有規格。
👤 適合閱讀對象
正在評估要不要導入 AI 的中小企業決策者、被交辦「研究一下 Agent」的 IT 與 MIS 負責人、想把部門重複流程交出去的行銷業務客服主管
不確定公司哪個流程適合交給 AI Agent？加 LINE 傳一份你想自動化的作業流程說明，我們先幫你判斷該用 Workflow 還是 Agent → 加 LINE 諮詢
這篇文章不談論文、不推特定產品，只把導入前你一定會遇到的名詞跟判斷邏輯講清楚。看完之後，你至少能在會議上分辨出：業務簡報裡講的那個「AI Agent」，到底是真的自主決策，還是一條包裝過的自動化流程。這兩者的價格跟維護成本差很多。
這篇文章寫給誰看
- 已經付費用 AI、但沒感覺省到人力的公司：想知道問題出在工具還是用法。
- 被老闆要求評估 AI Agent 的 IT 負責人：需要一套能拿去跟廠商對話的判斷框架。
- 正在被廠商推銷 Agent 方案的採購或決策者：想確認報價裡的東西到底有沒有必要。
- 考慮把 AI 放在自己機房、資料不外流的企業：想先搞懂架構，再決定硬體要買到什麼規格。
一、AI Agent 跟你現在用的 ChatGPT 差在哪？
差別不在模型聰不聰明，在於它會不會進入「循環」：思考一步、實際動手做一步、看結果、再決定下一步，直到任務結束。聊天機器人是你問一句它答一句，答完就停。Agent 收到目標之後不會停，它會自己判斷還缺什麼、該去拿什麼，一路做到底。
一個好懂的比喻：大語言模型像是一位很資深的顧問，你問他辦公室網路該怎麼規劃，他能講得頭頭是道，但他不會替你打電話叫料、不會爬上天花板拉線。Agent 則是接了案的工班負責人，你跟他說「把這層樓的網路弄好」，他會自己去現勘、開料單、排師傅、遇到樑柱擋住就改路徑，做完回報你。顧問給的是答案，工班給的是結果。
用一個具體的指令來對照最清楚。你說：「查一下下週三台北會不會下雨，不下雨就把戶外拍攝排進行事曆。」
聊天機器人會告訴你可以去哪裡查天氣、行事曆怎麼新增事件。Agent 會直接去呼叫天氣服務拿到當天預報，判斷條件成立，再去呼叫行事曆建立活動，最後回你一句「排好了」。前者交付的是說明書，後者交付的是完成狀態。
這個差別放到企業場景就是成本的差別。說明書要有人照著做，完成狀態不用。但同時要注意，能自己決定下一步的系統，也代表它可能決定錯，這是後面談風險控管時的重點。
二、為什麼「很會聊天」不等於「能把事做完」
純粹的大語言模型有四個先天限制，Agent 的整套架構基本上就是為了逐一補這四個洞而長出來的。
限制一：只能輸出文字，碰不到任何系統
模型本質上是在預測下一個字。它可以把 SQL 寫得很漂亮，但它不會自己連到你的資料庫去跑。你請它「幫我把這張報價單寄給客戶」，它能把信寫好，寄出去這個動作它做不到。能力被關在對話框裡，是最根本的一個限制。
限制二：對話結束就忘光
你花了一個下午跟它交代公司的報價規則、客戶的特殊條件、哪幾家不能給折扣。隔天開新對話，這些全部歸零。企業用起來特別痛的地方在這裡：規則要一講再講，每個同事各講各的，輸出品質就不可能穩定。這一塊該怎麼處理，我們另外寫過一篇專門談AI Agent 記憶系統的文章，裡面有四種記憶方案的比較。
限制三：只知道訓練時看過的東西
你問它今天的匯率、這個月的庫存、上週的訂單狀況，它答不出來，但它常常會裝作答得出來。這就是俗稱的幻覺。模型的知識有截止日期，而且不會自己去查證。對企業來說，一個會用很肯定的語氣講錯數字的系統，比一個直接說不知道的系統危險得多。
限制四：不會把大任務拆成小步驟
丟一句「幫我做競品分析」給模型，它會一口氣生出一大段文字。它不會先想「我該先蒐集哪些資料、從哪幾個面向比較、缺的部分去哪裡補」，然後分頭去執行。它是被動的，你問什麼它答什麼，不會自己安排工作。
把這四個限制擺在一起看，Agent 要做的事情就很清楚了：給它手腳（工具）、給它記事本（記憶）、給它查證的管道（外部資料）、給它排工的能力（規劃）。
三、Agent 的四個模組：大腦、規劃、記憶、工具
不管廠商包裝成什麼名字，拆開來看都是這四塊，缺任何一塊，那個東西就不該叫 Agent。採購時可以直接拿這四項去問，對方答不出來或閃躲，通常代表那是一套自動化腳本外面包了一層對話介面。
| 模組 | 負責什麼 | 缺了會怎樣 | 採購時該問的話 |
|---|---|---|---|
| 大腦（模型） | 理解意圖、推理、決定下一步 | 整套系統的判斷品質就是這裡的天花板 | 用哪個模型？跑在誰的機器上？資料會不會出境？ |
| 規劃 | 把大任務拆成可執行的步驟 | 只能做單一動作，複雜任務接不起來 | 遇到多步驟任務，它是自己排還是照寫死的流程走？ |
| 記憶 | 記住當下的進度，以及跨對話的長期規則 | 每次都要重講一次公司規則，輸出不穩定 | 公司的作業規則存在哪？換一個同事使用還記得嗎？ |
| 工具 | 實際去呼叫系統、查資料、執行動作 | 只會產生建議，不會產生結果 | 能接我們現有的 ERP／CRM 嗎？權限怎麼控？ |
四塊裡面最容易被低估的是記憶與工具。模型可以換、規劃邏輯可以調，但要把 Agent 接進公司既有的系統、把權限切乾淨，這是實打實的整合工程，也是導入專案裡最花時間的部分。
四、Agent 的四種工作模式怎麼分
四種模式對應四種做事方法，差別在成本、速度跟品質的取捨，實務上經常混用而不是二選一。
模式一：邊想邊做（ReAct）
最基礎也最常見的一種。流程是想一下、做一個動作、看結果，然後回到想一下。像你出差前打包行李：先查天氣，看到會下雨，想到要帶傘，拿了傘之後又想到還沒確認飯店，再去查訂房。每一步都根據上一步的結果決定。
好處是每一步的思考過程都看得到，出錯容易追。壞處是每一步都要讓模型重新想一次，用量會累積得很快，而且有機會卡在原地反覆做同一件事。
模式二：先規劃再執行
先把整份清單列出來，然後照著清單一項一項打勾。規劃只做一次，執行階段不用每步重新思考全局，用量會比邊想邊做省。代價是彈性差：做到第三步發現狀況跟預期不同，原本的計畫可能就不適用了。實務上的折衷是在中間插入幾個檢查點，執行幾步就回頭確認計畫還成不成立。
模式三：做完自我檢查
做完不急著交出去，先自己審一遍再修。可以是同一個 Agent 換成審查者的角色回頭看自己的產出，也可以是一個負責寫、另一個負責挑毛病，來回幾輪直到過關。對品質要求高的產出特別有用，代價是時間跟成本都會往上加。
模式四：多個 Agent 分工
任務太複雜時，改成一組人做：一個負責拆解需求、一個負責找資料、一個負責產出、一個負責檢查。聽起來很理想，但要提醒的是，多 Agent 架構會把除錯難度往上推一大截——出問題時你得先找出是哪一個環節判斷錯，而它們之間的交接本身也會出錯。
導入的順序建議反過來：先用最簡單的做法試，真的撞到牆再加複雜度。很多公司一開始就上多 Agent，結果是花了三倍的錢，得到一個沒人敢放進正式流程的系統。
五、Workflow 還是 Agent？導入前最該先問的一個問題
先問這個流程的步驟固不固定。固定就用 Workflow，成本低、跑得穩、出事好查；只有在步驟無法事先窮舉時，才需要付出 Agent 的成本與不確定性。
用退款申請來對照。Workflow 的做法是工程師事先把流程寫死：收件、抽出關鍵資訊、查訂單、比對退款政策、執行退款或發拒絕信、通知客戶。每一步走哪條路都寫在程式裡，模型只是在其中幾個步驟被叫出來做理解跟判斷。
Agent 的做法是你只給它「處理這件退款申請」，它自己決定要先看什麼、需不需要查政策文件、要不要問客戶補件。每一步都是它當下判斷出來的。
| 比較項目 | Workflow（預先編排） | Agent（自主決策） |
|---|---|---|
| 誰在控制流程 | 程式碼，工程師事先定好 | 模型，執行時自己決定 |
| 行為可預測性 | 高，同樣輸入得到同樣路徑 | 低，同樣輸入可能走不同路徑 |
| 運算成本 | 較低，只在特定步驟呼叫模型 | 較高，每一輪決策都要推理 |
| 出錯時追查 | 容易，知道卡在第幾步 | 困難，要重建當時的判斷脈絡 |
| 面對意外狀況 | 差，沒寫到的情況就中斷 | 好，能自己找替代路徑 |
| 適合的場景 | 報表產出、資料轉檔、固定審批、法遵要求高的作業 | 客訴處理、資料調查、需求不明確的探索型任務 |
實務上的答案通常是混用。整體流程用 Workflow 控住，只在「處理」這種真的需要臨場判斷的環節放 Agent 進去。金流、開單、修改資料庫這類動作留在 Workflow 裡，讓它照規矩走。
還有一個現實面的理由：稽核。如果這個流程未來要面對外部查核，或牽涉到金額與個資，可預測、可重現的 Workflow 遠比自主決策的 Agent 好交代。
六、Function Call、MCP、Skills、A2A 一次分清楚
這四個名詞常被擺在一起講，但它們處在四個不同的層次，不是四個互相競爭的選項。用新人到職來類比最好懂：Function Call 是他學會打電話，MCP 是公司有一本統一的通訊錄，Skills 是他手上的職務手冊，A2A 是跨部門同事之間的溝通規矩。
| 名詞 | 解決什麼問題 | 在哪裡執行 | 本質是什麼 |
|---|---|---|---|
| Function Call | 模型怎麼告訴程式「我要呼叫這個功能、參數是這些」 | 你自己的應用程式 | 一種輸出格式約定 |
| MCP | 大量工具怎麼用統一標準接上來，不必每接一個寫一套 | 外部的 MCP 伺服器 | 一種通訊協定 |
| Skills | Agent 知不知道這類任務該用什麼方法、遵守什麼規範 | Agent 的上下文之內，不對外呼叫 | 一份用自然語言寫的作業指引 |
| A2A | 不同團隊、不同框架做的 Agent 之間怎麼互相發現與委派任務 | Agent 與 Agent 之間 | 一種通訊協定 |
Function Call：讓模型能開口叫工具
OpenAI 在 2023 年 6 月推出，現在主流模型幾乎都支援。要注意一個常被誤解的地方：模型本身並不執行任何函式。它只是輸出一段結構化的指令說「我想呼叫 get_weather，參數是台北」，真正去呼叫、去連資料庫的是你自己的程式。這個分工很重要，因為權限控管、錯誤處理、稽核紀錄全都在你這一側，不在模型那一側。
MCP：把 N×M 的整合變成 N+M
假設你有 3 個 AI 應用要接 5 個內部系統，土法煉鋼要寫 15 套介接。MCP 由 Anthropic 在 2024 年 11 月提出並開源，做法是讓每個 AI 應用實作一次用戶端、每個系統提供一次伺服端，兩邊就能自動對接，介接數量從相乘變成相加。
對企業採購來說，2025 年 12 月的變化比技術細節更值得記：Anthropic 把 MCP 捐給 Linux Foundation 底下的 Agentic AI Foundation，改由社群治理。這代表它從單一廠商的規格變成中立標準，OpenAI、Google、Microsoft 都已採用。押在這個標準上的長期風險，比押在任一家廠商的私有介面低。
Skills：把「該怎麼做」寫下來
工具解決的是「能做什麼」，Skills 解決的是「該怎麼做」。有廚房不代表會做菜，還需要食譜。實務上它就是一份 Markdown 檔，寫明什麼情況下啟用、要按什麼步驟走、輸出要長什麼樣子。
Anthropic 在 2025 年 12 月把這個格式開放成公開規格，之後陸續被多家開發工具採用。對企業真正的價值在於：老師傅腦袋裡的判斷順序、公司內部的作業規範、報價的眉角，這些過去只能靠帶人傳承的東西，現在可以寫成檔案讓整個團隊的 AI 共用。這也是導入 AI 時最容易被跳過、卻最影響成效的一步。
A2A：Agent 之間的溝通規矩
MCP 處理的是 Agent 對工具，A2A 處理的是 Agent 對 Agent。Google 在 2025 年 4 月發布，同年 6 月捐給 Linux Foundation，2026 年 8 月轉由 Agentic AI Foundation 託管，截至 2026 年 4 月已有超過 150 個組織支持。
它要解決的場景是這樣：新人到職時，人資的 Agent、資訊的 Agent、財務的 Agent 需要協作，但它們可能是不同團隊用不同框架做的，彼此不認識。A2A 定義了一張「能力名片」讓它們互相辨識，再用標準化的任務生命週期來委派與追蹤。
兩個協議的定位可以這樣記：MCP 是直的，處理 Agent 往下接工具；A2A 是橫的，處理 Agent 之間橫向協作。兩者是互補設計，同一套系統可以同時用。資料來源：Model Context Protocol 官方規格與 Linux Foundation／Agentic AI Foundation 公開聲明。
對大多數中小企業來說，A2A 目前還是先了解、不急著採用的階段。它真正發揮價值的前提是公司內部已經有好幾個各自獨立的 Agent 在跑，多數企業還沒到那一步。
七、企業導入 AI Agent 最常見的 4 個誤解
這四個誤解的共同點，是把 Agent 當成買一套軟體，而不是改一段流程。
誤解一：模型換成最強的，效果就會好
模型只是四個模組裡的一個。如果公司的作業規則沒有整理過、內部系統沒開介接、權限沒切乾淨，換再強的模型也只是把錯的事情做得更快。實務上，導入卡住的原因八成不在模型，在資料跟流程。
誤解二：讓它全自動跑，不用人管
凡是會動到錢、動到客戶、動到資料庫的動作，都應該保留人工確認這一關。做法是讓 Agent 把要寄的信、要送的單準備好，停在那裡等人按下確認。多這一個動作，就能擋掉判斷錯誤造成的實際損失。這不是不信任 AI，是任何自動化系統該有的閘門。
誤解三：用雲端服務就好，不用管資安
Agent 跟聊天機器人在資安上的差別很大：聊天機器人只看得到你貼給它的內容，Agent 有工具權限，能主動去讀你的系統。一旦它被誘導做出錯誤判斷，影響範圍是它拿得到的所有東西。所以權限要用最小範圍給，而不是先開好開滿再說。
如果公司的資料本來就不宜外流，那該考慮的是把模型放在自己機房。這條路的硬體、模型授權與費用，我們整理在地端 LLM 建置完整指南；主機該怎麼隔離、防火牆規則怎麼開，則另外寫在AI 防火牆建置那一篇。
誤解四：先買再說，之後再想要用在哪
這是最花錢的一種。正確順序是先挑一個明確、重複、目前確實在吃人力的流程，把它做通、量出省了多少工，再考慮第二個。一次要做五件事的專案，通常五件都做不完。
八、導入前先確認的三件事
在談任何報價之前，這三件事先確認清楚，可以省掉大部分白花的錢。
- 這個流程的步驟固定嗎：固定就別買 Agent，用自動化流程做，成本差很多。這一題答錯，後面全錯。
- 資料能不能出公司：能，雲端服務最快上線。不能，就要往地端規劃，硬體規格與預算要一起評估。這一題決定的是整個架構走向，不是細節。
- 誰負責看著它：Agent 不是裝完就結束，它會需要有人定期看它做了什麼、規則要不要調。公司裡如果沒有這個角色，導入後多半會慢慢荒廢。
蓋斯克在這一塊的角色偏基礎建設：網路、主機、隔離、備援這些讓 AI 能穩定跑起來的底層。如果你已經確定要走地端，或是需要有人幫忙盤點現有環境撐不撐得住，可以直接預約一次免費諮詢，我們先看環境再談要不要動。
結論
三個最值得記住的重點。
第一，Agent 跟聊天機器人的差別是「會不會循環」，不是模型的參數大小。第二，步驟固定的流程用 Workflow 就好，Agent 的成本與不確定性只該花在真的需要臨場判斷的地方。第三，Function Call、MCP、Skills、A2A 是分層互補的四件事，其中 MCP 跟 A2A 都已經交給中立基金會治理，可以當成比較安全的長期押注。
最後提醒一句：導入的難度通常不在 AI，在把公司既有的流程跟規則講清楚。這件事沒有捷徑，但做過一次之後，後面每一個流程都會快很多。
想導入 AI，但不確定現在的網路跟主機撐不撐得住？
蓋斯克科技專注在企業網路與 IT 基礎建設，包含地端 AI 主機的硬體評估、網段隔離與防火牆規劃。我們不賣模型，只確保你要跑的東西有一個穩定的底。先看環境、再談需求，現場勘查不收費。
看地端 LLM 建置指南 免費預約諮詢電話：02-2717-1019 LINE：加 LINE 諮詢
🔗 延伸閱讀：AI Agent 記憶系統完全指南｜中小企業 AI 代理部署指南｜LLM 主機規格怎麼抓｜IT 委外服務
參考資料
- Model Context Protocol 官方文件（MCP 規格與架構）
- Linux Foundation：Agent2Agent Protocol Project 成立聲明
- A2A Protocol 官方網站（Agent Card 與任務生命週期定義）
- OpenAI Function Calling 官方文件
