AI Agent 是什麼？和 chatbot、workflow 差在哪（2026 定義與架構）

「AI Agent」在 2026 年已經變成一個過度使用的詞。客服機器人、公司內部的 ChatGPT wrapper、能幫工程師改 repo 的 coding assistant、能跨工具跑流程的自動化系統，都可能被包裝成 agent。

這造成一個問題：如果所有東西都叫 agent，那這個詞就失去判斷力。

比較有用的定義是這樣：AI Agent 是一種由模型、工具、記憶、規則與回饋迴圈組成的軟體系統。它接收一個目標，觀察環境，決定下一步，呼叫工具執行，再根據結果修正計畫。模型是引擎，但 agent 是整個系統。

簡短版：

Chatbot 回答問題。Workflow 執行預先寫好的流程。Agent 在工具與環境回饋之間，自己決定下一步怎麼完成目標。

這個差異不是文字遊戲。它決定一個 AI 應用能不能進入真實工作流。

三個容易混在一起的詞

先把 chatbot、workflow、agent 分開。

類型	控制權在哪裡	典型輸入	典型輸出	適合場景
Chatbot	使用者一輪一輪推進	一個問題或指令	一段回答	問答、改寫、摘要
Workflow	工程師預先寫好的流程	固定格式的任務	按步驟完成的結果	審核、分類、翻譯、資料清洗
Agent	模型根據狀態動態決策	一個目標	多步行動後的結果	coding、研究、客服處理、內部營運

Anthropic 在〈Building effective agents〉裡把 workflow 與 agent 做了清楚區分：workflow 是 LLM 與工具沿著預先定義的程式路徑被編排;agent 則是 LLM 動態指揮自己的流程與工具使用。

這也是實務上最重要的一刀。

很多產品宣稱自己是 agent，其實只是 workflow。這不一定不好。Workflow 可預測、便宜、容易除錯，在企業場景常常比 agent 更適合。真正的 agent 應該用在「無法事先寫死步驟」的任務上，例如修一個不確定會動到哪些檔案的 bug、研究一個需要多次查證的問題、處理一張需要查訂單、看政策、判斷例外狀況的客服工單。

Agent 的基本架構

最小可用的 agent 通常有五個部件。

部件	作用	例子
Model	理解目標、規劃、選工具、產生輸出	GPT、Claude、Gemini、開源模型
Tools	讓模型能做事	搜尋、讀檔、寫檔、GitHub API、CRM、資料庫
Memory / Context	保存任務狀態與外部資訊	對話紀錄、專案檔案、向量資料庫、短期 scratchpad
Policy / Guardrails	限制能做與不能做的事	權限、審核點、資料外洩規則、花費上限
Feedback loop	讓系統根據結果修正	工具回傳、測試結果、使用者確認、人工審核

如果只有 model，那是 chatbot。如果有 model 加工具，但每一步都由固定程式流程決定，那多半是 workflow。如果系統讓 model 根據觀察結果決定下一步工具與策略，才比較接近 agent。

ReAct 論文把這個模式寫得很早也很清楚：讓語言模型交錯產生推理痕跡與任務行動。推理幫助模型追蹤計畫與處理例外;行動讓模型連接外部環境，取得新的資訊。後來的 agent 系統大多可以看成這個思路的工程化版本。

Agent 的執行迴圈

一個 agent 的核心不是「會思考」，而是回饋迴圈。

目標
  ↓
觀察目前狀態
  ↓
決定下一步
  ↓
呼叫工具
  ↓
讀取工具結果
  ↓
更新狀態與計畫
  ↓
完成或繼續下一輪

拿「幫我修這個 GitHub issue」當例子。

Chatbot 會請你貼錯誤訊息，再給一段建議。

Workflow 可能會固定跑：讀 issue → 找檔案 → 產生 patch → 跑測試 → 回報。

Agent 則會先讀 issue，搜尋相關檔案，發現測試失敗，回頭改另一個模組，再跑測試，如果測試環境缺套件就判斷要安裝還是回報 blocker。它的每一步不是事先寫死，而是根據工具結果決定。

這也是 agent 有價值的地方：它能處理「中途才知道下一步」的任務。

2026 年常見的 agent 型態

1. Coding agent

Coding 是目前最容易落地的 agent 場景之一，原因不是模型特別愛寫程式，而是軟體工程有明確的環境回饋。

程式能被讀取、修改、測試、lint、build。錯了可以看到錯誤訊息，再迭代。這讓 agent 的行動有客觀驗證方式。Claude Code、Cursor agent mode、OpenAI Codex 類工具都在這個方向上演化。

但 coding agent 也不是「丟一句話就生出產品」。它比較像一個能在 repo 裡工作的 junior engineer:可以很快，但需要明確任務、測試、review，也需要知道專案慣例。

2. Research agent

Research agent 的任務是找資料、交叉比對、摘要、列出來源。它適合處理「需要多次搜尋與查證」的工作，例如產業研究、競品整理、政策變更追蹤。

風險在於 citation。Agent 如果找錯來源、誤讀文件、把二手解讀當成一手事實，輸出會很像真的。研究型 agent 必須要求來源列表、來源分級、可追溯引用，也要把「未確認」與「已確認」分開。

矽基前沿的 article schema 會保留 sources、keyClaims、lastVerified，就是同一個邏輯：讓 agent 和人都能回頭檢查每個聲稱從哪裡來。

3. Customer support agent

客服是另一個高潛力場景。客服 agent 不只是回答 FAQ，還可以查訂單、看會員狀態、判斷退費規則、開 ticket、把複雜案例轉給人。

