AI Agent 是什麼：從 ChatGPT 到會自己做事的 AI

你一定聽過「AI Agent」這個詞，但多數解釋要嘛塞滿術語，要嘛抽象到讓人抓不到重點。這篇文章只解決一個問題：講清楚 Agent 到底是什麼、它跟你每天在用的 ChatGPT 差在哪、它適合做什麼事、又會在哪裡失敗。不需要任何程式基礎，出現術語時我們會當場解釋。

先搞清楚：LLM 本身只會「講話」

要理解 Agent，得先理解它的核心零件——LLM。LLM（Large Language Model，大型語言模型）是讀過海量文字、學會「接話」的 AI 模型，ChatGPT、Claude、DeepSeek 的底層都是它。LLM 做的事本質上只有一件：給它一段文字，它接著寫出下一段文字。

這個「只會接文字」的特性，帶來三個先天限制：

1. 拿不到新資訊。 模型的知識停在訓練資料的截止點。你問它今天的股價，它只能「寫出」一個看起來像股價的答案，很可能是編的。這種「一本正經地說出不存在的內容」的現象，術語叫幻覺（hallucination）。
2. 做不了動作。 它可以寫出「我建議您預訂會議室」，但它自己訂不了。它沒有手，只有嘴。
3. 沒有記憶。 每一次 API 呼叫（API 是程式之間互相要求服務所用的標準介面）都是獨立的，模型預設不記得你上一句說過什麼。聊天軟體看起來「記得」對話，其實是每次都把整段對話紀錄重新傳給它。

Agent 就是為補齊這三個缺口而生的工程方案。

Agent = LLM + 上下文 + 工具 + 循環

剝掉所有行銷話術，任何一個 Agent 都由四個零件組成。

零件一：LLM，大腦。 負責理解指令、分析狀況、決定下一步做什麼。

零件二：上下文（context），大腦每一輪看到的全部資訊。 包括你的指令、對話歷史、工具執行回傳的結果、你額外補充的背景資料。因為模型沒有記憶，所有資訊都必須每一輪重新以文字塞給它。上下文的品質直接決定 Agent 的表現——餵給它錯的資訊，它就會做出錯的決定。

零件三：工具（tools），手腳。 一份「模型可以挑選的動作清單」，每個工具都有名字、用途說明與需要的參數。查天氣、搜尋網頁、執行程式碼、修改檔案、寄送郵件，都是工具。模型從清單中挑一個、照說明填好參數，由外層程式真正去執行。

零件四：循環（loop），串起大腦與手腳的神經。 這是 Agent 的靈魂。程式不是只問模型一次，而是跑一個迴圈：模型決定下一步 → 程式執行工具 → 把結果塞回給模型 → 模型再決定下一步 → 一直到模型判斷任務完成，輸出最終答案為止。

畫成流程圖：

        你給 Agent 一個目標
               ↓
   ┌→ LLM 思考：下一步做什麼？ ←────────┐
   │        ↓                ↓          │
   │    需要用工具         任務完成      │
   │        ↓                ↓          │
   │   程式執行工具      輸出最終答案，結束
   │        ↓
   └─ 把工具結果塞回上下文

一句話總結：Agent 是一個讓 LLM 自己決定「下一步做什麼」、並且真的有能力去做的循環。

下面這張圖把同一個循環畫細一點，補上上面省略的兩個環節：權限閘門與沙箱。點右下的箭頭可以逐步看，也可以放著讓它自己跑。

1/8使用者請求

任務用自然語言進來。harness 要把它變成模型能處理的東西。

第 1 步，共 8 步 使用者請求

定義很簡單，但請注意一個常被忽略的事實：四個零件裡只有 LLM 是「模型」，其餘三個都是工程師寫的普通程式。一個系統是不是 Agent，跟它用了哪家模型關係不大，跟模型外圍的程式怎麼寫關係很大。

聊天機器人 vs Agent：三條判斷線

