你一定聽過「AI Agent」這個詞，但多數解釋要嘛塞滿術語，要嘛抽象到讓人抓不到重點。這篇文章只解決一個問題：講清楚 Agent 到底是什麼、它跟你每天在用的 ChatGPT 差在哪、它適合做什麼事、又會在哪裡失敗。不需要任何程式基礎，出現術語時我們會當場解釋。
先搞清楚：LLM 本身只會「講話」
要理解 Agent，得先理解它的核心零件——LLM。LLM（Large Language Model，大型語言模型）是讀過海量文字、學會「接話」的 AI 模型，ChatGPT、Claude、DeepSeek 的底層都是它。LLM 做的事本質上只有一件：給它一段文字，它接著寫出下一段文字。
這個「只會接文字」的特性，帶來三個先天限制：
- 拿不到新資訊。 模型的知識停在訓練資料的截止點。你問它今天的股價，它只能「寫出」一個看起來像股價的答案，很可能是編的。這種「一本正經地說出不存在的內容」的現象，術語叫幻覺（hallucination）。
- 做不了動作。 它可以寫出「我建議您預訂會議室」，但它自己訂不了。它沒有手，只有嘴。
- 沒有記憶。 每一次 API 呼叫（API 是程式之間互相要求服務所用的標準介面）都是獨立的，模型預設不記得你上一句說過什麼。聊天軟體看起來「記得」對話，其實是每次都把整段對話紀錄重新傳給它。
Agent 就是為補齊這三個缺口而生的工程方案。
Agent = LLM + 上下文 + 工具 + 循環
剝掉所有行銷話術，任何一個 Agent 都由四個零件組成。
零件一：LLM，大腦。 負責理解指令、分析狀況、決定下一步做什麼。
零件二：上下文（context），大腦每一輪看到的全部資訊。 包括你的指令、對話歷史、工具執行回傳的結果、你額外補充的背景資料。因為模型沒有記憶，所有資訊都必須每一輪重新以文字塞給它。上下文的品質直接決定 Agent 的表現——餵給它錯的資訊，它就會做出錯的決定。
零件三：工具（tools），手腳。 一份「模型可以挑選的動作清單」，每個工具都有名字、用途說明與需要的參數。查天氣、搜尋網頁、執行程式碼、修改檔案、寄送郵件，都是工具。模型從清單中挑一個、照說明填好參數，由外層程式真正去執行。
零件四：循環（loop），串起大腦與手腳的神經。 這是 Agent 的靈魂。程式不是只問模型一次，而是跑一個迴圈：模型決定下一步 → 程式執行工具 → 把結果塞回給模型 → 模型再決定下一步 → 一直到模型判斷任務完成，輸出最終答案為止。
畫成流程圖：
你給 Agent 一個目標
↓
┌→ LLM 思考：下一步做什麼？ ←────────┐
│ ↓ ↓ │
│ 需要用工具 任務完成 │
│ ↓ ↓ │
│ 程式執行工具 輸出最終答案，結束
│ ↓
└─ 把工具結果塞回上下文
一句話總結：Agent 是一個讓 LLM 自己決定「下一步做什麼」、並且真的有能力去做的循環。
定義很簡單，但請注意一個常被忽略的事實：四個零件裡只有 LLM 是「模型」，其餘三個都是工程師寫的普通程式。一個系統是不是 Agent，跟它用了哪家模型關係不大，跟模型外圍的程式怎麼寫關係很大。
聊天機器人 vs Agent：三條判斷線
同樣是「跟 AI 對話」，聊天機器人和 Agent 的差別可以用三條線判斷：
| 判斷線 | 聊天機器人 | Agent |
|---|---|---|
| 誰決定下一步 | 你。每一輪都要人類追問推進 | 模型自己。循環持續運轉直到任務完成 |
| 能不能呼叫工具 | 不能，內容全靠模型「回憶」出來 | 能，會實際執行並拿到真實結果 |
| 能不能多輪迭代 | 一問一答，答錯等你糾正 | 多輪試錯，自己重試、自己修正 |
舉一個具體的例子。你說：「幫我查台北明天的天氣，如果可能下雨，把我下午的野餐改到星期四。」
聊天機器人的回應大概是：「我無法查詢即時天氣，請您自行查看天氣應用程式；若下雨建議改期。」它只能說。
Agent 的執行過程則是這樣：
- 呼叫天氣工具查台北明天的天氣 → 拿到真實回傳，例如「降雨機率偏高」
- 自己判斷這算「可能下雨」→ 決定要改期
- 呼叫行事曆工具，把野餐行程移到星期四
- 回報你：「明天降雨機率高，已幫你把野餐改到星期四下午」
關鍵差異在第 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 循環架構比較。