這類 agent 的關鍵不是「語氣像人」，而是工具與權限設計。它能不能查到正確資料？能不能只做被授權的動作？遇到例外時會不會停下來問人？這些比模型分數重要。

4. Internal operations agent

企業內部有大量跨系統流程：整理週報、同步 CRM、檢查合約欄位、比對發票、追蹤專案狀態。這些流程常常不是單一 SaaS 能解決，而是散在 Google Workspace、Slack、Notion、Jira、ERP、資料庫裡。

Agent 的價值在於跨工具編排。但這也帶來最直接的風險：一旦權限設計錯，agent 可以把錯誤動作放大到多個系統。

MCP 為什麼重要

Agent 要能做事，就需要工具。工具越多，整合成本越高。

Model Context Protocol(MCP) 的意義在這裡：它試圖把「模型如何連到外部工具與資料」標準化。Anthropic 在 2024 年 11 月公開 MCP，把它定位成 AI application 連接資料源與工具的開放標準。這讓工具供應者可以寫一次 MCP server，再被不同 agent client 使用。

可以把 MCP 想成 agent 世界的接口層。它不是 agent 本身，也不是模型能力本身，而是讓 agent 有機會用一致方式取得資料與執行工具。

但 MCP 也讓治理問題更急迫。當工具接口變容易，錯誤工具、過大權限、惡意 prompt、未隔離的本機資源，都會變成更實際的攻擊面。對企業來說，MCP 的價值和風險是同一件事的兩面：它降低整合成本，也降低了 agent 觸碰真實系統的門檻。

為什麼 agent 不能只看 demo

Agent demo 很容易好看，production 很難。

原因有五個。

第一，錯誤會複合。 單次 LLM 回答錯一點，你可能看得出來。Agent 跑 20 步，第 3 步的小錯可能在第 17 步變成難以追蹤的錯誤結果。

第二，成本會乘上步數。 Chatbot 可能只呼叫一次模型。Agent 每一輪都可能要呼叫模型、工具、retrieval、檢查器。任務越開放，成本越難預估。

第三，延遲會變長。 使用者能接受聊天等 5 秒，但不一定能接受 agent 跑 12 分鐘還失敗。產品需要進度回報、取消、保存狀態與恢復。

第四，除錯很難。 傳統軟體有 stack trace。Agent 的錯誤可能是一串自然語言判斷、工具輸入、外部 API 回應與模型抽樣結果。沒有 tracing，就無法 productionize。

第五，權限是事故邊界。 Agent 如果只讀文件，錯誤多半是內容品質問題。Agent 如果能寄信、刪資料、改 CRM、下訂單、碰 production database，錯誤就是營運事故。

所以成熟的 agent 系統不會只問「模型多強」。它會問：

• 工具有沒有最小權限？
• 高風險動作是否需要人確認？
• 每一步是否有 log?
• 能不能重播與稽核？
• 有沒有成本與步數上限？
• 錯誤結果能不能回滾？

對台灣企業的判斷方式

台灣企業導入 agent，不該從「我們要做一個全自動 AI 員工」開始。比較務實的起點是找三種任務。

第一，流程邊界清楚。 例如客服查單、合約欄位檢查、例行報表整理、內部 knowledge base 查詢。這些任務有明確輸入、明確輸出、明確失敗判準。

第二，資料權限可控。 Agent 能碰到的資料越多，風險越大。早期應該用 read-only 或低風險工具開始，再逐步開放寫入與外部動作。

第三，能由人審核結果。 Agent 最適合先做 draft、整理、建議、預填。讓人批准後才送出，通常比一開始追求全自動更快進入 production。

台灣很多中小企業的機會不在訓練自己的模型，而在把既有流程整理成 agent 可用的工具與資料接口。換句話說，先把公司變成 agent-readable，再談 agent-native。

對 builder 的判斷方式

如果你正在做 AI 產品，可以用四個問題檢查自己是不是真的需要 agent。

1. 這個任務的步驟能不能預先寫死？如果可以，workflow 可能比 agent 更好。
2. 這個任務是否需要根據中途結果改變策略？如果是，agent 才有價值。
3. 這個任務的成功與失敗能不能被驗證？如果不能，agent 只會產生更多看似合理的輸出。
4. 這個任務的工具權限能不能被限制與稽核？如果不能，不要讓 agent 自主行動。

Anthropic 對 agent 的實務建議很接近這個方向：從最簡單的方案開始，只有在複雜度能換到可測量的效果時才加 agent。這句話對 2026 年的 AI 產品尤其重要。Agent 不是成熟度徽章，而是一種成本與風險都更高的系統設計。

一個實用定義

最後給一個可操作的定義：

AI Agent 是一個能在目標導向任務中，使用模型理解狀態與規劃行動，透過工具影響外部環境，並根據回饋持續修正的軟體系統。

這個定義刻意不把「完全自主」當成必要條件。真正的 production agent 常常需要人在 loop 裡。人不是失敗的補丁，而是系統設計的一部分。

2026 年的 agent 不該被理解成「AI 取代人操作軟體」。比較準確的說法是：軟體正在多一層新的介面。過去人透過 UI 操作系統;現在 agent 可以透過工具接口操作系統，人負責設定目標、審核高風險決策、處理例外。

下一個問題不是「agent 會不會來」。它已經在 coding、客服、研究與營運流程裡出現。真正的問題是：哪些任務值得交給 agent，哪些任務應該留在 workflow，哪些動作必須永遠保留人類審核。

把這三件事分清楚，才是 agent 進入工作現場的開始。