同樣是「跟 AI 對話」，聊天機器人和 Agent 的差別可以用三條線判斷：

判斷線	聊天機器人	Agent
誰決定下一步	你。每一輪都要人類追問推進	模型自己。循環持續運轉直到任務完成
能不能呼叫工具	不能，內容全靠模型「回憶」出來	能，會實際執行並拿到真實結果
能不能多輪迭代	一問一答，答錯等你糾正	多輪試錯，自己重試、自己修正

舉一個具體的例子。你說：「幫我查台北明天的天氣，如果可能下雨，把我下午的野餐改到星期四。」

聊天機器人的回應大概是：「我無法查詢即時天氣，請您自行查看天氣應用程式；若下雨建議改期。」它只能說。

Agent 的執行過程則是這樣：

1. 呼叫天氣工具查台北明天的天氣 → 拿到真實回傳，例如「降雨機率偏高」
2. 自己判斷這算「可能下雨」→ 決定要改期
3. 呼叫行事曆工具，把野餐行程移到星期四
4. 回報你：「明天降雨機率高，已幫你把野餐改到星期四下午」

關鍵差異在第 2 步：程式裡沒有一行寫死「如果降雨機率超過某個數字就改期」——「算不算下雨、要不要改、改到哪天」是模型當場根據你的自然語言指令決定的。你給的是目標，不是步驟。

這也是 Agent 與傳統自動化腳本的本質區別：腳本的每一步路徑都由人寫死，遇到沒預料過的狀況就卡住；Agent 的路徑由模型現場規劃，能處理「寫程式時無法窮舉」的狀況。代價是它的行為也更難預測——這點我們在失敗模式一節會展開。

三個具體例子

日常：行程規劃助手

你說：「幫我安排三天東京自由行，我喜歡美術館，行程不要太趕。」Agent 會自己拆解任務：搜尋你旅行日期間的展覽（搜尋工具）、確認各場館的開放時間（網頁擷取工具）、評估地點之間的移動時間（地圖工具），最後產出一份逐日行程。如果它發現某個美術館在你排的第二天休館，會自己調整順序重排，而不是等你發現問題再重問一次。你得到的是一個「結果」，中間十幾次工具呼叫你完全不用管。

開發：會改程式碼的 coding Agent

這是目前 Agent 落地最成熟的方向。你對一個 coding Agent（例如 Claude Code 這類在終端機裡操作的程式助手）說：「幫這個登入模組補上單元測試，並讓測試全部通過。」它會自己讀取相關原始碼檔案（檔案工具）、寫出測試程式（編輯工具）、在終端機執行測試（執行工具）、看到哪些測試失敗、回去改程式、再跑一次——直到全數通過才停。開發者的角色從「一行行寫」變成「審查它的產出」。想知道這類工具實際怎麼運作，可以看 Claude Code 完全指南。

商業：客服工單處理

客戶來信：「我收到的商品型號不對，想退款。」一個部署在客服系統的 Agent 會：查這位客戶的訂單紀錄（訂單系統工具）→ 檢索公司的退款政策（知識庫檢索工具）→ 依政策草擬回信、發起退款流程 → 如果退款金額超過公司設定的門檻，停下來轉給人類審核。

這裡的知識庫檢索用到一項叫 RAG 的技術（Retrieval-Augmented Generation，檢索增強生成）：先從文件庫撈出相關文件，再讓模型「看著文件」回答，而不是憑記憶回答——這樣政策條文才有依據、才能減少幻覺。想深入可看 RAG 深度解析。

三個例子有一個共同點：任務的中間步驟無法事先寫死在程式裡，需要模型隨機應變。 這正是 Agent 的適用邊界，反過來說，也是判斷「該不該用 Agent」的標準。

能力邊界與失敗模式

Agent 很強，但它的失敗方式也很特別。以下五種是實務上最常見的失敗模式，每一種都附帶標準的緩解手段：

一、幻覺。 模型在不確定時會編造內容：編造工具沒回傳過的「查詢結果」、引用不存在的資料。緩解方式：關鍵事實一律以工具的真實回傳為準，並要求 Agent 附上出處；對數字、日期、人名這類硬性資訊做程式化校驗。

二、迴圈失控。 Agent 卡住，反覆執行同一個失敗的動作不停下來。因為每一輪循環都是一次真實的 API 呼叫、要付真實的錢，失控的 Agent 會安靜地把預算燒光。緩解方式：設定最大迭代次數（例如跑滿若干輪就強制停止），加上「連續重複相同動作」的偵測。

三、錯誤傳播。 第一步的小錯，被後面每一步當成事實繼續用。任務鏈越長，整體成功率越低——這是乘法效應，不是加法效應。緩解方式：把長任務拆成多個短任務，段落之間加入檢查點，由程式或人類驗證後再繼續。

四、權限誤用。 擁有「刪除檔案」「寄送郵件」「操作資料庫」工具的 Agent，是真的會做這些事的。當模型判斷失誤或被惡意內容誤導時，動作會直接發生在真實世界。緩解方式：最小權限原則（只給完成任務所需的最小工具集）、高風險動作加人類確認關卡、在隔離環境中執行。

五、殺雞用牛刀。 如果一個流程的每一步都是固定的、永遠不會變，那寫普通程式或自動化工作流就好，比 Agent 更穩定、更便宜、可預測。Agent 的成本與不確定性，只有在你「無法窮舉步驟」時才值得付。

一個簡單的決策標準：步驟寫得死，用腳本；步驟寫不死、需要看情況決定，才用 Agent。 而且就算用了 Agent，也應該把它關在明確的邊界裡——有限的工具、有限的預算、有限的權限，加上人類覆核的關鍵節點。「全自主」不是目標，「可控地完成任務」才是。

常見誤解

最後破除三個最常見的誤解，順便講一個新手最容易踩的坑。

誤解一：「ChatGPT 接上外掛就是 Agent。」 只對一半。如果每次工具呼叫都要你手動觸發、模型不能自己決定連續動作，那只是「加強版聊天機器人」。有沒有自主運轉的循環，才是分水嶺。

誤解二：「Agent 是某種新模型。」 不是。Agent 是圍繞模型的架構，不是模型本身。同一個 LLM，外面包一層聊天介面就是聊天機器人，包一層工具加循環就是 Agent。

誤解三：「越自主越好。」 自主性與可控性是光譜的兩端。自主性越高，行為越難預測、出錯時越難追查。生產環境的 Agent 幾乎都會刻意限制自主範圍，而不是放到最大。

新手最常踩的坑： 第一次玩 Agent 就直接給它真實的信箱、真實的資料庫、不設花費上限。正確做法是先在沙盒環境（用假資料、mock 工具、低額度）裡跑，觀察它的決策品質，確認可靠之後再逐步開放真實權限。本站的實作教學 你的第一個 Agent 就是用 mock 工具開始的。

下一步

• 想親手做一個：先照 五分鐘設置你的 LLM 開發環境 把環境裝好，再走 第一次呼叫 LLM API 發出第一個請求，最後用 你的第一個 Agent：一個會用工具的 Hello World 手寫出本文講的那個循環。
• 想理解底層原理：Transformer 架構解析 講 LLM 是怎麼運作的；Prompt Engineering 方法論 講怎麼把指令寫好——對 Agent 來說，這決定了大腦的品質。
• 想看更完整的框架視角：三層 Agent 框架 與 Agent 循環架構比較。
• 本篇出現的名詞：LLM（大型語言模型）、AI Agent（代理）、Tool Call（工具呼叫）、Agent Loop（代理迴圈）、Harness（執行環境／框架）、Sandbox（沙箱）。四個零件裡只有 LLM 是模型，其餘三個的定義都在詞彙表。